凌晨两点盯着屏幕上那个“请求超时”一边换网线一边怀疑交换机端口坏了这是很多人接触网络的起点。后来排查得多了才发现真正让数据包走不通的往往不是物理层而是 IP 层的两件事编址和转发。编址决定了“你是谁、你在哪个网段”转发决定了“包去往下一跳找谁”。这两件事构成了网际协议的核心也是互联网能从几台机器长到今天这个规模的底层原因。这篇内容围绕 IPv4 的地址结构、子网划分、CIDR 聚合、路由表查找、最长前缀匹配、ARP 与二层封装、分片与 MTU 展开中间会带上可复现的命令实验和参数计算过程。刚入门网络的朋友可以照着敲一遍命令建立直觉有几年运维或开发经验的人可以重点看路由聚合、分片黑洞和排查那一部分这些都是文档里很少写、但线上真会咬人的地方。1. 先把 IP 层到底在干什么说清楚1.1 用快递分拣中心的比喻理解“转发”互联网的本质是“一堆互相不认识的网络靠一套共同规则拼起来”。IP 层在这套规则里扮演的角色非常像一个跨省快递的分拣中心网络。寄件人只需要写清楚收件地址目的 IP把包裹交给最近的网点默认网关网点不关心包裹里是什么只关心“这个地址应该往哪个方向甩”——发往华东的丢到 1 号传送带发往华南的丢到 2 号传送带。每个中转站只做一件事查表决定下一跳。这个“查表”就是转发。它有两个非常关键的特性。第一是逐跳独立每个路由器只看自己的表不知道也不关心上一个路由器怎么想的更不知道整条路径长什么样。第二是无状态路由器不记录“这个包我见过”来一个转一个。这两点带来了极强的扩展性——新增一个网络只需要让相邻的路由器知道怎么到达它不用通知全网每一台设备。但代价也很明显路径可能不对称包可能绕路也可能被丢弃而发送方毫不知情可靠性被推给了上层的 TCP。而“写清楚收件地址”这件事就是编址。地址不是随便编的它必须携带位置信息否则分拣中心无从判断方向。IPv4 用 32 位地址前一部分表示网络、后一部分表示主机中间那条分界线由子网掩码划定。理解了这一点后面所有的子网划分、路由聚合、最长前缀匹配本质上都是在玩这条分界线。1.2 编址和转发为什么必须放在一起看单独看编址很容易学成“算 IP 地址的数学题”单独看转发又容易学成“背路由表字段”。但这两件事是互相咬合的编址的结构决定了转发的效率。举个具体的例子。假设一个组织有 4096 台设备如果给它一段连续的地址 10.20.0.0/20对外只需要一条路由条目10.20.0.0/20就能把流量引过来。但如果这 4096 台设备散落在十几个不相邻的地址段里骨干网的路由表就要多出十几条记录。地址分配得有没有“聚合性”直接决定了全网路由器要维护多少条表项。今天的骨干网路由表规模在百万条量级能维持住靠的就是 CIDR 这种支持任意长度前缀、可以把连续地址块合并成一条的编址方案。反过来转发机制也约束了编址的自由度。因为转发是最长前缀匹配不是“精确匹配”所以地址块可以嵌套10.0.0.0/8是一条兜底路由10.20.0.0/20是更具体的路由两者同时存在时去往 10.20.5.5 的包会命中后者。这种嵌套设计让“默认路由 明细路由”成为可能也让网络可以分层管理——大区域一条粗路由小区域一条细路由各管各的。如果没有最长前缀匹配每台路由器都得存全量明细这就没法玩了。所以我在带新人的时候习惯把这两块绑在一起讲先讲地址结构里的“网络号/主机号”分界再立刻讲路由表怎么用这个分界做匹配。两块知识一旦连上很多原本要靠死记的东西就自然通了。2. 编址地址结构决定了转发效率2.1 掩码才是真正的主角很多人初学时会盯着 IP 地址看其实掩码比地址更重要。同样一个192.168.1.100配上/24意味着它在 192.168.1.0 这个网段里网关大概是 192.168.1.1配上/16就意味着它在 192.168.0.0 这个大网段里同网段的主机范围一下子扩到六万多台网关可能是 192.168.0.1。地址没变网络拓扑的含义完全变了。计算上有三个必须练到条件反射的换算掩码长度 n 对应主机位数 32 − n可用主机数是 2^(32−n) − 2减去网络地址和广播地址。每个 /n 网块的地址总数是 2^(32−n)网块的起始地址一定是这个大小的整数倍。网块边界可以用“块大小”快速算掩码最后一段的值 m块大小 256 − m。比如 /26 掩码最后一段是 192块大小就是 64网块起点是 0、64、128、192。我推荐一个口算习惯判断某个地址属于哪个网块不要转二进制直接用块大小做除法取整。例如判断 172.16.5.200/26 属于哪个网段块大小 64200 ÷ 64 3 余 8取整为 3起点 3 × 64 192所以网段是 172.16.5.192/26可用范围 172.16.5.193 到 172.16.5.254广播地址 172.16.5.255。这个算法在排查现场非常省时间不用掏计算器。注意主机位全 0 是网络地址全 1 是广播地址这两个都不能分配给主机。但 /31 和 /32 是例外——/31 用于点对点链路RFC 3021两个地址都可当主机用/32 用于回环或主机路由。老一些的资料会直接说“减 2”遇到 /31 就会算错。2.2 子网划分的完整计算过程假设拿到一段192.168.10.0/24需要拆成 4 个部门每个部门独立广播域问怎么划。第一步确定借位。要 4 个子网2^2 4借 2 位主机位做子网位新掩码长度 24 2 26即255.255.255.192。第二步列网块。块大小 256 − 192 64四个子网分别是子网网络地址可用主机范围广播地址可用数量子网 1192.168.10.0/26.1 – .62.6362子网 2192.168.10.64/26.65 – .126.12762子网 3192.168.10.128/26.129 – .190.19162子网 4192.168.10.192/26.193 – .254.25562总共可用 62 × 4 248 个比原来的 254 个少了 6 个——这是划分子网的固有损耗每多一个子网就多损失两个地址。这就是为什么不要为了“整齐”而过度划分。但现实里四个部门的人数往往不平均。财务 5 个人、研发 50 个人、市场 20 个人、会议室 8 个终端。这时候均分 /26 就浪费了。更合理的做法是VLSM变长子网掩码从大到小分配研发 50 台需要 2^6 − 2 62 ≥ 50用 /26192.168.10.0/26范围 .1–.62。市场 20 台需要 2^5 − 2 30 ≥ 20用 /27块大小 32从 .64 开始192.168.10.64/27范围 .65–.94广播 .95。会议室 8 台需要 2^4 − 2 14 ≥ 8用 /28块大小 16从 .96 开始192.168.10.96/28范围 .97–.110广播 .111。财务 5 台用 /29块大小 8从 .112 开始192.168.10.112/29范围 .113–.118广播 .119。剩下的 .120–.255 留作后续扩展或点对点互联。这里的关键原则是从大到小分配因为大块需要地址对齐如果先占了小块大块可能就找不到连续空间了。这个坑我在实际项目里踩过先给几个小部门分了 /28结果研发要一个 /26 时发现没有连续 64 个地址的块只能整体重排白折腾一晚上。2.3 CIDR 与路由聚合骨干网没被撑爆的原因早期 IPv4 是有类编址A 类 /8、B 类 /16、C 类 /24边界固定。这套方案的毛病是粒度太粗一个中型组织需要 500 个地址给 /24 不够给 /16 又浪费六万多。CIDR 取消了这个限制允许任意长度的前缀同时把“多条连续路由合并成一条”变成标准操作也就是路由聚合也叫超网。聚合的计算规则很简单找到多条路由的共同前缀把不一致的位全部归零。例如10.20.0.0/24 10.20.1.0/24 10.20.2.0/24 10.20.3.0/24第三段分别是 0、1、2、3二进制是 00000000、00000001、00000010、00000011前 6 位相同后 2 位不同。所以共同前缀是第三段的前 6 位加上前两段的 16 位合计 /22。聚合结果是10.20.0.0/22。这里有个硬性条件被聚合的地址块必须连续而且起始地址必须按聚合后的块大小对齐。10.20.1.0/24和10.20.2.0/24这两条能不能聚合成 /23不能。因为 /23 的块大小是 2起点必须是偶数段1 和 2 跨过了 10.20.0.0/23 和 10.20.2.0/23 的边界聚合后会把不属于它们的 10.20.0.0/24 和 10.20.3.0/24 也包含进来。如果这两个网段实际在别处使用就会产生路由黑洞——流量被引到错误的方向然后被丢弃。这个细节值得单独强调因为配置聚合的时候手滑一次故障范围可能是整个区域。我的习惯是聚合完立刻做一次反向验证用ip route get或者在线的前缀计算工具把聚合后的网段里每一个 /24 的首地址都查一遍确认它们确实都在本区域内。聚合带来的收益是实实在在的。假设一个区域有 16 个连续的 /24不聚合的话上级路由器要写 16 条聚合后只要 1 条 /20。全球路由表能维持在可接受的规模靠的就是这种层层聚合。反过来说如果地址规划做得很碎比如按部门随意分配、跨界申请那聚合就无从谈起最后全网设备都得扛着庞大的路由表。2.4 特殊地址和边界别踩线有几类地址在编址时必须心里有数地址段用途注意事项10.0.0.0/8、172.16.0.0/12、192.168.0.0/16私有地址不可在公网路由出境需做地址转换127.0.0.0/8本机回环整段都是回环不只是 127.0.0.1169.254.0.0/16链路本地自动获取地址失败时的兜底看到它基本等于“没拿到地址”0.0.0.0/8本网络/未指定作为目的地址有特殊语义不能当普通主机地址用224.0.0.0/4组播不能配置为单播接口地址240.0.0.0/4保留实验用途公网不可路由192.0.2.0/24、198.51.100.0/24、203.0.113.0/24文档示例写教程、做实验专用不会和真实网络冲突写实验和文档时我强烈建议只用上面那三段文档地址不要随手拿 1.1.1.1 或 8.8.8.8 举例。这两个地址在真实网络里有人用照抄到配置里可能真的把流量引出去。另外私有地址的选择也有讲究。很多组织图省事所有分支都用 192.168.1.0/24结果做站点互联时地址冲突只能做地址转换拓扑复杂度翻倍。比较稳妥的做法是按站点分大块比如总部 10.10.0.0/16、分支 A 10.20.0.0/16、分支 B 10.30.0.0/16每个站点内部再细分。这样将来做聚合、做策略都好办。3. 转发一个包穿越网络的全过程3.1 路由表长什么样每一列管什么在 Linux 上执行ip route你会看到类似这样的输出$ ip route default via 192.0.2.1 dev eth0 proto static metric 100 192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.10 10.20.0.0/22 via 192.0.2.254 dev eth0 proto static metric 50 10.20.5.0/24 via 192.0.2.253 dev eth0 proto static metric 50每一列的含义需要掰开default就是0.0.0.0/0前缀长度 0匹配一切作为兜底。via是下一跳地址必须和本机某个接口在同一网段否则解析不出二层地址。dev是出接口。proto kernel表示这条路由是内核根据接口地址自动生成的直连路由proto static是手工或路由协议下发的。scope link表示目的地就在本地链路上不需要经过网关。metric是度量值多条路由前缀长度相同时优先选 metric 小的。需要注意的一点路由表里不存目的主机地址只存前缀。转发时做的是前缀匹配不是精确查表。这就是最长前缀匹配的由来。3.2 最长前缀匹配的全流程拆解假设上面那张路由表现在有一个目的地址为10.20.5.88的包要发出去。转发引擎的处理顺序大致是这样第一步从路由表里找出所有匹配该地址的条目。0.0.0.0/0匹配任何地址都匹配10.20.0.0/22匹配10.20.4.0–10.20.7.25510.20.5.0/24匹配。三条候选。第二步选前缀最长的。/24比/22比/0都长所以选10.20.5.0/24下一跳 192.0.2.253。第三步TTL 减 1。如果减完变成 0丢弃并向源地址回一个 ICMP 超时报文这就是 traceroute 的原理。第四步重新计算 IP 头校验和因为 TTL 变了。注意只重算头部校验和数据部分不管。第五步查 ARP 表拿到下一跳的 MAC 地址。如果 ARP 表里没有就发 ARP 请求把包暂时排队或者直接丢掉取决于实现。第六步封装成二层帧发出去。在 Linux 上可以直接观察这个决策结果$ ip route get 10.20.5.88 10.20.5.88 via 192.0.2.253 dev eth0 src 192.0.2.10 uid 0 cacheip route get是我最常用的排查命令之一它会把内核实际选中的路由、出接口、源地址一次性打出来比人肉比对路由表快得多。带上from参数还能指定源地址看选路结果$ ip route get 10.20.5.88 from 192.0.2.10如果返回unreachable或者和预期不一致问题基本就定位在路由表或者策略路由上了。第五步里有个容易忽略的细节下一跳必须能解析出二层地址。如果路由写的是via 10.99.99.99但本机没有任何接口在 10.99.99.0 网段这条路由会直接被标记为不可用包发不出去。配置静态路由时把下一跳写成“对端设备的接口地址”而不是“对端设备所在网段的网关”是新手最常见的错误之一。3.3 ARP最后一公里的地址翻译IP 地址是逻辑地址真正在以太网上传输要靠 MAC 地址。ARP 干的就是这个翻译工作广播问“谁有 192.0.2.1”对应主机单播回“我有我的 MAC 是 xx:xx:xx:xx:xx:xx”。结果进 ARP 缓存有老化时间Linux 默认约几十秒到几分钟具体看内核版本和配置。ARP 有几个必须知道的行为特征只在同一广播域内工作。跨网段是解析不出来的所以网关地址必须和本机同网段。请求是广播应答是单播。广播帧会被同网段所有设备收到这也是 ARP 欺骗的土壤。缓存有老化。地址变了但缓存没更新会出现短暂的“能 ping 通但业务不通”等老化后自愈。查看和清理$ ip neigh show 192.0.2.1 lladdr 52:54:00:12:34:56 REACHABLE 192.0.2.254 lladdr 52:54:00:ab:cd:ef STALE $ sudo ip neigh flush dev eth0STALE状态不代表条目没用只表示“最近没确认过”真正发包前会重新探测。看到FAILED或者INCOMPLETE就要警惕了通常意味着同网段那台设备没开机、掩码配错、或者被隔离了。一个很隐蔽的坑同网段两台机器掩码不一致。A 配 /24B 配 /25。A 认为 B 在同网段直接 ARP 找 BB 能收到并回复但 B 认为 A 不在自己网段因为 /25 把网段切小了回复时会走网关。结果就是 A 能 ping 通 BB ping A 却不通或者通得时断时续。这类问题在换设备、改配置后特别容易出现排查时第一件事就是核对两端的掩码。3.4 分片与 MTU最容易背锅又最难查的一环以太网的标准 MTU 是 1500 字节指的是帧里数据部分的上限。IP 包如果超过这个长度在 IPv4 里可以分片也可以由发送方提前分好。这里有一串必须记住的数字关系IP 头最小 20 字节所以 IP 载荷上限 1500 − 20 1480。TCP 头最小 20 字节TCP 有效载荷MSS上限 1480 − 20 1460。UDP 头 8 字节UDP 载荷上限 1480 − 8 1472。ICMP Echo 头 8 字节ping的-s参数最大 1472 才能不分片。验证方式# 允许分片发 2000 字节能通 $ ping -c 2 -s 2000 192.0.2.1 # 禁止分片发 2000 字节应当失败并提示需要分片 $ ping -c 2 -M do -s 2000 192.0.2.1 ping: local error: message too long, mtu1500 # 恰好 1472应当成功 $ ping -c 2 -M do -s 1472 192.0.2.1这三个命令组合起来就是现场定位 MTU 问题的标准手法。如果 1472 通、1473 不通说明链路 MTU 就是 1500正常如果 1400 通、1450 不通说明中间某段链路的 MTU 被压到了 1400 左右常见的如某些封装链路、拨号链路。二分法找临界值几轮就能定位。更麻烦的是MTU 黑洞路径中间某台设备 MTU 较小它应该回一个 ICMP“需要分片”的报文让发送方调小但如果这个 ICMP 被策略拦掉了发送方永远收不到反馈。表现出来就是小包一切正常SSH 能连上但一传大文件、一开 HTTPS 就卡死浏览器转圈然后超时。这种故障最难查因为 ping 永远通、telnet 端口永远通。我的排查套路是用ping -M do -s二分找路径 MTU。如果发现实际 MTU 小于 1500 且不可调就把本机的 MSS 钳一下。服务端和客户端都要看别只改一边。Linux 上钳 MSS$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu或者在路由上直接指定接口 MTU$ sudo ip link set dev eth0 mtu 1400改接口 MTU 会影响到所有经过该接口的流量属于比较重的手段MSS 钳制只影响 TCP 握手粒度更细。生产环境我优先用后者改完记得观察一段时间的建连成功率。4. 动手实验一台机器上把编址和转发跑一遍4.1 用 network namespace 搭一个最小拓扑不需要虚拟机、不需要额外硬件一台 Linux 就能完整复现“两个网段 一个路由器”的场景。原理是用 network namespace 隔离出独立的网络栈用 veth pair 把它们连起来——veth pair 就像一根网线一头插在一个 namespace另一头插在另一个。拓扑设计hostA(192.0.2.2/24) --- router(192.0.2.1/24, 198.51.100.1/24) --- hostB(198.51.100.2/24)hostA 在 192.0.2.0/24hostB 在 198.51.100.0/24中间 router 各连一边负责转发。这里用的都是文档保留地址不会和真实网络冲突。创建脚本# 三个网络命名空间 sudo ip netns add hostA sudo ip netns add hostB sudo ip netns add router # 两对 veth sudo ip link add veth-a type veth peer name veth-ra sudo ip link add veth-b type veth peer name veth-rb # 分别塞进对应的 namespace sudo ip link set veth-a netns hostA sudo ip link set veth-ra netns router sudo ip link set veth-b netns hostB sudo ip link set veth-rb netns router # 起回环和物理口 for ns in hostA hostB router; do sudo ip netns exec $ns ip link set lo up done sudo ip netns exec hostA ip link set veth-a up sudo ip netns exec hostB ip link set veth-b up sudo ip netns exec router ip link set veth-ra up sudo ip netns exec router ip link set veth-rb up4.2 配地址、配路由、开转发# hostA sudo ip netns exec hostA ip addr add 192.0.2.2/24 dev veth-a sudo ip netns exec hostA ip route add default via 192.0.2.1 # hostB sudo ip netns exec hostB ip addr add 198.51.100.2/24 dev veth-b sudo ip netns exec hostB ip route add default via 198.51.100.1 # router 两侧地址 sudo ip netns exec router ip addr add 192.0.2.1/24 dev veth-ra sudo ip netns exec router ip addr add 198.51.100.1/24 dev veth-rb # 关键一步打开内核转发 sudo ip netns exec router sysctl -w net.ipv4.ip_forward1net.ipv4.ip_forward1这一步是新手最常漏的。配完地址、配完路由两端 ping 不通八成就是转发没开。内核默认关闭转发是有道理的——一台普通主机不应该莫名变成路由器。做实验时可以直接改但在真实设备上改这个参数前要想清楚一旦开了这台机器就会对收到的所有包做转发判断可能带来意料之外的路径。配完之后验证$ sudo ip netns exec hostA ping -c 3 198.51.100.2 PING 198.51.100.2 (198.51.100.2) 56(84) bytes of data. 64 bytes from 198.51.100.2: icmp_seq1 ttl63 time0.048 ms 64 bytes from 198.51.100.2: icmp_seq2 ttl63 time0.051 ms 64 bytes from 198.51.100.2: icmp_seq3 ttl63 time0.047 ms注意 TTL 是 63 而不是 64说明中间经过了一跳转发这是转发生效最直接的证据。如果 TTL 还是 64那要么没走 router要么路由配错了。4.3 观察转发过程把黑盒打开实验环境最大的价值是可以随便抓包。在 router 的两个接口上同时抓能看到一个包进去、改了 TTL、再出来sudo ip netns exec router tcpdump -i veth-ra -nn -v icmp sudo ip netns exec router tcpdump -i veth-rb -nn -v icmp sudo ip netns exec hostA ping -c 1 198.51.100.2输出里能看到ttl 64从 veth-ra 进来ttl 63从 veth-rb 出去校验和也随之变化。这种直观感受比看十张图都管用。再做一个更有意思的观察在 hostA 上扔一个 TTL 很小的包看它在哪一跳死掉。$ sudo ip netns exec hostA ping -c 1 -t 1 198.51.100.2 From 192.0.2.1 icmp_seq1 Time to live exceededTTL 设为 1包到达 router 后减到 0router 丢弃并回 ICMP 超时源地址是 router 的入接口地址。traceroute 就是靠这个机制从 TTL1 开始递增把路径上每一跳的地址逼出来。顺便验证一下前面讲的最长前缀匹配。在 router 上加一条更细的路由sudo ip netns exec router ip route add 198.51.100.128/25 via 192.0.2.2 sudo ip netns exec router ip route get 198.51.100.200因为 198.51.100.200 落在了 /25 里而 /25 比直连的 /24 更长所以会走 192.0.2.2 这个下一跳而不是直连的 veth-rb。这个实验能让人对“最长前缀优先于直连”有非常直观的印象——很多人以为直连一定优先其实不是直连只是前缀长度 24遇到 /25 照样被覆盖。5. 常见问题与排查技巧实录5.1 一张速查表覆盖八成现场现象最可能的原因快速验证手段同网段能通跨网段不通缺默认路由 / 网关地址配错ip route、ip route get 目的地址能 ping 网关出不去转发未开 / 上层无回程路由在网关执行sysctl net.ipv4.ip_forward抓包看包是否被转出小包通大包不通MTU 不匹配 / ICMP 被拦导致黑洞ping -M do -s二分法时通时不通ARP 老化 / 双网关冲突 / 链路抖动ip neigh show、看 ARP 表是否频繁 FAILED单向通掩码不一致 / 防火墙状态化丢包核对两端掩码、conntrack -L看状态拿到 169.254 开头地址自动获取地址失败检查 DHCP 服务可达性路由环路静态路由互指 / 聚合过度traceroute看是否两地址来回跳间歇性丢包且无规律地址冲突IP 重复arping -D探测、看交换机 MAC 表是否漂移5.2 几个文档里不会写的排查心得先看路由再看防火墙最后看物理。这是顺序问题。很多人一上来换网线、换端口浪费大量时间。实际上ip route get一条命令就能把 90% 的选路问题定位掉。我习惯的排查树是能不能解析出下一跳路由层→ 下一跳能不能 ARP 到链路层→ 包发出去了有没有回来抓包→ 回来了为什么没被上层收到防火墙/监听。抓包要两端同时抓。只在一端抓包永远分不清“没发出去”和“发出去了但没回来”。在源端和目标端各抓一次对比一下问题立刻二分两端都有请求说明是回程问题目标端没收到说明是路径问题目标端收到了但源端没收到回复说明是回程路由或策略问题。ICMP 不是可有可无的。很多安全策略会一刀切拦 ICMP结果把“需要分片”“目的不可达”“超时”这些关键反馈全拦掉了MTU 黑洞和路径诊断统统失效。我的建议是至少放行 type 3目的不可达含 code 4 需要分片和 type 11超时这两类对网络自愈特别重要。聚合前先画图。路由聚合做错会造成大范围黑洞而且症状很诡异一部分地址通一部分不通看起来像随机故障。我的做法是把要聚合的地址段在纸上画出来标出每个 /24 的实际归属确认完全连续且对齐后再配。配完立刻用ip route get对首尾地址各验证一次。改 MTU 要改全套。只改一端不管用路径上所有相关接口、隧道封装、负载均衡健康检查的探测包大小都要一起考虑。我见过的情况是业务链路 MTU 改对了但健康检查还在发 1500 的探测包结果后端一直被判定为异常流量根本进不来。文档地址别乱用。写配置、做实验只用 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24 这三段。用真实公网地址做示例被谁复制到生产环境里就是一次事故。记录比记忆可靠。每次调整路由或地址把变更前后的ip route、ip addr、ip neigh输出存一份。出问题时对比一下能省掉大量猜测。这个习惯看起来笨但在多人数次交接的环境里价值极高。5.3 关于排障心态的一点体会网络排查最怕的是“凭感觉改”。改一个参数现象变了但不知道是参数生效了还是刚好赶上缓存老化这种“碰巧修好”最危险因为它会在几天后以另一种形式复发。我的做法是每次只改一个变量改完立刻用固定的一组命令复测把结果记下来。慢一点但每一步都是确定的。另外编址和转发这两块知识光看是学不会的必须动手。上面那个 namespace 实验从头到尾敲一遍大概二十分钟但建立起来的直觉能管好几年。我在实际工作中判断一个人网络功底如何经常就看他能不能不查资料说清楚“一个包从 A 到 B 中间 TTL 怎么变、ARP 在哪查、路由表按什么规则匹配”。这三件事答得清楚剩下的都是查手册的活。