Web 服务与持久性套接字 [关闭]答案

【问题标题】：Web Services vs Persistent Sockets [closed]Web 服务与持久性套接字 [关闭]
【发布时间】：2010-04-12 16:31:49
【问题描述】：

我自己计划围绕这个问题做一些基准测试。但我认为从“社区”获得一些初步反馈会很好。有没有人对这两种技术的优缺点做过任何分析？我的想法：

与持久连接相比，为 Web 服务调用打开和关闭 TCP/IP 连接的成本相对较高。
使用基于 Web 服务的框架可以更轻松地处理间歇性连接错误和状态等。
您没有看到使用 Web 服务的魔兽世界。

我似乎无法在任何地方（甚至在这里）找到很多答案...是单个网卡可以支持的持久连接数的限制等吗？

【问题讨论】：

标签： c# wcf web-services tcp soa

【解决方案1】：

这是一个非常笼统的问题，是您明确提出的多个问题，还有更多相关的问题，您可能知道也可能不知道。

一个问题是 HTTP 与其他协议（准确地说是消息交换模式）的对比。 HTTP 是request-response，许多通信模式不适合请求响应范例。持久连接允许更灵活的面向消息的协议，例如典型的全双工聊天交换模式。

既然你提到WOW，他们使用UDP而不是TCP。 TCP 提供流保证语义，具有顺序保证且无重复。但是要实现这一点，就需要在延迟方面付出沉重的代价。像 WOW 这样的游戏对延迟更感兴趣，而不关心订单保证：最新的数据包总是最好，并取代任何以前的数据包信息。

还有更多的问题潜伏在表面之下：

出站防火墙穿越（HTTP 几乎总是允许）
读取和理解 HTTP 标头的侵入性代理
入站 NAT 穿越问题

最后是您刚刚询问的问题：TCP 套接字限制。它们取决于每个操作系统。例如，由于 TCP 端口耗尽，典型的开箱即用 Windows Server 将在大约 1000 个 TCP 套接字时阻塞。它必须是专门的tuned for higher numbers。即使经过调整，它也几乎不会接近 64K 开放、正常运行的套接字。对于需要连接到数百万客户端的服务器，连接必须由中间层多路复用，并且消息传递协议必须准备好处理转发产生的问题，最重要的是消息顺序反转。

这个问题空间很大，每座桥下都有很多龙。

【讨论】：

感谢您的回复。关于端口耗尽的示例似乎更适用于耗尽可用于通信的“返回端口”数量的客户端计算机，而不是托管在单个端口上的服务器。
接受套接字与侦听套接字不同。服务器耗尽端口，实际上速度很快。

【解决方案2】：

您正在将消息格式和传递方式结合在一起。如果您有一种消息，您可以节省位数并重新排列消息以便更快地使用消息，那么 Web 服务可能不是您的正确选择。如果我假设您有相对较大的基于文本的消息，那么 Web 服务可能会满足您的需求。有了这个，我将这样回答你的想法：

打开/关闭 TCP 连接：是的，这相对昂贵。 Web 服务依靠 HTTP（和 TCP/IP）以下列方式提供帮助：
- 如果单个客户端必须发送大量消息，他们可能会通过“保持活动”HTTP 连接发送消息。
- 您可以在 Web 服务器前面放置一个负载平衡器，以进一步优化 TCP 层。它将处理 TCP/IP 级别的连接混乱，并且只向您的 Web 服务器提供少数长期连接。
处理间歇性连接：HTTP 是无状态的，这让这更容易。
WoW 与 WS：我不确定所涉及的消息类型，但 WoW 需要发送一系列极短的消息，HTTP 标头本身的开销可能太大，无法保证 Web 服务。

我不知道你最后一个问题的确切答案。您的 Web 服务器可以处理的连接数将受到一个限制，然后您的操作系统会以套接字数量的形式施加另一个限制。

希望这会有所帮助。 -拉杰

【讨论】：

谢谢，拉吉。在评估这两种选择时，我认为您对发送的消息数量和大小的重要性是正确的。我也认为你说的从传输方法与协议的角度来看问题很模糊是对的。