原文网站： TCP协议如何保证可靠的传输_IT利刃出鞘博客-CSDN博客
本文介绍TCP协议保证可靠传输的原理。
这个内容也是Java后端面试中常见的问题。
摘要TCP协议保证数据传输可靠性的方法主要有：
大小控制APP应用的数据被划分成TCP确定为最适合传输的数据块。 序列号TCP对所发送的每个分组进行编号，接收端对分组进行排序，并将有序数据转发到APP应用层。 TCP的接收方丢弃重复的数据，根据序列号判断数据是否重复。 校验和TCP保存其报头和数据的检查。 它旨在进行端到端检查，并检测传输过程中的数据变化。 如果有接收段检查和错误，TCP将放弃此段，不确认接收。 在业务控制TCP连接中分别具有一定大小的缓冲空间，允许TCP的接收侧仅将发送侧缓冲器能够接收的数据发送到发送侧。 在接收侧赶不上发送侧的数据的处理的情况下，能够提示发送侧降低发送速率，防止分组丢失。 TCP使用的流控制协议是大小可变的滑动窗口协议。 在拥塞控制网络(TCP使用滑动窗口来实现业务控制)拥塞的情况下减少数据传输。 确认响应是ARQ协议实现的基本原理，其中每次传输分组时停止传输并等待对方的确认。 确认后发送下一组。 在重发超时TCP发出段之后，启动计时器，等待目的地确认接收到此消息段。 如果不能立即收到确认，请重新发送此消息。 详细说明校验和的计算方法。 在数据传输过程中，所有发送的数据段都被视为16位整数。 把这些整数加起来。 而且不能放弃前面的进位。 埋在后面，最后翻过来得到校验和。
发送方：发送数据前计算校验和，并进行校验和嵌入。 接收方：收到数据后，同样计算数据，求出校验和，与发送方进行核对。
注意：如果接收方的匹配校验和与发送方不匹配，则数据传输一定有错误。 但是，如果接收端的校验和与发送端一致，则数据的传输不一定成功。
响应和序列号序列号
TCP传输时对各字节的数据进行了编号。 这就是序列号。
序列号的作用不仅仅是响应的作用。 如果有序列号，则可以按序列号对接收到的数据进行排序，去除重复序列号的数据。 这也是TCP传输可靠性的保证之一。
确认应答
在TCP传输过程中，每次接收方收到数据时，都会对传输方进行确认响应。 也就是说发送ACK消息。 该ACK消息具有对应的确认序列号，告诉发送源接收到了哪个数据，下一个数据是从哪里发送的。
在进行TCP传输时，为了确认响应和序号的机制，即在发送侧发送了数据的一部分之后，等待来自接收侧的ACK消息，对ACK消息进行分析，判断数据传输是否成功。 如果发送方发送数据后延迟等待接收方的ACK消息，该怎么办？ 没有收到ACK消息的理由是什么呢？
首先，发送方没有介绍响应的ACK消息的理由有两个：
数据在传输中由于网络的原因等，直接导致整体数据包丢失，接收方完全没有接收。 接收方接收到响应数据，但发送的ACK消息响应因网络而丢包。 TCP在解决这个问题时引入了一种称为超时重发机制的新机制。 简单地说，发送方在发送数据后等待时间，如果时间到了还没有接收到ACK消息，就重新发送刚才发送的数据。 如果是刚才的第1个原因，则接收侧在接收到重发的数据后进行ACK响应。 如果是第二个原因，则接收端注意到接收的数据已经存在(因为判断为存在的依据是序列号，所以如上所述序列号具有去除重复数据的作用) )，直接丢弃，发送ACK响应。
那么发货人发货后要等多长时间？ 此等待时间太长会影响TCP传输的总体效率，而等待时间太短会经常发送重复的数据包。 怎么权衡？
TCP传输动态计算最大超时时间(即等待时间)，因为在任何环境中都能确保高性能通信。
在Linux上(甚至在BSD Unix和Windows上)超时由500ms单位控制，每次确定超时时，重传的超时时间都是500ms的整数倍。 如果重新发送一次，但仍然没有响应，请等待2*500ms的时间，然后再次重新发送。 等待4*500ms的时间继续重发。 正在指数增长。 累计到一定的重发次数后，TCP判断网络或对方有异常，强制关闭连接。
连接管理是指三次握手和四次挥手的过程，前面已经详细说明过了，这里不做说明。 保证可靠的连接是保证可靠性的前提。
流控制接收方在接收到数据后对其进行处理。 如果发送方的发送速度太快，接收方的结束缓冲区将立即填满。 此时，如果发送方仍在发送数据，则下一次发送的数据都将成为丢包，引起丢包的一连串连锁反应，超时后重新发送。 另一方面，TCP基于接收端的数据处理能力，决定发送端的发送速度。 这个机制
流量控制。在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
注：16位的窗口大小最大能表示65535个字节（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M，实际的窗口大小就是16为窗口字段的值左移M位。每移一位，扩大两倍。
拥塞控制TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。
慢开始慢开始不是指cwnd的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1。
思路：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图：
为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限（ssthresh状态变量）
当cnwd＜ssthresh，使用慢开始算法
当cnwd=ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
当cnwd＞ssthresh，使用拥塞避免算法
拥塞避免并非完全能够避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
思路：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞控制窗口加一。
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。
加法增大与乘法减小
乘法减小：无论是慢开始阶段还是拥塞避免，只要出现了网络拥塞（超时），就把慢开始门限值ssthresh减半
加法增大：执行拥塞避免算法后，拥塞窗口线性缓慢增大，防止网络过早出现拥塞
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量。
快恢复（与快重传配合使用） 采用快恢复算法时，慢开始只在TCP连接建立时和网络出现超时时才使用。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。注意
发送方窗口的上限值=Min（接受窗口rwnd，拥塞窗口cwnd）
rwnd＞cwnd 接收方的接收能力限制发送方窗口的最大值
rwnd＜cwnd 网络的拥塞限制发送方窗口的最大值
TCP 协议如何保证可靠传输 - SegmentFault 思否
网络基础：TCP协议-如何保证传输可靠性_Chenxi13-CSDN博客
TCP如何保证可靠传输_Lzc的博客-CSDN博客