TCP慢启动，拥塞控制，ECN 笔记

TCP慢启动，拥塞控制，ECN 笔记

1，TCP慢启动

TCP在链接过程的三次握手完成后，开始传数据，并非一开始向网络通道中发送大量的数据包，这样很容易致使网络中路由器缓存空间耗尽，从而发生拥塞；而是根据初始的cwnd大小逐步增长发送的数据量，cwnd初始化为1个最大报文段(MSS)大小（这个值可配置不必定是1个MSS）；每当有一个报文段被确认，cwnd大小指数增加。 
开始 —> cwnd = 1 
1个RTT后 —> cwnd = 2*1 = 2 
2个RTT后 —> cwnd = 2*2= 4 
3个RTT后 —> cwnd = 4*2 = 8

2，拥塞避免

cwnd不能一直这样无限增加下去，必定须要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量，一旦cwnd>=ssthresh（大多数TCP的实现，一般大小都是65536），慢启动过程结束，拥塞避免阶段开始； 
拥塞避免：cwnd的值再也不指数级往上升，开始加法增长。此时当窗口中全部的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增长，这样就能够避免增加过快致使网络拥塞，慢慢的增长调整到网络的最佳值。 
非ECN环境下的拥塞判断，发送方RTO超时，重传了一个报文段；

• 1，把ssthresh下降为cwnd值的一半；
• 2，把cwnd从新设置为1；
• 3，从新进入慢启动过程。

3，快速重传

快速重传，TCP在收到重复的3次ACK时，会认为重传队列中的第一个报文段被网络丢弃，但因为收到的重复的3次ACK，则认为该报文段以后的三个报文已经被接收端收到，则不等待重传定时器超时，直接重发重传队列中的第一个报文段。

• 1，把ssthresh设置为cwnd的一半
• 2，把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
• 3，从新进入拥塞避免阶段。

4，快速恢复

快速恢复的数据包守恒原则，即同一个时刻在网络中的数据包数量恒定，“老”数据包离开后，才能向网络中发送“新”的数据包。若是发送方收到一个重复的ACK，TCP的ACK机制就代表有一个数据包离开，此时cwnd加1。

• 1，当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，而后重传丢失的报文段，加3的缘由是由于收到3个重复的ACK，代表有3个“老”的数据包离开了网络。
• 2，再收到重复的ACK时，拥塞窗口增长1。
• 3，当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。缘由是由于该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，能够回到恢复以前的状态了，也即再次进入拥塞避免状态。

5，ECN（Explicit Congestion Notification），WWDC 2017 再次提到

5.1，现有TCP在拥塞时出现的问题

非ECN环境下，在网络中间路由器丢包时，TCP协议经过RTO超时来重传丢失的包，保证数据可靠性。 
对于网络链路中的路由器来讲，当中间路由器队列过载致使丢包后，各主机之间的TCP链接并不感知中间路由器的转发队列的忙闲状态。而是在RTO定时器超时以后，因为没有收到ACK，开始重传报文。而这个定时器的时间相对较长，一般从几秒到几十秒不等。报文丢弃致使多路TCP开始下降发送速率，甚至在一个窗口发送完毕以后，TCP的重传定时器没有超时以前，整个发送过程会偶尔停滞。在全部TCP下降性能以后，路由器的转发队列拥塞获得缓解，再也不丢弃报文，全部TCP又会同时提升发送速率，到达必定程度以后，路由器又开始丢弃报文，并重复刚才TCP的重传过程。该现象的问题有：

• 一、丢包致使TCP重传，该重传定时器的时间较长，对时延敏感的应用来讲，影响用户感觉。
• 二、丢包以后，全部TCP开始进行退避，下调发送性能，拥塞获得缓解，但此时的网络利用率没法达到最优。
• 三、在拥塞缓解以后，TCP为了得到发送的最优性能，又继续扩大发送窗口，直到发现丢包，重复上述问题过程。

5.2，中间路由器拥塞控制队列

路由器的转发队列一般实现了RED功能，即路由器会根据当前队列的平均长度来作丢包决策，并随机丢弃一些TCP报文段，而不是等到队列满载，很好地避免了全部TCP同时超时的问题。

5.3，ECN设计

经过在TCP和IP首部的修改，能解决如下问题：

• 1，全部的TCP发送端尽快感知中间路径的拥塞，主动减少cwnd；
• 2，对于在中间路由器中超过平均队列长度的TCP报文进行ECN标记，并继续进行转发，不丢弃报文，避免了报文丢弃和发送端重传；
• 3，因为显式的标识拥塞的发生，不用再等待RTO超时（时间比较长）再重发数据，提高了时延敏感应用的直观感觉。
• 4，与非ECN网络环境相比，网络利用率更高，再也不是在过载和轻载之间来回震荡。

5.4，对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，须要有如下新增功能：

• 一、 当拥塞发生时，针对ECN=00的报文，走原有普通非ECN流程，即，进行RED丢包。
• 二、 当拥塞发生时，针对ECN=01或ECN=10的报文，都须要修改成ECN=11，并继续转发流程。
• 三、 当拥塞发生时，针对ECN=11的报文，须要继续转发。
• 四、 为了保证与不支持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中的设计以下：

• 一、 在TCP接收端收到IP头中的ECN=11标记，并在回复ACK时将ECE bit置1。并在后续的ACK总均将ECE bit置1。
• 二、 在TCP发送端收到ECE bit置1的ACK报文时，须要将本身的发送速率减半，并在发送下一个报文时，将CWR bit置1。
• 三、 在接收端收到CWR bit置1的报文时，后续的ECE bit将再也不置1。直到再次收到IP首部ECN=11时，重复上述过程。
• 四、 TCP发送端在收到一个ECE=1时，缩小发送窗口，而且在本次RTT时间内将再也不再次缩小发送窗口。
• 五、 TCP接收端向发送端回应ACK时，若是该ACK是一个不带数据的“纯”ACK，那么必须IP首部ECN=00，由于TCP没有机制对纯ACK进行响应，就没法针对纯ACK发送拥塞通知。
• 六、 对于支持IP ECN的主机，TCP层在发送报文时须要将IP首部中的ECN置为01或10。

总结

记录和转载别人的博客，加深记忆。

参考

• 《TCP/IP详解，卷1：协议》
• http://blog.csdn.net/itmacar/article/details/12278769
• ECN：http://blog.csdn.net/xxx_500/article/details/8584323