网络这块东西刚上手的时候最容易犯的一个毛病就是把它当成一门“背诵课”——IP 地址长什么样、MAC 地址多少位、数据包怎么封装背得滚瓜烂熟可一旦让你画一张“两台机器隔着好几个网段通信数据到底怎么走的”图脑子立马就空了。我自己当年也是这样书翻了三遍真到抓包看流量的时候还是一脸懵。后来带过几个新人发现大家卡的地方高度一致不是记不住概念而是脑子里没有一张“从应用到网卡”的完整路径图尤其是中间那层“软件虚拟层”到底干了什么几乎没人讲得清楚。这篇东西就是想把这件事捋顺。核心讲三块跨网络传输的大致过程配上图解思路、IP 地址到底是个什么东西、以及 IP 和 MAC 这两个地址为什么非得同时存在。适合刚学网络基础的同学也适合工作几年但一直没把底层链路想明白的开发者——尤其是做后端、做容器、做虚拟化相关工作的软件虚拟层这块绕不过去。我会尽量用“数据从你键盘敲下去到对面屏幕亮起来”这条主线串起来中间该停的地方停下来讲原理该给参数的地方给具体数字能画图的地方用文字把图“讲”出来你照着在纸上画一遍基本就通了。1. 先把“跨网络”这件事拆成四段路来看很多人一上来就啃 OSI 七层模型啃完还是不知道数据怎么走。我的建议是先别管分层先把一次跨网络通信想象成“寄快递”分成四段路每段路的“交接方式”都不一样这样理解起来会顺很多。1.1 四段路的分段逻辑为什么必须切开看假设你在 A 城市的一台电脑上要访问 B 城市某台服务器上的一个网页。这中间物理上可能隔了十几台路由器、若干交换机。如果把它当成一整条路来看你会觉得“数据包怎么知道该往哪拐”这个问题无解。但切成四段就清楚了第一段本机内部从浏览器进程到本机网卡这一段根本没出机器走的是操作系统内部的软件栈第二段本机到本网关也就是你所在局域网内从你的网卡到路由器的 LAN 口第三段网关到对端网关这一段跨了多个网络是真正意义上的“跨网络”经过一堆路由器逐跳转发第四段对端网关到目标主机进入对方局域网最后送到服务器网卡。这么切的好处是每一段只关心“下一跳是谁”不需要知道全程。这跟寄快递一模一样——你只需要写清楚收件地址快递员只负责送到下一个中转站中转站再决定下一站没人需要记住从你家到收件人手里的完整路线。逐跳转发hop-by-hop这个思想是整个互联网能扩展到今天这个规模的根本原因也是理解跨网络传输的第一把钥匙。我见过不少人纠结“路由器怎么知道整个互联网的拓扑”其实它根本不知道也不需要知道。它只看目标 IP查自己的路由表找到“去这个网段该从哪个口出去、下一跳是谁”然后把包扔出去就完事了。这个认知一旦建立后面所有内容都会顺。1.2 每一段路上“地址”扮演的角色不一样四段路切开了接下来要理解一个关键点不同路段用的“地址”不是同一个东西。这就像寄快递包裹上写的是最终收件地址相当于 IP但快递员在分拣中心之间传递时靠的是每个中转站自己的内部编号和交接单相当于 MAC 在局域网内的作用。具体来说路段主要使用的地址作用范围谁负责解析本机内部无走本地回环或直接系统调用进程到网卡操作系统协议栈本机到网关MAC 地址局域网内同一广播域ARP网关到对端网关IP 地址逐跳变化的是 MACIP 不变跨网段路由表对端网关到主机MAC 地址局域网内同一广播域ARP这张表是整篇文章的骨架建议你抄下来。它说明了一个特别容易被忽略的事实IP 地址在整条路上基本不变NAT 场景除外而 MAC 地址每经过一个三层设备就会换一次。为什么因为 MAC 只在局域网内有效出了这个广播域就没意义了所以每到一个新局域网必须换成那个局域网内能识别的 MAC。这个点在后面第 4 节还会展开这里先埋个伏笔。1.3 用“寄快递”类比把封装和解封装串起来数据往下走的时候要一层层“套信封”往上走的时候要一层层“拆信封”这就是封装和解封装。还是用快递类比你写一封信应用层数据装进信封写上收件地址加 TCP/UDP 头形成段再装进快递袋贴上运单加 IP 头形成包最后装进车厢加 MAC 头形成帧发出去。到了每个中转站工作人员拆开外层车厢看看运单拆 MAC 头看 IP决定下一站然后重新装车换新 MAC 头继续发。只有到了最终收件人手里才会把信封拆开读到信的内容一路拆到应用层。这个类比里有个细节值得强调中转站只拆到“运单”这一层不会拆信封。对应到网络里路由器只处理到 IP 层不会去动 TCP 头和里面的应用数据。这就是为什么端到端的可靠性比如 TCP 重传必须由两端自己保证中间设备帮不上忙。理解了这一点你就能明白为什么“网络层不保证可靠交付”这句话不是缺陷而是设计上的取舍——把复杂性放在两端中间设备才能做得简单、跑得快。2. 软件虚拟层数据在出网卡之前到底经历了什么这一段是很多人最模糊的地方。大家知道“应用发数据、网卡发帧”但中间那一大坨软件到底干了啥说不清楚。我把它叫“软件虚拟层”是因为这一层里全是“虚拟”出来的东西——虚拟的接口、虚拟的缓冲区、虚拟的连接状态物理上你什么都看不到但每一步都实实在在影响着性能和排错。2.1 从 socket 到协议栈一次 write 调用背后的动作序列你在代码里写一句send()或者write()看起来是一个动作实际上内核里跑了一长串。以 TCP 为例大致是这样应用把数据拷进内核的发送缓冲区。注意write()返回成功不代表数据发出去了只代表拷进缓冲区了。这是新手最容易误解的点也是“为什么程序显示发送成功但对面没收到”的常见原因。TCP 层给数据分段、加头。根据 MSS最大报文段长度切分加上源端口、目的端口、序列号、确认号、窗口大小等字段。IP 层加 IP 头。填源 IP、目的 IP、TTL、协议号等。这里要做一件关键的事查路由表决定从哪个网卡出去、下一跳是谁。查 ARP 缓存拿下一跳的 MAC。如果缓存里没有就要先发 ARP 请求这个后面细讲。链路层加 MAC 头形成帧。交给网卡驱动驱动把帧塞进网卡的发送环形缓冲区ring buffer触发 DMA网卡硬件真正把电信号/光信号打到线路上。这一串动作里第 3 步和第 4 步是“软件虚拟层”的核心。路由表决定了“往哪走”ARP 决定了“交给谁”。这两个表都是纯软件维护的你在ip route和arp -a里看到的就是它们。我排查网络问题时第一步永远是看这两个表十有八九问题就出在这儿。提示write()返回的是“拷进缓冲区的字节数”不是“对端收到的字节数”。要确认对端收到必须靠应用层的确认机制别指望系统调用给你保证。2.2 路由表软件层怎么决定“下一跳”路由表这个东西说白了就是一张“目的地 → 出口”的对照表。Linux 上用ip route看典型输出长这样default via 192.168.1.1 dev eth0 proto static 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 10.0.0.0/8 via 192.168.1.1 dev eth0怎么读内核收到一个包拿目的 IP 去匹配遵循最长前缀匹配原则。比如目的 IP 是10.2.3.4它会匹配到10.0.0.0/8这条前缀长度 8走网关192.168.1.1如果目的 IP 是192.168.1.50匹配192.168.1.0/24前缀长度 24直接走 eth0不经过网关如果都不匹配就走default前缀长度 0最短所以是兜底。这里有个实操中特别容易踩的坑多条路由前缀长度相同时看 metric度量值小的优先。我遇到过一台机器配了两条默认路由metric 一样结果流量随机走两个网关时通时不通排查了半天才发现是路由冲突。所以配路由时要么保证 metric 有区分要么就别配重复的。还有一个概念叫“直连路由”就是上面192.168.1.0/24 dev eth0这种是网卡配了 IP 之后内核自动生成的scope 是 link表示“这个网段我直接能到不用网关”。这类路由你一般不用手动配但排查时要知道它存在因为它优先级往往很高。2.3 ARPIP 到 MAC 的那次“广播喊话”路由表告诉你“下一跳的 IP 是 192.168.1.1”但网卡发帧需要的是 MAC 地址这中间的转换就靠 ARP。过程很朴素本机广播一个 ARP 请求“谁是 192.168.1.1把你的 MAC 告诉我。”这个包的目的 MAC 是全 Fff:ff:ff:ff:ff:ff局域网内所有设备都能收到。目标设备单播回复“我是我的 MAC 是 xx:xx:xx:xx:xx:xx。”本机把这条映射存进 ARP 缓存一段时间内不再重复问。用arp -a或ip neigh能看到缓存。这里有几个实战经验值得说ARP 缓存有老化时间Linux 默认大概几十秒到几分钟具体看内核参数gc_stale_time等。缓存过期后要重新 ARP这会造成短暂延迟高频通信场景下影响不大但极端低延迟场景要留意。ARP 是局域网内广播跨网段问不到。所以如果你发现“能 ping 通网关但 ping 不通同网段另一台机器”八成是 ARP 出问题了先清缓存试试ip neigh flush all。免费 ARPGratuitous ARP常用于 IP 冲突检测和主备切换设备上线时主动广播自己的 IP-MAC 映射通知大家更新缓存。做高可用的时候这个概念很重要。2.4 虚拟网卡、网桥、命名空间容器场景下的“软件虚拟层”长什么样如果你做容器或者虚拟化上面这套“软件虚拟层”会更复杂一层因为网卡本身都是虚拟的。典型结构是物理网卡 → 网桥bridge→ veth pair一对虚拟网线→ 容器内的虚拟网卡。数据从容器出来先走 veth 到网桥网桥再根据 MAC 决定转发到哪个口最后从物理网卡出去。这里的关键认知是虚拟网卡和物理网卡在协议栈看来没区别一样有 MAC、一样参与 ARP、一样查路由表。所以你在容器里ip route、arp -a看到的和物理机上是同一套逻辑。区别只在于“线”是软件模拟的转发靠的是网桥的软件交换逻辑而不是硬件交换芯片。这也解释了一个常见现象容器网络性能不如物理机瓶颈往往不在协议栈而在 veth 和网桥这一段的软件转发开销以及可能的多次内存拷贝。优化方向通常是减少拷贝比如用零拷贝技术、或者绕过网桥直接走路由。这些属于进阶内容但底层逻辑还是那句话——软件虚拟层干的活本质是把“物理上要做的事”用软件重新实现一遍理解了物理链路虚拟链路就不难。3. IP 地址不是“门牌号”那么简单“IP 地址就像门牌号”——这个比喻流传太广但它其实误导了很多人。门牌号是固定的、唯一的而 IP 地址是分层的、可变的、甚至可以是共享的。把 IP 理解成“分层定位系统”更准确它同时承担了“标识一台主机”和“帮助路由器定位网段”两个职责这两个职责的张力正是很多网络设计的根源。3.1 点分十进制背后的二进制结构192.168.1.100这个写法叫点分十进制本质是 32 位二进制每 8 位一组转成十进制用点隔开。所以192 . 168 . 1 . 100 11000000 . 10101000 . 00000001 . 01100100为什么要懂二进制因为子网掩码、网段计算、CIDR 表示法全都建立在二进制之上。比如192.168.1.100/24这个/24表示前 24 位是网络位后 8 位是主机位。网络地址就是把主机位全置 0192.168.1.0广播地址是主机位全置 1192.168.1.255可用主机范围是192.168.1.1到192.168.1.254共 254 个。这个计算看着简单但实际排错时特别有用。我见过有人把两台机器配成192.168.1.10/24和192.168.1.200/25看着都在 192.168.1 段实际/25的网段是192.168.1.128到192.168.1.255跟/24的192.168.1.0到192.168.1.127根本不是一个网段互相 ping 不通太正常了。判断两台机器是否同网段不能只看前三段数字必须用掩码算。3.2 私有地址、公网地址与 NAT 的现实妥协IPv4 地址只有 32 位理论上约 43 亿个早就不够用了。解决办法之一是划出一批私有地址只在内部网络使用不直接在公网上路由地址段范围常见用途A 类私有10.0.0.0/8大型内网、云上 VPCB 类私有172.16.0.0/12中型网络、容器网络常用C 类私有192.168.0.0/16家庭、小型办公网络私有地址要访问公网必须经过 NAT网络地址转换把私有源 IP 换成公网 IP。这就引出一个重要认知IP 地址在整条路上“基本不变”这个说法在 NAT 场景下要打折扣。经过 NAT 设备时源 IP 会被改写回来的包再被改回去。所以严格说端到端的 IP 在 NAT 环境下并不是真正端到端的这也是为什么有些 P2P 应用在 NAT 后面会出问题。做开发的同学尤其要注意如果你在代码里依赖“对端看到的源 IP 就是我本机 IP”在 NAT 环境下这个假设不成立。日志里记录的客户端 IP 可能是 NAT 设备的地址真实客户端 IP 要靠应用层透传比如 HTTP 头里的转发字段。这个坑我踩过不止一次。3.3 子网划分的实际算法手算一遍就再也不会忘光看公式容易忘手算一遍最扎实。假设给你172.16.8.0/22要划分成能容纳 500 台主机的子网怎么算先看/22有多少主机位32 - 22 10 位主机数 2^10 - 2 1022 个。要 500 台需要 2^n - 2 ≥ 500n 至少 92^9 - 2 510。所以主机位留 9 位网络位就是 32 - 9 23 位即/23。/22能切成两个/23172.16.8.0/23范围172.16.8.0到172.16.9.255172.16.10.0/23范围172.16.10.0到172.16.11.255每个/23有 510 个可用地址满足 500 台需求。这个手算过程建议你自己拿几个网段练几遍练到看到/22就能条件反射出“1022 个地址、能切两个 /23”排错时速度会快很多。注意主机数计算永远要减 2因为网络地址和广播地址不能分配给主机。这个“减 2”在点对点链路/31和单主机/32场景下有例外但常规子网划分记住减 2 就行。3.4 特殊地址清单排错时能救命的那几个有几个特殊 IP 段平时不显眼出问题时全靠它们定位127.0.0.0/8回环地址127.0.0.1最常用。ping 它通说明本机协议栈正常不通说明协议栈或网卡驱动有问题跟外部网络无关。这是排查的第一步。0.0.0.0表示“本机所有地址”或“未指定”。服务监听0.0.0.0表示监听所有网卡路由表里的0.0.0.0/0就是默认路由。169.254.0.0/16链路本地地址。如果你看到机器拿到这个段的 IP基本可以断定 DHCP 没拿到地址是自动分配的兜底地址网络大概率不通。255.255.255.255受限广播地址只在本地网段广播不跨路由器。我排查“机器上不了网”的标准流程就是先 ping127.0.0.1确认协议栈再看 IP 是不是169.254段DHCP 问题再看路由表有没有默认路由最后看 ARP 和 DNS。这套流程走下来八成问题当场定位。4. IP 与 MAC为什么两个地址缺一不可这是被问得最多的问题之一“既然 IP 能定位主机为什么还要 MAC直接用 IP 通信不行吗”这个问题问得好答案藏在“分层”和“解耦”这两个词里。理解了这一层你对网络设计的理解会上一个台阶。4.1 从“谁负责送到”看两个地址的分工先给结论IP 负责“最终送到哪”MAC 负责“这一跳交给谁”。两者职责完全不同不能互相替代。打个比方你要从北京寄一份文件到广州某公司。收件地址IP写的是“广州市某区某路某号某公司”这个地址在整个运输过程中不变快递公司靠它决定最终送到哪。但文件在运输途中从北京分拣中心到石家庄中转站、再到郑州中转站每一段都是“北京站交给石家庄站的车”“石家庄站交给郑州站的车”这个“交给谁”是每一跳临时决定的相当于 MAC。你不可能在收件地址里写清楚“先交给石家庄站再交给郑州站”因为路线可能变、中转站可能调整写死了反而僵化。对应到网络IP 是端到端的逻辑地址跨越整个网络不变NAT 除外MAC 是链路层的物理地址只在当前局域网有效每过一跳就换。用 IP 做端到端定位用 MAC 做逐跳交付各司其职这是分层设计的精髓。4.2 如果只有 MAC 会怎样一个思想实验假设我们不用 IP只用 MAC 通信会发生什么MAC 地址是 48 位理论上全球唯一看起来“直接用 MAC 定位”也行。但问题在于MAC 地址没有层次结构。IP 地址是分层的网络位 主机位路由器可以只看网络位就把整个网段“打包”处理路由表能压缩到几十万条覆盖全球。而 MAC 是扁平的48 位里没有“你在哪个区域”的信息路由器要转发就得记住全球每一台设备的 MAC路由表会爆炸到不可维护。更致命的是MAC 地址跟硬件绑定换网卡就换 MAC设备移动位置 MAC 也不变但网络拓扑变了扁平地址根本无法表达“位置”。所以纯 MAC 通信在规模上根本行不通。这个思想实验说明地址必须分层才能支撑大规模网络。IP 的分层设计不是随便定的是被规模逼出来的。4.3 一次完整转发中两个地址的变化轨迹把前面所有内容串起来看一个包从 A 到 B 的完整轨迹重点盯 IP 和 MAC 的变化阶段源 IP目的 IP源 MAC目的 MACA 发出A 的 IPB 的 IPA 的 MAC网关1 的 MAC网关1 转发A 的 IPB 的 IP网关1 的 MAC网关2 的 MAC网关2 转发A 的 IPB 的 IP网关2 的 MAC网关3 的 MAC到达 B 网段A 的 IPB 的 MAC网关N 的 MACB 的 MAC看这张表规律一目了然IP 从头到尾不变MAC 每跳都换。这就是“端到端不变、逐跳变化”的直观体现。抓包的时候如果你在多个网段同时抓会看到同一个包的 IP 头完全一样但 MAC 头每段都不同这就是最直接的证据。这里补充一个细节TTL 字段每经过一个路由器减 1减到 0 就丢弃并回 ICMP 超时。这个机制防止包在网络里无限循环。traceroute就是利用 TTL 逐跳递增、收集每跳返回的 ICMP 超时包从而画出路径的。理解了 TTL你就理解了 traceroute 的原理也理解了为什么“网络环路”会导致包被丢弃而不是永远转圈。4.4 常见误解澄清MAC 唯一不等于 MAC 不可改最后澄清几个高频误解这些在面试和实际排错里都容易翻车“MAC 地址全球唯一所以不能改”错。MAC 唯一性靠厂商自觉分配软件层面完全可以改网卡驱动支持的话这叫 MAC 地址伪造。虚拟化环境里 MAC 更是随便配。唯一性只是“约定”不是“物理定律”。“同网段通信不需要 IP”错。同网段通信虽然最终靠 MAC 交付但发送方仍要用 IP 判断“是否同网段”拿目的 IP 和自己的掩码算判断完才决定是直接 ARP 目的 IP 还是 ARP 网关。IP 在这里承担的是“判断逻辑”不是“交付手段”。“交换机看 IP路由器看 MAC”反了。二层交换机看 MAC 转发三层路由器看 IP 转发。这个基础别搞混。“IP 地址能唯一标识一台设备”不完全对。NAT 后面一堆设备共享一个公网 IP负载均衡后面一个 VIP 对应多台机器。IP 标识的是“网络位置”不是“设备身份”。5. 把整条链路画在纸上一份可复现的图解思路前面讲了一堆概念最后落到“怎么画一张自己能看懂的图”。我不给你现成的图而是给你一套画图的方法你照着画一遍比看十张图都管用。这也是我带新人时最常用的训练方式。5.1 画图前的准备先确定三个要素动手画之前先把三个要素定下来否则画出来是乱的拓扑几台主机、几个网段、几个路由器。建议从最简单的开始——两台主机、两个网段、一个路由器先把这条链路画透。地址规划每个网段用什么 IP 段每台设备的 IP、网关、MAC 都标上。地址一定要具体别写“A 的 IP”这种占位符写192.168.1.10这种真实值画的时候才有代入感。通信方向明确是“A 访问 B”单向画别一会儿正向一会儿反向容易乱。我建议用纸笔画别一上来就用工具。纸笔慢但慢的过程就是思考的过程。等你能在纸上流畅画出来再用工具画就水到渠成了。5.2 分层画法一张图分三层叠上去我的画法是分三层从下往上叠第一层画物理拓扑主机、交换机、路由器、连线标上接口。这一层只关心“谁和谁连着”。第二层画地址在每个设备旁边标 IP、MAC、网关。这一层把第 3 节的地址知识用上。第三层画数据流用箭头标出包从 A 出发经过哪些设备每个设备上 IP 和 MAC 怎么变。这一层把第 4 节的转发轨迹用上。三层叠完一张完整的图就有了。关键是每一层只关注一件事别混着画混着画必乱。这个方法和软件设计里的“关注点分离”是一个道理画图也一样。5.3 用文字把图“讲”出来一个具体例子假设拓扑是主机 A192.168.1.10/24MACAA:AA→ 路由器 R1LAN 口192.168.1.1MACR1LWAN 口10.0.0.1MACR1W→ 路由器 R2WAN 口10.0.0.2MACR2WLAN 口192.168.2.1MACR2L→ 主机 B192.168.2.20/24MACBB:BB。A 要访问 B。数据流这样走A 拿目的 IP192.168.2.20和自己的掩码/24算发现不同网段决定走网关192.168.1.1。A 查 ARP 拿192.168.1.1的 MACR1L封装帧源 IP192.168.1.10目的 IP192.168.2.20源 MACAA:AA目的 MACR1L发出去。R1 收到拆帧看目的 IP192.168.2.20查路由表下一跳是10.0.0.2。重新封装源 IP 不变目的 IP 不变源 MAC 换成R1W目的 MAC 换成R2WARP 得到从 WAN 口发出。R2 收到拆帧看目的 IP192.168.2.20发现是直连网段ARP 拿 B 的 MACBB:BB。重新封装源 IP 不变目的 IP 不变源 MAC 换成R2L目的 MAC 换成BB:BB从 LAN 口发出。B 收到拆帧目的 MAC 是自己目的 IP 是自己往上递交给协议栈处理。你把这个过程在纸上画一遍每个设备旁边标上“进什么帧、出什么帧”IP 和 MAC 的变化就一目了然了。画完你会发现整个过程里 IP 一次没变MAC 换了三次A→R1、R1→R2、R2→B跟第 4 节的表格完全对得上。5.4 画完之后的自检清单图画完用这几个问题自检能答上来说明你真懂了如果 A 的 ARP 缓存里没有网关的 MAC第一步会发生什么答先广播 ARP 请求如果 R1 的路由表里没有去192.168.2.0/24的路由包会怎样答走默认路由或丢弃取决于配置如果 B 的网关配错了A 能 ping 通 B 吗答去程能到回程回不来表现为单向不通如果中间某台设备的 MTU 较小会发生什么答可能分片或触发 PMTUD表现为大包不通小包通这几个问题覆盖了 ARP、路由、网关、MTU 四个高频故障点能答上来说明你对整条链路的理解是完整的不是零散记忆。6. 几个我踩过的坑和对应的排查手法概念讲完最后分享几个真实踩过的坑。这些坑教科书上不会写但实际工作中遇到频率极高尤其是做后端和运维的同学早晚会碰上。6.1 “能 ping 通 IP 但 ping 不通域名”先分清楚是哪一层的问题这个现象太常见了。ping IP 通说明网络层及以下没问题——路由通、ARP 通、链路通。ping 域名不通问题一定在 DNS 这一层。排查顺序cat /etc/resolv.conf看 DNS 服务器配了没、配得对不对nslookup 域名或dig 域名直接测 DNS 解析看返回什么如果 DNS 服务器是内网的确认到 DNS 服务器的路由通不通检查是不是防火墙拦了 53 端口。我遇到过一次resolv.conf里配的 DNS 服务器 IP 是旧的早下线了但系统一直没报错只是解析超时后走备用慢得让人抓狂。这种问题不看配置文件根本发现不了。6.2 “同网段两台机器不通”优先怀疑掩码和 ARP同网段不通比跨网段不通更让人困惑因为“看起来应该通”。我的排查顺序是先算掩码拿两台机器的 IP 和掩码分别算网络地址确认真的同网段。前面说过/24和/25看着像同段实际可能不同段。再看 ARPip neigh看有没有对方的 MAC 记录。没有的话手动 ping 一下触发 ARP再看有没有。如果 ARP 请求发了但没回应可能是对方防火墙拦了 ARP或者中间有隔离比如交换机的端口隔离功能。最后看交换机如果是物理环境确认两台机器接的交换机端口在同一个 VLAN。VLAN 配错导致“物理同网段、逻辑不同广播域”的情况我见过不止一次。6.3 “改完 IP 后时通时不通”ARP 缓存没刷新这个坑特别隐蔽。你给一台机器改了 IP但同网段其他机器的 ARP 缓存里还留着旧 IP 对应的旧 MAC或者旧 IP 对应的记录没清导致流量发到错误的地方。表现就是“时通时不通”因为有的机器缓存刷新了有的没刷。解决办法改 IP 后在相关机器上清 ARP 缓存ip neigh flush all或者等缓存自然老化。更彻底的做法是改 IP 时发免费 ARP 通知大家更新。这个细节在做服务器迁移、主备切换时特别重要不做的话切换后会有几分钟的“抖动期”。6.4 “大包不通小包通”MTU 和分片问题ping 小包通、大包不通或者 SSH 能连上但传大文件卡死八成是 MTU 问题。链路中某一段的 MTU 比端到端协商的小大包被丢弃而 ICMP 的“需要分片”消息又被防火墙拦了导致发送方不知道要减小包一直重传大包。排查手法用ping -s 1472 -M do 目标IP1472 28 1500即标准 MTU逐步减小包大小找到能通的最大值就知道链路的实际 MTU 了。这个手法在跨运营商、走隧道比如 IPsec、GRE的场景下特别有用因为隧道封装会增加开销实际可用 MTU 比 1500 小。提示隧道场景下TCP MSS 需要相应调小否则会出现“握手成功但传数据卡死”的经典现象。这个坑在云上跨可用区通信时很常见。6.5 排查的通用心法从下往上逐层排除最后说个心法。网络排查最忌讳“猜”正确做法是从下往上逐层排除物理层网线、网卡状态→ 链路层ARP、MAC→ 网络层IP、路由、ping→ 传输层端口、防火墙→ 应用层服务、配置。每层用对应的工具验证验证通过再往上走别跳。这套方法看着笨但最可靠。我见过太多人一上来就怀疑应用代码查了半天发现是网线没插好。逐层排除虽然慢一点但不会漏而且每排除一层你就对这条链路多一分把握。排查完一次把过程记下来下次遇到类似问题直接照着走效率会越来越高。这套东西说到底核心就一句话网络传输是分层的、逐跳的、地址是分工的。把这三件事想透剩下的都是细节。图你自己画一遍坑你自己踩一遍比看多少篇文章都管用。
