TCP_DEFER_ACCEPT 优化连接进入应用层时机，使内核延迟将仅完成三次握手而无数据的连接放入accept队列，直至首个数据包到达才通知worker；需在listen前设置，推荐seconds=3～5，仅Linux支持。
TCP_DEFER_ACCEPT 不是用来优化“非阻塞连接接收”本身，而是优化连接进入应用层的时机——它让内核把只完成三次握手、但尚未发送任何业务数据的连接拦在 accept 队列之外，直到第一个真实数据包抵达才通知 worker 进程。这对非阻塞 I/O（如 epoll + non-blocking socket）场景尤为有效，能直接减少无效系统调用和资源占用。
核心作用：跳过空连接的 accept 通知
在标准非阻塞服务模型中（例如基于 epoll_wait 的循环），即使 socket 是 non-blocking 的，只要三次握手完成，连接就会被放入 accept 队列，epoll_wait 就会返回该 listen fd 可读，worker 必须调用 accept() 获取新连接 fd，再注册到 epoll。但若客户端建连后迟迟不发数据（如 HTTP/1.1 keep-alive 空闲连接、移动端心跳保活、扫描器试探连接），这个流程就纯属空转：
- accept() 返回一个新 fd → 占用文件描述符
- 需调用 epoll_ctl(ADD) 注册该 fd → 多一次系统调用
- 该 fd 后续长期处于 EPOLLIN 就绪但 recv() 返回 0 或 EAGAIN → 白耗 epoll_wait 轮询和上下文切换
启用 TCP_DEFER_ACCEPT 后，这类连接压根不会进 accept 队列，epoll_wait 根本看不到它，自然跳过全部后续动作。
正确配置方式（Linux 限定）
必须在调用 listen() 之前，对监听 socket 设置选项：
- 使用 setsockopt(listen_fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, &seconds, sizeof(seconds))
- seconds 推荐设为 3～5：太小（如 1）可能导致弱网客户端重传未达即超时；太大则僵死连接滞留过久
- 同步调整内核参数 net.ipv4.tcp_synack_retries = 3（默认常为 5），确保重传次数与 DEFER 时间匹配，避免提前丢弃合法连接
- 注意：该选项仅作用于监听 socket，且不可跨平台（FreeBSD 用 SO_ACCEPTFILTER，Windows 无等效机制）
与非阻塞 I/O 的协同要点
开启后，accept() 调用行为发生本质变化：
- 每次 accept() 成功返回的 fd，一定已收到至少一个数据包，可立即调用 recv() 或 read()，大概率不会阻塞或返回 EAGAIN
- 不再需要为每个新连接做“先 accept、再等待数据”的两阶段处理，简化事件驱动逻辑
- epoll_wait 触发频次下降，worker 循环更“稠密”——每次就绪几乎都对应真实业务数据，吞吐更稳
- 仍需保持 socket 本身为 non-blocking 模式，因为单个连接后续的数据收发仍可能部分到达、需轮询
适用与慎用场景
适合高并发、低活跃度的典型 Web/HTTP 服务（Nginx、自研 HTTP server）、长连接网关；但以下情况不宜开启：
- 需要即时响应 connect() 的协议，如某些健康检查探针（发 SYN-ACK 就期望立刻收到 ACK 并确认存活）
- 客户端行为异常：极慢启动、ACK 延迟严重、或依赖“建连即触发服务端预热”的逻辑
- 调试或抓包分析阶段——它会让 tcpdump 看到 SYN_RECV 状态停留更久，可能干扰对连接建立时序的判断
