【转】TCP/IP ECN分析
转自http://blog.sina.com.cn/s/blog_6cf9802d0100xtwv.html
一、 现有TCP流量在拥塞的情况下出现的问题
根据RFC793的描述，TCP协议是按照端到端设计的可靠的流传送协议。其特点是：
1、 在三次握手建立连接时，协商发送端和接收端的发送和接收能力，滑窗。
2、 在完成连接建立之后，TCP按照当初协商的窗口大小进行报文的发送。
3、 提供可靠地连接，TCP的接收端将使用ACK机制通知发送端数据是否成功接收。
4、 TCP发送端按照接收端的ACK来判断数据是否正确接收，并且对没有ACK的报文进行重发。
从上面的TCP协议的特点可以看出，TCP是端到端的协议，并不直接感知报文在中间路径上传送的状态。即，在网络中间路由器丢包时，TCP协议是通过感知是否有ACK或者是否有重复的ACK来重传报文。TCP将网络路径中的所有转发设备看做是黑盒，只要感知ACK没有在规定的时间收到，则认为报文被中间链路丢弃，并进行报文重传，保证数据可靠性。
对于网络链路中的路由器来说，需要转发的TCP报文并不一定来自同一台主机，各主机之间的TCP连接并不感知中间路由器的转发队列的忙闲状态。当中间路由器队列过载导致丢包后，
所有主机的TCP连接并不立即感知到，而是在定时器超时之后，由于没有收到ACK，开始重传报文。而这个定时器的时间相对较长，通常从几秒到几十秒不等。报文丢弃导致多路TCP开始降低发送速率，甚至在一个窗口发送完毕之后，TCP的重传定时器没有超时之前，整个发送过程会偶尔停滞。在所有TCP降低性能之后，路由器的转发队列拥塞得到缓解，不再丢弃报文，所有TCP又会同时提高发送速率，到达一定程度之后，路由器又开始丢弃报文，并重复刚才TCP的重传过程。该现象的问题有：
1、 丢包导致TCP重传，该重传定时器的时间较长，对时延敏感的应用来说，影响用户感受。
2、 丢包之后，TCP根据RFC793规定的要求，所有TCP开始进行退避，下调发送性能，拥塞得到缓解，但此时的网络利用率无法达到最优。
3、 在拥塞缓解之后，TCP为了获得发送的最优性能，又继续扩大发送窗口，直到发现丢包，重复上述问题过程。
二、 现有TCP的拥塞控制
1、 慢启动，TCP为了探测网络实际性能，也为了避免一开始就发送过多数据，使用的一种发送算法。即一开始尽发送一个MSS报文段，随着ACK的不停回复，TCP发送端开始放大发送能力，该算法的放大时按照指数方式，当达到一定的速率时切换成线性增长方式。
2、 快速重传，TCP在收到重复的3次ACK时，会认为重传队列中的第一个报文段被网络丢弃，但由于收到的重复的3次ACK，则认为该报文段之后的三个报文已经被接收端收到，则不等待重传定时器超时，直接重发重传队列中的第一个报文段。
3、 快速恢复，当TCP收到3次重复的ACK时，将拥塞窗口减半，并在后续再收到重复的ACK时线性增加窗口，以保证发送报文的性能。在收到新的非重复ACK后，TCP连接恢复到慢启动状态发送报文。
三、 路由器拥塞控制队列
在网络中的路由器的转发队列通常实现了Random Early Detection (RED)功能，即，路由器会根据当前转发队列的平均长度来做丢包决策，并且随机的丢弃一些TCP流量的报文，而不是等待队列溢出后丢弃全部的报文，这样能够很好的避免所有TCP同时超时的问题。由于按照队列的平均长度来进行丢包，而不是队列满长，所以会引起一部分TCP的退避，让一部分TCP先放缓，保证另一些TCP的通常。再次，使用的随机丢弃，所以针对所有TCP连接来说是相对公平的。
四、 ECN的设计概念
在RFC3168中定义了ECN的设计目标，是通过TCP发送端和接收端以及中间路由器的配合，感知中间路径的拥塞，并主动的减缓TCP的发送速率，从而从早期避免拥塞而导致的丢包，实现网络性能的最大利用。能够解决的问题如下：
1、 所有TCP发送端能够早期感知中间路径拥塞，并主动放缓发送速率，预防拥塞发生。
2、 在中间路由器上转发的队列上，对于超过平均队列长度的TCP报文进行ECN标记，并继续进行转发，不再丢弃报文。避免了报文的丢弃和TCP的重传。
3、 由于减少了丢包，TCP不需要经过几秒货几十秒的重传定时器出发报文重传，提高了时延敏感应用的用户感受。
4、 与没有部署ECN功能的网络相比，网络的利用率更好，不再在过载和轻载之前来回震荡。
五、 ECN在IP层和TCP层的修改
IP首部的修改
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
The Differentiated Services and ECN Fields in IP.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
The ECN Field in IP.
IP首部的TOS字段中的第7和8bit的res字段被重新定义为ECN字段，其中有四个取值，在RFC3168中描述，00代表该报文并不支持ECN，所以路由器的将该报文按照原始非ECN报文处理即可，即，过载丢包。01和10这两个值针对路由器来说是一样的，都表明该报文支持ECN功能，如果发生拥塞，则ECN字段的这两个将修改为11来表示报文经过了拥塞，并继续被路由器转发。针对01和10的具体区别请参考RFC3168。
所以路由器转发侧要支持ECN，需要有以下新增功能：
1、 当拥塞发生时，针对ECN=00的报文，走原有普通非ECN流程，即，进行RED丢包。
2、 当拥塞发生时，针对ECN=01或ECN=10的报文，都需要修改为ECN=11，并继续转发流程。
3、 当拥塞发生时，针对ECN=11的报文，需要继续转发。
4、 为了保证与不支持ECN报文的公平性，在队列超过一定长度时，需要考虑对支持ECN报文的丢弃。
TCP首部的修改
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
CWR: Congestion Window Reduce
ECE: ECN-Echo
The new definition of bytes 13 and 14 of the TCP Header.
针对主机侧的修改，首部将bit8和bit9的res字段修改为CWR和ECE。在RFC3168中的设计如下：
1、 在TCP接收端收到IP头中的ECN=11标记，并在回复ACK时将ECE bit置1。并在后续的ACK总均将ECE bit置1。
2、 在TCP发送端收到ECE bit置1的ACK报文时，需要将自己的发送速率减半，并在发送下一个报文时，将CWR bit置1。
3、 在接收端收到CWR bit置1的报文时，后续的ECE bit将不再置1。直到再次收到IP首部ECN=11时，重复上述过程。
4、 TCP发送端在收到一个ECE=1时，缩小发送窗口，并且在本次RTT时间内将不再再次缩小发送窗口。
5、 TCP接收端向发送端回应ACK时，如果该ACK是一个不带数据的“纯”ACK，那么必须IP首部ECN=00，因为TCP没有机制对纯ACK进行响应，就无法针对纯ACK发送拥塞通知。
6、 对于支持IP ECN的主机，TCP层在发送报文时需要将IP首部中的ECN置为01或10。
六、 ECN兼容性问题
IP 首部兼容性
由于ECN修改了IP首部，所以存在以下兼容性问题：
1、以下RFC除了RFCs 731,2474,2780这三个标准可以兼容ECN的增量部署之外，其他RFC实现均无法兼容ECN部署。
RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP header.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not
discuss any specific use for those two bits:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU | RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+ 2780
中间设备
针对防火墙、网管等中间安全和管理设备，其实现和配置规则可能不能很好的与当前ECN兼容。需要中间设备厂商修改代码或修改安全配置。
ECN在各种隧道中的支持
针对IP Tunnel[RFC2003]，RFC3168明确规定了报文到达隧道ingress和egress时ECN字段的复制要求，详细信息请参考RFC3168，这里不再赘述。
针对IP Sec[RFC2401]，RFC3168中明确定义了需要在IP Sec的安全关联数据库（SAD）和安全关联属性（SAA）中增加类型和字段来支持ECN在IP Sec隧道下的协商。详细信息请参考RFC3168，这里不再赘述。
针对MPLS, GRE, L2TP, PPTP等隧道支持ECN的规范没有在RFC3168中明确说明，但RFC3168提到使这些隧道支持ECN并非难事。
七、 ECN在现有网络中的增量部署
1、 网络中的路由器按照1999年的ECN草案方案实现，将只识别ECN=10的报文作为支持ECN功能，而不识别ECN=01的报文，这类路由器可能将ECN=01的报文将按照ECN=00的行为处理，最后进行RED丢包。但并不影响网络的正常功能。
2、 针对防火墙、网管等中间安全和管理设备，其实现和配置规则可能不能很好的与当前ECN兼容。需要中间设备厂商修改代码或修改安全配置。
3、 针对主机侧TCP仅有一端支持ECN功能时，支持ECN的TCP端需要先尝试进行ECN的协商，如果连接不成功，必须进行非ECN功能的TCP连接协商，以保证TCP的向后兼容性。
4、 当支持ECN的TCP协商了非ECN的TCP连接后，如果后续收到ECN报文，应该按照支持ECN的行为进行相应，以兼容早期ECN实现。
5、 针对IP Tunnel和IP Sec隧道，设置两种模式开关，即支持ECN和不支持ECN，在不支持ECN情况下，ECN报文通过隧道将按照原始不支持ECN的行为进行转发和丢弃。
6、 在隧道的ingress和egress必须同时支持ECN或同时不支持ECN，不允许非对称处理。
八、 ECN安全问题
1、 当TCP发送端重传定时器超时，引起重传报文发送时，则已经下调了发送速率，所以重传的报文IP头的ECN=00，则中间路由器不再置ECN标记。以避免DOS攻击。
2、 TCP接收端在收到IP头的ECN=11时，但TCP序号不正确的报文，回应ACK时，不应该将ECE bit置位，以避免DOS攻击。
