社区编辑申请
注册/登录
可恶,又被小林装到了!
网络 无线技术
通过抓包图的序列号信息,确认客户端发起的 SYN 报文的序列号是不合法的,所以如果服务端还是处于 TIME_WAIT 状态的话, 收到这个不合法的 SYN 报文,应该是回 RST 的,而抓包图的现象却是正常建立了连接。

大家好,我是小林。

前几天群里有个读者问了一个很有意思的问题。

他抓到一个抓包图,客户端和服务端四次挥手后,客户端在 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 值。

根据抓包图,我们可以得出,seq = 3145977016,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 版本后,直接取消了这一参数。

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

怎么样,这一波被我装到了!

责任编辑:赵宁宁 来源: 小林coding
相关推荐

2022-06-04 14:43:31

Windows 10出厂设置重装

2022-06-15 17:55:43

IE浏览器Windows微软

2022-06-16 11:01:22

数据库SQL

2022-05-24 15:55:37

避障小车华为

2022-06-06 14:08:52

开发者GitHubPR

2022-05-19 11:33:32

数字化

2022-05-13 15:35:10

VR/AR元宇宙Meta

2022-05-24 12:42:24

物联网

2022-06-01 16:54:05

区块链区块链技术医药冷链物流

2022-05-06 07:52:06

Nacos服务注册

2022-03-16 10:14:55

C语言C++

2022-02-11 13:49:42

2022-03-29 09:21:21

DevOps开发

2022-03-27 23:59:11

网络安全美国网络窃密

2022-03-09 15:34:03

物联网老年人

2021-12-15 15:28:18

2021-12-08 15:09:26

2016-12-21 17:38:59

系统

2018-11-15 10:04:02

机柜方法布线

2020-01-14 18:20:48

OA选型CIO

同话题下的热门内容

VXLAN 与 MPLS:从数据中心到城域以太网HTTP 新增的 103 状态码,这次终于派上用场了!谁家的加密密钥,写死在代码里?聊聊 TCP/IP 协议处理流程当“无线网”邂逅“零漫游”:锐捷植根行业场景出新招“稳赢”数智转型:锐捷发布场景化无线零漫游解决方案聊聊WiFi的前世与今生

编辑推荐

为什么WiFi信号满格,网速还是卡!WiFi信号强,网速却很慢?这样操作就能搞定!无线AP容量及网络带宽计算方法干货:手把手教你,解决WiFi干扰的难题Wi-Fi身份验证出现问题应该如何解决?
我收藏的内容
点赞
收藏

51CTO技术栈公众号