JavaEE 初阶第二十三期：网络原理，底层框架的“通关密码”(三)

专栏：JavaEE初阶起飞计划

个人主页：手握风云

目录

一、TCP协议

1.1. 滑动窗口

1.2. 流量控制

1.3. 拥塞控制

---

一、TCP协议

1.1. 滑动窗口

        TCP的确认应答、超时重传、连接管理都是保证TCP传输的可靠性，因为每发送一个数据，都要等ACK，单位时间内能传输的数据就变少了。而滑动窗口机制就是为了提高效率。

        通过上面两张图的对比可以发现，滑动窗口把每次发送数据等待ACK调整为批量发送一波，再等ACK，花等待一份的时间，其实是在等待多组ACK的到达。批量发送多少不需要等待的数据量称为窗口的大小。

        发送方是收到一份ACK，就立即往后发送一条数据。如下图所示，当A收到2001的ACK，就立即发送5001—6001的数据，那么此时等待ACK的窗口就变成了2001—6001。每收到一个ACK，窗口就会平移一个格子。

        滑动窗口效率的提升，本质上是在“亡羊补牢”。效率再怎么提升，也不如UDP的无可靠连接。

        滑动窗口的机制下，如果出现ACK丢包，在滑动窗口机制下，不需要做任何处理。因为根据ACK的确认序号，如果收到了1001，那么1001之前的数据就都会收到。

        如果1001数据丢包了，主机B反复向A索要这个数据，A感知到多次索要，就会认为出现了丢包，然后触发超时重传1001。B收到之后，自己的接收缓冲区中，已经有了2001—7000这些数据，接下来接收7001数据。这样的传输机制称作快速重传。

        滑动窗口的快速重传与确认应答、超时重传是TCP两套共存的机制，并不冲突。如果使用 TCP 传输较大量的数据的时候，自然就会触发滑动窗口，重传机制采取快速重传；如果使用 TCP 传输较少的数据，此时就仍然是按照确认应答和超时重传方式来进行。就如同物理学里的牛顿经典力学与爱因斯坦的相对论时空观，后者并没有否定前者。

1.2. 流量控制

        流量控制需要搭配滑动窗口使用，窗口越大，传输速度就越快。如果发送方速度很快，导致接收方没法收到数据，这也是不行的。流量控制，就是根据接收方的处理能力，干预发送方的发送速度，也就是调整滑动窗口大小。

        关于如何衡量接收方的处理能力，接收方拿到发送方的数据，通过TCP的接收缓冲区，作为中转场地。接收方缓冲区可以看作阻塞队列，如果里面没有数据，应用程序在read的时候就会阻塞。接收方的处理能力也就是调用read的速度。

        要想衡量read的速度

        进水，对应发送方发送数据的行为（数据 “流入” 接收缓冲区）；放水：对应应用程序读取（处理）数据的行为（数据从接收缓冲区 “流出”，被应用处理）。

        当进水速度（发送速度）固定时，放水速度（应用程序read的速度，即接收方处理数据的速度）越快，水池 “水位”（接收缓冲区的已用空间）就越低，剩余空间越大；反之，放水越慢，水位越高，剩余空间越小。若 “剩余空间大”（水位低）：说明接收方处理数据快，发送方可以加快发送速度；若“剩余空间小”（水位高）：说明接收方处理数据慢，发送方需要减慢发送速度，避免接收缓冲区溢出（数据因没地方存而丢失）。

        TCP的窗口大小，即报文中的 16 位窗口大小字段，告知发送方自己当前接收缓冲区还能容纳多少数据。发送方的 “发送窗口”（一次能发送的数据量上限）会受这个 “接收方声明的窗口大小” 制约 —— 发送方一次发送的数据，不能超过接收方告知的 “窗口大小”。

        流量控制的核心是“接收方通过反馈缓冲区剩余空间，让发送方调整发送速度”，而 “窗口大小” 是这个反馈的 “载体”。

        接收缓冲区的剩余空间，由接收方的处理速度决定（类比 “水池放水速度决定剩余空间”）。而 “窗口大小” 是对 “剩余空间” 的 “量化声明”，发送方又严格依据这个窗口大小来限制发送量—— 最终，“接收方的处理能力（流量控制的核心需求）” 通过 “窗口大小”，直接制约了发送方的发送窗口，实现了 “发送速度与接收能力的匹配”。

1.3. 拥塞控制

        TCP 拥塞控制的核心目标是防止网络过载，平衡传输效率与稳定性，通过动态调整发送窗口（受拥塞窗口cwnd控制）实现。

        拥塞控制和流量控制一样，都是限制滑动窗口的传输速度。在整个通信过程中，不仅有发送方和接收方，还有传输路径和中间的一些节点。这时我们就需要拥塞控制衡量发送速度。

        拥塞控制的核心思路：先按照比较小的速度发送数据，看一下是否丢包。如果丢包，说明中间链路已经有节点顶不住了，减小窗口大小，减小速度；如果不丢包，说明中间链路已经有节点顶不住了，增大窗口大小，增加速度。会维持着这样的动态平衡。

        发送方的发送窗口大小，同时取决于流量控制和拥塞控制，通过二者的最小值来调整窗口大小。

        拥塞窗口的变化过程，也是比较巧妙的设定：

1. 初始情况下，窗口大小非常小的，因为刚开始网络的畅通情况是未知的。
2. 慢启动之后如果不丢包，就会按照指数方式增长。
3. 指数增长到一定程度(达到阈值)，指数增长变成线性增长。
4. 线性增长到一定程度，终究会触发丢包(网络的承载能力到达上限了)。
5. 出现丢包，窗口大小一落千丈，回到最初慢启动窗口大小，接下来重复指数增长/线性增长的过程。