JavaEE 初阶 — 传输层中 TCP 协议的确认应答机制

冷不防 2023-10-04 21:08 10阅读 0赞

#### 文章目录 ####

*  确认应答机制
 *   *  1 什么是后发先至问题
     *  2. 如何解决后发先至问题

**TCP 的十大特性：**  
  
[超时重传机制][Link 1]

[连接管理机制][Link 2]

[滑动窗口][Link 3]

[流量控制与拥塞控制][Link 4]

[延时应答与捎带应答][Link 5]

[面向字节流的粘包问题与TCP的异常情况][TCP]

## 确认应答机制 ##

**确认应答** 是实现可靠传输的最核心机制。

这里指的 **可靠传输** 不是说 100% 可以把消息发给接收方，而是尽力而为，尽可能的把数据传输过去。  
同时，如果传输不过去，至少可以及时的获知。  
  
我要给张三发短信，如果是在十几年前，这个发送的短信就有一个很大的问题，那就是可能会**丢包**，尤其是高峰期的时候。  
  
有一天我想约张三出来一起去打球，所以就给他发了一个短信。  
  
![45a735cc553e4cc7be0a115a96906b07.png_pic_center][]  
  
这里张三回答的 OK 就称为 **“应答报文”**，也叫做 ack（acknowledge的缩写）  
  
当我收到 OK 的时候，我就知道，我发送的消息已经顺利的被张三看到了。（也就是短信没丢包）  
如果隔了半天还没有收到张三回复，就说明发送的消息大概率是没了。

TCP 进行可靠性传输，最主要的就是靠这个确认应答机制。  
A 给 B 发了一个消息，B 收到之后就会返回一个**应答报文（ACK）**。此时 A 收到应答之后，  
就会知道了刚才发的数就已经顺利到达 B 了。  
  
生活中随处可见这样的应答机制，比如打电话，打电话就相当于是可靠传输。

下面考虑一下更复杂的情况。  
  
![0b55256064644ba981d37a8f99a17cdc.png_pic_center][]  
此处我可能是连续发送两条消息，我发送第一条的时候，不需要等第一条消息的回应，而张三则是收到消息就会立即回应。

### 1 什么是后发先至问题 ###

网络上可能存在 “后发先至” 的情况，这个情况下，收到消息的顺序是可能存在变数的。  
  
考虑上述约张三打球的场景，如果收到消息的顺序是可能存在变数，那么我发送的打球去收到的会是滚犊子，  
而输的请客吃饭则会收到 OK。  
  
![8b1be39747ac4005aeda209e2062cb05.png_pic_center][]  
  
如果发生了 “后发先至” 的情况，本来要表达的含义就会出现歧义了。  
  
像 “后发先至” 这种情况，现实生活中也是挺常见的。  
  
比如说马拉松比赛，刚开始选手都是在起点线排在一起，有的靠前，有的靠后。  
  
![47497d1f1c304fb49810495bf6764763.png_pic_center][]  
  
随着比赛开始，由于每一个选手的速度和耐力都是不一样的，  
并且有的选手会因为体力不支而无法完赛，撤离赛场所走的路径与比赛选手的路劲也不同，  
因此想要保持比赛开始前的队形是非常困难的。  
  
**网络中数据的 后发先至 也是同理。**

两个主机之间，路线存在多条，数据报1 和 数据报2 走的都是不同的路线。  
数据报1 和 数据报2 转发的速率也不一样，有的快，有的慢，此时，这两个数据报到达的顺序就存在变数了。  
  
**结论：**

网络后发先至这个现象是客观存在的，是无法避免的。因此应答报文到达的顺序也是可能发生变动的。  
此时就需要考虑如何避免这种顺序错乱所带来的歧义。

### 2. 如何解决后发先至问题 ###

给传输的数据和应答报文都进行编号就可以了。  
  
![1cb77c90c41441a2bf13416a5a21ff91.png_pic_center][]  
这里的 1 和 2 就是**序号**，而 针对1 和 针对2 就是**确认序号**。  
当引入了序号之后，即使是顺序乱了，也可以通过序号来区分当前的**应答报文**是针对哪个数据进行的。

针对于 **序号** 的解释：

任何一条数据（包括应答报文）都是有序号的，确认序号则是只有应答报文有。（普通报文确认序号字段里的值无意义）

前面所提到的 ACK （确认号是否有效），是用来表示这一条报文是否是应答报文。  
如果 ACK 这个标志位为1，表示为应答报文，如果为0，表示不是应答报文。

实际上 TCP 的序号并不是按照 “一条两条” 这样的方式来编号的。TCP 是面向字节流的，TCP 的序号也是按照字节来编号的。  
  
![3633ba995aed464c92c9a39ed63c80dd.png_pic_center][]  
![fde0e69e94de42258e7532f88079d551.png_pic_center][]  
  
TCP 的字节的序号是依次累加的，这个依次累加的过程对于后一条数据来说，  
起始字节的序号就是上一个数据的最后一个字节的序号。

每个 TCP 数据报报头填写的序号只需要写 TCP 数据的头一个字节的序号即可。

TCP 知道了同一个字节的序号，再根据 TCP 报文长度，就很容易知道每一个字节的序号。

针对于 **确认序号** 的解释：  
  
确认序号的取值，是收到的数据的最后一个字节的序号 + 1。  
  
![8e9beec36f374de7b2c1ee562236a65c.png_pic_center][]  
应答报文中的确认序号填写的是 1001，就是在刚才 1000 的基础上 +1。

表示的含义：

1、小于 1001 的数据都已经确认收到了。  
2、主机1 接下来应该从 1001 这个序号开始继续发送。（主机2向主机1索要 1001 的数据）

**小结**：

1、TCP 可靠传输能力，最主要就是通过确认应答机制来保证的。  
2、通过应答报文，就可以让发送方清楚的知道传输是否成功。  
3、进一步的引入了序号和确认序号，针对多组数据进行详细的区分。  
  
可靠传输是 TCP 最核心的部分，TCP 的可靠传输就是通过 确认应答 + [超时重传][Link 1]来进行体现的。  
其中 **确认应答** 描述了是传输顺利的情况，而 **超时重传** 描述的是传输出现问题的情况。  
这两者相会配合，共同支撑整体的 TCP 可靠性。

![263a2c7651e249f2a1558f30a2cec9fb.gif_pic_center][]

[Link 1]: https://blog.csdn.net/m0_63033419/article/details/128981959?spm=1001.2014.3001.5501
[Link 2]: https://blog.csdn.net/m0_63033419/article/details/129016700?spm=1001.2014.3001.5502
[Link 3]: https://blog.csdn.net/m0_63033419/article/details/129032826?spm=1001.2014.3001.5501
[Link 4]: https://blog.csdn.net/m0_63033419/article/details/129032948?spm=1001.2014.3001.5501
[Link 5]: https://blog.csdn.net/m0_63033419/article/details/129073258?spm=1001.2014.3001.5501
[TCP]: https://blog.csdn.net/m0_63033419/article/details/129073509?spm=1001.2014.3001.5501
[45a735cc553e4cc7be0a115a96906b07.png_pic_center]: https://img-blog.csdnimg.cn/45a735cc553e4cc7be0a115a96906b07.png#pic_center
[0b55256064644ba981d37a8f99a17cdc.png_pic_center]: https://img-blog.csdnimg.cn/0b55256064644ba981d37a8f99a17cdc.png#pic_center
[8b1be39747ac4005aeda209e2062cb05.png_pic_center]: https://img-blog.csdnimg.cn/8b1be39747ac4005aeda209e2062cb05.png#pic_center
[47497d1f1c304fb49810495bf6764763.png_pic_center]: https://img-blog.csdnimg.cn/47497d1f1c304fb49810495bf6764763.png#pic_center
[1cb77c90c41441a2bf13416a5a21ff91.png_pic_center]: https://img-blog.csdnimg.cn/1cb77c90c41441a2bf13416a5a21ff91.png#pic_center
[3633ba995aed464c92c9a39ed63c80dd.png_pic_center]: https://img-blog.csdnimg.cn/3633ba995aed464c92c9a39ed63c80dd.png#pic_center
[fde0e69e94de42258e7532f88079d551.png_pic_center]: https://img-blog.csdnimg.cn/fde0e69e94de42258e7532f88079d551.png#pic_center
[8e9beec36f374de7b2c1ee562236a65c.png_pic_center]: https://img-blog.csdnimg.cn/8e9beec36f374de7b2c1ee562236a65c.png#pic_center
[263a2c7651e249f2a1558f30a2cec9fb.gif_pic_center]: https://img-blog.csdnimg.cn/263a2c7651e249f2a1558f30a2cec9fb.gif#pic_center