主要领域
基础设施
在 主要领域 分类下,基础设施 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

互联网历史
校验位是对的,书却可能不是那一本:RFC 3187
一个 ISBN-10 可以通过模 11 校验,却仍可能被错误地用于另一部书。RFC 3187 没有把算术正确包装成身份正确:校验位只能检查字符关系,版本归属、目录记录与解析来源仍需另外验证。

互联网历史
链路对客户透明,路径权力却留在运营者手中:RFC 3186
透明常被理解成“中间什么也没发生”。RFC 3186 展示的恰好相反:客户设备看到一条普通 PPP 点到点链路,是因为两端交换机替换并恢复了帧头字节。中间发生的事很多,只是被精心藏在接口之后。

互联网历史
“名单里没有”不等于“钥匙已收回”:RFC 3185
第二封加密消息的收件人名单删掉了三个人,但这三个人仍能解密。名单描述的是新消息如何自我呈现,旧钥匙描述的是谁已经获得能力。RFC 3185 把两者的差别写进安全注意事项:从表示中移除名字,并不会追回此前交付的密码学权限。

互联网历史
“已签名”四个字,藏着几种不同的权力:RFC 3183
“这封邮件已签名”听起来像一句完整结论。RFC 3183 却迫使人继续追问:谁签的,签名表示作者身份、组织放行、审查批准,还是属性绑定?密文又由谁打开?如果这些问题没有答案,一个正确的密码学结果也可能被界面翻译成错误的公共事实。

互联网历史
名字进入了 RSVP,权力仍须决定它意味着什么:RFC 3182
把名字写进报文很容易,把名字变成资源权利却需要一整条可审计的权力链。2001 年的 RFC 3182 允许 RSVP 携带用户、应用、Kerberos 票据或证书,交给策略系统判断一条流能否占用稀缺资源。它没有让身份字段自动成为授权。定位符只指向规则,凭据只支撑验证,PDP 作出策略判断,PEP 才在本地执行;多播汇合时,甚至由谁的应用身份留下,也可能是一项选择。

互联网历史
新流赢得了准入,防守优先级仍要经受下一位来客:RFC 3181
资源不够时,后来者未必只能排队。RFC 3181 允许一条新流凭借更高等级挤掉先前获准的预留,却没有把这次胜利写成永久特权。进门时比较的是抢占优先级,进门后抵御下一位来客的是另一项防守优先级。中间还有策略来源、合并算法、节点容量与执行动作;再往外,才是数据包和应用结果。一个数字无法替这些层面同时作证。

互联网历史
运行时回复了 231,脚本仍欠一张终止凭据:RFC 3179
自动化系统里最危险的一句话往往不是“失败”,而是过早出现的“成功”。RFC 3179 把这种时间差写进协议:231 只说明命令抵达某个运行状态,中间结果、错误和终止各有后续消息;即使脚本结束,结果是否被理解、设备是否真的改变,仍须另行取证。一次响应只能为它亲眼看见的边界作证。

互联网历史
核心忘掉了流,边缘仍须证明它的预留:RFC 3175
RFC 3175 想解决一个很实际的扩展问题:不再让核心中的每台路由器记住每一条 RSVP 预留,同时又不牺牲端到端请求。它压缩的是共享状态,不是证据责任。一个大带宽块可以承载许多承诺,却不能替每条流证明承诺已经兑现。

互联网历史
这个区至关重要,却不必永远由根服务器兼任:RFC 3172
RFC 3172 给 `.arpa` 的权威服务套用了根服务器级别的运行要求,却明确预期它离开根服务器。它留下的不是一份永久托管证明,而是一种更耐久的安排:名字与协调规则保持稳定,承担服务的机器可以更换。

互联网历史
登记表分配了组播地址,却仍要追问它是否在使用:RFC 3171
一行多年不变的登记记录,很容易被看成永远有效的权利。RFC 3171 选择了更严格的理解:全球协调的 IPv4 组播地址是一种需要持续说明理由的例外。登记解决“大家把这个值理解成什么”,却不能替运行中的网络回答“还有谁依赖它”。

互联网历史
索引只给策略行命名,却不解释它的含义:RFC 3159
一台策略服务器向路由器发送两行配置。两行的分类条件、动作、阈值和引用对象完全相同,唯一差别是行号。它们是两项不同策略、一次重复提交,还是两个等待解释的可寻址记录?RFC 3159 对其中一层给出了异常克制的答案:`InstanceId` 只负责指出哪一行,不负责说明那一行意味着什么。

互联网历史
转换器改了分组,也必须改写报告:RFC 3158
RTP 转换器可以保留发送源的 SSRC,同时重编码媒体、合并分组或改变时间戳频率。画面仍能播放,并不表示控制证据仍然正确。若接收端看见的是新的序列空间,RTCP 报告就不能继续照抄旧流的字节数、分组数和丢包数。RFC 3158 把“媒体变了,报告也要跟着变”写成了一组可验证的历史责任。

互联网历史
服务器不必看见明文,仍然控制凭证能否取得:RFC 3157
保险库看不懂信封里的文件,并不妨碍它决定物主何时能够取回信封。2001 年 8 月,RFC 3157 把这条界线带进了密码凭证的移动问题:私钥可以在服务器无法解密的状态下存放和传输,但服务器仍可决定它是否被列出、下载、替换或删除。秘密是否保密、对象是否可得、身份能否延续、后续行动是否成功,从一开始就是四项不同的证明。

互联网历史
发送端看见丢包,却看不见原因:RFC 3155
重复 ACK 不是事故报告。它告诉 TCP 发送端,接收端仍在等待某一段字节;它不会说明那段数据是在拥塞队列里被丢弃、在无线链路上损坏、被链路层重传拖晚,还是连确认报文本身也在返程途中消失。2001 年 8 月,RFC 3155 接受了这种认知边界:当原因不明时,TCP 仍要优先保护共享网络;更好的恢复机制可以少浪费时间,却不能把症状改写成诊断。

互联网历史
中继补上了头部,消息末尾却可能消失:RFC 3164
在早期 BSD syslog 格式中,中继可以补上时间戳和主机名,让一条裸消息更容易阅读。但 RFC 3164 同时把整个数据包限制在 1,024 字节以内:新增头部占用的空间,可能正是原始事件正文所需的空间。

互联网历史
接收端愿意接收复用帧,发送端仍可选择不用:RFC 3153
如果把 RFC 3153 只概括成“多个小包合成一个大包”,就会漏掉它最重要的权力边界。2001 年的这份标准先让接收端声明自己能拆解 PPP 复用帧,再允许发送端按本地队列与时机决定是否真的复用。协商成功只建立可解释性,不生成数据帧,也不生成性能收益。省下多少包头、增加多少等待,必须回到线上逐帧核算。

互联网历史
服务器为何需要第三个随机值:RFC 3163
在 RFC 3163 的双向认证模式中,第三个随机值不是装饰。它要处理的是一次顺序上的不对称:客户端挑选自己的随机数时,已经看过服务器最初发来的挑战值。这个补充有明确边界,协议提供的保证也同样有限。

互联网历史
新反向树已经存在,旧反向树却尚未消失:RFC 3152
2001 年 8 月,互联网为 IPv6 反向解析选定了 `IP6.ARPA`,却没有假装一纸 RFC 能同时改写所有解析器。RFC 3152 请求完成上层委派,让下层结构跟随 IPv6 地址分配,并把 `IP6.INT` 判定为不适合新实现。旧树的退出仍要“有序”进行。标准决定、权威委派、区域注册管理机构、PTR 数据、缓存与应用结果因此各有自己的时钟。

互联网历史
IPv6 要等认证之后:RFC 3162
接入服务器必须先批准会话,之后才知道主机要使用哪种 Internet 协议。RFC 3162 允许同一条 RADIUS 消息携带两种地址族的属性,再由网络边缘决定哪些配置真正适用。

互联网历史
旧名字变成了 URN,却没有因此自行解析:RFC 3151
XML 继承了一批能跨越单机环境、却无法直接进入 URI-only 接口的公共标识符。RFC 3151 用确定的 `urn:publicid:` 转写把它们带进 Web 架构。规范化后的名称因而可比较、可传递,但前缀没有替名称登记所有者,也没有替运行环境选择目录、验证目标或证明解析器拿到了正确字节。
