Book Notes · 13 / 14 · 中文入门
图解HTTP
精读笔记
上野宣从一次浏览器请求出发，把 HTTP 的报文、方法、状态码、首部、Cookie 与 HTTPS 串成一条清楚的学习路径。本页保留这条入门主线，并补上 HTTP/2、HTTP/3 的时代坐标，适合先建立全景，再按问题回查规范。
全书骨架：一场请求—响应对话
全书可压缩为六个连续问题：Web 如何找到资源、请求怎样表达意图、服务器怎样报告结果、上下文怎样随报文传递、信道怎样获得保护，以及新版协议怎样突破旧传输方式的瓶颈。
HTTP 不限定资源是什么，只用 URI 标识目标；同一套语义可以传文档、图片、接口结果或控制信息。
起始行决定本次对话的方向，首部描述条件与格式，消息体承载具体表示，三者不要混为一谈。
每个请求原则上可独立解释；Cookie 等机制在此基础上补充连续会话，而不是改变 HTTP 的基本模型。
HTTP/2 与 HTTP/3 主要改进传输组织和连接表现，方法、状态码、首部所表达的 HTTP 语义仍可延续。
HTTP 诞生与 Web 基础
HTTP 最初服务于超文本文档的共享，后来成长为 Web 的通用应用层协议。入门时先看清它和 URI、TCP/IP 分层以及客户端—服务器模型的关系。
从超文本到通用资源协议
Web 把分散在不同主机上的资源用超链接连接起来。浏览器作为客户端，根据 URI 指定的位置向服务器索取资源；服务器返回该资源的一种表示。随着用途扩展，HTTP 的对象不再局限于 HTML，接口数据、媒体文件和操作结果都能沿用同一套请求—响应规则。
URI 负责标识，URL 强调位置
日常浏览中常把 URL 当作网址，它通常包含方案、主机、端口、路径、查询等组成部分。理解各部分的职责比死背格式更重要：主机告诉 DNS 要解析谁，端口选择服务进程，路径与查询共同指向服务器要处理的目标。
HTTP 位于分层栈的应用层
应用层定义请求与响应的意义，传输层负责把字节送到对端进程，网络层负责跨网络寻址，链路层负责一跳内交付。传统 HTTP 通常借助 TCP；加上 TLS 后成为 HTTPS。分层让应用无需操心每一跳的物理细节。
报文结构与方法
读报文先找起始行，再看首部，最后判断有没有消息体。方法不是“动作按钮”的随意命名，而是客户端希望服务器按何种语义处理目标资源。
请求与响应的三段结构
请求起始行包含方法、请求目标和协议版本；响应起始行包含协议版本、状态码与原因说明。随后是若干首部字段，空行之后才可能出现消息体。原因说明便于人读，程序决策应以三位状态码为准。
GET /notes HTTP/1.1：方法、目标、版本
请求首部主机、可接受格式、条件、认证等元数据
空行标记首部区域结束
消息体按需承载表单、JSON、文件等表示
常用方法表达不同意图
GET 获取资源表示，HEAD 只取与 GET 对应的首部信息，POST 把表示交给目标处理，PUT 用提交的表示创建或替换目标，DELETE 请求移除目标，OPTIONS 查询通信选项。服务器是否允许某方法仍取决于资源和权限。
安全性、幂等性与缓存性
“安全”表示按定义不应要求服务器改变资源状态，不等于没有日志或计费等附带影响；“幂等”表示同一请求重复多次的预期效果与执行一次相同。它们帮助客户端判断重试风险。能否缓存则还受方法、状态码与缓存首部共同约束。
状态码体系
状态码是服务器对本次请求处理结果的紧凑分类。先看首位数字判断大类，再结合具体代码、方法与首部理解下一步动作。
五大类别是一张导航图
成功与重定向不只一种
200 表示请求成功，但消息体含义仍由方法与表示决定；204 表示成功且没有要返回的内容；206 用于范围请求得到的部分表示。重定向可能是永久或临时，也可能要求客户端使用另一 URI，缓存与后续方法的处理需要结合具体代码。
客户端错误与服务器错误要分责
400 指向请求本身无法正确处理，401 与认证挑战有关，403 表示服务器理解却拒绝处理，404 表示未找到目标资源。500 是服务端内部失败的通用信号，503 多用于暂时无法提供服务。排障时还应检查响应首部和服务日志。
首部字段与 Cookie
首部是报文的控制面：它们描述目标、表示、缓存、条件、认证与连接上下文。Cookie 则在 HTTP 的无状态对话上携带由服务器指定的小段状态标识。
按职责读首部，而非背字段表
请求首部可表达客户端能力与条件，响应首部描述处理结果及后续指示，表示元数据说明内容类型、编码与长度，通用控制信息则可能影响缓存或中间节点。实际报文里这些职责会同时出现，先问“字段在约束谁、描述什么”最有效。
Host 帮助同一地址上的服务区分站点
内容协商Accept 等字段表达客户端偏好的表示形式
表示说明Content-Type 描述消息内容的媒体类型
缓存控制Cache-Control 向缓存参与者传达复用约束
条件请求验证器与条件字段让客户端判断是否需要重新传内容
内容协商与缓存减少无效传输
客户端可以声明偏好的媒体类型、语言与编码，服务器据此选择合适表示。缓存保存可复用响应；到期后不一定要下载完整内容，可以带验证条件询问资源是否变化。新鲜度、验证器与缓存指令共同决定能否直接使用旧副本。
Cookie 把状态带回服务器
服务器通过响应指示客户端保存 Cookie，之后浏览器在符合域、路径与安全条件的请求中带回它。Cookie 常承载会话标识、偏好或实验分组；真正的会话资料通常留在服务器端，避免把敏感业务状态全部交给客户端。
HTTPS 与安全
HTTP 明文传输时，路径上的观察者可能读取或改动内容，也难以确认对端身份。HTTPS 通过 TLS 为 HTTP 建立经过认证并受保护的通信信道。
TLS 解决三类信道问题
机密性降低旁观者读取内容的能力，完整性让篡改更容易被发现，服务器身份认证则把域名与受信任证书链联系起来。三者组合后，浏览器才能较有把握地判断正在与预期站点通信，且报文在途中没有被随意查看或改写。
握手先协商，再保护应用数据
TLS 握手协商协议参数，服务器提交证书材料，双方建立共享密钥，随后使用对称加密保护大量应用数据。非对称密码学适合认证与密钥建立，对称密码学适合高效传输；实际协议把两者放在各自擅长的位置。
证书信任不等于网站绝对安全
浏览器验证证书链、有效期与目标名称，用来判断当前公钥是否与所访问站点匹配。它并不审计网站业务是否诚信，也不能自动消除脚本漏洞、弱口令、终端恶意软件或服务端数据泄露。
时代注记：从 HTTP/1.1 升级到 2 与 3
原书以 HTTP/1.1 时代的观察为主。今天阅读时应把“语义”和“线上编码与传输”分开：新版协议延续多数 HTTP 概念，重点重做连接上的报文组织方式。
HTTP/1.1 的连接利用仍有限制
持久连接避免每次请求都重新建立 TCP，但同一连接上的响应次序仍可能影响后续工作。浏览器曾通过并行连接、合并资源等方式规避等待，却增加了连接数量与工程复杂度。问题的焦点逐渐从“要表达什么”转向“怎样更有效地传”。
HTTP/2 用帧与流复用连接
HTTP/2 把消息切成二进制帧，在一条连接上交错传输多个流，并压缩首部表示。不同请求不必严格按整条消息排队，应用层并发显著改善；但它仍通常运行在 TCP 上，一旦底层丢包，连接中的数据都可能等待 TCP 恢复。
HTTP/3 把 HTTP 映射到 QUIC
HTTP/3 使用基于 UDP 构建的 QUIC。QUIC 在协议内部整合加密、可靠性和多流传输，让一个流的丢包恢复不必阻塞其他独立流，并改善连接建立与网络路径变化时的体验。它不是“去掉可靠性”，而是换了实现可靠传输的位置。