搞运维和后台开发这十几年我很少直接相信“网络有问题”这句话。这么说不是抬杠而是在绝大多数故障现场里用户感知到的“网络慢”真实原因常常五花八门可能是服务端线程池满了可能是磁盘 IO 在打架可能是 TCP 在疯狂重传甚至可能就是某台机器的网卡协商到了百兆。网络和 IO一个在链路传输一个在系统内部读写看起来分属两个领域实际排查时却必须放在一起看。今天这篇第 6 章就围绕“网络与 IO 问题排查”把从方法论、工具链到真实复盘案例的完整过程讲一遍希望能给做运维、后端、SRE 以及自建服务排查的朋友一些参考。1. 为什么把网络和 IO 放在同一章链路视角下的排查逻辑1.1 先把 IO 的范围说清楚“IO”这个词在不同领域含义完全不一样。嵌入式工程师听到 IO 想到的是 GPIO 口、推挽输出、开漏上拉、片选信号做硬件控制的人看到的是 esp8266 扩展 IO 口、海康相机 IO 拍照接线、CC-Link 模块的 IO 地址映射。而本文讨论的 IO是系统层面的输入输出包括网络数据读写、磁盘块读写、文件读写、进程间管道读写。这是运维和软件排查里最常见的含义。这两个含义在热搜词里常常被混在一起但实际工作中一定要先对齐如果用户报“IO 出问题了”先问清楚是业务接口慢、磁盘占用高还是硬件 IO 口没信号。我在不少故障群里见过双方扯了半天最后发现一个在说网络吞吐另一个在说单片机引脚完全不在一个频道。第 6 章里提到的 IO默认指系统 IO。1.2 网络和 IO 是同一根链条上的两环一个请求从客户端发出到服务端返回响应完整链路大致是客户端应用写入 socket → 系统协议栈打包 → 网卡发送 → 网络链路传输 → 服务端网卡接收 → 协议栈解包 → 服务端应用读取 socket → 应用处理可能读写磁盘或数据库→ 响应写回 socket → 再走一次网络。这条链路上任何一个环节卡住客户端感知到的都是“慢”或“超时”。换句话说“网络慢”其实是一个模糊的症状不是一个根因结论。如果不把网络和 IO 放在一起分析很容易只盯着一端排查。比如数据库磁盘 IO 打满查询延迟从 2ms 变成 500ms对客户端来说就是“接口访问超时”。这时候你去链路层看丢包、看延迟大概率什么都查不到因为物理链路根本没问题瓶颈在服务端落盘和查询的那一段。1.3 一张映射表表象与真实根因的对应关系这些年在各类案例里我整理过一组很常见的“表象 → 根因”对应关系用户看到的表象可能的真实根因网页打不开DNS 解析失败、服务端线程池耗尽、防火墙静默丢包接口偶发超时服务端 GC 停顿、磁盘 IO 抖动、TCP 重传过高文件上传极慢带宽被打满、网卡软中断不均衡、目的磁盘写性能不足报错 connection reset / broken pipe服务端主动断开、中间设备空闲超时、客户端读超时后重置长连接突然断流代理层 idle timeout、对方进程重启、NAT 会话老化这张表的价值不是罗列问题而是提醒排查时不要被“表象”带着走。用户说“网络有问题”你不一定真的要去查网络。先把症状翻译成技术指标再决定从哪一层入手才是正确的打开方式。2. 排查前的四件事拓扑、基线、工具清单、日志开关很多网络与 IO 问题排查效率低不是因为手段不够而是准备工作没做。真正上场时才想到没画拓扑、没留基线、没开日志、工具没装齐每一步都卡在“先等一下我看下 xxx”。所以我建议把这四件事当成排查前的固定动作。2.1 没有拓扑图排查全靠猜网络拓扑图不是画给领导看的是排查故障时最省时间的工具。至少要包含几类信息物理链路和跳数、每一段的带宽与协议、关键端口和超时参数、依赖的外部服务DNS、NTP、数据库、缓存。不用画得多精致但要能让人一眼看清“客户端到服务端中间经过了几层设备每层可能做什么”。我见过最典型的案例某个后端服务跟数据库之间偶发断连排查了一整天才发现中间有一台负载均衡设备配置了空闲超时连接静默超过 90 秒就会被断开。如果拓扑图上标注过这类参数排查时间至少缩短一半。所以画完拓扑之后顺手把每层的 timeout、keepalive、最大连接数标上去这份图才会真正值钱。2.2 基线数据没有对比就没有结论“这台服务器 IO 性能明显下降了”这句话如果没有对比数据支撑充其量是个体感。判断是否真的下降需要知道正常时期的延迟、吞吐、连接数、磁盘 util 等指标。所以我会建议提前积累三类基线网络基线到关键目标 IP 的 RTT、丢包率、实测带宽用 iperf3 打出来的数值。磁盘 IO 基线iostat 里的磁盘 util、await、r/s、w/s尤其是业务高峰期的数值。连接基线TCP 连接数、TIME_WAIT 数量、文件描述符使用量。这些数据不需要复杂系统一台带历史存储的监控服务器就够。在线测速工具适合普通用户检查互联网带宽但服务器之间还是用 iperf3 实测更靠谱因为在线测速只能说明机房出口带宽说明不了内网某一段链路的质量。2.3 工具清单先列出来别等出事了再找排查现场最忌讳临时装工具。系统权限不够、包管理器源不可用、装完发现命令版本不对都会把排查节奏打乱。下面这张表是我常用的排查工具箱绝大多数 Linux 发行版都能一条命令装齐场景工具连通性测试ping、telnet、nc、curl路径探测traceroute、mtr抓包分析tcpdump、Wireshark、tshark连接与流量ss、netstat、iftop、nethogs、sar -n DEV应用层压测curl、wget、ab、wrk、iperf3磁盘 IOiostat、iotop、pidstat -d、sar -d系统资源top、htop、vmstat、free系统调用跟踪strace、lsof这里特别说一下 nethogs 和 strace。nethogs 可以按进程维度看网络流量适合定位“哪个程序在偷偷占带宽”strace 能跟踪进程的系统调用当 IO 慢但又不知道卡在哪个函数时strace -p PID -f能直接看到是不是在 read/write 上阻塞。这两个工具不是系统默认自带但值得提前装好。2.4 日志开关把时间线对齐排查耗时最多的往往不是定位技术问题而是“证据对不上”。常见情况是A 机器的日志显示 14:03:02 连接断开B 机器的日志显示 14:02:58 收到 FIN两边时间差了 4 秒怎么都拼不上。一问才发现两台机器没有做时间同步差了几分钟。所以排查前先确认 NTP 同步正常所有日志格式统一包含毫秒和时区。另一个常被忽略的问题关键日志没开。生产环境为了性能关闭 debug 日志可以理解但访问日志、错误日志、慢查询日志必须开。中间件层面尤其重要Nginx 的 access log 和 error log、MySQL 的 slow query log、Redis 的 slow log这些在故障复盘里的价值超过任何监控图。服务还应该把链路追踪 ID 串进日志否则微服务几十个调用链根本没法还原现场。3. 网络链路排查从连通性到抓包取证的分步打法网络链路排查不是简单敲几个命令而是按层逐级确认。我的习惯是先定范围再做连通性测试然后路径探测最后抓包取证。每一步的目的都是缩小怀疑面而不是盲目收集数据。3.1 先定范围是一台机器、一块区域还是全部挂了排查前先问三个问题只有一个人反馈还是一批人反馈只有一台服务器有问题还是整个集群都有问题是偶发还是持续不可用这三个问题的答案能直接决定排查方向。举个例子办公室某一台电脑有线网络卡顿旁边同事都正常那优先怀疑本机网线、交换机端口、网卡驱动或者系统配置如果整个办公室有线网络都卡那就查上联口、网关、DHCP 或者出口带宽。同理线上服务只有一台实例异常先看那台机器的负载、IO、网卡错误包所有实例一起异常优先怀疑依赖的下游服务或网络设备。3.2 基础连通性测试ping 通不代表业务端口通端口通不代表应用可用基础连通性测试一般分三层第一层ICMP 探测ping -c 10 目标IP看丢包率和平均 RTT。注意 ping 通了只能说明 ICMP 协议可达它走的是另一条路径和协议号TCP 业务不通的故障里 ping 完全正常的案例太多了。第二层TCP 端口探测nc -vz 目标IP 8080 telnet 目标IP 8080这一步确认目标端口是否有服务监听、防火墙是否放行。能建立 TCP 连接说明传输层没问题。第三层应用层探测curl -o /dev/null -s -w dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n https://example.com这个命令能拆解出 DNS 解析耗时、TCP 建连耗时、TLS 握手耗时和总耗时。如果 connect 很快但 total 很慢问题大概率在服务端处理而不是网络链路。三层测下来基本能定位到“网络通但应用慢”还是“链路本身不通”排查方向也就清晰了。3.3 路径探测用 mtr 看每一跳的延迟和丢包跨机房、跨运营商的问题光测目标 IP 不够还要看中间每一跳。这里我强烈推荐 mtr而不是传统 traceroute。mtr 会持续发送探测包并统计每一跳的丢包率和延迟比 traceroute 打一次就退出的方式更适合判断链路质量。mtr -rw 目标IP # -r 报告模式 -w 宽输出 mtr -c 100 目标IP # 连续发 100 个包解读 mtr 输出有个关键技巧如果最后一跳丢包高而前面几跳都正常说明丢包发生在目标机器自身或目标内网可能是目标机器负载高、防火墙丢包如果中间某一跳持续丢包且后续所有跳也丢包才说明中间链路真实存在问题。有些骨干节点对 ICMP 限速会导致假性丢包需要结合 TCP 抓包交叉验证不能单看 mtr 就下结论。3.4 抓包取证让 TCP 自己说出问题当连通性测试正常但业务仍然异常或者日志里出现 connection reset、broken pipe 这类报错时就必须抓包了。抓包的目的是让 TCP 协议栈替你说出问题真相。# 抓取指定主机和端口的双向流量写入文件 tcpdump -i eth0 host 目标IP and port 8080 -w /tmp/cap.pcap # 实时查看摘要不落盘 tcpdump -i eth0 host 目标IP and port 8080 -nn -c 100抓到的 pcap 文件用 Wireshark 打开重点看这四类现象TCP 重传Retransmission发送端没收到 ACK说明中间丢包或对端处理不过来。重复 ACK / 快速重传Dup ACK报文乱序或部分丢失。零窗口Zero Window接收方缓冲区满了应用进程没及时读取数据。这个指标特别关键它指向的是接收端应用 IO 性能不足而不是网络问题。RST 包谁发的 RST谁就是主动断开方。RST 出现的位置能告诉我们断连发生在建连时、传输中还是空闲期。我在实际项目里遇到过两台电脑用网络调试助手做 UDP 通信朋友反馈“局域网内还是丢包”。抓包后发现根本不是物理链路丢包而是发送端发送速率太快接收端 socket 缓冲区不够系统直接静默丢弃 UDP 包。调整发送频率并调大接收缓冲区后问题立刻消失。所以很多“网络问题”说到底都是 IO 缓冲和应用处理速度不匹配的问题。3.5 带宽测试测速要分场景用户侧测速可以打开在线测速网站但服务器之间不要用这个方式。服务端带宽测试的标准工具是 iperf3# 服务端 iperf3 -s # 客户端 iperf3 -c 目标IP -t 60 -P 10-P 10表示 10 个并发流能更好地压出真实带宽。测试前先检查网卡协商速率ethtool eth0 | grep Speed见过不少案例网线老化或者交换机端口问题网卡协商到了百兆而不是千兆带宽直接差 10 倍监控图上看起来接口没打满但用户体感就是明显变慢。这时候 iperf3 一测就知道瓶颈在哪根本不用猜。4. 系统 IO 排查当瓶颈不在网线而在内核与磁盘网络链路查完没问题接下来就要把视线转向系统内部。这里涉及两类 IO网络 IO 处理路径上的瓶颈以及磁盘 / 文件 IO 瓶颈。它们和网络问题交织在一起是排查中最容易绕弯的地方。4.1 第一步先鉴别慢在磁盘 IO还是慢在网络 IO遇到“服务响应慢”我会先跑三条命令# 看整体负载、CPU 和 IO 等待 vmstat 1 # 看磁盘详细指标 iostat -x 1 # 看网卡实时吞吐 sar -n DEV 1关注几个关键数字vmstat 里的 wa 列高说明 CPU 在等待磁盘 IOb 列高说明进程因为 IO 阻塞排队。iostat -x 里的 util 接近 100%、await 比 svctm 大很多就是磁盘能力到顶或磁盘在排队。sar -n DEV 能看到 rxkB/s 和 txkB/s用这个值和网卡带宽做对比确认网络流量是否打满。一个快速判断逻辑客户端慢、服务器 CPU 不高、网卡流量也不大但磁盘 util 高优先排查磁盘 IO网络流量已经接近带宽上限优先排查带宽和流量来源两者都不高就要回到应用层看线程池、连接池、GC 了。4.2 磁盘 IO 性能下降的常见元凶不一定是磁盘坏了“IO 性能明显下降了”是我听过最多的一句话之一但排查下来的结果往往不是存储设备损坏而是这些软件层面问题日志文件膨胀到十几个 GB每次写日志都要触发大量磁盘寻址和缓存淘汰。数据库产生的随机 IOPS 超过磁盘上限机械盘尤其明显。内存不足触发 swap 抖动swap 的读写让磁盘 IO 看起来异常高。文件系统挂载参数不合适比如默认开启了 atime 更新每次读文件都附带一次写操作。大量小文件频繁创建删除导致 inode 缓存和目录操作压力很大。定位谁在写磁盘用pidstat -d 1按进程看 IO用iotop看实时排序再用lsof -p PID查看进程打开了哪些文件。曾经有个项目反馈数据库所在机器 IO 高排查时用 pidstat 发现罪魁祸首根本不是数据库而是同机部署的采集程序在疯狂写临时文件把磁盘 IO 吃光了。所以“谁在写”永远比“磁盘是不是坏了”值得先查。4.3 网卡 IO 的隐藏瓶颈软中断与队列分布不均网络流量不高但 CPU 出现单核 100%这是网卡中断不均导致的典型现象。多队列网卡如果没启用 RSSReceive Side Scaling或者驱动不支持多队列所有收包中断可能集中在同一个 CPU 核上导致软中断处理不过来表现为网络吞吐上不去、延迟抖动。查看方法top 里按1看每个核的使用率如果某个核 si 占很高而其他核空闲基本可以确认是这个原因。再用cat /proc/interrupts看中断向量在各 CPU 上的分布会更直观。处理方式一般有两种一是确认网卡多队列已开启二是配置 RPSReceive Packet Steering# 将 rx 队列的 RPS 掩码设置为多核例如 4 核机器 echo f /sys/class/net/eth0/queues/rx-0/rps_cpus还可以调整网卡环形缓冲区大小ethtool -G eth0 rx 4096 tx 4096这类配置是生产环境变更操作前要确认当前驱动支持哪些参数并先在低峰期验证。但排查思路要建立起来网络 IO 性能问题不一定在“网络”很可能在内核处理网络包的方式上。4.4 网络文件系统的 IO 陷阱本机不慢但读写远程存储很慢服务器挂载 NFS 或 SMB 后本机 iostat 看本地磁盘正常但应用写文件极慢这时要考虑是不是网络文件系统本身的问题。网络文件系统的每次读写都要经过网络 RPC所以它的性能同时受网络延迟和服务端并发能力影响。排查时先看挂载参数和 RPC 统计mount | grep nfs nfsstat -m cat /proc/net/rpc/nfsd常见问题包括NFS 客户端没有配置适当的协议版本或挂载参数导致每次读写都走低效路径服务端并发线程不足排队严重网络小包延迟偏高时每条 NFS 请求都会放大这种延迟。这类问题的特点是“本机磁盘没压力、应用却感觉 IO 慢”诊断时一定要把网络文件系统单独拎出来当独立瓶颈对待。5. 一个典型报错的完整复盘stream disconnected before completion前面讲的是方法论这一节我用一个真实复盘把整个链路串起来。报错信息很有代表性stream disconnected before completion: failed to send websocket request: io error: peer closed connection with ...。如果你也在 WebSocket 长连接或 HTTP/2 流式请求里遇到过类似报错这个案例的排查路径可以直接复用。5.1 现象与初步定性ping 全通但还是报错现象是客户端通过 WebSocket 长连接向后端发送业务请求偶发出现上述报错频率不高但一旦出现请求就失败客户端重试后通常能成功。用户侧感知是“网络不稳定”。我的初步排查动作按顺序做了三件事ping 目标服务 IP丢包 0%延迟正常。用nc -vz测目标端口连接正常建立。用客户端单独发起一次 WebSocket 请求能成功说明功能本身没问题。到这里基础网络层面看起来是通的。这种“什么都通但就是偶发断”的情况大概率不是链路故障而是连接管理策略的问题。接下来必须抓包确认。5.2 抓包定位找出 RST 和 FIN 的发送方在客户端和服务端同时抓包这里有个经验两边抓包前必须先确认时间同步否则对比报文时间线会非常痛苦。抓包命令# 客户端抓包 tcpdump -i any host 服务端IP and port 443 -w /tmp/client.pcap # 服务端抓包 tcpdump -i any host 客户端IP and port 443 -w /tmp/server.pcap两边 pcap 一起放进 Wireshark按时间线对齐很快就看到真相服务端在一段空闲时间后主动发起了断开连接客户端在连接已断开的情况下继续发送 WebSocket 请求收到 RST 后抛出“peer closed connection with ...”异常最终体现为stream disconnected before completion。这里还有一个重要细节客户端发请求时连接从应用视角看还是“已连接”状态但底层 socket 早已被对端关闭。这种“半开连接”是长连接类应用最常见的坑。5.3 根因确认超时配置不一致继续挖发现触发断开的不是业务代码显式关闭而是服务端和客户端之间的空闲超时配置不一致。服务端或中间负载均衡/WebSocket 代理配置了空闲超时比如 60 秒没有数据传输就主动断开连接客户端没有在超时周期内发送心跳也没有在断开时立刻感知到于是下一次请求就砸在了死连接上。更隐蔽的一种场景是代理层配置了proxy_read_timeout如果服务端业务处理时间偶尔超过这个阈值代理会直接断开连接客户端看到的就是“failed to send websocket request: io error”。这种情况和网络质量一点关系都没有纯粹是“业务处理耗时 代理超时时间”造成的误杀。5.4 修复方案与验证定位到根因后修复是组合拳不能只改一头客户端增加 WebSocket 心跳ping/pong周期明显小于服务端空闲超时比如服务端 60 秒超时客户端 25 秒发一次心跳。服务端或代理调大空闲超时或者关闭不必要自动断开。客户端在发送请求前检测连接状态捕获 IO 异常后分类处理连接被重置就走重连超时就退避重试不能一律无限重试。对重试逻辑做幂等设计尤其是涉及下单、支付这类写操作。验证阶段做了两件事一是长时间压测观察报错率二是构造人为断连测试客户端重连逻辑是否生效。最终线上偶发错误率从万分之几降到零。这个案例本身技术含量不算高但它完整展示了“网络报错 → 抓包 → 根因在连接治理”的典型路径。5.5 同类问题的举一反三stream disconnected、connection reset、broken pipe这一大类错误本质都是“连接状态与双方预期不一致”。以后遇到这类问题我的排查顺序固定如下抓包看 RST / FIN 是谁发的、发生在哪个阶段。检查双方超时配置空闲超时、读超时、写超时。检查连接是否空闲过久NAT 会话是否老化。检查应用读写缓冲区和线程池是否有积压。不要一上来就怀疑机房抖动或带宽不足。虽然确实存在硬件链路故障导致断连的情况但大多数偶发断连问题最后查下来都是连接治理和应用层处理策略的问题。6. 实战心得排查顺序、误判陷阱与常用命令速查这一节算是我个人经验的沉淀也是排查完大量问题后总结出来最值得分享的部分。6.1 推荐的排查顺序四层走查不要跳步我推荐的排查顺序可以浓缩成“四层走查”先看应用与监控确认故障影响范围、精确到分钟的时间窗口、错误日志和链路追踪。这一步能过滤掉大量“假网络故障”。再看网络层连通性、丢包、延迟、TCP 重传、连接数。再看系统层磁盘 IO、CPU、内存、软中断、文件句柄。最后回到应用层线程池、连接池、GC、慢查询。很多人习惯跳过第 1 层直接开始 ping结果查了半天最后发现是当次发布导致的问题。每敲一条命令之前先问自己我现在想验证什么假设验证完了结论是什么带着问题去排查比东一榔头西一棒子高效得多。6.2 我踩过的误判陷阱陷阱 1ping 通了就觉得网络没问题。ICMP 可达不代表 TCP 端口通更不代表应用层可用。要分三层做连通性测试。陷阱 2只盯平均值不看长尾。很多偶发问题平均延迟正常但 P99 高得离谱。看监控要同时看 P50、P95、P99 和最大耗时。陷阱 3日志时间不同步。多台机器日志时间不一致案情还原直接崩掉。NTP 同步是排查的基础设施。陷阱 4抓包工具本身干扰业务。大流量场景下 tcpdump 自身可能丢包要设置合理的 snaplen只抓需要的端口避免全端口抓包。陷阱 5IO 性能下降先怀疑硬件。多数 IO 问题其实是日志膨胀、数据库慢查询、swap 抖动导致的先用 pidstat 找“谁在写”比换硬盘更重要。陷阱 6忽视连接数。文件描述符或 TCP 连接数打满时新连接无法建立现象极像网络故障但本质是资源耗尽。6.3 常用排查命令速查表把这篇涉及的命令汇总成一张表方便直接截图保存想查什么命令整体负载与 CPUtop、uptime、vmstat 1CPU 等待 IO 比例vmstat 1 里的 wa 列磁盘 IO 明细iostat -x 1进程级磁盘 IOpidstat -d 1、iotop网卡实时吞吐sar -n DEV 1网络流量按进程看nethogsTCP 连接状态统计ss -s、netstat -ant端口连通性nc -vz IP 端口、telnet IP 端口应用层耗时拆解curl -w路径与每跳丢包mtr -rw 目标IP抓包落盘tcpdump -i eth0 host IP and port 8080 -w cap.pcap进程打开的文件lsof -p PID系统调用阻塞位置strace -p PID -f实际带宽测试iperf3 -c 目标IP -t 60 -P 10网卡协商速率ethtool eth0中断分布cat /proc/interrupts6.4 最后一个建议沉淀自己的排查模板每次故障解决后我都会做一件事把现象、影响范围、时间窗口、拓扑图、关键配置、抓包结论、根因、修复动作和验证结果整理成一个固定模板的文档。刚开始觉得麻烦坚持半年后发现价值极大很多新问题其实是旧问题的变体翻历史记录就能快速定位方向。推荐的排查模板字段可以参考这些现象描述、影响范围、时间窗口、当前拓扑、关键配置项、抓包文件路径、命令输出摘要、根因结论、修复动作、验证结果、遗留事项。按这个模板积累三个月再遇到网络与 IO 类问题你就不会再像无头苍蝇一样从上到下挨个敲命令了。