📚 课程目录第1章通信异常概述

1. 通信异常概述

各位好，我是老周。做通信故障排查这行快十五年了。今天咱们聊聊通信异常这件事。

很多人一遇到网络不通就慌了，到处乱试。重启路由器、拔插网线、改IP地址……折腾半天，问题还在。其实，通信异常没那么玄乎。只要搞清楚通信是怎么工作的，再按层去查，大部分问题都能快速定位。

我个人习惯，遇到任何故障，先问自己三个问题：通信模型是什么？问题出在哪一层？用什么方法论去查？ 这三个问题搞明白了，排查就成功了一半。

通信的本质，就是信息从源点传输到目的点。不管多复杂的网络，拆到底层，都逃不开这个基本模型：

信源 → 编码 → 信道 → 解码 → 信宿

再加上一个关键要素：噪声。噪声无处不在，它是通信异常的根源之一。

举个例子。你打电话给同事，你的声音（信源）经过手机编码变成电信号，通过基站和光纤（信道）传输，同事的手机解码还原成声音（信宿）。如果周围有干扰（噪声），声音就断断续续。这就是最朴素的通信模型。

我在项目里见过一个案例。某工厂的传感器数据经常丢包。查了半天，发现是传感器到网关的线缆和动力电缆走同一个线槽，电磁干扰把信号全吃了。说白了，就是信道噪声的问题。把线缆分开走，问题立刻解决。

这个模型告诉我们：排查异常，要从信源、编码、信道、解码、信宿、噪声六个维度去思考。缺一不可。

通信异常千奇百怪，但按层次分类，就清晰多了。我习惯按物理层、链路层、网络层、应用层来归类。你想想看，这四层几乎覆盖了所有你能遇到的故障。

层次	典型异常	常见表现
物理层	线缆损坏、接口松动、信号衰减、电磁干扰	完全不通、间歇性断连、速率异常
链路层	MAC地址冲突、VLAN配置错误、STP环路、CRC校验错	能ping通但丢包、广播风暴、端口反复up/down
网络层	IP地址冲突、路由黑洞、子网掩码错误、NAT失效	跨网段不通、路由跳数异常、traceroute卡住
应用层	DNS解析失败、HTTP 502、SSL证书错误、端口未开放	浏览器打不开、邮件发不出、API超时

我的经验：70%的通信异常其实出在物理层和链路层。很多人一上来就查应用层配置，折腾半天发现是网线没插紧。嗯，别笑，我见过太多这样的案例了。

我曾经处理过一个“瘫痪”的故障。所有业务都中断，领导急得团团转。我到了现场，先看物理层——机柜里的核心交换机，电源灯不亮。拔插电源线，还是不亮。最后发现是PDU（电源分配单元）的开关被保洁阿姨不小心碰到了。合上开关，恢复。前后不到两分钟。

这个故事告诉我们：从底层往上查，永远是最稳的排查路径。

说到排查方法论，就绕不开两个经典模型：OSI七层模型和TCP/IP四层模型。

OSI七层是理论上的“完美模型”，TCP/IP四层是实际网络用的“实战模型”。两者不矛盾，而是互补。我个人的排查习惯，是把两者结合起来用。

下面这张图，是我自己总结的通信异常排查分层对照图，你看一眼就明白了：

你看，OSI七层分得很细，但实际网络设备（交换机、路由器）只用到下面几层。TCP/IP四层更贴近实战。我排查故障时，脑子里同时装着这两个模型：

避坑指南：我曾经遇到一个案例，某业务系统间歇性超时。开发说是网络问题，网络说是应用问题，互相甩锅。我抓包一看，TCP三次握手正常，但应用层的数据包在某个字段上格式不对，服务器直接丢弃了。嗯，这其实是应用层的问题，但表现得很像网络层丢包。

教训：不要只看表象，要逐层验证。抓包是终极手段。

说了这么多理论，来点实际的。我个人总结了一套排查流程，简单粗暴，但很有效：

这个顺序，我用了十几年，从来没出过大的偏差。你想想看，物理层都不通，你查应用层配置有什么用？

小技巧：我习惯在工位上常备一根已知完好的网线和一个USB转串口线。很多物理层问题，换根线就能确认。串口线用来登录交换机看日志，比远程SSH靠谱多了——毕竟网络都不通了，你还想SSH？

好了，这一章的内容就到这里。通信异常排查，说白了就是分层定位、逐层验证。记住这个核心思想，后面的章节我们会深入到每一层的具体排查技巧。