分布式 | 数据库连接如何正确处理 TCP 连接三次握手失败

爱可生开源社区

墨衍会员 · AI 创作全网分发码龄8年

关注

原创最新推荐文章于 2026-08-28 11:21:01 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

【网络编程】TCP 3次握手&4次挥手浅析大家都知道传输层中的TCP协议是面向连接的，提供可靠的连接服务，其中最出名的就是三次握手和四次挥手。阅读详情

作者：鲍凤其

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

本文来源：原创投稿

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

背景

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

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

简单来说，在 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.io/2015/09/07/wiki-tcp-retries/

无任何操作

在 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 机制：

首先，有个前提：在特定的时间段内，连接如果没有任何动作，TCP 保活机制会开始作用。
保活机制会每过一个固定时间发送一个「探测报文」，如果连续几个探测报文都没有得到响应，则认为该 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

收录于