【Linux从青铜到王者】tcp协议2

滑动窗口

滑动窗口是什么

上篇提到如果两端发送数据如果是一发一收那就是串行，效率很低，所以可以一次发送多个报文，一次也可以接受多个报文，可以大大的提高性能(其实是将多个段的等待时间重叠在一起了）

那么是怎么发送多个报文的呢？靠的就是滑动窗口这个大杀器

滑动窗口是什么？是为了让tcp并发地发送大量暂时不需要ACK的数据段，从而提高发送效率的解决方案（这里也涉及流量控制的解决方案，和重传机制也有关系！）

如果学习过双指针算法的同学可能听到滑动窗口这个名字很熟悉，其实这里就是类似的

之前我们说过可以把缓冲区当做一个单位大小为char的数组，然后有两个指针win_start和win_end分别指向滑动窗口的起始位置和结束位置

这样发送缓冲区就被分成了三个区域：

滑动窗口的左边区域，处于滑动窗口的区域，滑动窗口的右边区域

分别对应已发送已确认，可以直接发送但是尚未确认，未发送或者没数据的区域

下图为示范例子：

窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。图中，窗口大小为4个段，也就是4000个字节。
发送前四个段的时候, 不需要等待任何ACK, 直接发送。
收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推。
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉——所以一个数据被发送后，不能立马被移除
窗口越大, 则网络的吞吐率就越高

滑动窗口在哪里？

滑动窗口本质上就是发送缓冲区的一个区域

滑动窗口怎么理解？

【win_start,win_end】：滑动窗口！！——本质就是两个数组下标充当指针作用

win_start=确认序号

win_end=win_start（确认序号）+win（接收方的接受能力）——16位窗口大小

所谓的窗口滑动，本质就是下标移动

因为滑动窗口发送的是可以直接发送尚未确认的数据，所以要考虑对方的接受能力，所以滑动窗口的大小由对方的接受能力决定！！！（后续会有变化）

那么最开始的时候，我还没发送数据的时候，滑动窗口的大小是多大？

所以在三次握手的时候，滑动窗口的大小，双方已经协商完毕

滑动窗口的变化以及流量控制

滑动窗口可以往左移动吗？

不可以，win_start=确认序号，而确认序号=序号 +1的，所以滑动窗口只可能往左移动

滑动窗口的大小不变吗？变大？变小？为0？

当确认一个报文后又发送一个报文的时候，滑动窗口的大小就是不变的

当一次发了四五个报文，只有前面两个应答了，那么win_start+=2个报文的长度，滑动窗口也就变小了。后面全部报文都应答了，win_end+=三个报文的长度，滑动窗口也就变大了

所以不变，变大和变小都是可以的——流量控制！！！

接收方能力弱：我就发慢点

接收方能力强：我就发快点

变大变小不变都行，这才叫控制

如果滑动出去，越界了怎么办？把发送缓冲区想象成环形结构即可！！！（环形数组可以用数组来模拟实现）

这里也体现到上篇提到的如果报文发送了，还没应答，就不能丢弃，暂时存起来，存在哪？滑动窗口里

报文丢失

一次发多个数据，那么肯定会有上篇讲的丢失报文的问题，那么报文丢了怎么办？

我们可以将报文丢失分为三类：最左侧丢失，中间丢失，右侧丢失

如果发了序号2000,3000,4000,5000的四个报文，正常情况下发送方应该收到确认序号为2001,3001,4001,5001的ACK

最左侧丢失就是2001ACK没收到，那么此时后面的确认序号就不再是3001,4001,5001了，而是1001，因为确认序号的定义是该序号之前的数据，全部收到

所以连续接收到三个1001ACK，但是明明发的是2000,3000,4000，5000，所以就可以推测出是2000报文丢失了，所以会补发2000报文！！！

如果是中间丢失，也就是3001丢失，那么发送方是接收到2001ACK的，所以窗口会向右移动一个长度，此时中间丢失就变成最左边丢失，重复以上动作即可

如果是最右侧丢失，那么结果还是一样的，窗口不断右移直到丢失的报文成为最左侧，变成最左侧丢失的情况，然后重复上述操作！

总结：不管是什么丢失，最后都会变成最左侧丢失

这里涉及到一个重传机制

快重传：如果连续收到三个同样的确认序号的时候，会立即将对应的报文进行补发！！！

有人会想了，都有快重传了，听名字就挺快的，还要超时重传干什么？

细看的话会发现快重传是有条件的，要连续收到三个同样的确认序号，不是连续的话只能超时重传了

所以超时重传是兜底的，快重传是提高效率的重传策略，两者互相配合

在滑动窗口这里，可以充分体会到确认序号的的价值！！！

还有将缓冲区视为字节环形结构的作用——有了序号和确认序号，保证了可靠性——发送成功或者失败都100%知道！！！

到这里不得不赞叹tcp的设计，几个字段互相配合不仅仅保证了可靠性，还实现了效率的提升

拥塞控制

到目前为止我们讲的都是两个主机之间的，两个主机之间通信还要经过网络这一环节

假设有一天网络突然瘫痪（网络非常繁忙）了，发送的报文迟迟未被接收，那么此时要进行超时重传吗？

如果这时进行超时重传，注意此时不再是两台主机之间通信，可能有很多台主机都向你超时重传发送信息，注意此时网络已经瘫痪，超时重传等于再发一次信息，无异于压死骆驼的最后一根稻草，让网络雪上加霜

所以此时不能进行网络重传

当出现小面积丢包的时候，认为是丢包，进行超时重传

当出现大面积丢包的时候，认为是网络出现问题，不超时重传，而是拥塞控制

什么是拥塞控制呢？就是先试探，慢慢发，随着你应答的次数增多而显著提高发送的数据量

滑动窗口决定了我们单次发送数据量的多少——所以滑动窗口的大小不仅与对方的接受能力有关，还要考虑网络的状态

滑动窗口=min（拥塞窗口大小，对方的窗口大小）

拥塞窗口本质就是一个数字，当发送数据量超过拥塞窗口的时候，有很大的概率会引起网络拥塞

拥塞窗口=2^n，就是个指数函数。可以发现该函数完美切合要求，慢启动，快增长。

前期慢，增长快——前期慢是为了试探网络环境如何，增长快是为了尽快进行正常网络的通信

当拥塞窗口的值超过阈值的时候，拥塞窗口就会变成线性增长，变化规律如图所示，就不赘述

我们发送数据的时候，就是按照图片的规律来发送吗？当然不是，发送数据靠什么？靠滑动窗口？滑动窗口win_start=ack,win_end=min（拥塞窗口大小，对方窗口大小）

所以可能发送到一半就按照对方窗口的大小发送了

但是拥塞窗口必须一直在变化，因为网络的状态要一直探测

tcp的保活机制（心跳机制）

当机器掉电，网线断开的时候，tcp内部有一个计时器，当超过固定时间后仍未应答则自动关闭连接，但是tcp的时间定的太长了，一般更推荐在应用层完成

listen的第二个参数

全连接队列

饭店排队场景类似

如果一个饭店里很多人用餐没有位置了，此时又新来了客人，你直接对客人说走吧没位置了，那肯定会被老板喷个狗血淋头，因为等里面的客人吃完了，如果此时又没新的客人来，高峰期的时候一些座位就会被闲置了

如果你在外面放了一些椅子，让客人在外面等，这时里面的人用完餐了，外面的人就可以直接进去用餐了，高峰期里面的位置被闲置的概率大大降低

但是你也不能在外面摆太长，比如摆个几百张，除了前面几十张等得起，后面的人要等的时间太久了，而且椅子也是占空间的，外面的地可不是都是你们店的

上面的饭店就类似应用层，客人就是连接，外面摆的椅子就是全连接队列，全连接队列不能太长