Linux（二十六）TCP的高效性体现

TCP提高高效性的方法

*滑动窗口
*快重传
*延迟应答
*捎带应答

滑动窗口

上一篇我们说了确认应答机制，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点就是性能较差，尤其是数据往返的时间较长的时候
既然这样一收一发的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段等待时间重叠在一起了）。

*窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。
*发送窗口大小数据的时候，不需要等待任何ACK，直接发送；
*收到一个ACK后，滑动窗口向后移动继续发送下一个段的数据，以此类推
*操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有那些数据没有应答；只有确认应答过的数据才能从缓冲区中删除；
*窗口越大，网络的吞吐量就越高

在这里我们假设滑动窗口的大小是4000，那么我们把数据1001-2001从主机A发送给主句B，在收到主机B的确认应答后，滑动窗口就会往后移动

快重传

那么问题来了
如果出现了丢包的问题，数据怎么进行重传呢？
这里有两种情况

1：数据包已经抵达，但是ACK被丢了
2：数据包丢了

我们先来看第一种情况

这个时候我们不用担心，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认，知道前面的数据没有丢

第二种情况

*当某一段报文段丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端“我想要的是1001”
*如果发送端主机连续三次收到了同样的1001这样的应答，就会将对应的数据1001-2000重新发送
*在这个时候接收端收到了1001，返回的ACK就是6001，其他的已经收到了

这种机制被称为快重传，我们在上一篇中讲到，超时重传，两个 是不一样的，缺一不可，超时重传是没有收到一次ACK，超过时间才会重传，而这里的快重传是收到重复ACK3次后重传

延迟应答

如果接收数据的主机立刻返回ACK应答，这个时候返回的窗口可能比较小。
*假设接收缓冲区为1M，一次收到500K的数据；如果立刻应答，返回的窗口就是500K；
*但实际上可能处理端处理的素的很快，10S之内就把500K数据从缓冲区中消费掉了；
*在这种情况下，接收端处理还远没有达到自己的极限，即使窗口在放大一些，也能处理过来；
*如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；

窗口越大，网络吞吐量就越大，传输效率就越高，我们是为了保证网络不拥塞的情况下，尽量提高传输效率

捎带应答

在延迟应答的基础上，我们发现很多情况下，客户端服务器在应用层也是“一发一收”的，意味着客户端给服务器说了一句话，服务器也会给客户端回一句话；
那么这个时候ACK就可以搭顺风车，和服务器返回的话一起回给客户端