TCP协议中的可靠性机制

news2024/9/23 3:12:21

确认应答

滑动窗口

快重传

流量控制

窗口探测

拥塞控制

延迟应答

捎带应答

总结

相较于UDP协议，TCP协议由于要确保通信过程中的可靠性与尽可能提高通信效率提供了很多可靠性机制，因此TCP比较复杂。

确认应答

滑动窗口

滑动窗口是发送方/接收方的发送缓冲区中的一部分。

通过控制指针位置来改变滑动窗口的大小。滑动窗口是动态变化的，可能变小、变大、变成0。

对于确认应答策略如果让发送方每发送一个报文必须收到接收方的确认应答ACK才可以发送下一个数据段，这样做的缺点是性能较差，尤其是数据往返时间间隔较长的时候。既然这样一发一收的发送方式性能较低，那么一次可以发送多条数据，就可以提高性能(其实是将多个数据段发送与到达的时间间隔重叠在了一起)。

1、滑动窗口的大小指无需等待确认应答而可以继续发送数据段的最大值，上图的滑动窗口大小是4000字节即4个数据段。

2、A主机向B主机发送前4个数据段(1~4000)时直接发送，不需要等待任何ACK。

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

4、操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答。

5、只有确认应答过的数据, 才能从缓冲区删掉。

6、窗口越大, 则网络的吞吐率(单位时间里，网络中成功交付数据的平均速率)就越高。

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

数据段送达，但ACK丢失

如果数据1~1000与2001~3000对应ACK丢失，接收方给发送方返回的ACK报头中的确认序号是3001，因此确认序号保证了允许ACK丢失。其实接收方会根据收到的数据段的序号进行排序，如果序号是连续的说明没有数据丢失。

数据段丢了

快重传

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

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

这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

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

流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送，就会造成丢包, 继而引起丢包重传等等一系列连锁反应。

因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)。流量控制就是通过滑动窗口实现。

窗口探测

当接收端窗口大小(接收端接收缓冲区的剩余空间大小)为0时，向发送端确认应答，此时发送端就不会再向接收端发送数据段，接收端会隔一段时间向发送端发送窗口更新通知(接收端的用户层取走了数据)。对于发送端如果过了超时重发的时间还没有收到接收端的窗口更新通知，发送端就会向接收端发送窗口探测请求。过程如下图：

接收端如何把窗口大小告诉发送端呢 ? 在 TCP 首部中，有一个 16 位窗口字段 , 就是存放了窗口大小信息。

那么问题来了 , 16 位窗口大小字段最大表示 65535，那么 TCP 窗口最大就是 65535 字节吗 ?

实际上，TCP 首部 40 字节选项中还包含了一个窗口扩大因子 M，实际窗口大小是窗口字段的值左移 M 位，即实际窗口大小=16位窗口大小字段*(2^M)。

拥塞控制

虽然 TCP 有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据，但是如果在刚开始阶段就发送大量的数据、仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下 , 贸然发送大量的数据，是很有可能引起数据丢包， TCP 引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态 , 再决定按照多大的速度传输数据。

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

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

每次收到一个ACK应答, 拥塞窗口加1。

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

像上面这样的拥塞窗口增长速度, 是指数级别的。 "慢启动" 只是指初使时慢, 但是增长速度非常快。当拥塞窗口超过阈值的时候，不再按照指数方式增长，而是按照线性方式增长。