1. 先定边界：网络层、IO层，还是两者叠加？
做故障排查这么多年，我最大的体会是：绝大多数网络与IO问题，不是“查不到”，而是“查错了方向”。一条超时日志摆在那里，有人去抓包，有人去看磁盘队列，有人去查交换机端口，最后发现真正的问题出在中间某个代理的闲置连接超时上——这种案例我见过太多次了。
所以这一章我会把第6章“网络与 IO 问题排查实战”里的方法，拆成一套可以直接上手用的排查思路。核心就一句话：先定边界，再动工具。
什么叫定边界？就是要先搞清楚：这个问题究竟是网络层引起的，还是IO层引起的，或者根本就是两层叠加放大的。
1.1 一条超时日志背后的两套排查路线
假设你收到一条报错：“stream disconnected before completion: failed to send websocket request: io error: peer closed connection with”。这句话信息量很密，别急着搜报错。
拆开看：
stream disconnected before completion：说明数据流没有完整传输完毕就断了。failed to send websocket request：说明是在发送WebSocket请求时失败。io error：这是一个IO层的异常标记。peer closed connection with：对端主动关闭了连接。
很多人一看到“IO error”就冲到IO层面去查磁盘，看到“websocket”就去查后端服务，看到“peer closed connection”就去查对端进程——结果三个人查了三个方向，谁也没法说服谁。
正确的做法是先判断：这个IO error到底是网络IO还是磁盘IO还是文件IO。在绝大多数网络编程框架里，“IO error”指的是网络套接字的读写失败，而不是磁盘读写失败。它背后真正的原因，往往还要再看网络层。
所以我建议，排查的第一步永远是问自己三个问题：
- 这个错误是偶发还是必现？
- 是在什么操作之后出现的？（重启、发消息、空闲一段时间、高并发…）
- 报错的进程和对端进程分别在哪个节点上？
这三个问题回答清楚了，边界基本就划出来一半。
1.2 分层三分法的具体操作
我自己的习惯是把排查分成三层：网络链路层、协议传输层、应用IO层。
网络链路层看的是物理连通性。从本机出发，经过交换机、路由器、防火墙到达对端，这一段有没有丢包、有没有延迟抖动、有没有MTU分片问题。用的工具是ping、mtr、网络测速工具，以及交换机侧的端口统计。
协议传输层看的是TCP/UDP行为。TCP连接有没有建起来、握手有没有完成、有没有反复重传、RTO（重传超时）有没有异常增长、连接有没有进TIME_WAIT出不来。这一层的排查往往要配合抓包工具。
应用IO层看的是进程内部的读写逻辑。缓冲区有没有设置太小、业务代码有没有同步阻塞、连接池有没有被耗尽、线程有没有卡在read上不返回，等等。
这三层不是独立的。举个例子：网络层丢包率不高，但如果TCP发送缓冲区设置过小，应用层的写入就会变慢；换一个更大的缓冲区，同样的网络条件，应用就不报超时。
所以排查时要带着分层思维去看，但最终要能串联起来解释整个链条。
1.3 热词里的“网络通信协议”和“IO约束”有什么用
这次为了保证内容更贴近真实排查场景，我特意检索了一批和“网络”“IO”“问题排查”相关的热词，其中“网络通信协议”“IO约束”“网络拓扑图”“网络调试助手”这几个词，我直接融进了下面的案例和工具流程里。实际上，这几个词也正好对应了排查时要准备的几样东西：懂协议、理清拓扑、备好工具。
网络通信协议不用背全，但TCP握手挥手、半开连接、Keep-Alive机制、WebSocket的帧结构和关闭握手这几个必须熟练。IO约束要理解的是，一个系统的IO能力是有上限的，文件描述符数量、连接数、缓冲区大小、磁盘队列深度、硬件IO驱动能力，这些都是约束。排查问题的时候，往往就是在这些约束条件里找哪个被突破了。
2. 网络链路排查：从丢包率到协议栈细节
2.1 用ping与mtr画出网络链路
网络问题的排查起点，永远是链路本身。我发现很多人有个坏习惯：一上来就对端开抓包，结果抓了一堆包，也不知道自己的包有没有到达对端。
先别急，按这个顺序来：
- ping本机网关：确认本机到网关没问题。如果这一步就有丢包，大概率是网卡、网线或者Wi-Fi信号的问题。
- ping对端IP：确认跨节点连通性。如果有丢包，就要考虑专线质量、防火墙策略、路由是否有黑洞。
- 用mtr双向跑一次：mtr集合了traceroute和ping的功能，能一跳到一跳地显示丢包率和延迟。重点看是某个中间跳点丢包，还是只有最后一跳丢包。
这里有个很实用的经验：如果mtr显示中间某个跳点丢包，但最终延迟没有明显上涨，很可能只是那个路由器不回应ICMP，不是真丢包。真正的网络问题，往往伴随延迟抖动明显，或者最后一跳丢包率飙升。
网络拓扑图在排查里非常重要。我看过不少团队，线上出了问题，连对端服务部署在哪台机器上都要临时去翻CMDB。如果有现成的拓扑图，把网络路径画出来，排查效率能高一倍。
2.2 抓包思路：先有个假设再抓，别盲抓
抓包是网络排查里绕不开的一步，但也是最容易被误用的。很多新手抓到包就开始翻，翻了半天不知道看什么。
我的习惯是：带着假设去抓包。
比如前面那条WebSocket错误，我怀疑是连接在空闲期间被中间设备断开，那我就在抓包之前，先让两端建立连接，不做任何操作，干等几分钟再尝试发送。看TCP层有没有收到RST或者FIN。如果干等期间收到了FIN/RST，那问题就变成“谁发的”和“为什么发”。
常用抓包工具我推荐两个：
- tcpdump：命令行抓包，适合在服务器上直接操作，开销小。
- Wireshark：图形化分析，适合离线分析pcap文件。
Windows上用“网络调试助手”这类工具做TCP/UDP收发测试也很快。特别是排查两台电脑之间的UDP通信问题，用网络调试助手一边发一边收，能很直观地判断是本机防火墙拦截、还是对端没有监听端口、还是中间NAT没有做端口映射。
抓包时要重点看几个信息：TCP的Flags、Sequence Number、Window Size，以及有没有大量重传包（tcp.analysis.retransmission）。
2.3 TCP状态机与UDP：两种完全不同脾气的协议
TCP和UDP在排查思路上差异极大。TCP有状态、有重传、有流量控制，问题往往藏在状态迁移和参数配置里；UDP无状态、无重传，问题常常表现为“发出去没有回应”。
TCP排查时，我会先看连接状态分布。在服务器上执行netstat -an | awk '{print $6}' | sort | uniq -c，看各个状态的连接数量。重点关注几类异常：
- 大量
TIME_WAIT：说明短连接关闭频繁，可能要靠连接复用或调整tcp_tw_reuse来缓解。 - 大量
SYN_SENT：说明主动连接方发出去的SYN没有得到回应，可能是对端没监听、防火墙丢包、或者半连接队列满了。 - 大量
SYN_RECV：说明对端收到了SYN但没法完成握手，往往是accept队列满了，应用层处理不过来了。
UDP的排查更依赖应用层配合。拿网络调试助手做对端验证，先确认UDP端口有没有监听、本机防火墙有没有放行。UDP还有个坑是MTU，数据报超过MTU就会在IP层分片，分片丢了整个数据报就丢了，而UDP层根本不知道。碰到大包不通小包通的情况，优先怀疑MTU。
3. IO链路排查：当性能下降和阻塞开始出现
3.1 怎么定位“IO性能明显下降”
很多人听到“IO性能明显下降了”这句话，第一反应是打开任务管理器或者top看一眼，但“明显下降”本身太模糊。到底是谁在说性能下降？是数据库写入慢了，还是文件读写慢了，还是网络吞吐低了？
我建议用工具先把IO性能指标拆出来：
- Linux：
iostat -x 1看磁盘的%util、await、svctm。如果%util长期接近100%，说明磁盘确实忙不过来。 - Windows：性能监视器里的
PhysicalDisk计数器，重点关注Avg. Disk Queue Length。 - 综合分析：还要看
iowait和进程的D状态（不可中断睡眠）。如果大量进程卡在D状态，说明在等磁盘IO返回，这时候CPU再空闲也没用。
这里要给个反直觉的提示：iowait高不一定就是磁盘坏了，也可能是文件系统设计问题、日志同步策略太激进，或者虚拟机磁盘在底层和其他虚拟机抢占资源。我踩过一个大坑，就是从物理机迁移到虚拟化平台之后，数据库写入时不时卡顿，查下来宿主机上的其他虚拟机在做大文件复制，共享存储的IO被占满了。
3.2 Java IO/NIO的线程阻塞线索
在语言层面，IO问题往往和线程状态直接挂钩。以Java为例，同样是网络IO，传统BIO（阻塞IO）和NIO（非阻塞IO）在排查方法上差异很大。
如果是BIO模式，服务端用一连接一线程，出问题时常表现为线程池被占满、大量线程阻塞在SocketInputStream.read上。你一看线程dump，满屏都是java.net.SocketInputStream.socketRead0，那基本可以断定连接数超过线程池上限了。要么扩容线程池，要么换成NIO模型。
NIO的问题则更隐蔽一点。NIO用Selector管理多路复用，最常见的坑是空轮询Bug，就是Selector在没有事件的情况下被唤醒，导致CPU飙高。排查方法是看到某个进程CPU飙高，但业务量并没有增长，立刻抓线程dump，看有没有线程一直在执行Selector.select。
还有一个更常见但容易被忽略的问题：缓冲区太小导致读写频次过高。Java里ByteBuffer.allocate(1024)和allocateDirect(64 * 1024)在同样吞吐下，系统调用次数差一个量级。系统调用本身有开销，次数多了，IO性能自然会下降。曾经有个项目，网关转发性能上不去，最后把每次读取的缓冲区从2KB调到8KB，整体吞吐直接翻倍。
3.3 硬件IO：从“io口输入”聊到“驱动能力”
热词里还有一批偏硬件的，比如“io口输入”“STM32 IO驱动能力”“FPGA的IO有没有类似ARM的模式”“推挽、开漏、上拉”。这说明IO问题排查不只是软件和网络的范畴，嵌入式场景里IO口本身的配置直接影响功能是否正常。
硬件IO排查有个思维和软件完全不同：软件IO看阻塞和性能，硬件IO看电气特性和模式配置。
比如STM32的PF0做IO口时，如果直接配置成浮空输入，而外部电路又没有明确拉高拉低，读到的电平就会飘忽不定。排查思路是看GPIO模式配置对不对：
- 输入场景：要用上拉/下拉/浮空中的哪一种，取决于外部电路默认电平是什么。
- 输出场景：推挽输出能同时提供灌电流和拉电流，适合驱动LED、蜂鸣器这类负载；开漏输出只能主动拉低，高电平全靠外部上拉电阻，适合电平转换和多设备共线。
推挽和开漏的区别，我经常用一个比方：推挽输出像一扇既能推又能拉的门，开漏输出像一扇只能往外推、拉回来要靠在墙上的门。墙上那根拉回来的绳子，就是上拉电阻。
还有一个高发问题：GPIO直接驱动大电流负载，结果拉不动或者把引脚烧了。因为单片机的IO驱动能力是有限的，比如STM32的GPIO典型灌电流20mA左右，你要驱动一个需要50mA的继电器，就必须加三极管或驱动芯片，不能直接怼。
4. Stream Disconnected类错误：网络与IO交叉的经典现场
4.1 把错误信息拆到不能再拆
这一节专门讲前面提到的那条报错，因为它太典型了，横跨了网络、协议、IO三个层面。在实际排查中，我见过不少团队被这条错误卡了大半天。
拆完整句之后，优先级排序是这样的：
peer closed connection with是最接近物理真相的一条。意思是：TCP对端主动发了FIN或者RST，把连接关掉了。failed to send websocket request说明了业务动作：我正在发一个WebSocket请求。io error只是把上面的现象归类为IO错误。stream disconnected before completion说的是结果：数据没传完。
所以排查终点不是“IO为什么错”，而是“对端为什么关闭连接”。
4.2 WebSocket断开排查五步
WebSocket是长连接，和普通HTTP短连接的处理方式不一样，很多坑都出在“长”上。我总结了一个五步排查法：
第一步，核对中间设备。WebSocket连接要穿过防火墙、负载均衡、网关，很多设备默认对空闲连接有个超时时间，比如300秒。连接一旦空闲超过这个时间，中间设备会偷偷把连接断掉。客户端不知道，还认为连接在，等下次发消息时，数据已经到了对端却被丢弃。
第二步，对比空闲断开和活跃断开的区别。如果只在空闲后断开，优先怀疑超时回收；如果活跃时也断，那就得看应用层有没有异常、消息体有没有超大帧、协议版本是否一致。
第三步，抓包确认谁先发的FIN。抓包后看时间线：是客户端先发FIN，还是服务端先发FIN，还是某台中间设备发了RST。这一步能直接把责任方锁定。
第四步，检查心跳机制。WebSocket本身有Ping/Pong帧，但要确认业务实现里真的用了，并且间隔要小于中间设备的空闲超时时间。比如中间设备300秒断开，心跳就最好90秒一次。
第五步，验证重连后的幂等性。断线重连本身不复杂，复杂的是重连后消息会不会重复发送、消费端能不能幂等。很多“偶发故障”其实不是断线那一下，而是重连后的数据不一致。
4.3 peer closed connection with背后的物理真相
peer closed connection with这句话，要说清楚它的物理含义：TCP关闭连接有两种方式，一种是正常的四次挥手，先发FIN，等对方ACK；另一种是异常重置，直接发RST。
如果是FIN关闭，通常是对端应用层主动调用了close或者退出进程。排查重点在对端应用为什么退出，看日志、看OOM、看进程重启记录。
如果是RST关闭，情况就复杂了，常见原因有：
- 对端端口根本没有监听，内核直接回RST。
- 对端应用崩溃，内核清理socket时发送RST。
- 中间防火墙对不允许的流量直接回RST。
- 本地发送的数据违反了TCP协议，比如往一个已经关闭的socket写入数据。
排查RST有一条捷径：看sequence number。如果RST的序列号正好匹配当前TCP流的位置，说明是正常拒绝；如果差异很大，可能是伪造的RST或中间设备注入的RST。不过这个判断需要抓包对比，不是看日志能看出来的。
5. 嵌入式IO组态实战：从HC_COUNTER到CC-Link地址映射
5.1 Factory IO与高速计数器的硬件组态
热词里有“factory io”“autoshop h5u 【hc_counter 传统高速计数器】io 硬件组态完整”，这些都是工业自动化里常见的场景。Factory IO是一个工业仿真软件，常和PLC编程配合使用。在仿真环境里跑通了，再到现场接真实设备，能省下大量调试时间。
以高速计数器HC_COUNTER为例，硬件组态的核心工作是：把物理输入点映射到计数器通道，再在PLC程序里配置计数模式。常见的坑是：端子接线明明对了，程序里读不到计数，结果发现是组态里没有启用快速输入滤波或者没有把通道对应的响应频率调到与实际传感器匹配。
工业现场的高速计数器，最常出问题的是干扰。传感器信号线如果和动力线走同一个线槽，高速脉冲容易被干扰导致计数丢失。排查时用示波器看输入波形，如果边缘有毛刺，就要考虑屏蔽线接地、信号隔离器、或者在组态里调整数字滤波参数。
5.2 STM32的PF0做IO口要注意什么
“stm32f30f4p6 pf0做io口”这个问题，我一看就很有共鸣，因为PF0/PF1这对引脚在不少STM32型号上默认是接外部晶振的，要当普通IO用，必须先把RCC的HSE旁路配置关掉。
具体排查步骤是：
- 确认芯片的PF0/PF1是否默认复用为OSC_IN/OSC_OUT。
- 如果是，需要在系统时钟初始化之前，或者合理配置时钟树，把这两个引脚释放成普通GPIO。
- 配置GPIO模式：输入还是输出，是推挽还是开漏，要不要上拉。
- 检查有没有复用冲突，比如调试接口、低功耗唤醒引脚等是否占用了同一个引脚。
很多人在这里栽跟头是因为只改GPIO初始化代码，没有关掉HSE相关配置，结果引脚电平一直被时钟电路拉着，怎么读都不对。
还有一个容易忽略的细节：引脚作为IO输入时，如果外部信号是高阻态，一定要配置内部上拉或者下拉，否则浮空输入会带来随机电平波动。
5.3 FPGA IO的模式选择与推挽开漏
热词里那句“fpga的io有没有类似arm的模式，推挽,开漏 上拉”，直接说明嵌入式圈子对FPGA的IO模式同样关心。
FPGA的IO和ARM的GPIO在概念上有类似的地方，但也有很大不同。FPGA里每个IO Bank往往支持多种电平标准，比如LVCMOS33、LVCMOS25、LVDS等，而且可以配置上下拉、驱动强度、施密特触发器。比如Xilinx的IO约束里，通过IOSTANDARD、DRIVE、PULLUP/PULLDOWN、SLEW这些属性来控制。
但FPGA和ARM有一个根本性区别：FPGA的IO行为是和逻辑代码绑定的，不像是GPIO寄存器那样独立出来。所以排查FPGA IO问题时，既要在约束文件（.xdc/.sdc）里看电气属性配置，也要看逻辑代码里对IO的操作时序。
我在FPGA项目里踩过的一个坑：IO约束里配了PULLUP，但逻辑代码里同时用三态缓冲器驱动同一个引脚，导致引脚状态互相打架。用示波器看波形就是一条不上不下的电平，数字逻辑读到0和1完全随机。
6. 一个综合案例：网络拓扑背后的“谁先断开”真相
为了把这些思路串起来，我用一个真实处理过的案例做复盘。希望能帮你在自己排查时，建立一条清晰的思考链条。
6.1 现象描述与初步判断
一个物联网网关项目，网关通过WebSocket连到云端平台，上报设备数据。某天开始，大量网关在每天凌晨2点左右集体掉线重连，业务方反馈数据上报中断了几分钟。
初步看，现象有三个特征：
- 掉线时间集中在同一时段，而不是分散在全天。
- 掉线前没有业务高峰，不是并发压力导致。
- 网关侧日志统一报“stream disconnected before completion: failed to send websocket request: io error: peer closed connection with”。
按前面第1节的定界方法，我第一反应是：这不像应用层崩溃或负载问题，更像是网络链路层的定时事件。于是决定从网络拓扑出发，查掉线时刻链路里发生了什么。
6.2 排查过程和证据链
第一步，我把网关的掉线日志、云端平台的连接日志、以及网络设备日志拉到一起，按时间对齐。
第二步，抓包。在网关侧和云端侧同时抓包，发现一个关键事实：在凌晨2点左右，网关并没有主动发FIN，云端也没有主动发FIN——但在TCP层，云端却收到了一个带RST标志的包。
第三步，追踪RST的来源。因为网关侧抓包里没有发出RST，云端的RST也不是自己发的，那就只剩中间链路。我们顺着网络拓扑找，发现网关和云端之间经过了一个运营商NAT设备，而那台设备正好在凌晨2点做定期会话回收。
真相浮出水面：运营商NAT设备对长连接会话有一个固定时长的空闲回收策略，凌晨2点是它批量清理的时间点。清理动作在TCP层表现为注入RST，连接就被重置了。
6.3 根因与修复方案
根因清楚了：不是我们的代码问题，而是中间网络设备的会话保持时间和业务心跳间隔不匹配。但它是一直存在的，为什么以前没爆发？因为以前心跳间隔短，NAT设备认为会话处于活跃状态，不回收；后来有一次版本升级，把心跳间隔调长了，超过了NAT设备的空闲回收阈值，于是每天定时被清。
修复方案就很明确了：
- 把心跳间隔改回去，或调整到低于中间设备会话超时时间的安全区间。
- 增加断线感知和快速重连机制，就算被断开，也要在几秒内恢复。
- 在服务端做消息幂等，重连后不会重复写数据。
这个案例很典型地说明了为什么我坚持“先定边界、再看拓扑、再抓包、再定位”这个顺序。如果一开始就去改网关重连逻辑，问题可能还是会在第二天凌晨2点再次出现。
7. 给排查新手的一套自检清单
最后，作为一个经常带新人排查问题的老工程师，我想分享几个我自己反复用的检查习惯。每次遇到网络与IO问题，我都会对照着过一遍，能省掉很多无效排查时间。
时间线对不对齐？ 所有日志、抓包、监控数据，先统一时区、统一时间格式。很多时候“查不到问题”是因为两边差了几分钟，把因果关系看反了。
拓扑图是不是最新的？ 排查前先确认：客户端到服务端之间到底有几层设备？有没有防火墙、NAT、负载均衡、WAF？每一层都可能成为故障点。
自己是偶发还是持续？ 偶发问题优先查超时、回收、重启这类周期性事件；持续问题优先查配置、资源耗尽、死锁。
有没有对比组？ 找一个正常的客户端或节点做对照组，和异常节点同时操作，对比差异。这个思路在硬件IO和软件IO问题上都极其有效。
抓包了吗？抓完整了吗？ 只抓应用层日志不抓TCP包，很多网络层问题会漏掉。反过来，只抓包不看应用行为，也可能被表象迷惑。
现在再看一遍开头那条报错，你是不是已经能快速判断出排查方向了？网络与IO问题表面上千变万化，但底层逻辑就那么多：链路、协议、状态、资源、超时。把这几个维度摸透，任何报错都只是这些维度的不同组合而已。
