值得一读TCP's RFC,特别是第1.5节(操作),它解释了过程。部分地说,它说:
TCP必须从互联网通信系统损坏,丢失,重复或乱序发送的数据中恢复。这是通过为每个传输的八位字节分配一个序列号,并要求来自接收TCP的肯定确认(ACK)来实现的。如果在超时间隔内未收到ACK,则重新发送数据。在接收器中,序列号用于正确排序可能无序接收的段并消除重复。通过向每个传输的段添加校验和,在接收器处检查它并丢弃损坏的段来处理损坏。
我看不出这是迄今为止最明确的,但自从确认(如第2.6节)描述了如何将数据包的下一个希望的分组,接收TCP实现永远只承认连续序列开始。也就是说,如果您从未收到第一个数据包,即使您收到了该消息中的所有其他数据包,也不会发送确认消息;如果你已经收到1,2,3,5和6,你只承认1-3。
为了完整起见,我还请你注意,以2.6节,再次,它描述了上面引述的部分后的详细信息:
通过TCP的确认并不保证数据已经交付给最终用户,但只是接收技术合作计划承担了这样做的责任。
因此,TCP确保数据包的顺序,除非应用程序没有收到它们。除了应用程序不可用的情况外,该例外可能不常见,但这确实意味着应用程序不应该认为成功的发送相当于成功的接收。它由于各种原因而可能是,可能是,但它明确超出协议的范围。
@PSkocik你的意思是一个TCP数据包可能会被拆分为几个没有顺序保证的IP数据报,并且它会被正确地重组到原始TCP数据包中? –
不一定。它也适用于整个细分市场。 – EJP
NB质量不佳。三次握手并不是“臭名昭着的”,至少不是因为引用中提出的任何有力的理由。 “TCP会话两端的客户端”是矛盾的。没有什么能够真正回答你的问题。 – EJP