Mastering TCP Connection States and Linux Backlog Tuning
This article explains all TCP connection states, the three‑way handshake and four‑way termination, details half‑open and full‑open queues, shows how to monitor and troubleshoot listen and accept queue overflows, and lists key Linux kernel parameters for optimizing TCP performance.
Network Connection States
Network connection states (11 types) are crucial, covering both the three‑way handshake and the four‑way termination.
LISTEN Passive open; the server creates a socket, binds, listens and blocks on accept().
SYN_SENT Active open; the client calls connect(), sends a SYN and waits for SYN+ACK.
SYN_RECV Server receives SYN, replies with SYN+ACK, and waits for the client’s ACK; the SYN queue length is controlled by tcp_max_syn_backlog.
ESTABLISHED Both sides have exchanged SYN, SYN+ACK and ACK; data transfer can begin.
FIN_WAIT1 Active close; initiator sends FIN and waits for the remote ACK.
CLOSE_WAIT Passive close; receives FIN, sends ACK, and waits for the application to close.
FIN_WAIT2 After ACK, waits for the remote FIN.
LAST_ACK Passive close sends FIN+ACK and waits for the final ACK.
TIME_WAIT Ensures the remote ACK is received; lasts 2 MSL before moving to CLOSED.
CLOSING Rare state, waiting for remote confirmation of connection termination.
CLOSED Connection fully terminated.
Three‑Way Handshake
The client sends SYN, the server replies SYN+ACK, and the client sends ACK; after this both sides enter ESTABLISHED.
The handshake also negotiates options such as MSS (maximum segment size) and SACK (selective acknowledgment) to improve transmission efficiency.
Half‑Open and Full‑Open Queues
The unfinished‑connection queue (SYN queue) holds incoming SYNs until the handshake completes; its size is set by net.ipv4.tcp_max_syn_backlog (default 2048). cat /proc/sys/net/ipv4/tcp_max_syn_backlog The completed‑connection queue (accept queue) holds ESTABLISHED sockets waiting for accept(); its size is controlled by net.core.somaxconn (default 128) and the backlog argument passed to listen(). net.core.somaxconn = 128 Common problems include listen‑queue overflow and SYN flood attacks. Use netstat to monitor: netstat -s | egrep "listen|LISTEN" If the accept queue is full, the kernel can be configured to send RST packets:
echo '1' > /proc/sys/net/ipv4/tcp_abort_on_overflowss Command: Recv‑Q and Send‑Q
In LISTEN state, Recv‑Q shows current accept‑queue usage, while Send‑Q shows the maximum backlog size.
In non‑LISTEN states, Recv‑Q indicates bytes received but not yet read by the application, and Send‑Q indicates bytes pending acknowledgment.
netstat -n | awk '/^tcp/ {++S[$NF]} END {for (a in S) print a, S[a]}'Key Linux TCP/IP Kernel Parameters
tcp_abort_on_overflow (default 0): action when the accept queue is full; set to 1 to send RST.
net.core.netdev_max_backlog (default 128): max packets queued per NIC when kernel processing lags.
net.ipv4.tcp_max_orphans : max number of orphaned sockets.
net.ipv4.tcp_max_syn_backlog : max half‑open connections.
net.core.somaxconn : max length of the accept queue (default 128).
net.ipv4.tcp_timestamps : enable/disable TCP timestamps.
net.ipv4.tcp_synack_retries : number of SYN+ACK retries before giving up.
net.ipv4.tcp_syn_retries : number of SYN retries.
net.ipv4.tcp_syncookies : enable SYN‑cookie protection against SYN flood.
net.ipv4.tcp_tw_reuse and net.ipv4.tcp_tw_recycle : reuse and recycle TIME_WAIT sockets.
net.ipv4.tcp_fin_timeout : timeout for FIN_WAIT2.
net.ipv4.tcp_keepalive_time : interval for keepalive probes (default 2 h).
net.ipv4.ip_local_port_range : range of local ports (default 1024‑65000).
net.ipv4.tcp_max_tw_buckets : max number of TIME_WAIT sockets.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Raymond Ops
Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
