TCP是否确保数据包按服务器发送的顺序接收到

我正在研究与游戏客户端通信的游戏服务器，但不知道客户端收到它时，数据包服务器发送给客户端是否保持顺序？TCP是否确保数据包按服务器发送的顺序接收到

像服务器发送数据包A，B，C 但客户端收到B，A，C？

我已阅读伟大的博客http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/ 看来，由服务器发送的每个数据包都有被客户端相应的ACK，但它并没有说为什么由客户端接收到的数据包与服务器

来源

2017-06-05 liu hao

@PSkocik你的意思是一个TCP数据包可能会被拆分为几个没有顺序保证的IP数据报，并且它会被正确地重组到原始TCP数据包中？ –

不一定。它也适用于整个细分市场。 – EJP

NB质量不佳。三次握手并不是“臭名昭着的”，至少不是因为引用中提出的任何有力的理由。 “TCP会话两端的客户端”是矛盾的。没有什么能够真正回答你的问题。 – EJP

值得一读TCP's RFC，特别是第1.5节（操作），它解释了过程。部分地说，它说：

TCP必须从互联网通信系统损坏，丢失，重复或乱序发送的数据中恢复。这是通过为每个传输的八位字节分配一个序列号，并要求来自接收TCP的肯定确认（ACK）来实现的。如果在超时间隔内未收到ACK，则重新发送数据。在接收器中，序列号用于正确排序可能无序接收的段并消除重复。通过向每个传输的段添加校验和，在接收器处检查它并丢弃损坏的段来处理损坏。

我看不出这是迄今为止最明确的，但自从确认（如第2.6节）描述了如何将数据包的下一个希望的分组，接收TCP实现永远只承认连续序列开始。也就是说，如果您从未收到第一个数据包，即使您收到了该消息中的所有其他数据包，也不会发送确认消息;如果你已经收到1,2,3,5和6，你只承认1-3。

为了完整起见，我还请你注意，以2.6节，再次，它描述了上面引述的部分后的详细信息：

通过TCP的确认并不保证数据已经交付给最终用户，但只是接收技术合作计划承担了这样做的责任。

因此，TCP确保数据包的顺序，除非应用程序没有收到它们。除了应用程序不可用的情况外，该例外可能不常见，但这确实意味着应用程序不应该认为成功的发送相当于成功的接收。它由于各种原因而可能是，可能是，但它明确超出协议的范围。

来源

2017-06-05 10:47:43

TCP相同的序列保证字节流的顺序和完整性。您将不会收到序列中的数据。从RFC 793：

可靠通信：一个TCP连接上发送的数据的流被可靠地且在为了在目的地递送。

来源

2017-06-05 10:06:10 EJP

TCP是否确保数据包按服务器发送的顺序接收到

回答

相关问题