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

  • 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。

总结

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

posted @ 2017-06-12 23:56  edisongz  阅读(11307)  评论(0编辑  收藏