1

作者:鲍凤其

爱可生 dble 团队开发成员,主要负责 dble 需求开发,故障排查和社区问题解答。少说废话,放码过来。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


背景

在稳定性环境中,当 dble 初始化后端连接池后,后端连接池会出现连接计数器(totalConnections)和实际连接(allConnections)数量不符合的情况,理论情况下两个变量会保持最终一致性。

后续通过查阅网上相关文档,找到了相关文档:https://mp.weixin.qq.com/s/FE... ,详细分析过程可参考此文章。

简单来说,在 dble 初始化后端连接池的过程中,瞬时创建的连接数量可能过大,导致部分 TCP 连接握手时触发了 TCP 的 syn_cookie 机制并且第三次 TCP 握手的 ACK 报文丢失了,从而导致了上述的情况。

后续,在稳定性环境中将 TCP 的 syn_cookie 关闭之后暂时解决了此种情况。

但假设正常 TCP 三次握手出现如下三种异常情况:

  • TCP 第一次握手包 SYN 丢包了
  • TCP 第二次握手包 SYN、ACK 丢包了
  • TCP 第三次握手包 ACK 包丢了

客户端和服务端是如何处理的,如果重传,重传多少次?每次间隔时长多少?

实验环境

在一台服务器上启动 MySQL 服务,端口是3306,IP地址:10.186.60.69

在一台服务器上使用 MySQL client 连接 MySQL 服务,IP地址:10.186.60.60

第一种场景

TCP 第一次握手包 SYN 报文丢包了,会发生什么?

在 MySQL 服务器上执行,通过 iptables 阻断客户端的发送过来的所有TCP报文:

$ iptables -i eth0 -A INPUT -p tcp --dport 3306 -j DROP

在 MySQL 服务器上开始抓包:

$ tcpdump -i eth0 tcp and port 3306 -w tcp_syn_timeout.cap

通过 MySQL client 连接 MySQL 服务端,过了一分多钟后,客户端返回报错,此时停止抓包,如下图:

$ mysql -h10.186.60.69 -uroot -p123456 -P3306
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can't connect to MySQL server on '10.186.60.69' (110)

wireshark 分析抓包文件:

客户端在收不到 TCP SYN 报文的 ACK 报文后,会不断进行重试,示例中会进行六次重试并且每次 RTO 是不同的:

  • 第一次是1秒后重试
  • 第二次是3秒后重试,和第一次相差 2s 左右
  • 第三次是7秒后重试,和第二次相差 4s 左右
  • 第四次是15秒后重试,和第三次相差 8s 左右
  • 第五次是31秒后重试,和第四次相差 16s 左右
  • 第六次是65秒后重试,和第五次相差 32s 左右

每次超时时间 RTO 是指数上涨的。另外,这里的重试次数可以配置,由客户端机器的如下内核参数指定:

$ cat /proc/sys/net/ipv4/tcp_syn_retries
6 
 
# 不同的发行版本,参数可能不同
$ uname -a
Linux ubuntu 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

可以尝试修改此参数看看效果:

$ echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

因此:

TCP 第一次握手包 SYN 报文丢包了,会发生什么?

客户端会重传 SYN 报文,直到收到 ACK 或者达到最大次数,每次重试的时间是翻倍上涨的。

第二种场景

TCP 第二次握手的 SYN + ACK 报文丢包了,会发生什么?

为了模拟 SYN + ACK 的丢包情形,在客户端设置防火墙,将MySQL服务端的报文全部拦截:

$ iptables -A INPUT -p tcp -s 10.186.60.69 -j DROP

在 MySQL 服务器端抓包:

$ tcpdump -i eth0 tcp and port 3306 -w tcp_syn_ack_timeout.cap

在 wireshark Statistics下面 flow graph 功能分析 tcp 流:

从上图来看,可以分为两个视角:

客户端视角:客户端发出 SYN 报文之后,由于设置了防火墙,没有收到 SYN + ACK 报文,因此,客户端会不断进行重试,直到收到 SYN + ACK 或者达到最大重试次数

服务器视角:服务器端在收到 SYN 报文之后,发送SYN + ACK 报文,但是收不到最后一次握手的 ACK 报文,因此服务器端会不断进行重试发送SYN + ACK 报文。

客户端超时重传的 SYN 包抵达了服务端后,服务端然后回了 SYN、ACK 包,但是 SYN、ACK 包的重传定时器并没有被重置,仍然持续在重传。

从图中可以看出,服务端在收到第三次的 SYN 报文并发出的 SYN + ACK 报文之后,后面重试了四次,将之前重试的一次也算在内。

这个重试次数也由内核参数控制:

$ cat /proc/sys/net/ipv4/tcp_synack_retries
5

将客户端内核参数 tcp_synack_retries 设置成 1 之后,TCP 交互图:

这样重试次数就更加明显了。

第三种场景

TCP 第三次握手的 ACK 丢包了

在 MySQL 服务器端设置防火墙,拦截 TCP 第三次握手的 ACK 报文:

$ iptables -A INPUT -p tcp --tcp-flag ack ack --dport 3306 -j DROP

在 MySQL 服务器端抓包:

$ tcpdump -i eth0 tcp and port 3306 -w tcp_3th_ack_timeout.cap

分析抓包文件:

从上图来看,可以分为两个视角:

客户端视角:对于客户端来说,其实连接已经建立好了

通过 netstat 命令查看连接的状态:

$ netstat -napt|grep 3306
tcp 0 0 10.186.60.60:42490 10.186.60.69:3306 ESTABLISHED 14391/mysql

此时连接的状态是 ESTABLISHED 状态。

服务器视角:由于没有收到第三次的 ACK 报文,和第二种场景类似,服务器会一直重新发送 SYN + ACK 报文,直到达到最大次数

在重试期间,服务端连接的状态一直处于 SYN_RECV 状态:

$ netstat -napt|grep 3306
tcp        0      0 10.186.60.69:3306       10.186.60.60:42868      SYN_RECV    -

过了半分钟左右,也就是服务器端达到重试次数之后,服务端刚才处于 SYN_RECV 的状态的 TCP 连接不见了。

可是此时客户端的连接却依然存在。

客户端的连接之后怎么处理?

此时分场景讨论:

一种场景是,客户端在 TCP 连接建立完成之后,直接发送数据。

另一个种场景是,客户端没有任何操作。下面对这两种情况进行讨论。

客户端发送数据

为了模拟这种场景,我们预先通过客户端连接 MySQL 服务器。

连接上之后在 MySQL 服务器端通过防火墙隔离客户端的报文:

$ iptables -A INPUT -p tcp -s 10.186.60.60 -j DROP

在 MySQL 服务端进行抓包:

$ tcpdump -i eth0 tcp and port 3306 -w tcp_data.cap

之后通过刚才建立的连接,下发 use test ; 语句。

下面分析一下抓包文件:

分析:

我们发现客户端一共重传了十一次。

TCP 建立连接后的数据包传输,最大超时重传次数是由 tcp_retries2 指定,默认值是 15 次,这里为了便于观测,将数值调整成了 10 次,如下:

$ cat /proc/sys/net/ipv4/tcp_retries2
10

可是这里的抓包文件中传输了十一次报文,这里参考文章:https://perthcharles.github.i...

无任何操作

在 MySQL 的协议中,TCP 建立完成之后,MySQL 服务端会发送握手包,由于 MySQL 服务端连接已经不在,因此不会下发握手包,客户端会一直 hang 住。

$ mysql -h10.186.60.69 -uroot -p123456 -P3306
mysql: [Warning] Using a password on the command line interface can be insecure.

此时客户端连接的存活由 TCP 的保活机制确保。

keep-alive 机制:

  1. 首先,有个前提:在特定的时间段内,连接如果没有任何动作,TCP 保活机制会开始作用。
  2. 保活机制会每过一个固定时间发送一个「探测报文」,如果连续几个探测报文都没有得到响应,则认为该 TCP 连接已经死亡,系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔,以下都为默认值:

$ sysctl -a|grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
  
# 也可以通过下面的方式来查看:
$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl
$ cat /proc/sys/net/ipv4/tcp_keepalive_probes
$ cat /proc/sys/net/ipv4/tcp_keepalive_time

参数解释:

  • tcp_keepalive_intvl=75:表示每次检测间隔 75 秒;
  • tcp_keepalive_probes=9:表示检测 9 次无响应,认为对方是不可达的,从而中断本次的连接。
  • tcp_keepalive_time=7200:表示保活时间是 7200 秒(2小时),也就 2 小时内如果没有任何连接相关的活 动,则会启动保活机制

我们可以修改参数看下效果:

$ echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl
$ echo 40 > /proc/sys/net/ipv4/tcp_keepalive_time
$ echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes

通过抓包文件查看:

可以看到在 40s 时候,开始探活包,探测了两次,每次间隔 10s 中,符合参数修改的定义

修改参数之后,client 过了大约一分钟后,就报错了:

$ mysql -h10.186.60.69 -uroot -p123456 -P3306
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 110

爱可生开源社区
423 声望206 粉丝

成立于 2017 年,以开源高质量的运维工具、日常分享技术干货内容、持续的全国性的社区活动为社区己任;目前开源的产品有:SQL审核工具 SQLE,分布式中间件 DBLE、数据传输组件DTLE。


引用和评论

0 条评论