Shadowsocks 高并发连接优化：TCP 参数与 epoll 深度调优

• 高并发下的瓶颈在哪里
• TCP 参数：为什么要关心它们
• TCP 连接建立和 SYN 队列
• TIME_WAIT 与端口资源
• 发送/接收缓冲区与窗口缩放
• epoll 深度与事件处理模型的影响
• 一次性批量处理与延迟
• 边沿触发（ET） vs 水平触发（LT）
• 系统级配套项：文件描述符与 accept 相关
• 实战场景：一次优化的思路地图
• 常用观测与诊断工具
• 权衡与风险
• 案例速览：从 2 万到 10 万并发的变更要点
• 面向未来的考虑

高并发下的瓶颈在哪里

在部署 Shadowsocks 或类似的 TCP 转发服务时，单台服务器很快就会遇到两个维度的瓶颈：操作系统内核层面的 TCP 状态与参数限制，以及事件通知与 I/O 调度层面的 epoll/线程模型限制。前者决定了连接建立、拆除、重用的效率，后者决定了并发连接的实际可处理吞吐与延迟表现。理解这两者的相互作用，是拿出稳定高并发表现的关键。

TCP 参数：为什么要关心它们

TCP 参数影响着 socket 的生命周期和内核对流量的处理能力。常见的痛点包括端口耗尽、TIME_WAIT 累积导致的连接无法快速重建、SYN 队列溢出，以及窗口/缓冲区设置不匹配引起的吞吐下降。下面按问题分块描述几个关键参数与背后的原理。

TCP 连接建立和 SYN 队列

当大量客户端同时发起新连接时，内核需要为每个 TCP 三次握手维护半连接队列（SYN queue）以及已完成但未被应用 accept 的已完成队列（accept queue）。两个相关参数决定队列长度，队列满会导致丢 SYN，从而出现重试与延迟。调优的方向是增大这些队列长度，同时让应用层尽可能快速 accept 连接。

TIME_WAIT 与端口资源

短连接场景（比如大量短时间代理连接）会产生大量处于 TIME_WAIT 的 4 元组。TIME_WAIT 会占用本地端口资源，对短时间内高频建立连接的场景非常不友好。可以通过缩短 TIME_WAIT 保存时间、允许重用端口、以及采用长连接或连接池策略来缓解。但需要注意并发安全和兼容性问题。

发送/接收缓冲区与窗口缩放

默认缓冲区在高带宽延迟乘积（BDP）网络下可能不足，导致未能填满链路，从而严重限制吞吐。增大 socket 发送/接收缓冲区和启用窗口缩放，可以提高单连接在高延迟线路下的带宽利用率。但如果缓冲区过大，在并发连接数巨大的情况下会占用过多内存，需综合权衡。

epoll 深度与事件处理模型的影响

epoll 本身是一个高效的事件分发机制，但它并不自动解决所有并发场景的问题。所谓“epoll 深度”可以从两个角度理解：一是 epoll_wait/epoll_pwait 每次返回的事件数量上限（最大事件数）；二是事件在应用层被处理的并发深度（并发 worker 数、accept 循环频率等）。

一次性批量处理与延迟

将 epoll_wait 的返回事件数设置得较大，有利于在单次调用中处理更多就绪 socket，减少系统调用开销。但过大的批量也会造成单次处理时间变长，增加响应尾延迟，并且可能导致 CPU 缓存/上下文切换效率降低。合适的策略是根据负载把批量大小调整到每个 worker 能够在可接受延迟内完成处理的规模。

边沿触发（ET） vs 水平触发（LT）

ET 模式下应用必须尽可能一次性把可读/可写的数据处理完，否则不会再次触发事件，适合非阻塞 I/O 和高并发场景，但实现复杂度高。LT 则更容错，但在大量就绪 socket 时可能频繁唤醒。搭配合理的循环与状态机设计，可以在 ET 下获得更高的吞吐。

系统级配套项：文件描述符与 accept 相关

高并发连入时，文件描述符（FD）上限、进程/线程的 ulimit、以及 accept 时的互斥问题（accept(2) 锁竞争）都直接影响可承载连接数。常见做法包括：提高进程 FD 上限、在多核服务器上采用 SO_REUSEPORT 分发负载、使用多 acceptor 线程或进程来减少单点竞争。

实战场景：一次优化的思路地图

假设你在一台 8 核、32GB 内存、几十 Gbps 带宽的服务器上运行 Shadowsocks，面临并发 10 万连接，连接模式多为短连接。可按以下思路逐步排查与调整：

• 观测指标：同时监控 TIME_WAIT 数量、SYN 重传与丢包率、Listen 队列长度、CPU 利用率、应用层 accept 延迟与处理 QPS。
• 接入优化：启用 SO_REUSEPORT（若程序支持），在多核上启动多个监听进程，减少 accept 锁。
• 内核队列：将半连接与已完成连接队列长度增大，避免 SYN 丢弃。配套调整 accept 循环让 accept 更及时。
• TIME_WAIT 缓解：缩短 TIME_WAIT 保存时间、允许端口重用（在确保安全的前提下），并尽量使用长连接或连接复用策略。
• 缓冲与窗口：根据带宽与 RTT 估算 BDP，适当增大发送/接收缓冲区和启用窗口缩放。
• epoll 调优：调整 epoll_wait 的最大事件数到每 worker 可处理的合适批量，优先使用边沿触发和非阻塞 I/O。
• 资源上界：提高 ulimit -n，使 FD 足够支持峰值连接数，避免因 FD 耗尽导致服务崩溃。

常用观测与诊断工具

没有可观测性就无法定位问题。常用工具包括：

• ss/netstat：查看 socket 状态分布、半连接队列与TIME_WAIT 数量。
• tcpdump/wireshark：观察 SYN/ACK 丢失、重传与 RTT。
• perf/iostat/top：定位 CPU、磁盘、系统调用瓶颈。
• eBPF 工具集：深入观测内核事件，如 accept 延迟、epoll_wait 调用热点。

权衡与风险

调大各类队列、缩短 TIME_WAIT、增加缓冲区都能短期提升并发能力，但也带来副作用：内存消耗增加、对异常连接的容忍度下降、以及某些内核参数在不同内核版本上行为差异（例如被弃用或具有安全隐患的参数）。因此必须在测试环境中做系统压力测试，并配合逐步放量到生产。

案例速览：从 2 万到 10 万并发的变更要点

在一次真实演练里，团队从 2 万并发提升到 10 万并发，关键动作包括：

• 把 listen backlog 和半连接队列扩大数倍，解决了大量 SYN 重试。
• 启用 SO_REUSEPORT，把单一 accept 线程的竞争分散到 8 个 worker。
• 调整 epoll 批量大小到 512（根据每个事件平均处理时间测试），减少系统调用且保证延迟。
• 将默认 socket 缓冲区扩大 2-4 倍，并启用窗口缩放，提升单连接吞吐。
• 把 TIME_WAIT 保持时间从几十秒缩短到合理区间，同时采用长连接与连接复用策略，端口复用率大幅提升。

结果是在峰值负载下丢包和重传显著下降，平均响应时间保持稳定，同时 CPU 利用率曲线更平滑。

面向未来的考虑

随着 QUIC/HTTP3 等基于 UDP 的协议兴起，很多短连接、高并发的代理场景会逐步迁移到用户态协议栈与多路复用方案，这会改变对内核 TCP 参数的依赖。但短期内 TCP 仍主导大量场景，理解并精细调优内核与 epoll 仍然是提升大型 Shadowsocks 部署性能的必备技能。

小结：要在高并发下稳定运行 Shadowsocks，需要同时从 TCP 参数、epoll 事件处理、应用架构与可观测性几方面入手。任何一次大幅调参都要配合压力测试与灰度发布，才能在提升并发能力的同时控制风险。