作者回复: 你说的没错,网卡的dropped是“有意识或者有感知”的丢包,而网络路径丢包是还没到达接收端的网卡,所以是"无感知“的,因为丢包环节不会对这个时间发送一个通知出来。 这类似一个逻辑命题:你不知道你不知道的事情。网卡也不知道路径上的丢包。
作者回复: 对我来说是又一个素材了:)
作者回复: 差不多,这就是TCP的重传和拥塞控制等机制的价值所在:)
作者回复: 恩这里有个笔误,感谢指出,我们更正一下~
作者回复: 我觉得这种程度的重传是可以接受的,因为内网一般也有约万分之一上下的丢包率,你这里是万分之0.25,其实你的内网质量已经很好了。 快速重传一般是报文在网络路径上或者在接收端出现了乱序,引发接收端回复DupAck,于是触发发送端快速重传。 至于“千分之2.5”这个重传率算不算高呢?需要综合各种因素来看,比如服务端的网络报文处理能力如何?压测时候的包量(pps, packet per second)达到多少? 可以在服务端运行sar -n DEV 1命令查看包量pps。根据主机配置的不同,包量上限也不同。在到达包量上限前,可能出现报文接收变慢、乱序增加等现象;到达包量上限后,丢包率会急剧上升,此时压测也到达了网络能力瓶颈(另外一个瓶颈是应用层瓶颈)。
作者回复: 确实如此:)
作者回复: 这里说的重传就包括了超时重传和快速重传。在Wireshark的expert information里,分别是retransmission和fast retransimission,两者之和就是重传包的数量~
作者回复: 都正确:) 网卡设备的dropped不同于路径中的丢包,这里的dropped是你说的各种NIC硬件相关的问题以及ring buffer等原因导致的“自己感知到的”丢包。 而路径上的丢包是网卡无法“感知”的,但是从TCP控制层面(序列号)是可以发现的,所以路径丢包是一个被“推理”出来的结论。 而ICMP echo报文能发现丢包也是利用了自己的报文序号(从1开始),这个方式也类似TCP序列号,同样可以发现丢包现象。 traceroute/mtr如果选中UDP模式,就是通过UDP端口号单调递增,也一样可以做到这一点。 融会贯通来理解网络会更好:)