2011-10-06 28 views
0

过去,我们的服务器应用程序的设计使得客户端创建一个TCP连接,使该连接无限期地建立并在需要时发送消息。这些消息可能会以大量突发或较长的空闲周期进入。我们现在正在切换到不同的连接协议,客户端将在每个消息中创建一个新连接,然后在发送后断开连接。每条消息创建新的TCP连接的性能影响

我有几个问题:

  1. 我知道有一些开销为3摇握手建立连接。但是这个开销是否显着(CPU,内存,带宽等)?

  2. 为建立的TCP连接传输的消息的等待时间与创建新连接并发送消息之间是否存在差异?

  3. 如果我试图确定切换到这个新的连接协议相比旧协议的性能影响,我应该考虑是否有其他因素/考虑因素?

任何帮助都非常感谢。

+0

您还应该考虑每次发送消息时启动3次握手的延迟影响 – cordialgerm

+1

为什么要这样做?你走错了方向。几十年来,每个人都在疯狂地将连接池添加到他们的应用程序和中间件层中。 – EJP

回答

1

打开和关闭很多TCP会话可能会影响连接跟踪防火墙和负载平衡器,导致它们减慢甚至失败并拒绝连接。有些像Linux iptables conntrack一样,对跟踪的连接数有适度的默认值。

如果程序循环过快,程序可能会用尽本地端口号。在套接字被视为“关闭”之前有一个TCP超时。通常有一个操作系统计时器来清理这些关闭的连接。如果打开太多插槽太快,操作系统可能没有时间清理。

握手会为您的带宽成本增加大约80个字节。 TCP连接关闭也涉及FIN或RST数据包,尽管这些标志可能与数据包组合在一起。

如果为邮件发件人启用了Nagle算法,则在建立的TCP会话中的延迟可能会稍高一点。 Nagle使得OS在发送部分填充的数据包之前等待更多的数据。正在关闭的TCP会话将刷新所有数据。在公开会议中,可以通过使用TCP_NODELAY标志禁用Nagle来实现同样的效果。

+1

握手需要三个最小大小为40字节的TCP段,总数为120,最后一个可以捎带数据。 – EJP

+0

@EJP:你的两端还有两个F数据包。 –

+0

握手仍然是三段。关闭FIN *段*和他们的ACKS是另外四个*段,所有这些都可以搭载。 – EJP