24 丢包：如何确定丢包的存在及其程度？
你好，我是胜辉。
在上一讲里，我们回顾了一个网络路径排查的典型案例。我们是通过 nc工具发起不同源端口的连接，从而定位了ECMP路径中的问题。这个排查方法的背后，其实是我们对三层网络的深入理解和灵活应对。在这一类的网络排查中，我们都未必要上抓包分析这样的“重型武器”，只要场景合适，我们就可以用小工具达到大效果。
现在我们也知道了，这个案例的根因是ECMP路径中某个节点存在丢包。而丢包，也是网络排查中特别普遍的现象，特别是下面这三个问题：
- 有没有丢包？
- 在哪里丢包？
- 丢包程度多严重？
这三个问题的组合，就使得很多故障场景变得复杂。特别是当丢包情况不太明显的时候，问题表象就变得更加“神出鬼没”了。
所以在这一讲里，我们将会对“丢包”这个十分典型的问题场景进行一次深入的探讨。这样，下次你遇到丢包等问题的时候，就有很多种“兵器”，也知道在什么场景下使用它们，从而真正突破“丢包”这个难点了。
那么首先，在讨论丢包之前，我们要先对网络排查工具做一下总体的审视。
路径排查工具概览
网络路径排查的工具有挺多，大体上可以分为两大类：探测类工具和统计类工具。
为什么要这么分呢？在我看来，网络信息的获取方式，大体上有动态和静态之分：
- 动态的信息在传输过程中体现，传输结束后就没有了。它获得的是通信两端在动态变化中的网络状况，所以我们需要做实时的探测，才能把这个动态的状态抓取下来。
- 静态的信息在传输结束后依然存在，继续保存在通信端的系统中。它是通信端的网络信息的历史统计。我们只要通过运行统计类工具，就能把这种累计的信息读取出来了。
所以下面，我们就先来看看这两类工具具体都包括了什么。
探测类工具
探测类工具主要包括ping、traceroute、mtr、nc、telnet等，它们都是从一端发起，对另外一端发送探测报文，然后观测报文的丢失、乱序、时延等情况。
其中，ping、traceroute、mtr主要是利用ICMP或者UDP的特性，实现了对网络路径状况的检测。在接下来的课程中，我们会深入探讨traceroute和mtr的工作原理。
而nc和telnet，则主要是测试传输层连通性的，比较典型的场景就是探测TCP握手能否成功。有了这两个工具，我们不需要做tcpdump抓包，就可以检测出TCP端口是否可以连通了。
统计类工具
统计类工具包括netstat、ss，这些工具都是在一端读取自己的历史统计值，而并不发送出探测报文。比如，我们可以通过netstat -s命令，看到很详细的传输层、网络层、数据链路层等的质量状况，包括报文丢失、重传、重置（RST）等情况的统计。比如下面这样：
# netstat -s
Ip:
Forwarding: 1
41406 total packets received
0 forwarded
0 incoming packets discarded
41406 incoming packets delivered
30976 requests sent out
Icmp:
16 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
echo replies: 16
16 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
echo requests: 16
IcmpMsg:
InType0: 16
OutType8: 16
Tcp:
18 active connection openings
0 passive connection openings
0 failed connection attempts
1 connection resets received
2 connections established
41353 segments received
30924 segments sent out
0 segments retransmitted
0 bad segments received
0 resets sent
Udp:
37 packets received
0 packets to unknown port received
0 packet receive errors
37 packets sent
0 receive buffer errors
0 send buffer errors
......
其中，跟丢包直接相关的是 segments retransmitted 这个指标，如果它一直在增长，那一般意味着网络上存在丢包，我们需要多加注意了。
当然，netstat命令是相对传统的命令，属于早已停止维护的net-tools工具集。新的工具集是iproute2，其中包括了ip、ss、nstat等命令。这些命令也可以读取到类似的网络统计信息。
不过，既然新老命令的功能类似，那为什么我们还要重复造这个轮子呢？
这其实是因为，netstat主要是通过/proc文件系统收集信息的，而ss主要通过netlink内核接口获取数据（有些信息也依然要从/proc中读取），这个netlink接口的效率要比/proc接口更高，所以ss能更快地返回数据。
另外，ss能获得的信息要比netstat更丰富。比如，ss就可以获取到socket option的信息，但netstat就做不到。
我们可以看一个例子。我在自己的Ubuntu容器里运行了这条命令：
就可以获取到很多netstat无法获取的信息：
我们可以挑几个信息展开一下。
cubic：这条TCP连接用的拥塞控制算法是cubic。wscale:2,7：这条TCP连接的两端的Window Scale分别是2和7。cwnd:10：这条TCP连接的拥塞窗口为10个MSS。
如果你感到好奇：“ss是如何获取到这么多有用的信息的呢？”其实这个也不难。一个简单的办法就是使用第21讲我们介绍的strace，然后就能观察到ss -eit拿到这些信息的具体过程了。
其实，类似这样的细微的探究过程，都能不经意间不断深化我们的技术能力。
nstat工具
我们还可以了解一下nstat这个工具。它跟ss一样，也是iproute2工具包里面的。nstat的一个特点是，如果不加参数，它每次运行时输出的数值，是从上一次被执行以来这些计数器的变化值。这就带来了一个挺明显的优势：我们不用像使用netstat那样，在两次输出值中找出变化量了，nstat输出的直接就是变化量。
首次运行nstat时，输出的就是全部计数器的值。第二次运行时，就只是发生变化的数值了，比如下面的nstat输出的就是变化的值：
root@08d984197cfb:/# nstat
#kernel
IpInReceives 5 0.0
IpInDelivers 5 0.0
IpOutRequests 4 0.0
TcpEstabResets 1 0.0
TcpInSegs 5 0.0
TcpOutSegs 4 0.0
TcpOutRsts 3 0.0
IpExtInOctets 336 0.0
IpExtOutOctets 160 0.0
IpExtInNoECTPkts 5 0.0
当然，要查看全部值也是可以的，执行这条命令即可：
nstat还有个功能是按JSON格式做输出，这有助于我们做自动化运维。做法是nstat命令加上--json参数：
而既然netstat和ss都能读取到计数器的值，那么这些计数器本身又是如何产生的呢？
内核的SNMP计数器
这些计数器的统计和更新其实都是Linux内核的行为。内核根据RFC1213的标准，定义了IP、ICMP、TCP、UDP等协议相关的SNMP计数器。在每次报文发送、接收、重传等行为发生时，都会往相应的计数器中更新数值。具体来说，这些计数器的定义在内核代码的include/linux/snmp.h文件中。
补充：SNMP名义上是“简单网络管理协议”，其实名字叫“简单”的技术往往并不简单。事实上SNMP还是很庞大的，这里就不展开了。
所以说，这些数值都不是netstat、nstat这些命令去“生成”的，而是内核早就准备好这些数据了，工具去完成读取就好了。
好了，讨论完各种工具，接下来我们就进入丢包这个核心话题。
如何确定丢包位置和丢包率？
在丢包这个问题上，我们最关心的可能就是丢包在哪里、丢包率是多少这两个问题。这里我们重点使用的工具，是traceroute和mtr。
traceroute和mtr的工作原理
我们先说traceroute。其实在第1讲，我就提到过traceroute的两种模式：UDP模式和ICMP模式。但是，traceroute为什么可以做到探测网络路径中的节点的呢？要知道，ping也是用ICMP，它咋就看不到中间节点呢？
你可以找一个工程师问这个问题：“traceroute是如何显示每一个节点的？”很多人可能都会卡住，或者会给一个似是而非的答案，比如说：“可能是有什么协议吧，可以展示每一个节点的”。
所以我们不要小看一些表面上不起眼的小技术点，也许里面藏着的，还正是你的盲区，也是我们可以提高的地方。
实际上，traceroute的工作原理，是巧妙地利用了IP报文的 TTL属性。具体过程是这样的：
- 发送端首次探测时把UDP源端口为33434，TTL设置为1。这个报文经过第一个路由器时TTL会被减1，也就是变为0，因此包被丢弃，这个路由器向源地址发回一个ICMP超时通知（ICMP Time Exceeded Message），于是第一跳就被探测出来了。
- 发送端把下一次发送的包的UDP源端口也加一，变为33435，TTL也在原来的基础加一，变为2，这样就可以多前进一步。跟上面的步骤类似，第二跳也被探测出来了。
- 发送端一直重复TTL加一和UDP源端口加一的操作，直到报文最终到达目的地，后者回复一个端口不可达的ICMP错误信息（ICMP Port Unreachable）。当源地址收到这个消息时，就停止traceroute。
补充：实际工作中，traceroute会批量发送多个不同TTL值的报文然后等待回应，这样效率更高。
当然，在探测过程中，任何一个探测报文如果在限定时间内没有收到，traceroute就会认为超时，在输出中这一跳就显示为一个星号。
另外，目的地也可能不回复ICMP Port unreachable，那么traceroute的输出就会出现从某一个位置开始的后续跳数全部是星号，直到你按Ctrl + C终止探测，或者是直到默认的64跳检测全部完成。对于这种情况，你可以加上-I参数，让traceroute用ICMP协议的echo request消息进行探测，一般来说，目的地总能对UDP和ICMP中的一种进行响应。
我们看一下原理示意图：
Linux的traceroute命令默认用的就是UDP模式，而Windows的tracert默认用了ICMP模式。有时候我们会看到每一跳有2个或者3个节点IP，其实就表明这几个路径是启用了ECMP的，所以有多个节点会被选到。比如下面这个例子：
$ traceroute www.ebay.com
traceroute to e9428.a.akamaiedge.net (23.45.61.92), 64 hops max
1 10.0.2.2 0.308ms 0.192ms 0.353ms
2 192.168.1.1 4.284ms 1.379ms 1.360ms
3 100.65.0.1 5.916ms 5.464ms 5.520ms
4 61.152.53.149 148.051ms 146.005ms 4.126ms
5 61.152.25.2 16.216ms 61.152.25.101 14.618ms 144.713ms
6 * 202.97.83.13 8.385ms *
7 202.97.12.186 5.112ms 13.341ms 14.592ms
8 202.97.41.142 49.747ms 54.797ms 202.97.41.130 58.370ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
当你改成用ICMP模式后，每一跳就变成只有一个IP了。原因我们在上一讲讨论过，就是因为五元组是一致的，所以路径也不变。比如我们还是对www.ebay.com进行探测，这次用ICMP模式，每跳就只有一个IP了，而且目的地也返回了有效的响应。
$ traceroute -I www.ebay.com
traceroute to e9428.a.akamaiedge.net (23.45.61.92), 64 hops max
1 10.0.2.2 0.003ms 0.002ms 0.003ms
2 192.168.1.1 7.616ms 1.315ms 6.206ms
3 * 100.65.0.1 11.057ms 7.746ms
4 * 61.152.53.149 18.436ms 9.598ms
5 * 61.152.25.158 12.918ms *
6 * * *
7 * * *
8 202.97.41.142 50.746ms 58.052ms 59.546ms
9 203.215.237.22 62.385ms 66.607ms 54.561ms
10 23.45.61.92 49.609ms 46.586ms 45.567ms
用mtr定位丢包点
在上一讲的案例中，我们是用nc加上-p参数指定多个源端口来测试，定位到了问题路径的存在。这对于问题节点丢包率比较高时，作用比较明显。
但是，当问题节点的丢包率不高的时候，我们用nc做多次测试，未必正巧能抓到现场。我们最好还要有持续监控的手段，运行一段时间或者发送一定数量（比如1000次以上）的报文，通过足够的探测数，来抓到偶发的故障现象。
这里呢，我们就要用到预习篇提到过的工具：mtr。mtr相当于traceroute的加强版，特别是它可以指定任意次数的探测并生成详细的探测报告，而traceroute只能对每个节点发起3次探测，数据量就不够了。
你也可以理解为mtr = traceroute + ping，因为ping也可以发送很多次，也有最终的报告。
比如，我们用下面这条命令，就可以对目标IP完成指定次数的探测并生成详细的报告，报告里包含了每一跳的丢包率，很有帮助。
$ mtr -c 10 -r 8.8.8.8
Start: 2022-03-27T00:44:36+0000
HOST: victorebpf Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 0.2 0.3 0.2 0.5 0.1
2.|-- 192.168.1.1 0.0% 10 1.9 14.9 1.6 119.8 37.0
3.|-- 100.65.0.1 0.0% 10 11.9 27.8 6.6 157.0 46.6
4.|-- 61.152.53.149 20.0% 10 4.3 29.9 3.2 128.5 45.4
5.|-- 61.152.24.226 20.0% 10 4.0 10.1 3.9 44.2 13.8
6.|-- 202.97.94.237 10.0% 10 28.1 41.8 22.2 157.4 43.5
7.|-- 202.97.12.182 60.0% 10 4.9 27.9 4.9 57.5 25.7
8.|-- 202.97.93.158 10.0% 10 89.4 111.8 80.8 217.6 55.0
9.|-- 72.14.211.144 20.0% 10 79.7 107.9 79.6 231.9 51.6
10.|-- 108.170.240.225 10.0% 10 89.8 91.5 81.0 148.2 21.5
11.|-- 74.125.251.207 0.0% 10 87.7 95.4 81.0 193.3 34.5
12.|-- dns.google 10.0% 10 81.0 106.2 80.1 286.9 67.9
可见，终点处的丢包率为10.0%。不过，你也可能注意到了：为什么中间有好几个节点的丢包达到了20.0%甚至60.0%，但终点丢包率反而更低？这是怎么回事？
为何中间节点丢包率更高？
首先，终点的丢包率（在这里是10.0%）肯定是正确的，因为这就是ICMP报文到达终点后的情况。按常规的理解，中间节点的丢包率应该比终点的丢包率低或者持平，但第4跳的20.0%和第7跳的60.0%，都比终点丢包率更高，这就令人费解了。另外，Last等列的响应耗时指标，也出现了中间节点和终点倒挂的情况。
其实，这个问题需要我们结合两个知识点来理解：
- mtr探测路径节点的工作机制；
- 网络设备回复ICMP报文的工作机制。
第一个知识点，mtr跟traceroute一样，也是通过递增TTL的方式，使得ICMP或者UDP报文终止在中间节点，从而获取到这些节点回复的ICMP time exceeded消息。也正是通过这个消息，我们知道了这个节点的IP、时延，以及我们关心的丢包率。
第二个知识点，是网络设备在回复ICMP报文时候的工作机制。其实，网络设备（交换机和路由器）在“转发”和 “回复”这两个任务上的工作机制是不同的：
- 对于“转发”，大部分工作是卸载到数据面的硬件芯片完成的，这也是实现高速转发的底层基础。
- 对于“回复”，因为需要自己生成一个ICMP响应报文，那就需要动用自己的CPU资源了，速度就会慢一些。
我们可以通过下面这个图来理解这个知识点：
另外还有一些原因会导致这个现象，比如，不少网络设备对自己的ICMP响应报文设置了限速（rate limit），这也会加剧这种中间节点丢包的情况。
如何解读中间节点的丢包率？
那么，这个中间节点的丢包率是不是就毫无价值了呢？我们再看另外一个例子：
我们从这里可以解读出很多的信息，包括：
- 从第5跳开始到最后一跳都有丢包。其中的第8跳到最后一跳的丢包率接近（都在20%左右），那么这几跳需要重点关注。
- 从第9到第11跳的节点名称解析来看，这些是日本东京（tokyjp）的路由节点，运营商是NTT。
- 第11跳的名称里带fastly，这是一个CDN厂商的名称，所以这是fastly CDN的节点。
- Last这一列是最近一次响应耗时，第7和第8跳的耗时突增了70ms。我们知道，时延跟地理距离成正比，而70ms是一个比较长的耗时了，所以我们可以判断，这两跳就是中日之间的海底光缆的两端。
根据这些信息，我们大致可以认为，丢包（本质是链路拥塞）主要发生在中日海底光缆这个位置。
当然，这是一个粗略的推断。一般来说，mtr最好在两端都做，然后结合两边的mtr的报告来综合分析，结论会更加准确。
为什么要在两端都做呢？这是因为，网络路由一般是“不对称的”，也就是发送是一条路径，回来往往是另外一条路径了。那么从一端发起mtr，只能看到这个方向的网络状况，另外一个方向的网络状况，就需要另外一端运行mtr来获取了。
比如我们借用一下上一讲的示意图。假设蓝色路径是起点到终点的路径，而紫色的是返回的路径，那么两条路径在r1，r3，r14这节点上是重合的，而在其他节点上“各走各的”。
你看，这跟我们抓包经常要在两端同时抓，背后的逻辑是不是差不多的？大道相通，我们积累得越多，越有可能打通这些知识之间的，达成更深的掌握。
丢包与MTU
在第8讲里，我们学习了MTU相关的概念。MTU是最大传输单元，而PMTU就是路径上的瓶颈MTU（最小MTU）。一旦报文设置了DF=1并超出PMTU的大小，就会被丢弃。特别是对于相对较大尺寸的TCP报文（比如超过1400字节）总是传输失败的情况，可以优先排查PMTU。
那么，我们有什么方法可以很方便地就找到PMTU呢？
快速探测PMTU的方法
其实，我们可以用一个十分简单的命令：ping。给 ping命令加上“-s 尺寸”这个参数，就可以发送自定义载荷尺寸的报文。比如你可以试试这个命令：
然后再运行：
看看两者的返回有没有区别？
ping报文属于网络层的ICMP控制报文，所以整体的IP报文大小是载荷（1472或者1473）加上IP头部的20字节和ICMP头部的8字节。显然，指定IP报文载荷为1473后，整个IP报文就达到1501字节，正好超过了1500字节，所以 ping www.baidu.com -s 1473 就在发送的途中丢失，也就无法收到ICMP响应了。
不过，也许你的网络环境跟我不同，特别是如果有隧道的存在，那-s 1472也无法通过。那么你可以不断调整这个值，直到试出一个刚刚能通过的尺寸，然后在它基础上加上28字节，就是你的网络环境的PMTU了。
补充：这里还隐含了另外一个知识点，就是IP分片。关于它的细节，你可以回顾第8讲的内容。
如何统计丢包率？
最后，我们来学习一下丢包率的统计方法。要统计丢包率，众所周知的方法应该就是用ping了，或者说“长ping”。比如下面的例子里，丢包率为1%：
--- turner-tls.map.fastly.net ping statistics ---
100 packets transmitted, 99 received, 1% packet loss, time 99204ms
rtt min/avg/max/mdev = 122.012/134.749/301.225/27.648 ms
不过ping还是有可能无法探测出网络的真实状况。其实在上一讲里，我们就发现，如果路径中有ECMP，那么因为ECMP哈希转发策略的存在，ping的网络路径可能就跟TCP的网络路径不同。这样可能就会造成这样的状况：
- 长ping没丢包的话，不等于应用也不丢包；
- 长ping丢包的话，应用丢包的可能性也很大。
所以，既然ping也未必准，那不如直接一边跑应用一边抓包，然后对抓包文件进行分析，从而得出丢包率。而这里，又分了两种途径：图形界面和命令行。
图形界面方法
在Wireshark中我们能看到TCP retransmission、Out-of-Order等信息提示，那么我们就可以借助这些信息，计算出丢包率来。
我们看一个抓包文件的Expert Information：
在第4讲中，我详细介绍过解读Expert Information的方法，这里就不赘述了，相信你也已经比较熟悉了。这里我们最关心的指标是retransmission，它有100个。
这些数量算多吗？没有基数就不好说了，所以让我们看一下整体包量。打开Wireshark的Statistics下拉菜单，选中第一个选项即Capture File Properties：
在弹出的界面中我们就能看到具体的数据了，比如这个抓包的整体包量是750个。
然后丢包率可以大致认为是重传率，也就是重传报文数/整体报文数。在这里就是100/750 = 13.3%。
命令行方法
另外一个办法是用 capinfos命令获取总的报文数：
$ capinfos viaLB.pcap
File name: viaLB.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 84 bytes
Number of packets: 750
File size: 68 kB
Data size: 315 kB
Capture duration: 2.076944 seconds
First packet time: 2016-12-09 20:06:00.629223
Last packet time: 2016-12-09 20:06:02.706167
Data byte rate: 151 kBps
Data bit rate: 1215 kbps
Average packet size: 420.67 bytes
Average packet rate: 361 packets/s
SHA256: 9c34dc15bcf69b419c0e3eb0c37fa851485adbe3953018b957b14de330fa0882
RIPEMD160: c353fdd8d634dd38ac395980b4824751f667908f
SHA1: fd86e4f6969cc8a27ff1a29cf2de88ab6d57db7d
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 750
结尾处就是总的报文数量，即Number of packets = 750。那么重传个数如何在命令行里获取呢？
你是否还记得之前我们学习过tshark这个命令？这里也是用 tshark，执行下面的命令：
$ tshark -n -q -r viaLB.pcap -z "io,stat,0,tcp.analysis.retransmission"
======================================
| IO Statistics |
| |
| Duration: 2.077 secs |
| Interval: 2.077 secs |
| |
| Col 1: tcp.analysis.retransmission |
|------------------------------------|
| |1 | |
| Interval | Frames | Bytes | |
|----------------------------------| |
| 0.000 <> 2.077 | 100 | 145400 | |
======================================
最后一行的Frames 100就是指重传报文个数100。同样的，把两个数字相除就得出了丢包率。
丢包多少算严重？
回到重传数量占整体比例的讨论。前面的例子里丢包率是13.3%。直觉上看，这个比例也高了。那如果降低一个数量级，比如1.33%，这算高还是低呢？
这个问题可能也没有标准答案，毕竟每个应用对于丢包和重传的敏感度也有不同。而且由于公网情况复杂，本身就有一定的丢包率存在，比如像前面的海底光缆拥塞造成的丢包，也难以避免。
实际上，公网丢包率在1%左右是一个可以接受的范围。如果明显超过1%，比如达到了5%以上，那对应用的影响就会比较明显了，此时应该通过节点修复或者链路调整，来解决丢包的问题，把丢包率控制在1%左右，最好是1%以下。
而内网网络会比公网稳定很多。一般来说，一个正常的内网也有万分之一左右的丢包率。如果明显超过了这个比率，比如达到了千分之一的话，尽管依然比公网丢包率低一个数量级，但也需要认真对待并解决。
小结
这节课，我们一起探讨了丢包这个关键话题的工具、原理，还有方法。我们学习了多种工具，包括：
- 探测类工具：ping、mtr、traceroute、nc、telnet等。
- 统计类工具：netstat、ss、nstat。
其中，netstat和nstat都会展示 TCP retransmission的数值，如果它随时间递增，那就说明这台主机的对外通信存在丢包的现象。我们也了解了Linux内核本身实现了SNMP计数器，这些计数器记录了系统启动后的各个网络指标的数值，而netstat等工具正是读取内核中这些计数器，获得了相应指标的数值。
另外我们也要清楚一点，ss能提供比netstat更多的网络信息，特别是TCP socket的各种属性。这些信息对TCP方面的排查工作很有帮助，比如运行：
而对于路径排查的重要工具 mtr 的原理和使用方法，你也要好好掌握。在mtr的输出中，要注意中间节点的丢包率。如果终点的丢包率比前面节点的低，那前面节点的丢包率只能作为有限的参考。如果节点丢包率出现越往后越高的情况，这样的丢包率的参考价值就高很多了。
而且，最好在通信两端都做mtr，然后结合两边的探测结果做综合分析。
另外，在丢包这个主题中，MTU 也是重要角色。因为路径MTU的不一致，某些情况下就会发生超出MTU而丢包的现象。由于ICMP消息不一定会回到发送方，就会导致发送方的PMTU机制不能正常工作，也就是无法感知到这个MTU超限的事实，导致连续发送失败。
一般我们会建议对自己网络情况了解清楚后，再对主机设置合适的MTU，这样可以最大程度上确保不发生MTU超限引发问题。另外呢，我们也可以用ping来探测PMTU，也就是运行：
最后，我们还学习了如何根据抓包文件，计算出丢包率，也就是丢包率=重传个数/总报文数。另外公网丢包率1%和内网丢包率万分之一，可以认为是正常范围。
思考题
最后，再给你留两道思考题：
- Linux中运行ifconfig -a看到的网卡接口的dropped指标，是指我们这里讨论的丢包吗？为什么？
- TCP是如何在发生丢包的情况下保证传输可靠性的呢？
欢迎你在留言区分享你的答案，我们一同进步、成长。
- 那时刻 👍（8） 💬（1）
网卡dropped 指标表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。而我们讨论的丢包是传输过程中，数据包在网络中丢失了，经过交换机转发过程中丢包，或者传输介质的原因丢失数据。 TCP 是如何在发生丢包的情况下保证传输可靠性的呢？ 1. 通过序列号和确认应答信号确保了数据不会重复发送和重复接收。 2. 同时通过超时重发控制保证即使数据包在传输过程中丢失，也能重发保持数据完整。 3. 通过三次握手，四次挥手建立和关闭连接的连接管理保证了端对端的通信可靠性。 4. TCP还使用了滑动窗口控制提高了数据传输效率
2022-03-28 - JianXu 👍（2） 💬（1）
出了事故以后，再来补课-：）
2022-07-23 - 老万 👍（2） 💬（1）
traceroute 应该是使用目的端口为33434以上的高端口
2022-04-29 - Chao 👍（2） 💬（1）
tcp发生丢包 最大措施就是降速，通过降速来保证传输。
2022-03-28 - 家军 👍（0） 💬（2）
老师请教一个问题：业务压测时，通过netstat -s监控发现：tcp重传较多(千分之2.5）其中快速重传占了99%以上，丢包重传较低（万分之0.25），造成这种情况的原因是什么？这种程度的重传需要关注吗？
2023-04-21 - 青梅煮酒 👍（0） 💬（1）
对比了tshark和wireshark的丢包计算结果，是所有的重传相加来计算丢包率的
2022-05-26 - 青梅煮酒 👍（0） 💬（1）
如果存在超时重传和快速重传是不是需要全部相加才可以计算丢包率呢
2022-05-26 - Realm 👍（0） 💬（1）
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 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通过重传、拥塞控制等机制保障可用性；
2022-03-28 - 追风筝的人 👍（1） 💬（0）
探测类工具：ping、mtr、traceroute、nc、telnet 等。 统计类工具：netstat、ss、nstat。
2022-03-30 - 上杉夏香 👍（0） 💬（0）
文章随机二刷： 一、为什么会发生丢包的情况 数据到达目的地的情况 1、到达目的地，只是不予受理。比如traceroute 采用ICMP、UDP探测，一般有一种方式在最后总是会丢包，变现为一直输出『* * * * 』 数据未到达目的地的情况 1、路径上MTU的限制+IP报文的不分段的联合机制 如何发现路径上最小的MTU： ping -s <icmp 报文的载荷大小> <目的IP>，不断试探。哦，没错，在这里你可以搞一个二分查找。 2、网络状态不好 路径上某台路由器达到最大的转发能力等等 二、如何检测到丢包？ 统计类工具，比如netstat、ss等工具。因为是静态的，你可以动起来~
三、在哪里丢包？ traceroute、mtr上场 四、丢包率是多少？ wireshark抓包，从专家信息中查看丢包的数量，然后获得整个过程的抓包总量。丢包率 = 丢包量/抓包总量2022-08-12