TCP Handshake Packet Loss Scenarios and Their Impact on MySQL Connections

Background In a stable environment, the Dble backend connection pool sometimes shows mismatched totalConnections and allConnections counts because a burst of connections can trigger TCP SYN‑cookie handling and loss of the third‑handshake ACK packet.

The author reproduces three TCP handshake loss scenarios using iptables to drop packets and captures traffic with tcpdump to analyze client and server retransmission behavior.

Experiment Environment

MySQL server runs on 10.186.60.69:3306; the client runs on 10.186.60.60.

Scenario 1 – SYN Packet Loss

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

After dropping SYN packets, the client retries six times with exponential back‑off (1 s, 3 s, 7 s, 15 s, 31 s, 65 s). The retry count is controlled by /proc/sys/net/ipv4/tcp_syn_retries , default 6.

cat /proc/sys/net/ipv4/tcp_syn_retries

Changing the value (e.g., echo 2 > /proc/sys/net/ipv4/tcp_syn_retries ) reduces the number of attempts.

Scenario 2 – SYN‑ACK Packet Loss

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

Both client and server keep retransmitting SYN or SYN‑ACK until the kernel limits are reached. The server side limit is /proc/sys/net/ipv4/tcp_synack_retries (default 5).

cat /proc/sys/net/ipv4/tcp_synack_retries

Scenario 3 – ACK Packet Loss (Third Handshake)

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

Even though the client sees the connection as ESTABLISHED , the server remains in SYN_RECV and repeatedly sends SYN‑ACK until the retry limit expires, after which the server side socket disappears while the client still holds the connection.

Data Transfer After Connection Established

When the client sends data after the handshake, the server may retransmit up to tcp_retries2 times (default 15). The experiment reduces this to 10 to observe eleven retransmissions.

cat /proc/sys/net/ipv4/tcp_retries2

No Further Activity – Keep‑Alive

If the client performs no operations, Linux keep‑alive probes eventually detect a dead peer. Default parameters are:

net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

Modifying them (e.g., setting interval to 10 s, probes to 2, time to 40 s) causes the client to report a lost connection after about a minute.

These experiments illustrate how TCP retransmission timers and kernel tunables influence MySQL connectivity under packet‑loss conditions.