跳转到主要内容

时间范围

多年期

在时间范围维度下,多年期时间跨度情报按信号预计产生影响的时间段组织文章。该页面帮助读者区分即时运营变化与可能需要数季度或数年才会逐步显现的长期治理、投资、标准和基础设施变化。它将时间预期与公开证据、相关方、市场背景、客户影响、政策压力和基础设施规划联系起来,以便读者判断某项动态是紧迫、具有战略意义,还是仍在等待证实证据。页面还解释了时间跨度如何改变信号的含义、哪些组织可能面临风险,以及哪些基础设施决策需要短期行动或长期监测。

Mike McBride 与只消除一种碰撞的组播注册表

IETF

Mike McBride 与只消除一种碰撞的组播注册表

如果两个分配器都被允许从同一只箱子里取号,那么“各自随机”不是隔离机制,只是把冲突推迟到运气用尽。RFC 10028 所做的事情很克制:先把箱子分格,再要求运行中的实现证明自己真的换了格子。

2026年8月31日
切换并非一次切换:RFC 897 如何把改名与 DNS 解析拆开

互联网历史

切换并非一次切换:RFC 897 如何把改名与 DNS 解析拆开

如果验收表只有一行“DNS 迁移完成”,1984 年 3 月的状态就无法填写:主机已经换上 `.ARPA` 正式名称,许多程序却仍从本地 HOSTS.TXT 查地址。RFC 897 的关键贡献,是把看起来同时发生的变化拆成可以分别验收的事实。

2026年8月31日
主机本不该看见的局域网:RFC 925 与隐藏拓扑的代价

互联网历史

主机本不该看见的局域网:RFC 925 与隐藏拓扑的代价

早期互联网中的一个站点,可以让外部网络看见每一根电缆,也可以让主机相信多条 LAN 只是同一个本地网络。RFC 925 选择了后一种幻象:不改变主机的 ARP,而让中间设备去发现、记忆,并在必要时代理主机本不该知道的路径。

2026年8月31日
承载网络不等于运输连接:RFC 892 如何把运输状态与底层路径分开

互联网历史

承载网络不等于运输连接:RFC 892 如何把运输状态与底层路径分开

一枚 `CR` 先给出本端引用与首选等级,一枚 `CC` 再返回对端引用与真正选定的等级。运输连接的成立来自这组对等证据,而不是来自“底层已经连通”这一件事。RFC 892 正是在两个都叫 connection 的对象之间画出这条边界。

2026年8月31日
Gavin Brown 与那次尚未注册域名的“成功创建”

IETF

Gavin Brown 与那次尚未注册域名的“成功创建”

挂号回执能证明柜台收下了材料,却不能证明申请人已经取得标的。RFC 8334 把这段常被界面抹掉的等待期写进协议:命令可以成功,域名分配仍然没有发生。

2026年8月31日
Russ Housley 与证书能够点名、却无法造出唯一性的 MAC 地址

IETF

Russ Housley 与证书能够点名、却无法造出唯一性的 MAC 地址

证书可以精确保存六个或八个八位组,却不会因此长出一双观察网络现场的眼睛。地址从哪里来、此刻落在哪个接口、谁看见了它、谁允许它通行,仍是四个不同问题。

2026年8月31日
最短路径传递时钟,却不负责选主:RFC 891 如何让一条 HELLO 同时服务路由与校时

互联网历史

最短路径传递时钟,却不负责选主:RFC 891 如何让一条 HELLO 同时服务路由与校时

一台 Fuzzball 收到 HELLO 后,可以改走更快的链路,却拒绝用同一报文更新时钟偏差。RFC 891 的精妙之处不只是复用测量,而是给路由、偏差和主时钟身份保留了不同的生效条件。

2026年8月31日
帧比数据报更长:RFC 894 如何把以太网填充留在 IP 之外

互联网历史

帧比数据报更长:RFC 894 如何把以太网填充留在 IP 之外

十六进制 `0800` 看起来像一个数字,却不是长度。它告诉以太网接收者:接下来要用 IPv4 的语法来读。真正决定数据报在哪一字节结束的数字,藏在 IPv4 头部的 Total Length 中。RFC 894 用这两个字段划开了一条边界:外层可以为了达到 46 字节的最低要求而继续发零,内层的意义却必须按时停止。

2026年8月31日
Benoît Claise 与基础模块无法点名的外来增强

IETF

Benoît Claise 与基础模块无法点名的外来增强

依赖关系最危险的时刻,不一定是它断了,而是箭头画反了:基础模块写得完整无误,却无法仅凭自身源码列出从外部伸进来的 `augment`。RFC 10035 为这条反向边补上了服务器证词。

2026年8月31日
广播里有人回答,不等于那台主机已经被确认:RFC 887 如何拆开服务发现的证据链

互联网历史

广播里有人回答,不等于那台主机已经被确认:RFC 887 如何拆开服务发现的证据链

1983 年的主机可以向整个本地网络问一句“谁提供这项资源”。RFC 887 却没有让第一个答复直接成为结论:公开征询、定向否认、第三方线索和服务主机本人的确认,各自只证明不同范围的事实。

2026年8月31日
Kazuho Oku 与那枚能说清拒绝、却不能保证流式传输的 HTTP 字段

IETF

Kazuho Oku 与那枚能说清拒绝、却不能保证流式传输的 HTTP 字段

最难诊断的延迟,不是连接断掉,而是连接一直开着、服务器也在产出数据,客户端却迟迟收不到第一个字节。RFC 10036 让理解新字段的中间节点必须把“我不愿增量转发”说出来;但它没有把整条路径变成一纸流式保证。

2026年8月31日
清单称它“官方”,却没有称它“已经实现”:RFC 880 如何把状态与运行代码分开

互联网历史

清单称它“官方”,却没有称它“已经实现”:RFC 880 如何把状态与运行代码分开

同一行里,GGP 被标为“实验性”,又被注明正在核心网关上使用。这不是 RFC 880 的自相矛盾,而是它最诚实的设计:制度分类、实际部署与技术成熟度本来就是三条不同的证据链。

2026年8月31日
Aaron Parecki 与阻止令牌窃取却不能阻止客户端劫持的 BFF

IETF

Aaron Parecki 与阻止令牌窃取却不能阻止客户端劫持的 BFF

把 OAuth 令牌移出浏览器 JavaScript,能真正切断凭据外带与独立滥用;但它不会替用户辨认哪一段同源代码怀有恶意。RFC 10017 把这条剩余边界写得很清楚:攻击者拿不到令牌,仍可能借活动会话让 BFF 替它完成请求。

2026年8月31日
这扇后门不是路由:RFC 831 如何抵达被分割的 SATNET

互联网历史

这扇后门不是路由:RFC 831 如何抵达被分割的 SATNET

故障时最危险的便利,往往不是多绕一跳,而是把临时入口宣布成所有人都能看见的道路。RFC 831 的方案反其道而行:伦敦的一台多宿主主机可以替特定维护报文执行网关式的源路由和地址改写,却不能发送路由更新。它有转送报文的能力,却没有招揽普通流量的资格。

2026年8月31日
网关能搬运字节,却不能发明缺失的含义:RFC 875 如何质疑协议翻译

互联网历史

网关能搬运字节,却不能发明缺失的含义:RFC 875 如何质疑协议翻译

如果备用网关不知道主网关正在谈的那场会话,它就只是第二只空盒子。RFC 875 从地址、确认、流控和异常信号一路追问,最终揭示了这一点:翻译器一旦替两个不兼容的协议作出对应,就会把会话的含义和状态收进自己内部。

2026年8月31日
Hannes Tschofenig:组件权威标识不是令牌签名者

IETF

Hannes Tschofenig:组件权威标识不是令牌签名者

同一个远程证明包里,可以同时出现组件签名者的密钥标识与外层 EAT 的签名;两者都有效,也不代表两者来自同一主体。RFC 10013 的价值,不是再增加一个“可信”标签,而是阻止系统把不同主体的声明压成一个绿色结果。

2026年8月31日
主文件已经更新,网络仍可能陈旧:RFC 849 如何拆分推送与轮询

互联网历史

主文件已经更新,网络仍可能陈旧:RFC 849 如何拆分推送与轮询

1983 年 5 月,Mark Crispin 追问的不是 HOSTS.TXT 由谁维护,而是更新怎样抵达真正使用它的主机。RFC 849 把“最新”拆成版本识别、传输、完整性、本地安装和失败恢复,由此揭示了登记状态与运行状态之间的距离。

2026年8月30日
Corey Bonnell:签名正确,密钥却没有获得签署 CRL 的授权

IETF

Corey Bonnell:签名正确,密钥却没有获得签署 CRL 的授权

吊销清单的数字签名可以完全正确,发行者名称可以吻合,证书路径也可以通向同一个信任锚;但这三项通过仍没有回答:实际使用的那把密钥,是否被证书明确许可签署 CRL。RFC 10007 补上的,正是“没有写禁止”与“明确获得授权”之间的空白。

2026年8月30日
Kireeti Kompella 与那张不能证明业务可用的 Echo 回执

IETF

Kireeti Kompella 与那张不能证明业务可用的 Echo 回执

一份 MPLS Echo Reply 可以说明:某个按特定方式构造的探针,到达了一台能够解释目标转发等价类的路由器。这是一项精确而有用的事实;它却不能顺带证明所有等价路径、闲置备份路径、对称回程、客户负载和应用交易。LSP Ping 最值得保留的不是一个绿色“成功”,而是它究竟问了什么。

2026年8月30日
主机表说“支持 TCP”,端口必须亲自回答:RFC 832 如何测量运行事实

互联网历史

主机表说“支持 TCP”,端口必须亲自回答:RFC 832 如何测量运行事实

1982 年 12 月,NIC 主机表已经能写下某台机器“支持 TCP”,但一行登记不能替远端完成一次连接。David Smallberg 的调查把这两层事实并排放置:左边是目录中的能力声明,右边是从特定主机、在特定时段向 Telnet、FTP 和 SMTP 发起连接后实际看到的结果。它没有把测量者变成裁判,而是用结果分类、失败复测和下一周的新快照,给“运行代码优先”划出可审计的边界。

2026年8月30日