sendfile断连后缓冲区不立即回收，因内核零拷贝路径中skb仍持有page cache引用，需等待ACK确认或socket销毁才释放；可通过Nginx日志、ss命令及内核指标定位，缓解措施包括禁用sendfile、调优TCP参数等。
当客户端在 sendfile 传输过程中断开连接（如主动关闭 TCP 连接、网络中断、浏览器取消请求），Nginx 本身无法立即感知该断开，内核的 socket 发送缓冲区（sk->sk_write_queue）和 page cache 引用可能不会被即时释放，导致内存延迟回收、连接 hang 住或 netstat -s | grep "segments retransmited" 异常升高。这不是 Nginx 配置错误，而是 Linux 内核 sendfile() 路径下资源生命周期管理的固有特性。
为什么 sendfile 断连后缓冲区不立刻回收？
sendfile 是零拷贝路径：Nginx 调用 sendfile(2) 后，内核直接从文件 page cache 构造 TCP 报文，数据不经过用户态；此时 socket 的发送队列中存放的是指向 page cache 的 struct sk_buff + page_frag 或 skb_shinfo 引用。若客户端中途断连：
- TCP 层检测到 FIN/RST 后会标记连接为
CLOSE_WAIT或TIME_WAIT，但已入队的 skb 仍持有 page 引用； - 内核需等待这些 skb 被确认（ACK）、超时重传失败或 socket 彻底销毁，才会调用
__skb_frag_unref()和put_page()； - 若连接长时间卡在
CLOSE_WAIT（如对端未发 FIN），page cache 引用将持续存在，/proc/meminfo中PageTables或SlabReclaimable可能异常偏高。
如何确认是否由 sendfile 断连引起缓冲区滞留？
结合内核观测与 Nginx 日志交叉验证：
- 检查 Nginx error log 是否高频出现
client prematurely closed connection或Broken pipe； - 运行
ss -i state close-wait查看是否存在大量CLOSE_WAIT连接，配合ss -i输出中的retrans、qsize（发送队列字节数）字段； - 用
cat /proc/net/snmp | grep TcpExt | grep -E "(DelayedACKs|ListenOverflows|SynRetrans)"排除其他干扰； - 启用内核 ftrace 跟踪
tcp_sendmsg和tcp_clean_rtx_queue，观察 skb 释放时机（需调试环境）。
缓解策略：平衡性能与健壮性
完全避免不可能，但可通过以下方式降低影响：
-
禁用 sendfile（小文件/高断连场景）：在 location 块中设
sendfile off;，改用read()+write()，使 Nginx 主动控制读写生命周期，断连时可立即清理 buffer； -
启用 tcp_nopush & tcp_nodelay：
tcp_nopush on;配合sendfile可减少小包堆积；tcp_nodelay on;加速 FIN/RST 响应，缩短连接残留时间； -
调优 TCP 回收参数：减小
/proc/sys/net/ipv4/tcp_fin_timeout（默认 60s），加快FIN_WAIT_2和CLOSE_WAIT状态超时；启用net.ipv4.tcp_tw_reuse = 1（仅客户端场景有效）； -
限制大文件传输的 keepalive：对静态资源 location 设置
keepalive_timeout 5s;，避免长连接滞留 page cache 引用。
内核级深度排查建议
若问题集中于特定内核版本（如 4.19–5.4），可能存在已知缺陷：
- 检查是否启用了
CONFIG_TCP_CONG_BBR或fq_pie等新调度器，某些组合下sendfileskb 清理逻辑异常； - 比对
git log --oneline v5.4..v5.10 net/core/skbuff.c，关注skb_drop_list、skb_free_head相关提交； - 使用
bpftrace监控tcp_cleanup_rbuf和__page_cache_release调用频次，确认 page 释放是否滞后于连接关闭。
