守株阁

同一个目的前缀，一条候选路径只经过一个自治系统，另一条经过两个，为什么仍可能选择后者？若物理连接一直存在，删除一条导出策略为什么又可能让某个邻居失去路由？这两个问题都不能只用链路成本解释。 第 11 篇在统一成本的小图上讨论内部选路。本篇引入独立管理的自治系统，以及各自决定接收、选择和通告哪些路径的策略。实验完全离线，不建立 BGP 会话，也不连接公网邻居。 先区分地址前缀与自治系统路径 IP 转发面对的是目的地址和前缀。BGP 通告在网络可达信息之外携带路径属性，AS_PATH 是其中之一。目的前缀回答哪些地址属于这条路由，AS_PATH 描述路径涉及的自治系统信息，二者不能互换。 RFC 4271 §5.1.2规定 AS_PATH 的形式与修改规则。本篇只使用有顺序的 AS_SEQUENCE，不处理聚合产生的其他形态。简化例子中，C 起源前缀并向外通告，邻居看到路径 [C]；B 将从 C 学到的路径通告给 A 时，添加自己的 AS，A 看到 [B,C]。 这个列表不是 IP 报文逐跳携带的完整源路由，也不能直接换算成路由器跳数或物理距离。一个自治系统内部可能有多个转发节点。即...

一条链路断开后，剩余拓扑仍有可用路径，为什么报文可能暂时在两个路由器之间往返？最终最短路径存在，并不意味着各节点已经同时知道变化，也不意味着它们同时安装了相容的转发状态。 第 10 篇区分计算与安装。本篇把这个区别扩展到多个节点，用同一张三节点图比较两类信息传播方式：距离向量交换到目的地的距离，链路状态传播拓扑信息。实验是有界、确定性的教学模拟，没有运行 RIP 或 OSPF 守护进程。 先固定拓扑与故障 设无向链路 A-B 的成本为 1，B-C 为 1，A-C 为 5，目标是 C。这里的成本是算法输入，不是测得的时延、丢包率或带宽倒数。 1234 1 1A ───── B ───── C ╲ ╱ ╲──── 5 ────╱ 断链前，A 经 B 到 C 的成本为 2，比直接到 C 的 5 小；B 直接到 C 的成本为 1。删除 B-C 后，稳定答案应为 A 直接到 C，成本 5；B 经 A 到 C，成本 6。两种算法比较的是同一个删除事件，不能给其中一种额外保留一条链路。 这个最终答案可以手算，也可以在完整新图上计算。但分布式更新中，每...

路由计算已经选中了新的下一跳，为什么同一个目的地址仍然沿旧路径转发？如果配置接口返回成功，是否足以说明所有后续报文都会使用新路径？这两个问题都要求区分计算结果、已安装状态和实际查询结果。 第 07 篇给定一张表，验证最长前缀匹配。本篇继续使用那份教学转发器，但不再直接把候选路由全部交给它。候选信息先经过选择，再显式安装为转发快照。实验只输出决策，不配置内核路由，不发送真实报文。 同一目的前缀为何有两种信息 Routing Information Base（RIB）与 Forwarding Information Base（FIB）描述不同用途的信息。路由信息可以包含可供选择的候选路径；转发查询需要取得当前应使用的下一跳、出口等信息。两者有关联，但不能因为都包含前缀就将它们视为同一份状态。 RFC 3222 §5.3–5.4在路由器基准测试语境中说明 RIB 与 FIB。使用这些术语时应保留文档范围：它不是要求每台路由器必须采用两张物理表，也不能由其中对次选路径的描述推导出现代实现不能支持等价多路径。 设目的前缀为 10.6.2.0/24，候选 A 的下一跳为 192.0.2.1、...

短请求可以返回，稍长的请求却一直等待。这个现象能否证明链路存在 MTU 黑洞？如果在发送端看到了一个大包，而接收端没有看到它，又能否立即认定中间路由器按 MTU 丢弃了报文？ 第 07 篇解释了下一跳选择，第 08 篇区分了 IPv4 与 IPv6 的邻居发现和分片职责。本篇在路径中加入一个更小的出口，沿着报文长度、错误反馈与应用结果逐项判断。需要证明的不是“大包失败”这句话，而是哪个长度超过哪个限制、在哪里停止，以及发送者得到了什么信息。 先统一长度的口径 链路 MTU 限制的是该链路承载的网络层报文大小。在本篇的普通以太网/IP 实验中，接口配置的 MTU 与 IP 包长比较，不把以太网首部或帧校验序列加到 IP 长度里。应用写入的字节数也不是 IP 包长，还要加上传输层与 IP 首部。 设 IPv4 没有选项，UDP 首部为 8 字节，应用载荷为 D 字节，则 IP 总长度为 20 + 8 + D。IPv6 没有扩展首部时，对应长度为 40 + 8 + D。这两式的条件决定了计算结果；增加首部后不能继续套用原来的载荷上限。 中间出口 MTU IP 条件 UDP 载荷上...

目的地址变成 IPv6 后，主机还会广播 ARP 查询网关吗？一个接口已经有 fe80:: 开头的地址，是否说明它拿到了可跨网络通信的地址？收到路由器通告，又是否等于同时获得地址、直连前缀和默认路由？ 这些问题不能仅用“地址从三十二位增加到一百二十八位”回答。第 07 篇建立了前缀与下一跳的关系，本篇保持这一关系，观察 IPv6 如何表达地址范围、发现邻居和取得配置。真实实验使用静态地址，SLAAC 与路由器通告另以规范和条件表解释。 地址文本与作用范围 IPv6 地址通常写成八组十六位十六进制数。连续的零可以按规则压缩，但压缩只改变文本表示，不改变地址本身。例如 2001:db8:8:1::2 与展开后的八组写法是同一个一百二十八位值；前缀长度仍表示固定多少位。 本篇的 2001:db8:8:1::/64 与 2001:db8:8:2::/64 是两个不同的文档示例地址块，来自 RFC 3849 保留的范围，仅用于隔离实验。不会把它们配置到公网，也不因名字中出现 IPv6 就声称它们可被全球路由。 RFC 4291 §2.5.6定义链路本地地址范围 fe80::/10。这类地...

同一个目的地址同时命中默认路由、10.0.0.0/8 和 10.6.2.0/24，应该选哪一条？如果每次都采用表中的第一条，添加一条宽泛路由就可能改变所有细分网络的去向。最长前缀匹配用地址范围的具体程度解决这个问题。 第 06 篇已经观察过默认网关的 ARP。本篇向前一步，推导默认网关为何被选中，再用一个不发包的教学转发器检查路由选择、TTL 递减与错误决策。这里没有部署新的 Linux 路由拓扑，程序输出不能当作真实 ICMP 报文。 前缀表示哪些地址 IPv4 地址有三十二位。CIDR 的 /p 表示前 p 位固定，其余位可以变化，因此一个地址块包含 2^(32-p) 个地址。RFC 4632 §3.1用前缀长度表示地址块，不再依赖旧式 A、B、C 类地址边界。 10.6.2.0/24 固定前三个字节，范围是 10.6.2.0 到 10.6.2.255。这有 256 个地址，不等于在任何接口类型上都有 256 个可分配主机地址；地址块范围和链路上的地址使用规则应分开计算。 以 10.6.2.130/26 为例，最后一个字节的二进制值为 10000010，掩码最后一个字节为 ...

一台刚配置好地址的主机准备访问另一子网的服务。目的 IP 已经确定，但邻居表还是空的。此时需要查询远端服务器的 MAC，还是默认网关的 MAC？如果地址来自 DHCP，提供租约的服务器是否必须承担这次转发？ 这几个地址属于不同决策：地址配置确定本机可使用的参数，路由选择确定当前报文的下一跳，邻居解析把下一跳 IP 对应到当前链路上的地址。第 04 篇已经解释了以太网转发，本篇沿着这三个决策，观察一个真正跨越两段隔离链路的请求。 目的地、下一跳与配置来源 设 A 的接口地址为 10.6.1.2/24，R 的两个接口分别为 10.6.1.1/24 和 10.6.2.1/24，B 为 10.6.2.2/24。A 的默认路由经 R 的左侧接口，B 的默认路由经 R 的右侧接口。这里的 /24 表示前二十四位是前缀，具体路由匹配留到第 07 篇。 123A R B10.6.1.2/24 ─── 10.6.1.1/24 10.6.2.1/24 ─── 10.6.2.2/24 默认下一跳...

同一房间里增加几个无线发送者，为什么一个小请求也可能等待更久？无线链路除了发送数据，还需要决定谁在什么时间占用共享介质。应用没有增加负载长度，等待介质、失败后的重试和重新竞争仍然可能改变完成时间。 第 01 篇分开了发送、传播与排队时延，第 04 篇观察了交换端口的转发范围。本篇增加介质竞争这一条件，用一个有界模型比较单发送者和多个竞争者。模型没有操作无线网卡，也不是完整的 IEEE 802.11 实现；所有时间数字都是模型单位，不能换算为真实 Wi-Fi 吞吐。 交换端口与共享介质 第 04 篇的实验从一个网桥入口选择出口，解决的是帧应该转发到哪里。即使目的地已经明确，发送者仍要获得底层介质的使用机会。Wi-Fi 的多个站点可能竞争同一信道，AP 本身也需要参与相应的介质访问过程。 讨论经典分布式协调功能 DCF 时，发送资格与载波侦听、帧间间隔和退避计数有关。不能把一条应用消息已经排到网卡队列前端，等同于它马上开始在无线介质上传输。 现代 Wi-Fi 还有优先级、聚合、多用户调度等机制。为了隔离基本因果，本篇只讨论共享介质竞争的一个简化视角，不把它作为所有制式、所有工作模式...

一个网桥有三个端口，A、B、C 各占一个。A 发给 B 的帧第一次经过网桥时，网桥尚不知道 B 在哪个端口。它既不能向所有网络查询 B，也不能直接丢弃所有未知目的地，否则刚接入的设备就无法开始通信。未知单播泛洪和源地址学习共同解决这个起步问题。 本篇从这个三端口问题出发，再增加一个属于其他 VLAN 的 D。实验使用 Linux 虚拟机中的自建命名空间、veth 和网桥，直接发送带唯一标记的二层测试帧，检查学习前后的出口变化。它延续第 03 篇的观察边界：端口收到测试帧是链路层证据，不等于业务请求成功，更不能代表物理交换机性能。 帧里的地址决定什么 本实验构造未带 VLAN 标签的 Ethernet II 格式：六字节目的 MAC、六字节源 MAC、两字节 EtherType，后接测试载荷。Linux 的 struct ethhdr 就按这一顺序定义；附件按照这个已知格式构造和解析帧，不把十四字节偏移套到任意抓包链路类型。 123目的 MAC 源 MAC EtherType 测试载荷02:00:00:00:04:02 02:00:0...

抓包文件里有一个确认号覆盖了请求的全部字节，能否据此认定服务端已经处理请求？不能。这个确认号属于 TCP 的接收状态；业务处理发生在应用读取、解析和执行之后。要回答“请求停在哪里”，必须把报文记录与端点日志放到同一条有边界的证据链上。 第 02 篇已经定义四字节长度头和有界消息体。本篇沿用该格式，只发送合成字符串 network-03，观察应用调用、连接端点与序号之间的关系。实际环境完成了回环回显和序号手算，但抓包设备权限不足，未取得真实 pcap；下文把已运行的部分、可复跑的捕获步骤和未验证结论分别标出。 报文记录首先属于一个捕获点 应用调用 sendall，数据进入传输实现；抓包程序在操作系统提供的捕获接口观察记录；接收应用再调用 recv，取得可读字节。这些事件并不是同一个事件的不同显示方式。一个观察点缺少另一个观察点的信息，不能靠增加输出字段补齐。 123客户端调用日志 → 本机 TCP 路径 → 回环捕获点 → 本机 TCP 路径 → 服务端调用日志 ↓ ...