text: 緩衝膨脹是一種因資料包過度緩衝而引起的資料包交換網路高延遲原因。緩衝膨脹還可能導致資料包延遲變化，線上遊戲，甚至普通的網頁瀏覽，即使是非常高速的網路也幾乎無法使用。一些通訊裝置製造商在他們的某些網路產品中不必要地設計了過大的緩衝區。在這種裝置中，當網路鏈路擁塞時，就會發生緩衝膨脹，從而導致資料包在這些超大緩衝區中長時間排隊。在先進先出佇列系統中，過大的緩衝區會導致更長的佇列和更高的延遲，並且不會提高網路吞吐量。早在1985年就已經有人發現並描述了這種緩衝膨脹現象。從2009年開始，它受到了越來越廣泛的關注。緩衝.網路裝置製造商的既定經驗是提供足夠大的緩衝區，足夠透過裝置的流量緩衝起碼250ms的資料。例如，路由器的千兆乙太網介面將需要相對較大的32 MB緩衝區。 緩衝區的這種大小可能導致TCP擁塞控制演算法失效。然後，在重置擁塞控制和TCP連接回升到速度並再次填充緩衝區之前，需要花費一些時間來耗盡緩衝區。 因此，緩衝膨脹會導致諸如高延遲和可變延遲之類的問題，並且在緩衝區充滿了一個TCP流的資料包，然後丟棄其他資料包時，阻塞了所有其他流的網路瓶頸。緩衝膨脹僅在該緩衝區重度使用時才出現嚴重影響。換句話說，過大的緩衝區成為他們緩衝的連線的瓶頸時才具有破壞作用。可以使用大多數作業系統提供的ping實用工具來衡量服務瓶頸的緩衝區大小。首先，對其他主機執行ping操作；然後，開始幾秒鐘長的下載，並停止幾次。透過設計，TCP擁塞避免演算法將迅速填充路由上的瓶頸。如果下載。在前面的示例中，使用高階traceroute工具而不是簡單的ping接收到的資料包的RTT。機制.大多數TCP擁塞控制演算法都依靠測量丟包的發生來確定連線兩端之間的可用頻寬。該演算法會加快資料傳輸速度，直到資料包開始丟失，然後降低傳輸速率。理想情況下，他們會不斷調整傳輸速率，直到達到鏈路的平衡速度為止。為了使演算法能夠選擇合適的傳輸速度，必須及時收到有關丟包的反饋。使用已滿的大緩衝區時，資料包雖然最後會到達目的地，但延遲較高。因為資料包沒有丟失，所以即使上行鏈路飽和，TCP也不會減慢速度，從而進一步導致緩衝區飽和。僅在緩衝區完全飽和時才丟棄新到達的資料包。一旦發生這種情況，TCP可能認為連線的路徑已更改而決定更激進地搜尋尋找新的工作點。資料包在傳輸之前先在網路緩衝區中排隊；在有問題的情況下，僅當緩衝區已滿時才丟棄資料包。在較舊的路由器上，緩衝區很小，因此緩衝區很快就裝滿了，因此，在鏈路飽和後不久，資料包就開始丟失，因此TCP協議可以進行調整，問題不會變得明顯。在較新的路由器上，緩衝區已變得足夠大，可以容納幾秒鐘的緩衝資料。對於TCP，當緩衝區填滿時，擁塞的連結似乎可以正常執行。TCP演算法不知道連結已阻塞，並且直到緩衝區最終溢位並丟棄資料包後才開始採取糾正措施。只要緩衝區的實現是簡單的佇列，所有透過緩衝區的包都會出現這樣的延遲。因此，所有經過已滿緩衝區的連線，延遲都會受到影響。可用的通道頻寬也可能最終未被使用，因為某些緩衝區可能被資料阻塞，等待資料傳送到較慢的目的地，因此可能無法迅速到達某些較快的目的地。這些影響削弱了使用其他網路協議的應用程式的互動性，其中包括對延遲敏感的應用程式中使用的UDP。對應用的影響.無論頻寬要求如何，要求持續低延遲或無抖動傳輸的任何型別的服務都可能受到緩衝膨脹的影響。示例包括語音呼叫，線上遊戲，影片聊天以及其他互動式應用程式，例如即時訊息傳遞和遠端登入。當出現緩衝膨脹現象並且網路處於負載狀態時，即使是正常的網頁載入也可能需要花費幾秒鐘來完成，或者簡單的DNS查詢由於超時而失敗。DSL Reports Speedtest 是一種易於使用的測試，其中包括關於緩衝膨脹的評分。ICSI Netalyzr 是另一個線上工具，可用於檢查網路是否存在緩衝膨脹，以及檢查許多其他常見配置問題。該服務已於2019年3月關閉。有些網站列出了一些工具和過程，用於確定連線是否有過多的緩衝會減慢連線速度。解決方案和緩解措施.存在幾種技術解決方案，可以大致分為兩類：針對網路的解決方案和針對端點的解決方案。 兩種解決方案通常是互補的。網路解決方案通常採用佇列管理演算法的形式。 這類解決方案一直是IETF AQM工作組的重點。 著名的例子包括：針對端點的解決方案的著名示例包括：對於大多數終端使用者而言，修改家用路由器可以帶來最大的改進。 大多數技術修復程式都包含在Linux作業系統的最新版本和LEDE / OpenWrt售後路由器韌體中。 也可以透過減少OS 和網路硬體上的緩衝區大小來緩解該問題。但是，這通常是不可配置的。
metadata: erhwenkuo/wikipedia-zhtw
metadata: 緩衝膨脹
metadata: https://zh.wikipedia.org/wiki?curid=6925758