我正试图理解一个协议的措辞，该协议推断应用程序曾经能够按顺序接收TCP数据包。这是应用程序按顺序接收数据，而不是按顺序显示在主机上的IP数据包。
这很奇怪。我不知道TCP的任何实现都可能允许这种情况发生。我认为这总是违反TCP的一个核心原则。
有人能解释一下MQTT 3.1.1标准中的这段话吗：
当CleanSession设置为0的客户端重新连接时，客户端和服务器都必须使用其原始数据包标识符[MQTT-4.4.0-1]重新发送任何未确认的PUBLISH数据包(其中QoS>0(和PUBREL数据包。这是唯一需要客户端或服务器重新传递消息的情况。
非规范性意见历史上需要重新传输控制数据包，以克服某些旧TCP网络上的数据丢失问题在这样的环境中部署MQTT 3.1.1实现时，这可能仍然是一个问题。
MQTT是面向连接的，因此在任何其他时间重新发送将明确地意味着发送相同的"；控制包"；断开同一TCP连接两次如果数据不是第一次到达，那么接收主机肯定会阻止应用程序接收任何进一步的数据。重新发送是徒劳的。
事实上，这与后来的MQTT 5.0标准形成了鲜明对比：
当客户端在Clean Start设置为0且存在会话的情况下重新连接时，客户端和服务器必须使用其原始数据包标识符重新发送任何未确认的PUBLISH数据包(其中QoS>0(和PUBREL数据包。这是唯一需要客户端或服务器重新发送消息的情况客户端和服务器不得在任何其他时间重新发送消息[MQTT-4.4.0-1]。
作者最初是错的吗？是否需要通过相同的TCP连接重新传输数据(由应用程序(来处理数据丢失？还是标准中的这段话只是误导，而不是作者的意图？
请注意，这不仅仅是我对这一措辞的推断。我已经看到这个协议的主流实现周期性地在同一个TCP连接上重新传输相同的数据包
正如评论中所提到的，这是关于数据包丢失，而不是无序交付。
MQTT的早期(甚至可能是第一次(部署是在使用卫星回程形式的网络上进行的，其中卫星调制解调器将在实际数据包传输到卫星之前用ack数据包进行响应，因此客户端可能认为数据包已由代理接收，而实际上数据包已丢失(要么在上卫星的路上，要么在下卫星的路上(。