【Linux网络】传输层协议TCP（3）滑动窗口、流量控制

hello~ 很高兴见到大家! 这次带来的是Linux网络中关于网络基础这部分的一些知识点,如果对你有所帮助的话,可否留下你宝贵的三连呢?个 人 主 页: 默|笙文章目录一、滑动窗口1.1 流量控制与窗口探测1.2 滑动窗口介绍滑动窗口的正常工作流程异常情况情况一报文已送达应答丢了情况二报文丢了通过滑动窗口来看情况二滑动窗口的边界一、滑动窗口1.1 流量控制与窗口探测流量控制就是通过 TCP 报文首部中的 16 位窗口大小这个属性来知晓对方的接收能力从而调整发送的速度。当对方的接收能力为 0 时即接收窗口大小为 0发送方如何知道对方什么时候能够重新接收数据这时候就用到“窗口探测”这个策略了。假设 A 和 B 通信当 B 的接收缓冲区满了之后A 会启动一个持续计时器每隔一段时间向 B 发送一个探测报文。因为确认应答机制B 收到探测报文后必须给 A 返回一个应答这个应答报文里就包含 B 当前的窗口大小A 借此就能知道 B 的恢复情况。真正的窗口探测报文通常会携带 1 个字节的有效数据。如果 B 的缓冲区还是满的B 会拒绝接收这 1 个字节并回复一个 ACK里面的窗口大小依然是 0如果 B 刚好腾出了空间B 就会收下这 1 个字节并回复一个包含新窗口大小的 ACK。A 借此就能实现精准的探测。为什么能传报头B的接受缓冲区不是满了吗这里说的“满”指的是内核中的 TCP 接收缓冲区满了无法再存放有效载荷。而报头Header是由系统内核的网络协议栈直接解析的处理报头既不占用 TCP 接收缓冲区也不受其容量限制。当 B 有了空闲位置之后它的内核也会主动向 A 发送一个窗口更新通知Window Update告知 A 最新的窗口大小。这个通知报文在传输过程中同样有丢失的风险此时窗口探测机制就可以作为兜底。这两个策略共同工作确保即使通知丢失发送方也能通过探测探知接收方的最新窗口状态。那么在第一次发送数据报文时发送方怎么知道对方的接收能力呢答案就在三次握手的过程中。在建立连接时双方发送的 SYN 报文和 SYN-ACK 报文的首部中都携带了各自的初始窗口大小Window Size字段。因此在连接正式建立、发送第一个数据报文之前发送方就已经通过三次握手获知了对方的初始接收能力。这也正是三次握手的重要作用之一它不仅在握手阶段完成了序列号同步还顺带完成了初始窗口大小的协商与同步。流量控制是动态调整的它不仅会在对方接收能力变小时限制发送方减慢发送速度也会在对方接收能力变强窗口变大时允许发送方加快发送速度。1.2 滑动窗口介绍我们知道TCP 发送数据并不是“发一个报文等一个应答”的停止等待模式而是一下子连续发送多个报文将大大缩短提高性能就是把多个应答的等待时间叠在一起了。那么问题来了这些连续发出的报文存在哪里而且发送出去的报文在等到对方的应答ACK之前是不能丢弃的因为如果丢了对方没收到就需要重传它们又保存在哪里流量控制又是如何精准地做到“不多发、不少发”的这一切都跟接下来要讲到的滑动窗口有关。滑动窗口位于发送缓冲区中是发送缓冲区里的一块区域通信双方的发送缓冲区都有。它把发送缓冲区分成三个部分已确认区域、窗口区域即“正发送区域”和待发送区域这里假设发送缓冲区是满的。发送缓冲区在逻辑上是线性结构因此滑动窗口自然也是线性的可以把它当作 char 类型数组来理解。已确认区域是已经收到应答ACK的报文数据窗口区域是滑动窗口当前覆盖的范围表示当前允许发送或已发送但尚未确认的数据待发送区域则是窗口右侧尚未进入发送窗口的数据。滑动窗口通过两个指针索引来定义开始和结束位置左指针 start_win 指向窗口的起始位置右指针 end_win 指向窗口的结束位置。发送窗口内尚未发送的数据可以直接连续发送不必“发一个等一个应答再发下一个”发送出去后进入等待应答状态。只有窗口左端的数据收到确认应答后滑动窗口才会右移已确认的数据才可以释放或复用未被确认的数据会一直保留在发送缓冲区中不能删除。滑动窗口的正常工作流程首先要确认滑动窗口的大小。这个滑动窗口的大小依据对方的接收能力通知窗口cwnd和拥塞窗口而定win_size滑动窗口容量 min(对方接收能力cwnd, rwnd拥塞窗口大小现在暂不做考虑只看对方接收能力)不因待发数据少而变小滑动窗口允许有空位。窗口通过移动两个指针来确定start_win 初始序列号 1 / 应答报文中的确认序号end_win start_win win_size。确认序号的意义就是让窗口左边界能够向前滑动释放已确认数据占用的窗口空间。假如初始序列号是 1001对方的接收能力是 4000要发送的数据设为无穷则win_size min(4000, 无穷) 4000start_win 1001end_win 5001。这个窗口内的数据可以连续发出去之后就是等待应答报文了。如图当收到确认应答之后窗口就要更新start_win 确认序号 2001。如果对方刚把数据放进接收缓冲区就被应用层读取上去那么接收能力仍是 4000窗口大小不变但整体向右移动此时 end_win 2001 4000 6001。如果对方没有及时读取数据那么它的接收能力就是 3000start_win 5001窗口缩小了。窗口也有变大的时候比如接收能力变大时例如应用层把其他数据读取上去。滑动窗口有没有可能左移研究两个指针就可以了start_win 不收到对应的确认序号是不会移动的而确认序号的含义是“该序号之前的数据已经接收完毕”所以 start_win 没有可能左移而且左边的数据也已经被清理或复用了。再看右指针 end_win start_win win_size。正常情况下 end_win 也只会向右移动因为窗口右边界不应收缩。这里要注意win_size 并不是发送前完全固定不变它会随接收能力变化如果 win_size 变小按公式 end_win 可能比原来小但 TCP 设计上应避免已通告窗口的右边界左移发送方也不应把窗口右边界回退。所以结论是两个指针正常都只向右移动——start_win 不左移是因为确认序号只前进end_win 不左移是因为窗口右边界不收缩。滑动窗口的大小通常取决于对方的接收能力以及之后要讲到的拥塞窗口因为一般要发送的数据会很多滑动窗口机制是实现流量控制的重要方式。接收方通过通告窗口rwnd告诉发送方还能接收多少数据发送方据此调整滑动窗口从而控制发送速率适配接收方的处理能力。异常情况情况一报文已送达应答丢了如果报文送到了但是应答丢了怎么办如图所示信道良好时总有应答能够传递到 A。即使 ACK1001、ACK3001、ACK4001 丢了只要 ACK5001、ACK6001 到达就能根据累计确认判断该确认序号之前的数据都已经收到前面的报文无需重传。对于最新发送的报文它传过去后如果迟迟收不到对应的确认应答就由超时重传机制兜底超时后重传该未确认报文。这就是确认序号机制可以大大减少因应答丢失而触发的重传次数的原因。情况二报文丢了如果报文丢了主机 B 丢失了 10012000 这段数据而后面的数据都收到了那么主机 B 对后续报文返回的确认序号都会是 ACK1001表示 1001 之前的数据已收到期望下次从 1001 开始发送。主机 A 一旦收到三个这样的重复 ACK冗余 ACK就判断该报文丢失立即触发快速重传。等主机 B 接收到 10012000 这段数据后会把已缓存的后续数据拼接起来并按累计确认机制更新确认序号通常直接更新到连续收到的数据末尾。超时重传机制作为兜底与快速重传一起保证数据传输的可靠性。快速重传Fast Retransmit 是 TCP 在“疑似丢包”时提前重传的一种机制发送方收到三个冗余 ACK同一个确认序号重复到达三次后不再等超时定时器到期而是立即重传对应报文。其他更复杂的丢包情况通常可以看作“报文丢失”和“应答丢失”这两种基本情况的组合解决方法仍然是上述机制的组合运用依靠累计确认减少因 ACK 丢失导致的重传依靠冗余 ACK 触发快速重传并由超时重传兜底保证数据最终可靠传输。通过滑动窗口来看情况二通过滑动窗口来看丢失情况可以把丢失情况分为三类最左侧数据丢失、中间数据丢失、最右侧数据丢失。如果是最左侧数据丢失左指针 start_win 不会移动因为确认序号一直等于当前的 start_win在重传并收到新的应答之后左指针才会向右移动。假如下一次后续数据都收到了那么下一次确认序号会因累计确认机制直接更新为 5001假使接收能力为 2000那么就是 start_win 5001end_win 5001 2000 7001。如果是中间数据丢失假如是 20013000 这段数据丢了那么确认序号会是 2001发送方收到后把 start_win 推进到 2001此时 20013000 就成为当前窗口最左侧的未确认数据这不就是最左侧数据丢失的情况吗最右侧数据丢失也是同样前面的数据确认后丢失段会成为新的窗口左端未确认数据。所以从“当前窗口最左侧未确认数据”的角度看数据丢失都可以概括为一种情况那就还是最左侧数据丢失。区别主要在于中间丢失常能由后续数据触发冗余 ACK进而快速重传最右侧丢失可能更多依赖超时重传兜底。滑动窗口的边界最后一点滑动窗口一直向右移动到发送缓冲区边界了怎么办可以把发送缓冲区理解成一个环形队列。逻辑上滑动窗口的右边界在序列空间里持续向右推进物理上缓冲区用固定大小的环形队列实现队头对应已确认区域队尾对应待发送区域窗口在队列中向右滑动。已确认的数据从队头出队并释放空间新数据从队尾入队指针走到数组末尾时通过取模回绕到开头复用左侧已释放的空间。未确认的数据继续留在队列中。这样滑动窗口在逻辑序列空间上一直向右移动在环形队列中则循环使用物理空间。缓冲区满时窗口右边界受可用空间限制新数据暂不能入队等确认释放空间后再继续推进。总结连续发出的报文保存在发送缓冲区中窗口内未被确认的数据会一直保留收到确认应答后窗口左边界向右移动已确认的数据才可以删除或复用。流量控制依靠滑动窗口实现接收方通过通告窗口告知接收能力发送方据此调整发送窗口大小。为什么发送数据不直接一整个发送4000字节而是要拆成好几段通常按MSS比如每段不超过约1460字节进行发送这主要和数据链路层的MTU限制有关MSS通常由MTU推导MAC帧最大长度是底层原因之一。今天的分享就到此结束啦,如果对读者朋友们有所帮助的话,可否留下宝贵的三连呢~~让我们共同努力, 一起走下去!