跳至內容

顯式擁塞通知

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
互聯網協定套組
應用層
傳輸層
網絡層
連結層

顯式擁塞通知（英語：Explicit Congestion Notification，簡稱ECN）是一個對網際協定和傳輸控制協定（TCP）的擴充，定義於RFC 3168（2001）。ECN允許擁塞控制的端對端通知而避免丟包。ECN為一項可選功能，如果底層網絡設施支援，則可能被啟用ECN的兩個端點使用。

通常來說，TCP/IP網絡通過丟棄封包來表明信道阻塞。在ECN成功協商的情況下，ECN感知路由器可以在IP頭中設置一個標記來代替丟棄封包，以標明阻塞即將發生。封包的接收端回應傳送端的表示，降低其傳輸速率，就如同在往常中檢測到包遺失那樣。

相較於正確響應或者忽略位標記，一些過時或有故障的網絡裝置會丟棄或篡改封包的ECN位。[1][2][3]截至2015年 (2015-Missing required parameter 1=month!)，測量顯示，公共互聯網上會因ECN設置阻斷網絡連接的網頁伺服器減少到不足1%。[4]

2015年5月，蘋果公司宣佈將在受支援的及未來的產品中預設啟用ECN，以推進ECN信令在全行業的應用。[5]

操作

[編輯]

由於下列原因，ECN需要互聯網層和傳輸層提供特定支援：

  • 在TCP/IP中，路由器在互聯網層操作，而傳輸速率由傳輸層處的端點處理。
  • 擁塞可能僅由傳送端處理，但由於它是在封包傳送後發生，所以接收端必須向傳送端回傳擁塞指示。

在無ECN時，擁塞指示回傳是通過檢測分組遺失來間接實現。在有ECN時，擁塞通過設置IP分組內的ECN欄位為CE並由接收端通過在傳輸協定的報頭中設置適當的位來回傳給傳送端。例如，當使用TCP時，擁塞指示通過設置ECE位來回傳。

IP 中的 ECN 操作

[編輯]

ECN 使用 IPv4 首部或 IPv6 首部中 ToS (Type of Service，位於首部第 9 到 16 位元位) 欄位的兩個最低有效位（最右側的位編碼）來表示四個狀態碼：

  • 00 – 不支援 ECN 的傳輸，非 ECT(Non ECN-Capable Transport)
  • 10 – 支援 ECN 的傳輸，ECT(0)
  • 01 – 支援 ECN 的傳輸，ECT(1)
  • 11 – 發生擁塞，CE(Congestion Experienced)。

當兩端支援 ECN 時，它將封包標為 ECT(0) 或 ECT(1)。如果分組穿過一個遇到阻塞並且相應路由器支援 ECN 的活動佇列管理（英語：active queue management）（AQM）佇列（例如一個使用隨機早期檢測（英語：random early detection），即 RED 的佇列），它可以將代碼點更改為CE而非丟包。這種行為就是「標記」，其目的是通知接收端即將發生擁塞。在接收端，該擁塞指示由上層協定（傳輸層協定）處理，並且需要將訊號回傳給傳送端，以通知其降低傳輸速率。

因為 CE 指示只能由支援它的上層協定有效處理，ECN 只能配合上層協定使用。例如 TCP 協定，它支援阻塞控制並且有方法將 CE 指示回傳給傳送端。

TCP中的ECN

[編輯]

TCP支援使用TCP頭中的三個標記（flag）來支援ECN。第一個標記是隨機和（Nonce Sum，簡稱NS），用於防止TCP傳送者的封包標記被意外或惡意改動。[6]另兩位用於回傳擁塞指示（即指示傳送者應減少資訊傳送量）和確認接收到了擁塞指示回應。這即是ECN-Echo（ECE）和Congestion Window Reduced（CWR）位。

在TCP連接上使用ECN是可選的；當ECN被使用時，它必須在連接建立時通過SYN和SYN-ACK段中包含適當選項來協商。

當在一個TCP連接上協商ECN後，傳送方指示連接上的TCP段攜帶IP分組傳輸流量，將支援ECN的傳輸用ECT碼點標記。這使支援ECN的中間路由器可以標記具有CE碼點的IP分組而不是丟棄它們，以指示即將發生的阻塞。

當接收到具有遇到阻塞碼點時，TCP接收者使用TCP頭中的ECE標記回傳這個阻塞指示。當一個端點收到TCP帶有ECE位的段時，它減少其擁塞窗口來代替丟包。然後，它設置段的CWR位來確認阻塞指示。

節點保持傳輸設置有ECE位的TCP段，直到它接收到設置有CWR的段。

要使用tcpdump檢視受影響的封包，使用過濾方法 (tcp[13] & 0xc0 != 0)。

ECN與TCP控制包

[編輯]

由於傳輸控制協定（TCP）不對控制分組（純ACKs、SYN、FIN段）進行擁塞控制，控制分組通常不被標記為可進行ECN。

一份2009年的提議[7]建議將SYN-ACK標記為支援ECN。這種改進被稱為ECN+，已經顯示出對短壽命TCP連接的效能提供了顯著改善[8]。

ECN也在其他執行擁塞控制的傳輸層協定中被定義，尤其是數據擁塞控制協定（DCCP）和流控制傳輸協定（SCTP）。其一般原理類似於TCP，儘管編碼細節有所不同。

在原則上可以在用戶數據報協定（UDP）之上的協定層實行ECN。但是，UDP需要應用程式實行擁塞控制，並且當前的網絡API未提供訪問ECN位的方法。

對效能的影響

[編輯]

由於ECN僅在配合活動佇列管理（AQM）策略時有效，因此ECN的益處依賴於所用的AQM的精確度。

如預期那樣，ECN減少TCP連接中被丟棄的封包數量，以避免重傳、減少等待時間，尤其是網絡抖動。當TCP連接有單個未完成段時，這種效果最為明顯[9]，它可以避免傳輸控制協定（RTO）逾時；這通常發生在互動式連接時，例如遠端登入，以及事務協定，例如HTTP請求、SMTP的對談階段、SQL請求。

ECN對批次吞吐的效果不太明確[10]，因為現代的TCP實現在傳送方的窗口足夠大時對於及時處理段遺失相當友好。

ECN的使用已被發現在高度擁塞的網絡上是有害的，AQM演算法使封包不會被丟棄。[8]現代的AQM實現在極高負載下會丟包而非標記包來避免這個陷阱。

實現

[編輯]

許多現代產品中的TCP/IP協定已部分支援ECN；但是，大多數產品預設禁用ECN。[來源請求]

主機支援的TCP中的ECN

[編輯]

Microsoft Windows

[編輯]

Windows自Windows Server 2008和Windows Vista開始支援TCP中的ECN。[11]因為數據中心傳輸控制協定（DCTCP）被使用，從Windows Server 2012開始在Windows Server版本中預設啟用。[12]在更早的Windows版本以及非Server版本中，它被預設禁用。

ECN支援可以用命令啟用，例如netsh interface tcp set global ecncapability=enabled。

類Unix

[編輯]
BSD
[編輯]

FreeBSD 8.0和NetBSD 4.0為TCP實現了ECN支援，可以通過sysctl介面將net.inet.tcp.ecn.enable參數設為1來啟用。與此相同，OpenBSD中可以設置sysctl net.inet.tcp.ecn。[13][14]

Linux
[編輯]

從發佈於2002年11月的Linux內核2.4.20版本開始[15]，Linux支援TCP中的ECN的三種工作模式，以及通過sysctl介面設置/proc/sys/net/ipv4/tcp_ecn參數為下列值：[16]

  • 0 – 禁用ECN，不發起也不接受
  • 1 – 啟用ECN，當傳入連接請求時，並也在傳出連接時嘗試請求ECN
  • 2 – （預設）傳入連接請求時啟用ECN，但不在傳出連接上請求ECN

從2015年6月發佈的Linux內核4.1開始，tcp_ecn_fallback機制按RFC 3168中的規定[17][18]，在ECN被啟用（值為1）時預設啟用。該回退機制在傳出連接的初始設置時嘗試ECN連接，對沒有ECN能力的傳輸實行良好回退，緩解不支援ECN的主機或防火牆問題。

Mac OS X
[編輯]

Mac OS X 10.5和10.6為TCP實現了ECN支援。它採用sysctl的布林變數net.inet.tcp.ecn_negotiate_in和net.inet.tcp.ecn_initiate_out控制。[19]第一個變數在已經設置ECN標記的傳入連接上使用ECN；第二個則嘗試在傳出連接上啟用ECN。兩個變數均預設為0，但可以設置為1以實現相應的行為。

2015年6月，蘋果公司宣佈將在年內發佈的OS X 10.11將預設啟用ECN。[5]

iOS
[編輯]

2015年6月，蘋果公司宣佈iOS的下一版本——iOS 9，將支援ECN並預設啟用。[5]

Solaris
[編輯]

Solaris內核支援對TCP支援ECN的三種狀態：[來源請求]

  • never – 無ECN
  • active – 使用ECN
  • passive – 僅在被詢問時宣告ECN支援。

預設行為是passive。從Solaris 11開始，可以通過ipadm set-prop -p ecn=active tcp啟用完整的ECN功能。[來源請求]

路由器支援的IP中的ECN

[編輯]

由於在路由器中標記ECN依賴於某些形式的活動佇列管理（英語：active queue management），路由器必須組態合適的佇列規則才能實行ECN標記。

Cisco IOS路由器從12.2(8)T版本開始，如果已組態WRED（英語：Weighted random early detection）排隊規則，則實行ECN標記。

Linux路由器實行ECN標記，如果RED（英語：Random Early Detection）或GRED佇列顯式組態了ecn參數，通過使用sfb（英語：Stochastic Fair Blue）規則，或使用CoDel公平排隊（fq_codel）規則。

現代的BSD實現，例如FreeBSD、NetBSD和OpenBSD支援ECN標記，在許多排隊規則（英語：Queuing discipline）的ALTQ（英語：ALTQ）佇列實現，尤其是RED（英語：Random Early Detection）和Blue（英語：Blue (queue management algorithm)）。FreeBSD 11在具有ECN標記能力的ipfw/dummynet框架中包括CoDel、PIE、FQ-CoDel和FQ-PIE 排隊規則（英語：Queuing discipline）的實現。[20]

數據中心TCP

[編輯]

數據中心傳輸控制協定（也稱數據中心TCP或DCTCP）是利用ECN來增強傳輸控制協定的擁塞控制演算法，其用於數據中心網絡。標準的TCP擁塞控制演算法只能檢測擁塞的存在，而使用ECN的DCTCP可以測量擁塞的程度。[21]

DCTCP修改了TCP的接收端以始終中繼傳入連接的精確ECN標記，代價是忽略一個保持信令可靠性的功能。這使DCTCP的傳送端易受到接受ACK遺失的影響，因為它沒有檢測或應對的機制。[22]截至2014年7月 (2014-07)，以更可靠的方法提供等效或更好的接收器反饋的演算法是一個活躍的研究課題，並有一個被稱為「More accurate ECN feedback in TCP」（「TCP中更準確的ECN反饋」）（Accurate ECN，精準ECN）的實驗建議[23]。

參見

[編輯]

參考資料

[編輯]
  1. ^ Steven Bauer; Robert Beverly; Arthur Berger. Measuring the State of ECN Readiness in Servers, Clients, and Routers (PDF). Internet Measurement Conference 2011. 2011 [2016-12-17]. （原始內容存檔 (PDF)於2014-03-22）. 
  2. ^ Alberto Medina; Mark Allman; Sally Floyd. Measuring Interactions Between Transport Protocols and Middleboxes (PDF). Internet Measurement Conference 2004. [2016-12-17]. （原始內容存檔 (PDF)於2016-03-04）. 
  3. ^ TBIT, the TCP Behavior Inference Tool: ECN. Icir.org. [2014-03-22]. （原始內容存檔於2013-03-11）. 
  4. ^ Brian Trammell; Mirja Kühlewind; Damiano Boppart; Iain Learmonth; Gorry Fairhurst; Richard Scheffenegger. Enabling Internet-Wide Deployment of Explicit Congestion Notification (PDF). Proceedings of the Passive and Active Measurement Conference 2015. 2015 [14 June 2015]. （原始內容 (PDF)存檔於2015年6月15日）. 
  5. ^ 5.0 5.1 5.2 Your App and Next Generation Networks. Apple Inc. 2015 [2016-12-17]. （原始內容存檔於2015-06-15）. 
  6. ^ RFC 3540 - Robust Explicit Congestion Notification.
  7. ^ RFC 5562 - Adding Explicit Congestion Notification Capability to TCP's SYN/ACK Packets.
  8. ^ 8.0 8.1 Aleksandar Kuzmanovic.
  9. ^ Jamal Hadi Salim and Uvaiz Ahmed.
  10. ^ Marek Malowidzki, Simulation-based Study of ECN Performance in RED Networks, In Proc.
  11. ^ New Networking Features in Windows Server 2008 and Windows Vista. [2016-12-17]. （原始內容存檔於2012-04-15）. 
  12. ^ Data Center Transmission Control Protocol (DCTCP) (Windows Server 2012). [2016-12-17]. （原始內容存檔於2017-08-26）. 
  13. ^ Michael Lucas. Absolute OpenBSD: UNIX for the Practical Paranoid. Books.google.com. [2014-03-22]. 
  14. ^ Announcing NetBSD 4.0. 2007-12-19 [2014-10-13]. （原始內容存檔於2014-10-31）. 
  15. ^ A Map of the Networking Code in Linux Kernel 2.4.20, Technical Report DataTAG-2004-1, FP5/IST DataTAG Project (PDF). datatag.web.cern.ch. March 2004 [1 September 2015]. （原始內容存檔 (PDF)於2015-10-27）. 
  16. ^ Documentation/networking/ip-sysctl.txt: /proc/sys/net/ipv4/* Variables. kernel.org. [2016-02-15]. （原始內容存檔於2016-03-05）. 
  17. ^ RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP. ietf.org. September 2001 [2016-02-15]. （原始內容存檔於2019-04-26）. 
  18. ^ Linux man pages. man7.org. 2015-12-05 [2016-02-15]. （原始內容存檔於2016-02-16）. 
  19. ^ ECN (Explicit Congestion Notification) in TCP/IP. [2016-12-17]. （原始內容存檔於2012-04-15）. 
  20. ^ Import Dummynet AQM version 0.2.1 (CoDel, FQ-CoDel, PIE and FQ-PIE) to FreeBSD 11. The FreeBSD Project, FreeBSD r300779. [5 August 2016]. （原始內容存檔於2021-02-25）. 
  21. ^ Data Center TCP. [2011-08-23]. （原始內容存檔於2016-12-05）. 
  22. ^ Requirements for a More Accurate ECN Feedback. tools.ietf.org. IETF. March 9, 2015 [May 2, 2015]. （原始內容存檔於2015-11-19）. 
  23. ^ RFC 7560: Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback. tools.ietf.org. IETF. August 26, 2015 [May 12, 2016]. （原始內容存檔於2016-04-29）. 

外部連結

[編輯]
取自 "https://wiki.zwnes.eu.org/w/index.php?title=显式拥塞通知&oldid=83415940"