TCP 协议如何提高传输效率

标签：协议窗口 ACK 应答 TCP 传输效率

本片主要讨论 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" ⼀起回给客户端；版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。本文链接：https://blog.csdn.net/J4Ya_/article/details/81005217 原作者删帖不实内容删帖

标签：协议,窗口,ACK,应答,TCP,传输,效率
From： https://www.cnblogs.com/yang131/p/16996446.html

TCP 协议如何提高传输效率

相关文章

相关文章

赞助商

阅读排行