TCP能保证按顺序到达吗？
如果我发送两条TCP消息，是否需要处理后者先于前者到达的情况？或者是否保证按照我发送的顺序到达？我认为这不是 Twisted 特定的示例，因为它应该符合 TCP 标准，但如果任何熟悉 Twisted 的人可以为我自己提供一个 Twisted 特定的答案，让我安心，那将不胜感激:-)
If I send two TCP messages, do I need to handle the case where the latter arrives before the former? Or is it guaranteed to arrive in the order I send it? I assume that this is not a Twisted-specific example, because it should conform to the TCP standard, but if anyone familiar with Twisted could provide a Twisted-specific answer for my own peace of mind, that'd be appreciated :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
只要这两个消息是在同一个 TCP 连接上发送的，顺序就会保持不变。如果在同一对进程之间打开多个连接，您可能会遇到麻烦。
关于 Twisted 或任何其他异步事件系统：我希望您将按照接收字节的顺序获得
dataReceived消息。然而，如果您开始将工作推迟到延迟调用上，那么您可以，呃……将您的控制流程“扭曲”到无法识别的程度。As long as the two messages were sent on the same TCP connection, order will be maintained. If multiple connections are opened between the same pair of processes, you may be in trouble.
Regarding Twisted, or any other asynchronous event system: I expect you'll get the
dataReceivedmessages in the order that bytes are received. However, if you start pushing work off onto deferred calls, you can, erm... "twist" your control flow beyond recognition.TCP 是面向连接的，并为客户端提供按顺序传送。当然，这适用于连接级别：各个连接是独立的。
您应该注意，通常我们指的是“TCP 流”和“UDP 消息”。
无论您使用什么客户端库（例如 Twisted），底层 TCP 连接都与其无关。 TCP 将按顺序向您的客户端传递“协议消息”。我所说的“协议消息”当然是指您在 TCP 层使用的协议。
进一步注意，I/O 操作本质上是异步的，并且非常依赖于系统负载+还加剧了网络延迟和网络延迟。损失，您不能依赖 TCP 连接之间的消息排序。
TCP is connection-oriented and offers its Clients in-order delivery. Of course this applies to the connection level: individual connections are independent.
You should note that normally we refer to "TCP streams" and "UDP messages".
Whatever Client library you use (e.g. Twisted), the underlying TCP connection is independent of it. TCP will deliver the "protocol messages" in order to your client. By "protocol message" I refer of course to the protocol you use on the TCP layer.
Further note that I/O operation are async in nature and very dependent on system load + also compounding network delays & losses, you cannot rely on message ordering between TCP connections.
TCP“保证”接收方将收到发送方最初发送的重组字节流。然而，在 TCP 发送/接收端点（即物理网络）之间，数据可能会无序接收、可能会被分段、可能会被损坏，甚至可能会丢失。 TCP 使用握手机制来解决这些问题，该机制会导致错误数据包重新传输。接收器上的 TCP 堆栈按照传输顺序放置这些数据包，以便当您从 TCP 套接字读取数据时，您将收到最初发送的数据。
当您调用 doRead 方法时Twisted 中，数据从套接字读取到缓冲区的大小。该数据可以表示单个消息、部分消息或多个消息。您可以从缓冲区中提取消息，但可以保证此时字节按其传输顺序排列。
抱歉，我之前的帖子把水搅浑了……
TCP "guarantees" that a receiver will receive the reconstituted stream of bytes as it was originally sent by the sender. However, between the TCP send/receive endpoints (i.e., the physical network), the data can be received out of order, it can be fragmented, it can be corrupted, and it can even be lost. TCP accounts for these problems using a handshake mechanism that causes bad packets to be retransmitted. The TCP stack on the receiver places these packets in the order in which they were transmitted so that when you read from your TCP socket, you are receive the data as it was originally sent.
When you call the doRead method in Twisted, the data is read from the socket up to the size of the buffer. This data may represent a single message, a partial message, or multiple messages. It is up to you to extract the messages from the buffer, but you are guaranteed that the bytes are in their transmitted order at this point.
Sorry for muddying the waters with my earlier post...
TCP是流，UDP是消息。你混淆了术语。对于 TCP 来说，流确实会按照发送时的顺序到达。 TCP 中没有明确的消息，字节在到达时出现，将它们解释为消息取决于您。
TCP is a stream, UDP is a message. You're mixing up terms. For TCP it is true that the stream will arrive in the same order as it was send. There are no distict messages in TCP, bytes appear as they arrive, interpreting them as messages is up to you.