【JavaEE网络】 TCP的可靠传输机制总结

---

可靠传输实现机制

确认应答

这是保证可靠性的最核心机制

TCP将每个字节的数据都进行了编号。即为序列号。

这是为了防止连续发多条数据的时候，可能出现“后发先至”的情况，也就是为了可靠性传输

由于TCP是面向字节流的，不是以“条”为单位来传输的。这里是第一条1_{1000，第二条1001}2000，也可以第一条1_{1500，第二条1501}2000。

1. 是针对字节编号的，不是针对“条”
2. 应答报文也是要和收到的数据的序号相关联的，但不是“相等”

此时就需要有办法区分出当前的这个报文是普通报文还是应答报文

就用到了6位标志位中的 ACK

ACK 为 0 表示这是一个普通的报文。此时只有 32 位序号是有效的

ACK 为 1 表示这是一个应答报文，这个报文的 序号 和 确认序号 都是有效的

ACK => acknowledge 应答

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。

TCP报文中，开始序号+长度-1 => 最后一个序号（但TCP报文中，没有保存最后一个序号，只有开始序号，但可以通过这样算）

核心一句话：确认应答，是TCP保证可靠性的最核心机制。而超时重传是TCP可靠性机制的有效补充

网络上说TCP保证可靠性的核心机制是“三次握手”，这是错的！！！

超时重传

丢包，在网络上很可能出现发一个数据然后丢了

网络传输过程中，路由器/交换机是“交通枢纽”。如果设备太繁忙，后面新来的数据等太久了，就可能被丢弃了，网络负载越高，越繁忙，就越容易被丢包

举例：你发信息给别人，信息发丢了但你不知道，但你知道你没有收到应答，因此你就会重新发一次

而超时重传，就是等待一定时间，超过一定的时间之后，再进行重传。

超时重传相当于针对确认应答，进行的重要补充

发的信息本身丢包了

发送端发送数据给接收端之后，可能因为网络拥堵等原因，数据无法到达接收端；

如果发送端在一个特定时间间隔内没有收到接收端发来的确认应答，就会进行重发；

但是，发送端未收到接收端发来的确认应答，也可能是因为ACK丢失了；

因此接收端会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。

这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。

以上两种情况无法区分，那就只能都重传咯~~

那么，如果超时的时间如何确定？

最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。

但是这个时间的长短，随着网络环境的不同，是有差异的。

如果超时时间设的太长，会影响整体的重传效率；

如果超时时间设的太短，有可能会频繁发送重复的包；

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。

如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。

如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。

重传次数达到一定程度，此时就会尝试“重置”TCP连接，TCP复位报文，是6位标志位中的RST，如果为1就是一个复位报文就尝试重新连接了

累计到一定的重传次数，如果仍无法成功，TCP认为网络或者对端主机出现异常，强制关闭连接，放弃连接了。

连接管理

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

握手：发一个打招呼的数据（不携带业务信息），使用这个打招呼触发“特定场景”

三次连接：A和B完成连接的过程，就需要“三次”这样的打招呼的数据交互

为啥可以合并？因为封装和分用

合并之后，节省了封装和分用的过程，降低了成本提高了效率

TCP三次握手的过程是怎么样的？

三次握手的意义是啥，要完成什么目的？初心是什么？

• 本质上是“投石问路”
• TCP要想保证可靠传输，可靠传输的前提是网络路径得畅通
• TCP三次握手，就是要验证网络通信是否通畅，以及验证每个主机的发送能力和接收能力是否正常

用打游戏连麦理解三次握手：把麦克风比作发送能力，耳机比作接收能力

第一次：

A发送“hellohellohello”，为了验证A的麦克风是否正常以及B的耳机是否正常

B收到“hellohellohello”，B就知道了A的麦克风没问题，B的耳机没问题

第二次：

B发送“hellohello”，为了验证B麦克风是否正常以及A的耳机是否正常

A收到“hellohello”，A就知道了A的耳机没问题，B的麦克风没问题

注意：到这一步，A是知道了双方的耳机和麦克风都没问题，但B还不知道B的麦克风和A的耳机是否正常，B只知道B的耳机和A的麦克风是没问题的

第三次：

A发送“hello”，就是对上述的“hellohello”进行回应

B收到“hello”，B就知道了B的麦克风没问题，A的耳机没问题

到了这一步，AB双方才都知道AB双方的麦克风和耳机都没问题

为什么是三次握手？

恰好三次，就能验证好双方的发送能力和接收能力均正常，并且把这样的信息同步给了双方

两次是否可以？

很明显不可以，虽然两次握手，可以验证完成通信能力的正确性，但是服务器这边还不知道这样验证通过的信息

四次是否可以？

可以但没必要（把中间两次拆成两次），三次即可，中间能合并就合并，这样能提高效率

三次握手还能起到“消息协商”这样的效果

通信的时候涉及到一些参数，需要双方保持一致，通过协商来决定参数具体是多少

TCP通信过程中，有很多信息是需要进行协商的。比如双方的序号从几开始（一般不会从0/1开始）

这样做主要是保证，两次连接，消息的序号能够有较大的差异，从而好去判定出某个消息是否属于这个连接

综上：三次握手，的初心主要就是两方面：

1. 投石问路，验证通信路径是否畅通，双方的发送/接收能力是否正常

2. 协商必要的参数，使客户端和服务器使用相同的参数进行消息传输

断开连接，四次挥手

连接：通信双方，各自在内存中保存对端的相关信息，如果不需要连接了，就得及时的释放上述存储空间

四次挥手的流程和三次握手非常相似

三次握手必定是客户端主动发起，四次挥手则不一定，服务器也可以发起，不过大多数情况是客户端主动发起

四次挥手为什么是四次，三次可以吗？

四次挥手有时候确实可以三次，但有时候不行。中间这两次不一定能合并

FIN的触发，是应用程序代码来控制的，调用socket.close()，或者进程结束，就会触发FIN

相比之下，ACK则是内核控制的，收到FIN就会立刻返回ACK

如果服务器始终不进行close会怎么样？客户端的连接就始终不关闭吗？

此时，服务器的TCP状态，就处于CLOSE_WAIT状态（还没close时），如果此时close了就发送FIN并且进入LAST_ACK状态，如果一直不close此时仍然是CLOSE_WAIT状态

站在服务器的角度，虽然这里的连接没有关闭，但是此时这个连接已经不能正常使用了

1. 针对当前socket进行读操作，如果数据还没读完（缓冲区还有数据），就能正常读到；如果数据已经读完了，此时就会读到 EOF(对于字节流来说，返回 -1。如果是scanner，hasNext就会为 false)
2. 针对当前socket进行写操作，直接就会触发异常

无论如何此时连接已经无法正常使用了，关闭是唯一的选择。

极端情况代码出现bug，忘记写close了怎么办？

此时站在客户端角度，迟迟收不到对方的FIN，也会进行等待。如果一直等，都等不到，就会单方面放弃连接（客户端直接把自己保存的对端信息给删了，释放了）

目标：就是释放资源，能双方顺利释放最好，如果不方便，单方面删也行。

如果通信过程中,出现丢包了，又咋处理？

这里也是涉及到超时重传的。三次握手，和四次挥手，也都是带有重传机制的

尽可能重传，如果重传仍然失败，连续多次，此时仍然会单方面释放连接

1. 如果是第一组FIN/ACK丢失，客户端直接重传FIN即可
2. 如果是第二组FIN丢失，服务器重传FIN即可
3. 如果是第二组ACK丢失，以下详细说明

站在A的角度，当收到这个FIN之后，并且发出去ACK了，此时A可以视为四次挥手结束，直接释放连接了吗？

不可以！！！

最后一个ACK还是很有可能丢包的。

如果最后一个 ACK 丢失, 服务器就会重新传过来一个，FIN，此时如果客户端已经把连接释放了，重传的 FIN 就无人能够进行 ACK了。

因此，就需要让客户端在发出去最后一个 ACK 之后，让连接再等一会。（主要就是看等的过程中会不会收到对方重传的 FIN）如果等了一定时间之后，对方还没有重传 FIN，就认为 ACK 已经被对方收到了此时客户端才能正确释放连接

同理这里客户端等多久？

等待时间是网络上任意两点之间传输数据的最大时间（定义为MSL）*2

举个生活例子：你送你家孩子去上幼儿园，假设你心比较大并不知道要不要上课，孩子进入幼儿园要花费t时间，你就等个2t时间看看是不是真上学，2t之后孩子没回头那你就走了

滑动窗口

作用：提高传输效率（更准确的说是让TCP在可靠传输的前提下，效率不要太低）（类似亡羊补牢的机制，是为了尽量止损）

使用滑动窗口，不能使TCP比UDP快，但可以缩小差距

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

没有滑动窗口，会带有确认应答

这样的传输，能够保证可靠性，但是大量的时间，都消耗在等 ack 上了

使用滑动窗口，就是为了缩短上述等待时间

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多

个段的等待时间重叠在一起了）。

一次性发出一组数据，发这一组数据的过程中，不需要等待ACK就直接往前发

此时，就相当于使用“一份等待时间”等四个ACK

把一次发多少数据，不用等ACK这样的大小，称为“窗口”

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。

发送前四个段的时候，不需要等待任何ACK，直接发送；

收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；

操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；

窗口越大，则网络的吞吐率就越高；

滑动窗口，是一个“形象的比喻”，实际上本质就是批量发送数据。这样就可以缩短等待时间，比之前能提升一定的效率(缩短不是没有，仍然需要花时间等待，传输效率仍然不会比 UDP 更高)

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

1. 数据报丢了
2. ACK丢了（这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认）

比方说，假如1001确认序号丢了，2001确认序号到了，表示2001之前的数据都收到了，也包括1~1000

滑动窗口下，超时重传

当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；

如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送；

这个时候接收端收到了 1001 之后，再次返回的ACK就是9001了（因为2001 - 9000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；

这种机制被称为 “高速重发控制”（也叫 “快重传”）。

其实就是超时重传，只是结合滑动窗口，产生的变形操作

流量控制

流量控制是作为滑动窗口的补充

滑动窗口越大，传输效率越高，但也不能无限大，如果太大接收方可能处理不过来了，或者是使传输的中间链路出现处理不过来，这样就会出现丢包，就得重传了，窗口大并没有提高效率，反而影响了效率。流量控制就是给滑动窗口刹刹车，避免窗口太大，接收方处理不过来

其实流量控制也是在跟生产者消费者模型有关，发送端生产速度很快，接收端消费速度跟不上就很快满了，满了还发数据就容易丢包

因此，流量控制就是根据接收方的处理能力，来限制发送方的发送速度（窗口大小）

因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（Flow Control）

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；

窗口大小字段越大，说明网络的吞吐量越高；

接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；

发送端接受到这个窗口之后，就会减慢自己的发送速度；

如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

拥塞控制

光考虑接收方，还是不够的，还需要考虑中间链路的处理能力（拥塞控制）

中间如果某个环节，转发能力特别差，此时发送端的发送速度就不应该超过这里的值

具体怎样去衡量中间设备的转发能力呢？

把中间的设备都看成一个整体而是采取“实验”的方式，动态调整，产生出一个合适的窗口大小

1. 使用一个较小的窗口传输。如果传输通常，就调大窗口
2. 使用一个较大的窗口传输，如果传输丢包(出现拥堵)，就调小窗口

拥塞窗口：在拥塞控制机制之下，采用的窗口大小

此处引入一个概念程为拥塞窗口

发送开始的时候，定义拥塞窗口大小为1；

每次收到一个ACK应答，拥塞窗口加1；

每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口；

TCP中拥塞控制具体是这样展开的：

1. 慢启动：刚开始进行通信的时候，会使用一个非常小的窗口,先试试水。

​ 像上面这样的拥塞窗口增长速度，是指数级别的。“慢启动” 只是指初使时慢，但是增长速度非常快。

为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。

此处引入一个叫做慢启动的阈值

当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长

2. 指数增长：在传输通畅的过程中，拥塞窗口就会指数增长(* 2)
3. 线性增长：指数增长当拥塞窗口达到一个值之后，就会从指数增长，转换成线性增长(+n)
4. 拥塞窗口回归小窗口：当窗口大小增长过程中，如果传输出现丢包，认为当前网络出现拥堵了

​ 此时就会把窗口大小调整成最初的小窗口，继续回到之前 指数增长 + 线性增长 的过程

​ 另外此处也会根据当前出现丢包的窗口大小，调整值(指数增长 -> 线性增长)

当TCP开始启动的时候，慢启动阈值等于窗口最大值；

在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1；

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；

当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

实际发送方的窗口=min（拥塞窗口，流量控制窗口）（此处不光考虑接收方的处理能力，更要考虑中间节点的处理能力）

拥塞控制和流量控制（这两个就可以视为保证可靠性的机制），共同限制了滑动窗口机制，可以使滑动窗口能够在可靠性的前提下，提高了传输效率了。

延迟应答

提高传输效率的机制，依然是围绕滑动窗口琢磨的

是否有办法在条件允许的基础上，尽可能的提高窗口大小呢？

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。因此就需要在返回ACK的时候，拖延一点时间，利用这个拖延的时间，就可以给应用程序腾出来更多的消费数据的时间。接受缓冲区的剩余空间就会更大了

假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；

但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；

在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；

如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；

那么所有的包都可以延迟应答么？肯定也不是；

数量限制：每隔N个包就应答一次；（滑动窗口）

时间限制：超过最大延迟时间就应答一次；（非滑动窗口）

具体的数量和超时时间，依操作系统不同也有差异；一般N取2，超时时间取200ms；

捎带应答

在延迟应答的基础上，引入的进一步提高效率的方式。延时应答是让ACK传输的时机更慢；捎带应答，基于延时应答，让数据进行合并

为啥说四次挥手可能是三次？
主要就是 延时应答和捎带应答 起到的效果