主要领域
基础设施
在 主要领域 分类下，基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
案例档案
名字选中了 TLS 上下文，却没有授权请求：SNI 路由提示的权威边界
一台多租户网关收到 `tenant-a.example`，准确选中了租户 A 的证书与 TLS 配置。随后它又把这次选择记成“租户 A 已认证”，让没有任何客户端凭证的连接靠近管理接口。密码学没有失败；失败的是系统把客户端自己填入的名字升格成了客户端身份。
案例档案
证书签名通过了，握手却没有完成：TLS 1.3 `Finished` 的转录权威
监控平台在服务端 CertificateVerify 验签成功时就记下一次“安全握手”。下一条加密握手消息的 `Finished` 校验失败，客户端按规范发送致命错误并断开。证书私钥确实完成了它应有的证明，系统却提前替它宣布了另一项尚未发生的事实。
互联网历史
证明回程存在的令牌：DNS Cookies 为何不是身份凭证
EDNS 中一个很小的选项，改变了 DNS 服务器理解 UDP 源地址的方式。它不能说明请求者是谁，却能说明一件更窄、也更实用的事：先前发往这个表面地址的响应，曾被某个端点收到；如今，对方带回了服务器签发的令牌。
案例档案
边缘节点协商了 HTTP/2，源站却仍说 HTTP/1.1：TLS ALPN 只拥有一条连接的协议决定权
浏览器提出 `h2` 与 `http/1.1`，边缘节点选择 `h2`，握手完成，HTTP/2 帧也正常流动。监控随后把源站标成“原生支持 HTTP/2”。这个结论越界了：边缘节点已经终止第一条 TLS 连接，又以独立客户端身份向源站建立第二条连接，并在那一段使用 HTTP/1.1。ALPN 证据没有错，错的是把它跨过终止点继续使用。
案例档案
CA 名称在清单里，身份却未获准：TLS `certificate_authorities` 的选择提示权边界
客户端看到服务器列出的 CA 名称，挑出一张匹配的证书；服务器也确实把证书链验证到了受信任锚点。随后，业务服务拒绝了这个主体——它不属于目标租户，也没有所请求操作的角色。这里没有密码学矛盾。故障发生在观察系统把“被选中”“已验证”和“可执行”压成同一个绿色结论之时。
案例档案
签名是真的，状态仍可能滞后：TLS OCSP 装订与缓存答案的权限边界
证书在 10:07 被撤销。10:11，服务器仍向新连接附上了一份签名完全正确的 `good` 响应，`nextUpdate` 还有数小时才到。这里没有伪造：答案是真的、仍在声明的时间区间内，却已经落后于现实。真正误导人的，是监控把这三件事压成了一个绿色字段：`revocation_checked=true`。
案例档案
套接字关了，交易没有结束：TLS `close_notify` 的终止权限
客户端收到了“成功”，服务器也完成了看似正常的 TLS 关闭。几毫秒后，数据库却拒绝了那次写入。这里没有密码学矛盾：`close_notify` 只证明服务器在一个 TLS 发送方向上不再发送消息，不能证明付款、授权或状态变更已经持久化。真正的故障，是系统把连接终止当成了业务结论。
案例档案
票据还在，会话已不在：TLS 1.3 恢复状态的权限边界
区域切换后，新节点接受了一张六小时前签发的 TLS 1.3 会话票据。密码学验证没有出错：客户端持有对应的恢复 PSK，binder 也覆盖了这次新握手。问题在于，用户的管理权限早已被撤销。系统恢复了旧判断，却没有证明那个判断此刻仍然成立。
案例档案
记录更长，不等于消息更长：TLS 1.3 填充与可见长度的证据边界
取证表里有两个数字：第一条密文记录比第二条多 512 字节。报告把差额直接算进请求正文，并据此认定用户执行了某项操作。抓包没有错，推论却跨错了层。发送端正把 TLS 1.3 记录补齐到固定边界，有时还发送正文为空的应用数据记录。线上可见的是密文长度，不是填充前的应用消息长度。
案例档案
第一次问候被退回，却没有被抹去：TLS HelloRetryRequest 与协商记录的权威
故障分析拿到的抓包从第二个 ClientHello 才开始。里面只有一个密钥份额，服务端接受了它，握手也顺利结束。若把这段记录单独阅读，很容易断言客户端一开始就选择了这个群组。事实恰好相反：第一次问候曾作出另一种预测，而 TLS 特意把它的哈希带进后续记录，使一次纠偏不能变成对历史的重写。
案例档案
协商要的是证书，代码却放行了密钥：TLS 裸公钥与验证权边界
裸公钥并不是“少了几段的证书”，而是 TLS 明确定义的另一种认证形态。真正危险的不是使用它，而是在双方没有选择它时让它改写验证规则。wolfSSL 在 2026 年修复的高危缺陷，正好留下了一份运行代码证据：一枚格式正确的密钥，也可能从错误的门进入信任系统。
案例档案
证明在连接开始后才到达，但它不能改写过去：TLS Exported Authenticator 与应用权限
14:03，一份有效的证书证明进入了一条已承载数百次操作的连接。系统随即提升所有并发流，还把此前五分钟的工作改记在新身份名下。密码学验证没有错，授权历史却被写错了。RFC 9261 能把新增身份的私钥持有证明绑定到既有连接，却不会替应用决定生效时刻、目标流和权限范围。
案例档案
证书尚未通过验证，内存请求却必须先被裁决：TLS 证书压缩的信任前边界
一个只有两千字节的握手消息，声称解压后要占用十二兆字节。此时接收方还看不到证书名称、签名与信任链，却已经要决定是否为这个未经认证的请求分配内存和计算时间。RFC 8879 可以减少线上字节，但不能替对端决定本地资源预算，更不能把解压成功当成身份成立。
案例档案
边缘拿到了密钥，却没有拿到证书：TLS 委托凭据的短期权限边界
凌晨两点，一把只能使用数小时的私钥被部署到边缘。它足以代表证书持有者完成一类 TLS 1.3 握手，却不能续签证书、生成下一份有效委托，也不能让应用接受一笔交易。真正转移的是一段可到期的执行权限，不是身份所有权。
全球机构趋势
当时钟只有一个主人，网络就谈不上韧性
网络可以不断电、路由可以保持可达、服务器也能通过健康检查，但整个系统仍可能失去判断事件先后顺序的能力。精确时间是无线同步、身份认证、控制系统、交易记录与事故证据背后的隐形依赖。真正的韧性始于三个可回答的问题：时钟最多可以错多少、这个界限能维持多久、谁有权在失去信任时选择新的时间基准。
IETF
“最新收到”不等于“全部发生过”：Observe 之外仍要有人为缺口负责
一个压力传感器在拥塞期间先越过告警线，几秒后又恢复正常。CoAP 客户端只收到恢复后的表示。就“现在是多少”而言，它可能已经收敛；就“期间是否发生过危险”而言，它没有证据。RFC 7641 从未把两者混为一谈。它提供的是尽力而为的当前状态观察，并明确允许跳过任意数量的中间状态。真正危险的不是协议压缩了历史，而是自动化系统把被压缩的历史包装成完整审计。
案例档案
对端请求换钥，却没有接管密钥世代：TLS 1.3 KeyUpdate 的轮换权边界
一条 KeyUpdate 记录由旧密钥加密，后续记录却必须进入新世代。对端可以验证这座桥，也可以要求反向更新；它看不见旧 secret 是否真正离开内存，更不能把一次流量密钥刷新变成新的身份认证或无限计算授权。
案例档案
会话属于路由服务器，下一跳却不属于它：IXP 路由中介的权力边界
值班人员看到两条 BGP 会话都是 Established，便把故障排除在路由服务器之外。真正阻断流量的却是另一条链路：客户路由器已经选中路由，但无法把保留下来的 NEXT_HOP 解析成交换网中的 MAC 地址。控制消息来自路由服务器，数据包本来就不该去那里。
案例档案
请求写着“紧急”，调度器仍要自己决定：HTTP Priority 的资源分配权边界
英雄图、网页字体和后台请求都能要求更早送达，但它们竞争的带宽并不属于请求方。RFC 9218 建立的是可互操作的偏好语言，不是远程接管 CDN、源站或 QUIC 调度器的命令接口。
互联网历史
那个试图让 IPv6 自动运行的前缀：6to4 与 2002::/16
6to4 曾给出一个诱人的承诺：把已有 IPv4 地址变成一张 IPv6 网络，再由中继完成剩余路程。地址转换确实按设计工作了；围绕它的运营责任却没有自行就位。