1. HTTP性能工程全景
大家好，我是你们这门课的老朋友。今天咱们正式开篇，聊聊 HTTP 协议。
HTTP，全称是 HyperText Transfer Protocol，超文本传输协议。说白了，它就是客户端（比如你的浏览器）和服务器之间沟通的“通用语言”。你打开网页、刷视频、点外卖，背后都是 HTTP 在干活。
我个人习惯把 HTTP 比作“快递员”。你下单（发起请求），快递员按地址送货（服务器响应），就这么简单。但别小看它，这个“快递员”从诞生到现在，已经迭代了好几代，每一代都解决了上一代的痛点。
1.1 HTTP 的发展历史：从“一句话”到“多路复用”
HTTP 的历史，其实就是一部互联网的进化史。我刚开始接触 Web 开发时，用的还是 HTTP/1.1，那时候觉得它挺完美。直到后来遇到高并发场景，才发现它有多“笨拙”。咱们按时间线捋一捋。
HTTP/0.9：只有“GET”的原始时代
1991 年，HTTP 刚出生。那时候它简单到什么程度？只有一个方法：GET。没有请求头，没有响应头，服务器返回的只能是 HTML 字符串。你想想看，连图片都传不了。
核心特征：
- 仅支持
GET方法 - 无请求头/响应头
- 响应只能是 HTML
- 无状态、无连接（其实那时候也没啥状态可谈）
我记得有次翻老代码，看到一段注释写着“兼容 HTTP/0.9 客户端”，当时还愣了一下。嗯，现在基本见不到了。
HTTP/1.0：可扩展的“浏览器时代”
1996 年，HTTP/1.0 正式发布。它终于有了版本号、状态码、请求头和响应头。你可以传图片、传文件，甚至支持了 POST 和 HEAD 方法。
但有个大问题：每个请求都要新建一个 TCP 连接。你打开一个网页，里面有 10 张图片，浏览器就得建立 10 次 TCP 连接。这在当时网络慢、页面小的时代还能忍，但放到今天，简直不敢想。
我曾经踩过的坑： 早期做移动端页面时，没注意 HTTP/1.0 的短连接特性，结果用户反馈页面加载极慢。后来一查，每次请求都经历三次握手，光握手时间就占了总耗时的一半。从那以后，我养成了检查 Connection: keep-alive 的习惯。
HTTP/1.1：统治互联网二十年的“老大哥”
1997 年，HTTP/1.1 来了。它引入了 持久连接（Keep-Alive），允许在一个 TCP 连接上发送多个请求。还加入了管道化（Pipelining）、分块传输编码、缓存控制等特性。
但管道化有个“坑”：虽然客户端可以连续发请求，但服务器必须按顺序响应。如果第一个请求处理慢了，后面的都得等着——这就是著名的队头阻塞问题。
| 特性 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|
| 连接方式 | 短连接（每次新建） | 持久连接（默认 Keep-Alive） |
| 管道化 | 不支持 | 支持（但有队头阻塞） |
| Host 头 | 可选 | 必选 |
| 缓存控制 | Expires | Cache-Control、ETag 等 |
我个人习惯在面试时问候选人：“HTTP/1.1 的管道化为什么没被广泛使用？” 能答出“队头阻塞”的，基本算入门了。
HTTP/2：多路复用与二进制分帧
2015 年，HTTP/2 发布。它基于 Google 的 SPDY 协议，核心改进是多路复用——一个 TCP 连接可以同时处理多个请求，彻底解决了队头阻塞。
它还引入了二进制分帧层、头部压缩（HPACK）、服务器推送等特性。你想想看，以前 HTTP/1.1 是文本协议，现在变成了二进制协议，解析效率高了一大截。
避坑指南： HTTP/2 虽然解决了应用层的队头阻塞，但 TCP 层的队头阻塞依然存在。如果丢包严重，整个连接都会受影响。这也是 HTTP/3 要解决的问题。
HTTP/3：基于 QUIC 的“未来已来”
2022 年，HTTP/3 正式标准化。它把传输层从 TCP 换成了 QUIC（基于 UDP）。QUIC 内置了加密、多路复用、0-RTT 握手等特性，连接建立时间几乎为零。
我记得去年帮一家直播平台做优化，他们从 HTTP/2 迁移到 HTTP/3 后，首屏加载时间降低了 30%。尤其是在弱网环境下，效果特别明显。
核心演进脉络：
- HTTP/0.9 → 文本、单请求、无头
- HTTP/1.0 → 可扩展、短连接
- HTTP/1.1 → 持久连接、管道化、缓存
- HTTP/2 → 二进制、多路复用、头部压缩
- HTTP/3 → QUIC、0-RTT、无队头阻塞
1.2 HTTP 的核心特点：无状态、无连接、请求-响应模型
聊完历史，咱们看看 HTTP 的“基因”。这三个特点，是理解 HTTP 一切行为的基础。
无状态：服务器不“记得”你
HTTP 是无状态的。意思是，服务器处理完你的请求后，就把你忘了。下次你再发请求，它不认识你。
为什么会这样？因为设计初衷就是简单。服务器不需要保存每个客户端的状态，资源开销小，扩展性好。但这也带来了问题——你怎么实现“登录后保持会话”？
解决方案： 用 Cookie + Session，或者 JWT（JSON Web Token）。服务器通过 Cookie 里的 session_id 来“记住”你是谁。我在项目中经常用 JWT，因为它无状态、跨域友好，适合微服务架构。
无连接：用完就“断”
在 HTTP/1.0 时代，每次请求结束后，TCP 连接就关闭了。这叫“无连接”。好处是服务器资源释放快，但坏处也明显——频繁建立连接太慢了。
HTTP/1.1 引入了持久连接，默认不关闭。但“无连接”这个设计理念依然存在：协议层面不强制维护连接状态。即使连接保持，服务器也不保证“记住”你之前的请求。
我曾经踩过的坑： 早期做长轮询（Long Polling）时，没处理好连接超时，结果服务器连接数暴涨，直接 OOM。后来加了心跳机制和连接池，才算稳住。
基于请求-响应模型：一问一答
HTTP 是典型的“一问一答”模式。客户端发请求，服务器回响应。没有“服务器主动推送”的概念（除非用 WebSocket 或 Server-Sent Events）。
这个模型简单、可靠，但有个局限：实时性差。比如你想实现聊天功能，客户端得不断轮询服务器。后来有了 WebSocket，才解决了这个问题。
请求-响应模型的核心要素：
- 请求： 方法（GET/POST/PUT/DELETE 等）、URL、请求头、请求体
- 响应： 状态码（200/404/500 等）、响应头、响应体
- 交互流程： 客户端发起 → 服务器处理 → 服务器返回 → 客户端解析
1.3 小结：为什么这些概念重要？
你可能会问：“知道这些历史有什么用？” 我告诉你，太有用了。
比如你遇到页面加载慢，如果不懂 HTTP/1.1 的队头阻塞，你可能只会加带宽。如果你懂 HTTP/2 的多路复用，就知道该升级协议。再比如你设计 API，如果不懂无状态，可能会把用户状态存在服务器内存里，导致集群部署时出问题。