从TCP到HTTP：BFF网关网络IO性能优化实战复盘

先还原一下这次优化的真实场景。我接手的是一个内部 BFF 网关，职责很单纯：接收移动端的 HTTP 请求，拼装后端数据，再返回 JSON。平时 QPS 在 2000 左右，CPU 30%，看起来一切正常。某次活动流量上来后，QPS 爬到 9000，最先崩的不是业务逻辑，而是网络 IO——客户端开始报连接超时、502、connection reset，机器上到处是 TIME_WAIT。第一反应是加机器，但加的机器过了一会儿又开始报同样的错。其实就是把同一个问题复制到了更多节点上。

从那时候开始，我花了几天时间把整个链路从 TCP 到 HTTP 一层层拆开，先后调整了连接生命周期、TCP 队列、应用层 IO 模型、HTTP 连接复用策略和响应体大小，最后单机吞吐量翻了近三倍，P99 延时从 400ms 级降到了 100ms 以内。这篇文章不是教科书式解释，是我把这些配置、命令、判断方法完整整理出来的一次实操复盘。合适给后端开发、运维、SRE，或者任何正在被“网络慢、连接多、服务假死”折磨的人当参考。

1. 优化前先明确边界：问题出在 TCP 还是 HTTP

1.1 现场监控里的几个反常信号

我先说当时看到的几个核心指标，因为优化网络 IO 最忌讳的是不先看现象就改内核参数。那台机器 CPU 只有 28% 到 35%，内存没满，磁盘也没压力，但系统的软中断占用明显偏高，负载在高峰期接近 12。用 ss -s 看连接统计，TIME_WAIT 大概有 2 万多个，同时 ESTABLISHED 也到了 1 万多，业务日志里大量上游读取超时。业务同学的第一反应是“线程池满了”，但线程数其实离上限还远，大部分线程阻塞在 socket 读上，所以真正的问题是连接处理和请求分发在 TCP/HTTP 两层都没有跑对。

遇到这种情况，我的经验是先分清两个方向。如果 CPU 已经打满、内存频繁 GC、业务代码有明显耗 CPU 逻辑，那可能先做代码级优化更值。但如果 CPU 明明有空闲、线程又在 wait、网络相关指标异常，那就应该优先怀疑网络 IO 路径。网络 IO 性能优化往往不需要一次性改多少个地方，找到一个堵点先打通，效果会非常明显。

1.2 TCP 层和 HTTP 层分别负责什么

TCP 层的职责可以通俗理解为“保证数据可靠地按顺序到达”。连接能不能建立、连接断了会不会重传、数据包会不会丢、滑动窗口给多少，这些都在 TCP 层处理。HTTP 层则是应用语义：一次 GET 代表什么、请求头和响应头怎么解析、body 用什么格式、连接能不能复用、客户端要不要重试。

所以排查问题时，我会把错误样本分类。连接失败、连接被重置、握手超时、大量重传，这些大概率要看 TCP 层或者与 TCP 直接相关的进程模型。如果连接明明建立了，但请求响应不对、返回慢、状态码不对，就要看 HTTP 层以及应用代码。拿当时最典型的 502 来说，那是个七层网关返回的，但导致它的根因往往在 TCP 层：比如后端连接的 accept 队列溢出，HTTP 请求还没被应用读到，连接就被内核断开。只看 HTTP 状态码会被带偏，需要往 TCP 层去找。

1.3 先定目标再动手

我给自己定的优化目标不是“哪哪都要调”，而是三条：连接建立阶段的错误率降下去、请求的长尾延时降下来、单机能扛住的 QPS 提上来。指标主要看 P99、accept 队列溢出数、TIME_WAIT 数量、网络重传率这些相对直接的指标。正因为目标清楚，后面改动带来的收益才能横向比较。否则今天改个 backlog，明天调个超时，数据完全对不上。

2. TCP 层优化：连接生命周期与队列是重点

2.1 三次握手不是免费午餐

TCP 建立连接需要三次握手。在优化之前，我看到客户端每次请求都新建一个 TCP 连接，这其实是最影响网络 IO 开销的行为之一。假设一个接口的业务处理只花 1ms，但 RTT 是 20ms，那么每次请求如果新建连接，握手阶段就先吃掉 20ms 左右，整体响应时间要么接近 21ms，要么并行并发时因为握手排队变得更夸张。如果还需要 TLS，那还要额外加一个 RTT，代价更明显。

同样的道理体现在连接关闭上。短连接请求结束后会进入四次挥手，主动关闭的一方还要进入 TIME_WAIT 状态，默认要停留 60 秒。一个高并发网关如果经过的都是短连接，每秒几千个请求就会同时制造几千个 TIME_WAIT 连接，虽然它们本身不占太多内存，但会让 ss 看着触目惊心，而且大量连接新建/关闭会显著增加内核软中断处理量和进程上下文切换。

2.2 让连接活得更久：keep-alive 和连接池

这个阶段的第一个优化动作就是让客户端和服务端之间的连接尽量复用。HTTP/1.1 默认开启 keep-alive，但在真实链路里，很多框架、网关、代码库会在某些条件下主动把连接关掉，尤其是每发一次请求就 new 一个 HttpClient 或者每写一段代码就手动 close socket，这样 keep-alive 就形同虚设。

以 Java 为例，我习惯把连接池显式配置出来，至少保证每个路由有固定数量的连接复用，而不是请求来了随手建一个。以 Go 为例，http.Transport 的关键参数大致是这样：

go复制transport := &http.Transport{
    MaxIdleConns:        200,
    MaxIdleConnsPerHost: 64,
    IdleConnTimeout:     90 * time.Second,
    MaxConnsPerHost:     0,
}

这里有几个经验值可以参考。MaxIdleConnsPerHost 不要太小，否则并发一高还是要重新建连接；IdleConnTimeout 设置过短会让空闲连接被过早回收，设置过长又会长时间占着 fd。如果是内网服务，90 秒到 180 秒之间比较常见。关键不在于参数本身，而在于连接池必须让同一目标主机的连接可以复用，避免每次请求都完整走一次 TCP 握手和四次挥手。

2.3 小包场景下的 TCP_NODELAY 与 Nagle 算法

如果服务端经常要响应很小的报文，还有一类容易被忽略的问题：Nagle 算法和延迟 ACK 互相“打架”。Nagle 算法会把多个小包攒起来一起发，避免网络里塞满小包；但另一个方向的延迟 ACK 会故意等一会儿再回 ACK。两端如果同时生效，会出现一个数据包发出后迟迟等不到 ACK，于是剩下的数据也迟迟不发的现象，最坏情况下能卡出几十毫秒。

在我的服务里，HTTP 请求响应大多是小于 MTU 的小包，所以我会在 socket 层面关闭 Nagle 算法，也就是开启 TCP_NODELAY。Java 里是 setTcpNoDelay(true)，Nginx 里可以设置 tcp_nodelay on;，Go 的默认网络库对 TCP 连接也会默认启用 TCP_NODELAY。如果你自己封装 socket 或者用某个底层库，需要确认这个选项没被关掉。

延迟 ACK 也可以在某些 Linux 版本里通过修改 tcp_delack_min 的间隔来降低，但这属于影响面比较广的调优，我一般不在生产环境全局修改，而是优先确保业务不是频繁地“一问一答”式小包往返。TCP_NODELAY 虽然不能直接扩大带宽，但能让会话式交互的延迟明显下降，尤其是那种后端之间同步调用、一次请求包含多次小数据往返的场景。

2.4 监听队列与 backlog：高并发下请求真正丢失的地方

很多时候，TCP 连接已经成功握手，但应用层还没调用 accept，这个连接会先放在内核的 accept 队列里。如果业务进程处理不过来，accept 队列溢出，就会出现从客户端角度看“明明 TCP 能连上，但发 HTTP 请求后没有响应”，或者直接被重置。当时我查这个问题时发现 ss -lnt 里 listen socket 的 Recv-Q 一直比较高，再用 netstat -s 能看到 listen queue overflow 的数量在持续增长。

对应调整方案有三步。

第一步，把应用监听队列调大。很多服务端框架允许 listen(port, backlog) 时自定义 backlog，底层库若不暴露就检查框架配置项。Nginx 里可以写：

nginx复制listen 80 backlog=2048;

内核还要同步把 somaxconn 提高，否则应用想申请更大的队列也会被内核上限卡住：

bash复制sysctl -w net.core.somaxconn=2048

持久化写入 /etc/sysctl.conf 后执行 sysctl -p。

第二步，提高进程文件描述符上限。1 万个连接如果按默认 1024 的 nofile 来算，连接还没到瓶颈进程先崩了。我在这个项目里把服务的 LimitNOFILE 或 /etc/security/limits.conf 里的 nofile 调到了 1048576，避免 file descriptor 不足引发的奇怪错误。

第三步才是业务层面要做的：让 accept 和 HTTP 处理解耦，别在 accept 之后做阻塞操作。否则就算队列调大，连接也是一个个堆在队列里得不到处理。

2.5 TIME_WAIT 怎么处理才不会踩坑

看到大量 TIME_WAIT 后，网上最常见的建议是开启 net.ipv4.tcp_tw_reuse 或者 tcp_tw_recycle，但我不建议在服务器上盲目开这两个参数。tcp_tw_recycle 因为 NAT 场景下会丢连接，新内核已经基本废弃；tcp_tw_reuse 只对发起连接的一端有意义，而且依赖时间戳选项，如果经过某些 NAT 设备或对端实现不标准，可能引入连接异常。真正的解决方向是不要产生那么多“短命连接”，优先用 keep-alive 和连接池把连接生命周期拉长。

如果发现 TIME_WAIT 还是很多，可以从另一个角度看：是不是服务端自己主动关闭了空闲连接。比如 Nginx 的 keepalive_timeout 设得太短，大量闲置 HTTP 连接到了就被服务端主动 FIN，服务端自然成了 TIME_WAIT 大户。所以配合超时参数的调整，TIME_WAIT 数量会自然降下来。最后还有一个不算调优但很实用的操作：如果本机作为主动发起方访问同一组外部端口时撞上了本地端口不够，可以扩大 net.ipv4.ip_local_port_range。注意这只是给新建连接腾更多端口空间，不能解决根本的连接复用问题。

3. 再往下一层：进程里的网络 IO 模型

3.1 一个连接一个线程为什么扛不住

TCP 层参数调完之后，吞吐量有一定提升，但再往上压测又出现了新的瓶颈。原因在于服务实例内部的 IO 模型还是传统的“一个连接一个线程”。假设一台机器有 4 核 CPU，但开了 500 个线程，每个线程都在等一个 socket 的 read 返回，CPU 大部分时间不是在算业务，而是在线程切换、内核态和用户态之间来回跳，同时线程各自持有的栈内存加起来也非常可观。

网络 IO 优化的一个核心事实是：等待网络事件不应该占用业务线程。现代操作系统提供了 epoll 这类事件通知机制，可以让进程把一批 socket 的读写事件交给内核监听，内核只在事件发生时通知用户态处理，这样线程就不需要阻塞在每个连接上干等。这个概念名字很多，叫 Reactor、Event Loop、NIO、异步 IO，底层思路差不多：真正阻塞等待的人越少，系统调度成本越低。

3.2 用 epoll 和事件循环时要注意的几个细节

如果是自己基于 epoll 写服务，不要把事件驱动做成“事件里做一切”。一个常见的反模式是：accept 到一个连接后，在同一个事件循环线程里直接做数据库查询或远程调用，导致这个线程阻塞，整个事件循环都跟着停顿。我见过有人在这个地方调一个 sleep(50ms) 模拟业务处理，结果单线程事件循环只能处理 20 QPS，其实问题不在事件循环原理，而在把阻塞操作放进了非阻塞路径。

正确做法是，accept 只负责把连接接进来，解析 HTTP 请求后把任务丢给业务线程池，由执行器处理真正可能阻塞的逻辑，处理完再把响应写回 socket。如果想追求极致，还可以把网络读写线程和业务线程分开，甚至再拆分出专门处理 I/O 读写事件的几个线程组。在大多数后端服务里，网络线程数按 CPU 核数或稍高一点配置就够了，业务线程池再按业务类型单独隔离，避免慢接口拖垮其他接口。

3.3 多进程与 SO_REUSEPORT：分摊队列压力

单进程事件循环在某些语言里受限于单核性能，即使开了很多 goroutine 或者虚拟线程，整体的系统调用还是会被集中到一个进程里。如果服务端恰好是独立的监听进程模式，可以考虑启用 SO_REUSEPORT，允许多个进程绑定同一个端口，让内核在新建连接时按哈希分发到不同进程。这样每个进程都有自己独立的 accept 队列和事件循环，竞争小很多。

Nginx 和一些高并发中间件都支持 SO_REUSEPORT。比如 Linux 下多个 worker 进程都 SO_REUSEPORT，连接请求不会挤在一个进程的队列里，整体 wait/lock 开销会更小。副作用是连接会被相对均匀地打散到各 worker，无法人为控制某个长连接始终落在同一个进程。这个功能可以依据业务场景决定，若服务是无状态的，收益大于代价。

4. HTTP 层优化：从请求模型到协议选择

4.1 HTTP keep-alive 只是开始，反向代理也要配好

很多人在应用代码里设置了 keep-alive，却漏了反向代理这一层。当时我们的链路是客户端到 Nginx，Nginx 再转发到后端服务。Nginx 默认对 upstream 的 HTTP 连接不会复用，如果不在配置里显式开启，Nginx 每次转发请求都和后端建立新 TCP 连接。这等于前面应用层连接池的努力全被 Nginx 绕过去了。

Nginx 的 upsteam keepalive 需要这样配置：

nginx复制upstream backend_app {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://backend_app;
    }
}

keepalive 32 表示 Nginx 会保留 32 个空闲的连接给后端，后续请求可以复用。proxy_set_header Connection "" 是把客户端的 Connection 头清空，避免告诉后端要关闭长连接。缺了这一步，即使 keepalive 配置了，效果也大打折扣。

4.2 HTTP/2 多路复用解决的是 HTTP 队头阻塞

HTTP/1.1 在同一个 TCP 连接上处理多个请求时，默认是串行的：前一个请求没返回，后一个请求只能等着。虽然浏览器会为同一个域名开多个 TCP 连接来提速，但服务端到服务端的同步调用不会那么积极。HTTP/2 提供了多路复用能力，在一条 TCP 连接上可以并发跑多个 stream，互不阻塞，这对减少连接数量、提高链路利用率非常明显。

不过我要提醒一句，HTTP/2 只解决了 HTTP 层面的队头阻塞。TCP 本身如果发生丢包重传，仍然可能影响后续所有 stream。所以更准确的理解是：启用 HTTP/2 后，来自应用层的并发能力更强，网络层的重传问题仍然要靠可靠的网络环境或 TCP 优化去处理。如果网关后面是多个后端微服务，可以考虑先在入口层启用 HTTP/2，让客户端到网关这一段减少连接数。内部服务之间如果都是同机房、低延迟、高可靠网络，HTTP/1.1 配合连接池就已经够用，不必为了追新技术把所有链路都切成 h2c。

4.3 响应体也要克制：序列化、压缩与去冗余

网络 IO 优化的范围不只是 socket 的收发，也包含 HTTP body 的生成和传输。给移动端返回一个大而全的 JSON 是最常见的隐性浪费。比如列表接口返回 3000 条数据，每条 1KB，整体就有 3MB，即使网络很快，移动端解析 JSON 也会一秒以上，这在弱网环境几乎是不可用的。所以我在优化时会把响应体瘦身当成“网络 IO 优化”的一部分。

序列化层面，优先检查是否对同一份 JSON 做了多次 string 拼接或重复序列化。前后端热词里经常提到 JSON.stringify 的性能，这其实不只是前端问题，服务端 JSON 序列化同样要走字符串分配、编码、转义这些开销。服务端常见的优化有两个：用可以追加到缓冲区的 JSON 库，避免产生巨大中间字符串；开启压缩层，比如 Nginx 的 gzip，对可压缩文本类 JSON 效果最好。如果接口只服务于内部系统，还可考虑用更紧凑的序列化格式替代 JSON，但团队接入成本偏高，我一般只在请求量极大的内部链路上才做。

网络传输的数据越少，TCP 需要发送的段数就越少，慢启动时间越短，HTTP 整体完成时间也越短。所以治理响应体时不要只看“返回数据大小”，要看它经过压缩、裁剪之后实际在线路上传输了多少字节。

4.4 移动端弱网下最有效的招数：减少请求次数

移动端场景还有一个特殊问题：移动网络下 RTT 和丢包率都比机房网络差很多，每次请求就算只花一毫秒处理，传输过程也可能要几十甚至几百毫秒。客户端如果把一个页面要用的详情接口拆成了 5 个不同 API 并发请求，这 5 个请求即便并发发出，移动端和服务器之前的无线链路调度也会让它们排队，结果页面加载很慢。

这种情况下，最有效的网络 IO 优化不是继续调 TCP 参数，而是从 API 设计上割掉不必要的往返。合并接口可以是一次性把列表数据、用户状态、运营配置一起返回，也可以把之前需要先请求 A 拿 ID、再请求 B 查详情的流水线改成一次请求。HTTP/2 虽然能减少一部分多连接开销，但不要指望它能抵消“多一次往返”在弱网下造成的延迟。这个层面的优化影响范围最大，也能让前面的 TCP/HTTP 细节优化真正体现到用户体验上。

5. 用数据验证：压测和监控要对应到层级

5.1 几条不读代码也能定位层级的命令

网络 IO 优化特别容易凭感觉，所以我把压测和排障过程固定成了一组命令，看到输出基本就知道瓶颈在哪层。

先用 curl 看完整分段时间：

bash复制curl -o /dev/null -s -w \
'connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n' \
http://your-api-path/

这里的 time_connect 就是 TCP 握手完成耗时。如果这个值很大，说明连接建立环节有问题；如果它很小但 time_starttransfer 很大，说明服务端收到请求后处理或返回响应太慢。用这个命令对比“首包之前”的耗时，可以快速判断问题是网络往返、连接队列还是应用处理。

看系统连接状态：

bash复制ss -s
ss -lnt
ss -tan state time-wait

ss -lnt 里监听 socket 的 Recv-Q 如果持续接近 backlog，说明 accept 队列已经溢出。用 netstat -s | grep -i 'listen queue\|overflow' 可以看历史累计。想抓重传率就：

bash复制ip -s link
netstat -s | grep -i 'retrans'

想进一步确认是不是 TCP 有重传或乱序，可以抓包看：

bash复制tcpdump -ni eth0 tcp port 80 and host <target> -w netio.pcap

有了 pcap 文件，再用 Wireshark 对比特定 TCP stream 的时序图，能看到包是延迟到达还是重复发送。这比纯靠日志判断要可靠得多。

5.2 我这次优化前后的数据

我并不主张把一套优化数据当成万能结论，因为不同业务差异很大。但列出我这次改造前后的变化，能给你一个对照参考。场景是 8 核 16G 的普通云主机，接口返回一个 20KB 左右的 JSON，后端有少量数据库查询，网关层是 Nginx 加一个 Go 写的 BFF。

这个效果不是某一个配置带来的。连接池和 Nginx upstream keepalive 主要解决了连接建立和 TIME_WAIT 的问题，accept 队列和 backlog 调优解决了高峰期的 502，事件驱动模型和业务线程池隔离让 CPU 利用率变得有效。最后 HTTP/2 和响应体裁剪让单请求的总耗时进一步下降。整套组合才把单机能力推到新水平。

5.3 不要只盯平均值，长尾才是网络 IO 的问题

优化前我看了平均值，P50 只有几十毫秒，觉得问题不大。但 P99 到了 400ms 甚至更高，实际用户感受到的往往是长尾那部分。网络 IO 因为涉及路由器排队、TCP 重传、内核队列拥塞、并发竞争，天然会有长尾。优化的核心目标一定要包含极端分位值。压测时我会把并发从 100 慢慢加到 1000，每种档跑至少 5 分钟，然后看不同百分位的变化趋势。正常情况下，随着并发上升，P50 和 P99 都会逐渐抬高；如果 P99 在某个并发点突然飙升，那通常意味着某个队列满了，而不是单纯性能不够。

6. 常见问题与避坑实录

6.1 连接超时、connection reset 到底怎么查

最常见的一个现象是客户端偶发 connection reset by peer 或者 connect timeout。很多人第一反应是防火墙或者网络丢包，但我在大量案例里发现，业务侧最多的是 accept 队列溢出和连接被攻击性断开。排查时先看服务端有没有“Listen queue overflow”，再看连接数是否已经超过了 nofile，最后才去怀疑网络设备。connection reset 有一个很隐蔽的触发点：服务端对 keep-alive 空闲连接设置了较短的超时，客户端并不知道，下次直接复用连接发出请求，服务端已经把这个连接关了，于是返回 RST。解决方式就是给客户端调用库加上“连接已关闭则重试一次”的逻辑，很多 HTTP 客户端都有自动重试选项。

6.2 502 不是应用 500，而是连接层问题

这次优化里，最典型的是 Nginx 报 502。业务日志没看到 500，但 Nginx 返回 502，意味着网关去连后端时失败或请求发出后连接断开。当时我们打开 Nginx 的后端 access log 和 error log，看到 upstream prematurely closed connection。因为后端代码里没有设置 keep-alive，Nginx 转发请求时和后端建立的是短连接；后端处理稍慢，Nginx 设置的 proxy_read_timeout 又比较短，连接被中途断开，于是返给客户端 502。后来把 Nginx upstream keepalive 和后端连接池都修好，这个问题就很少出现。

如果你遇到 502，优先确认一下请求路径里每一层的超时时间。网关超时时间不要设置得比后端接口 P99 还短，否则正常的慢请求也会被当成失败。同时检查后端有没有在处理时主动关闭连接、有没有因为线程池满了不接受新请求。很多后端框架在线程池满时会立刻关闭新连接，外层网关看到的依然是 502，但根因在后端线程池容量。

6.3 本地端口耗尽和 Address already in use

服务作为客户端访问下游时，如果并发很大且连接不复用，可能会出现 bind: only one usage of each socket address 或者 Cannot assign requested address。这个错误说明当前五元组组合中本地端口不够用了。Linux 默认的临时端口范围是 32768 到 60999，也就是只有两万多个可用的本地端口。如果 1 万个并发短连接同时发起，很容易撞上上限。临时解法是扩大端口范围：

bash复制sysctl -w net.ipv4.ip_local_port_range="1024 65535"

但根本解法还是要做连接复用，让所有请求共用少数几个连接到下游，而不是每个请求占一个新端口。端口范围调整是给“实在无法复用”的场景兜底的，不能当日常优化手段长期依赖。

6.4 小心连接池被“饿死”

有次我遇到一个诡异现象：服务刚启动没问题，运行一段时间后所有请求都变慢。后来发现连接池里的连接全部是半开状态，因为中间的网络设备把空闲连接悄悄清掉了，客户端连接池并不知道，仍然把这些死连接发给业务用。业务请求发出去后一直等不到响应，直到超时。这时连接池设置的 MaxIdle 再大也没用，因为它没有及时淘汰不可用的连接。

解决方案是给连接池配置空闲连接探活，比如连接空闲时间超过 30 秒就主动发送一个轻量级请求或应用层心跳，同时在获取连接时可以设置“如果连接已不可用，丢弃并新建一个”。对一些老的 JAVA HttpClient 或自研 socket 池，记得要看有没有 validateAfterInactivity 之类的设置。网络 IO 调优到后期，很多问题都和“死连接”有关。

6.5 顺手沉淀的复盘动作

优化结束后，我把这次网络 IO 排查的动作沉淀成了一张清单，后续再遇到类似案例，我不需要重新想该看什么，直接按这个顺序走：

1. 先看 CPU 使用率和软中断比例，排除业务计算瓶颈。
2. 用 curl 分阶段耗时定位是连接、首字节还是下载慢。
3. 用 ss 查看连接状态分布和 accept 队列长度。
4. 看 netstat 里的队列溢出与重传统计。
5. 检查客户端和服务端是否都在用连接池，超时时间是否匹配。
6. 服务端 socket 是否有 TCP_NODELAY。
7. 确认 listen backlog 和 somaxconn 是否够用。
8. 检查 nofile 和线程数是否成为并发上限。
9. 观察长尾 P99 是否在压测过程中出现突然抬升。
10. 最后再考虑是不是要切 HTTP/2 或调整响应体。

这张表对一次完整的 TCP 到 HTTP 层层排查已经足够用了。每次踩坑都往里面补一条，慢慢就会形成自己的网络 IO 排查方法论。