创建 TCP 连接的一般开销
我想知道与 UDP 相比创建新连接的一般成本。我知道 TCP 需要初始数据包交换（3 次握手）。还有什么其他费用？例如，内核中是否需要某种魔法来设置缓冲区等？
我问的原因是我可以保持现有连接打开并根据需要重用它。然而，如果重新连接的开销很小，就会降低复杂性。
I'd like to know the general cost of creating a new connection, compared to UDP. I know TCP requires an initial exchange of packets (the 3 way handshake). What would be other costs? For instance is there some sort of magic in the kernel needed for setting up buffers etc?
The reason I'm asking is I can keep an existing connection open and reuse it as needed. However if there is little overhead reconnecting it would reduce complexity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一旦 UDP 数据包被转储到线路上，UDP 协议栈就可以完全忘记它。对于 TCP，至少有连接详细信息（源/目标端口和源/目标 IP）、序列号、连接的窗口大小等......这不是大量数据，但在繁忙的服务器有很多连接。
然后还有 3 次握手。一些脑残（和/或恶意系统）可能会滥用该过程（查找“syn洪水”），或者只是断开其末端的连接，让您的系统等待永远不会到来的响应或关闭通知。有利的一面是，使用 TCP 系统将尽最大努力确保数据包到达它必须到达的地方。对于 UDP，根本没有任何保证。
Once a UDP packet's been dumped onto the wire, the UDP protocol stack is free to completely forget about it. With TCP, there's at bare minimum the connection details (source/dest port and source/dest IP), the sequence number, the window size for the connection etc... It's not a huge amount of data, but adds up quickly on a busy server with many connections.
And then there's the 3-way handshake as well. Some braindead (and/or malicious systems) can abuse the process (look up 'syn flood'), or just drop the connection on their end, leaving your system waiting for a response or close notice that'll never come. The plus side is that with TCP the system will do its best to make sure the packet gets where it has to. With UDP, there's no guarantees at all.
与数据包交换的延迟相比，所有其他成本（例如内核设置时间）都是微不足道的。
Compared to the latency of the packet exchange, all other costs such as kernel setup times are insignificant.
选项 1：创建 TCP 连接的一般成本为：
第 1 步：需要交换数据包，因此延迟了 to & 。网络延迟加上目标服务器的服务时间。两个机器上的 CPU 使用率均不显着。
步骤 2：取决于消息的大小。
步骤 3：IIRC，仅发送“立即关闭”数据包，无需等待目的地确认，因此不涉及延迟。
选项 2：UDP 成本：*
第 1 步：需要最少的设置，无需担心延迟，非常快。
步骤 2：注意大小，UDP 中没有重传，因为它不关心数据包是否被任何人收到。我听说消息越大，接收到的数据被损坏的可能性就越大，而且根据经验，超过 20 MB 的消息会丢失一定比例的消息。
第三步：最少的工作、最少的时间。
选项 3：改用 ZeroMQ
您正在将 TCP 与 UDP 进行比较，目的是减少重新连接时间。有一个很好的妥协：ZeroMQ 套接字。
ZMQ 允许您设置一个发布套接字，您不关心是否有人在侦听（例如 UDP），并且在该套接字上有多个侦听器。这不是 UDP 套接字 - 它是这两种协议的替代方案。
有关详细信息，请参阅：ZeroMQ.org。
它具有非常高的速度和容错能力，并且由于这些原因在金融行业中的使用越来越多。
OPTION 1: The general cost of creating a TCP connection are:
Step 1: Requires an exchange of packets, so it's delayed by to & from network latency plus the destination server's service time. No significant CPU usage on either box is involved.
Step 2: Depends on the size of the message.
Step 3: IIRC, just sends a 'closing now' packet, w/ no wait for destination ack, so no latency involved.
OPTION 2: Costs of UDP:*
Step 1: Requires minimal setup, no latency worries, very fast.
Step 2: BE CAREFUL OF SIZE, there is no retransmit in UDP since it doesn't care if the packet was received by anyone or not. I've heard that the larger the message, the greater probability of data being received corrupted, and that a rule of thumb is that you'll lose a certain percentage of messages over 20 MB.
Step 3: Minimal work, minimal time.
OPTION 3: Use ZeroMQ Instead
You're comparing TCP to UDP with a goal of reducing reconnection time. THERE IS A NICE COMPROMISE: ZeroMQ sockets.
ZMQ allows you to set up a publishing socket where you don't care if anyone is listening (like UDP), and have multiple listeners on that socket. This is NOT a UDP socket - it's an alternative to both of these protocols.
See: ZeroMQ.org for details.
It's very high speed and fault tolerant, and is in increasing use in the financial industry for those reasons.