Linux TCP 三次握手在内核中的执行过程

三次握手的入口函数是tcp_v4_conn_request，负责SYN校验与半连接队列管理；tcp_rcv_state_process处理ACK并移入全连接队列；accept()仅消费已建立连接。

三次握手的入口函数是 tcp_v4_conn_request

当 SYN 报文到达，且 socket 处于 LISTEN 状态时，内核会调用 tcp_v4_conn_request（IPv4 场景）启动握手流程。这个函数不直接发送 SYN+ACK，而是先做合法性校验：检查源端口非 0、SYN 标志位是否置位、是否超过半连接队列上限（net.ipv4.tcp_max_syn_backlog）、是否触发 syncookie 机制等。

常见错误现象包括：客户端收不到 SYN+ACK，但服务端 netstat -s | grep "SYNs to LISTEN sockets" 计数持续增长——这往往说明半连接队列已满，后续 SYN 被丢弃，而非进入队列。

• 若启用了 syncookie（net.ipv4.tcp_syncookies = 1），即使队列满，也会动态生成 cookie 并发回 SYN+ACK，避免丢包；但此时不分配 Struct sock，直到收到第三次 ACK 才真正创建连接
• 未启用 syncookie 时，队列满会导致 TCPDropReq 计数上升，且不会给客户端任何响应
• tcp_v4_conn_request 返回 0 表示成功入队（或 syncookie 发送成功），返回负值则直接丢包

tcp_rcv_state_process 处理 SYN+ACK 和 ACK

客户端收到 SYN+ACK 后发送 ACK，服务端在 tcp_rcv_state_process 中处理该报文。此时连接仍处于 TCP_SYN_RECV 状态，该函数会检查 ACK 序号是否匹配（即是否等于自己发出去的 ISN + 1），并验证时间戳、SACK 等选项。

关键点在于：只有通过所有校验，内核才会将连接从半连接队列（inet_ehash_bucket 中的 syn_table）移到全连接队列（sk->sk_receive_queue 对应的 accept 队列），并将 socket 状态改为 TCP_ESTABLISHED。

• 若 ACK 序号错误或时间戳校验失败（如 net.ipv4.tcp_timestamps = 1 且对端时间戳回绕异常），该 ACK 会被静默丢弃，连接卡在 TCP_SYN_RECV
• 全连接队列长度由 listen() 的 backlog 参数和 net.core.somaxconn 共同限制，超限后新 ACK 不入队，也不发 RST
• 客户端若迟迟没发 ACK（比如网络延迟或丢包），服务端靠 tcp_synack_retries 控制重传次数，默认 5 次，对应约 3 分钟后超时释放临时结构

accept() 系统调用只从全连接队列取 sock，不参与握手

accept() 是用户态行为，它不触发、不等待、也不校验三次握手过程。它只是从内核维护的全连接队列中取出一个已处于 TCP_ESTABLISHED 状态的 struct sock，复制一份给用户进程，并返回新的 fd。

所以即使握手已完成，只要全连接队列为空（比如服务端处理太慢、accept() 调用不及时），新连接就一直卡在队列里，表现为客户端 connect() 已返回但服务端还没调用 accept() —— 此时连接状态在服务端是 ESTABLISHED，但尚未被应用感知。

• 可通过 ss -lnt 查看 Recv-Q 列：非 0 表示全连接队列有积压
• 若 Recv-Q 持续 > 0，说明应用 accept 速度跟不上连接建立速度，可能需优化事件循环或增加 worker 数量
• 注意：netstat -s 中的 "times the listen queue of a socket overflowed" 计数上升，说明曾有连接因全连接队列满而被丢弃（此时内核会发 RST 给客户端）

抓包看到 SYN+ACK 但连接不成立？重点查半连接队列和 cookie 状态

wireshark 显示服务端发了 SYN+ACK，但客户端 connect() 失败或超时，大概率不是网络问题，而是服务端没收到第三次 ACK 或拒绝了它。这时不能只盯发送路径，要结合内核参数和统计确认实际执行分支。

• 运行 cat /proc/net/netstat | grep -i "Syncookies"：若 SyncookiesSent 值增长，说明走的是 syncookie 路径，此时第三次 ACK 必须携带正确 cookie，否则被丢弃且无日志
• 检查 net.ipv4.tcp_abort_on_overflow = 0（默认值）：为 0 时，全连接队列满只会丢 ACK；设为 1 则对新 ACK 直接发 RST，客户端立刻报 Connection refused
• 用 tcpdump -nni any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' and port XXX 对比服务端收包和发包时间差，可判断是否在 tcp_v4_conn_request 阶段就被过滤

整个握手过程没有“原子性”保障：每个报文都可能被中间设备丢弃、被防火墙拦截、或在内核不同阶段因参数/资源限制被静默丢弃。最易被忽略的是半连接队列与全连接队列的双重限制，以及 syncookie 开启后对第三次 ACK 的强校验逻辑。