1 为什么还要学 IPv6：地址耗尽之外的交付问题
在 S15 中，我们用 IPv4 地址与子网掩码判断目标是否位于本地网络，再决定直接交付还是交给网关。IPv6 没有推翻这个过程：主机仍然需要地址、前缀、邻居信息和路由。变化首先发生在地址空间。IPv4 地址长 32 位，IPv6 地址长 128 位；但学习 IPv6 的目标，不是记住地址总量，而是让应用在新的地址族上能够被访问、被保护、被排查。
IPv4 公网地址紧张时，企业常把多个私有地址映射到少量公网地址。NAT 让这种共享成为可能，也增加了交付条件。例如，公网用户访问某台服务器的 443 端口，可能先经过公网地址、端口映射与负载均衡，再抵达私有地址。排查人员必须确认外部入口与内部目标是否对应，日志中的源地址是否被转换，返回路径是否经过相同设备。地址不够只是起点，映射关系的维护才是持续成本。
IPv6 为大量接口分配可路由地址提供了空间，减少了依赖地址转换来共享公网入口的压力。所谓端到端，是通信双方可以用各自地址建立通信，不必天然依赖中间的地址转换；它不等于所有接口都应暴露到公网。路由决定是否有路径，安全组与防火墙决定是否允许报文，服务监听决定应用是否接收。拥有全局单播地址，不能替代任何 1 项安全配置。
实际交付常采用双栈：同一主机同时具备 IPv4 与 IPv6，应用根据解析结果和连接策略选择路径。这允许已有 IPv4 客户端继续工作，也允许 IPv6 客户端使用新的路径。不过，双栈意味着维护 2 套地址族的证据。IPv4 的入口、安全组和监控都正常，不能证明 IPv6 也正常；同一个域名甚至可能在不同客户端上触发不同故障。
不要承诺“打开 IPv6 就会更快”。某条 IPv6 路径可能更直接，也可能受到运营商互联、上游出口或云端配置影响。应比较相同服务在指定地址族上的连接成功率与耗时，再解释差异。本课沿用“先判断范围，再确认交付条件”的方法，重点学习地址如何写、邻居如何找到，以及如何证明双栈服务真的可用。
2 地址形态：2000::/3、链路本地、唯一本地
先按作用范围区分地址，能够避免大量配置错误。全局单播地址用于可在全球路由体系中使用的单播通信，本课以当前常见分配空间 2000::/3 建立直觉。它包含首个十六进制数字为 2 或 3 的地址。这里的 /3 表示前 3 位固定，不是前 3 个字符固定。前缀属于这段空间，也不意味着某个具体地址已经分配、发布路由或允许公网访问。
本课配置示例使用 2001:db8::/32 内的地址。这段空间专供文档示例，不能直接拿去部署公网服务。看到 2001:db8:16:20::10 时，应理解它在展示地址结构；动手操作时必须替换为云平台实际分配的前缀与地址。这样既能练习判断，也不会把某个真实站点的地址误写进配置。
fe80::/10 是链路本地地址范围，常见地址写法以 fe80: 开头。它用于同一链路上的邻居发现、下一跳通信等活动，路由器不会把这类流量转发到其他链路。主机即使没有全局地址，也可能已经有链路本地地址。因此，“网卡出现 IPv6 地址”和“主机能够访问 IPv6 公网”是不同的验收结论。
链路本地地址还需要接口上下文。主机有 eth0 与 eth1 时，两条链路上都可能出现名为 fe80::1 的邻居。命令中的 fe80::1%eth0 用区域标识说明走哪张接口；部分工具也支持用独立接口参数指定。不能只记录 fe80::1，然后期待系统在所有场景中自动知道目标位于哪条链路。
fc00::/7 是唯一本地地址范围，简称 ULA，适合组织内部通信，不作为公共互联网中的全局可达地址使用。实践中常使用 fd00::/8 下按规范随机生成全局标识的前缀，再分配内部子网。不要把所有站点都手工设成同一个 fd00::/48：站点合并或建立互联后，地址冲突仍会制造返工。ULA 的内部用途也不代表天然安全，内部访问仍需权限边界。
判断题可以换成部署问题：访问公网服务，检查分配给接口的全局单播地址；找本链路的网关，可能使用链路本地地址；组织内部跨子网通信，可以规划 ULA 并配置内部路由。它们回答的是不同范围的问题，不能因为都包含冒号就相互替换。同一接口拥有这几类地址，也并不矛盾。
3 前缀、接口标识与 /64 直觉
IPv6 地址仍然要和前缀长度一起看。以 2001:db8:16:20::10/64 为例，展开后是 2001:0db8:0016:0020:0000:0000:0000:0010。前 64 位是子网前缀，后 64 位是接口标识，简称 IID。由于每个十六进制数字表示 4 位，前 4 组共 16 个十六进制数字，恰好对应 64 位。这个位置关系比背一个巨大的“可用主机数”更实用。
比较 2001:db8:16:20::10/64 和 2001:db8:16:20::20/64，它们具有相同的 /64 前缀。把后者改成 2001:db8:16:21::20/64，第 4 组变化，意味着子网前缀也变化。主机仍须依据实际路由表决定出口；相同前缀有助于理解本地交付，但地址写得相似并不能替代正确的接口与路由配置。
在普通以太网局域网中，/64 是非常常见的子网长度，也是通常的 SLAAC 无状态地址自动配置所依赖的子网形态。它让网络前缀与接口标识具有稳定边界。不要因为某个子网只有 20 台机器，就照搬 IPv4 的节约思路，把它缩到 /120 后继续期待原有 SLAAC 行为。特定链路确实可能使用其他长度，但那需要明确的设计依据，本课不把特殊用途当默认配置。
从上级前缀划分子网时，可以做一个小规模计算。假设组织拿到示例前缀 2001:db8:1200::/56，划出 /64 子网需要再固定 8 位，因此可划成 256 个 /64。其中包括 2001:db8:1200:0::/64、2001:db8:1200:1::/64，直到 2001:db8:1200:ff::/64。这个计算服务于网段规划，不要求把每个网段内的所有接口数写出来。
IID 不一定来自网卡 MAC。早期常见做法包括基于 MAC 的修改 EUI-64，也可以使用稳定隐私方式生成地址，客户端还可能使用会轮换的临时地址。稳定隐私地址强调在适用网络内保持稳定并减少暴露硬件标识，临时地址则强调降低长期关联性。排查时不能看到地址尾部不像 MAC，就判断配置有误；也不能把临时地址直接当作长期服务入口。
观察滑块时，先固定上级 /56，再比较目标 /60 与 /64：前者划出 16 个子网，后者划出 256 个子网。交互展示的是“多固定几位，会改变子网划分粒度”。用于普通 SLAAC 局域网时仍以 /64 为常见边界，不能把滑块能选到的每个长度都解释为推荐部署值。服务器入口还应确认地址生命周期、重启后的保留方式及云平台分配记录。
4 如何写进配置：压缩、不省略的坑
IPv6 的完整表示包含 8 组十六进制数字，每组 16 位。书写时可去掉每组前导的 0，还可以用 1 次 :: 压缩连续的全零组。例如，2001:0db8:0016:0020:0000:0000:0000:0010 可以写成 2001:db8:16:20::10。这只是同一个 128 位地址的不同表示，压缩没有减少地址实际占用的位数。
有 3 个边界尤其容易写错。第 1，不能去掉组内有意义的零：0010 可以写成 10，不能写成 1。第 2，一个地址里最多使用 1 次 ::，否则无法判断各处分别补多少组。第 3，不足 8 组的地址必须靠合法的 :: 表达省略，不能把 2001:db8:16:20:10 当成完整地址。按组补齐，比凭视觉猜测可靠。
展开 2001:db8:16:20::10 时，已经写出的组数为 5，因此 :: 补入 3 组 0000。再看 2001:db8::16:0:10，显式写出的组数也是 5，同样补 3 组，但补的位置不同，得到的是另一个地址。压缩位置属于地址内容的一部分，不能把冒号随意挪动。规范化输出通常压缩最长的连续零组，长度相同时优先靠左，并使用小写字母，方便人工比较。
把地址放进 URL 时，还需要用方括号分清地址与端口：https://[2001:db8:16:20::10]:8443/。这里地址中的冒号不承担分隔端口的职责。该 URL 只是语法示例，文档地址不可用于真实公网测试。正式应用通常通过域名访问，以便让证书校验、地址更新和双栈选择有一致的入口。
表示差异也会变成权限问题。例如，资产表保存展开形式，配置生成器保存压缩形式，某段脚本用字符串完全相等来决定是否创建规则，就可能漏掉本应匹配的地址。正确做法是使用支持 IPv6 的地址解析与前缀比较，把文本变成地址值后判断。人工复核时也应把地址与前缀长度一起核对，确认云安全组规则实际写入成功。
权限范围不能靠省略表达。允许单个 IPv6 地址，规则应使用 /128；允许整个示例局域网，才是 2001:db8:16:20::/64。:: 是地址压缩，/64 是前缀长度，两者没有替代关系。在 IPv4 中熟悉的 /32 单地址规则，也不能直接搬到 IPv6。将 /128 误写为 /64，扩大的是访问范围；地址文本写错而规则未创建，则可能表现为连接失败。
5 邻居发现替代 ARP：NS/NA 与到达性
IPv4 在以太网上常用 ARP 把下一跳 IPv4 地址解析成 MAC 地址。IPv6 使用邻居发现协议 NDP，其中邻居请求 NS 与邻居通告 NA 承担相近的地址解析角色。NDP 基于 ICMPv6，还涉及路由器发现、重复地址检测和邻居可达性维护。本课把重点放在“下一跳是谁、它对应哪个链路层地址、现在是否还能到达”这条交付链。
假设主机 A 为 2001:db8:16:20::10/64，主机 B 为同链路的 2001:db8:16:20::20/64。A 根据路由判断下一跳就是 B，但邻居表中还没有 B 的链路层地址。A 会发送针对 B 的 NS，典型的初始解析使用 B 对应的请求节点多播地址；B 收到有效请求后用 NA 回应。A 学到映射后，才能把后续 IPv6 报文装进适当的以太网帧发出。
若目标改为另一个网络中的服务器，A 要解析的是默认网关等下一跳的链路层地址，而不是远端服务器的 MAC。IPv6 目的地址仍指向远端服务器，当前以太网帧的目的 MAC 则指向本链路下一跳。这个区分与 S15 的路由选择相接，也能解释为什么公网服务器不可达时，先检查网关邻居往往更有价值。
S14 中交换机的 MAC 学习解决“某个目的 MAC 应从哪个交换端口转发”。主机的邻居表解决“某个下一跳 IPv6 地址应使用哪个链路层地址”。交换机转发表有条目，不代表主机已学到 IPv6 邻居；主机收到 NA，也不意味着远端应用端口已经放行。它们是交付路径上不同位置的证据，不能相互代替。
Linux 上可用 ip -6 neigh show dev eth0 查看邻居状态。REACHABLE 表示近期有可达性确认，STALE 表示条目仍在但确认已经变旧，并不直接代表故障。后续通信可能触发延迟检查与探测。持续出现 INCOMPLETE 或 FAILED 时，应检查接口、目标是否同链路、下一跳配置和 NS/NA 是否被过滤，再据此定位；不要把所有非 REACHABLE 状态都清空重建。
ICMPv6 也不只是给 ping 使用。例如 Packet Too Big 报文参与路径 MTU 发现，过滤后可能出现小报文正常、较大响应卡住的现象。因此，“业务只用 HTTPS，所以禁掉全部 ICMPv6”会破坏业务依赖。应按云平台与主机防火墙的机制放行必要类型，并确认链路上的实际过滤位置；允许回显请求并不能证明其他必要 ICMPv6 消息也已放行。
6 双栈与只开 v6：应用、DNS 与默认路由
双栈的完整路径从应用开始。应用通常通过 getaddrinfo 等接口查询域名，获取可用地址；A 记录承载 IPv4 地址，AAAA 记录承载 IPv6 地址。返回顺序与应用最终选择还受到本机策略、可用源地址及连接实现影响，不能把它简化为“DNS 先返回哪个，就永远用哪个”。部分应用会依次尝试，部分应用会采用后面案例中的连接竞速策略。
DNS 中存在 AAAA，也只说明发布了 IPv6 目标。客户端仍需可用的 IPv6 源地址和路由，服务器也必须在相应地址族上监听。Linux 的 ip -6 route show 可用于查看 IPv6 路由，::/0 表示 IPv6 默认路由，与 IPv4 的 0.0.0.0/0 属于不同地址族。已有 IPv4 默认路由不会替 IPv6 提供出口。
典型默认路由可以显示为 default via fe80::1 dev eth0。下一跳使用链路本地地址是正常现象，因为网关本来就在本链路，dev eth0 指明了范围。主机凭全局地址发往远端，先把帧交给这个下一跳；这并不意味着远端也能访问该网关的 fe80::1。地址作用域与数据最终目的地需要分开理解。
服务端也要确认监听。可用 ss -lnt 查看 TCP 监听地址，检查目标服务是否覆盖 IPv6 地址。绑定 0.0.0.0 通常只说明 IPv4 监听；看到 [::] 则应继续结合系统与应用的双栈套接字设置验证，不能仅凭这一行推断两种地址族都能接收。验收仍应从外部客户端分别建立真实连接。
DNS 查询使用的传输协议，与回答中的记录类型是独立的。通过 IPv4 联系 DNS 解析器，也能取得 AAAA；通过 IPv6 联系解析器，也能查询 A。只开 IPv6 的主机需要能够到达解析器，还需要它访问的服务、软件仓库、监控和认证上游具备 IPv6 可达路径。解析器给出 A 记录，并不会让只具备 IPv6 的主机自动访问 IPv4 地址。
若上游只有 IPv4，就需要经过设计的转换或代理能力，例如配套的 DNS64/NAT64 服务；这种能力不是“启用 IPv6”后自动出现的。部署前应列出关键依赖并实际验证。本课不展开转换机制，只要求识别边界：客户端能解析、能选地址、能找到默认出口，仍需目标与依赖共同支持所选路径。
7 常见坑：关掉 v6「图省事」、错误禁用 SLAAC、把链路本地当全局
第 1 类坑是发现浏览器连接慢，就禁用内核 IPv6 功能或阻止模块加载。症状可能因此消失，因为应用不再尝试那条路径；但这没有说明故障究竟发生在 DNS、默认路由、安全组还是上游。它还可能改变本机监听、容器通信和监控行为。若确需短期回退，应记录触发条件、影响范围与恢复条件，同时保留强制 IPv6 连接失败的证据。
对比试验应尽量缩小变量。例如在同一主机、同一时段，对同一域名分别运行强制 IPv4 与强制 IPv6 的请求，再检查失败地址族的路由与日志。这样可以形成“该主机的 IPv6 TCP 连接在超时前没有建成”的结论。直接说“IPv6 坏了”，既没有故障范围，也无法指导下一位值班人员采取行动。
第 2 类坑是为了固定服务器地址而关闭 SLAAC，却没有提供完整替代配置。SLAAC 常利用路由器通告 RA 中的前缀信息生成地址，RA 还承担发现默认路由等职责。DHCPv6 可以提供地址或其他配置，但通常不负责提供 IPv6 默认网关。因此，“我已经配了 DHCPv6”不等于“默认路由肯定存在”。关闭自动配置前，要分别确认地址、默认路由和 DNS 从哪里来。
可以把故障具体化：服务器原本从 RA 学到 /64 前缀与默认出口，修改后只剩 fe80:: 地址，应用便失去全局通信条件；另一个场景中，静态全局地址还在，但不再接受 RA，默认路由随有效期到期而消失。后者可能在变更后暂时正常，稍后才失败。验收不能只在修改瞬间看地址，还应检查路由来源、有效期及重启后的配置是否生效。
第 3 类坑是把 fe80:: 地址写进跨子网访问策略、服务注册或 DNS AAAA。对端即使拿到该地址，也无法跨路由到达它；没有接口区域信息时，本机甚至无法唯一确定发送链路。若配置目标是“另一个子网的应用服务器”，就应使用适合该范围且有路由的地址。默认网关是本链路邻居，可以使用链路本地地址，这是另一种用途。
这些坑共同提示我们按责任拆分配置。地址自动化负责得到什么地址，路由配置负责向哪里发送，安全策略负责允许什么通信，DNS 与服务注册负责向谁公布入口。某个开关同时影响多项行为时，更应该先列出依赖再变更。固定地址的需求可以通过云平台保留地址或明确的静态配置解决，而不是把所有自动发现能力一起关闭。
8 案例：云主机双栈开通验收
假设一台 ECS 已提供 IPv4 HTTPS 服务，现在需要增加 IPv6。云平台给实例网卡分配了某个实际全局单播地址，以下记为 2001:db8:16:20::10，网关示例为 fe80::1。域名采用保留的 web.example。这些占位值只用于展示验收方法，所有命令执行前都应替换成实际地址、接口和域名，不能把示例配置直接视为生产配置。
第 1 步核对云端与本机。云控制面显示地址已绑定后，在主机运行下面的只读检查，确认地址确实出现在预期网卡上，前缀长度符合交付说明，且没有仍在重复地址检测或检测失败的状态。控制面分配完成与操作系统配置完成是 2 个观察点，镜像网络配置或初始化过程可能使它们不一致。
ip -6 addr show dev eth0
ip -6 route show
ip -6 neigh show dev eth0第 2 步核对默认出口。检查路由表中是否有 ::/0 对应的默认路由，下一跳与网卡是否正确。需要确认具体目标的选路时，可执行 ip -6 route get 2001:db8:99::80，其中目标应替换为实际测试服务器。输出中的源地址和出口接口有助于发现多网卡情况下的误选；命令能够给出路由，也不等于报文已到达目标。
第 3 步检查本链路。在网关允许响应回显的环境中，用 ping -6 -c 3 -I eth0 fe80::1，或等价的 ping6 命令测试网关。成功说明当时这条本链路往返可用，尚不能证明公网出口和业务端口正常。若失败，结合邻居表判断；云虚拟网关也可能不回应回显，需要参考平台说明，用邻居证据与后续真实连接补充判断，不能只凭丢包直接否定配置。
第 4 步确认安全组、网络访问控制与主机防火墙。IPv4 已允许 443，不代表 IPv6 来源也获准访问。核对 IPv6 规则的源前缀、方向、协议和目标端口，同时确保必要 ICMPv6 消息没有被一概过滤。NDP、差错消息与公网回显在平台中的处理位置可能不同，应分别核实，避免把“安全组放开 ping”当成完整证明。
第 5 步从具备 IPv6 出口的外部客户端发起真实业务连接，确认应用监听与证书正常，再发布指向已验收入口的 AAAA。随后检查权威 DNS 与客户端使用的递归解析器，并分别验证 A、AAAA 对应的入口。记录 DNS TTL，避免更新后不同缓存结果被误认为随机故障。交付记录应包含测试时间、源网络、解析结果、地址族和连接结果，使后续变更有可比较的基线。
9 排查案例：A 记录通、AAAA 不通或反过来
工单描述是“浏览器偶发慢，有时刷新就好了”。服务同时发布 A 与 AAAA，不能从这一句直接推断服务器负载或 IPv6 故障。先在同一客户端、接近的时刻收集解析与连接证据。下面命令中的域名需要替换；浏览器若使用独立的加密 DNS，也应记录它使用的解析路径，因为它可能与命令行的系统解析器不同。
dig web.example A
dig web.example AAAA
curl -4 -v --connect-timeout 5 --max-time 15 https://web.example/
curl -6 -v --connect-timeout 5 --max-time 15 https://web.example/观察 dig 的状态、答案与 TTL，并从 curl 输出区分解析失败、连接超时、证书错误和 HTTP 响应错误。这里的 5 秒限制连接阶段，15 秒限制整次请求；它们是便于复现实验的上限，不是业务性能标准。若返回多个地址，应记录每次实际连接的目标，必要时逐个验证，避免把某个后端故障错误推广到整个地址族。
路径 A：当前解析器只返回 A，没有可用 AAAA。curl -4 成功，curl -6 因没有相应地址而不能建立连接，这组证据首先指向记录发布或解析视图。继续检查权威记录、委派、缓存与客户端是否使用了预期解析器。AAAA 查询无答案与 DNS 查询本身超时是不同结果；此时反复调整服务器 IPv6 安全组，通常无法解决“目标地址没有被解析出来”的问题。
路径 B：AAAA 正常返回，但 IPv6 连接超时。先看客户端是否有可用源地址与默认路由，再看选路、网关邻居与外部路径；服务器侧核对地址绑定、监听与入站策略。假设 IPv4 在 80 毫秒内完成连接，而 IPv6 连续 3 次都在 5 秒连接上限内未建成，结论应写成“从该源网络到该 AAAA 目标的 IPv6 连接失败”。安全组丢弃、缺少路由和上游黑洞仍是待区分的原因。
ICMPv6 被过滤时还要看失败阶段。初始连接完全没有回应，与连接建立后较大响应停住，证据不同。后者应考虑 Packet Too Big 消息是否被阻断及路径 MTU 问题，不能只用小包回显成功排除网络。必要时结合允许范围内的抓包或平台流量日志确认报文在哪段消失，但不要在没有证据时把具体原因直接写成结论。
路径 C：浏览器采用 Happy Eyeballs，在优先路径迟迟未成功时，按实现策略发起另一个地址族的连接尝试。为了说明现象，假设某实现经过 250 毫秒发起 IPv4 尝试，IPv4 再用 80 毫秒建成连接，用户可能只感到约 330 毫秒的额外等待，却仍能打开页面。这个间隔是教学假设，实际算法、缓存与调度会改变时序，也不保证每次都先试 IPv6。
因此，浏览器能打开页面不能证明 IPv6 健康，强制 curl -6 失败也不能证明浏览器必定失败。把竞速暂时分解为单地址族测试，可以看清是哪条路径在被另一条路径掩盖。修复 IPv6 后还应重复同样测试，确认恢复来自配置变化，而不是客户端碰巧选择了另一个地址。
如果结果反过来，AAAA 与 curl -6 正常，A 对应连接失败，就沿 IPv4 的地址、默认路由、NAT 映射与安全策略排查。双栈并不规定哪个地址族应当成为故障来源。工单最终应写出源网络、解析器、具体目标、失败阶段、修复项与复测结果，例如“IPv6 入站 443 规则缺失，补齐后同源连续 3 次连接成功”，让结论可以被复现。
放进方案里
方案应先写清服务覆盖哪些客户端、依赖哪些上游，再选择只用 IPv4、双栈或只用 IPv6。现有系统只有 IPv4、上游与管理工具也尚未具备 IPv6 时，可以保留只用 IPv4 的阶段安排，同时记录扩容与地址转换成本。面向多种公网客户端且具备运维能力的服务，通常适合双栈逐步交付。只用 IPv6 则要求 DNS、软件源、认证、监控和业务上游都有可验证路径；仅有 IPv4 的依赖需要明确的转换或代理安排。
把验收清单放进变更单，并逐项留下证据。地址项记录云端分配、本机地址、前缀长度、作用域与生命周期，确认服务入口不会因临时地址轮换失效。路由项记录默认路由、下一跳、网卡和实际选用的源地址；多网卡实例还要确认响应能够沿预期路径返回。邻居与 ICMPv6 项检查下一跳学习、必要差错消息和路径 MTU 条件，不以单次回显结果代替全部网络验收。
DNS 项核对 A、AAAA、TTL 与实际解析器，确保已发布的每个入口都有人负责维护。安全项同时审查云安全组、网络控制与主机防火墙，明确 IPv6 源前缀和业务端口，并用地址解析工具复核规则范围。应用项确认监听地址族、证书与真实请求结果。最后从目标用户所在网络分别执行 IPv4、IPv6 测试，保存时间、目标与失败阶段，作为上线后的对照基线。
灰度期间同时观察两种地址族的连接成功率与耗时，不能只统计合并后的页面成功率，否则连接竞速会掩盖单侧故障。回退计划要说明调整的是 DNS 发布、入口策略还是主机配置，并考虑缓存有效期。交付完成的判据是目标客户端能够稳定使用承诺的路径，配置可在重启后恢复，值班人员能够用清单复现验证，而不是控制台上出现了“已开通 IPv6”。
10 小结：走向传输层（S17）与云上 IPv6 网关
IPv6 排查仍然沿着可检查的交付链展开：确认地址作用域与前缀，找到正确下一跳，用 NDP 取得本链路交付信息，再检查默认路由、DNS、安全策略和应用监听。双栈使应用拥有多条候选路径，也要求运维分别证明这些路径可用。地址表示、接口范围与前缀长度写清楚，许多“偶发问题”就有了稳定的定位入口。
S17 将继续研究 TCP：地址与路由可用之后，连接如何建立、如何确认数据、超时又意味着什么。以后遇到云上 IPv6 网关，也可以继续追问它承担哪段出口、入口或转换职责，结合产品说明验证路由、策略和返回路径，而不把“开通网关”直接等同于业务交付成功。
下一课转向 S20 TLS 与 HTTPS：把本章验收过的结论带进后续主题，写成可检查的方案约束。