☰

流控丟包真的丟包了嗎？

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 則不執行此操作。丟棄的資料包必須再次向發送站請求，因此在繁忙的路由上，丟棄的資料包可能會導致更多的擁塞和更多的丟棄資料包。

相關內容