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的重传过程。该现象的问题有：

1、丢包导致TCP重传，该重传定时器的时间较长，对时延敏感的应用来说，影响用户感受。
2、丢包之后，所有TCP开始进行退避，下调发送性能，拥塞得到缓解，但此时的网络利用率无法达到最优。
3、在拥塞缓解之后，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，需要有以下新增功能：

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。

总结

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

参考

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