三次握手的入口函数是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 的强校验逻辑。
