TCP Incast学习笔记.docx

一、 现有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 codepointECN: Explicit Congestion NotificationThe Differentiated Services and ECN Fields in IP.+-+-+| ECN FIELD |+-+-+ECT CE Obsolete RFC 2481 names for the ECN bits.0 0 Not-ECT0 1 ECT(1)1 0 ECT(0)1 1 CEThe 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 ReduceECE: ECN-EchoThe 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 notdiscuss 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 TunnelRFC2003，RFC3168明确规定了报文到达隧道ingress和egress时ECN字段的复制要求，详细信息请参考RFC3168，这里不再赘述。针对IP SecRFC2401，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和不支持