每条消息创建新 TCP 连接的性能影响
过去，我们的服务器应用程序被设计为客户端创建一个 TCP 连接，无限期地保持该连接的建立，并在需要时发送消息。这些消息可能会大量突发或中间有较长的空闲时间。我们现在正在切换到不同的连接协议，客户端将为每条消息创建一个新连接，然后在发送后断开连接。
我有几个问题：
我知道 3 次握手建立连接会产生一些开销。但是这个开销很大吗（CPU、内存、带宽等）？
已建立的已空闲几分钟的 TCP 连接传输消息的延迟与创建新连接并发送消息之间有什么区别吗？
如果我试图确定切换到这一新连接协议与旧连接协议相比对性能的影响，是否还应该考虑任何其他因素/注意事项？
是否还有其他因素
非常感谢任何帮助。
In the past, our server application was designed so that a client creates one TCP connection, keeps this connection established indefinitely and sends messages when needed. These messages may come in high volume bursts or with longer idle periods in between. We are switching to a different connection protocol now, where the client will create a new connection per message and then disconnect after sending.
I have a few questions:
I know there is some overhead for the 3-shake handshake to establish the connection. But is this overhead significant (cpu, memory, bandwidth, etc.)?
Is there any difference between the latency of message being transferred for an established TCP connection that has been idle for minutes vs. creating a new connection and sending the message?
Are there any other factors/considerations that I should be considering if I'm trying to determine the performance impact of switching to this new connection protocol compared to the old one?
Any help at all is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
打开和关闭大量 TCP 会话可能会影响连接跟踪防火墙和负载均衡器，导致它们减慢甚至失败并拒绝连接。有些（例如 Linux iptables conntrack）对于跟踪的连接数有适度的默认值。
如果程序循环消息的速度太快，则可能会耗尽可用的本地端口号。在套接字被视为“关闭”之前，存在 TCP 超时。通常有一个操作系统定时器来清理这些关闭的连接。如果打开太多套接字太快，操作系统可能没有时间进行清理。
握手会额外增加大约 80 个字节的带宽成本。 TCP 连接关闭还涉及 FIN 或 RST 数据包，尽管这些标志可能与数据包组合在一起。
如果为消息发送方打开 Nagle 算法，已建立的 TCP 会话的延迟可能会稍高一些。 Nagle 导致操作系统在发送部分填充的数据包之前等待更多数据。正在关闭的 TCP 会话将刷新所有数据。通过使用
TCP_NODELAY标志禁用 Nagle，可以在打开的会话中产生相同的效果。Opening and closing a lot of TCP sessions may impact connection tracking firewalls and load balancers, causing them to slow down or even fail and reject the connection. Some, like the Linux iptables conntrack, have moderate default values for the number of tracked connections.
The program might run out of available local port numbers if it cycles messages too quickly. There is a TCP timeout before a socket can be considered "closed". There is often an operating system timer to clean up these closed connections. If too many sockets are opened too quickly, the operating system may not have had time to clean up.
The handshake adds about an extra 80 bytes to your bandwidth cost. The TCP connection close also involves FIN or RST packets, although these flags may be combined with the data packet.
Latency in an established TCP session might be a tiny bit higher if the Nagle algorithm is turned on for the message sender. Nagle causes the OS to wait for more data before sending a partially filled packet. The TCP session that is being closed will flush all data. The same effect can be had in the open session by disabling Nagle with the
TCP_NODELAYflag.