1991 年 8 月 6 日，互联网上出现了第一个公开可访问的网页。它的内容是关于如何使用万维网的说明，由 Tim Berners-Lee 在瑞士日内瓦的 CERN（欧洲核子研究中心）托管。地址后来常写成 http://info.cern.ch。万维网的第一份公开文档是说明书，不是报纸：它教人怎么用浏览器、服务器和 HTML。
这一天距 ARPANET 建立已过去 22 年。互联网（Internet）存在了 22 年，但万维网（World Wide Web）才刚刚开始。互联网和万维网常被混用，实际上截然不同：互联网是底层的网络基础设施，万维网是运行在互联网之上的一种特定的信息超链接系统。
1993 年 4 月 30 日，CERN 把万维网软件放进公有领域。几个月后 Mosaic 浏览器把图片嵌进页面，网不再只是物理学家的备忘录。协议开放与多媒体被一次性打包，两件事叠在一起，网才从高能物理的说明书变成报纸的对手。Berners-Lee 没有为协议申请专利。开放是后来爆炸的前提，也是后来中心化的缝：谁都能建站，流量却可以重新集中。状态码是一份共享词汇。404 不只是失败，它让爬虫、监控和人用同一个数字谈话。没有这张表，缓存不知道何时重试，搜索引擎不知道何时删库。
明文 HTTP 在 2010 年代的死亡，是监听丑闻、搜索排名和免费证书三件事叠出来的，不是一次技术会议的决议。安全默认值往往不是密码学先胜，而是激励改了。
破除误解：网络不等于互联网
互联网（Internet）是由 TCP/IP 协议连接的全球计算机网络，支持电子邮件、FTP、VoIP、万维网等众多服务。万维网（World Wide Web，WWW）是其中一种服务：以超链接文档（HTML）为形式，以 HTTP 为传输协议，以 URL 为地址系统的信息空间。
没有万维网，互联网仍然存在——电子邮件、新闻组、FTP 都在万维网诞生前运作多年。Berners-Lee 的贡献是把文档、链接、地址和传输协议打包成一个易于使用的系统。
三个核心构件
万维网不是一夜之间出现的。1989 年 3 月，Berners-Lee 向 CERN 提交了一份名为《Information Management: A Proposal》的备忘录，主张用超文本把机构内分散的文档连成网络——当时他甚至没给系统定名，一度称之为 "Mesh"，"World Wide Web" 是 1990 年写代码时才定下的。同年他与同事 Robert Cailliau 正式立项，并在年底亲手做出三样东西：第一个浏览器（同时也是编辑器，名叫 WorldWideWeb）、第一个 Web 服务器、第一个网站。这个网站早在 1990 年 12 月 20 日就在 CERN 内网上线，1991 年 8 月 6 日才对 CERN 之外的公众开放。万维网真正的骨架，是下面三个彼此配合的发明：
1. URL（统一资源定位符）：给每个资源一个全球唯一的地址。
``
https://www.example.com:443/path/to/page?key=value#section
|____| |_____________| |__| |_________| |_______| |_____|
协议 主机名 端口 路径 查询字符串 片段
``
2. HTML（超文本标记语言）：描述文档结构和内容，以及文档之间的链接。链接让"超文本"成为现实——读者可以自由跳转，不再受线性阅读的限制。
3. HTTP（超文本传输协议）：客户端（浏览器）与服务器之间的请求/响应协议。
HTTP 的工作原理
HTTP 是无状态的请求-响应协议。每次交互：
客户端发送请求：
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html服务器返回响应： HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 1234
<html>...</html> ```
HTTP 方法（动词）定义操作语义：
- GET：获取资源，无副作用，可缓存
- POST：提交数据，创建资源
- PUT：替换资源
- PATCH：部分更新资源
- DELETE：删除资源
- HEAD：只获取响应头，不要正文
- OPTIONS：查询服务器支持哪些方法
状态码告知结果：
| 范围 | 含义 | 常见示例 |
|---|---|---|
| 2xx | 成功 | 200 OK, 201 Created, 204 No Content |
| 3xx | 重定向 | 301 永久移动, 302 临时移动, 304 未修改 |
| 4xx | 客户端错误 | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | 服务器错误 | 500 Internal Server Error, 503 Service Unavailable |
安全方法与幂等方法：RFC 9110 给 HTTP 方法赋予两条正交的语义约束。安全（safe）指方法本质上是只读的、客户端不期望它改变服务器状态——GET、HEAD、OPTIONS 都安全。幂等（idempotent）指同一个请求发一次和发多次，对服务器的最终影响相同——GET、PUT、DELETE 都幂等（对同一资源重复 DELETE，结果都是"它不存在"）。POST 既不安全也不幂等：连点两次提交按钮，可能真的下两笔订单。这套语义不是吹毛求疵——浏览器、代理与 CDN 正是据此决定能否缓存响应、能否在超时后自动重试请求。若把"修改数据"误用 GET 实现，搜索引擎爬虫或浏览器预取就可能在你毫不知情时改坏后台数据。
HTTP 的演化：从 0.9 到 3
HTTP/0.9（1991）：只有 GET 方法，只能传 HTML，每次请求新建 TCP 连接。
HTTP/1.0（1996，RFC 1945）：引入方法、头部、状态码、多媒体类型。仍然每请求一连接。
HTTP/1.1（1997，RFC 2068；修订 1999，RFC 2616）：引入持久连接（Keep-Alive）（同一 TCP 连接复用多次请求）、管道（Pipelining，允许连续发送请求不等响应）、分块传输编码、Host 头（允许一个 IP 托管多个域名）。Host 头看起来像一条小字段，经济后果很大：没有它，一个 IP 只能挂一个域名，共享主机和后来的虚拟主机业态几乎长不出来。HTTP/1.1 统治互联网长达 15 年以上。这份规范本身也在不断打磨：2014 年它被拆分重写为 RFC 7230–7235（语法、语义、缓存、认证各自成篇），2022 年又整合为 RFC 9110–9112，并首次升格为互联网标准（Internet Standard，STD 97）。管道在实践里几乎没站住——队头阻塞加上代理实现不一致，浏览器后来默认关掉它。真正把并行做进一条连接的，是 HTTP/2 的多路复用。
HTTP/2（2015，RFC 7540；2022 年经 RFC 9113 修订）：脱胎于 Google 2009 年发布的实验性协议 SPDY。核心改进： - 二进制帧（取代文本格式，更高效解析） - 多路复用（Multiplexing）：单个 TCP 连接上并行传输多个请求/响应流 - 头部压缩（HPACK）：减少重复头部的传输量 - 服务器推送（Server Push）：服务器可主动推送资源
压缩加加密曾打开过一扇窗：CRIME、BREACH 一类攻击吃的就是压缩比泄漏的秘密。后来的协议在压缩和保密之间更谨慎。性能优化会重新打开密码学以为关上的窗。
HTTP/2 消除了 HTTP/1.x 的"队头阻塞"（在应用层）——但 TCP 层的队头阻塞仍然存在。
HTTP/3（2022，RFC 9114）：传输层从 TCP 换为 QUIC（RFC 9000，基于 UDP）。QUIC 让每条流独立处理丢包，彻底消除了 TCP 层的队头阻塞；它还支持连接迁移（手机从 Wi-Fi 切到蜂窝网络也不断连），并把 TLS 加密内建进握手。第一次往返就能带上加密，是为了把"建连"从多次握手压成一次。据 Cloudflare 统计，2025 年已有约 35% 的请求走 HTTP/3。比例随运营商和客户端变化，把它当成全网常数并不稳；方向是清楚的：Web 的传输层正在从"可靠字节流"换成"可靠的多条流"。
REST：Web API 的架构风格
REST（Representational State Transfer）由 Roy Fielding 在 2000 年的博士论文中提出，是一套描述 Web 架构风格的约束集合。RESTful API 把网络服务的每个资源赋予 URL，用 HTTP 方法表达操作语义：
GET /users/42 # 获取用户 42 的信息
POST /users # 创建新用户
PUT /users/42 # 替换用户 42 的信息
DELETE /users/42 # 删除用户 42
```REST 不是标准，是一种风格。它的普及使 Web API 设计趋于统一，但"真正的 RESTful"在工程界常有争议。GraphQL（Facebook，2015）和 gRPC（Google，2016）是主要的替代方案，各有适用场景。
HTTPS 与 TLS
HTTP 本身是明文——所有传输数据包括密码都可被监听。HTTPS = HTTP over TLS：在 TCP 和 HTTP 之间加入 TLS 层，实现加密和服务器身份验证。
2010 年代，推动 HTTPS 的历史事件包括： - 斯诺登披露（2013）：NSA 大规模监听互联网流量 - Google 从 2014 年起给 HTTPS 网站在搜索排名中加分 - Let's Encrypt（2015）：免费自动化证书颁发，让小网站也能用 HTTPS。证书不再是每年几百美元的门禁，HTTPS 才从银行网站变成默认。技术门槛下降之后，明文 HTTP 失去了"太贵所以不用"的借口。
2023 年，约 95% 的 Chrome 浏览器页面加载使用 HTTPS。明文 HTTP 实际上已成遗迹。
Cookie 与会话：打破无状态
HTTP 的无状态性（每个请求互相独立）在功能上是简单性的来源，在工程上却是麻烦——如何让服务器记住"用户已登录"？
Cookie（1994 年由 Netscape 工程师 Lou Montulli 发明）：服务器在响应中设置小型键值对，浏览器在后续请求中自动携带。这让"会话"成为可能。"cookie" 这个名字借自 Unix 世界早已有的 "magic cookie"——一段由客户端原样带回给服务器的数据。它最初只是 Netscape 的私有约定，直到 1997 年 2 月才被 RFC 2109 正式标准化。
这里要破除一个常见误解：HTTP 无状态，并不等于"网站记不住你、没法登录"。无状态说的是协议层——每个请求自带全部信息，服务器不被强制保留上一个请求的上下文。登录态是在应用层补出来的：要么把会话标识塞进 cookie，要么把令牌（如 OAuth 2.0 的 Bearer token、JWT）放进 Authorization 头随请求带上。无状态反而是优点——它让任意一台服务器都能处理任意一个请求，这正是 Web 能水平扩展、扛住海量并发的前提。GET 因此可以被缓存、被重放、被 CDN 复制。这既是性能来源，也是安全边界：带副作用的请求不能走这条便宜的路。REST 把约束说成风格，工程上则是缓存能不能赚钱的问题。
Cookie 后来也成为广告追踪的基础，引发了长达二十年的隐私之争。Safari 与 Firefox 已默认屏蔽第三方 Cookie（跨站追踪）；浏览器还引入 SameSite 属性（Chrome 自 2020 年起把未声明的 cookie 默认按 SameSite=Lax 处理）来限制 cookie 的跨站发送，这也是抵御 CSRF 的一道防线。这里要更正一个流行说法：Chrome 曾计划全面淘汰第三方 Cookie，但 Google 在 2024 年放弃了该计划，2025 年 4 月撤掉了"用户选择"提示，并于 2025 年 10 月终止整个 Privacy Sandbox——截至 2026 年，第三方 Cookie 仍保留在 Chrome 中，没有移除时间表。
代价与争议
开放性与滥用：HTTP 的开放性让任何人都能建网站，也让钓鱼、垃圾邮件、DDoS 无处不在。Web 的成功从未与安全同步。
Web 的中心化：万维网最初的愿景是去中心化的信息网络。但今天，网络流量高度集中在少数平台（Google、Facebook、Amazon、Cloudflare）。Berners-Lee 本人多次表达对这种中心化趋势的担忧，并在 2018 年启动 Solid 项目，试图重建去中心化 Web。Solid 想把个人数据放回用户控制的 pot。愿景仍是 1989 年备忘录里的文档网：链接还在，所有权换手。落地远慢于平台。开放协议不保证开放权力——TCP/IP 和 HTTP 足够开放，广告与登录态仍然可以把流量折进少数域名。去中心化若只改存储位置、不改发现与激励，中心会在别的层长回来。
URL 把"在哪"和"叫什么"焊在一起。页面搬家，旧地址就变成 404 或被重定向改写。数字人文跨域已经点了可引用性的裂口：同一地址在不同时间、对不同人可以返回不同内容。内容寻址（按哈希取文档）能补上这一刀，却还不是 Web 的默认。Berners-Lee 最初要的是可点击的链接，不是永不变的图书馆索书号。成功与缺陷来自同一个设计选择。
Cookie 从 Netscape 的私有约定走到 RFC，中间隔了三年。标准化往往落后于已经铺开的行为。浏览器先造成事实，委员会再追认。HTTP 的许多"标准"都是这种事后照片。理解 Web，要同时读 RFC 和已经占领市场的实现。HTTP 方法的安全与幂等也是这种事后才被说清楚的纪律。浏览器按这张表决定能不能缓存、能不能超时重试；把改数据的动作伪装成 GET，爬虫就会在你不知情时写库。语义不是修辞，是机器要执行的合同。Web 能放大，是因为这份合同足够简单，简单到可以被缓存层、浏览器和爬虫同时遵守。复杂的合同无法被机器执行。
HTTP/2 Server Push 的失败：HTTP/2 引入的服务器推送功能，理论上可以让服务器在客户端请求前推送所需资源。实践中，浏览器实现复杂、收益不明显。Chrome 在 2022 年宣布移除 HTTP/2 Server Push 支持。这是一个"理论上优美，实践中失败"的设计的典型案例。
跨域连接
- API 设计：安全与幂等不是术语洁癖，而是可被第三方依赖的契约：浏览器、代理与内容分发网络据此决定能否缓存、能否在超时后自动重试。这给出一条可检验的后果——把修改数据的操作用只读方法实现，爬虫抓取或浏览器预取就可能在无人操作时改坏后台，而承担代价的是服务提供方而非违约方。
- 负载均衡：无状态是水平扩展的前提，不是缺陷。若服务器必须保留上一请求的上下文，任意请求就不能交给任意实例处理，负载均衡与故障转移同时被绑死。把会话外置到令牌或共享存储，等于把状态从进程内移到请求内，代价是每个请求都要携带并验证凭据——扩展性正是用这份重复开销换来的。
- 平台治理：浏览器是事实上的规制者，默认设置比立法更快地重塑整个广告生态。正文那段反复的第三方 Cookie 政策也暴露了这一安排的问题：做决定的厂商同时是广告收入方。推论是把关键隐私默认值交给单一市场主体，其结果可以由该主体的收入结构相当程度地预测，而非由技术优劣决定。
- 言论自由：全网加密把「能否被大规模被动监听」从政策问题变回技术问题，监听成本因此陡增。但它并不减少审查总量，只是把施加位置从网络中段推向端点与平台。可观察的推论是：加密普及之后，管控手段转向域名解析、应用商店与平台规则，这些环节更集中、更少公开记录，也更难被外部核查。
- 数字人文与大数据史学：网页的可引用性有个结构性缺陷——同一个地址在不同时间、对不同人可能返回不同内容，个性化更让「同一来源」不再唯一。这使引用无法复核，除非补上访问时间与存档快照。推论是内容寻址标识与网页存档不是锦上添花，而是把网络材料纳入可核查证据体系的最低条件。
参考文献
- Berners-Lee, T. Information Management: A Proposal. CERN, 1989. （万维网提案原文）
- CERN. Statement concerning CERN W3 software release into public domain. 30 April 1993.
- Fielding, R. Architectural Styles and the Design of Network-based Software Architectures. PhD dissertation, UC Irvine, 2000. （REST 的出处）
- Ietf. HTTP/1.1. RFC 9110–9112, 2022. （HTTP 的最新统一规范）
- IETF. Hypertext Transfer Protocol -- HTTP/1.0. RFC 1945, 1996. （HTTP/1.0 规范）
- Belshe, M., Peon, R., Thomson, M. Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540, 2015. （HTTP/2，源自 SPDY）
- Bishop, M. (Ed.) HTTP/3. RFC 9114, 2022. （基于 QUIC / RFC 9000）
- Kristol, D., Montulli, L. HTTP State Management Mechanism. RFC 2109, 1997. （Cookie 的首个标准化规范）
延伸阅读
- Grigorik, I. High Performance Browser Networking. O'Reilly, 2013. （免费在线版）