前阵子处理一个线上问题压测时接口平均耗时从1.2秒降到了180毫秒业务代码一行没改只是把从TCP到HTTP这一路上的几个关键参数捋了一遍。最近关于网络IO、TCP、HTTP性能优化的讨论又热起来了结合我踩过的坑和复盘记录把整个过程整理成这篇应该能给正在排查慢接口、镜像拉取失败、连接被重置问题的你一些参考。这套优化不挑语言不管你是Java、Go、Python还是写C只要服务跑在Linux上走的是TCP/IP协议栈里面的思路都能用上。适合后端开发、运维、SRE也适合刚入门想搞懂网络优化到底在优化什么的人。1. 先把“性能优化”这件事分层别急着调参很多人一提到网络IO优化第一反应就是改内核参数把net.ipv4.tcp_tw_reuse打开、把socket缓冲区调大结果改完没效果甚至把系统搞得更糟。原因很简单你根本不知道瓶颈出在哪一层就开始动刀了。1.1 网络IO的完整链路究竟长什么样一段数据从你的进程出发到对端应用收到中间经过的路径比你想象的长得多。大致是这样应用进程 → socket发送缓冲区 → 内核TCP协议栈切包、加TCP头、重传控制 → IP层路由、分片 → 网卡驱动 → 网卡硬件 → 物理链路 → 对端网卡 → 对端IP层 → 对端TCP协议栈 → 对端socket接收缓冲区 → 对端应用进程这每一层都有自己的瓶颈类型。应用层瓶颈通常是序列化、业务逻辑耗时传输层瓶颈是握手次数多、重传率高、缓冲区不足网络层瓶颈是路由绕路、丢包链路层瓶颈是带宽打满、网卡软中断占用过高。所以如果你只盯着应用代码调优忽略传输层握手开销或者只调内核参数而不管应用层是否在频繁创建连接都是白费力气。我把这类问题归纳成一句优化必须分层做但必须先从观测开始。1.2 没有测量的优化都是赌博我的习惯是拿到一个“网络慢”的问题先做三件事用curl -w把一次请求的时间拆解开看DNS解析、TCP握手、TLS握手、首字节、总耗时分别占多少。用ping、iperf粗测链路延迟和带宽。用Wireshark或tcpdump抓包看握手是否重传、窗口是否被打满。做完这三步基本能判断问题到底在DNS、TCP、TLS、HTTP还是业务代码。我见过最典型的误判开发说是HTTP慢结果抓包一看TCP三次握手阶段SYN就重传了三次问题在链路丢包根本到不了HTTP层。1.3 影响范围哪些系统最吃这套优化网络IO优化不是只对高并发网关有意义凡是依赖网络通信的系统收益都很大。高并发API服务收益最大连接复用和内核参数调整能直接降低CPU占用和延迟微服务调用链上每次RPC都在握手优化连接管理效果立竿见影容器镜像分发场景下镜像仓库拉取失败、超时都是典型的网络协议栈和HTTP层问题还有数据库连接池、消息队列客户端、长连接推送服务全都吃这一套。2. TCP层三次握手、连接复用、重传与内核参数一个都不能少TCP层是我在优化时最常花时间的部分。很多人觉得TCP是操作系统帮你搞定的不用管真到了线上你会发现握手延迟、连接堆积、端口耗尽、重传风暴全是这一层的事。2.1 三次握手到底浪费了多少时间TCP三次握手跑一次正常情况需要1个RTT再多一点点。RTT就是数据包走一个来回的时间。局域网内可能0.5毫秒跨地域公网可能50毫秒如果是跨洲链路可能150毫秒以上。一次新连接建立先SYN过去再SYNACK回来最后ACK过去等于你什么都没传就先白等了至少一个来回。如果是HTTPS还得叠加TLS握手那又是1到2个RTT。所以高频小请求场景下连接建立的耗时可能比业务处理本身还大。我做过一个统计某个内部服务单次RTT约30毫秒每次请求新建TCP连接再走TLS光握手花掉60到90毫秒占接口总耗时的50%以上。这种场景优化业务代码不如先把连接管好。减少握手开销的路径有三条长连接连接复用、连接池、TCP Fast Open。后面两条尤其值得关注。2.2 连接复用是回报最高的一步连接复用的思路很简单一条TCP连接建立之后不关后续请求继续用这条连接发。HTTP/1.1的keep-alive、数据库连接池、RPC框架的长连接本质上都是这个思路。但我在不少项目里看到有人明明用了连接池还是慢。查下去发现是服务端主动关连接太勤客户端连接池里的连接频繁失效每次都要重新建立。服务端keep-alive超时时间设置得太短比如5秒客户端一复用就遇到连接已被关闭只能重连。这种问题配置层面就能解决。以nginx为例处理HTTP请求时keepalive_timeout默认是65秒keepalive_requests默认是100意思是单条连接最多处理100个请求后关闭。如果你发现线上大量请求都要重建连接检查这两个值。内网服务一般可以放宽到300秒和1000以上。TCP层的长连接参数也同理系统层面没有全局开关主要靠应用和中间件配置。注意连接池大小也不是越大越好。连接多了会占用文件描述符和内核内存每个TCP连接在内核里有发送缓冲区和接收缓冲区几千条连接占用的内存相当可观要根据实际QPS和延迟来设置池子上限。2.3 内核参数somaxconn、tw_reuse、缓冲区做TCP层优化绕不开这几个内核参数。我放一张自己常用的速查表参数默认值建议值作用net.core.somaxconn1281024或更高socket监听队列上限值太小会丢连接net.ipv4.tcp_max_syn_backlog128各发行版不同1024SYN等待队列长度影响高并发握手成功率net.ipv4.ip_local_port_range32768 60999根据并发调大范围本地端口范围客户端连接多时会用尽net.ipv4.tcp_tw_reuse01仅对发起连接方有效允许复用TIME_WAIT状态的连接net.ipv4.tcp_fin_timeout6030或更低FIN_WAIT_2状态超时回收速度net.ipv4.tcp_rmem4096 87380 6291456按需调整min/default/max接收缓冲区自动调整区间net.ipv4.tcp_wmem4096 16384 4194304按需调整发送缓冲区自动调整区间先解释一个高频故障。很多人见过java.net.BindException: Address already in use发生在客户端重连时尤其是短连接高并发场景。原因是本地端口进入TIME_WAIT状态默认等60秒左右才能复用端口范围又有限最终端口耗尽。解决办法对发起连接的一方开启tcp_tw_reuse同时调大ip_local_port_range。但我要提醒一句tcp_tw_reuse只能用在主动发起连接的那一侧如果开在服务端被动连接侧作用非常有限而且可能会引入连接复用错乱。更根本的办法是客户端做连接池尽量复用连接而不是频繁新建。net.core.somaxconn这个参数特别容易被忽略。高并发下listen的accept队列如果满了内核会直接丢弃新的连接请求客户端表现就是连接超时或握手被重置。nginx、Tomcat、Redis都有各自的应用层backlog参数比如nginx的listen 80 backlog1024但最终上限还得看net.core.somaxconn。关于TCP缓冲区很多系统的默认值在跨机房传输、带宽较高的场景下是不够的。判断方法是用ss -tni看连接的实际收发缓冲区和拥塞窗口。如果发送缓冲长期处于满的状态说明应用写入速度超过了网络发送能力需要调大tcp_wmem如果接收窗口经常打满就得调大tcp_rmem同时确认对端应用消费速度是不是太慢。2.4 收到重复ACK别慌重传与乱序诊断Wireshark里经常能看到TCP Dup ACK很多人一看到就以为是丢包其实这是TCP快速重传机制的一部分。逻辑是这样接收端收到乱序数据包时会重复回复当前期望的序号发送端连续收到3个重复ACK就认为后面这段丢了不等超时直接重传。这个机制本身没问题但如果Dup ACK大量出现说明链路存在丢包或乱序。排查时我习惯统计重传率也就是TCP Retransmission包占总包数的比例。正常局域网内应该趋近于0公网环境下超过1%就要警惕。开启SACK能够显著提升乱序场景下的重传效率Linux默认是开启的。确认方法sysctl net.ipv4.tcp_sack输出为1即可。另外很多高性能服务器会开启net.ipv4.tcp_congestion_control为bbr在有一定丢包率的公网链路上表现比cubic好延迟也更低。不过是否启用BBR要看内核版本和网络环境不要无脑照抄。3. HTTP层从短连接到长连接再到真正的多路复用把TCP层处理完下一步看HTTP层。这一层的优化直接影响用户的直观感受但很多坑也藏在这里。3.1 HTTP/1.1的连接复用和“隐形的队头阻塞”HTTP/1.1默认开启keep-alive一条TCP连接上可以连续发多个请求。相比每次请求都新建连接提升非常明显。但HTTP/1.1有个老问题——同一时刻、同一条连接上只能有一个请求在等待响应后面的请求必须排队。就算浏览器对同一域名一般开6条连接一旦其中有慢请求其他请求还是会被阻塞。这叫做队头阻塞。解决方案看起来是HTTP/2的多路复用但实际部署中还有细节要注意。3.2 HTTP/2 和 HTTP/3 带来的变革HTTP/2在一条TCP连接上通过二进制分帧层把多个请求交错传输每个请求有自己的流ID彻底解决了HTTP/1.1的应用层队头阻塞。另外还带了头部压缩对请求头很大的场景有奇效。但HTTP/2有个前置条件浏览器和主流客户端基本只在TLS上启用h2。所以你要启用HTTP/2就得保证网关和链路能顺利走TLS握手。如果TLS握手本身很慢HTTP/2带来的并发提升会被握手开销抵消掉。部署HTTP/2还有一个隐藏收益服务器推送能力可以提前把关键资源发给客户端减少后续请求。HTTP/3则更进一步基于UDP实现握手降低到0-RTT还解决了TCP层本身的队头阻塞。但目前生产环境普及率有限升级需要客户端、网关、CDN三方配合。我目前只在边缘节点和移动端场景实验过后端内网服务的收益不明显。3.3 别忘了应用自己头部长、重定向、压缩与缓存HTTP层最容易被忽视的问题不是协议版本而是应用自己制造的负担。我见过一个线上事故某系统因为Cookie越加越多单个Header总计超过16KB网关直接返回HTTP Error 400. A request header field is too long.所有用户请求全部失败。这种问题在nginx里可以通过调大large_client_header_buffers临时解决但本质是应用层设计问题——不该放Cookie的数据放进去了。优化方向是精简Cookie、把无状态数据放服务端、减少header体积。另一个常见瓶颈是重定向链。很多接口返回302客户端再跟一次请求一次访问最终变成3到4次HTTP往返TTFB自然高。能直接返回内容就别重定向确实需要跳转时也要让CDN或网关在边缘把重定向消化掉别让客户端来回跑。压缩和缓存也属于HTTP层优化。响应体启用gzip或Brotli压缩尤其对JSON大响应非常有效缓存控制头配好了能省掉整个请求。这套优化性价比很高但很多人只关注了握手和参数把这一块漏了。3.4 超时、重试与幂等网络故障时的优雅降级HTTP层的性能不只是“快”还包括“挂的时候别把系统拖死”。连接超时、读取超时、写入超时这三个参数必须分开设置。连接超时建议设短一点比如1到2秒因为连接失败是立刻能感知的读取超时和写入超时要根据业务耗时合理设置设太短会把慢请求误判为故障设太长又会让线程池被慢请求占满。重试一定要谨慎。连接超时可以重试但读超时后盲目重试容易造成请求重复执行典型例子是下单接口超时重试导致重复扣款。所以重试前必须确认接口幂等或者给请求带幂等键。重试间隔用退避策略比如第一次等200毫秒第二次翻倍避免重试洪峰把所有服务都打挂。4. 实战复盘镜像仓库连接失败背后的层层排查前面讲的是原理和方法这部分我放两个真实场景把排查流程完整走一遍你会发现前面那些层层的判断思路是直接能用的。4.1 现象error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled这个报错应该是不少运维的噩梦。Docker拉取镜像时提示连接取消、等待超时很多人第一反应是重启Docker然后发现没有用接着想到重新拉取还是失败。遇到这种问题我会先拆开看Docker客户端请求镜像目录时走了HTTPS也就是先要TCP握手再做TLS握手然后发GET /v2/请求。每一环都可能出问题。用curl模拟相同请求curl -v https://registry-1.docker.io/v2/ --connect-timeout 5 -m 10如果返回连接超时排查方向是DNS解析、路由和出口链路先用dig或nslookup确认域名解析结果是否正常解析超时或返回异常都会导致连接卡住。再用telnet或nc测试443端口连通性通不了就是链路问题。如果端口能通但TLS握手一直不完成重点检查证书链、系统时间是否正确。这类问题里DNS解析出问题的概率特别高。本地DNS缓存了错误记录或者解析到了不可达的地址都会让Docker以为连不上。动手改系统参数之前先把DNS缓存刷一遍换一个可靠的公共DNS试一下往往比调内核参数管用得多。4.2 另一个经典现场Harbor推送失败和端口绑定失败自建镜像仓库同样有网络问题。我遇到过两次很有代表性的情况。第一次是推送镜像到内网Harbor报错信息类似Get https://192.168.209.133/v2/: dial tcp 192.168.209.133:443: connect: connection refusedconnection refused说明TCP层握手就被拒了对端根本没人监听或防火墙直接丢弃。排查方法很明确登录Harbor节点执行ss -tlnp | grep 443确认服务是否监听在443端口。服务没起来怎么调网络参数都没用。如果监听正常检查iptables或安全组规则看是否放行了对应来源IP的443端口。这里很多团队会因为安全组配置少放行了一条规则浪费半天时间。第二次是启动容器时报error response from daemon: ports are not available: exposing port tcp 0.0.0.0:8080这个错误信息很直白宿主机的8080端口已经被人占了。netstat -tulnp | grep 8080看一下占用进程换端口或者停掉冲突进程即可。这类问题属于应用部署层面但报错发生在网络协议栈的bind阶段懂一点TCP端口管理知识排查会快很多。4.3 用抓包数据确认问题层排查网络问题我一直觉得“数据优先”别靠猜。Wireshark和tcpdump是最好用的工具。比如怀疑TCP握手慢抓包时过滤tcp看SYN包发出到SYNACK回来间隔了多少时间一眼就知道是链路RTT大还是中间丢包重传。如果SYN重传了好几次说明SYN包在路上丢了。如果SYNACK一直不回大概率是防火墙或监听问题。再比如怀疑TLS握手慢看Client Hello发出到Server Hello回来时间如果TCP握手很快、TLS这步很慢问题多半在对端证书校验或加密套件协商上不是网络链路问题。抓包分析有个实用技巧先在客户端抓再在对端抓。如果客户端抓包能看到对端回复但对端抓包没看到请求那就是中间链路丢包如果两端都能抓到数据但应用就是没反应问题在应用处理而不是网络。4.4 修复后的参数与效果把两次镜像仓库问题修完之后我顺手把整个过程整理成了一个排查表报错关键信息问题层第一步排查推荐处理http: request canceled while waiting for connectionHTTP/TCP连接建立curl分步测连通性检查DNS、路由、TLS证书dial tcp IP:443: connect: connection refusedTCP监听/防火墙对端ss监听检查确认服务存活、检查防火墙规则ports are not available: exposing port tcp 0.0.0.0端口绑定netstat查端口占用换端口或停冲突进程400 A request header field is too longHTTP头大小看网关日志精简Header、调大bufferrequest returned 500 internal server errorHTTP层API异常看引擎与客户端版本匹配升级对应组件这套表放出去之后团队里排查同类问题的时间从半小时降到了五分钟以内。5. 压测工具、监控指标和一套可复制的排查流程优化做完后不能就这么算了还得压测验证、持续监控。否则过一阵子流量涨了你又不知道瓶颈在哪。5.1 压测前把工具选对curl/wrk/ab/iperf不同的压测工具干的活不一样选错了测出来的数据没有参考价值。工具适用场景核心用途curl单次请求调试分阶段耗时拆解、验证header、TLSabHTTP接口短连接压测简单吞吐测试、并发请求测试wrkHTTP接口压测多线程压测、延迟分位统计iperf3TCP/UDP链路压测纯带宽、延迟、丢包测试tcpdump/Wireshark抓包分析定位丢包、重传、握手、TLS问题我日常定位慢接口的第一步永远是curl因为它的输出信息量最大curl -o /dev/null -s -w DNS:%{time_namelookup}\nTCP:%{time_connect}\nTLS:%{time_appconnect}\nTTFB:%{time_starttransfer}\nTotal:%{time_total}\n https://example.com/api这组数据能直接告诉你慢在哪一段。如果TCP耗时高问题在链路或TCP参数如果TLS耗时高问题在证书链或加密套件如果TTFB高但TCP和TLS都正常那慢的是服务端业务处理。5.2 关键监控指标线上环境我建议网络监控至少覆盖下面几项TCP连接建立成功率异常波动通常意味着握手队列满或防火墙变动。TCP重传率这个指标最能反映链路质量。连接池利用率包括活跃连接数、空闲连接数、等待获取连接耗时。首字节时间TTFB这是客户端感知延迟的核心指标。HTTP错误率分布重点看502、504、408这些跟网络相关的状态码。我之前在一个网关项目里加了重传率监控上线一周就发现某条跨机房链路重传率从0.3%飙到3%后来定位到链路割接导致的路由绕路。如果没有这个指标问题会在更晚的时候以业务超时的形式暴露影响面大得多。5.3 优化流程复盘最后总结一套我目前一直在用的优化流程你可以直接抄作业。第一步拆分请求耗时。用curl或客户端埋点拿到DNS、TCP、TLS、TTFB、Total的耗时分布。第二步确认瓶颈层。哪一段占比最高就先去处理哪一段。TCP握手占比高就搞连接复用和参数TTFB占比高就查服务端处理DNS占比高就查解析链。第三步逐层调整、逐层复测。改一个参数就压测一次不要同时改好几个否则出了问题你不知道是谁引起的。第四步结果落到监控里。把优化前的基线和优化后的数据记下来设好告警阈值防止回归。第四步这块容易被忽略但恰恰是最重要的。很多团队优化完就散伙三个月后流量上来问题重现又从头排查一遍全是重复劳动。6. 最后分享几条实际经验这套从TCP到HTTP的优化流程跑下来我有几个主观但很强烈的体会。第一先别改全局内核参数。很多优化只影响特定场景比如tcp_tw_reuse只对主动连接方有意义tcp_rmem调大了反而浪费内存。我见过有人为了“优化”把整个集群的缓冲区都调大最后内存用量翻倍性能没见提升。参数要按服务场景去调能改容器网络配置或应用层配置解决的事不要轻易动宿主机内核。第二长连接不是越长约好。连接复用的前提是链路稳定、请求频率足够。低频请求场景下维持一条长连接反而要额外发心跳包保活。要拿数据和场景说话别盲目复用。第三网络排查要留痕。每次抓包、每次参数调整记录当时的现象、改动、结果。网络问题很多时候是间歇性的没有现场记录下回再现你又要从头开始。第四应用层别给网络层添乱。大Header、多重定向、超大Cookie、不合理超时这些设计问题会让再好的网络参数都白搭。优化的时候从上往下看也得从下往上想。