网络排查案例课
杨胜辉
eBay 资深运维专家,流量系统负责人
22781 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
实战三:不用抓包就能做的网络排查篇 (2讲)
网络排查案例课
15
15
1.0x
00:00/00:00
登录|注册

12 | 重传的认识:重传到底是怎么回事?

TCP头部长度限制,SACK最多放置4个块
避免已到达的数据被重传
服务端根据DupAck快速重传丢失的报文
服务端发送数据报文后,客户端回复DupAck
连接关闭
连续重传、DupAck和Spurious重传
TLS握手
TCP握手
个人遇到的重传问题及处理方式
TCP确认报文丢失的情况下的重传行为
TSO (TCP Segmentation Offload) 的存在可能影响DupAck数量
专家信息里的提示和报文类型识别
定位到被重传的原始报文的方法
结合抓包发生的一侧来解读信息
SACK需要TCP扩展属性SACK permitted的支持
避免不必要的数据重传
SACK (Selective Acknowledgement) 提供更详细的确认信息
通常不是问题,不需特别处理
Wireshark识别到已确认的报文再次发送
SACK (选择性确认) 与快速重传
快速重传案例分析
触发条件是收到3个或以上的重复确认报文 (DupAck)
超时重传案例分析
实际场景中,RTO为200ms出头最为常见
RTO有上限值和下限值,常见值分别为2分钟和200ms
RTO的初始值是1秒,在连接建立后会动态计算
重传超时 (RTO) 是基于计时器的
发送方在一定时间内未收到确认会触发重传
思考题
Wireshark使用技巧
SACK与重传的关系
Spurious重传 (Spurious Retransmission)
快速重传 (Fast Retransmission)
超时重传 (Timeout Retransmission)
TCP重传机制

该思维导图由 AI 生成,仅供参考

你好,我是胜辉。
在前面的第 8 讲第 9 讲,我们先后介绍了两个 TCP 传输方面的案例。在刚过去的第 11 讲,我们更是全面了解了 TCP 的拥塞控制机制。其中有一个词经常被提到,就是“重传”。
在我看来,TCP 最核心的价值,如果说只有一个的话,那就是对可靠传输的保证而要实现可靠的传输,可能需要这样做:如果我的报文丢了,应该在一定次数内持续尝试,直到传输完成;而如果这些重传都失败了,那就及时放弃传输,避免陷入死循环。
所以,为了应对不同的情况,TCP 又发展出了两种不同的重传类型:超时重传快速重传。它们在各自的场景下都有不可替代的作用。不过,它们本身也只是外在的表现,触发它们的条件又分别是什么呢?
另外,你可能在 Wireshark 里也见过 Spurious retransmission,这个又是什么意思,会对传输有什么影响吗?
这节课,我就通过对几个案例中的抓包文件的解读,带你学习这些重传家族的成员,了解它们的性格脾气,以后你在日常网络排查中看到重传,也就能顺利搞定了。

超时重传

我们先来学习下超时重传,Timeout Retransmission。在 TCP 传输中,以下两种情况,都可能会导致发送方收不到确认:
报文在发送途中丢失,没有到达接收方,那接收方也不会回复确认包。
报文到达接收方,接收方也回复了确认,但确认包在途中丢失。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

TCP的重传机制对于确保可靠传输至关重要。本文介绍了超时重传和快速重传两种重传类型,并通过案例分析了它们在网络中的应用。超时重传是在发送方未收到确认时重新发送报文,而快速重传则是在对端回复连续3个重复确认时触发。文章还讨论了重传超时的动态计算和调整。通过抓包分析,文章展示了快速重传和超时重传的具体情况,以及与之相关的专家信息和重传报文的解读。特别是针对快速重传的情况,文章详细解释了快速重传报文的产生原因,以及出现大量重复确认的背后原因。此外,文章还提到了TSO(TCP Segmentation Offload)对重传报文数量的影响。总的来说,重传机制是TCP保证可靠传输的重要手段,了解重传类型和相关参数对网络排查和优化至关重要。文章还介绍了SACK(Selective Acknowledgment)对重传的影响,以及SACK在TCP中的作用。文章通过案例分析和Wireshark技巧的介绍,帮助读者更好地理解TCP重传机制的实际应用和排查方法。总的来说,本文通过深入的技术讲解和实例分析,使读者对TCP重传机制有了更全面的了解,为网络排查和优化提供了有益的参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《网络排查案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 江山如画
    问题1: 分情况讨论。 1. 如果是三次握手时,第二个握手报文SYN+ACK 丢失,在经过一个 RTO 时间后,由于还没收到第三个握手报文,发生超时重传,会重传这个报文。(这种情况是我猜的,没有实际验证) 2. 如果发送端先后发送了报文n,n+1,接收端也先后确认了这两个报文,如果ACK[n] 传输时丢失,ACK[n+1] 正常传输,由于后者的确认范围涵盖了前者,那么即使 ACK[n] 丢失也不会有什么影响,则不会重传 ACK[n]。 3. 如果在情况2中,第 n+1 个报文是当前数据流的最后一个报文,且 ACK[n+1] 传输时丢失了,发送端经过1个RTO时间后会触发超时重传,接收端在接收到报文后会重传 ACK[n+1]。

    作者回复: 非常好,而且全面,这些理解都是正确的,感觉你进步明显:)也请继续加油~

    2022-02-17
    3
    11
  • MeowTvづ
    由于Option字段最大为40字节,所以SACK中只能装4组边界信息,SACK选项的最大占用字节数=4*8+2 = 34。

    作者回复: 赞:)其中的2字节是kind和length的各一个字节~

    2022-02-16
    8
  • 我来也
    思考题一:TCP 的确认报文如果丢失了,发送端还会不会重传呢?为什么? 我觉得要看实际情况。 1. 比如后续收到了更新的 ACK 报文,说明前面的内容都接收到了。发送端自然不会再重传前面的内容。 2. 如果说后续没有 ACK 报文了,触发了发送端的 超时重传,这个时候就会重传了。

    作者回复: 是的,ack本身没有ack了,否则就是无限循环了。根据不同的场景,对端会启动超时重传或者快速重传,这样就还是能保证传输。要保障传输可靠性,这就是是tcp如此复杂和精妙的原因。

    2022-02-16
    4
  • taochao_zs
    1 不会,ack是没有ack确认报文,所有没有重传的意义。2 重传的本质是:网络/应用/操作系统不稳定导致处理不及时,网络层避免重传应该重点关注网络流量工程的规划和建设,应用层和操作系统层关注重试机制的应对保证不稳定状态下业务稳定性。

    作者回复: 说的很好:)网络要做好质量可靠性,应用也需要做到比较好的容错性,两者合作,这样就最大程度的保证系统可靠性了。

    2022-02-16
    2
  • 志强
    老师您好 我的环境rx 几秒钟就会dropped值加一,但要是在环境上tcpdump抓包,rx的dropped就不变了,取消抓包,又几秒钟开始出现dropped值加一,请问老师这可能是什么原因 环境是微服务三台部署,没有任何业务

    作者回复: 有意思的问题:)你tcpdump时候有没有启用混杂模式(promiscuous mode)?可能drop的是广播包(目标MAC是全1),而启用混杂模式会收下这种报文。

    2022-02-23
    4
    1
  • xuty
    您好,请问下一般如何定位重传的网络设备区间呢?

    作者回复: 可以参考第24讲的“用 mtr 定位丢包点”部分的内容。双向跑mtr可以定位到一个相对准确的区间,当然如果你有网络设备权限或者网络组支持,帮忙一起看是更好啦!

    2023-09-11归属地:江苏
  • 不忘初心
    老师,对于重传有些疑问。 1. 如果发送端网络报文因为延迟多次重发后,因为接收端已经收到过该报文, 是不是直接就将该报文丢弃了。并且回复SACK吗? 2. 如果SACK机制没有打开, 会怎么样? 会回复什么呢?

    作者回复: 1. 开启SACK的情况下,就是你说的 2. 没开启SACK的情况,假设接收端收到了1~1000字节的数据,而第1000~1500未收到;发送端持续重传2000~2500这些数据,那么接收端还是只ACK 1000,当然更没有SACK

    2022-11-15归属地:上海
  • Realm
    快速重传如何触发?没有SACK的情况下,32号报文从服务端发出,在网络上丢了,后面服务端又发了34,36,38...,客户端在收到这些报文时,根据seq-len一看,发现我压根没有收到序列号是seq-len的32号报文,就一直回DupAck要32号报文,就触发快速重传了,老师,是不是这样理解?

    作者回复: 应该说是34 36这些报文的序列号,跟前面30(也就是32之前的报文)的nextseq连不上了,按tcp的规定,tcp头部的确认号必须是连续字节,如果“跳空”了,就只能ack最近的连续字节位置。每次收到这种“跳空”的报文,确认报文还是要回复的,只是确认号会重复,你看看这样说可以清楚一点吗

    2022-02-17
    2
  • Realm
    “我直接给你揭晓答案:就是因为从 32 号报文之后,服务端还继续发送了 14 个数据报文,远不止 3 个,所以触发的 DupAck 也远不止是 3 个。你可以直接看下图来理解这里的逻辑” ,老师,这个下面的图,是不是34、36、38触发重传更准确一点,35好像是反方向的数据包.

    作者回复: 恩是34 36 38:)

    2022-02-17
  • ERROR404
    1.不会,接收端可以根据通过ACK来告诉发送端收到的收到的重复数据,每次服务端发送最新ACK号即可,即D-SACK。 2.重传还是看影响不影响到业务,实际是允许重传存在的。像互联网线路丢包或者营销等引起流量突升的重传。

    作者回复: 嗯回答挺好的:)这里面的DSACK我没有在课程中提及,但确实是一个知识点,有时候工作中也会遇到。DSACK的作用向对端表示“我重复收到了某些报文”,这样对端可以相应的做传输优化,比如拥塞控制行为的调整。 重传是TCP应对网络网络的行为,本质上不能算是“根因”,而是一种外化表现,有时候重传是正常的,有时候表示真的有问题,然后就需要针对这些重传的具体情况来分析应对了~

    2022-02-16
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部