本片主要讨论TCP协议在保证可靠传输的前提下,如何提高传输效率;
提高性能
- 滑动窗口
- 快重传
- 延迟应答
- 捎带应答
滑动窗口
如果我么每一次发送一个数据,都要给一个ACK应答,收到ACK应答以后再去发送下一个数据(如下图),那么我们的效率会比较低,大部分的时间都浪费在等待ACK应答上;
既然一发一收的效率比较低,那么我们可以一次发送多条数据,这样使等待的时间重叠在一起,那么我们就可以大大的提供性能;
- 窗口的大小是无需等待确认应答可以继续发送数据的最大值,上图窗口大小就是4000个字节(四个段);
- 发送前四个段的时候,不需要等待任何的ACK应答,直接发送;
- 收到第一个ACK应答以后,窗口向后移动,继续发送第五个段的数据;
- 操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录那些数据还没有应答;只有确认应答过的数据才能在缓冲区中删除;
- 窗口越大,网络吞吐量就越高;
- 在建立连接的时候已经确认了窗口的大小,确认了发送数据大小的上限;
丢包:
情况一: 数据报已经抵达,ACK丢了
这种情况下,部分ACK丢了并不要紧,因为后序的ACK已经到达了,证明前面的数据主机B已经收到了(如确认1001丢了,但是确认4001到达了对端,证明在4001以前的数据都收到了)
情况二: 数据报丢失
"快重传"
- 当某一个数据报丢失以后,发送端会一直收到对1001的确认应答,是在提醒"我下一个想要1001"
- 发送端连续收到了三个同样的ACK,就会将1001-2000进行重传;
- 这是接收端收到1001以后,再次确认的就是7001,因为已经收到了7001之前的,放在了接收缓冲区中;
延迟应答
如果接收数据的主机⽴刻返回ACK应答, 这时候返回的窗⼝可能⽐较⼩;
假设接收端缓冲区为1M. ⼀次收到了500K的数据;
如果⽴刻应答, 返回的窗⼝就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到⾃⼰的极限, 即使窗⼝再放⼤⼀些, 也能处理过来;
如果接收端稍微等⼀会再应答, ⽐如等待200ms再应答, 那么这个时候返回的窗⼝⼤⼩就是1M;
窗口越大,网络吞吐量就越大,传输效率就越高,我们的目的是在保证网络不阻塞的情况下尽量提高传输效率;
延迟应答的两个限制
- 数量限制: 每个N个包就应答一次;
- 时间限制: 超过最大的延迟时间就应答一次;
具体的数量和超时时间,不同的操作系统也有差异,一般N为2,超时时间取2000ms;
捎带应答
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应⽤层也是 "⼀发⼀收" 的.
意味着客户端给服务器说了 "How are you", 服务器也会给客户端回⼀个 "Fine, thank you";
那么这个时候ACK就可以搭顺⻛⻋, 和服务器回应的 "Fine, thank you" ⼀起回给客户端;