当TIME_WAIT状态的TCP正常挥手，收到SYN后…

摘要：今天就来讨论下这个问题，在TCP正常挥手过程中，处于TIME_WAIT状态的连接，收到相同四元组的SYN后会发生什么？

本文分享自华为云社区《在TIME_WAIT状态的TCP连接，收到SYN后会发生什么？》，作者：小林coding。

周末跟朋友讨论了一些TCP的问题，在查阅《Linux服务器高性能编程》这本书的时候，发现书上写了这么一句话：

书上说，处于TIME_WAIT状态的连接，在收到相同四元组的SYN后，会回RST报文，对方收到后就会断开连接。

书中作者只是提了这么一句话，没有给予源码或者抓包图的证据。

起初，我看到也觉得这个逻辑也挺符合常理的，但是当我自己去啃了TCP源码后，发现并不是这样的。

所以，今天就来讨论下这个问题，「在TCP正常挥手过程中，处于TIME_WAIT状态的连接，收到相同四元组的SYN后会发生什么？」

问题现象如下图，左边是服务端，右边是客户端：

先说结论

在跟大家分析TCP源码前，我先跟大家直接说下结论。

针对这个问题，关键是要看 SYN 的「序列号和时间戳」是否合法，因为处于 TIME_WAIT 状态的连接收到 SYN 后，会判断 SYN 的「序列号和时间戳」是否合法，然后根据判断结果的不同做不同的处理。

先跟大家说明下，什么是「合法」的 SYN？

合法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大，并且 SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。
非法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小，或者 SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。

上面 SYN 合法判断是基于双方都开启了 TCP 时间戳机制的场景，如果双方都没有开启 TCP 时间戳机制，则 SYN 合法判断如下：

合法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大。
非法 SYN：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小。

收到合法 SYN

如果处于 TIME_WAIT 状态的连接收到「合法的 SYN 」后，就会重用此四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。

用下图作为例子，双方都启用了 TCP 时间戳机制，TSval 是发送报文时的时间戳：

上图中，在收到第三次挥手的FIN报文时，会记录该报文的TSval（21），用ts_recent变量保存。然后会计算下一次期望收到的序列号，本次例子下一次期望收到的序列号就是301，用rcv_nxt变量保存。

处于TIME_WAIT状态的连接收到SYN后，因为SYN的seq（400）大于rcv_nxt（301），并且SYN的TSval（30）大于ts_recent（21），所以是一个「合法的SYN」，于是就会重用此四元组连接，跳过2MSL而转变为SYN_RECV状态，接着就能进行建立连接过程。

收到非法的SYN

如果处于TIME_WAIT状态的连接收到「非法的SYN」后，就会再回复一个第四次挥手的ACK报文，客户端收到后，发现并不是自己期望收到确认号（acknum），就回RST报文给服务端。

用下图作为例子，双方都启用了TCP时间戳机制，TSval是发送报文时的时间戳：

处于TIME_WAIT状态的连接收到SYN后，因为SYN的seq（200）小于rcv_nxt（301），所以是一个「非法的SYN」，就会再回复一个与第四次挥手一样的ACK报文，客户端收到后，发现并不是自己期望收到确认号，就回RST报文给服务端。

客户端等待一段时间还是没收到SYN+ACK后，就会超时重传SYN报文，重传次数达到最大值后，就会断开连接。

PS：这里先埋一个疑问，处于TIME_WAIT状态的连接，收到RST会断开连接吗？

源码分析

下面源码分析是基于Linux4.2版本的内核代码。

Linux内核在收到TCP报文后，会执行tcp_v4_rcv函数，在该函数和TIME_WAIT状态相关的主要代码如下：

inttcp_v4_rcv(structsk_buff*skb)

{

structsock*sk;

...

//收到报文后，会调用此函数，查找对应的sock

sk=__inet_lookup_skb(&tcp_hashinfo,skb,__tcp_hdrlen(th),th->source,

th->dest,sdif,&refcounted);

if(!sk)

gotono_tcp_socket;

process:

//如果连接的状态为time_wait，会跳转到do_time_wait

if(sk->sk_state==TCP_TIME_WAIT)

gotodo_time_wait;

...

do_time_wait:

...

//由tcp_timewait_state_process函数处理在time_wait状态收到的报文

switch(tcp_timewait_state_process(inet_twsk(sk),skb,th)){

//如果是TCP_TW_SYN，那么允许此SYN重建连接

//即允许TIM_WAIT状态跃迁到SYN_RECV

caseTCP_TW_SYN:{

structsock*sk2=inet_lookup_listener(....);

if(sk2){

....

gotoprocess;

}

}

//如果是TCP_TW_ACK，那么，返回记忆中的ACK

caseTCP_TW_ACK:

tcp_v4_timewait_ack(sk,skb);

break;

//如果是TCP_TW_RST直接发送RESET包

caseTCP_TW_RST:

tcp_v4_send_reset(sk,skb);

inet_twsk_deschedule_put(inet_twsk(sk));

gotodiscard_it;

//如果是TCP_TW_SUCCESS则直接丢弃此包，不做任何响应

caseTCP_TW_SUCCESS:;

}

gotodiscard_it;

}

该代码的过程：

接收到报文后，会调用__inet_lookup_skb()函数查找对应的sock结构；
如果连接的状态是TIME_WAIT，会跳转到do_time_wait处理；
由tcp_timewait_state_process()函数来处理收到的报文，处理后根据返回值来做相应的处理。

先跟大家说下，如果收到的SYN是合法的，tcp_timewait_state_process()函数就会返回TCP_TW_SYN，然后重用此连接。如果收到的SYN是非法的，tcp_timewait_state_process()函数就会返回TCP_TW_ACK，然后会回上次发过的ACK。

接下来，看tcp_timewait_state_process()函数是如何判断SYN包的。

enumtcp_tw_status

tcp_timewait_state_process(structinet_timewait_sock*tw,structsk_buff*skb,

conststructtcphdr*th)

{

...

//paws_reject为false，表示没有发生时间戳回绕

//paws_reject为true，表示发生了时间戳回绕

boolpaws_reject=false;

tmp_opt.saw_tstamp=0;

//TCP头中有选项且旧连接开启了时间戳选项

if(th->doff>(sizeof(*th)>>2)&&tcptw->tw_ts_recent_stamp){

//解析选项

tcp_parse_options(twsk_net(tw),skb,&tmp_opt,0,NULL);

if(tmp_opt.saw_tstamp){

...

//检查收到的报文的时间戳是否发生了时间戳回绕

paws_reject=tcp_paws_reject(&tmp_opt,th->rst);

}

}

....

//是SYN包、没有RST、没有ACK、时间戳没有回绕，并且序列号也没有回绕，

if(th->syn&&!th->rst&&!th->ack&&!paws_reject&&

(after(TCP_SKB_CB(skb)->seq,tcptw->tw_rcv_nxt)||

(tmp_opt.saw_tstamp&&//新连接开启了时间戳

(s32)(tcptw->tw_ts_recent-tmp_opt.rcv_tsval)<0))){//时间戳没有回绕

//初始化序列号

u32isn=tcptw->tw_snd_nxt+65535+2;

if(isn==0)

isn++;

TCP_SKB_CB(skb)->tcp_tw_isn=isn;

returnTCP_TW_SYN;//允许重用TIME_WAIT四元组重新建立连接

}

if(!th->rst){

//如果时间戳回绕，或者报文里包含ack，则将TIMEWAIT状态的持续时间重新延长

if(paws_reject||th->ack)

inet_twsk_schedule(tw,&tcp_death_row,TCP_TIMEWAIT_LEN,

TCP_TIMEWAIT_LEN);

//返回TCP_TW_ACK,发送上一次的ACK

returnTCP_TW_ACK;

}

inet_twsk_put(tw);

returnTCP_TW_SUCCESS;

}

如果双方启用了TCP时间戳机制，就会通过tcp_paws_reject()函数来判断时间戳是否发生了回绕，也就是「当前收到的报文的时间戳」是否大于「上一次收到的报文的时间戳」：

如果大于，就说明没有发生时间戳绕回，函数返回false。
如果小于，就说明发生了时间戳回绕，函数返回true。

从源码可以看到，当收到SYN包后，如果该SYN包的时间戳没有发生回绕，也就是时间戳是递增的，并且SYN包的序列号也没有发生回绕，也就是SYN的序列号「大于」下一次期望收到的序列号。就会初始化一个序列号，然后返回TCP_TW_SYN，接着就重用该连接，也就跳过2MSL而转变为SYN_RECV状态，接着就能进行建立连接过程。

如果双方都没有启用TCP时间戳机制，就只需要判断SYN包的序列号有没有发生回绕，如果SYN的序列号大于下一次期望收到的序列号，就可以跳过2MSL，重用该连接。

如果SYN包是非法的，就会返回TCP_TW_ACK，接着就会发送与上一次一样的ACK给对方。

在TIME_WAIT状态，收到RST会断开连接吗？

在前面我留了一个疑问，处于TIME_WAIT状态的连接，收到RST会断开连接吗？

会不会断开，关键看net.ipv4.tcp_rfc1337这个内核参数（默认情况是为0）：

如果这个参数设置为0，收到RST报文会提前结束TIME_WAIT状态，释放连接。
如果这个参数设置为1，就会丢掉RST报文。

源码处理如下：

enumtcp_tw_status

tcp_timewait_state_process(structinet_timewait_sock*tw,structsk_buff*skb,

conststructtcphdr*th)

{

....

//rst报文的时间戳没有发生回绕

if(!paws_reject&&

(TCP_SKB_CB(skb)->seq==tcptw->tw_rcv_nxt&&

(TCP_SKB_CB(skb)->seq==TCP_SKB_CB(skb)->end_seq||th->rst))){

//处理rst报文

if(th->rst){

//不开启这个选项，当收到RST时会立即回收tw，但这样做是有风险的

if(twsk_net(tw)->ipv4.sysctl_tcp_rfc1337==0){

kill:

//删除tw定时器，并释放tw

inet_twsk_deschedule_put(tw);

returnTCP_TW_SUCCESS;

}

}else{

//将TIMEWAIT状态的持续时间重新延长

inet_twsk_reschedule(tw,TCP_TIMEWAIT_LEN);

}

...

returnTCP_TW_SUCCESS;

}

}

TIME_WAIT状态收到RST报文而释放连接，这样等于跳过2MSL时间，这么做还是有风险。

sysctl_tcp_rfc1337这个参数是在rfc1337文档提出来的，目的是避免因为TIME_WAIT状态收到RST报文而跳过2MSL的时间，文档里也给出跳过2MSL时间会有什么潜在问题。

TIME_WAIT状态之所以要持续2MSL时间，主要有两个目的：

防止历史连接中的数据，被后面相同四元组的连接错误的接收；
保证「被动关闭连接」的一方，能被正确的关闭；

详细的为什么要设计TIME_WAIT状态，我在这篇有详细说明：如果 TIME_WAIT 状态持续时间过短或者没有，会有什么问题？

虽然TIME_WAIT状态持续的时间是有一点长，显得很不友好，但是它被设计来就是用来避免发生乱七八糟的事情。

《UNIX网络编程》一书中却说道：TIME_WAIT是我们的朋友，它是有助于我们的，不要试图避免这个状态，而是应该弄清楚它。

所以，我个人觉得将net.ipv4.tcp_rfc1337设置为1会比较安全。

总结

在TCP正常挥手过程中，处于TIME_WAIT状态的连接，收到相同四元组的SYN后会发生什么？

如果双方开启了时间戳机制：

如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大，并且SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。那么就会重用该四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。
如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小，或者SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。那么就会再回复一个第四次挥手的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号，就回 RST 报文给服务端。

在TIME_WAIT状态，收到RST会断开连接吗？

如果net.ipv4.tcp_rfc1337参数为0，则提前结束TIME_WAIT状态，释放连接。
如果net.ipv4.tcp_rfc1337参数为1，则会丢掉该RST报文。

点击关注，第一时间了解华为云新鲜技术~