网络排错，从分层开始
你在公司连不上外网，第一反应是重启路由器？还是直接打运维电话？其实，掌握网络协议的七层模型，很多问题自己就能定位。这个模型不是课本里的摆设，而是实际排错的路线图。
物理层：先看灯亮不亮
电脑没网，第一步别急着敲命令。看看网线插没插紧，交换机上的指示灯闪不闪。这就是物理层的事——电缆、光纤、接口、电压这些实实在在的东西。有时候，一根被踩扁的网线就能让你折腾半天，而解决方法只是换个位置插一下。
数据链路层：MAC 地址和交换机表
两台设备在同一个局域网里传文件，突然传不动了。这时候可能不是 IP 的问题，而是 MAC 地址没对上。交换机会记录每个端口对应的 MAC 地址，如果表满了或者出错，通信就断了。可以用 arp -a 看本地缓存的 MAC 映射，检查有没有异常条目。
网络层：IP 和路由才是关键
ping 不通远端服务器，但局域网正常？多半是网络层的问题。IP 地址配错、子网掩码不对、默认网关填了别人的地址，这些都常见。比如财务部新接了一台打印机，抄了别人配置但忘了改 IP，结果冲突导致整个楼层断网。
用 tracert（Windows） 或 traceroute（Linux/macOS） 能看到数据包走到哪一步卡住。如果第三跳就没响应，那问题大概率出在中间那台路由器或防火墙上。
传输层：端口和服务的关系
网站打不开，但能 ping 通 IP？可能是传输层的问题。TCP 或 UDP 没建立连接，常见原因是目标端口被防火墙拦了。比如你想访问一台 Web 服务器的 80 端口，但对方 iptables 规则没开，SYN 发过去没人回 ACK，连接就僵住了。
这时候用 telnet <IP> <端口> 测试最直接。能通说明服务开着，不通就得查防火墙或服务进程是否运行。
会话层与表示层：容易被忽略的环节
两个系统对接 API，数据格式明明一样，却一直报错。可能是在表示层出了问题——一方发的是 UTF-8，另一方按 GBK 解码；或者 JSON 数据加密方式不一致。这类问题在跨平台对接时特别多。
会话层管的是连接的建立和维持。比如视频会议中途频繁掉线，不一定网络差，可能是会话超时设置太短，中间设备主动切断了“空闲”连接。
应用层：用户看得见的地方
浏览器打不开网页，提示“无法建立安全连接”。表面上是应用层问题，但原因可能藏在下层。比如 HTTPS 请求发出去了，但 TLS 握手失败，这就涉及表示层的加密协商。再往下追，可能是时间不同步导致证书校验失败——这种细节往往让人摸不着头脑。
抓包看 HTTP 状态码也很有用。404 是资源不存在，502 是后端服务挂了，这些信息都在应用层体现，但背后可能牵扯到下层的服务发现或负载均衡配置。
实战中的分层思维
某次公司邮箱突然收不到邮件。有人说是服务器坏了，有人说是网络故障。用分层法一步步来：
1. 物理层：网线正常，指示灯闪烁；
2. 网络层：能 ping 通邮件服务器 IP；
3. 传输层：telnet 邮件服务器 25 端口不通；
4. 登录服务器查看，发现 postfix 服务没启动。
问题出在应用层服务未运行，但通过下层验证排除了网络问题，节省了排查时间。
网络协议七层模型不是理论摆设，每一层都对应着具体的故障点。下次遇到连不上、传不动、打不开的情况，不妨一层一层往上查，比瞎猜高效得多。