13 | 重传的再认识：没有任何丢包却也一直重传？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文通过实际案例介绍了eBay的HTTP请求慢的问题排查过程，从应用层分析到抓包排查，最终发现了LB和网络层面的问题。通过Wireshark抓包分析，发现了规律性的DupAck和重传现象，揭示了重传背后的未知机制。文章深入探讨了TCP重传现象，帮助读者更深刻理解TCP的基本设计，特别是重传部分，为读者在工作中遇到TCP问题提供了更准确的判断和解决思路。文章内容详实，逻辑清晰，对网络排查和TCP重传问题有很好的指导意义。文章还介绍了TCP协议的规范和对排查过程的启发，提出了对排查期间发现的规律性现象的重点关注，以及对于“超时、处理慢”这类问题的排查思路。文章总结了一个比较罕见的案例，对读者有很好的指导意义。
《网络排查案例课》，新⼈⾸单¥59
全部留言(12)
- 最新
- 精选
MeowTvづ这一讲的例子也说明，两端没有开启SACK技术：）作者回复: 哈哈，确实如此~
2022-02-1846
那时刻根据rfc793文档，for ESTABLISHED STATE，If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. 在链接状态的时候，如果收到ack number小于未被ack的number，这个ack包会被忽略。我粗略看了下文档，其它状态下，貌似没有说明，不知是否有遗漏。 老师提到通过扩大 TCP receive buffer size，使得缓冲区足够大，做到了对 Bug 的规避。请问是把net.ipv4.tcp_rmem扩大到多少呢？作者回复: 是的，就是这段，你找的很对。另外调整接受缓冲区，对这个设备来说是配置一个profile，跟linux还是不同的，设备的tcp是自己维护的并不是内核，所以方式也不同。如果是linux，就是你说的配置了～
2022-02-1832
taochao_zs1 根据滑动窗口定义：左边界不会左移只会右移（推进），收到左边已确认的重复确认包会直接丢弃。 2 老师说的问题还没碰到过，以后碰到再补上；）作者回复: 正确，这个ack报文会被忽略 以后遇到类似问题心里有底了：）
2022-02-182
Realm1 直接丢掉，服务端说，别把我当傻子，我这里记着呢；2 没有遇到，感谢老师的“惊艳”分享，很奇葩，这种分组好的，重新拆开，又组装成新的分组，对性能影响巨大.作者回复: 正确！：） 可以参考内核的这几行代码对老旧ack的处理，很直白： /* If the ack is older than previous acks * then we can probably ignore it. */ if (before(ack, prior_snd_una)) goto old_ack;
2022-02-181- Geek_糖厉子在吗老师能发我一点数据包案例吗？我这需要素材
作者回复: 大部分案例都有示例文件，比如本节的文件在这里：https://gitee.com/steelvictor/network-analysis/tree/master/13
2023-03-21归属地：上海 - Geek_413acb老师，这个例子很精彩。有两个问题，麻烦看一下： 1. 为啥有这么多的dup ack呢？不是收到data才会ack吗？但是tcpdump后面并没有看见几个发给lb的数据报啊？ 2. 另外为啥最后lb突然ack了101525，而不是每个包都要求拆成2半重传呢？
作者回复: 您好，关于这两个问题： 1. lb回复的很多个DupAck是那个“错位”位置后面的客户端发给LB的报文触发的，因为当时LB的接收窗口比较大，所以客户端连续发送很多数据，只是在大约30KB左右的地方发生了“错位”，于是后面30KB就变成了触发许多个DupAck的原因 2. 这个问题本质上是LB的bug，在示例文件中用tcp.stream eq 0 and not tcp.srcport eq 80过滤出报文，可以看到最后一次“错位”是在37961，之后LB恢复了正常，而由于大部分报文其实也已经到达LB，所以最终LB“突然ack了101525”。看起来略显突兀，不过也是可以解释的~
2022-05-17 
青鸟飞鱼老师是个健身达人啊作者回复: 还行，准备一直健康工作下去：）
2022-04-19
山丘tcp的学习接近尾声了，把之前困扰多年的tpc层概念 MSS，MTU，窗口，拥塞，dupAck，重传，快速重传这些之前打开wireshark抓瞎的东西都搞清楚，对wireshark的了解和使用能力也大大提高了，非常感谢杨老师的课程，真是受益匪浅。 另外这一讲还有个问题没搞懂，请杨老师指教： LB对于发送过来的1460个字节只ack了512个字节，杨老师说 剩余的948字节需要和下一个包的前 512 字节，组合在一起，变成一个新的 1460 字节的包，再发送给客户端。但在抓包文件里并没有看到报文的nextSeq为27741+1460 = 29201的报文，看这个抓包文件里好像并没有重新组装报文？或者说在这个抓包文件里哪个报文是重新组装后的报文呢？作者回复: 感谢你的支持，而且你也真的认真去实践了，怪不得能把之前模糊的概念都清楚了，这门课程的核心思想就是“实践出真知”：） 关于你提的nextSeq问题，你可以去找的是27741+948=29689，这个在抓包文件里就有~
2022-03-022- Geek_93970d增大接受缓冲区为何能规避这个 BUG？接受缓存能放更多东西，但是，没开 SACK 的话，客户端会将乱序开始之后的数据都重发一遍，客户端依然需要拆包重组呀2023-04-02归属地：北京1
原则老师我看抓包文件里面并不都是标准的 70 个 Dup ACK，这个只是一个大概吧？ 另外，为什么会有这么多的 Dup ACK，看起来也没有这么多的数据报文发过来呀？2023-06-07归属地：广东
