admin管理员组

文章数量:1546091

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                本文写于国庆长假第一天早晨，正好碰到今天热线值班，终于不用假期出去添堵折腾了(14年来[自离开高中]，从来没有过过一个完整的可以休息的假期！预定了N次在家的假期，失败了N次，谎称过几次加班，但也不是长计，因为必须要离开家，实在也没地方去，我觉得此生假期难自由了，然而如果公司硬性规定必须在家值班，那也是不啻一种上好的方法啊！哈哈)，作文一篇，以表达对假期自由的感慨！

最开始的事实

首先，我们先明确Linux TCP实现中的3个事实，这些叫做“事实”的论述是颇为主观的，它们只是我积累下来的所谓“事实”，这些事实即：

1.Linux作为数据接收端的时候，默认不会Delay ACK，直到...
直到Linux接收端发现了处在交互模式，即pingpong设置为1的时候，才会开启Delay ACK。你试下在Linux上用wget去一个web服务器下载一个文件并抓包，你会发现对接收到的数据的ACK并没有Delay。这也是与Windows的Delay ACK不同的地方，详情参见《 TCP之Delay ACK在Linux和Windows上实现的异同-Linux的自适应ACK》
2.按序接收的快速路径中，TCP接收端如果收到已经收到的数据，会直接丢弃
这个事实可以引申到部分重叠模式的数据接收。举个例子，如果收到一个按序的长度为10的skb，携带序列号10-20，那么当再次收到长度为15，携带序列号15-25的skb时，会将已经收到的15-20丢弃，仅仅保存21-25的新数据。不光如此，当收到这样的部分重叠数据时，会立即回复一个ACK，不管当前是不是处在交互行为的Delay ACK模式下。
3.乱序接收的慢速SACK路径中，TCP接收端如果收到已经收到的数据，会用新数据覆盖老数据
这显然是合理的，因为在乱序模式下，意味着可能出现了丢包或者多径延时，这将使TCP离开正常的状态，此时不管是发送端还是接收端所有的努力都是趋向于将TCP带回到按序处理的快速路径，接收端会尽可能快速回复ACK以反馈信息，发送端会重传可能丢失的数据，由于接收端并不对乱序数据做任何存储上的保证，因此其假设直到最终填洞完毕，之前的数据都可能无效！但是确实一定是这样吗？请跟着在下面实验中找答案。
        以上3个事实看起来并不是显然的，因此需要涉及一些用例来验证。能够探测TCP行为的轻量级工具，我选packetdrill，因此我们就用这个工具来验证吧。

packetdrill验证事实

现在我们来用packetdrill验证一下上述的事实。由于需要验证事实2和事实3，因此需要打印出接收端收到的数据，当前的packetdrill并不支持这个功能，所以需要修改它的代码。
1.为packetdrill构造的数据段增加可以用来区别的payload信息并打印
为此，我们需要修改tcp_packet.c的new_tcp_packet函数，增加简单的payload： 
struct packet *new_tcp_packet(int address_family,                               enum direction_t direction,                               enum ip_ecn_t ecn,                               const char *flags,                               u32 start

本文标签： 数据TCPoverlapAckDelay

版权声明：本文标题：TCP接收到重叠数据 overlap 后的行为解析-附带一个有关Delay ACK和超时重传的优化 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dianzi/1727167687a1099979.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。