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就可以搭顺风车,和服务器返回的话一起回给客户端

©️2020 CSDN 皮肤主题: 精致技术 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值