跳转到主要内容

主要领域

基础设施

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

一个数据包为何会让共享链路上的其他人等待:RFC 3150

互联网历史

一个数据包为何会让共享链路上的其他人等待:RFC 3150

在很慢的链路上,数据包大小也决定了其他共享接口的通信要等多久。RFC 3150 把这段时间纳入设计约束,而不只把 MTU 看作字节效率问题。

2026年10月1日
Call Agent 控制功能,静音键却留在本地:RFC 3149

互联网历史

Call Agent 控制功能,静音键却留在本地:RFC 3149

MGCP 把呼叫控制的“智能”放在电话之外,但 RFC 3149 没有把每一次触摸都送进网络。功能键的编号由远端 Call Agent 解释,XML 屏幕甚至拥有独立 endpoint;音量、听筒与免提之间的即时切换,以及静音键和指示灯,却由电话本地执行。中心可以定义意义,不等于中心必须占有全部动作。

2026年10月1日
同一条路径为何会有两个都成立的容量数字:RFC 3148

互联网历史

同一条路径为何会有两个都成立的容量数字:RFC 3148

单流大数据传输测试看起来只会产生一个数字。RFC 3148 指出,传输算法的选择会让这个数字取决于测量方法,因此必须保留它背后的路径证据。

2026年10月1日
新管理网络必须穿过旧网络:RFC 3147

互联网历史

新管理网络必须穿过旧网络:RFC 3147

迁移图上总有一支从“旧”指向“新”的箭头,真实网络却不会沿箭头整齐移动。2001 年,新的 SONET/SDH 网元开始用 IP 管理,而抵达它们的路仍可能是一片不能立即拆除的 CLNS 管理网。RFC 3147 用 CLNP 承载 GRE,再由 GRE 承载 IP。这个不起眼的反向隧道揭示了迁移的本质:替代首先是共存,旧系统暂时成了新系统的通道。

2026年10月1日
隧道已经关闭,原因码仍无权裁决原因:RFC 3145

互联网历史

隧道已经关闭,原因码仍无权裁决原因:RFC 3145

一条 PPP 会话可以在 L2TP 隧道里结束,而看见故障细节的主机与面对用户的主机并不属于同一家机构。RFC 3145 让原因穿过这道边界,却刻意不让原因码变成判决:报告者、协议、方向、隧道结果和后续事实必须分别保留。

2026年10月1日
用户选好了来电怎么处理,网络却还没有执行:RFC 3136

互联网历史

用户选好了来电怎么处理,网络却还没有执行:RFC 3136

电脑窗口里,“转接”按钮已经亮起;电话交换机里的呼叫却仍在等待。2001 年的 RFC 3136 用 SPIRITS 架构说明了两者之间的距离:用户的选择只是意图,真正改变呼叫还要经过网关、业务控制与交换执行。

2026年10月1日
网络策略写着 Gold,每台设备却只能由一个翻译器写入:RFC 3139

互联网历史

网络策略写着 Gold,每台设备却只能由一个翻译器写入:RFC 3139

“给这些客户 Gold 服务”是一句全网承诺,却不是任何一台路由器能够直接执行的配置。2001 年的 RFC 3139 把中间链条逐层展开:拓扑与能力输入、全网配置、设备本地翻译、唯一写入者、同步下发、反馈,以及最终流量行为。

2026年10月1日
代理已经确认字节,应用却还没有收到:RFC 3135

互联网历史

代理已经确认字节,应用却还没有收到:RFC 3135

发送端看到 ACK,便继续加速。可那条确认并不是从远端应用返回的,数据甚至还没有越过最难的一段链路。2001 年的 RFC 3135 把这种性能优化拆开来看:更快的反馈确实有用,但它也把保管责任、故障状态与证据权力转移给了路径中的代理。

2026年10月1日
交付率很好,应用表现却很差:RFC 3133

互联网历史

交付率很好,应用表现却很差:RFC 3133

一条很小的确认帧丢了。其余大多数数据都抵达,仪表盘上的百分比依然漂亮;发送方却不得不重做大得多的一批工作。2001 年的 RFC 3133 没有把这个矛盾藏在脚注里,而是直接写进了指标的解释。

2026年10月1日
第一个数据包必须先叫醒主机,才能抵达:RFC 3132

互联网历史

第一个数据包必须先叫醒主机,才能抵达:RFC 3132

移动主机为了省电,不再持续监听承载普通流量的无线信道。于是,第一个数据包到来时,网络面对的已不只是转发问题,而是一场定位、唤醒与重建路径的接力。

2026年10月1日
路由器不再承载中转,却仍然可达:RFC 3137

互联网历史

路由器不再承载中转,却仍然可达:RFC 3137

把一台路由器从最短路径上移开,不等于必须把它从拓扑中抹掉。RFC 3137 用最高链路代价表达了这个差别:节点还在,抵达它仍有路径,但经过它应当成为最后选择。

2026年10月1日
一天的研讨会测不到签名过期:RFC 3130

互联网历史

一天的研讨会测不到签名过期:RFC 3130

到 IETF 49 前后,DNSSEC 社群遇到的难题不再只是“记录能否签、验证器能否验”。一次为期一两天的演示可以在所有计时器到期之前圆满结束,却无法证明跨组织的密钥轮换、父子区交接、缓存与应用在更长时间里仍然一致。

2026年10月1日
KDC 扛起了每个 IPsec 对等体无力独担的信任:RFC 3129

互联网历史

KDC 扛起了每个 IPsec 对等体无力独担的信任:RFC 3129

2001 年 6 月,RFC 3129 没有把密钥交换仅仅写成密码算法之间的竞争。它追问的是组织问题:当每个 IPsec 对等体都要自行承担策略、证书、计算和成对密钥时,能否把其中一部分责任交给 Kerberos 密钥分发中心,以换取一个更可治理的系统?

2026年10月1日
第一个分片通过了,重叠分片却改写了端口:RFC 3128

互联网历史

第一个分片通过了,重叠分片却改写了端口:RFC 3128

RFC 3128 揭示的并不是一个“防火墙什么都没看”的故事。恰恰相反,过滤器看到了足够像正常 TCP 首部的第一份字节,并据此作出了合理决定;危险在于,终点主机随后可能从同一组分片中重组出另一份首部。

2026年10月1日
长期证据必须比密钥活得更久:RFC 3126

互联网历史

长期证据必须比密钥活得更久:RFC 3126

RFC 3126 把旧签名视为一个证据保管问题。2001 年成立的密码学计算,若干年后未必还能自证:证书会过期,撤销记录会消失,时间戳机构的密钥会老化,hash 也会变弱。它给出的不是“永久可信”按钮,而是一条必须持续维护的证据链。

2026年10月1日
有效签名仍然需要一份策略:RFC 3125

互联网历史

有效签名仍然需要一份策略:RFC 3125

RFC 3125 试图把电子签名周围的规则变成可引用、可校验、必要时可由机器处理的对象。密码学计算正确,只打开了第一道门;真正的“有效”还取决于哪一版策略、哪种承诺、哪些信任条件,以及外部制度是否承认它们。

2026年10月1日
一次发送许可还不是一个数据包队列:RFC 3124

互联网历史

一次发送许可还不是一个数据包队列:RFC 3124

拥塞管理器试图在一台主机内协调多个应用何时发送,却有意不接管它们的数据。RFC 3124 最值得记住的边界,是把请求、短时许可、本机实际发送与接收端反馈拆成不同事实。

2026年10月1日
前缀列表还不是访问策略:RFC 3123

互联网历史

前缀列表还不是访问策略:RFC 3123

DNS 可以准确发布一串网络前缀。RFC 3123 更重要的克制,是没有把这串数据伪装成命令:记录负责表示,应用负责解释,运营者负责决定,执行点才负责动作。

2026年10月1日
延迟数字也在陈述时钟:RFC 3116

互联网历史

延迟数字也在陈述时钟:RFC 3116

ATM 实验室里,接收时间减去发送时间似乎就是答案。RFC 3116 把被减法遮住的条件重新摆上台面:先证明两个时间戳属于同一时间轴,再谈交换机用了多久。

2026年10月1日
共享同一套系统,不等于合并批准权:RFC 3113

互联网历史

共享同一套系统,不等于合并批准权:RFC 3113

2001 年,第三代移动系统必须接入互联网,IETF 也必须听见无线网络的约束。RFC 3113 没有为两者发明一个共同上级,而是把协作设计成一条不夺权的接口。

2026年10月1日