为什么 TIME_WAIT 状态的 TCP 连接,收到 SYN 报文后,可以正常建立连接?

x33g5p2x  于2022-04-23 转载在 其他  
字(3.1k)|赞(0)|评价(0)|浏览(179)

大家好,我是小林。

昨天群里有个读者问了一个很有意思的问题,他抓到一个抓包图,客户端和服务端四次挥手后,客户端在 17 秒内又复用了与上一次连接相同的端口,向服务端发起了 SYN 报文, 并成功建立了连接。

他觉得服务端应该还是处于 TIME_WAIT 状态(因为 Linux 操作系统中,2MSL 的时间是 60 秒,也就是 TIME_WAIT 状态的持续时间),为什么收到客户端的 SYN 报文后可以正常建立连接?

抓包图手机端不好看,为了方便大家看,我画了一个图:

简单来说,这个问题就是,为什么处于 TIME_WAIT 状态的 TCP 连接,收到相同四元组的 SYN 报文后,可以正常建立连接。

可能有人问,这个问题小林不是写过吗?对的,我之前是写过一篇:处于 TIME_WAIT 状态的连接,收到相同四元组的 SYN 后会发生什么?

当时文章给出的结论是:

  • 如果 SYN 报文的「序列号+时间戳」都是合法的话,就会重新建立连接;
  • 如果 SYN 报文的「序列号+时间戳」其中一个不合法的话,就会回 RST。

这位读者也看了这篇文章的,他觉得他抓包图中客户端的 SYN 报文的序列号是不合法的,所以应该是回 RST 才对,但是现象却是是可以正常建立连接。

到这,我开始慌了,难道,我之前的文章写错了?难道处于 TIME_WAIT 状态的连接,只要收到 SYN 报文,不管合不合法,都会重新建立连接?

我先不着急说结论,我先带大家分析一波,从这个抓包图的信息,分析内核有没有走 TIME_WAIT 状态收到 SYN 报文后,重新建立连接的逻辑。

分析一波内核源码

在 Linux 内核中,处于 TIME_WAIT 状态的连接,收到 SYN 报文后,有这么一个逻辑:

大概就是,如果报文是 SYN 包,时间戳+序列号都是合法的,那么就会允许在 TIME_WAIT 状态下重新建立连接。

抓包图中的客户端是在 17 秒后重用端口发起 SYN 报文的,所以时间戳肯定相比于历史连接是递增的,所以时间戳是合法的。

接下来,我们重点分析 SYN 报文中的序列号是否合法的。

首先,内核是这样判断的:

//如果after函数返回 1, 则说明合法,否则不合法
after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt)

如果after函数返回 1, 则说明收到报文的序列号是合法的,否则不合法。after 函数的参数分别表示:

  • TCP_SKB_CB(skb)->seq,这个是 SYN 报文的序列号;
  • tcptw->tw_rcv_nxt,这个是 TIME_WAIT 状态期望下一次收到的序列号,其实也就是第四次挥手中 ACK 报文中的 ack num 值。

根据抓包图,我们可以得出,TCP_SKB_CB(skb)->seq = 3145977016tcptw->tw_rcv_nxt = 40088018880

after 这个函数实现很短,我贴出来给大家看:

static inline bool before(unsigned int  seq1, unsigned int seq2)
{
        return (int)(seq1-seq2) < 0;
 }
#define after(seq2, seq1)   before(seq1, seq2)

然后,我写了个代码来验证 after 函数返回的值是什么:

可以发现,after 函数返回的是 0 ,说明抓包图中 SYN 报文的序列号是不合法的,所以根本就没有进入到 TIME_WAIT 状态重建连接的逻辑

还有一个角度可以证明,此抓包图没有中 TIME_WAIT 状态重建连接的逻辑。

因为当 TIME_WAIT 状态允许重建连接时,服务端第二次握手的初始序列号是这样计算的 tcptw->tw_snd_nxt + 65535 + 2,其中 tw_snd_nxt 表示服务端 TIME_WAIT 状态下最后一个发出报文的序列号。

根据抓包图,可以得出 tw_snd_nxt 是 1082535342。

如果走了TIME_WAIT 状态重建连接的逻辑,那么服务端的第二次握手中的序列号应该是 1082535342+ 65535 + 2,而抓包图中显示的服务端第二次握手的序列号为 2175872083这两个值并不相同,所以从这个角度,也可以证明,此抓包图没有中 TIME_WAIT 状态重建连接的逻辑

当时,我也在群里说了这个结论。

被我分析出来了

经过上面的分析,如果服务端还是处于 TIME_WAIT 状态的话,那么收到不合法的 SYN 报文,肯定是回 RST 的,这一点不用怀疑。

所以,我开始考虑是不是因为服务端开启了某些 TCP 内核参数,导致 TIME_WAIT 状态的连接被快速回收了,从而使得客户端后面发起的 SYN 报文,可以正常建立连接。

这里先跟大家说下,有哪些 TCP 内核参数会导致 TIME_WAIT 状态被快速回收:

  • 参数一:net.ipv4.tcp_tw_reuse,如果开启该选项的话,客户端(连接发起方) 在调用 connect() 函数时,内核会随机找一个 TIME_WAIT 状态超过 1 秒的连接给新的连接复用,所以该选项只适用于连接发起方。
  • 参数二:net.ipv4.tcp_tw_recycle,如果开启该选项的话,允许处于 TIME_WAIT 状态的连接被快速回收。

从抓包图可以看出,服务端主动发起的 FIN 报文,所以是服务端处于 TIME_WAIT 状态,所以 tcp_tw_reuse 这个参数不会是导致 TIME_WAIT 状态被快速回收的原因,因为这个参数是用于连接发起方,也就是客户端处于 TIME_WAIT 状态,在发起连接的时候,可以复用 TIME_WAIT 状态。

所以,排除参数一的可能性。

我当时就怀疑是因为服务端开启了 tcp_tw_recycle 参数,导致服务端的 TIME_WAIT 状态被快速回收了,并没有经过完整的 2MSL (60秒)时长的 TIME_WAIT 状态。

所以, 我就让读者去确认下,服务端是否开启了 tcp_tw_recycle 参数。

好家伙,经过读者的确认后,发现服务端真的开启了 tcp_tw_recycle 参数。

那么抓包图的现象就可以很好解释了,就是因为服务端开启了 tcp_tw_recycle 这个参数,导致服务端的 TIME_WAIT 状态被快速回收了,可能经过不到几秒,服务端就进入到 CLOSED 状态了。然后,17 秒后客户端发起的相同四元组的 SYN 报文,就正常建立连接了,因为服务端并没有处于 TIME_WAIT 状态

总结

最后总结下,我的分析思路。

通过抓包图的序列号信息,确认客户端发起的 SYN 报文的序列号是不合法的,所以如果服务端还是处于 TIME_WAIT 状态的话, 收到这个不合法的 SYN 报文,应该是回 RST 的,而抓包图的现象却是正常建立了连接。所以从这个分析中,我确认了服务端的 TIME_WAIT 状态可能是被快速回收了。

然后,想到了 Linux 两个快速回收 TIME_WAIT 状态的参数 tcp_tw_reuse 和 tcp_tw_recycle,其中 tcp_tw_reuse 参数是用于连接放起方,而本次的案例 TIME_WAIT 状态是在服务端,而不是客户端,所以可以排除这个参数的可能性。

于是,就让读者确认是否开启了 tcp_tw_recycle 参数,因为开启了这个参数后,不管是服务端还是客户端,处于 TIME_WAIT 状态的连接,都会被快速回收,然后 TCP 连接就会进入到 CLOSE 状态。

最终,经过读者确认后,发现服务端确实开启 tcp_tw_recycle 参数。

不过,tcp_tw_recycle 状态还是不建议大家开启的,因为在 NAT 的网络下是不安全的,在 Linux 4.12 版本后,直接取消了这一参数。

通过这次的分析案例,大家是不是体验到了「八股文」
的力量,就从一个抓包图的现象,就能分析出是什么导致的。

怎么样,这一波分析,是不是很强

相关文章

微信公众号

最新文章

更多