企业官网建设流程全解析

搞运维和后台开发这十几年，我很少直接相信“网络有问题”这句话。这么说不是抬杠，而是在绝大多数故障现场里，用户感知到的“网络慢”，真实原因常常五花八门：可能是服务端线程池满了，可能是磁盘 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 一张映射表：表象与真实根因的对应关系

这些年在各类案例里，我整理过一组很常见的“表象 → 根因”对应关系：

这张表的价值不是罗列问题，而是提醒排查时不要被“表象”带着走。用户说“网络有问题”，你不一定真的要去查网络。先把症状翻译成技术指标，再决定从哪一层入手，才是正确的打开方式。

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 发行版都能一条命令装齐：

这里特别说一下 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 在等待磁盘 IO；b 列高说明进程因为 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%，这是网卡中断不均导致的典型现象。多队列网卡如果没启用 RSS（Receive Side Scaling），或者驱动不支持多队列，所有收包中断可能集中在同一个 CPU 核上，导致软中断处理不过来，表现为网络吞吐上不去、延迟抖动。

查看方法：top 里按1看每个核的使用率，如果某个核 si 占很高，而其他核空闲，基本可以确认是这个原因。再用cat /proc/interrupts看中断向量在各 CPU 上的分布，会更直观。

处理方式一般有两种：一是确认网卡多队列已开启，二是配置 RPS（Receive 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这一大类错误，本质都是“连接状态与双方预期不一致”。以后遇到这类问题，我的排查顺序固定如下：

1. 抓包看 RST / FIN 是谁发的、发生在哪个阶段。
2. 检查双方超时配置（空闲超时、读超时、写超时）。
3. 检查连接是否空闲过久，NAT 会话是否老化。
4. 检查应用读写缓冲区和线程池是否有积压。

不要一上来就怀疑机房抖动或带宽不足。虽然确实存在硬件链路故障导致断连的情况，但大多数偶发断连问题，最后查下来都是连接治理和应用层处理策略的问题。

6. 实战心得：排查顺序、误判陷阱与常用命令速查

这一节算是我个人经验的沉淀，也是排查完大量问题后总结出来最值得分享的部分。

6.1 推荐的排查顺序：四层走查，不要跳步

我推荐的排查顺序可以浓缩成“四层走查”：

1. 先看应用与监控：确认故障影响范围、精确到分钟的时间窗口、错误日志和链路追踪。这一步能过滤掉大量“假网络故障”。
2. 再看网络层：连通性、丢包、延迟、TCP 重传、连接数。
3. 再看系统层：磁盘 IO、CPU、内存、软中断、文件句柄。
4. 最后回到应用层：线程池、连接池、GC、慢查询。

很多人习惯跳过第 1 层直接开始 ping，结果查了半天，最后发现是当次发布导致的问题。每敲一条命令之前，先问自己：我现在想验证什么假设？验证完了结论是什么？带着问题去排查，比东一榔头西一棒子高效得多。

6.2 我踩过的误判陷阱

• 陷阱 1：ping 通了就觉得网络没问题。ICMP 可达不代表 TCP 端口通，更不代表应用层可用。要分三层做连通性测试。
• 陷阱 2：只盯平均值不看长尾。很多偶发问题平均延迟正常，但 P99 高得离谱。看监控要同时看 P50、P95、P99 和最大耗时。
• 陷阱 3：日志时间不同步。多台机器日志时间不一致，案情还原直接崩掉。NTP 同步是排查的基础设施。
• 陷阱 4：抓包工具本身干扰业务。大流量场景下 tcpdump 自身可能丢包，要设置合理的 snaplen，只抓需要的端口，避免全端口抓包。
• 陷阱 5：IO 性能下降先怀疑硬件。多数 IO 问题其实是日志膨胀、数据库慢查询、swap 抖动导致的，先用 pidstat 找“谁在写”比换硬盘更重要。
• 陷阱 6：忽视连接数。文件描述符或 TCP 连接数打满时，新连接无法建立，现象极像网络故障，但本质是资源耗尽。

6.3 常用排查命令速查表

把这篇涉及的命令汇总成一张表，方便直接截图保存：

6.4 最后一个建议：沉淀自己的排查模板

每次故障解决后，我都会做一件事：把现象、影响范围、时间窗口、拓扑图、关键配置、抓包结论、根因、修复动作和验证结果整理成一个固定模板的文档。刚开始觉得麻烦，坚持半年后发现价值极大：很多新问题其实是旧问题的变体，翻历史记录就能快速定位方向。

推荐的排查模板字段可以参考这些：现象描述、影响范围、时间窗口、当前拓扑、关键配置项、抓包文件路径、命令输出摘要、根因结论、修复动作、验证结果、遗留事项。按这个模板积累三个月，再遇到网络与 IO 类问题，你就不会再像无头苍蝇一样从上到下挨个敲命令了。