跳转到主要内容

时间范围

Current

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

Juliusz Chroboczek 与并非全局评分的 Babel 度量

IETF

Juliusz Chroboczek 与并非全局评分的 Babel 度量

路由度量可以对本地选择至关重要,却不因此成为全网的评分。RFC 8966 把 Babel 的链路成本和度量计算留给本地策略,只把一条很窄的共同约束留在协议层:为避免持续路由环路,计算结果必须严格单调。这个约束不是带宽、价格、时延、可达性或用户体验的通用证明。

2026年9月4日
Wassim Haddad 与尚未授权转发的前缀

IETF

Wassim Haddad 与尚未授权转发的前缀

移动路由器可以先向归属代理完成登记,随后才知道能够使用哪个移动网络前缀。Wassim Haddad 参与撰写的 RFC 6276 把这个顺序写得很清楚:有效的 DHCPv6 前缀委派租约,才是把特定前缀加入归属代理绑定缓存并避免向未委派前缀转发流量的条件。

2026年9月3日
Nandita Dukkipati 与不再忽停忽冲的 TCP 恢复

IETF

Nandita Dukkipati 与不再忽停忽冲的 TCP 恢复

同样把拥塞窗口从二十收缩到十,并不代表两次恢复做了同一件事。一次可以先沉默半个往返时间,再突然补发一串报文;另一次则随着 ACK 返回,逐次放行经过计算的少量数据。终点相同,沿途给队列、超时风险和运维判断留下的事实却完全不同。Nandita Dukkipati 参与推动的比例速率缩减,正是把这段“怎么走”变成了可以验证的控制面。

2026年9月2日
Ashesh Mishra 与那次必须能够撤销的 BFD 校验

IETF

Ashesh Mishra 与那次必须能够撤销的 BFD 校验

报文还没有通过验证,接收端却必须先算出“未来”的一个值。麻烦在于:这次试算本身,就可能抹掉它拒绝该报文时仍需依赖的当前状态。

2026年9月2日
Wes Hardaker 与那台必须熬过两种 TTL 的 DNS 服务器

IETF

Wes Hardaker 与那台必须熬过两种 TTL 的 DNS 服务器

新权威服务器已经稳定应答,旧服务器的流量也几乎归零。此时关机看似只是收尾;但对仍拿着父区旧委派的递归解析器而言,那不是收尾,而是把一条尚未到期的路突然截断。

2026年9月2日
Mirja Kühlewind:QUIC spin bit 测到的是应用周期,不一定是网络 RTT

IETF

Mirja Kühlewind:QUIC spin bit 测到的是应用周期,不一定是网络 RTT

旁路观测器每隔 200 毫秒看到一次整齐翻转,于是把路径 RTT 写成 200 毫秒。报文和减法都没有错,错的是问题:应用正以 200 毫秒为周期稀疏发送,实际路径快得多。

2026年9月2日
Murray Kucherawy:DKIM 验证通过时,邮件尾部仍可能没有签名

IETF

Murray Kucherawy:DKIM 验证通过时,邮件尾部仍可能没有签名

一封邮件的认证结果写着 `dkim=pass`,正文却不一定全部进入过签名计算。DKIM 的可选标签 `l=` 可以让哈希在规范化正文的某个位置停止;阅读器仍会继续显示后面的内容。绿色结果没有错,错的是把它扩大成“整封邮件都受保护”。

2026年9月1日
John Klensin:SMTP 的肯定答复接下责任,却不证明送达

IETF

John Klensin:SMTP 的肯定答复接下责任,却不证明送达

发件服务器在 DATA 结束后收到 `250 OK`,于是从队列中删掉本地副本。这个动作可以完全合规:远端已经接手。问题在于,很多面板把“有人接手”改写成了“收件人已经收到”。

2026年9月1日
Tomek Mrugalski:DHCPv6 的“成功”并没有续租

IETF

Tomek Mrugalski:DHCPv6 的“成功”并没有续租

设备换了网络,IPv6 地址仍在,DHCPv6 还返回 `Success`。最容易发生的错误,是把三件真事拼成一句假话:“租约已经续期。”RFC 9915 的边界更窄,也更可靠:地址适合当前链路,原有租期继续倒计时。

2026年9月1日
Bob Briscoe 与那枚无法证明低时延的 L4S 标记

IETF

Bob Briscoe 与那枚无法证明低时延的 L4S 标记

包头写着意图,排队器留下事实,时钟记录结果。RFC 9332 的精妙之处,正是没有把这三件事混为一谈:一个携带 ECT(1) 的包,可能被某个运营者有意送进 Classic 队列,而它端到端的 L4S 标识仍然保持不变。

2026年9月1日
Kent Watsen 与没有记录运行中套接字的 UDP 模型

IETF

Kent Watsen 与没有记录运行中套接字的 UDP 模型

一张配置截图能够证明系统曾收到怎样的意图,却不能证明内核最后绑定了哪个端口。RFC 9984 的价值,恰恰在于它没有让一份可复用模型冒充运行现场。

2026年9月1日
David Schinazi:目的端尚未回应,UDP 隧道为何已经成功

IETF

David Schinazi:目的端尚未回应,UDP 隧道为何已经成功

一个状态值首先要回答的,不是“成功了吗”,而是“谁有资格说成功”。CONNECT-UDP 的成功由代理发出,它确认自己已经准备转发;这句话不能越过网络,替尚未出声的目的端作证。

2026年9月1日
Christopher A. Wood 与不应由单一运营方掌握的隐私边界

IETF

Christopher A. Wood 与不应由单一运营方掌握的隐私边界

Oblivious HTTP 的核心不是让一家机构承诺“不看”,而是让任何一个合规角色都看不全:中继知道请求从哪里来,却打不开内容;网关能读懂内容,却不应知道最初是谁连进来。

2026年9月1日
Martin Thomson 与那份能解密会话、却不能证明会话发生过的密钥日志

IETF

Martin Thomson 与那份能解密会话、却不能证明会话发生过的密钥日志

抓包里出现了明文,调查报告便写下“会话已被证明”。这句话跨得太远。解密成功证明秘密材料与一组通信记录可以配合使用;它没有自动补上记录者、端点、授权、时间和保管链。

2026年9月1日
Todd Herr 与那封通过 DMARC 却依然不安全的邮件

IETF

Todd Herr 与那封通过 DMARC 却依然不安全的邮件

安全系统最容易犯的错误,不是算错,而是把算对的结果用到错误对象上。DMARC 显示 `pass` 时,它确认的是发件人域名的使用经过授权;它没有确认屏幕上的人名、邮件里的承诺、附件的安全性,也没有替收件服务器作出投递决定。

2026年9月1日
支持收件箱需要一只“案件时钟”

号码资源协会

支持收件箱需要一只“案件时钟”

邮件已经从会员一侧发出,并不等于接收机构已经受理、分派并约定下次回应。对于参与互联网号码资源治理的会员组织,解决办法不是承诺满足每项请求,而是让处理状态可以被看见、核对和追溯。

2026年8月26日
公开成员名录需要“撤出”状态

号码资源协会

公开成员名录需要“撤出”状态

公开名录可以说明今天谁被认可,却无法仅凭一个消失的名字解释昨天的认可如何终止、由谁终止,以及究竟终止了什么。

2026年8月25日
Alexey Galaev

全球机构趋势

Alexey Galaev

Alexey Galaev 的情报摘要说明事态进展、可核验的公开证据、相关组织、区域背景、市场风险敞口,以及可能带来的基础设施影响。全球机构趋势情报 语境将这一信号与网络运营、服务商策略、治理决策、资本流动、客户依赖、监管压力、合作关系动向、韧性规划、采购风险和服务连续性联系起来。

2026年5月26日