加载中…
正文 字体大小:

TCP/IP ECN分析

(2012-01-26 13:54:31)
标签:

杂谈

分类: 技术
一、 现有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攻击。

0

阅读 评论 收藏 转载 喜欢 打印举报
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有