☰

流控丢包真的丢包了吗？

tag-icon • tag-icon tc
流控丢包真的丢包了吗？

虽然我的网络出现了轻微的超时问题（路由器需要休息一下，所以问题就解决了），但tc -s在注意到“丢弃”值代表了包的重要比例（至少为 10%）之后，我发现自己正在尝试破译输出：

qdisc cbq 1: root refcnt 2 rate 10Mbit (bounded,isolated) prio no-transmit
 Sent 392050166 bytes 727491 pkt (dropped 27505, overlimits 1201372 requeues 1) 
 backlog 0b 0p requeues 1 
  borrowed 0 overactions 0 avgidle 12500 undertime 0
qdisc sfq 10: parent 1:10 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
 Sent 16125105 bytes 265435 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 20: parent 1:20 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
 Sent 375890855 bytes 461738 pkt (dropped 27505, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc sfq 30: parent 1:30 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc ingress ffff: parent ffff:fff1 ---------------- 
 Sent 342713979 bytes 716041 pkt (dropped 1308, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0

所以，这些计数器代表真正丢弃的包裹，阿拉iptables？或者它只是其他事物的代表？这个数字代表什么？

手册上说了一些关于掉落的内容，但这让我产生了同样的疑问：

描述

Tc 用于配置 Linux 内核中的流量控制。交通控制包括以下内容：

[...]

掉落

超过设定带宽的流量也可能在入口和出口立即被丢弃。

答案1

丢弃的数据包将被丢弃。它不会到达目的地。这种情况可能发生在交换机或路由器中任何超出带宽的点。接收系统有责任跟踪传入的数据包并确保接收到所有数据包。 TCP 执行此操作，但 UDP 则不执行此操作。丢弃的数据包必须再次向发送站请求，因此在繁忙的路由上，丢弃的数据包可能会导致更多的拥塞和更多的丢弃数据包。

相关内容