HTTP 与 HTTPS：核心语义、首部、缓存、连接与版本演进
HTTP 规定请求与响应长什么样；HTTPS 在同样语义外包一层 TLS，解决传输上的机密性与完整性。这两篇把「日常接口与抓包够用」的 HTTP 核心，与「1.0→3、何时 TLS」的版本线放在一起。
应用层常见协议一览
应用层直接面向具体业务，下列是日常最常碰见的名字，后面正文重点展开 HTTP/HTTPS：
| 协议 | 做什么 |
|---|---|
| HTTP / HTTPS | 网页与绝大多数 API 的请求/响应语义；HTTPS 在 HTTP 外加 TLS 加密与完整性。 |
| DNS | 把域名解析成 IP（等记录）。 |
| WebSocket | 在 TCP/TLS 上建全双工长连接，常用于实时推送。 |
| FTP / SFTP | 文件传输（传统 FTP 与基于 SSH 的 SFTP 不是一回事，只是同归「传文件」需求）。 |
| SMTP / IMAP / POP3 | 发信、收信、邮箱同步等邮件场景。 |
| SSH | 安全远程登录与隧道。 |
| MQTT | 轻量发布/订阅，常见于物联网与消息中间件。 |
还有很多（如 NTP、SNMP、LDAP 等），用到再查即可。
HTTP 协议是什么
HTTP（Hypertext Transfer Protocol，超文本传输协议）用来约定超文本在网络上的传输方式；这里的超文本不单指文字，而是泛指网页里常见的各类资源与消息。
HTTP 是一个无状态（stateless）协议：服务器不维护任何有关客户端过去所发请求的消息。有状态协议往往更复杂，要持久维护状态（历史信息），而且一旦客户端或服务端失效，还容易出现状态不一致，把不一致修回去的代价通常更高。于是在协议层保持无状态，需要会话时在 HTTP 之上用 Cookie、Session、Token 等机制补齐，是常见做法。
1. 请求、响应与语义
一次 HTTP 交换由请求与响应组成。请求至少包含：方法、目标 URI（含路径与查询串）、协议版本；响应至少包含：状态码、说明短语（可省略语义）、首部与可选正文。
1.1 方法（Method）
| 方法 | 直觉 |
|---|---|
| GET | 获取资源，不应在规范语义上产生副作用；可被缓存、可带查询参数。 |
| POST | 提交数据、触发处理，可能改变服务端状态；通常不缓存响应本体。 |
| PUT / PATCH | 整体或部分替换/更新资源（具体语义依 API 约定）。 |
| DELETE | 删除资源。 |
| HEAD | 与 GET 同，但不要正文，只要头（用于探测存在性、长度等）。 |
| OPTIONS | 探测服务器支持的方法或 CORS 预检。 |
1.2 状态码区间
记百位即可：2xx 成功，3xx 重定向（看 Location），4xx 客户端问题，5xx 服务端问题。
2. HTTP/1.0 与 HTTP/1.1
响应状态码
HTTP/1.1 在规格里补充并细化了一批状态码及使用场景，例如 100 Continue（可先应答再继续发大正文）、409 Conflict（资源冲突）、416 Range Not Satisfiable（请求的字节范围不合法）等。HTTP/1.0 时代很多实现只常用 2xx/3xx/4xx/5xx 的子集，能表达的「细分错误 / 中间状态」较少。
缓存处理
HTTP/1.0 多依赖 Expires、Last-Modified 等，能表达的缓存规则也比较粗。
HTTP/1.1 用 Cache-Control 把策略说细（如 max-age 定「多久内可本地直接用」、no-store「不落盘」、no-cache「用前须向源校验」等）；用 ETag 给内容一个版本指纹，配合 If-None-Match 做协商；If-Modified-Since 仍可与 Last-Modified 搭配。没变时常回 304，少传正文，浏览器与 CDN 都按同一套语义实现。
连接方式
HTTP/1.0 常见实现是短连接：一个请求开一条 TCP、响应结束就关的情况很多；若要复用连接，通常要 Connection: Keep-Alive 且双方支持。
HTTP/1.1 默认持久连接（除非请求或响应里显式 Connection: close），减少反复握手。同一连接上多个请求/响应仍是顺序交付，队头阻塞问题后来由 HTTP/2 的多路复用缓解。
Host 头处理
HTTP/1.0 并无强制要求带 Host；HTTP/1.1 规定请求必须带 Host
用处：
- 历史局限 (HTTP/1.0)
假设：1 个 IP = 1 个网站。 请求：浏览器连接 IP 后只发 GET /index.html。 困境：当一台服务器（单 IP）托管多个域名（a.com, b.com）时，服务器收到请求后无法判断该返回哪个网站的内容。
- 核心突破 (HTTP/1.1)
新规：请求头必须携带 Host 字段。 逻辑：GET /index.html HTTP/1.1 + Host: www.a.com。 结果：服务器通过 Host 字段精准识别目标域名，实现虚拟主机（Virtual Hosting）功能。
带宽优化
HTTP/1.1 支持 Range / Content-Range，便于断点续传、分段下载；支持 Transfer-Encoding: chunked，正文可边生成边传（长度事先不知道时很有用）。大体积上传还可配合 Expect: 100-continue，服务端先返回 100 Continue 再收正文，少传无效数据。HTTP/1.0 对此类能力支持弱，整包 Content-Length 更常见。
3. HTTP 版本线：各自解决什么
HTTP/1.0
一请求一连接居多；无默认持久连接。
HTTP/1.1 默认持久连接、分块传输、更丰富的缓存控制；同一 TCP 上响应仍按序，易队头阻塞。
HTTP/2
- 二进制分帧：不再像 1.1 那样一口气发一段长文本，而是把数据切成一个个带编号的小货柜（帧）。机器读这些规则的小货柜比读长文本要快得多。
- 多路复用：以前一条 TCP 路上只能跑一辆货车，现在可以在同一条路上混着跑。可以同时跑很多个「请求—响应流」（多个 stream）
- HPACK：以前每个包都要贴详细的地址（首部），现在只传变动的部分，重复的地址查表即得。
底层： HTTP/2 解决的是应用层的排队。但底层还是一条单向 TCP 管道。想象一下，如果路上有一个货柜（包）丢了，整条路都要停下来等待这个包补发。哪怕后面的货柜是别的请求的，也得一起等着。这就是「TCP 层的队头阻塞」。
HTTP/3
- QUIC 跑在 UDP 上：既然 TCP 管道出问题会卡死全球，那就换个思路。在 UDP 这种“只管发货”的快递员身上，自己封装一套更聪明的可靠传输协议（QUIC）。
- 流的解耦：在 HTTP/3 里，每一个请求都是一条独立的虚拟车道。A 车道爆胎了（丢包），B 车道依然可以全速前进，不需要停下来等 A。
- 弱网神器：用手机过隧道，信号闪断一下时，HTTP/3 的网页可能只是缺个图，而 HTTP/2 的网页可能整个都在转圈。
