详解TCP状态转换

Last Updated: 2023-04-18 09:44:07 Tuesday

-- TOC --

TCP的三次握手
TCP的四次挥手
详解TIME_WAIT状态
同时SYN
同时FIN
TIME_WAIT过多带来的影响
TCP抓包测试
强制close时RST，避免TIME_WAIT状态
ECE和CWR

本文详细介绍TCP连接的三次握手，四次挥手，2MSL，TIME_WAIT状态等概念。下图去掉CLOSED，刚好是TCP的11个状态：

下图来自RFC793：

                              +---------+ ---------\      active OPEN  
                              |  CLOSED |            \    -----------  
                              +---------+<---------\   \   create TCB  
                                |     ^              \   \  snd SYN    
                   passive OPEN |     |   CLOSE        \   \           
                   ------------ |     | ----------       \   \         
                    create TCB  |     | delete TCB         \   \       
                                V     |                      \   \     
                              +---------+            CLOSE    |    \   
                              |  LISTEN |          ---------- |     |  
                              +---------+          delete TCB |     |  
                   rcv SYN      |     |     SEND              |     |  
                  -----------   |     |    -------            |     V  
 +---------+      snd SYN,ACK  /       \   snd SYN          +---------+
 |         |<-----------------           ------------------>|         |
 |   SYN   |                    rcv SYN                     |   SYN   |
 |   RCVD  |<-----------------------------------------------|   SENT  |
 |         |                    snd ACK                     |         |
 |         |------------------           -------------------|         |
 +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+
   |           --------------   |     |   -----------                  
   |                  x         |     |     snd ACK                    
   |                            V     V                                
   |  CLOSE                   +---------+                              
   | -------                  |  ESTAB  |                              
   | snd FIN                  +---------+                              
   |                   CLOSE    |     |    rcv FIN                     
   V                  -------   |     |    -------                     
 +---------+          snd FIN  /       \   snd ACK          +---------+
 |  FIN    |<-----------------           ------------------>|  CLOSE  |
 | WAIT-1  |------------------                              |   WAIT  |
 +---------+          rcv FIN  \                            +---------+
   | rcv ACK of FIN   -------   |                            CLOSE  |  
   | --------------   snd ACK   |                           ------- |  
   V        x                   V                           snd FIN V  
 +---------+                  +---------+                   +---------+
 |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
 +---------+                  +---------+                   +---------+
   |                rcv ACK of FIN |                 rcv ACK of FIN |  
   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |  
   |  -------              x       V    ------------        x       V  
    \ snd ACK                 +---------+delete TCB         +---------+
     ------------------------>|TIME WAIT|------------------>| CLOSED  |
                              +---------+                   +---------+

                      TCP Connection State Diagram
                               Figure 6.

TCP传输的可靠性，是通过对每个传输字节的seq进行确认和checksum来保证的！

TCP的三次握手

客户端发送一个带SYN标志的TCP报文到服务器，这是三次握手过程中的第1个报文。
服务器端回应，这是三次握手中的第2个报文，这个报文同时带ACK标志（确认客户端发的SYN）和SYN标志（服务器给客户端发自己的SYN）。因此它表示对刚才客户端SYN报文的回应，同时又发送SYN给客户端，询问客户端是否准备好进行数据通讯。
客户必须再次给服务端回应一个ACK报文（确认服务器端发送的SYN），这是第3个报文。（理论上，第3个报文就可以携带数据了）

客户端状态： SYN_SENT ----> ESTAB

客户端报文：发送SYN ----> 接收ACK（带SYN标志） ----> 发送ACK

服务器端状态： LISTEN ----> SYN_RCVD ----> ESTAB

服务器端报文：接收SYN ----> 发送ACK（带SYN标志）----> 接收ACK

客户端会先于服务器端一丢丢，进入ESTAB状态。

通信双方同步Sequence Number

通信双方在SYN报文中，都随机初始化了一个Seq序列号，这个序列号是保障数据可靠接收的关键。SYN报文中含有一个随机的序列号SEQ，应答ACK报文中含有SEQ+1。TCP是全双工通信，两个发送方使用自己随机初始化的序列号。

检测TCP端口是否开放？

从原理上看，发送SYN后如果能收到对应的ACK，这个端口就可以进行TCP连接，这就是TCP端口扫描的基本原理。因此，connect调用能成功，端口就是open的。（用connect接口，就能够写一个简单的端口扫描工具，或tcping工具）

TCP的四次挥手

服务器端的TCP，其实就是不断地产生与客户端一样的TCP，因此在ESTAB状态下，任何一方都可以首先离开，发FIN。

主动关闭连接的一方A，调用close，协议层发送FIN包，进入FINWAIT-1状态；
被动关闭的一方B收到FIN包后，协议层回复ACK，然后B进入CLOSE_WAIT状态；
A收到ACK后进入FINWAIT-2状态，此时，A等待B调用close；
B在完成所有数据发送后，调用close操作，此时，协议层发送FIN包给A，等待A的ACK，B进入LAST_ACK状态；
A收到FIN包，协议层回复ACK，此时，A进入TIME_WAIT状态，而B进入CLOSED状态;
等待2MSL时间，A结束TIME_WAIT，进入CLOSED状态 ;

因此，首先发起关闭TCP的一方，最终会进入著名的TIME_WAIT状态！

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方执行主动关闭，而另一方执行被动关闭。

我们说的四次挥手，具体是那四次呢？其实就是双方各自发出的FIN报文和各自给对方的ACK报文，加起来一共4个报文。

主动关闭方A的状态变化： ESTAB ----> FINWAIT-1 ----> FINWAIT-2 ----> TIME_WAIT ----> CLOSED

主动方A的报文：发送FIN ----> 收到ACK ----> 收到FIN ----> 发送ACK

被动关闭方B的状态变化：ESTAB ----> CLOSE_WAIT ----> LAST-ACK ----> CLOSED

被动方B的报文：收到FIN ----> 发送ACK ----> （完成数据发送后）发送FIN ----> 收到ACK

由于网络传输，主动方A有可能先收到被动方B的FIN，然后才收到ACK，所以就多了一个进入 CLOSING 状态，然后跳过 FINWAIT-2 状态，直接到 TIME_WAIT 状态的转移路径！

FIN_WAIT_1和FIN_WAIT_2状态，表示等待对方的FIN_ACK和FIN报文，而这两种状态的区别是，FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它要主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态。正常情况下，无论对方处于何种情况下，都应该马上回应ACK 报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

也有可能是三次挥手，比如收到对端的FIN，在回复ACK的时候，自己没有数据要发送，有可能将FIN和ACK合并在一起发给对端。就像三次握手的时候，Server将SYN和ACK合并在一起一样。

特别注意：Python的close接口，不一定会发出FIN！请先shutdown！

详解TIME_WAIT状态

要先记住，主动发起FIN的那一方A，才会进入这个著名的TIME_WAIT状态。主动发FIN，就意味着自己的数据传输已经完成了，后面不会再发送数据了！

也有可能不发FIN，直接发RST，此时就没有TIME_WAIT，参考close和shutdown

此时，被动方B回应ACK后，进入CLOSE_WAIT状态，B虽然收到了FIN，也回应了ACK，但B的数据可能还没有发完，它还要继续发送数据。被动方B要完成数据发送后，才会发出自己的FIN，进入LAST-ACK状态。主动方A会进入TIME_WAIT状态，就是因为被动方B可能还有数据在发送，网络中可能还存在B发出的，A还未接收到的数据。

socket有个shutdown接口，可以只关闭发送或接收，调用shutdown可以发出FIN，而调用close有时会直接发RST。

由于网络传输的各种不确定性，在TIME_WAIT状态下，主动的A虽然占用了一组（ip,port）资源，暂时不会被系统回收再利用，直到TIME_WAIT超时结束。主动方A这样长时间的等待，确保了新的连接（假如继续使用相同的ip和port资源），绝对不会收到旧连接在网络上重传的报文。如下图：

time_wait_1

假如TIME_WAIT的时间很短，或者没有，新的socket又不小心复用了相同的ip和port资源，seq=3的报文，被新的连接错误的接收（此时正好seq=3能够跟其它报文的seq对应上，如果seq对不上，会被RST）。

上图是收到错误的数据包的情况，下图是收到错误类型的报文：

time_wait_2

被动的B发送FIN后，一直收不到ACK（丢了），此时如果正好A端不小心复用了ip和port资源，并用来建立新的连接，主动的A会发送SYN，B收到后认为这是个错误的报文，直接RST！

因此，TIME_WAIT状态其实就是等待网络出清，规避各种可能因为网络传输的不确定性造成的问题。

2MSL是什么？

MSL：Max Segment Lifetime，是网络报文的最大生存时间！2MSL，就是2倍这个时间。（TCP报文使用segment这个术语，这暗指了它可以处理很长的数据流stream，而segment只是stream的一部分）

这个2MSL时间有多长呢？

60秒，内核写死的默认值（fedora）；
2分钟，协议规定2分钟；
不一定，30秒，1分钟、2分钟或者4分钟。不同的发行版可能会不同（发行版本给内核打补丁）。

2MSL的时间是从主动方A接收到FIN，回应ACK后，开始计时的。如果在TIME-WAIT时间内，因为主动方A的ACK没有传输到被动房B，主动方A又重复接收到了被动房B重发的FIN报文，那么2MSL时间将重新计时。（这会是一种攻击方式吗？）

修改TIME_WAIT的时长，需要重新编译内核：

$ grep -rnE 'TCP_TIMEWAIT_LEN' --include=*.h
include/net/tcp.h:121:#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
include/net/tcp.h:123:#define TCP_FIN_TIMEOUT   TCP_TIMEWAIT_LEN

确保对方收到自己发送的最后一个ACK（因为对方发送了FIN），如果对方没有收到自己发送的ACK必定会重新发送FIN，这样保证4次断开的完整性。因为MSL是最大报文生存时间，如果在1个MSL时间内自己发送的ACK对方没有收到那就注定收不到了，而且对方肯定还会发送FIN，那么一个FIN发送过来的最长时间也是1个MSL，所以这里要等待2MSL。
另外一个原因就是避免延迟的IP报文，在频繁短连接的场景下客户端通常会对同一个IP和Port在短时间内发起多次连接，而客户端使用的端口是自己系统随机分配的高位端口，有一定概率发生上一个socket四元组和下一个socket四元组一样，如果这时候一个原本属于上一个socket四元组的被延迟的IP报文送达，那么这将发送数据混乱的状态，所以为了避免这种情况就利用MSL这个报文最大生存时长机制让残余的IP报文在网络中消失。这时候同样的四元组又可以被使用了。

Server在accept之后，会创建一个新的socket，不会影响那个用于accept的socket。新的socket的端口号也是系统随机分配的，当Server主动关闭了这个连接，进入TIME_WAIT状态的也仅仅只是这个新的socket。Server还可以继续创建新的socket，用不同的port。

同时SYN

tcp_syn

两个应用程序同时执行主动打开的情况是可能的，虽然发生的可能性较低。

每一端都发送一个SYN，并传递给对方，且每一端都使用对端所知的端口作为本地端口（主动bind）。但多数伯克利版的tcp/ip实现并不支持同时打开。

同时FIN

tcp_fin

这种情况比较糟糕，通信两端都会进入TIME_WAIT状态。

如果应用程序同时发送FIN，或者由于网络传输的原因，导致双方都在发出自己的FIN后，收到对方的FIN，则双方在发送后会首先进入FIN_WAIT_1状态。在收到对端的FIN后，回复一个ACK，会进入CLOSING状态。在收到对端的ACK后，进入TIME_WAIT状态。这种情况称为同时关闭。同时关闭也需要有4次报文交换，与典型的关闭相同。

TIME_WAIT过多带来的影响

过多的 TIME-WAIT 状态主要的危害有两种：

第一是内存资源占用；
第二是对端口资源的占用，一个 TCP 连接至少消耗「发起连接方」的一个本地端口，可能导致发起方无法创建新的连接；

主动FIN的一方，主要受系统资源限制：

由于一个四元组表示 TCP 连接，理论上主动关闭连接的服务端可以建立很多连接，因为服务端只监听一个端口，不会因为 TCP 连接过多而导致端口资源受限。但是 TCP 连接过多，会占用系统资源，比如文件描述符、内存资源、CPU 资源、线程资源等。

被动连接方，主动关闭TCP，此TCP对应的不占用port资源的socket，会有TIME_WAIT状态吗？

会的。但是主动连接方或者Server方，都有可能直接发RST，这样就没有TIME_WAIT状态。

TCP抓包测试

Server在12345号端口上listen， accept之后，发送一个welcome消息，然后等待10秒后，close。Client直接在Python解释器里面随手输入。

（1）Client连接后，调用recv，让Server先close，Client后close

10:02:31.526543 IP localhost.55056 > localhost.12345: Flags [S], seq 1926553857, win 65495, options [mss 65495,sackOK,TS val 2537488315 ecr 0,nop,wscale 7], length 0
10:02:31.526572 IP localhost.12345 > localhost.55056: Flags [S.], seq 1990950355, ack 1926553858, win 65483, options [mss 65495,sackOK,TS val 2537488315 ecr 2537488315,nop,wscale 7], length 0
10:02:31.526582 IP localhost.55056 > localhost.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 2537488315 ecr 2537488315], length 0
10:02:31.526955 IP localhost.12345 > localhost.55056: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 2537488315 ecr 2537488315], length 8
10:02:31.526961 IP localhost.55056 > localhost.12345: Flags [.], ack 9, win 512, options [nop,nop,TS val 2537488315 ecr 2537488315], length 0
10:02:41.537577 IP localhost.12345 > localhost.55056: Flags [F.], seq 9, ack 1, win 512, options [nop,nop,TS val 2537498326 ecr 2537488315], length 0
10:02:41.580922 IP localhost.55056 > localhost.12345: Flags [.], ack 10, win 512, options [nop,nop,TS val 2537498369 ecr 2537498326], length 0
10:02:46.088801 IP localhost.55056 > localhost.12345: Flags [F.], seq 1, ack 10, win 512, options [nop,nop,TS val 2537502877 ecr 2537498326], length 0
10:02:46.088815 IP localhost.12345 > localhost.55056: Flags [.], ack 2, win 512, options [nop,nop,TS val 2537502877 ecr 2537502877], length 0

完美的三次握手和四次挥手！

（2）Client连接后，不调用recv，在Server调用close后，client调用close

10:04:47.825547 IP localhost.55058 > localhost.12345: Flags [S], seq 262689593, win 65495, options [mss 65495,sackOK,TS val 2537624614 ecr 0,nop,wscale 7], length 0
10:04:47.825560 IP localhost.12345 > localhost.55058: Flags [S.], seq 2935847414, ack 262689594, win 65483, options [mss 65495,sackOK,TS val 2537624614 ecr 2537624614,nop,wscale 7], length 0
10:04:47.825569 IP localhost.55058 > localhost.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 2537624614 ecr 2537624614], length 0
10:04:47.825988 IP localhost.12345 > localhost.55058: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 2537624614 ecr 2537624614], length 8
10:04:47.825995 IP localhost.55058 > localhost.12345: Flags [.], ack 9, win 512, options [nop,nop,TS val 2537624614 ecr 2537624614], length 0
10:04:57.832942 IP localhost.12345 > localhost.55058: Flags [F.], seq 9, ack 1, win 512, options [nop,nop,TS val 2537634621 ecr 2537624614], length 0
10:04:57.876939 IP localhost.55058 > localhost.12345: Flags [.], ack 10, win 512, options [nop,nop,TS val 2537634665 ecr 2537634621], length 0
10:05:00.360197 IP localhost.55058 > localhost.12345: Flags [R.], seq 1, ack 10, win 512, options [nop,nop,TS val 2537637148 ecr 2537634621], length 0

注意：此时client直接发出了RST报文。

（3）Client连接后，在server close之前，client直接close

10:07:59.675050 IP localhost.55060 > localhost.12345: Flags [S], seq 4215475499, win 65495, options [mss 65495,sackOK,TS val 2537816463 ecr 0,nop,wscale 7], length 0
10:07:59.675075 IP localhost.12345 > localhost.55060: Flags [S.], seq 2210383874, ack 4215475500, win 65483, options [mss 65495,sackOK,TS val 2537816463 ecr 2537816463,nop,wscale 7], length 0
10:07:59.675095 IP localhost.55060 > localhost.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 2537816463 ecr 2537816463], length 0
10:07:59.676064 IP localhost.12345 > localhost.55060: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 2537816464 ecr 2537816463], length 8
10:07:59.676081 IP localhost.55060 > localhost.12345: Flags [.], ack 9, win 512, options [nop,nop,TS val 2537816464 ecr 2537816464], length 0
10:08:02.314109 IP localhost.55060 > localhost.12345: Flags [R.], seq 1, ack 9, win 512, options [nop,nop,TS val 2537819102 ecr 2537816464], length 0

不给Server发Fin的机会，Client直接RST。

（4） Client连接后，也发一个消息，但是在Server close之前，client先close

10:10:28.424276 IP localhost.55062 > localhost.12345: Flags [S], seq 2883372796, win 65495, options [mss 65495,sackOK,TS val 2537965212 ecr 0,nop,wscale 7], length 0
10:10:28.424313 IP localhost.12345 > localhost.55062: Flags [S.], seq 4093837342, ack 2883372797, win 65483, options [mss 65495,sackOK,TS val 2537965212 ecr 2537965212,nop,wscale 7], length 0
10:10:28.424343 IP localhost.55062 > localhost.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 2537965212 ecr 2537965212], length 0
10:10:28.425555 IP localhost.12345 > localhost.55062: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 2537965214 ecr 2537965212], length 8
10:10:28.425575 IP localhost.55062 > localhost.12345: Flags [.], ack 9, win 512, options [nop,nop,TS val 2537965214 ecr 2537965214], length 0
10:10:30.362500 IP localhost.55062 > localhost.12345: Flags [P.], seq 1:4, ack 9, win 512, options [nop,nop,TS val 2537967151 ecr 2537965214], length 3
10:10:30.362526 IP localhost.12345 > localhost.55062: Flags [.], ack 4, win 512, options [nop,nop,TS val 2537967151 ecr 2537967151], length 0
10:10:33.361355 IP localhost.55062 > localhost.12345: Flags [R.], seq 4, ack 9, win 512, options [nop,nop,TS val 2537970149 ecr 2537967151], length 0

没想到，这个时候Client还是直接发RST。

（5）Client连接后，发个消息（或者增加一个recv），等待Server先close，自己最后close

10:14:05.555841 IP localhost.55066 > localhost.12345: Flags [S], seq 569604261, win 65495, options [mss 65495,sackOK,TS val 2538182344 ecr 0,nop,wscale 7], length 0
10:14:05.555887 IP localhost.12345 > localhost.55066: Flags [S.], seq 1036382583, ack 569604262, win 65483, options [mss 65495,sackOK,TS val 2538182344 ecr 2538182344,nop,wscale 7], length 0
10:14:05.555917 IP localhost.55066 > localhost.12345: Flags [.], ack 1, win 512, options [nop,nop,TS val 2538182344 ecr 2538182344], length 0
10:14:05.556892 IP localhost.12345 > localhost.55066: Flags [P.], seq 1:9, ack 1, win 512, options [nop,nop,TS val 2538182345 ecr 2538182344], length 8
10:14:05.556914 IP localhost.55066 > localhost.12345: Flags [.], ack 9, win 512, options [nop,nop,TS val 2538182345 ecr 2538182345], length 0
10:14:08.567662 IP localhost.55066 > localhost.12345: Flags [P.], seq 1:4, ack 9, win 512, options [nop,nop,TS val 2538185356 ecr 2538182345], length 3
10:14:08.567687 IP localhost.12345 > localhost.55066: Flags [.], ack 4, win 512, options [nop,nop,TS val 2538185356 ecr 2538185356], length 0
10:14:15.568236 IP localhost.12345 > localhost.55066: Flags [R.], seq 9, ack 4, win 512, options [nop,nop,TS val 2538192356 ecr 2538185356], length 0

第一次观察到Server直接发RST的情况！

强制close时RST，避免TIME_WAIT状态

这不是推荐的做法，TIME_WAIT是我们的朋友，如果服务器有太多TIME_WAIT，可以尝试不要主动关闭TCP，让分散在各个地方的Client去关闭。

强制在close的时候发RST，使用SO_LINGER：

struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));

如果l_onoff为非 0，且l_linger值为 0，那么调用close后，会立该发送一个RST标志给对端，该 TCP 连接将跳过四次挥手，也就跳过了TIME_WAIT状态，直接关闭。

Python版本：

import socket
import struct
s = socket.socket()
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii',1,0))

ECE和CWR

下面介绍TCP头中，ECE和CWR标志位是如何工作的：

会话建立时，要协商ECN的支持情况，A发送一个ECE和CWR置位的SYN包，B应答一个仅ECE置位的SYN-ACK包，这样协商表示双方支持ECN，其他情况不允许发送仅ECE置位的SYN-ACK包。
连接建立后，后续发送的数据报文，要将IP头中ECN置位为ECT。（kernel在封装TCP Segment的时候，要设置IP报文的ECT标志）
后续传输中，若中间链路预测到拥塞，则会对上述数据报文IP头中置位CE。（参考：IP头的ECN）
当TCP接收端收到IP头中有CE标记的报文后，回复ACK时，将TCP的ECE bit置1，并在后续所有报文中，一直将ECE bit置1，不论收到的IP报文是否还有CE。
当TCP发送端收到ECE bit置1的ACK报文时，缩小发送窗口，将自己的发送速率减半，并在发送下一个报文时，将CWR bit置1。
当TCP接收端收到CWR bit置1的报文时，后续报文的ECE bit将不再置1，直到再次收到IP首部ECN=11时，重复上述过程。

RFC3168还规定的一些实现细节：

TCP接收端向发送端回应ACK时，如果该ACK是一个不带数据的纯ACK，那么必须将IP首部ECN设置为00，因为TCP没有机制对纯ACK进行响应，无法针对纯ACK发送拥塞通知。
TCP必须协商成功双方都支持ECN之后，才可以在发送数据包时将IP头中ECN置位为ECT。
如果TCP连接一端发送了ECE包，该主机需要正确清除或设置该TCP连接中后续报文的CWR标记。
即便一开始ECN协商没有成功，后续有收到CE标记的TCP报文，也要正确按照支持ECN处理，发出ECE置位的ACK包。
ECE和CWR完全置位，被认为是ECE-setup SYN，ECE和CWR，1个或者2个都不置位都是non-ECE-setup SYN。只有ECE置位，CWR不置位才是ECE-setup SYN-ACK，其他ECE/CWR组合都认为是non-ECE-setup SYN-ACK，都需要正确处理。
SYN和SYN-ACK报文中不允许设置IP头中ECT位。
一旦连接进入TIMEW-WAIT或CLOSED状态，ECN协商结果不可继承，必须重新协商。
如果主机发送ECN-setup SYN包后，收到了RST，或者在SYN重传定制器超时后重新发送，后续要重新发送一个普通ECE/CWR都不置位的SYN包，进行非ECN连接。
TCP重传报文不允许设置ECT（0）或ECT（1），防止DOS攻击。
收包窗口之外的报文应该忽略ECN位的处理，防止DOS攻击。
TCP窗口探测报文不允许设置IP头ECT位或TCP CWR标记，窗口探测报文如果被置CE，接收端要按照ECN标准正确处理。
窗口内只处理一次ECE报文，或者一个round-trip-time RTT周期内处理一次ECE。
如果TCP支持ECN，TCP发送端口不论什么原因导致的窗口减小，都要在窗口减小后发送的第一个包中将CWR置位，如果此CWR置位的包被丢弃（对应重传定时器超时），发送端需要再次减小窗口并发送一个新的CWR置位的包，CWR置位的包不能是重传的包。
针对主机侧TCP仅有一端支持ECN功能时，支持ECN的TCP端需要先尝试进行ECN的协商，如果连接不成功，必须进行非ECN功能的TCP连接协商，以保证TCP的向后兼容性。
TCP接收端在收到IP头的ECN=11时，但TCP序号不正确的报文，回应ACK时，不应该将ECE bit置位，以避免DOS攻击。

太多细节....

本文链接：https://cs.pynote.net/net/tcp/202302281/

-- EOF --

-- MORE --