是會選擇性丟包嗎?依據什麼分類來進行丟包?丟包的優先順序是怎樣?

這個問題要澄清一下。

流量和速率的澄清就先不糾了，我來說說速率超高流量

大概題主想問的是：

20M/s的網口收到100M/s的數據怎麼辦。

1. 物理網口只有幾種接收速率，不存在20M這樣奇葩的速率。這個澄清回頭我找一個鏈接補充上來。

2. 如果兩個設備商量好了一個速率，比如100M，那麼發送端是無法發送超過100M速率的數據的，除非你不顧協商強行上1000M，那接收端一個比特也收不到，直接down掉埠

3. 那麼發端如果真有超過100M速率的包要發怎麼辦？發送端自己丟掉，根本不發

4. 發端為什麼會有發包速率超過協商速率呢？有2種可能：

a. 上級設備給下級發送，上級設備的數據來源速率大，出口數據小。一般我們說這種叫下行。舉例來說，骨幹網上一個設備的千兆連在骨幹網，百兆連在下級網，如果千兆網來的數據超過百兆

b. 下級或同級多個介面接收到的數據，出口是同一個，恰好大家都高速率同時到達。例如，兩個百兆口同時發來60M/s的數據，恰好要轉發到同一個介面發出去

那麼設備內部會發生什麼情況呢？

不管是不是擁塞，交換機路由器的每個埠都有一個或多個發送緩存區，大家發過來的包按照優先順序和先後順序進行排隊。如果啟用了qos，那麼可能高優先順序隊列的包發送的可能性會大些。否則大家順序來。

這個緩衝大小，決定了接收機對超速收到的包的處理能力。

如果超速的包持續時間短，那麼將會在隊列里多呆會兒被發走。因為出口速率是定的。

如果超速包持續時間長，緩衝滿了，只好丟了。他也沒辦法。

出口緩衝很像江上的大壩，如果洪水來得不猛，庫存升高就可以了，洪水會被慢慢的用時間來平滑掉，下一天暴雨他泄洪2天，那麼泄洪的水也不會太大。如果太猛庫存撐不住了，只好增大泄洪，下游有危險也不能讓上級潰壩。

在交換機這裡呢，限制了出口泄洪速率，那就是內部丟掉。

這個問題說的是轉發設備，對於終端端點設備，稍稍有點差異，但基本原理相似。

我覺得這個問題的描述不成立。只可能發生的是」埠跑滿了」，於是你猜，哦，流量超了。

至於用什麼演算法。

一是限速 car cir pir lr

二是整形 三是對於多隊列調度 pq wfq wrr drr cbq 四是擁塞避免 wred red三往往調用一來做著色。

這個從屬於Queue Management（QM）的範疇，其中還分為主動隊列管理，即AQM（Active Queue Management）和被動隊列管理，即PQM（Passive Queue Management），RED，WRED，以及無線最新採用的CoDel之類的屬於其中的一種演算法，至於如何丟包，要看具體採用哪一種QM演算法了（根據不同需求）。

進入軟體隊列進行排隊(當然可以修改軟體隊列的行為)之後調度這個報文進入硬體隊列進行轉發。軟體隊列排滿則進行尾丟，還有其他的例如RED WRED，題主可以了解下Qos
單純從三層上面描述(沒有qos)，如果給定速率小於埠協商速率，超出緩衝區的包會被接收端丟掉，如果給定速率大於埠協商速率，超出緩衝區的包會被發送埠丟掉，在有塞控制的情況下，發送源會被告知擁塞從而降低發送速率
QOS
推薦閱讀：
相关文章