緩衝膨脹
 | 此條目需要補充更多來源。 (2020年3月15日) |
緩衝膨脹是一種因數據包過度緩衝而引起的數據包交換網絡高延遲原因。緩衝膨脹還可能導致數據包延遲變化（也稱為抖動），並降低整體網絡吞吐量。當路由器或交換機配置了過大的緩衝區時，對於許多交互式應用程式，例如IP語音（VoIP），在線遊戲，甚至普通的網頁瀏覽，即使是非常高速的網絡也幾乎無法使用。
一些通信設備製造商在他們的某些網絡產品中不必要地設計了過大的緩衝區。在這種設備中，當網絡鏈路擁塞時，就會發生緩衝膨脹，從而導致數據包在這些超大緩衝區中長時間排隊。在先進先出隊列系統中，過大的緩衝區會導致更長的隊列和更高的延遲，並且不會提高網絡吞吐量。
早在1985年就已經有人發現並描述了這種緩衝膨脹現象。[1]從2009年開始，它受到了越來越廣泛的關注。[2]
緩衝
[編輯]網絡設備製造商的既定經驗是提供足夠大的緩衝區，足夠通過設備的流量緩衝起碼250ms的數據。例如，路由器的千兆乙太網接口將需要相對較大的32 MB緩衝區。[3] 緩衝區的這種大小可能導致TCP擁塞控制算法失效。然後，在重置擁塞控制和TCP連接回升到速度並再次填充緩衝區之前，需要花費一些時間來耗盡緩衝區。[4] 因此，緩衝膨脹會導致諸如高延遲和可變延遲之類的問題，並且在緩衝區充滿了一個TCP流的數據包，然後丟棄其他數據包時，阻塞了所有其他流的網絡瓶頸。[5]
緩衝膨脹僅在該緩衝區重度使用時才出現嚴重影響。換句話說，過大的緩衝區成為他們緩衝的連接的瓶頸時才具有破壞作用。可以使用大多數作業系統提供的ping實用工具來衡量服務瓶頸的緩衝區大小。首先，對其他主機執行ping操作；然後，開始幾秒鐘長的下載，並停止幾次。通過設計，TCP擁塞避免算法將迅速填充路由上的瓶頸。如果下載（分別為上載）與ping報告的往返時間的直接且重要的增加相關，則表明在下載方向上，當前緩衝區已成為瓶頸，發生了緩衝膨脹現象。由於往返時間的增加是由瓶頸上的緩衝區引起的，因此最大的增加可以粗略估計其大小（以毫秒為單位）。[6]
在前面的示例中，使用高級traceroute工具而不是簡單的ping（例如MTR）不僅會演示瓶頸上是否存在緩衝膨脹，還會查明其在網絡中的位置。Traceroute通過顯示路由（路徑）並測量數據包在網絡中的傳輸延遲來實現此目的。路由的歷史記錄為從路由（路徑）中的每個連續主機（遠程節點）接收到的數據包的RTT。[7]
機制
[編輯]大多數TCP擁塞控制算法都依靠測量丟包的發生來確定連接兩端之間的可用帶寬。該算法會加快數據傳輸速度，直到數據包開始丟失，然後降低傳輸速率。理想情況下，他們會不斷調整傳輸速率，直到達到鏈路的平衡速度為止。為了使算法能夠選擇合適的傳輸速度，必須及時收到有關丟包的反饋。使用已滿的大緩衝區時，數據包雖然最後會到達目的地，但延遲較高。因為數據包沒有丟失，所以即使上行鏈路飽和，TCP也不會減慢速度，從而進一步導致緩衝區飽和。僅在緩衝區完全飽和時才丟棄新到達的數據包。一旦發生這種情況，TCP可能認為連接的路徑已更改而決定更激進地搜索尋找新的工作點。[8]
數據包在傳輸之前先在網絡緩衝區中排隊；在有問題的情況下，僅當緩衝區已滿時才丟棄數據包。在較舊的路由器上，緩衝區很小，因此緩衝區很快就裝滿了，因此，在鏈路飽和後不久，數據包就開始丟失，因此TCP協議可以進行調整，問題不會變得明顯。在較新的路由器上，緩衝區已變得足夠大，可以容納幾秒鐘的緩衝數據。對於TCP，當緩衝區填滿時，擁塞的連結似乎可以正常運行。TCP算法不知道連結已阻塞，並且直到緩衝區最終溢出並丟棄數據包後才開始採取糾正措施。
只要緩衝區的實現是簡單的隊列，所有通過緩衝區的包都會出現這樣的延遲。因此，所有經過已滿緩衝區的連接，延遲都會受到影響。可用的通道帶寬也可能最終未被使用，因為某些緩衝區可能被數據阻塞，等待數據傳送到較慢的目的地，因此可能無法迅速到達某些較快的目的地。這些影響削弱了使用其他網絡協議的應用程式的交互性，其中包括對延遲敏感的應用程式（如VoIP和在線遊戲）中使用的UDP。[9]
對應用的影響
[編輯]無論帶寬要求如何，要求持續低延遲或無抖動傳輸的任何類型的服務都可能受到緩衝膨脹的影響。示例包括語音呼叫，在線遊戲，視頻聊天以及其他交互式應用程式，例如即時消息傳遞和遠程登錄。
當出現緩衝膨脹現象並且網絡處於負載狀態時，即使是正常的網頁加載也可能需要花費幾秒鐘來完成，或者簡單的DNS查詢由於超時而失敗。[10]
DSL Reports Speedtest [11]是一種易於使用的測試，其中包括關於緩衝膨脹的評分。ICSI Netalyzr [12]是另一個在線工具，可用於檢查網絡是否存在緩衝膨脹，以及檢查許多其他常見配置問題。[13]該服務已於2019年3月關閉。有些網站列出了一些工具和過程，用於確定連接是否有過多的緩衝會減慢連接速度。[14]
解決方案和緩解措施
[編輯]存在幾種技術解決方案，可以大致分為兩類：針對網絡的解決方案和針對端點的解決方案。 兩種解決方案通常是互補的。網絡解決方案通常採用隊列管理算法的形式。 這類解決方案一直是IETF AQM工作組的重點。 [15] 著名的例子包括：
- AQM算法，例如CoDel和PIE。 [16]
- 混合AQM和數據包調度算法，例如FQ-CoDel。 [17]
- DOCSIS標準[18]修正案，使電纜數據機中的緩衝區控制更加智能。 [19]
- 由於Linux通常在無線訪問點中使用，因此將隊列管理（FQ-CoDel）集成到Linux作業系統的WiFi子系統中。 [20]
針對端點的解決方案的著名示例包括：
對於大多數最終用戶而言，修改家用路由器可以帶來最大的改進。 [22] 大多數技術修復程序都包含在Linux作業系統的最新版本和LEDE / OpenWrt售後路由器固件中。 [22] 也可以通過減少OS [23]和網絡硬體上的緩衝區大小來緩解該問題。但是，這通常是不可配置的。
參考資料
[編輯]- ^ On Packet Switches With Infinite Storage. 1985-12-31 [2020-02-25]. （原始內容存檔於2021-05-01）.
- ^ van Beijnum, Iljitsch. Understanding Bufferbloat and the Network Buffer Arms Race. Ars Technica. 2011-01-07 [2011-11-12]. （原始內容存檔於2012-08-27）.
- ^ Nick McKeown. Sizing Router Buffers (PDF). ACM SIGCOMM. ACM. 2004 [2013-10-15]. （原始內容存檔 (PDF)於2013-10-15）.
- ^ Nichols, Kathleen. Controlling Queue Delay. ACM Queue. ACM Publishing. 2012-05-06 [2013-09-27]. （原始內容存檔於2020-02-27）.
- ^ Gettys, Jim. Bufferbloat: Dark Buffers in the Internet. IEEE Internet Computing. IEEE: 95–96. May–June 2011 [2012-02-20]. doi:10.1109/MIC.2011.56. （原始內容存檔於October 12, 2012）.
- ^ Clunis, Andrew. Bufferbloat demystified. 2013-01-22 [2013-09-27]. （原始內容存檔於2020-11-11）.[自述來源]
- ^ traceroute(8) – Linux man page. die.net. [2013-09-27]. （原始內容存檔於2021-04-15）.
- ^ Jacobson, Van; Karels, MJ. Congestion avoidance and control (PDF). ACM SIGCOMM Computer Communication Review. 1988, 18 (4). （原始內容 (PDF)存檔於2004-06-22）.
- ^ Technical Introduction to Bufferbloat. Bufferbloat.net. [2013-09-27]. （原始內容存檔於2020-02-25）.
- ^ Gettys, Jim; Nichols, Kathleen. Bufferbloat: Dark Buffers in the Internet. Communications of the ACM 55 (1). ACM: 57–65. January 2012 [2012-02-28]. doi:10.1145/2063176.2063196. （原始內容存檔於2015-08-10）.
- ^ Speed test - how fast is your internet?. dslreports.com. [26 October 2017]. （原始內容存檔於2021-05-04）.
- ^ ICSI Netalyzr. berkeley.edu. [30 January 2015]. （原始內容存檔於2019-04-07）.
- ^ Understanding your Netalyzr results. [26 October 2017]. （原始內容存檔於2021-04-22）.
- ^ Tests for Bufferbloat. bufferbloat.net. [26 October 2017]. （原始內容存檔於2020-12-31）.
- ^ IETF AQM working group. ietf.org. [26 October 2017]. （原始內容存檔於2021-02-26）.
- ^ Pan, Rong; Natarajan, Preethi; Piglione, Chiara; Prabhu, Mythili; Subramanian, Vijay; Baker, Fred; VerSteeg, Bill. PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem. 2013 IEEE 14th International Conference on High Performance Switching and Routing (HPSR). IEEE. 2013. doi:10.1109/HPSR.2013.6602305.
- ^ Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric. The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm. 2016-03-18 [2017-09-28]. （原始內容存檔於2021-03-08）.
- ^ DOCSIS "Upstream Buffer Control" feature. CableLabs: 554–556. [2012-08-09]. （原始內容存檔於2020-05-14）.
- ^ Gettys, Jim; Nichols, Kathleen. Bufferbloat: Dark Buffers in the Internet. Communications of the ACM 55 (1). ACM: 57–65. January 2012 [2012-02-28]. doi:10.1145/2063176.2063196. （原始內容存檔於2015-08-10）.
- ^ What Can I Do About Bufferbloat?. bufferbloat.net. [26 October 2017]. （原始內容存檔於2021-02-02）.
- ^ Gettys, Jim; Nichols, Kathleen. Bufferbloat: Dark Buffers in the Internet. Communications of the ACM 55 (1). ACM: 57–65. January 2012 [2012-02-28]. doi:10.1145/2063176.2063196. （原始內容存檔於2015-08-10）.
- ^ 22.0 22.1 What Can I Do About Bufferbloat?. bufferbloat.net. [26 October 2017]. （原始內容存檔於2021-02-02）.
- ^ Gettys, Jim; Nichols, Kathleen. Bufferbloat: Dark Buffers in the Internet. Communications of the ACM 55 (1). ACM: 57–65. January 2012 [2012-02-28]. doi:10.1145/2063176.2063196. （原始內容存檔於2015-08-10）.