语言、编程-协议森林10 魔鬼细节 (TCP滑窗管理).pdf

2015/9/16 协议森林10 魔鬼细节 (TCP滑窗管理) ­ Vamei ­ 博客园 Vamei 编程，数学，设计 博客园  首页  博问  闪存   联系  订阅  管理 随笔­213  文章­1  评论­3338  协议森林10 魔鬼细节 (TCP滑窗管理) 作者：Vamei 出处：http :///vamei 欢迎转载，也请保留这 段声明。谢谢！   在TCP协议与流通信中，我们建立了滑窗(sliding window)的基本概念。通过滑 窗与ACK的配合，我们一方面实现了TCP传输的可靠性，另一方面也一定程度上提高了 效率。其工作方式如下面的视频所示： 如果视频加载有问题，可点下面链接： http :///v_show/id_XNDg1NDUyMDUy.html 然而，之前的解释只是概念性的。TCP为了达到更好的传输效率，对上面的工作方式 进行了许多改进。The devil is in the details. 我们需要深入到细节，才能 看清楚TCP协议的智慧所在。 /vamei/archive/2012/12/18/2822739.html 1/15 2015/9/16 协议森林10 魔鬼细节 (TCP滑窗管理) ­ Vamei ­ 博客园   累计ACK 在TCP连接中，我们通过将ACK回复“附着”在其他数据片段的方式，减少了ACK回复所 消耗的流量。但这并不是全部的故事。TCP协议并不是对每个片段都发送ACK回复。 TCP协议实际采用的是累计ACK回复(accumulative acknowledgement)。接收方 往往利用一个ACK回复来知会连续多个片段的成功接收。通过累计ACK，所需要的ACK 回复通常可以降到50%。 如下图所示，橙色为已经接收的片段。方框为滑窗，滑窗可容纳3个片段。 /vamei/archive/2012/12/18/2822739.html 2/15 2015/9/16 协议森林10 魔鬼细节 (TCP滑窗管理) ­ Vamei ­ 博客园 累计ACK   滑窗还没接收到片段7时，已接收到片段8，9。这样就在滑窗中制造了一个“空 穴”(hole)。当滑窗最终接收到片段7时，滑窗送出一个回复号为10的ACK回复。发 送方收到该回复，会意识到，片段10之前的片段已经按照次序被成功接收。整个过程 中节约了片段7和片段8所需的两个ACK回复。 此外，接收方在接收到片断，并应该回复ACK的时候，会故意延迟一些时间。如果在 延迟的时间里，有后续的片段到达，就可以利用累计ACK来一起回复了。   滑窗结构 在之前的讨论中，我们以片段为单位，来衡量滑窗的大小的。真实的滑窗是以byte为 单位表示大小，但这并不会对我们之前的讨论造成太大的影响。 发送方滑窗可以分为下面两个部分。offered window为整个滑窗的大小。   接收方滑窗可分为三个部分：   /vamei/archive/2012/12/18/2822739.html 3/15 2015/9/16 协议森林10 魔鬼细节 (TCP滑窗管理) ­ Vamei ­ 博客园 可以看到，接收方的滑窗相对于发送方的滑窗多了一个Received; ACKed; Not Sent to Proc的部分。接收方接收到的文本流必须等待进程来读取。如果进程正 忙于做别的事情，那么这些文本流即使已经正确接收，还是需要暂时占用接收缓存。 当出现上述占用时，滑窗的可用部分(也就是图中advertised window)就会缩水。 这意味着接收方的处理能力下降。如果这