先补一个背景看到“回购协议卡顿不一定是网卡”这个标题我第一反应是语音识别把 RPC 听岔了。RPCRemote Procedure Call远程过程调用是分布式系统里最常见的一种调用方式Windows 域环境里的很多通信、Linux 上的 gRPC/Thrift以及各类微服务之间的同步调用底层都离不开它。所以大家说 RPC 卡顿的时候真正想表达的是接口偶尔超时、登录域控很慢、批量任务经常失败但服务端日志里往往看不到明确报错。这篇文章要解决的问题是当“RPC 协议卡顿”这类现象出现时如何用一套可复现的排查流程快速判断卡顿到底发生在网卡、DNS、链路还是应用层。适合长期跟服务器、域控、虚拟机打交道的运维和 SRE也适合第一次接手“间歇性卡顿”问题的新手拿来当排查清单。先给出结论真正的网卡硬件故障远没有你想的那么多。1. 先明确问题边界卡顿不一定等于丢包1.1 网卡真的出故障时会有什么表现先别急着找换网卡的理由先看证据。传统意义上的网卡故障通常会出现以下可观察特征中的至少一种网卡速率协商明显降级比如千兆口变成了百兆甚至百兆口不停 up/down系统网卡统计里出现大量rx_crc_errors、rx_missed_errors、rx_fifo_errors、tx_timeout传输接口计数器显示errors、dropped持续增长重启网卡后短暂恢复过一会儿又涨dmesg或 Windows 事件日志里反复出现Link is down、tx timeout、NETDEV WATCHDOG之类记录。在 Linux 上ip -s link可以看到所有网卡的收发统计重点看errors和dropped两列。ethtool -S eth0能看到更细的硬件计数器比如 CRC 错误、missed packets、tx timeouts。在 Windows 上PowerShell 里可以用Get-NetAdapterStatistics看 Received Discards 和 Outbound Discards也能用性能监视器里的Network Interface计数器。如果这些特征一个都没有尤其是错误计数器干干净净那就大概率不是网卡坏了。RPC 卡顿更常见的原因是DNS 解析慢、域控响应慢、TCP 握手重传、交换机丢包、虚拟化平台 CPU 排队、应用线程阻塞。这些都是“看起来像网络问题但实际上和网卡硬件无关”的典型场景。1.2 RPC 卡顿的常见误判我处理过不少工单前端同事反馈“RPC 超时”后端同事第一句话就是“物理机网卡不行换一张吧”。这种判断太草率。一次 RPC 调用要经过的环节非常多先做 DNS 解析再建立 TCP 连接可能还要做 TLS 握手、Kerberos 票据验证之后才把请求序列化发到服务端服务端处理完还要回包。网卡只是其中最底层的一小段。网络层零丢包、零延迟抖动RPC 照样可能慢到超时。比如服务端线程池满了请求在队列里排队数据库一条慢 SQL 把连接池打满客户端 GC 暂停导致心跳超时防火墙对 RPC 动态端口做了限制导致连接被重置这些都会表现为“RPC 卡顿”但和物理网卡没有直接关系。所以真正的排查顺序应该是先确认链路层有没有硬件级问题再看 DNS 和域名解析然后看交换机和虚拟化承载环境最后通过抓包把问题的层级锁定下来。下面按这个顺序拆开讲。2. 先用三组命令给网络栈做体检2.1 ping 怎么测才不是走过场很多人的习惯是 ping 网关四个包看着全通就说网络正常。这远远不够。RPC 卡顿往往是偶发性的可能是每秒几百个包里丢一两个也可能是延迟在某个时间段突然从 1ms 跳到 100ms。只 ping 四个包什么都测不出来。我的做法是持续压测一段时间比如连续 ping 100 个 1400 字节的包ping -c 100 -f -s 1400 192.168.1.1-f是泛洪模式间隔极短-s 1400是使用接近 MTU 的包大小这样能把链路层的问题放出来。判读标准很简单丢包率 0%最大最小延迟差不超过 2~5ms才算链路正常。如果网关正常而目标服务器丢包那就把mtr或traceroute跑一遍看丢包出现在哪一跳。这里有一个容易踩的坑ping 用的是 ICMP很多交换机对 ICMP 有单独的 QoS 限速策略ICMP 丢包不代表 TCP 数据包也丢。反过来ICMP 正常也不代表 TCP 稳定。所以 ping 只是第一步不能作为最终结论。2.2 链路速率和错误计数ethtool 是网卡判官Linux 下判断网卡物理状态最直接的工具是ethtoolethtool eth0重点看Speed和Duplex。比如网卡明明支持万兆协商出来只有千兆那说明链路或者对端设备有问题。再看ethtool -S eth0 | grep -i errorrx_crc_errors增长说明物理层有丢帧或者网线质量不好rx_missed_errors增长说明网卡接收队列不够或者驱动处理不过来tx_timeout出现说明网卡驱动可能已经假死基本可以直接换驱动或者换卡验证。还要养成看网卡队列和缓冲区配置的习惯ethtool -l eth0如果只有一个队列高并发下软中断都集中在一个 CPU 上RPC 延迟自然会抖动明显。这时候可以适当增加队列数或者用ethtool -L eth0 combined 8调整 RSS 队列。需要注意这个操作在不同驱动上支持程度不一样部分虚拟网卡不支持多队列改了会报错。2.3 打流测试把网卡和协议层分开ping 正常不代表带宽、队列、驱动都没问题。真正要区分网卡性能瓶颈和协议层问题需要打流。# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.100 -t 60 -P 8如果iperf3能跑到链路速率的 90% 以上说明网卡驱动、中断、队列、交换机链路基本都是好的。但这里有个非常容易被忽略的点RPC 业务大多是小包高并发关心的是延迟而不是带宽。所以打完带宽之后还要用小包高并发方式再测一轮。比如用ping -f -s 1400看稳定延迟或者用netperf的 TCP_RR 模式看短连接 RTT。短 RTT 抖动大才是 RPC 卡顿的典型信号。打流正常但短连接 RTT 不稳定问题就不在网卡硬件而在更上层的调度、防火墙策略或者接入交换机队列。3. 域名解析和域控配置是最容易踩的坑3.1 RPC 与 DNS 的关系远比你想的密切在 Windows 域环境里客户端要找到域控不是直连 IP而是通过 DNS 查询一个 SRV 记录比如nslookup -typeSRV _ldap._tcp.dc._msdcs.example.com这个过程慢一点整个域登录和 RPC 调用都会慢。很多运维只盯着网卡却忽略了客户端 DNS 指到了不可用的服务器或者在 DNS 服务器上存在过期的 DC 记录。Linux 环境也一样微服务通过服务发现获取地址如果 DNS 解析本身要 3 秒那 RPC 超时基本是必然的。所以 RPC 卡顿出现时第一件事不是换网卡而是先确认域名解析到底花了多久。Windows 上可以用Measure-Command { nslookup dc01.example.com }来粗略计算解析耗时Linux 上用time nslookup或者dig的查询时间字段。3.2 AD 域内多台 DC 时 DNS 该怎么配“AD 域内 3 台 DC 域控制器”是高频场景也是最容易配置错的地方。三台 DC 的 DNS 指向如果混乱比如某台 DC 把自己的首选 DNS 指向公网或者指向了一个已经故障的实例客户端在域控发现阶段就可能频繁超时。比较稳妥的做法是每台 DC 的首选 DNS 指向另一台正常 DC辅助 DNS 指向第三台或者本机回环地址127.0.0.1但无论如何不要把自己放在首位也不要把公网 DNS 混进域内解析链。这样做的原因是DC 之间需要互相解析对方的主机名和 SRV 记录如果首选 DNS 指向了不可达地址启动域控服务时可能一直超时。配置完之后用dcdiag /test:dns /v做一次完整验证。这个命令会检查每台 DC 上的 DNS 记录是否能被正确解析通常在域控故障排查里价值很高。如果 DNS 测试有报错先处理报错项再做 RPC 测试往往就好了。3.3 缓存和事件日志里翻线索很多 RPC 卡顿是“启动后第一次调用慢之后就好”。这种情况和 DNS 客户端缓存关系很大。Windows 客户端可以定期清理本地 DNS 缓存排查时直接执行ipconfig /flushdns Clear-DnsClientCacheLinux 上如果是 systemd-resolved就执行resolvectl flush-caches另外Windows 事件日志里Microsoft-Windows-DNS-Client会记录解析失败域控上的ActiveDirectory_DomainController事件日志会记录复制失败和 Kerberos 问题。不要只看应用日志这些系统事件往往是真正的根因。我之前遇到过一次“RPC 客户端间歇性连不上”的问题最后定位到是一台 DC 的 DNS SRV 记录被握手失败风暴刷掉清理缓存后重新注册 A 记录才恢复。4. 链路、交换机和虚拟化层的隐蔽故障4.1 双工失配与不涨网卡计数器的丢包网卡自身统计正常不代表中间链路没问题。我见过最多的情况是服务器网卡这边看着好好的但交换机端口上已经积累了海量错误。登录交换机看端口状态show interface GigabitEthernet 1/0/1重点看input errors、CRC、late collisions、runts。如果有持续增长的 CRC 错误先怀疑网线和水晶头再看这对端口的双工模式是否一致。半双工和全双工失配后延迟会随机变大但网卡上的计数器可能完全正常。还有一种情况是光电转换器。服务器从光模块转到电口再接网线只要中间某段网线老化就会出现偶发丢包。这类问题很隐蔽因为 ping 打出来的丢包率不高但 RPC 的 TCP 连接对任何一次重传都非常敏感一个小丢包就会让一次调用超时重试。4.2 MTU、巨型帧和 TCP 卸载RPC 卡顿不只是小包问题。当业务涉及批量传输、数据库大结果集、文件拷贝时MTU 不对会导致大包被丢弃表现就是小包通信完全正常大包传输频繁失败或者奇慢无比。测试 MTU 最直接的办法是带 DFDont Fragment位发送不同大小的包ping -M do -s 1472 192.168.1.100如果 1472 字节通继续加大如果中途开始丢包或超时说明路径上某个设备 MTU 小于当前值。这种问题不一定是网卡更多是交换机端口上的巨型帧配置不一致。两边都开了巨型帧但中间一台交换机没开就会出现“能通但不稳定”的现象。另一类是 TCP 卸载和网卡 GRO/TSO 的问题。驱动在开启gro、gso、tso后能把 CPU 占用降下来但部分驱动或者固件存在 bug高负载下会出现乱序、checksum 错误。为了验证可以临时关闭卸载功能ethtool -K eth0 gro off gso off tso off如果关掉之后 RPC 卡顿消失基本就是网卡驱动或者固件兼容性问题。注意这只是验证方法确认后应该升级驱动或固件再把卸载功能开回来不要长期关闭否则高并发下 CPU 会扛不住。4.3 虚拟网卡和宿主机的坑虚拟化环境里“网卡正常”和“虚拟网卡正常”是两回事。同一个宿主机上的两台虚拟机通信其实是在虚拟交换机内部走一圈物理网卡根本不参与数据转发。如果宿主机 CPU 饱和度太高或者内存大压力虚拟交换机会排队RPC 延迟就会飙升但物理网卡计数器完全正常。排查时先在虚拟机里看sar -n DEV或者mpstat -P ALL确认是不是某个 CPU 的软中断被打满。再去看宿主机层面的网络和 CPU 统计数据不要一头扎进物理网卡。VirtualBox 这类桌面虚拟化工具也经常出现 host-only 网卡消失尤其是 Windows 笔记本开着移动热点关机再开机之后虚拟网卡驱动会和新出现的无线虚拟接口冲突。这类问题不需要换物理网卡去设备管理器把隐藏的 VirtualBox Host-Only Ethernet Adapter 卸载再重新扫描硬件或者在 VirtualBox 全局设置里重建 host-only 网络即可。Linux 虚拟机还有一个很常见的坑克隆虚拟机之后网卡找不到。原因往往是/etc/udev/rules.d/70-persistent-net.rules里保存了旧网卡的 MAC 地址克隆后新网卡 MAC 对不上系统就默认不创建网卡接口。这种情况查看lspci | grep Ethernet能看到硬件但ip link列表里是空的。删掉规则文件重启或者用nmcli重新配置连接即可恢复。Rocky Linux 和麒麟 V10 这类系统同样会遇到兼容性配置问题特别是网卡开机不自启时要先检查ONBOOTyes是否设置。5. 从抓包结果反推卡顿到底在哪一层5.1 抓包位置和关键时间间隔网络体检做完还是找不到问题就必须抓包了。抓包的目的不是“看有没有封包”而是把卡顿归因到网络层、协议层还是应用层。最理想的方式是在客户端和服务端同时抓这样能对比同一段路径上包的出现时间。以 Windows 域环境为例RPC 通信经常涉及端点映射器端口 135 和后续动态端口。抓包可以先过滤到目标主机tcpdump -i any -nn -s 0 host 192.168.1.100 and tcp port 135 -w rpc-tail.pcap如果知道具体端口就直接抓那个端口减小文件体积。抓包需要覆盖卡顿发生的完整时间段建议持续时间在卡顿前后各留 30 秒以上方便对比。分析时盯住三个关键时间间隔TCP 握手时SYN发出到SYN-ACK返回的间隔反映网络 RTT 和服务端内核协议栈是否正常请求包发出到服务端第一个响应包返回的间隔反映服务端应用处理耗时请求期间是否伴随重传反映链路是否丢包。如果SYN到SYN-ACK稳定在几毫秒但请求到响应间隔已经到几秒那就已经说明问题不在网卡和物理链路而在服务端应用线程、数据库查询或者业务代码逻辑上。5.2 重传、乱序与零窗口怎么读Wireshark 里打开 pcap 文件先把tcp.analysis.flags这一列加上让异常包自动标红。常见的信号含义如下现象含义优先排查方向大量 TCP Retransmission链路丢包、对端不响应交换机错误计数、网线、防火墙策略DUP ACK 或 Out-of-Order路径乱序、负载均衡策略多链路负载、虚拟交换机、RSS 哈希Zero Window接收端缓冲区满应用不消费服务端线程池、内存、读取逻辑RST 包连接被强制关闭防火墙策略、应用主动拒绝、端口不通这里特别提一下如果抓包看到重传不要马上赖网卡。交换机端口缓存溢出、防火墙丢包、虚拟机网卡驱动丢包都会造成 TCP 重传。需要结合两端网卡计数器和交换机端口统计一起看才能判断丢掉的那个包到底发生在哪一段。5.3 抓包之后如何定位抓包只是工具关键是拿数据去对应。如果确认是服务端处理时间长就去翻应用日志、数据库慢查询、线程 dump。如果确认是 DNS 解析阶段慢就去修 DNS 配置。如果确认是 TCP 握手阶段丢包再去处理物理链路和中间设备。把“网卡”从嫌疑名单里摘出去很多问题反而好解决了因为你终于不用大海捞针。6. 高频故障速查表与几个真实案例复盘6.1 现象到排查方向速查表日常工单里我习惯把 RPC 卡顿相关现象做成一个速查表拿到问题先对号入座现象最可能原因第一步操作所有客户端都慢且出现在固定时间段DNS 缓存或批处理任务占用查 DNS 解析耗时、服务端定时任务内网 RPC 正常跨网段或跨机房慢防火墙策略、路由不对称抓包对比 SYN-RTT 和重传大包传输卡小包正常MTU 不一致ping -M do -s 1472网卡显示千兆但实际只有百兆速度网线线对不合格或协商降级ethtool eth0看 Speed虚拟机克隆后网卡消失udev 规则绑定旧 MAC删除持久网卡规则文件Windows 笔记本开热点关机后虚拟网卡消失虚拟网卡驱动冲突设备管理器卸载后重新扫描AD 域登录卡顿DC 的 DNS 配置问题dcdiag /test:dns /v连接特定 WiFi 才掉网卡信道宽度或省电模式冲突更新驱动关闭网卡省电和 EEE6.2 三个真实案例复盘第一个案例是 Windows 服务器 RPC 间歇性卡顿。服务器网卡统计非常干净ping只有 0.1% 丢包但每次卡顿都出现在固定线路的同一时间段。最后登录交换机看端口发现CRC errors在持续增长网线水晶头也有松动痕迹。换了一根网线、重新压了水晶头错误计数器归零RPC 再也没有超时。这个案例说明即使网卡计数器正常也不能排除物理层问题交换机端口的错误计数才是关键证据。第二个案例是 Ubuntu 系统克隆之后网卡找不到了。看起来特别像网卡硬件故障但lspci能看到网卡设备ip link却没有任何接口。原因就是系统里残留了旧网卡的 udev 规则新网卡 MAC 对不上系统拒绝创建接口。把/etc/udev/rules.d/70-persistent-net.rules删掉重启问题直接恢复。第三个案例是 AD 域内 3 台 DC客户端登录有时快有时慢。排查时nslookup返回了 3 条 SRV 记录但其中一台 DC 已经存在复制问题客户端轮询到那台 DC 时就会卡顿。最终用dcdiag /test:dns定位到那台 DC 的 DNS 指针配置错误修正并完成复制后RPC 恢复正常。这个案例是最典型的“网卡没事域控配置有问题”。7. 我常用的排查顺序和几条心得7.1 从现象出发的决策树经历过几次深夜排查之后我的固定顺序基本稳定下来这里直接分享给各位先确认现象范围是单台机器、某个网段还是全部客户端卡顿发生在固定时间还是毫无规律做链路体检ping -c 100 -f -s 1400、ethtool -S、iperf3打流一次性排除物理链路和驱动问题看 DNS 和域控状态nslookup查 SRV、dcdiag /test:dns /v处理解析和复制问题检查交换机端口错误计数和 MTU登录设备看端口统计而不是只看服务器端抓包分析把问题锁定在握手阶段、数据传输阶段还是应用处理阶段。这个顺序看起来繁琐但能避免很多无效操作。我见过太多人一上来就重装驱动、替换网卡结果问题原封不动。真正有效的排查都是先拿到数据再动硬件。7.2 一些容易被忽略的操作细节有几个细节在日常排查里特别值得留意。首先是网卡省电模式和 EEEEnergy Efficient Ethernet。笔记本和部分服务器网卡会在低流量时进入节能状态唤醒过程会造成偶发的几十毫秒甚至几百毫秒延迟。RPC 心跳这类小包最容易触发因为包太小、间隔太长网卡还没来得及唤醒。临时关掉网卡高级属性里的节能模式再用ethtool --set-eee eth0 eee off关闭 EEE卡顿往往能立竿见影地缓解。其次是驱动版本。换驱动前一定要先确认当前版本和网卡固件做好记录。有些问题不是网卡坏了而是驱动和系统内核版本不匹配。比如升级内核之后忘了重新编译网卡驱动导致模块加载失败系统会自动回退到通用驱动此时性能下降非常明显。还有 Windows 下多网卡的接口跃点Interface Metric问题如果 RPC 流量走了优先级更低的无线网卡表现就是延迟忽高忽低。用 PowerShell 里的Set-NetIPInterface -InterfaceMetric把有线网卡优先级调高通常能立刻稳定下来。最后想说的是排查卡顿最忌讳“凭感觉换硬件”。每做一步操作记录一次时间点和现象这个习惯在间歇性问题上特别重要。RPC 卡顿往往不会乖乖等着你复现你随手记下的那一条命令输出很可能就是解决问题的最关键证据。