主要领域
互联网基础设施
在 主要领域 分类下，互联网基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
互联网历史
由接收方决定谁先到
1981 年的邮件事务可以从一句试探开始：`MRSQ ?`。接收方回答 `215 T Text first, please`，意思不是它更喜欢某种排版，而是要求先把整段正文存下来，再逐个给出收件人。发送方可以提议另一种次序，却不能替接收方决定，因为真正要保存的是收件人表还是正文、什么时候能给出失败证据，取决于对端内部怎样递送邮件。SMTP 后来删掉了这场编舞协商，把一条可变状态机固定成今天熟悉的顺序。
互联网历史
发送端没有发送的字节：FTP MODE C 如何从 TYPE 重建填充内容
解码器读到一个有效长度，后面却没有可供重复的样本字节。这不是丢包，也不是文件被截断。FTP 的压缩模式故意把值留在数据流之外：会话此前协商的表示类型，已经决定接收端应当补入空格还是零。
互联网历史
每经一次中继，路径就后退一步
邮件抵达中继 ONE 时，收件命令里的地址不是普通的 `JOE@THREE`，而是 `@ONE,@TWO:JOE@THREE`。ONE 要做一件今天看来反直觉的事：从向前路径最左端删去自己，再把自己写到反向路径的最前端。通往收件人的指令缩短了一段，通往退信责任方的路径却增长了一段。早期 SMTP 把行程写进信封，也让行程在每次交接时改变方向。
互联网历史
必须出现两次的字节：FTP 如何在连续流中写入记录边界
接收程序读到一个全 1 字节，却还不能把它交给文件。它必须等待下一个字节：再来一个全 1，二者还原成一个字面数据；若后面是 1、2 或 3，这一对便分别关闭记录、关闭文件，或同时完成两件事。FTP 没把网络切块误当成文件结构，而是在流里建立了一套可逆语法。
IETF
Ray Bellis 与那台必须转发“未知”的 DNS 代理
一台家庭网关会告诉所有终端：DNS 先交给我。它看起来只是把查询转给上游，却因此站在了新协议功能必经的位置。Ray Bellis 在 RFC 5625 中给这类代理划出的权力边界很窄：可以管理转发、接口和明确的本地策略，但不能把自己不认识的字段，当成 DNS 不允许存在的字段。
互联网历史
缺失的页面不是零页：FTP STRU P 如何在主机之间传递空洞
接收端先看到一个页面，随后又看到索引更靠后的页面，中间位置却没有任何数据穿过网络。FTP 的页结构不要求把它判断为丢包，也不允许随手填成零页：那段沉默可能正是源文件需要保留的结构。
互联网历史
被切开以后仍须随行的指令
一份 IPv4 数据报同时带着两种路径记录：类型 131 的宽松源路由，其类型字节最高位为一；类型 7 的普通记录路由，最高位为零。路由器把数据报切成三片后，零偏移片保留两者，后两片却只带前者。同一数据报由此拥有三份并不等长的首部。这不是损坏，而是一位 Copy 标志指导下的合法派生。
互联网历史
一次尚未发生的重命名：FTP 如何把文件留在 RNFR 与 RNTO 之间
服务器答复了一个肯定的 `350`，监控面板便把重命名标成成功；但此时旧文件名可能一个字节都没有改变。FTP 把一次重命名拆成 `RNFR` 与 `RNTO`，也把“接受来源”与“完成变更”之间那段最容易被日志抹平的状态暴露了出来。
互联网历史
线路没有定义的那个字节
九个八位传输单元沿着 FTP 数据连接抵达，却在文件里只构成两个逻辑单位。因为发送方执行了`TYPE L 36`：每个有意义的单位长 36 位，两个单位合计 72 位，恰好穿过九个线上八位组。线路规定怎样搬运这些位，却没有取得把“字节”永远定义成八位的权力。
互联网历史
一次未被文件系统切换终止的登录：FTP SMNT 如何分开身份与命名空间
如果审计日志里两次出现同一个用户、同一条路径，人们很容易认定访问的是同一份文件。早期 FTP 却留下了一个反例：`SMNT` 可以在不清除登录、记账信息和传输参数的情况下，更换当前文件系统结构。会话仍是原来的会话，名字赖以成立的空间却已经换了。
互联网历史
一封试图抢在邮箱前抵达的邮件：SMTP 为何放弃终端投递
早期 SMTP 不只负责把邮件交给邮箱。发送方可以要求文字直接出现在用户正在使用的终端上，也可以选择“终端优先、邮箱兜底”，或者要求终端与邮箱同时接收。这个被遗忘的分支，把“此刻在线并愿意被打断”写进了传输协议；它后来退居兼容角落，恰好说明即时注意力为何不能等同于持久交付。
互联网历史
那盏绿灯并不属于你：NNTP 如何拆开新闻组规则与发帖权限
一行以 `y` 结尾的新闻组目录看上去像准入证明，可当前用户发出 `POST` 后，服务器仍能答复 `440 Posting not permitted`。这不是协议自相矛盾，而是早期互联网留下的一次精确分工：目录说明新闻组通常怎样处理来稿，具体会话能否投稿则要在另一道门上决定。
互联网历史
密码正确以后，FTP仍在等一个账户
用户已报上名字，密码也没有被拒绝，客户端却没有收到“已经登录”。服务器回的是`332`：还需要账户信息。早期 FTP 把今天常被压成一次登录的动作拆成了三个事实——你声称是谁、你给出的密码是否满足这一关、这次工作应当落在哪个本地账户上下文里。
IETF
Brian Carpenter 与必须证明“谁在里面”的网络边界
网络图上的边界总是很干净：机房、园区、云上租户或工业网络，各有一圈颜色。数据包看不见这圈颜色。Brian Carpenter 与 Bing Liu 在 RFC 8799 中追问的，正是工程师常常略过的一步：当一种协议只在局部有意义时，谁能证明成员身份、边界角色与出站行为真的和图上一致？
互联网历史
双方从未协商出的那个数字
一次 TCP 握手里可以同时出现两个不同的 MSS：客户端报 1460，服务器报 1200。它们并不冲突，也不需要选出胜者。客户端写下的是“你发给我的 TCP 数据段最多可以有多大”，服务器写下的则是反方向的同一句话。真正发送时，两端还要各自把对方的上限、IP 层此刻允许的尺寸和当前报文头开销重新合并。所谓“协商后的 MSS”，从一开始就是一个容易把三种事实压成一个数字的说法。
互联网历史
必须保留原名的投稿：NNTP 如何约束丢失的最终回复
文章全文已经越过连接，终止点也已送达。服务器可能完成接收并发出 `240`，但客户端只看见断线。重新连接后，阅读界面里暂时找不到文章也不能证明失败，因为稿件或许仍在等待审核。NNTP 没有承诺“只执行一次”，而是要求重试仍指向同一个 Message-ID。
互联网历史
认证也无法续接的命令：NNTP 为什么要求客户端再问一次
客户端先请求一个受限新闻组，服务器答复 `480`；客户端随后完成认证，得到 `281`，但新闻组并不会因此自动打开。它必须把原命令再发送一遍。NNTP 用这次看似多余的重问划出了一条重要边界：认证可以改变会话中的身份，却不能替客户端复活一项已经被拒绝的意图。
互联网历史
可以忘掉的，是接收记录
一个不保证补发丢失数据的传输协议，为什么还要认真保存确认记录，甚至要求对方确认自己收到过确认？DCCP 把两种看似相近的责任分开了：过时的应用数据可以不再发送，但拥塞控制所依赖的接收历史不能随意消失。真正值得追问的不是确认有多少层，而是哪一层的责任已经结束。
互联网历史
活跃目录里没有出生记录，历史档案里却留着退役群组：ACTIVE.TIMES 如何限制证据的权力
同一台 NNTP 服务器给出两份不一致的名单：一个今天仍可选择的新闻组没有创建记录，另一个已经不能选择的新闻组却仍留在历史档案里。这不是数据坏了，而是协议拒绝让“现在提供什么”与“过去还记得什么”互相冒充。
互联网历史
写入返回时，数据还不安全
远端服务器已经回了成功，客户端却仍不能释放手里的那份数据。字节也许只停在一段会随重启消失的内存中。NFS 第三版没有用一个含糊的“成功”掩盖这段空隙，而是把持久程度、服务器实例和重传责任拆开，让提速建立在可恢复的未完成状态上。