网络基础、发展史与互联网结构
内容摘要：本章建立学习计算机网络的第一层心智——网络要解决什么问题、互联网在物理与商业上如何组织、协议标准由谁定义、一份 RFC 从草案到废弃经历怎样的生命周期。理解这些，才能在后续章节把「协议字段」放回「它为什么存在」的语境里。
难度：入门 | 前置知识：无 | 所属层次：全局背景（非单一分层）
一、计算机网络要解决什么问题
计算机网络（Computer Network）的本质目标是：让分布在不同位置、由不同组织运营、使用不同硬件的计算设备之间可靠、可扩展、可演进地交换信息。这句话里的每个限定词都对应一类工程挑战：
| 目标 | 挑战 | 后续章节 |
|---|---|---|
| 不同位置 | 传播时延、带宽、丢包（物理规律不可回避） | 03 |
| 不同组织运营 | 谁来定义「怎么互通」、跨自治域路由与信任 | 11、本章标准组织 |
| 不同硬件 | 需要与介质无关的分层抽象 | 02 |
| 可靠 | 在不可靠的物理链路上构建可靠传输 | 13、14 |
| 可扩展 | 地址、路由、命名要能支撑数十亿节点 | 07、15 |
| 可演进 | 协议要能在不停机的情况下升级 | 本章 RFC 生命周期 |
设计动机：早期网络（如 20 世纪 60–70 年代的 ARPANET）要在部分节点损毁时仍能通信，这直接催生了「分组交换（packet switching）+ 无连接尽力而为（best-effort）转发」的设计——把复杂性推到端系统、让网络核心尽量简单。这条「端到端原则（end-to-end principle）」贯穿全书，也解释了为什么 TCP 的可靠性做在两端主机而非路由器里（详见 02、13）。
二、电路交换 vs 分组交换
理解互联网为何长这样，要先分清两种交换范式。
| 维度 | 电路交换（Circuit Switching） | 分组交换（Packet Switching） |
|---|---|---|
| 典型代表 | 传统电话网 | 互联网 |
| 资源分配 | 建连时预留固定带宽 | 按需统计复用（statistical multiplexing） |
| 建连开销 | 通话前需建立电路 | 无需预建，首包即可发 |
| 链路利用率 | 空闲时段浪费 | 高（多流共享） |
| 时延特性 | 建连后稳定、抖动小 | 有排队时延与抖动 |
| 故障容忍 | 电路中断即断话 | 可绕路重路由 |
| 适用场景 | 恒定速率、强时延保证 | 突发、异构、大规模 |
工程取舍：分组交换用「排队时延与抖动」换取了「高利用率与故障容忍」。这就是为什么实时音视频要专门做抖动缓冲与 QoS（见 QoS 与高可用），而文件传输几乎不在意抖动。
三、互联网的物理与商业结构
「互联网」不是一张由谁统一管理的网，而是数万个自治系统（Autonomous System，AS）通过商业与技术协议互联而成的「网络的网络」。理解其层级，是理解跨域路由（11）、CDN（18）和跨地域故障（分层故障排查）的前提。
关键概念：
- 自治系统（AS）：一个由单一机构统一路由策略管理的网络，用 AS 号（ASN） 全球唯一标识。AS 之间用 BGP 交换路由（11）。
- ISP 层级：
- Tier-1（骨干）：不向任何人付费购买中转（transit），仅靠对等（peering）即可到达全网。
- Tier-2（区域）：既向 Tier-1 购买中转，也与同级对等。
- Tier-3（接入）：主要向上游购买中转，直接服务终端用户。
- 对等（Peering）vs 中转（Transit）：对等是「互相免费交换各自及客户的路由」，中转是「付费换取到全网的可达性」。这套商业关系直接决定了数据实际走的物理路径，也解释了为什么两个「地理相邻」的用户流量可能绕行很远（非对称路由，见 分层故障排查）。
- 互联网交换中心（Internet Exchange Point，IXP）：多方在同一物理设施对等，缩短路径、降低成本。
- 内容分发网络（Content Delivery Network，CDN）：把内容缓存到离用户更近的边缘节点，甚至嵌入 ISP 内部（18）。
失败模式预告：因为路径由商业关系与 BGP 策略决定，「A 能到 B」不代表「B 能原路到 A」。这种非对称路由会让只在一侧抓包的排障产生误判（见 20 抓包与实验、分层故障排查）。
四、发展史里的关键决策（为什么重要）
历史细节可以查资料，但几个决策塑造了今天的协议行为，值得记住其「因果」而非年份：
| 决策 | 影响至今 |
|---|---|
| 分组交换 + 无连接 IP | 网络核心简单、可绕路；可靠性交给端系统 TCP |
| TCP 与 IP 分离（原本一体） | 传输语义（可靠/不可靠）与转发解耦，才有了 UDP |
| 端到端原则 | 新应用无需改造网络核心即可部署（Web、视频、区块链…） |
| 32 位 IPv4 地址 | 地址耗尽 → NAT 普及（19）→ IPv6（08） |
| 明文协议起家（HTTP/DNS/…） | 后期不得不叠加 TLS/DoT/DoH 补安全（15、17） |
认知校准：不要把这些历史选择当成「最优设计」，它们是在特定约束下的工程取舍。例如 NAT 既缓解了地址耗尽，又破坏了端到端连通性，催生了 STUN/TURN/ICE（19）。理解「取舍」比记忆「结论」更重要。
五、谁定义标准：标准组织与分工
协议的权威定义来自标准组织，而非博客或培训材料。涉及协议格式与状态机时必须回到对应标准（本知识库的硬性引用规范）。
| 组织 | 英文 / 缩写 | 负责领域 | 产出物 |
|---|---|---|---|
| 互联网工程任务组 | Internet Engineering Task Force, IETF | TCP/IP、DNS、HTTP、TLS、路由等核心协议 | RFC |
| 互联网号码分配机构 | Internet Assigned Numbers Authority, IANA | 端口号、协议号、地址块、DNS 根等参数注册 | 注册表（registry） |
| 地区互联网注册管理机构 | Regional Internet Registry, RIR | IP 地址与 ASN 的区域分配（如 APNIC/ARIN/RIPE） | 分配记录 |
| 电气电子工程师学会 | IEEE | 以太网、Wi-Fi 等 802 系列物理/链路层标准 | IEEE 802.x |
| 万维网联盟 / WHATWG | W3C / WHATWG | Web 平台、HTML、Fetch、URL 等规范 | Recommendation / Living Standard |
| CA/浏览器论坛 | CA/Browser Forum | 公共证书签发规则（Baseline Requirements） | BR 文档 |
| 互联网名称与数字地址分配机构 | ICANN | 顶层协调 DNS 与地址体系（IANA 职能运营） | 政策 |
引用优先级（本库统一遵循）：RFC/Internet-Draft 状态页 → IEEE 802 → IANA 注册表 → W3C/WHATWG/CA/B Forum → 各官方实现文档 → CVE/NVD → 高质量交叉验证资料。不得仅凭搜索摘要或问答网站写入协议/版本敏感结论。
六、RFC 是什么与它的生命周期
RFC（Request for Comments，请求评议） 是 IETF 体系发布文档的统称。并非所有 RFC 都是「标准」——这是初学者最常见的误解。
1、RFC 的类别与成熟度
一份 RFC 有两个正交属性：类别（category） 与 状态（status）。
- 类别：Standards Track（标准track）、Informational（信息）、Experimental（实验）、Best Current Practice（BCP，当前最佳实践）、Historic（历史）。
- 标准 track 的成熟度阶段（RFC 6410 简化后）：Proposed Standard（建议标准）→ Internet Standard（互联网标准）。早期的「Draft Standard」阶段已被合并取消。
2、关键认知（避免踩坑）
- Internet-Draft（I-D）不是 RFC：草案 6 个月无更新即过期，不能当稳定标准引用。
- RFC 一经发布，内容不可修改：修订通过发布新 RFC 并「obsoletes（废弃）」旧 RFC 实现。例如 HTTP/1.1 语义由 RFC 9110 定义，废弃了早期的 RFC 7230–7235；TCP 由 RFC 9293 定义，废弃了经典的 RFC 793。
- 勘误（Errata）：已发布 RFC 的错误通过 Errata 记录，不改原文。
- 「知名端口」不等于「协议只能用该端口」：端口与协议号由 IANA 注册（如 HTTP=80、HTTPS=443、DNS=53），但实际可自定义；排障时不要假设「443 一定是 HTTPS」（见 16、分层故障排查）。
待验证/时效说明：具体某 RFC 的最新状态、被谁废弃，会随时间变化，应在使用时查 IETF Datatracker 的状态页与勘误确认。本章所述流程与类别以 RFC 2026、RFC 6410、RFC 7841、RFC 8700 为准，
verified_at: 2026-09-07。
七、最小可复现实验：观察「一次访问」触及的多层与多方
本实验用只读、无副作用的客户端命令，直观感受本章抽象（端到端、多跳、多组织）。仅访问 IANA 保留的文档域名 example.com，不接触真实业务资产。
1、实验目标
- 用一条命令看到「域名 → IP → 建连 → 应用响应」跨越的层次。
- 用
traceroute感受「逐跳」与「多组织路径」（并理解其局限）。
2、平台与工具
- 本机验证环境：macOS 26.6.2，
curl 8.7.1、DiG 9.10.6。Linux 上命令一致（traceroute可用tracepath替代，无需 root）。
3、执行命令与本机实测输出
DNS 解析（应用层命名 → 网络层地址）：
dig +noall +answer example.com A本机实测（2026-09-07，输出会随时间/地域变化，属正常现象）：
example.com. 284 IN A 172.66.147.243
example.com. 284 IN A 104.20.23.154一次完整 HTTPS 访问的分阶段时延（DNS → TCP → TLS → 首字节）：
curl -sS -o /dev/null -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\nhttp_version=%{http_version} remote=%{remote_ip}\n' https://example.com/本机实测（2026-09-07）：
dns=0.002301s tcp=0.346848s tls=0.474025s ttfb=0.596131s total=0.596427s
http_version=2 remote=104.20.23.154解读：这一条命令就串起了本书主干——DNS（15）解析出 IP，TCP（13）建连，TLS（17）握手，HTTP/2（16）取回响应。
tcp - dns ≈ 0.34s是三次握手的 1 个 RTT 量级，tls - tcp ≈ 0.13s是 TLS 1.3 握手，二者之和构成了「首字节」前的固定开销。这解释了后续为何要关注连接复用、0-RTT 与就近接入。
逐跳路径（体会「多跳、多组织」，注意其局限）：
traceroute -n -q1 -w2 example.com # Linux 无 root 可用: tracepath example.com未在本环境粘贴 traceroute 输出的原因：
traceroute结果高度依赖测量点的网络位置，且中间设备常对探测限速或不回应（显示* * *），把某次输出写进知识库会误导读者以为那是「固定路径」。这正是本库的硬性规则：不得把 traceroute 的单向路径与每跳 RTT 当作完整双向业务路径与精确链路时延（见 09、分层故障排查）。请在自己环境运行并结合双向证据解读。
4、预期现象与结论边界
dig可能返回多个 A / AAAA 记录且随查询变化——这是 CDN 与 DNS 负载均衡的正常表现，不代表「解析不稳定」。curl的各阶段时延受地理位置、缓存命中、就近节点影响，属单点观测，不能推广为「该站点全球时延」。
5、清理与恢复
本实验为只读查询，无需清理，未修改任何本机或网络配置。
八、错误示例与常见误区
| 误区 | 纠正 |
|---|---|
| 「所有 RFC 都是必须遵守的标准」 | 多数 RFC 是 Informational/Experimental；只有 Standards Track 才是标准，且分 Proposed / Internet Standard 成熟度。 |
| 「互联网有中心机构统一管理路由」 | 没有。路径由各 AS 的 BGP 策略与商业关系决定（11）。 |
| 「地理相邻 = 网络路径短」 | 路径由对等/中转关系决定，可能绕行；需实测。 |
| 「端口 443 一定是 HTTPS」 | 端口是 IANA 约定，实际可自定义；排障要抓包确认协议（20 抓包与实验）。 |
| 「traceroute 显示的就是数据真实往返路径」 | 它是单向、逐跳的探测，受限速/ECMP/非对称路由影响，不等于业务双向路径。 |
九、性能影响
本章为背景知识，无直接性能开销。但互联网结构决定了性能上限：跨 Tier-1、跨地域、跨 IXP 的路径会显著增加 RTT，进而放大 TCP 建连、TLS 握手与拥塞控制的影响（见 03、14）。这也是 CDN 存在的根本原因——用「就近」压缩 RTT。
十、安全风险与加固
- 信任边界：数据可能穿越多个组织的网络，默认不可信。这是为什么应用层要用 TLS（17）、DNS 要用 DoT/DoH/DNSSEC（15）。
- 路由劫持：因 BGP 缺乏内建强认证，恶意或误配的 AS 可宣告不属于自己的前缀，劫持流量（详见 11、网络安全）。
- 本库红线：不得默认扫描、嗅探、攻击或修改不属于实验环境的网络；安全实验限于授权隔离环境（见总目录第八节）。
十一、常见问题与排查方向
- 「域名解析出多个 IP、每次还不同」：正常，DNS 负载均衡/CDN 所致（15）。
- 「同一网站在公司快、在家慢」：路径/对等关系/就近节点不同，需两端实测对比（分层故障排查）。
- 「查资料说的协议行为和实测不一致」：区分标准要求与实现差异，回到 RFC 与官方实现文档核对（本章第五、六节）。
十二、关联章节
检索关键词
分组交换 vs 电路交换 端到端原则 ISP 层级 Tier-1 对等与中转 peering transit IXP 标准组织 IETF IANA IEEE RFC 生命周期 Internet-Draft 不是标准 RFC 废弃 obsoletes
权威来源
- RFC 2026《The Internet Standards Process》及其更新 RFC 6410、RFC 7841
- RFC 8700《Fifty Years of RFCs》（RFC 历史与流程综述）
- IETF Datatracker（RFC/I-D 状态页与勘误，使用时以其为准）
- IANA 协议参数与端口注册表
- IEEE 802 标准页
本章流程与分类以上述 RFC 为准，
verified_at: 2026-09-07；实测命令输出来自 macOS 26.6.2 本机，仅为示例，随时间与网络位置变化。