Can you summarize the following document?
        
  由於下列原因,ECN需要網際網路層和傳輸層提供特定支援:  在無ECN時,擁塞指示回傳是通過檢測分組丟失來間接實現。在有ECN時,擁塞通過設定IP分組內的ECN欄位為CE並由接收端通過在傳輸協議的報頭中設定適當的位來回傳給傳送端。例如,當使用TCP時,擁塞指示通過設定ECE位來回傳。

  ECN 使用 IPv4 首部或 IPv6 首部中 ToS (Type of Service,位於首部第 9 到 16 位元位) 欄位的兩個最低有效位(最右側的位編碼)來表示四個狀態碼: 當兩端支援 ECN 時,它將資料包標為 ECT(0) 或 ECT(1)。如果分組穿過一個遇到阻塞並且相應路由器支援 ECN 的活動佇列管理(AQM)佇列(例如一個使用隨機早期檢測,即 RED 的佇列),它可以將程式碼點更改為codice_5而非丟包。這種行為就是“標記”,其目的是通知接收端即將發生擁塞。在接收端,該擁塞指示由上層協議(傳輸層協議)處理,並且需要將訊號回傳給傳送端,以通知其降低傳輸速率。  因為 CE 指示只能由支援它的上層協議有效處理,ECN 只能配合上層協議使用。例如 TCP 協議,它支援阻塞控制並且有方法將 CE 指示回傳給傳送端。

  TCP支援使用TCP頭中的三個標記(flag)來支援ECN。第一個標記是隨機和(Nonce Sum,簡稱NS),用於防止TCP傳送者的資料包標記被意外或惡意改動。另兩位用於回傳擁塞指示(即指示傳送者應減少資訊傳送量)和確認接收到了擁塞指示迴應。這即是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檢視受影響的資料包,使用過濾方法 codice_6。

  由於傳輸控制協議(TCP)不對控制分組(純ACKs、SYN、FIN段)進行擁塞控制,控制分組通常不被標記為可進行ECN。  一份2009年的提議建議將SYN-ACK標記為支援ECN。這種改進被稱為ECN+,已經顯示出對短壽命TCP連線的效能提供了顯著改善。  ECN也在其他執行擁塞控制的傳輸層協議中被定義,尤其是資料擁塞控制協議(DCCP)和流控制傳輸協議(SCTP)。其一般原理類似於TCP,儘管編碼細節有所不同。  在原則上可以在使用者資料包協議(UDP)之上的協議層實行ECN。但是,UDP需要應用程式實行擁塞控制,並且當前的網路API未提供訪問ECN位的方法。

  由於ECN僅在配合活動佇列管理(AQM)策略時有效,因此ECN的益處依賴於所用的AQM的精確度。  如預期那樣,ECN減少TCP連線中被丟棄的資料包數量,以避免重傳、減少等待時間,尤其是網路抖動。當TCP連線有單個未完成段時,這種效果最為明顯,它可以避免傳輸控制協議(RTO)超時;這通常發生在互動式連線時,例如遠端登入,以及事務協議,例如HTTP請求、SMTP的會話階段、SQL請求。  ECN對批量吞吐的效果不太明確,因為現代的TCP實現在傳送方的視窗足夠大時對於及時處理段丟失相當友好。  ECN的使用已被發現在高度擁塞的網路上是有害的,AQM演算法使資料包不會被丟棄。現代的AQM實現在極高負載下會丟包而非標記包來避免這個陷阱。

  許多現代產品中的TCP/IP協議已部分支援ECN;但是,大多數產品預設禁用ECN。

  

  Windows自Windows Server 2008和Windows Vista開始支援TCP中的ECN。因為資料中心傳輸控制協議(DCTCP)被使用,從Windows Server 2012開始在Windows Server版本中預設啟用。在更早的Windows版本以及非Server版本中,它被預設禁用。  ECN支援可以用命令啟用,例如。

  

  FreeBSD 8.0和NetBSD 4.0為TCP實現了ECN支援,可以通過sysctl介面將引數設為1來啟用。與此相同,OpenBSD中可以設定。

  從釋出於2002年11月的Linux核心2.4.20版本開始,Linux支援TCP中的ECN的三種工作模式,以及通過sysctl介面設定引數為下列值:  從2015年6月釋出的Linux核心4.1開始,機制按RFC 3168中的規定,在ECN被啟用(值為1)時預設啟用。該回退機制在傳出連線的初始設定時嘗試ECN連線,對沒有ECN能力的傳輸實行良好回退,緩解不支援ECN的主機或防火牆問題。

  Mac OS X 10.5和10.6為TCP實現了ECN支援。它採用sysctl的布林變數和控制。第一個變數在已經設定ECN標記的傳入連線上使用ECN;第二個則嘗試在傳出連線上啟用ECN。兩個變數均預設為,但可以設定為以實現相應的行為。  2015年6月,蘋果公司宣佈將在年內釋出的OS X 10.11將預設啟用ECN。

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

  Solaris核心支援對TCP支援ECN的三種狀態: 預設行為是。從Solaris 11開始,可以通過啟用完整的ECN功能。

  由於在路由器中標記ECN依賴於某些形式的活動佇列管理,路由器必須配置合適的佇列規則才能實行ECN標記。  Cisco IOS路由器從12.2(8)T版本開始,如果已配置WRED排隊規則,則實行ECN標記。  Linux路由器實行ECN標記,如果RED或GRED佇列顯式配置了"ecn"引數,通過使用sfb規則,或使用CoDel公平排隊(fq_codel)規則。  現代的BSD實現,例如FreeBSD、NetBSD和OpenBSD支援ECN標記,在許多排隊規則的ALTQ佇列實現,尤其是RED和Blue。FreeBSD 11在具有ECN標記能力的ipfw/dummynet框架中包括CoDel、PIE、FQ-CoDel和FQ-PIE 排隊規則的實現。

  資料中心傳輸控制協議(也稱資料中心TCP或DCTCP)是利用ECN來增強傳輸控制協議的擁塞控制演算法,其用於資料中心網路。標準的TCP擁塞控制演算法只能檢測擁塞的存在,而使用ECN的DCTCP可以測量擁塞的程度。  DCTCP修改了TCP的接收端以始終中繼傳入連線的精確ECN標記,代價是忽略一個保持信令可靠性的功能。這使DCTCP的傳送端易受到接受ACK丟失的影響,因為它沒有檢測或應對的機制。,以更可靠的方法提供等效或更好的接收器反饋的演算法是一個活躍的研究課題,並有一個被稱為“More accurate ECN feedback in TCP”(“TCP中更準確的ECN反饋”)(Accurate ECN,精準ECN)的實驗建議。
顯式擁塞通知(英語:Explicit Congestion Notification,簡稱ECN)是一個對網際協議和傳輸控制協議(TCP)的擴充套件,定義於(2001)。ECN允許擁塞控制的端對端通知而避免丟包。ECN為一項可選功能,如果底層網路設施支援,則可能被啟用ECN的兩個端點使用。