24 | 丢包：如何确定丢包的存在及其程度？
该思维导图由 AI 生成，仅供参考
路径排查工具概览
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了网络排查中丢包问题的挑战及解决方法。首先介绍了路径排查工具的概览，包括探测类工具如ping、traceroute、mtr等，以及统计类工具如netstat、ss和nstat等。重点介绍了traceroute和mtr工具的工作原理和优势，以及如何利用它们定位丢包点。文章通过详细介绍各种工具的特点和使用方法，为读者提供了深入了解网络排查和解决丢包问题的指导。 文章还探讨了中间节点丢包率的解读方法，以及快速探测PMTU的技巧。此外，还介绍了如何统计丢包率，包括使用ping和抓包文件分析等方法。通过本文的学习，读者可以掌握多种工具的使用方法，了解丢包问题的解读和快速探测技巧，从而更好地应对网络排查中的丢包问题。 在文章的后半部分，还介绍了丢包率的评估标准，以及对丢包率高低的分析和应对策略。此外，还提到了TCP在发生丢包情况下如何保证传输可靠性的问题。最后，通过思考题引发读者对文章内容的深入思考和讨论。 总的来说，本文通过介绍各种工具的原理和使用方法，以及对丢包问题的分析和评估，为读者提供了全面的网络排查和解决丢包问题的指导，对于需要解决网络丢包问题的技术人员具有很高的参考价值。
《网络排查案例课》，新⼈⾸单¥59
全部留言(10)
- 最新
- 精选
那时刻网卡dropped 指标表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。而我们讨论的丢包是传输过程中，数据包在网络中丢失了，经过交换机转发过程中丢包，或者传输介质的原因丢失数据。 TCP 是如何在发生丢包的情况下保证传输可靠性的呢？ 1. 通过序列号和确认应答信号确保了数据不会重复发送和重复接收。 2. 同时通过超时重发控制保证即使数据包在传输过程中丢失，也能重发保持数据完整。 3. 通过三次握手，四次挥手建立和关闭连接的连接管理保证了端对端的通信可靠性。 4. TCP还使用了滑动窗口控制提高了数据传输效率作者回复: 你说的没错，网卡的dropped是“有意识或者有感知”的丢包，而网络路径丢包是还没到达接收端的网卡，所以是"无感知“的，因为丢包环节不会对这个时间发送一个通知出来。 这类似一个逻辑命题：你不知道你不知道的事情。网卡也不知道路径上的丢包。
2022-03-287
JianXu出了事故以后，再来补课-：）作者回复: 对我来说是又一个素材了：）
2022-07-232- 老万traceroute 应该是使用目的端口为33434以上的高端口
作者回复: 恩这里有个笔误，感谢指出，我们更正一下～
2022-04-292 
Chaotcp发生丢包 最大措施就是降速，通过降速来保证传输。作者回复: 差不多，这就是TCP的重传和拥塞控制等机制的价值所在：）
2022-03-282
家军老师请教一个问题：业务压测时，通过netstat -s监控发现：tcp重传较多(千分之2.5）其中快速重传占了99%以上，丢包重传较低（万分之0.25），造成这种情况的原因是什么？这种程度的重传需要关注吗？作者回复: 我觉得这种程度的重传是可以接受的，因为内网一般也有约万分之一上下的丢包率，你这里是万分之0.25，其实你的内网质量已经很好了。 快速重传一般是报文在网络路径上或者在接收端出现了乱序，引发接收端回复DupAck，于是触发发送端快速重传。 至于“千分之2.5”这个重传率算不算高呢？需要综合各种因素来看，比如服务端的网络报文处理能力如何？压测时候的包量(pps, packet per second)达到多少？ 可以在服务端运行sar -n DEV 1命令查看包量pps。根据主机配置的不同，包量上限也不同。在到达包量上限前，可能出现报文接收变慢、乱序增加等现象；到达包量上限后，丢包率会急剧上升，此时压测也到达了网络能力瓶颈（另外一个瓶颈是应用层瓶颈）。
2023-04-21归属地：北京2
青梅煮酒对比了tshark和wireshark的丢包计算结果，是所有的重传相加来计算丢包率的作者回复: 确实如此：）
2022-05-26- 青梅煮酒如果存在超时重传和快速重传是不是需要全部相加才可以计算丢包率呢
作者回复: 这里说的重传就包括了超时重传和快速重传。在Wireshark的expert information里，分别是retransmission和fast retransimission，两者之和就是重传包的数量~
2022-05-26 
RealmPacket Dropped seen from ifconfig could be due to many reasons, you should dig deeper into NIC statistics to figure out real reason. Below are some general reasons * NIC ring buffers getting full and unable to cope-up with incoming bursts of traffic * CPU receiving NIC interrupts is very busy and unable to process * some cable/hardware/duplex issues * some bug in NIC driver Packet Dropped seen from ifconfig could be due to many reasons, you should dig deeper into NIC statistics to figure out real reason. Below are some general reasons * NIC ring buffers getting full and unable to cope-up with incoming bursts of traffic * CPU receiving NIC interrupts is very busy and unable to process * some cable/hardware/duplex issues * some bug in NIC driver 1 我们讨论的丢包是站在客户端的角度，多指网络传输层面； ifconfig中dropped，是站着服务器的角度，包进入了网卡，由于各种原因没有被处理，被统计为丢弃了，两者应该不是一回事。 2 tcp通过重传、拥塞控制等机制保障可用性；作者回复: 都正确：） 网卡设备的dropped不同于路径中的丢包，这里的dropped是你说的各种NIC硬件相关的问题以及ring buffer等原因导致的“自己感知到的”丢包。 而路径上的丢包是网卡无法“感知”的，但是从TCP控制层面（序列号）是可以发现的，所以路径丢包是一个被“推理”出来的结论。 而ICMP echo报文能发现丢包也是利用了自己的报文序号（从1开始），这个方式也类似TCP序列号，同样可以发现丢包现象。 traceroute/mtr如果选中UDP模式，就是通过UDP端口号单调递增，也一样可以做到这一点。 融会贯通来理解网络会更好：）
2022-03-28
追风筝的人探测类工具：ping、mtr、traceroute、nc、telnet 等。 统计类工具：netstat、ss、nstat。2022-03-301
上杉夏香文章随机二刷： 一、为什么会发生丢包的情况 数据到达目的地的情况 1、到达目的地，只是不予受理。比如traceroute 采用ICMP、UDP探测，一般有一种方式在最后总是会丢包，变现为一直输出『* * * * 』 数据未到达目的地的情况 1、路径上MTU的限制+IP报文的不分段的联合机制 如何发现路径上最小的MTU： ping -s <icmp 报文的载荷大小> <目的IP>，不断试探。哦，没错，在这里你可以搞一个二分查找。 2、网络状态不好 路径上某台路由器达到最大的转发能力等等 二、如何检测到丢包？ 统计类工具，比如netstat、ss等工具。因为是静态的，你可以动起来~ ```shell watch --diff netstat -s ``` 三、在哪里丢包？ traceroute、mtr上场 四、丢包率是多少？ wireshark抓包，从专家信息中查看丢包的数量，然后获得整个过程的抓包总量。丢包率 = 丢包量/抓包总量2022-08-12归属地：北京
