网络

选择器让 Service 从一段固定列表变成动态视图：新增移除都在后台完成，Pod 重启时客户端无需改任何配置。 地址稳定受 Service 对象存续期限定。成员关系、路由收敛与请求成功仍需分别看待。精确分配模型本轮再次通过，仅验证台账；未执行 Kubernetes。 先声明，再分配地址 普通 ClusterIP Service 在对象存续期间提供虚拟地址，并在集群 DNS 支持下提供稳定发现名称。带选择器的 Service 还声明本命名空间中哪些 Pod 是预期后端。其他形态不同：无头服务不分配虚拟 IP，ExternalName 使用 DNS 间接引用，无选择器服务可以配合单独管理的 EndpointSlice。不能把每种 Service 都套进同一种分配流程。 地址稳定仅限 Service 对象存续期间，不是某个名称出现之后永远占用同一个地址。删除重建可能得到新地址。客户端应遵守约定的发现方式，并适当重新解析，而不是把抄下来的 ClusterIP 当成永久基础设施身份。这层稳定性主要隔离后端更替，不能消除对象本身重建和发现系统变化带来的影响。 ...

TCP 最大段大小选项 MSS，按照其定义的开销规则，通告接收端可接受的 TCP 数据大小。两个方向分别通告，数值不必相同。路由器转发 SYN 消息时可以减小这些值，使后续数据段适应受限路径。这改变的是相关连接的 TCP 行为，不会修改底层链路 MTU。把选项调整与网络本身修复区分开，才能准确说明它解决了什么。 限制只改变新连接的 TCP 通告，不改变链路 MTU 或缺失的 ICMP 反馈。应保留对端较小上限，并分别验证两个方向。 坏掉的样子 中间瓶颈可能比两个端点接口都小。如果经典路径 MTU 反馈被过滤，连接可以成功建立，却在较大数据上停滞。降低 MSS 能帮助该 TCP 流量避开超大报文，但缺失的反馈仍然缺失。若把这个变通措施当作完整网络修复，其他协议与流量模式仍可能暴露原有问题，健康检查也可能继续遗漏受影响场景。 ...

gRPC 的 HTTP/2 传输允许多个 RPC 尝试共享一条连接，同时保留每条流内部的消息顺序。这对短调用和长时间交换都可能有用，但并不意味着每个调用获得了一条无限且完全独立的传输通道。带宽、TCP 交付、连接级流控以及实现中的资源仍然共享，理解这些边界才能准确判断哪些阻塞能够隔离，哪些会影响其他调用。 让调用形式匹配实际工作 一次基于 HTTP/2 的 RPC 尝试占用一条流；重试会发起另一次尝试，而不是把字节重新写入已经结束的流。复用连接能够摊薄建连和 TLS 的成本，但一个 channel 可以管理多条连接，访问不同后端也不会自动共用同一个 TCP 端点。每次调用仍然包含序列化、元数据、帧处理、调度和业务工作，不能把额外成本说成只剩几个帧头。 gRPC 提供单次请求响应、客户端流、服务器流和双向流四类方法。只有双向流允许双方在同一次 RPC 内独立发送消息序列。每个方向的消息顺序得以保留，但不要求每条请求消息都对应一条回复。应当根据应用契约选择调用形式，而不是认为只要采用 gRPC，所有方法就自然具备双向持续推送能力；什么时候读取和写入，仍需应用合理安排。 HTTP/1.1 可以复用持久连接，WebSocket 本身也支持双向消息，二者都不要求每发送一条应用消息就重新握手。因此，不能用虚构的“一次消息一次连接”来证明 gRPC 总是更省。更有意义的比较包括 RPC 契约、生成接口、状态模型和 HTTP/2 多路复用，再结合完整负载和运维约束测量，才能判断实际延迟、内存和连接开销。 分开调用期限与共享传输 截止时间属于某次 RPC，并不会自动成为同一连接上所有流的统一期限。应通过语言支持的上下文机制向下游传递剩余预算；每经过一层就重新领取完整超时，可能让工作持续到调用方早已不愿等待之后。取消还需要业务代码配合停止工作，已经提交的副作用不会因此自动回滚，客户端未收到成功也不等于服务端没有完成修改。 HTTP/2 对 DATA 帧同时实施流级和连接级流控。某条流的窗口耗尽时，只要连接信用仍足够，其他流就可能继续传输。某个方向的连接信用耗尽，会阻止该方向各条流发送非空 DATA；带 END_STREAM 的零长度 DATA 以及控制帧仍可发送。接收端实现可以独立补充连接信用，所以一个慢读者并不必然拖到整条连接都没有额度；应观察真实实现如何管理缓冲和更新。 ...

有用的名称为人和软件提供一个可以跨地址变化继续使用的引用，但这个引用需要明确范围与负责人。机器的本地主机名、服务 DNS 名称和实例标识可以有意不同。清楚命名有助于理解日志和部署，而不是假定一个标签自动建立系统中的所有其他身份。规划名称时，应先说明它标识的是哪类对象，以及希望保持稳定多久。 坏掉的样子 设置本地主机名，本身不会向权威区域发布 A 或 AAAA。注册可能由独立部署或网络管理软件完成，但那条流程必须实际存在。反过来，修改 DNS 地址也不会重命名内核的本地主机名。混淆两者，会产生本地标签看似正确、客户端却无法发现服务的机器。排障时应分别检查本地状态、注册动作和权威数据，不能用其中一个代替其他证据。 短名称依赖查询上下文。即使两台机器都使用正常 DNS 配置，service 在不同搜索域下仍可能指向不同目的地。复制的运行手册命令因此可能到达与作者测试不同的环境。配置中不能容忍歧义时，应使用完整目标 DNS 名称；交互操作使用短名时，也应保留解释它所需的上下文。名称看起来一样，并不意味着它在所有进程里具有相同范围。 人类可读的含义也有限制。app-prod-01 可以提示角色、环境与实例，却不是权限、归属或当前工作负载的权威证据。复用旧实例名称还可能混淆历史日志。服务名称与替换机器的生命周期不同时，应分别命名，并使用运维元数据记录变化事实，不要试图把所有信息都塞进主机名。方便阅读的前缀也不能成为授予访问权限的依据。 短名继承查询上下文。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 将脚本保存为 check-hostnames.py，准备 Docker 后执行 python3 check-hostnames.py。固定环境使用 BIND 9.18.49、dnsmasq 2.90 和 Python 3.11，解析器及 NSS 配置都位于可丢弃容器中。本实验关闭转发缓存，使搜索域和地址变化可以直接观察，不必等待上一代缓存寿命；这项设置用于隔离变量，不代表所有生产客户端都应关闭缓存： ...

IPv6 地址包含一百二十八位，通常写成八组十六进制数字。文本可以省略组内前导零，并用一次 :: 代替连续全零组。这些规则缩短写法而不丢失地址。RFC 4291 定义有效形式，RFC 5952 推荐一致的显示与交换形式。语法是否有效，和拼写是否符合推荐规范，是相关但不同的问题，不能用一个判断替代另一个。 坏掉的样子 直接比较原始字符串，可能把同一个地址当成多个身份。大写字母、前导零和展开的零组都能改变文本，却不改变底层位值，从而拆散资产记录，或破坏应用原本想进行的地址比较。应先使用适合输入类型的库解析，再比较地址值。仅转换成小写，不会处理所有零组和压缩差异，因此不能称为完整规范化。 压缩本身也有限制。:: 最多出现一次，否则无法确定各个省略段的长度。推荐表示应压缩最长连续零组；长度相同时选择最前一组，并且不要压缩单个零字段。一般 IPv6 语法允许部分推荐显示规则不采用的写法。规范化工具应区分有效但非首选的形式与真正非法输入，而不是把两者都报告成相同错误。 地址也未必构成完整端点。URL 中的 IPv6 字面量需要括号，将地址内部冒号与端口分隔符区别开。链路本地目的地还可能需要区域标识，以选择正确接口范围。如果没有明确比较策略就删除区域，或把映射 IPv4 地址扁平化，可能丢失调用方建立正确连接所需的信息。字符串变短，不代表端点含义仍完整。 文本规范化保留地址值，端点的其他组成仍须保留。两列按组展示，写出完整地址时用冒号分隔。规则与示例均来自原文，本草稿未重跑解析示例。 快速验证 将脚本保存为 check-ipv6-text.py，使用 Python 3.12 或更新版本执行 python3 check-ipv6-text.py。保留的旧审阅记录曾在 Python 3.12.14 原样运行此脚本，只调用标准库解析，不产生网络流量。程序比较有效变体、拒绝错误输入并检查端点组成，没有配置示例地址、发送 IPv6 报文或证明这些地址具有可用路由。解析验证与网络可达性在这里明确分开： ...

DNS 同时支持 UDP 和 TCP。服务器因可用消息空间而截断响应时，会设置 TC 标志。客户端收到该标志，需要处理结果不完整的情况，通常通过 TCP 重新查询。这涉及当前使用的 DNS 响应限制，并不直接证明物理网络无法承载任何更大的 UDP 数据报。排障时应先确认协议层发生了什么，再讨论传输路径的实际容量。 即使包含记录，TC 仍说明回答不完整。可用 TCP 路径能取回完整集合，只提供 UDP 的端点则无法完成。文章还展示消息边界与连接复用；这不表示 DNS 已加密。 坏掉的样子 允许 UDP 五十三端口却阻止 TCP 五十三端口的网络，可能小查询正常，大回答失败。DNSSEC 数据和较大记录集容易暴露这种差异，但 TCP 并不只用于这些特殊情况。通用 DNS 实现需要支持 TCP，客户端也可以直接选择它。因此，一次小型 UDP 查询成功，不能证明整个 DNS 服务的传输路径完整，尤其不能代替对 TCP 监听和访问规则的检查。 ...

网络地址转换会在数据包经过边界时改写地址信息。常见的多个客户端共用一个地址，实际采用网络地址和端口转换：路由器维护映射，区分同时存在的流量。远端 TCP 服务器可能看到相同源 IP，却看到不同源端口。这个共享地址代表转换边界，不一定代表同一台计算机、同一个账号或同一个人，不能直接替代身份判断。 坏掉的样子 转换不能代替路由。客户端仍需要到网关的路径，网关必须允许转发，转换后的地址也要具有返回路径。反过来，在能够路由相应前缀的内部网络中，使用私有地址并不必然要求 NAT。缺少返回路由和缺少转换规则都可能表现为超时，但两者对应不同配置决策。应先确定目标看到什么来源，再检查回复如何返回。 有状态 NAT 还会使规则变更中的已有连接与新连接表现不同。nftables 查询 NAT 链以建立流量映射，后续数据包复用保存的绑定。因此，移除 SNAT 规则不一定撤销已经建立的转换连接。这依赖连接跟踪继续工作、绑定仍然有效，不能把一次规则编辑理解成无条件清除全部会话。测试对象是否复用了旧连接，会直接影响结论。 端口映射与连接跟踪容量都是有限资源。资源耗尽、状态到期，或者故障切换设备缺少相关状态，都可能在对外地址未变时中断通信。可用转换源端口需要结合协议和相关连接元组判断，不能用一个对所有目的地、所有负载都通用的端口总数估算容量。NAT 与决定哪些流量被允许的防火墙策略，也属于不同职责。 独立流量可共享转换地址。删除规则不同于映射与依赖寿命；最后一次交互用于观察，不要求必然失败。 快速验证 历史文章报告未找到对应原始集成日志。本轮没有重跑；特权操作继续暂停，也没有尝试替代路径。 将脚本保存为 check-nat.py，准备 Docker 后运行 python3 check-nat.py。它构建包含 Python 3.11.16 和 nftables 1.0.6 的一次性环境，NET_ADMIN 与 SYS_ADMIN 是创建四个嵌套网络命名空间及临时 proc 挂载的前提。历史文章报告 Linux 6.12.76；需启用 Python 断言，清理仅尽力执行。Docker 共享宿主内核，必须只在另行获准的一次性虚拟机里运行；这些权限与共享内核意味着仅用容器不足以保证隔离。实时软件源也不保证未来还能取得这些固定包版本： ...

回环地址让进程通过本地 IP 协议栈通信，无须把交换送到物理网络链路。IPv4 为回环保留 127.0.0.0/8，其中最熟悉的是 127.0.0.1；IPv6 使用 ::1。在 Linux 中，相关的本地网络范围是网络命名空间。因此，同一台物理机器上的两个进程，可能对“自己的回环服务”具有不同答案，不能只按机器归属判断。 坏掉的样子 容器内客户端把数据库地址配置为 127.0.0.1，却希望访问宿主或另一容器时，经常失败。客户端实际请求的是自己命名空间中的监听，地址拼写没有错，拓扑理解却错了。宿主发布端口、容器接口地址和另一进程的回环，是不同目的地。选择连接配置前，应先确定客户端运行在哪里，以及真正服务由哪个网络范围提供。 回环也不保证任何探测都成功。目标端口需要监听，预期地址族需要可用，本地网络策略还可能影响交付。IPv4 请求成功不代表服务也监听 ::1；连接被拒绝，则可能只是调用方命名空间内对应地址与端口没有服务。不能因回环无须外部网线，就把协议栈、监听状态和访问规则当成始终有效的前提。 本地交付没有消除 IP 协议栈。回环流量仍经过套接字、协议处理和本地路由决策，只是没有沿外部物理网络绕行。测量一次回环请求，不能验证交换机配置、远程路由、互联网防火墙或公共服务名称的证书。解释健康探测时，应把这些路径分开，否则内部服务正常可能被误写成所有用户都能成功访问。 相同地址，不同本地范围。仅为 IPv4 预期实验，IPv6 需要独立配置。不声称已有复现运行或通过技术验收。 快速验证 2026-10-19 源码审阅说明：修订后的实验仅使用 IPv4。Docker 的 none 驱动不配置 ::1，独立的 IPv6 实验必须先建立并核验这项配置。技术与执行验收仍暂缓，等待获准环境中的完整运行。下文均为预期结果，不是本次复现的测量，静态修订并不证明实际就绪。 保存为 check-loopback.py，在获准的 Linux Docker 主机上运行 python3 check-loopback.py，固定镜像须事先已存在。其宣称的 Python 版本尚未重新确认。脚本禁止自动拉取镜像，不发布宿主端口。A 在一万九千零九十一端口提供 IPv4 服务；B 起初没有监听： ...