3. 物理层与数据链路层排查:网线、网卡、交换机、Wi-Fi信号问题导致的超时

很多朋友遇到连接超时,第一反应就是抓包、看路由、调防火墙。但我得说句实话——至少有三成的超时问题,根源就在物理层和数据链路层。说白了,就是线没插好、网卡罢工、交换机端口挂了,或者Wi-Fi信号在跟你开玩笑。

这一章,咱们就把这些“底层”问题捋一遍。我保证,看完你就能自己动手排查,不用动不动就喊网管。

核心观点: 网络七层模型里,下面两层是地基。地基不稳,上面再折腾也没用。排查超时,永远从物理层开始。
物理层与数据链路层排查知识体系 超时排查(底层) 网线问题 网卡问题 交换机问题 Wi-Fi信号问题 水晶头接触不良 线序/类型错误 驱动/固件异常 协商速率不匹配 端口CRC错误 STP/环路阻塞 信号干扰/衰减 信道/频段冲突 排查顺序:先看物理层(网线/信号),再看数据链路层(网卡/交换机)

3.1 网线:最容易被忽略的“隐形杀手”

你想想看,是不是经常遇到这种情况:网口灯亮着,但就是ping不通?我告诉你,灯亮只代表物理层有电信号,不代表数据能正常传输。

网线导致超时的常见场景:

  • 水晶头接触不良: 插进去松松垮垮,或者卡扣断了。稍微碰一下,连接就中断几毫秒。TCP对这种瞬断非常敏感,直接触发重传,然后就超时了。
  • 线序错误: 特别是手工做的网线。我记得有一次,一个同事做了根交叉线当直通线用,结果百兆能通,千兆死活协商不上,丢包率高达30%。
  • 网线类型不匹配: 长距离传输用了细线芯的“省钱线”,或者用了四芯线(只有1236通)。百兆勉强能用,千兆直接废掉。
  • 老化或损坏: 踩过、压过、被老鼠咬过。这种线平时没事,一震动就断流。
我的排查习惯: 先看网口指示灯。如果Link灯闪烁不正常(比如频繁熄灭),或者Activity灯狂闪但数据不通,我第一件事就是换一根已知好的网线。别问为什么,问就是吃过亏。

怎么测? 用网线测试仪是最直接的。但如果没有,我教你一个土办法:把网线两端拔下来,重新插紧,听到“咔哒”一声才算到位。然后看协商速率——如果显示100Mbps但你的网卡和交换机都支持千兆,那八成是线的问题。

3.2 网卡:驱动、协商与硬件故障

网卡问题分三种:驱动层面、协商层面、硬件层面。咱们一个一个说。

3.2.1 驱动与固件

Windows下最常见。系统更新后,网卡驱动被自动替换成通用版,然后就开始丢包。我遇到过一台服务器,装完补丁后网卡间歇性断流,重装原厂驱动就好了。

Linux下可以用 ethtool -i eth0 查看驱动版本。如果发现驱动太老或者太新,建议回退到厂商推荐的稳定版。

# 查看网卡驱动信息
ethtool -i eth0
# 输出示例:
# driver: e1000e
# version: 3.2.6-k
# firmware-version: 1.8-0

3.2.2 协商速率与双工模式

这是个大坑。网卡和交换机之间需要协商速率(10/100/1000Mbps)和双工模式(半双工/全双工)。如果协商失败,或者一端强制一端自适应,就会产生大量冲突和CRC错误。

场景 现象 排查命令
协商速率不匹配 能通但极慢,ping延迟波动大 ethtool eth0 查看 Speed 和 Duplex
双工模式不匹配 丢包率高,CRC错误暴增 netstat -i 查看 Rx/Tx errors
网卡硬件故障 完全不通,或者间歇性断网 dmesg | grep eth 查看硬件报错
避坑指南: 我曾经在一家工厂里,所有设备都强制设为100M全双工,结果新换的一批交换机默认是自适应。两边一对接,丢包率直接飙到50%。排查了整整两天,最后发现是双工不匹配。从那以后,我坚持所有设备都用自适应,除非有特殊需求。

3.3 交换机:端口、CRC与环路

交换机层面的问题,很多时候不是交换机坏了,而是端口状态异常。

常见问题清单:

  1. 端口CRC错误: 用 show interface 查看。如果CRC错误持续增长,说明物理层有问题(网线、网卡、电磁干扰)。
  2. 端口被STP阻塞: 特别是新接入设备时,STP收敛需要时间。如果端口在Listening/Learning状态卡太久,就会导致临时超时。
  3. 环路导致广播风暴: 交换机之间形成环路,广播帧无限转发,瞬间打满带宽。所有设备都会间歇性超时。
  4. 端口安全/MAC漂移: 交换机检测到MAC地址在多个端口间跳动,会直接shutdown端口。

怎么查? 登录交换机,看端口统计信息。重点关注 CRC errors、collisions、runts、giants 这几个计数器。如果它们不为零,说明物理层或数据链路层有问题。

# 思科交换机查看端口状态
show interface gigabitEthernet 0/1
# 重点关注:
# Input errors: CRC, runts, giants
# Output errors: collisions, late collisions
个人经验: 有一次用户反馈“每天下午3点准时断网”。我查了所有设备都没问题,最后发现是保洁阿姨每天下午3点用拖把碰到了机柜后面的网线,导致水晶头松动。嗯,物理层的问题有时候就是这么“接地气”。

3.4 Wi-Fi信号:看不见的“隐形战场”

Wi-Fi比有线复杂得多。信号干扰、信道冲突、频段拥堵,任何一个环节出问题,都会导致超时。

Wi-Fi导致超时的典型场景:

  • 信号弱: RSSI低于-70dBm,丢包率明显上升。TCP重传增多,最终超时。
  • 同频干扰: 周围太多AP用同一个信道,尤其是2.4GHz频段。信道利用率超过50%时,延迟就会变得不稳定。
  • 隐藏节点问题: 两个客户端互相看不见,同时向AP发数据,导致碰撞和重传。
  • 客户端网卡兼容性: 老网卡连接新AP,或者新网卡连接老AP,可能出现协商速率异常。

排查工具:

工具 用途 平台
Wi-Fi Analyzer 查看信道占用、信号强度 Windows/Android
Wireshark 抓包分析重传、802.11管理帧 全平台
iPerf3 测试实际吞吐量,排除应用层干扰 全平台
我的建议: 如果条件允许,优先用5GHz频段。2.4GHz现在太拥挤了,蓝牙、微波炉、无线鼠标都在抢。我家里现在所有设备都走5GHz,2.4GHz只留给IoT设备。

3.5 实战排查步骤

好了,理论说完了。咱们来点实际的。当你遇到连接超时,按下面这个顺序查,基本不会漏。

  1. 看灯: 网口Link灯是否正常?Wi-Fi信号强度是否达标?
  2. 换线: 换一根已知好的网线,看问题是否消失。
  3. 查协商: 用 ethtool 或系统网络设置,确认速率和双工模式。
  4. 看计数器: 登录交换机,检查端口CRC错误、碰撞计数。
  5. 测Wi-Fi: 用Wi-Fi Analyzer看信道利用率,换一个干净的信道。
  6. 抓包确认: 如果以上都查了还不行,抓包看是否有大量TCP重传或Dup ACK。
最后提醒一句: 不要一上来就怀疑上层协议。先确认物理层和数据链路层是健康的。我见过太多人花几个小时调防火墙规则,最后发现是网线没插紧。嗯,真的不夸张。