在什么情况下，应用程序可能会乱序接收 TCP 数据包？
Under what circumstances could an app ever receive TCP packets out of sequence?
我正在努力了解一个协议的措辞，该协议推断应用程序曾经能够乱序接收 TCP 数据包数据。那是 应用程序 乱序接收数据，而不是乱序出现在主机上的 IP 数据包。
这很好奇。我不知道任何可能允许这种情况发生的 TCP 实现。我认为这总是会违反 TCP 的核心原则。
谁能解释一下this passage in the MQTT 3.1.1 standard:
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.
Non normative comment
Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.
MQTT 是面向连接的，因此在任何其他时间重新发送将明确意味着通过相同的 TCP 连接发送相同的“控制数据包”两次。 如果数据没有第一次到达，接收主机肯定会阻止应用程序接收任何进一步的数据。重发无效.
确实，这和后来的MQTT 5.0 standard形成了鲜明的对比：
When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using their original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time [MQTT-4.4.0-1].
作者最初是不是搞错了？是否需要通过相同的 TCP 连接（由应用程序）重新传输数据来处理数据丢失？还是标准中的这段话只是误导而不是作者的本意？
请注意，这不仅仅是我对这种写法的推断。我已经看到该协议的主流实现周期性地通过相同的 TCP 连接重新传输相同的数据包。
如评论中所述，这是关于丢包，而不是乱序交付。
MQTT 的早期（甚至可能是第一次）部署在一个使用卫星回程形式的网络上，在该网络中，卫星调制解调器将在实际数据包传输到卫星之前以 ack 数据包响应，因此它客户端有可能认为数据包已被代理接收，而实际上它在路由上丢失了（在到达卫星的途中或返回的途中）。
我正在努力了解一个协议的措辞，该协议推断应用程序曾经能够乱序接收 TCP 数据包数据。那是 应用程序 乱序接收数据，而不是乱序出现在主机上的 IP 数据包。
这很好奇。我不知道任何可能允许这种情况发生的 TCP 实现。我认为这总是会违反 TCP 的核心原则。
谁能解释一下this passage in the MQTT 3.1.1 standard:
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.
Non normative comment Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.
MQTT 是面向连接的，因此在任何其他时间重新发送将明确意味着通过相同的 TCP 连接发送相同的“控制数据包”两次。 如果数据没有第一次到达，接收主机肯定会阻止应用程序接收任何进一步的数据。重发无效.
确实，这和后来的MQTT 5.0 standard形成了鲜明的对比：
When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using their original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time [MQTT-4.4.0-1].
作者最初是不是搞错了？是否需要通过相同的 TCP 连接（由应用程序）重新传输数据来处理数据丢失？还是标准中的这段话只是误导而不是作者的本意？
请注意，这不仅仅是我对这种写法的推断。我已经看到该协议的主流实现周期性地通过相同的 TCP 连接重新传输相同的数据包。
如评论中所述，这是关于丢包，而不是乱序交付。
MQTT 的早期（甚至可能是第一次）部署在一个使用卫星回程形式的网络上，在该网络中，卫星调制解调器将在实际数据包传输到卫星之前以 ack 数据包响应，因此它客户端有可能认为数据包已被代理接收，而实际上它在路由上丢失了（在到达卫星的途中或返回的途中）。