《透视HTTP协议》学习笔记

准备

git clone git@github.com:kibaamor/http_study.git

cd http_study/www

./run.sh start

编辑hosts，添加

127.0.0.1       www.chrono.com
127.0.0.1       www.metroid.net
127.0.0.1       origin.io

浏览器使用 firefox 测试。

HTTP 状态码

RFC 标准把状态码分成了五类：

• 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；

  我们偶尔能够见到的是”101 Switching Protocols”。它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改成其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。

• 2××：成功，报文已经收到并被正确处理；

  “200 OK” 是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非 HEAD 请求，通常在响应头后都会有 body 数据。

  “204 No Content” 是另一个很常见的成功状态码，它的含义与”200 OK”基本相同，但响应头后没有 body 数据。所以对于 Web 服务器来说，正确地区分 200 和 204 是很必要的。

  “206 Partial Content” 是 HTTP 分块下载或断点续传的基础，在客户端发送”范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。

  状态码 206 通常还会伴随着头字段 “Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如 “Content-Range: bytes 0-99/2000”，意思是此次获取的是总计 2000 个字节的前 100 个字节。

• 3××：重定向，资源位置发生变动，需要客户端重新发送请求；

  “301 Moved Permanently”俗称”永久重定向”，含义是此次请求的资源已经不存在了，需要改用改用新的 URI 再次访问。

  与它类似的是”302 Found”，曾经的描述短语是”Moved Temporarily”，俗称”临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。

  “304 Not Modified” 是一个比较有意思的状态码，它用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成”重定向已到缓存的文件”（即”缓存重定向”）。

  301 和 302 还另有两个等价的状态码 “308Permanent Redirect” 和 “307 TemporaryRedirect”，但这两个状态码不允许后续的请求更改请求方法。

• 4××：客户端错误，请求报文有误，服务器无法处理；

  “400 Bad Request”是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误，客户端看到 400 只会是”一头雾水””不知所措”。所以，在开发 Web 应用时应当尽量避免给客户端返回 400，而是要用其他更有明确含义的状态码。

  “403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等，如果服务器友好一点，可以在 body 里详细说明拒绝请求的原因，不过现实中通常都是直接给一个”闭门羹”。

  “404 Not Found”可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端。但现在已经被”用滥了”，只要服务器”不高兴”就可以给出个 404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，某种程度上它比 403 还要令人讨厌。

  4×× 里剩下的一些代码较明确地说明了错误的原因，都很好理解，开发中常用的有：

  • 405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
  • 406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
  • 408 Request Timeout：请求超时，服务器等待了过长的时间；
  • 409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
  • 413 Request Entity Too Large：请求报文里的 body 太大；
  • 414 Request-URI Too Long：请求行里的 URI 太大；
  • 429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略；
  • 431 Request Header Fields Too Large：请求头某个字段或总体太大；

• 5××：服务器错误，服务器在处理请求时内部发生了错误。

  “500 Internal Server Error”与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。不过对于服务器来说这应该算是好事，通常不应该把服务器内部的详细信息，例如出错的函数调用栈告诉外界。虽然不利于调试，但能够防止黑客的窥探或者分析。

  “501 Not Implemented”表示客户端请求的功能还不支持，这个错误码比 500 要”温和”一些，和”即将开业，敬请期待”的意思差不多，不过具体什么时候”开业”就不好说了。

  “502 Bad Gateway”通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。

  “503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的”网络服务正忙，请稍后重试”的提示信息就是状态码 503。

  503 是一个”临时”的状态，很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以 503 响应报文里通常还会有一个”Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。

HTTP 的实体数据

MIME

MIME 用在电子邮件系统里的，让电子邮件可以发送 ASCII 码以外的任意数据，方案的名字叫做”多用途互联网邮件扩展”（Multipurpose Internet Mail Extensions），简称为 MIME。

MIME 是一个很大的标准规范，但 HTTP 只”顺手牵羊”取了其中的一部分，用来标记 body 的数据类型，这就是我们平常总能听到的”MIME type”。

MIME 把数据分成了八大类，每个大类下再细分出多个子类，形式是”type/subtype”的字符串。

Encoding type

HTTP 在传输时为了节约带宽，有时候还会压缩数据，为了不要让浏览器继续”猜”，还需要有一个”Encoding type”，告诉数据是用的什么编码格式，这样对方才能正确解压缩，还原出原始的数据。

常用的只有下面三种：

• gzip：GNU zip 压缩格式，也是互联网上最流行的压缩格式；
• deflate：zlib（deflate）压缩格式，流行程度仅次于 gzip；
• br：一种专门为 HTTP 优化的新压缩算法（Brotli）。

Accept/Content 头

Accept字段标记的是客户端可理解的 MIME type，可以用”,”做分隔符列出多个类型，让服务器有更多的选择余地，例如下面的这个头：

Accept: text/html,application/xml,image/webp,image/png

相应的，服务器会在响应报文里用头字段Content-Type告诉实体数据的真实类型：

Content-Type: text/html

Accept-Encoding/Content-Encoding 头

Accept-Encoding字段标记的是客户端支持的压缩格式，例如上面说的 gzip、deflate 等，同样也可以用”,”列出多个，服务器可以选择其中一种来压缩数据，实际使用的压缩格式放在响应头字段Content-Encoding里。

不过这两个字段是可以省略的，如果请求报文里没有 Accept-Encoding 字段，就表示客户端不支持压缩数据；如果响应报文里没有 Content-Encoding 字段，就表示响应数据没有被压缩。

Accept-Language/Content-Language 头

“语言类型”就是人类使用的自然语言，例如英语、汉语、日语等，而这些自然语言可能还有下属的地区性方言，所以在需要明确区分的时候也要使用”type-subtype”的形式，不过这里的格式与数据类型不同，分隔符不是”/“，而是”-“。

同样的，HTTP 协议也使用 Accept 请求头字段和 Content 实体头字段，用于客户端和服务器就语言与编码进行”内容协商”。

Accept-Language字段标记了客户端可理解的自然语言，也允许用”,”做分隔符列出多个类型，例如：

Accept-Language: zh-CN, zh, en

这个请求头会告诉服务器：”最好给我 zh-CN 的汉语文字，如果没有就用其他的汉语方言，如果还没有就给英文”。

相应的，服务器应该在响应报文里用头字段Content-Language告诉客户端实体数据使用的实际语言类型：

Content-Language: zh-CN

Accept-Charset/Content-Type 头

字符集在 HTTP 里使用的请求头字段是Accept-Charset，但响应头里却没有对应的 Content-Charset，而是在Content-Type字段的数据类型后面用”charset=xxx”来表示，这点需要特别注意。

例如，浏览器请求 GBK 或 UTF-8 的字符集，然后服务器返回的是 UTF-8 编码，就是下面这样：

Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8

不过现在的浏览器都支持多种字符集，通常不会发送 Accept-Charset，而服务器也不会发送 Content-Language，因为使用的语言完全可以由字符集推断出来，所以在请求头里一般只会有 Accept-Language 字段，响应头里只会有 Content-Type 字段。

内容协商的质量值

在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候，还可以用一种特殊的”q”参数表示权重来设定优先级，这里的”q”是”quality factor”的意思。

权重的最大值是 1，最小值是 0.01，默认值是 1，如果值是 0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个”;”，然后是”q=value”。

这里要提醒的是”;”的用法，在大多数编程语言里”;”的断句语气要强于”,”，而在 HTTP 的内容协商里却恰好反了过来，”;”的意义是小于”,”的。

例如下面的 Accept 字段：

Accept: text/html,application/xml;q=0.9,*/*;q=0.8

它表示浏览器最希望使用的是 HTML 文件，权重是 1，其次是 XML 文件，权重是 0.9，最后是任意数据类型，权重是 0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出 HTML 或者 XML。

内容协商的结果

内容协商的过程是不透明的，每个 Web 服务器使用的算法都不一样。但有的时候，服务器会在响应头里多加一个Vary字段，记录服务器在内容协商时参考的请求头字段，给出一点信息，例如：

Vary: Accept-Encoding,User-Agent,Accept

这个 Vary 字段表示服务器依据了 Accept-Encoding、User-Agent 和 Accept 这三个头字段，然后决定了发回的响应报文。

Vary 字段可以认为是响应报文的一个特殊的”版本标记”。每当 Accept 等请求头变化时，Vary 也会随着响应报文一起变化。也就是说，同一个 URI 可能会有多个不同的”版本”，主要用在传输链路中间的代理服务器实现缓存服务。

HTTP传输大文件的方法

压缩 HTML 等文本文件是传输大文件最基本的方法。

分块传输

“化整为零”的思路在 HTTP 协议里就是”chunked”分块传输编码，在响应报文里用头字段”Transfer-Encoding: chunked”来表示，意思是报文里的 body 部分不是一次性发过来的，而是分成了许多的块（chunk）逐个发送。

分块传输可以流式收发数据，节约内存和带宽，使用响应头字段”Transfer-Encoding: chunked”来表示，分块的格式是 16 进制长度头 + 数据块。

“Transfer-Encoding: chunked”和”Content-Length”这两个字段是互斥的，也就是说响应报文里这两个字段不能同时出现，一个响应报文的传输要么是长度已知，要么是长度未知（chunked）。

范围请求

HTTP 协议允许客户端在请求头里使用专用字段来表示只获取文件的一部分，相当于是客户端的”化整为零”。

服务器必须在响应头里使用字段”Accept-Ranges: bytes”明确告知客户端：”我是支持范围请求的”。如果不支持的话该怎么办呢？服务器可以发送”Accept-Ranges: none”，或者干脆不发送”Accept-Ranges”字段。

请求头Range是 HTTP 范围请求的专用字段，格式是”bytes=x-y”，其中的 x 和 y 是以字节为单位的数据范围。

要注意 x、y 表示的是”偏移量”，范围必须从 0 计数，例如前 10 个字节表示为”0-9”，第二个 10 字节表示为”10-19”，而”0-10”实际上是前 11 个字节。

Range 的格式也很灵活，起点 x 和终点 y 可以省略，能够很方便地表示正数或者倒数的范围。假设文件是 100 个字节，那么：

• “0-“表示从文档起点到文档终点，相当于”0-99”，即整个文件；
• “10-“是从第 10 个字节开始到文档末尾，相当于”10-99”；
• “-1”是文档的最后一个字节，相当于”99-99”；
• “-10”是从文档末尾倒数 10 个字节，相当于”90-99”。

服务器收到 Range 字段后，需要做四件事。

第一，它必须检查范围是否合法，比如文件只有 100 个字节，但请求”200-300”，这就是范围越界了。服务器就会返回状态码416，意思是”你的范围请求有误，我无法处理，请再检查一下”。

第二，如果范围正确，服务器就可以根据 Range 头计算偏移量，读取文件的片段了，返回状态码”206 Partial Content”，和 200 的意思差不多，但表示 body 只是原数据的一部分。

第三，服务器要添加一个响应头字段Content-Range，告诉片段的实际偏移量和资源的总大小，格式是”bytes x-y/length”，与 Range 头区别在没有”=”，范围后多了总长度。例如，对于”0-10”的范围请求，值就是”bytes 0-10/100”。

最后剩下的就是发送数据了，直接把片段用 TCP 发给客户端，一个范围请求就算是处理完了。

有了范围请求之后，HTTP 处理大文件就更加轻松了，看视频时可以根据时间点计算出文件的 Range，不用下载整个文件，直接精确获取片段所在的数据内容。

不仅看视频的拖拽进度需要范围请求，常用的下载工具里的多段下载、断点续传也是基于它实现的，要点是：

• 先发个 HEAD，看服务器是否支持范围请求，同时获取文件的大小；
• 开 N 个线程，每个线程使用 Range 字段划分出各自负责下载的片段，发请求传输数据；
• 下载意外中断也不怕，不必重头再来一遍，只要根据上次的下载记录，用 Range 请求剩下的那一部分就可以了。

多段数据

刚才说的范围请求一次只获取一个片段，其实它还支持在 Range 头里使用多个”x-y”，一次性获取多个片段数据。

这种情况需要使用一种特殊的 MIME 类型：”multipart/byteranges”，表示报文的 body 是由多段字节序列组成的，并且还要用一个参数”boundary=xxx”给出段之间的分隔标记。

每一个分段必须以”—boundary”开始（前面加两个”-“），之后要用”Content-Type”和”Content-Range”标记这段数据的类型和所在范围，然后就像普通的响应头一样以回车换行结束，再加上分段数据，最后用一个”- -boundary- -“（前后各有两个”-“）表示所有的分段结束。

例如，请求

GET /16-2 HTTP/1.1
Host: www.chrono.com
Range: bytes=0-9, 20-29

响应

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=00000000001
Content-Length: 189
Connection: keep-alive
Accept-Ranges: bytes

--00000000001
Content-Type: text/plain
Content-Range: bytes 0-9/96

// this is
--00000000001
Content-Type: text/plain
Content-Range: bytes 20-29/96

ext json d
--00000000001--

课外小贴士

1. gzip 的压缩率通常能够超过 60%，而 br 算法是专为 HTML 设计的，压缩效率和性能比 gzip还要好，能够再提高 20%的压缩密度。
2. Nginx 的”gzip on”指令很智能，只会压缩文本数据，不会压缩图片、音频、视频。
3. Transfer-Encoding 字段最常见的值是chunked，但也可以用 gzip、deflate 等，表示传输时使用了压缩编码。注意这与 Content-Encoding 不同，Transfer-Encoding 在传输后会被自动解码还原出原始数据，而 Content-Encoding 则必须由应用自行解码
4. 分块传输在未尾还允许有”拖尾数据”，由响应头字段 Trailer 指定。

HTTP 的连接管理

短连接

客户端发送请求前需要先与服务器建立连接，收到响应报文后会立即关闭连接。

是客户端主动关闭的连接。

连接相关的头字段

客户端可以在请求头里明确地要求使用长连接机制，使用的字段是Connection，值是”keep-alive”。

如果服务器支持长连接，它总会在响应报文里放一个”Connection: keep-alive”字段，告诉客户端服务器是支持长连接的。

长连接也需要在恰当的时间关闭，不能永远保持与服务器的连接，这在客户端或者服务器都可以做到。

在客户端，可以在请求头里加上”Connection: close”字段，告诉服务器：”这次通信后就关闭连接”。服务器看到这个字段，就知道客户端要主动关闭连接，于是在响应报文里也加上这个字段，发送之后就调用 Socket API 关闭 TCP 连接。

服务器端通常不会主动关闭连接，但也可以使用一些策略。拿 Nginx 来举例，它有两种方式：

• 使用”keepalive_timeout”指令，设置长连接的超时时间，如果在一段时间内连接上没有任何数据收发就主动断开连接，避免空闲连接占用系统资源。
• 使用”keepalive_requests”指令，设置长连接上可发送的最大请求次数。比如设置成 1000，那么当 Nginx 在这个连接上处理了 1000 个请求后，也会主动断开连接。

另外，客户端和服务器都可以在报文里附加通用头字段”Keep-Alive: timeout=value”，限定长连接的超时时间。但这个字段的约束力并不强，通信的双方可能并不会遵守，所以不太常见。

性能优化

因为”请求 - 应答”模型不能变，所以”队头阻塞”问题在 HTTP/1.1 里无法解决，只能缓解，有什么办法呢？

这在 HTTP 里就是”并发连接”（concurrent connections），也就是同时对一个域名发起多个长连接，用数量来解决质量的问题。

但这种方式也存在缺陷。如果每个客户端都想自己快，建立很多个连接，用户数×并发数就会是个天文数字。服务器的资源根本就扛不住，或者被服务器认为是恶意攻击，反而会造成”拒绝服务”。

所以，HTTP 协议建议客户端使用并发，但不能”滥用”并发。RFC2616 里明确限制每个客户端最多并发 2 个连接。不过实践证明这个数字实在是太小了，众多浏览器都”无视”标准，把这个上限提高到了 6~8。后来修订的 RFC7230 也就”顺水推舟”，取消了这个”2”的限制。

但”并发连接”所压榨出的性能也跟不上高速发展的互联网无止境的需求，还有什么别的办法吗？

这个就是”域名分片”（domain sharding）技术，还是用数量来解决质量的思路。

HTTP 协议和浏览器不是限制并发连接数量吗？好，那我就多开几个域名，比如 shard1.chrono.com、shard2.chrono.com，而这些域名都指向同一台服务器 www.chrono.com。

课外小贴士

1. 因为 TCP 协议还有” 慢启动 “” 拥塞窗口”等特性，通常新建立的”冷连接”会比打开了一段时间的”热连接”要慢一些，所以长连接比短连接还多了这一层的优势。
2. 在长连接中的一个重要问题是如何正确地区分多个报文的开始和结束，所以最好总使用”Content-Length”头明确响应实体的长度正确标记报文结束。如果是流式传输，body长度不能立即确定，就必须用分块传输编码。
3. 利用 HTTP 的长连接特性对服务器发起大量请求，导致服务器最终耗尽资源”拒绝服务”这就是常说的 DDoS
4. HTTP 的连接管理还有第三种方式 pipeline(管道，或者叫流水线)，它在长连接的基础上又进了一步，可以批量发送请求批量接收响应，但因为存在一些问题，Chrome、Firefox等浏览器都没有实现它，已经被事实上”废弃”了。
5. Connection 字段还有一个取值 “Connection: Upgrade”,配合状态码 101 表示协议升级,例如从 HTTP 切换到 WebSocket.

HTTP的重定向和跳转

重定向的过程

重定向是服务器发起的跳转，要求客户端改用新的 URI 重新发送请求，通常会自动进行，用户是无感知的；

“Location”字段属于响应字段，必须出现在响应报文里。但只有配合 301/302 状态码才有意义，它标记了服务器要求重定向的 URI。

响应头字段 Location 指示了要跳转的 URI，可以用绝对或相对的形式；

重定向状态码

301俗称”永久重定向”（Moved Permanently），意思是原 URI 已经”永久”性地不存在了，今后的所有请求都必须改用新的 URI。

浏览器看到 301，就知道原来的 URI”过时”了，就会做适当的优化。比如历史记录、更新书签，下次可能就会直接用新的 URI 访问，省去了再次跳转的成本。搜索引擎的爬虫看到 301，也会更新索引库，不再使用老的 URI。

302俗称”临时重定向”（”Moved Temporarily”），意思是原 URI 处于”临时维护”状态，新的 URI 是起”顶包”作用的”临时工”。

浏览器或者爬虫看到 302，会认为原来的 URI 仍然有效，但暂时不可用，所以只会执行简单的跳转页面，不记录新的 URI，也不会有其他的多余动作，下次访问还是用原 URI。

301/302 是最常用的重定向状态码，在 3××里剩下的几个还有：

• 303 See Other：类似 302，但要求重定向后的请求改为 GET 方法，访问一个结果页面，避免 POST/PUT 重复操作；
• 307 Temporary Redirect：类似 302，但重定向后请求里的方法和实体不允许变动，含义比 302 更明确；
• 308 Permanent Redirect：类似 307，不允许重定向后的请求变动，但它是 301”永久重定向”的含义。

不过这三个状态码的接受程度较低，有的浏览器和服务器可能不支持，开发时应当慎重，测试确认浏览器的实际效果后才能使用。

HTTP 协议特别规定，浏览器必须具有检测”循环跳转”的能力，在发现这种情况时应当停止发送请求并给出错误提示。

重定向的相关问题

HTTP 协议特别规定，浏览器必须具有检测”循环跳转”的能力，在发现这种情况时应当停止发送请求并给出错误提示。

课外小贴士

1. 网页的”入链接”和”出链接”也是标记网页重要性的关键指标，最著名的就是 Google 发明的 PageRank。
2. “300 Multiple Choices”也是一个特殊的重定向状态码，它会返回一个有多个链接选项的页面，由用户自行选择要跳转的链接，用的较少
3. 重定向报文里还可以用 Refresh 字段，实现延时重定向，例如”Refresh: 5;url=xxx”告诉浏览器 5 秒钟后再跳转。
4. 与跳转有关的还有一个”Referer”和(注意前者是个拼写错误”Referrer-Policy”但已经”将错就错”)，表示浏览器跳转的来源(即引用地址)，可用于统计分析和防盗链。

HTTP的Cookie机制

Cookie 是服务器委托浏览器存储的一些数据，让服务器有了”记忆能力”。

Cookie 的工作过程

Cookie 是由浏览器负责存储的，而不是操作系统。所以，它是”浏览器绑定”的，只能在本浏览器内生效。

服务器有时会在响应头里添加多个 Set-Cookie，存储多个”key=value”。但浏览器这边发送时不需要用多个 Cookie 字段，只要在一行里用”;”隔开就行。

Cookie 的属性

有效期

Cookie 的有效期可以使用 Expires 和 Max-Age 两个属性来设置。

“Expires”俗称”过期时间”，用的是绝对时间点，可以理解为”截止日期”（deadline）。”Max-Age”用的是相对时间，单位是秒，浏览器用 收到报文的时间点 再加上 Max-Age，就可以得到失效的绝对时间。

Expires 和 Max-Age 可以同时出现，两者的失效时间可以一致，也可以不一致，但浏览器会优先采用 Max-Age 计算失效期。

作用域

设置 Cookie 的作用域，让浏览器仅发送给特定的服务器和 URI，避免被其他网站盗用。

作用域的设置比较简单，”Domain”和”Path”指定了 Cookie 所属的域名和路径，浏览器在发送 Cookie 前会从 URI 中提取出 host 和 path 部分，对比 Cookie 的属性。如果不满足条件，就不会在请求头里发送 Cookie。

不过现实中为了省事，通常 Path 就用一个”/“或者直接省略，表示域名下的任意路径都允许使用 Cookie，让服务器自己去挑。

安全性

写过前端的同学一定知道，在 JS 脚本里可以用 document.cookie 来读写 Cookie 数据，这就带来了安全隐患，有可能会导致”跨站脚本”（XSS）攻击窃取数据。

属性”HttpOnly”会告诉浏览器，此 Cookie 只能通过浏览器 HTTP 协议传输，禁止其他方式访问，浏览器的 JS 引擎就会禁用 document.cookie 等一切相关的 API，脚本攻击也就无从谈起了。

另一个属性”SameSite”可以防范”跨站请求伪造”（XSRF）攻击，设置成”SameSite=Strict”可以严格限定 Cookie 不能随着跳转链接跨站发送，而”SameSite=Lax”则略宽松一点，允许 GET/HEAD 等安全方法，但禁止 POST 跨站发送。

还有一个属性叫”Secure”，表示这个 Cookie 仅能用 HTTPS 协议加密传输，明文的 HTTP 协议会禁止发送。但 Cookie 本身不是加密的，浏览器里还是以明文的形式存在。

Cookie 的应用

Cookie 最基本的一个用途就是身份识别，保存用户的登录信息，实现会话事务。

Cookie 的另一个常见用途是广告跟踪。

你上网的时候肯定看过很多的广告图片，这些图片背后都是广告商网站（例如 Google），它会”偷偷地”给你贴上 Cookie 小纸条，这样你上其他的网站，别的广告就能用 Cookie 读出你的身份，然后做行为分析，再推给你广告。

这种 Cookie 不是由访问的主站存储的，所以又叫”第三方 Cookie”（third-party cookie）。如果广告商势力很大，广告到处都是，那么就比较”恐怖”了，无论你走到哪里它都会通过 Cookie 认出你来，实现广告”精准打击”。

为了防止滥用 Cookie 搜集用户隐私，互联网组织相继提出了 DNT（Do Not Track）和 P3P（Platform for Privacy Preferences Project），但实际作用不大。

小结

因为 Cookie 并不属于 HTTP 标准（RFC6265，而不是 RFC2616/7230），所以语法上与其他字段不太一致，使用的分隔符是”;”，与 Accept 等字段的”,”不同，小心不要弄错了。

课外小贴士

1. 如果Cookie的Max-Age属性设置为0，它的效果是立即删除该Cookie。
2. 如果不指定 Expires 或 Max-Age 属性，那么Cookie 仅在浏览器运行时有效，一旦浏览器关闭就会失效，这被称为会话 Cookie(sessioncookie)或内存 Cookie(in-memory cookie)在 Chrome 里过期时间会显示为”Session”或”N/A” 。

HTTP的缓存控制

【第1398期】一文读懂前端缓存

17 | 客户端缓存是如何帮助服务器分担流量的？

服务器的缓存控制

服务器标记资源有效期使用的头字段是”Cache-Control”，里面的值”max-age=30”就是资源的有效时间，相当于告诉浏览器，”这个页面只能缓存 30 秒，之后就算是过期，不能用。”

“Cache-Control”字段里的”max-age”和上一讲里 Cookie 有点像，都是标记资源的有效期。

但我必须提醒你注意，这里的 max-age 是”生存时间”（又叫”新鲜度””缓存寿命”，类似 TTL，Time-To-Live），时间的计算起点是响应报文的创建时刻（即 Date 字段，也就是离开服务器的时刻），而不是客户端收到报文的时刻，也就是说包含了在链路传输过程中所有节点所停留的时间。

Cookie 里的max-age是从客户端收到响应开始算。

“max-age”是 HTTP 缓存控制最常用的属性，此外在响应报文里还可以用其他的属性来更精确地指示浏览器应该如何使用缓存：

• no_store：不允许缓存，用于某些变化非常频繁的数据，例如秒杀页面；
• no_cache：它的字面含义容易与 no_store 搞混，实际的意思并不是不允许缓存，而是可以缓存，但在使用之前必须要去服务器验证是否过期，是否有最新的版本；
• must-revalidate：又是一个和 no_cache 相似的词，它的意思是如果缓存不过期就可以继续使用，但过期了如果还想用就必须去服务器验证。

听的有点糊涂吧。没关系，我拿生鲜速递来举例说明一下：

• no_store：买来的西瓜不允许放进冰箱，要么立刻吃，要么立刻扔掉；
• no_cache：可以放进冰箱，但吃之前必须问超市有没有更新鲜的，有就吃超市里的；
• must-revalidate：可以放进冰箱，保鲜期内可以吃，过期了就要问超市让不让吃。

服务器的缓存控制策略画了一个流程图，对照着它你就可以在今后的后台开发里明确”Cache-Control”的用法了。

客户端的缓存控制

不止服务器可以发”Cache-Control”头，浏览器也可以发”Cache-Control”，也就是说请求 - 应答的双方都可以用这个字段进行缓存控制，互相协商缓存的使用策略。

当你点”刷新”按钮的时候，浏览器会在请求头里加一个”Cache-Control: max-age=0”。因为 max-age 是”生存时间”，max-age=0 的意思就是”我要一个最最新鲜的西瓜”，而本地缓存里的数据至少保存了几秒钟，所以浏览器就不会使用缓存，而是向服务器发请求。服务器看到 max-age=0，也就会用一个最新生成的报文回应浏览器。

Ctrl+F5 的”强制刷新”又是什么样的呢？

它其实是发了一个”Cache-Control: no-cache”，含义和”max-age=0”基本一样，就看后台的服务器怎么理解，通常两者的效果是相同的。

那么，浏览器的缓存究竟什么时候才能生效呢？

别着急，试着点一下浏览器的”前进””后退”按钮，再看开发者工具，你就会惊喜地发现”from disk cache”的字样，意思是没有发送网络请求，而是读取的磁盘上的缓存。

另外，如果用重定向跳转功能，也可以发现浏览器使用了缓存。

其实也很简单，在”前进””后退””跳转”这些重定向动作中浏览器不会”夹带私货”，只用最基本的请求头，没有”Cache-Control”，所以就会检查缓存，直接利用之前的资源，不再进行网络通信。

条件请求

浏览器用”Cache-Control”做缓存控制只能是刷新数据，不能很好地利用缓存数据，又因为缓存会失效，使用前还必须要去服务器验证是否是最新版。

条件请求一共有 5 个头字段，我们最常用的是”if-Modified-Since”和”If-None-Match”这两个。需要第一次的响应报文预先提供”Last-modified”和”ETag”，然后第二次请求时就可以带上缓存里的原值，验证资源是否是最新的。

如果资源没有变，服务器就回应一个”304 Not Modified”，表示缓存依然有效，浏览器就可以更新一下有效期，然后放心大胆地使用缓存了。

“Last-modified”很好理解，就是文件的最后修改时间。ETag 是什么呢？

ETag 是”实体标签”（Entity Tag）的缩写，是资源的一个唯一标识，主要是用来解决修改时间无法准确区分文件变化的问题。

比如，一个文件在一秒内修改了多次，但因为修改时间是秒级，所以这一秒内的新版本无法区分。

再比如，一个文件定期更新，但有时会是同样的内容，实际上没有变化，用修改时间就会误以为发生了变化，传送给浏览器就会浪费带宽。

使用 ETag 就可以精确地识别资源的变动情况，让浏览器能够更有效地利用缓存。

ETag 还有”强””弱”之分。

强 ETag 要求资源在字节级别必须完全相符，弱 ETag 在值前有个”W/“标记，只要求资源在语义上没有变化，但内部可能会有部分发生了改变（例如 HTML 里的标签顺序调整，或者多了几个空格）。

条件请求里其他的三个头字段是”If-Unmodified-Since””If-Match”和”If-Range”，其实只要你掌握了”if-Modified-Since”和”If-None-Match”，可以轻易地”举一反三”。

课外小贴士

1. “no-cache”属性可以理解为*max-age=0,must-revalidate
2. 除了”Cache-Control”,服务器也可以用”Expires”字段来标记资源的有效期，它的形式和 Cookie 的差不多，同样属于”过时”的属性，优先级低于”Cache-Control”。还有一个历史遗留字段”Pragma: no-cache”，它相当于”Cache-Control: no-cache”，除非为了兼容 HTTP/1.0 否则不建议使用。
3. 如果响应报文里提供了”Last-modifed”，但浏览器没有”Cache-Control”或”Expires”，会使用”启发”(Heuristic)算法计算一个缓存时间，在 RFC 里的建议是:(Date -Last-modifed)*10%,
4. 每个Web 服务器对 ETag 的计算方法都不一样只要保证数据变化后值不一样就好，但复杂的计算会增加服务器的负担。Nginx的算法是”修改时间+长度”，实际上和 Last-modifed 基本等价。

HTTP的代理服务

代理相关头字段

代理服务器需要用字段”Via”标明代理的身份。

Via 是一个通用字段，请求头或响应头里都可以出现。每当报文经过一个代理节点，代理服务器就会把自身的信息追加到字段的末尾，就像是经手人盖了一个章。

“X-Forwarded-For”的字面意思是”为谁而转发”，形式上和”Via”差不多，也是每经过一个代理节点就会在字段里追加一个信息。但”Via”追加的是代理主机名（或者域名），而”X-Forwarded-For”追加的是请求方的 IP 地址。所以，在字段里最左边的 IP 地址就客户端的地址。

“X-Real-IP”是另一种获取客户端真实 IP 的手段，它的作用很简单，就是记录客户端 IP 地址，没有中间的代理信息，相当于是”X-Forwarded-For”的简化版。如果客户端和源服务器之间只有一个代理，那么这两个字段的值就是相同的。

代理协议

有了”X-Forwarded-For”等头字段，源服务器就可以拿到准确的客户端信息了。但对于代理服务器来说它并不是一个最佳的解决方案。

因为通过”X-Forwarded-For”操作代理信息必须要解析 HTTP 报文头，这对于代理来说成本比较高，原本只需要简单地转发消息就好，而现在却必须要费力解析数据再修改数据，会降低代理的转发性能。

另一个问题是”X-Forwarded-For”等头必须要修改原始报文，而有些情况下是不允许甚至不可能的（比如使用 HTTPS 通信被加密）。

所以就出现了一个专门的”代理协议”（The PROXY protocol），它由知名的代理软件 HAProxy 所定义，也是一个”事实标准”，被广泛采用（注意并不是 RFC）。

“代理协议”有 v1 和 v2 两个版本，v1 和 HTTP 差不多，也是明文，而 v2 是二进制格式。今天只介绍比较好理解的 v1，它在 HTTP 报文前增加了一行 ASCII 码文本，相当于又多了一个头。

这一行文本其实非常简单，开头必须是”PROXY”五个大写字母，然后是”TCP4”或者”TCP6”，表示客户端的 IP 地址类型，再后面是请求方地址、应答方地址、请求方端口号、应答方端口号，最后用一个回车换行（\r\n）结束。

例如下面的这个例子，在 GET 请求行前多出了 PROXY 信息行，客户端的真实 IP 地址是”1.1.1.1”，端口号是 55555。

PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n
GET / HTTP/1.1\r\n
Host: www.xxx.com\r\n
\r\n

服务器看到这样的报文，只要解析第一行就可以拿到客户端地址，不需要再去理会后面的 HTTP 数据，省了很多事情。

课外小贴士

1. “Via”是 HTTP 协议里规定的标准头字段，但有的服务器返回的响应报文里会使用”x-Via”含义是相同的。
2. 因为 HTTP 是明文传输，请求头很容易被窜改所以”X-Forwarded-For”也不是完全可信的。
3. RFC7239 定义了字段”Forwarded”，它可以代替”X-Forwarded-For””X-Forwarded-Host”等字段，但应用得不多

HTTP的缓存代理

源服务器的缓存控制

之前介绍的服务器端的”Cache-Control”属性：max-age、no_store、no_cache 和 must-revalidate，你应该还有印象吧？

这 4 种缓存属性可以约束客户端，也可以约束代理。

但客户端和代理是不一样的，客户端的缓存只是用户自己使用，而代理的缓存可能会为非常多的客户端提供服务。所以，需要对它的缓存再多一些限制条件。

首先，我们要区分客户端上的缓存和代理上的缓存，可以使用两个新属性”private”和”public”。

“private”表示缓存只能在客户端保存，是用户”私有”的，不能放在代理上与别人共享。而”public”的意思就是缓存完全开放，谁都可以存，谁都可以用。

比如你登录论坛，返回的响应报文里用”Set-Cookie”添加了论坛 ID，这就属于私人数据，不能存在代理上。不然，别人访问代理获取了被缓存的响应就麻烦了。

其次，缓存失效后的重新验证也要区分开（即使用条件请求”Last-modified”和”ETag”），”must-revalidate”是只要过期就必须回源服务器验证，而新的”proxy-revalidate”只要求代理的缓存过期后必须验证，客户端不必回源，只验证到代理这个环节就行了。

再次，缓存的生存时间可以使用新的”s-maxage”（s 是 share 的意思，注意 maxage 中间没有”-“），只限定在代理上能够存多久，而客户端仍然使用”max_age”。

还有一个代理专用的属性”no-transform”。代理有时候会对缓存下来的数据做一些优化，比如把图片生成 png、webp 等几种格式，方便今后的请求处理，而”no-transform”就会禁止这样做，不许”偷偷摸摸搞小动作”。

客户端的缓存控制

max-age、no_store、no_cache 这三个属性在[第 20 讲]已经介绍过了，它们也是同样作用于代理和源服务器。

关于缓存的生存时间，多了两个新属性”max-stale”和”min-fresh”。

“max-stale”的意思是如果代理上的缓存过期了也可以接受，但不能过期太多，超过 x 秒也会不要。”min-fresh”的意思是缓存必须有效，而且必须在 x 秒后依然有效。

比如，草莓上贴着标签”max-age=5”，现在已经在冰柜里存了 7 天。如果有请求”max-stale=2”，意思是过期两天也能接受，所以刚好能卖出去。

但要是”min-fresh=1”，这是绝对不允许过期的，就不会买走。这时如果有另外一个菠萝是”max-age=10”，那么”7+1<10”，在一天之后还是新鲜的，所以就能卖出去。

有的时候客户端还会发出一个特别的”only-if-cached”属性，表示只接受代理缓存的数据，不接受源服务器的响应。如果代理上没有缓存或者缓存过期，就应该给客户端返回一个 504（Gateway Timeout）。

其他问题

缓存代理的知识就快讲完了，下面再简单说两个相关的问题。

第一个是”Vary”字段，在[第 15 讲]曾经说过，它是内容协商的结果，相当于报文的一个版本标记。

同一个请求，经过内容协商后可能会有不同的字符集、编码、浏览器等版本。比如，”Vary: Accept-Encoding””Vary: User-Agent”，缓存代理必须要存储这些不同的版本。

当再收到相同的请求时，代理就读取缓存里的”Vary”，对比请求头里相应的” Accept-Encoding””User-Agent”等字段，如果和上一个请求的完全匹配，比如都是”gzip””Chrome”，就表示版本一致，可以返回缓存的数据。

另一个问题是”Purge”，也就是”缓存清理”，它对于代理也是非常重要的功能，例如：

• 过期的数据应该及时淘汰，避免占用空间；
• 源站的资源有更新，需要删除旧版本，主动换成最新版（即刷新）；
• 有时候会缓存了一些本不该存储的信息，例如网络谣言或者危险链接，必须尽快把它们删除。

清理缓存的方法有很多，比较常用的一种做法是使用自定义请求方法”PURGE”，发给代理服务器，要求删除 URI 对应的缓存数据。

课后小贴士

1. 有的缓存代理在”Cache Hit”的时候会在响应报文里加一个 Age 头字段，表示报文的生存时间，即已经在缓存里存了多久，通常它会小于”Cache-Control”里的 max-age 值，如果大于就意味着数据是”陈日的”(stale)。
2. 判断缓存是否命中(Hit)类似于查询 hash 表使用的 key 通常就是 URI，在 Nginx 里可以用指令”proxy_cache_key”自定义。
3. Nginx 对 Vary 的处理实际上是做了 MD5，把Vary 头摘要后写入缓存，请求时不仅比较URI，也比较摘要。

SSLTLS

SSL

SSL 即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层），由网景公司于 1994 年发明，有 v2 和 v3 两个版本，而 v1 因为有严重的缺陷从未公开过。

SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。

到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和去年（2018）的 1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。

目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1⁄1.0、SSLv3/v2）都已经被认为是不安全的，各大浏览器即将在 2020 年左右停止支持，所以接下来的讲解都针对的是 TLS1.2。

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为”密码套件”（cipher suite，也叫加密套件）。

你可以访问实验环境的 URI”/23-1”，对 TLS 和密码套件有个感性的认识。

你可以看到，实验环境使用的 TLS 是 1.2，客户端和服务器都支持非常多的密码套件，而最后协商选定的是”ECDHE-RSA-AES256-GCM-SHA384”。

这么长的名字看着有点晕吧，不用怕，其实 TLS 的密码套件命名非常规范，格式很固定。基本的形式是”密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”，比如刚才的密码套件的意思就是：

“握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。”

OpenSSL

说到 TLS，就不能不谈到 OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。

OpenSSL 是从另一个开源库 SSLeay 发展出来的，曾经考虑命名为”OpenTLS”，但当时（1998 年）TLS 还未正式确立，而 SSL 早已广为人知，所以最终使用了”OpenSSL”的名字。

OpenSSL 目前有三个主要的分支，1.0.2 和 1.1.0 都将在今年（2019）年底不再维护，最新的长期支持版本是 1.1.1，我们的实验环境使用的 OpenSSL 是”1.1.0j”。

由于 OpenSSL 是开源的，所以它还有一些代码分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL，这些分支在 OpenSSL 的基础上删除了一些老旧代码，也增加了一些新特性，虽然背后有”大金主”，但离取代 OpenSSL 还差得很远。

课外小贴士

1. 一个有趣的事实，当前所有 TLS 的 RFC 文档末尾数字都是”46”(2246、4346、5246.8846)
2. 除了 HTTP，SSL/TLS 也可以承载其他的应用协议，例如 FTP=>FTPS，LDAP=>LDAPS 等
3. OpenSSL前身”SSLeay”的名字来源于其作者之-“Eric A. Young”
4. 关于 OpenSSL 有一个著名的”心脏出血(Heart Bleed)”漏洞，出现在 1.0.1 版里。
5. OpenSSL 里的密码套件定义与 TLS 略有不同TLS 里的形式是”TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”，加了前缀”TLS”，并用”WITH”分开了握手和通信的算法。
6. 另一个比较著名的开源密码库是 NSS(Network Security Services),由Mozilla 开发。
7. 比特币、以太坊等区块链技术里也用到了ECC，它们选择的曲线是 secp 256k1。
8. 由于密码学界普遍不信任 NIST 和 NSA，怀疑 secp 系列曲线有潜在的弱点，所以研究出了 “x25519”，它的名字来源于曲线方程里的参数”2^255 - 19”。另有一个更高强度的曲线”x448”，参数是”2^448-2^224-1”。
9. 在 Linux 上可以使用 OpenSSL 的命令行工具来测试算法的加解密速度，例如”openssspeed aes”，”openssl speed rsa2048”等
10. TLS1.2 要求必须实现 TLS RSA WITH AES128 CBC SHA，TLS1.3 要求必须实现 TLSAES 128 GCM SHA256，并且因为前向安全的原因废除了 DH 和 RSA 密钥交换算法。
11. SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。
12. 虽然 SHA-2 很安全，但出于”未雨绸缪”的考虑，又出现了 SHA-3，它也有6种算法，名字与 SHA-2 差不多，比如 SHA3-224、SHA3-256，目前还未纳入 TLS。

TLS1.2连接过程解析

TLS 协议的组成

TLS 包含几个子协议，你也可以理解为它是由几个不同职责的模块组成，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。

• 记录协议（Record Protocol）规定了 TLS 收发数据的基本单位：记录（record）。它有点像是 TCP 里的 segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出，也并不需要像 TCP 那样返回 ACK。

• 警报协议（Alert Protocol）的职责是向对方发出警报信息，有点像是 HTTP 协议里的状态码。比如，protocol_version 就是不支持旧版本，bad_certificate 就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。

• 握手协议（Handshake Protocol）是 TLS 里最复杂的子协议，要比 TCP 的 SYN/ACK 复杂的多，浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。

• 最后一个是变更密码规范协议（Change Cipher Spec Protocol），它非常简单，就是一个”通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。

下面的这张图简要地描述了 TLS 的握手过程，其中每一个”框”都是一个记录，多个记录组合成一个 TCP 包发送。所以，最多经过两次消息往返（4 个消息）就可以完成握手，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

抓包的准备工作

新增一个系统变量”SSLKEYLOGFILE”，设置浏览器日志文件的路径。

后在 Wireshark 里设置”Protocols-TLS”（较早版本的 Wireshark 里是”SSL”），在”(Pre)-Master-Secret log filename”里填上刚才的日志文件。

ECDHE 握手过程

访问 https://www.chrono.com/26-1

TCP 建立连接之后，浏览器会首先发一个”Client Hello”消息，也就是跟服务器”打招呼”。里面有客户端的版本号、支持的密码套件，还有一个随机数（Client Random），用于后续生成会话密钥。

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Random: 1cbf803321fd2623408dfe…
    Cipher Suites (17 suites)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

服务器收到”Client Hello”后，会返回一个”Server Hello”消息。把版本号对一下，也给出一个随机数（Server Random），然后从客户端的列表里选一个作为本次通信使用的密码套件，在这里它选择了”TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”。

Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Random: 0e6320f21bae50842e96…
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

然后，服务器为了证明自己的身份，就把证书也发给了客户端（Server Certificate）。

因为服务器选择了 ECDHE 算法，所以它会在证书后发送”Server Key Exchange”消息，里面是椭圆曲线的公钥（Server Params），用来实现密钥交换算法，再加上自己的私钥签名认证。

Handshake Protocol: Server Key Exchange
    EC Diffie-Hellman Server Params
        Curve Type: named_curve (0x03)
        Named Curve: x25519 (0x001d)
        Pubkey: 3b39deaf00217894e...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature: 37141adac38ea4...

之后是”Server Hello Done”消息，服务器说：”我的信息就是这些，打招呼完毕。”

这样第一个消息往返就结束了（两个 TCP 包），结果是客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params。

客户端在验证了服务器的证书后，客户端按照密码套件的要求，也生成一个椭圆曲线的公钥（Client Params），用”Client Key Exchange”消息发给服务器。

Handshake Protocol: Client Key Exchange
    EC Diffie-Hellman Client Params
        Pubkey: 8c674d0e08dc27b5eaa…

现在客户端和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params），就用 ECDHE 算法一阵算，算出了一个新的东西，叫”Pre-Master”，其实也是一个随机数。

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)

至于具体的计算原理和过程，因为太复杂就不细说了，但算法可以保证即使黑客截获了之前的参数，也是绝对算不出这个随机数的。

现在客户端和服务器手里有了三个随机数：Client Random、Server Random 和 Pre-Master。用这三个作为原始材料，就可以生成用于加密会 话的主密钥，叫”Master Secret”。而黑客因为拿不到”Pre-Master”，所以也就得不到主密钥。

主密钥有 48 字节，但它也不是最终用于通信的会话密钥，还会再用 PRF 扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。

有了主密钥和派生的会话密钥，握手就快结束了。客户端发一个”Change Cipher Spec”，然后再发一个”Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。

意思就是告诉服务器：”后面都改用对称算法加密通信了啊，用的就是打招呼时说的 AES，加密对不对还得你测一下。”

服务器也是同样的操作，发”Change Cipher Spec”和”Finished”消息，双方都验证加密解密 OK，握手正式结束，后面就收发被加密的 HTTP 请求和响应了。

RSA 握手过程

整个握手过程可真是够复杂的，但你可能会问了，好像这个过程和其他地方看到的不一样呢？

刚才说的其实是如今主流的 TLS 握手过程，这与传统的握手有两点不同。

第一个，使用 ECDHE 实现密钥交换，而不是 RSA，所以会在服务器端发出”Server Key Exchange”消息。

第二个，因为使用了 ECDHE，客户端可以不用等到服务器发回”Finished”确认握手完毕，立即就发出 HTTP 报文，省去了一个消息往返的时间浪费。这个叫”TLS False Start”，意思就是”抢跑”，和”TCP Fast Open”有点像，都是不等连接完全建立就提前发应用数据，提高传输的效率。

实验环境在 440 端口 https://www.chrono.com:440/26-1 实现了传统的 RSA 密钥交换，没有”False Start”

大体的流程没有变，只是”Pre-Master”不再需要用算法生成，而是客户端直接生成随机数，然后用服务器的公钥加密，通过”Client Key Exchange”消息发给服务器。服务器再用私钥解密，这样双方也实现了共享三个随机数，就可以生成主密钥。

双向认证

双向认证的流程也没有太多变化，只是在”Server Hello Done”之后，”Client Key Exchange”之前，客户端要发送”Client Certificate”消息，服务器收到后也把证书链走一遍，验证客户端的身份。

课外小贴士

1. TLS 中记录协议原本定义有压缩方式，但后来发现存在安全漏洞(CRIME 攻击)，所以现在这个字段总是 NULL，即不压缩。
2. 在 TLS1.2 里，客户端和随机数的长度都是 28字节，前面的四个字节是 UNIX 时间戳，但并没有实际意义。
3. Chrome 开发者工具的”Security”面板里可以看到 HTTPS 握手时选择的版本号、密码套件和椭圆曲线，例如”ECDHE RSA withX25519,and AES 256 GCM”
4. ECDHE 即”短暂-椭圆曲线-迪菲-赫尔曼(ephemeral Elliptic Curve Diffie-Hellman)”算法，使用椭圆曲线增强了 DH 算法的安全性和性能，公钥和私钥都是临时生成的。
5. 在 Wireshark 抓包里你还会看见”Session ID”，”Extension”等字段，涉及会话复用和扩展协议，后面会讲到。

TLS1.3特性解析

最大化兼容性

由于 1.1、1.2 等协议已经出现了很多年，很多应用软件、中间代理（官方称为”MiddleBox”）只认老的记录协议格式，更新改造很困难，甚至是不可行（设备僵化）。

在早期的试验中发现，一旦变更了记录头字段里的版本号，也就是由 0x303（TLS1.2）改为 0x304（TLS1.3）的话，大量的代理服务器、网关都无法正确处理，最终导致 TLS 握手失败。

为了保证这些被广泛部署的”老设备”能够继续使用，避免新协议带来的”冲击”，TLS1.3 不得不做出妥协，保持现有的记录格式不变，通过”伪装”来实现兼容，使得 TLS1.3 看上去”像是”TLS1.2。

那么，该怎么区分 1.2 和 1.3 呢？

这要用到一个新的扩展协议（Extension Protocol），它有点”补充条款”的意思，通过在记录末尾添加一系列的”扩展字段”来增加新的功能，老版本的 TLS 不认识它可以直接忽略，这就实现了”后向兼容”。

在记录头的 Version 字段被兼容性”固定”的情况下，只要是 TLS1.3 协议，握手的”Hello”消息后面就必须有”supported_versions”扩展，它标记了 TLS 的版本号，使用它就能区分新旧协议。

其实上一讲 Chrome 在握手时发的就是 TLS1.3 协议，你可以看一下”Client Hello”消息后面的扩展，只是因为服务器不支持 1.3，所以就”后向兼容”降级成了 1.2。

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Extension: supported_versions (len=11)
        Supported Version: TLS 1.3 (0x0304)
        Supported Version: TLS 1.2 (0x0303)

TLS1.3 利用扩展实现了许多重要的功能，比如”supported_groups””key_share””signature_algorithms””server_name”等。

强化安全

TLS1.2 在十来年的应用中获得了许多宝贵的经验，陆续发现了很多的漏洞和加密算法的弱点，所以 TLS1.3 就在协议里修补了这些不安全因素。

比如：

• 伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；
• 明确禁止在记录协议里使用压缩；
• 废除了 RC4、DES 对称加密算法；
• 废除了 ECB、CBC 等传统分组模式；
• 废除了 MD5、SHA1、SHA-224 摘要算法；
• 废除了 RSA、DH 密钥交换算法和许多命名曲线。

经过这一番”减肥瘦身”之后，TLS1.3 里只保留了 AES、ChaCha20 对称加密算法，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法只能用 SHA256、SHA384，密钥交换算法只有 ECDHE 和 DHE，椭圆曲线也被”砍”到只剩 P-256 和 x25519 等 5 种。

减肥可以让人变得更轻巧灵活，TLS 也是这样。

算法精简后带来了一个意料之中的好处：原来众多的算法、参数组合导致密码套件非常复杂，难以选择，而现在的 TLS1.3 里只有 5 个套件，无论是客户端还是服务器都不会再犯”选择困难症”了。

这里还要特别说一下废除 RSA 和 DH 密钥交换算法的原因。

上一讲用 Wireshark 抓包时你一定看到了，浏览器默认会使用 ECDHE 而不是 RSA 做密钥交换，这是因为它不具有”前向安全”（Forward Secrecy）。

假设有这么一个很有耐心的黑客，一直在长期收集混合加密系统收发的所有报文。如果加密系统使用服务器证书里的 RSA 做密钥交换，一旦私钥泄露或被破解（使用社会工程学或者巨型计算机），那么黑客就能够使用私钥解密出之前所有报文的”Pre-Master”，再算出会话密钥，破解所有密文。

这就是所谓的”今日截获，明日破解”。

而 ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是”一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。

所以现在主流的服务器和浏览器在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS1.3 在协议里明确废除 RSA 和 DH 则在标准层面保证了”前向安全”。

提升性能

HTTPS 建立连接时除了要做 TCP 握手，还要做 TLS 握手，在 1.2 中会多花两个消息往返（2-RTT），可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。

现在因为密码套件大幅度简化，也就没有必要再像以前那样走复杂的协商流程了。TLS1.3 压缩了以前的”Hello”协商过程，删除了”Key Exchange”消息，把握手时间减少到了”1-RTT”，效率提高了一倍。

那么它是怎么做的呢？

其实具体的做法还是利用了扩展。客户端在”Client Hello”消息里直接用”supported_groups”带上支持的曲线，比如 P-256、x25519，用”key_share”带上曲线对应的客户端公钥参数，用”signature_algorithms”带上签名算法。

服务器收到后在这些扩展里选定一个曲线和参数，再用”key_share”扩展返回服务器这边的公钥参数，就实现了双方的密钥交换，后面的流程就和 1.2 基本一样了。

我为 1.3 的握手过程画了一张图，你可以对比 1.2 看看区别在哪里。

除了标准的”1-RTT”握手，TLS1.3 还引入了”0-RTT”握手，用”pre_shared_key”和”early_data”扩展，在 TCP 连接后立即就建立安全连接发送加密消息，不过这需要有一些前提条件，今天暂且不说。

握手分析

在 TCP 建立连接之后，浏览器首先还是发一个”Client Hello”。

因为 1.3 的消息兼容 1.2，所以开头的版本号、支持的密码套件和随机数（Client Random）结构都是一样的（不过这时的随机数是 32 个字节）。

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Random: cebeb6c05403654d66c2329…
    Cipher Suites (18 suites)
        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
        Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
        Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
    Extension: supported_versions (len=9)
        Supported Version: TLS 1.3 (0x0304)
        Supported Version: TLS 1.2 (0x0303)
    Extension: supported_groups (len=14)
        Supported Groups (6 groups)
            Supported Group: x25519 (0x001d)
            Supported Group: secp256r1 (0x0017)
    Extension: key_share (len=107)
        Key Share extension
            Client Key Share Length: 105
            Key Share Entry: Group: x25519
            Key Share Entry: Group: secp256r1

注意”Client Hello”里的扩展，”supported_versions”表示这是 TLS1.3，”supported_groups”是支持的曲线，”key_share”是曲线对应的参数。

服务器收到”Client Hello”同样返回”Server Hello”消息，还是要给出一个随机数（Server Random）和选定密码套件。

Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Random: 12d2bce6568b063d3dee2…
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Extension: supported_versions (len=2)
        Supported Version: TLS 1.3 (0x0304)
    Extension: key_share (len=36)
        Key Share extension
            Key Share Entry: Group: x25519, Key Exchange length: 32

表面上看和 TLS1.2 是一样的，重点是后面的扩展。”supported_versions”里确认使用的是 TLS1.3，然后在”key_share”扩展带上曲线和对应的公钥参数。

这时只交换了两条消息，客户端和服务器就拿到了四个共享信息：Client Random和Server Random、Client Params和Server Params，两边就可以各自用 ECDHE 算出”Pre-Master”，再用 HKDF 生成主密钥”Master Secret”，效率比 TLS1.2 提高了一大截。

在算出主密钥后，服务器立刻发出”Change Cipher Spec”消息，比 TLS1.2 提早进入加密通信，后面的证书等就都是加密的了，减少了握手时的明文信息泄露。

这里 TLS1.3 还有一个安全强化措施，多了个”Certificate Verify”消息，用服务器的私钥把前面的曲线、套件、参数等握手数据加了签名，作用和”Finished”消息差不多。但由于是私钥签名，所以强化了身份认证和和防窜改。

这两个”Hello”消息之后，客户端验证服务器证书，再发”Finished”消息，就正式完成了握手，开始收发 HTTP 报文。

课外小贴士

1. 对 TLS1.2 已知的攻击有 BEAST、BREACH,CRIME、FREAK、LUCKY13、POODLE、ROBOT 等。
2. 在 TLS1.3 的 RFC 文档里已经删除了”ChangeCipher Spec”子协议，但用 Wireshark 抓包却还能看到，这里以抓包为准。
3. TLS1.3 还提供了”降级保护机制”，如果”中间人”恶意降级到 1.2，服务器的随机数最后 8个字节会被设置为”44 4F 57 4E 47 52 4401”，即”DOWNGRD01”，支持 TLS1.3 的客户端就可以检查发现被降级，然后发出警报终止连接。

HTTPS的优化

HTTPS 连接大致上可以划分为两个部分，第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。

由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的”HTTPS 连接慢”指的就是刚开始建立连接的那段时间。

在 TCP 建连之后，正式数据传输之前，HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT。而且在握手消息的网络耗时之外，还会有其他的一些”隐形”消耗，比如：

产生用于密钥交换的临时公私钥对（ECDHE）；
验证证书时访问 CA 获取 CRL 或者 OCSP；
非对称加密解密处理”Pre-Master”。
在最差的情况下，也就是不做任何的优化措施，HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒，这其中既有网络耗时，也有计算耗时，就会让人产生”打开一个 HTTPS 网站好慢啊”的感觉。

不过刚才说的情况早就是”过去时”了，现在已经有了很多行之有效的 HTTPS 优化手段，运用得好可以把连接的额外耗时降低到几十毫秒甚至是”零”。

我画了一张图，把 TLS 握手过程中影响性能的部分都标记了出来，对照着它就可以”有的放矢”地来优化 HTTPS。

硬件优化

1. 更快的 CPU

   最好还内建 AES 优化，这样即可以加速握手，也可以加速传输。

2. SSL 加速卡

   加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力。

3. SSL 加速服务器

   用专门的服务器集群来彻底”卸载”TLS 握手时的加密解密计算。

软件优化

软件方面的优化还可以再分成两部分：一个是软件升级，一个是协议优化。

协议优化

如果有可能，应当尽量采用 TLS1.3，它大幅度简化了握手的过程，完全握手只要 1-RTT，而且更加安全。

如果暂时不能升级到 1.3，只能用 1.2，那么握手时使用的密钥交换协议应当尽量选用椭圆曲线的 ECDHE 算法。它不仅运算速度快，安全性高，还支持”False Start”，能够把握手的消息往返由 2-RTT 减少到 1-RTT，达到与 TLS1.3 类似的效果。

另外，椭圆曲线也要选择高性能的曲线，最好是 x25519，次优选择是 P-256。对称加密算法方面，也可以选用”AES_128_GCM”，它能比”AES_256_GCM”略快一点点。

在 Nginx 里可以用”ssl_ciphers””ssl_ecdh_curve”等指令配置服务器使用的密码套件和椭圆曲线，把优先使用的放在前面，例如：

ssl_ciphers     TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:EECDH+CHACHA20；
ssl_ecdh_curve  X25519:P-256;

证书优化

这里就有两个优化点，一个是证书传输，一个是证书验证。

服务器的证书可以选择椭圆曲线（ECDSA）证书而不是 RSA 证书，因为 224 位的 ECC 相当于 2048 位的 RSA，所以椭圆曲线证书的”个头”要比 RSA 小很多，即能够节约带宽也能减少客户端的运算量，可谓”一举两得”。

客户端的证书验证其实是个很复杂的操作，除了要公钥解密验证多个证书签名外，因为证书还有可能会被撤销失效，客户端有时还会再去访问 CA，下载 CRL 或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。

CRL（Certificate revocation list，证书吊销列表）由 CA 定期发布，里面是所有被撤销信任的证书序号，查询这个列表就可以知道证书是否有效。

但 CRL 因为是”定期”发布，就有”时间窗口”的安全隐患，而且随着吊销证书的增多，列表会越来越大，一个 CRL 经常会上 MB。想象一下，每次需要预先下载几 M 的”无用数据”才能连接网站，实用性实在是太低了。

所以，现在 CRL 基本上不用了，取而代之的是 OCSP（在线证书状态协议，Online Certificate Status Protocol），向 CA 发送查询请求，让 CA 返回证书的有效状态。

但 OCSP 也要多出一次网络请求的消耗，而且还依赖于 CA 服务器，如果 CA 服务器很忙，那响应延迟也是等不起的。

于是又出来了一个”补丁”，叫”OCSP Stapling”（OCSP 装订），它可以让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间。

会话复用

回想一下 HTTPS 建立连接的过程：先是 TCP 三次握手，然后是 TLS 一次握手。这后一次握手的重点是算出主密钥”Master Secret”，而主密钥每次连接都要重新计算，未免有点太浪费了，如果能够把”辛辛苦苦”算出来的主密钥缓存一下”重用”，不就可以免去了握手和计算的成本了吗？

这种做法就叫”会话复用”（TLS session resumption），和 HTTP Cache 一样，也是提高 HTTPS 性能的”大杀器”，被浏览器和服务器广泛应用。

会话复用分两种，第一种叫”Session ID”，就是客户端和服务器首次连接后各自保存一个会话的 ID 号，内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个 ID 过来，服务器就在内存里找，找到就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息往返就可以建立安全通信。

实验环境的端口 441 实现了”Session ID”的会话复用，你可以访问 URI https://www.chrono.com:441/28-1，刷新几次，用 Wireshark 抓包看看实际的效果。

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Session ID: 13564734eeec0a658830cd…
    Cipher Suites Length: 34
 
 
Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Session ID: 13564734eeec0a658830cd…
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

通过抓包可以看到，服务器在”ServerHello”消息后直接发送了”Change Cipher Spec”和”Finished”消息，复用会话完成了握手。

实际复现方法：

$ echo "GET /28-1" | openssl s_client -connect www.chrono.com:441 -tls1_2 -sess_out session.pem
ssl handshake by TLSv1.2

ssl session id is [62ca9b2ef960760e6b3a5f84bc9a21eb3bfd28dbd171e9a7a336ba1c08495261]

reused? false

$ echo "GET /28-1" | openssl s_client -connect www.chrono.com:441 -tls1_2 -sess_in session.pem
ssl handshake by TLSv1.2

ssl session id is [62ca9b2ef960760e6b3a5f84bc9a21eb3bfd28dbd171e9a7a336ba1c08495261]

reused? true

会话票证

“Session ID”是最早出现的会话复用技术，也是应用最广的，但它也有缺点，服务器必须保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。

于是，又出现了第二种”Session Ticket”方案。

它有点类似 HTTP 的 Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用”New Session Ticket”消息发给客户端，让客户端保存。

重连的时候，客户端使用扩展”session_ticket”发送”Ticket”而不是”Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信。

这个过程也可以在实验环境里测试，端口号是 442，URI 是 https://www.chrono.com:442/28-1。

不过”Session Ticket”方案需要使用一个固定的密钥文件（ticket_key）来加密 Ticket，为了防止密钥被破解，保证”前向安全”，密钥文件需要定期轮换，比如设置为一小时或者一天。

实际复现方法：

$ echo "GET /28-1" | openssl s_client -connect www.chrono.com:442 -tls1_2 -sess_out session.pem
ssl handshake by TLSv1.2

ssl session id is []

reused? false

$ echo "GET /28-1" | openssl s_client -connect www.chrono.com:442 -tls1_2 -sess_in session.pem
ssl handshake by TLSv1.2

ssl session id is [154a4f087c9afd9c386d18e50b98be58beaf5205df1946e9475a0919a427d0bf]

reused? true

预共享密钥

“False Start””Session ID””Session Ticket”等方式只能实现 1-RTT，而 TLS1.3 更进一步实现了”0-RTT”，原理和”Session Ticket”差不多，但在发送 Ticket 的同时会带上应用数据（Early Data），免去了 1.2 里的服务器确认步骤，这种方式叫”Pre-shared Key”，简称为”PSK”。

但”PSK”也不是完美的，它为了追求效率而牺牲了一点安全性，容易受到”重放攻击”（Replay attack）的威胁。黑客可以截获”PSK”的数据，像复读机那样反复向服务器发送。

解决的办法是只允许安全的 GET/HEAD 方法（参见[第 10 讲]），在消息里加入时间戳、”nonce”验证，或者”一次性票证”限制重放。

$ rm -f session.pem && echo "GET /28-1" | openssl s_client -connect www.chrono.com:444 -tls1_3 -sess_out session.pem
ssl handshake by TLSv1.3

ssl session id is [4686648639a518eee07db85218bd6c5a8bdf0df5ffb03e751c3612d27028a012]

reused? false

$ echo "GET /28-1" > early_data.txt && openssl s_client -connect www.chrono.com:444 -tls1_3 -sess_in session.pem -early_data early_data.txt
ssl handshake by TLSv1.3

ssl session id is [4686648639a518eee07db85218bd6c5a8bdf0df5ffb03e751c3612d27028a012]

reused? true

课外小贴士

1. 使用”SSL 加速卡”的一个案例是阿里的 Tengine，它基于 Intel QAT 加速卡，定制了Nginx和 OpenSSL.
2. 因为 OCSP 会增加额外的网络连接成本，所以Chrome 等浏览器的策略是只对 EV 证书使用OCSP 检查有效性，普通网站使用 DV、OV 证书省略了这个操作，就会略微快一点。
3. 在 Nginx 里可以用指令”ssl_stapling on”开启”OCSP Stapling”，而在 OpenResty 里更可以编写 Lua 代码灵活定制。
4. “Session ID”和”Session Ticket”这两种会话复用技术在 TLS1.3 中均已经被废除，只能使用 PSK 实现会话复用。

我应该迁移到HTTPS吗

申请证书

几个注意事项

第一，申请证书时应当同时申请 RSA 和 ECDSA 两种证书，在 Nginx 里配置成双证书验证，这样服务器可以自动选择快速的椭圆曲线证书，同时也兼容只支持 RSA 的客户端。

第二，如果申请 RSA 证书，私钥至少要 2048 位，摘要算法应该选用 SHA-2，例如 SHA256、SHA384 等。

第三，出于安全的考虑，”Let’s Encrypt”证书的有效期很短，只有 90 天，时间一到就会过期失效，所以必须要定期更新。你可以在 crontab 里加个每周或每月任务，发送更新请求，不过很多 ACME 客户端会自动添加这样的定期任务，完全不用你操心。

配置 HTTPS

密码套件的选择方面，我给你的建议是以服务器的套件优先。这样可以避免恶意客户端故意选择较弱的套件、降低安全等级，然后密码套件向 TLS1.3”看齐”，只使用 ECDHE、AES 和 ChaCha20，支持”False Start”。

ssl_prefer_server_ciphers   on;

ssl_ciphers   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:!MD5:!SHA1;

如果你的服务器上使用了 OpenSSL 的分支 BorringSSL，那么还可以使用一个特殊的”等价密码组”（Equal preference cipher groups）特性，它可以让服务器配置一组”等价”的密码套件，在这些套件里允许客户端优先选择，比如这么配置：

ssl_ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305];

如果客户端硬件没有 AES 优化，服务器就会顺着客户端的意思，优先选择与 AES”等价”的 ChaCha20 算法，让客户端能够快一点。

重定向跳转

现在有了 HTTPS 服务，但原来的 HTTP 站点也不能马上弃用，还是会有很多网民习惯在地址栏里直接敲域名（或者是旧的书签、超链接），默认使用 HTTP 协议访问。

所以，我们就需要用到”重定向跳转”技术了，把不安全的 HTTP 网址用 301 或 302”重定向”到新的 HTTPS 网站，这在 Nginx 里也很容易做到，使用”return”或”rewrite”都可以。

return 301 https://$host$request_uri;             # 永久重定向
rewrite ^  https://$host$request_uri permanent;   # 永久重定向

但这种方式有两个问题。一个是重定向增加了网络成本，多出了一次请求；另一个是存在安全隐患，重定向的响应可能会被”中间人”窜改，实现”会话劫持”，跳转到恶意网站。

不过有一种叫”HSTS”（HTTP 严格传输安全，HTTP Strict Transport Security）的技术可以消除这种安全隐患。HTTPS 服务器需要在发出的响应头里添加一个”Strict-Transport-Security”的字段，再设定一个有效期，例如：

Strict-Transport-Security: max-age=15768000; includeSubDomains

这相当于告诉浏览器：我这个网站必须严格使用 HTTPS 协议，在半年之内（182.5 天）都不允许用 HTTP，你以后就自己做转换吧，不要再来麻烦我了。

有了”HSTS”的指示，以后浏览器再访问同样的域名的时候就会自动把 URI 里的”http”改成”https”，直接访问安全的 HTTPS 网站。这样”中间人”就失去了攻击的机会，而且对于客户端来说也免去了一次跳转，加快了连接速度。

课外小贴士

1. SNI使用明文表示域名，也就提前暴露了一部分 HTTPS 的信息，有安全隐患，容易被”中间人”发起拒绝攻击，被认为是 TLS”盔甲上最后的一个缝隙”，目前正在起草 ESNI规范。
2. “HSTS”无法防止黑客对第一次访问的攻击所以 Chrome 等浏览器还内置了一个”HSTSpreload”的列表(chrome://net-internals/#hsts)，只要域名在这个列表里，无论何时都会强制使用 HTTPS 访问。
3. “HPKP”(HTTP Public Key Pinning)是另一种 HTTPS 安全技术，指示客户端固定网站使用的公钥，防止”中间人”攻击，但因为接受程度过低，现在已经被放弃了。
4. 之前在实验环境访问 HTTP 协议时可以看到请求头里有”Upgrade-Insecure-Requests:1”它就是 CSP 的一种，表示浏览器支持升级到HTTPS 协议。

HTTP2特性概览

刚结束的”安全篇”里的 HTTPS，通过引入 SSL/TLS 在安全上达到了”极致”，但在性能提升方面却是乏善可陈，只优化了握手加密的环节，对于整体的数据传输没有提出更好的改进方案，还只能依赖于”长连接”这种”落后”的技术。

所以，在 HTTPS 逐渐成熟之后，HTTP 就向着性能方面开始”发力”，走出了另一条进化的道路。

在[第 1 讲]的 HTTP 历史中你也看到了，”秦失其鹿，天下共逐之”，Google 率先发明了 SPDY 协议，并应用于自家的浏览器 Chrome，打响了 HTTP 性能优化的”第一枪”。

随后互联网标准化组织 IETF 以 SPDY 为基础，综合其他多方的意见，终于推出了 HTTP/1 的继任者，也就是今天的主角”HTTP/2”，在性能方面有了一个大的飞跃。

为什么不是 HTTP/2.0

对此 HTTP/2 工作组特别给出了解释。

他们认为以前的”1.0””1.1”造成了很多的混乱和误解，让人在实际的使用中难以区分差异，所以就决定 HTTP 协议不再使用小版本号（minor version），只使用大版本号（major version），从今往后 HTTP 协议不会出现 HTTP/2.0、2.1，只会有”HTTP/2””HTTP/3”……

这样就可以明确无误地辨别出协议版本的”跃进程度”，让协议在一段较长的时期内保持稳定，每当发布新版本的 HTTP 协议都会有本质的不同，绝不会有”零敲碎打”的小改良。

兼容 HTTP/1

由于 HTTPS 已经在安全方面做的非常好了，所以 HTTP/2 的唯一目标就是改进性能。

但它不仅背负着众多的期待，同时还背负着 HTTP/1 庞大的历史包袱，所以协议的修改必须小心谨慎，兼容性是首要考虑的目标，否则就会破坏互联网上无数现有的资产，这方面 TLS 已经有了先例（为了兼容 TLS1.2 不得不进行”伪装”）。

那么，HTTP/2 是怎么做的呢？

因为必须要保持功能上的兼容，所以 HTTP/2 把 HTTP 分解成了”语义”和”语法”两个部分，”语义”层不做改动，与 HTTP/1 完全一致（即 RFC7231）。比如请求方法、URI、状态码、头字段等概念都保留不变，这样就消除了再学习的成本，基于 HTTP 的上层应用也不需要做任何修改，可以无缝转换到 HTTP/2。

特别要说的是，与 HTTPS 不同，HTTP/2 没有在 URI 里引入新的协议名，仍然用”http”表示明文协议，用”https”表示加密协议。

这是一个非常了不起的决定，可以让浏览器或者服务器去自动升级或降级协议，免去了选择的麻烦，让用户在上网的时候都意识不到协议的切换，实现平滑过渡。

在”语义”保持稳定之后，HTTP/2 在”语法”层做了”天翻地覆”的改造，完全变更了 HTTP 报文的传输格式。

头部压缩

首先，HTTP/2 对报文的头部做了一个”大手术”。

通过”进阶篇”的学习你应该知道，HTTP/1 里可以用头字段”Content-Encoding”指定 Body 的编码方式，比如用 gzip 压缩来节约带宽，但报文的另一个组成部分——Header 却被无视了，没有针对它的优化手段。

由于报文 Header 一般会携带”User Agent””Cookie””Accept””Server”等许多固定的头字段，多达几百字节甚至上千字节，但 Body 却经常只有几十字节（比如 GET 请求、204/301/304 响应），成了不折不扣的”大头儿子”。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费，”长尾效应”导致大量带宽消耗在了这些冗余度极高的数据上。

所以，HTTP/2 把”头部压缩”作为性能改进的一个重点，优化的方式你也肯定能想到，还是”压缩”。

不过 HTTP/2 并没有使用传统的压缩算法，而是开发了专门的”HPACK”算法，在客户端和服务器两端建立”字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率。

二进制格式

你可能已经很习惯于 HTTP/1 里纯文本形式的报文了，它的优点是”一目了然”，用最简单的工具就可以开发调试，非常方便。

但 HTTP/2 在这方面没有”妥协”，决定改变延续了十多年的现状，不再使用肉眼可见的 ASCII 码，而是向下层的 TCP/IP 协议”靠拢”，全面采用二进制格式。

这样虽然对人不友好，但却大大方便了计算机的解析。原来使用纯文本的时候容易出现多义性，比如大小写、空白字符、回车换行、多字少字等等，程序在处理时必须用复杂的状态机，效率低，还麻烦。

而二进制里只有”0”和”1”，可以严格规定字段大小、顺序、标志位等格式，”对就是对，错就是错”，解析起来没有歧义，实现简单，而且体积小、速度快，做到”内部提效”。

以二进制格式为基础，HTTP/2 就开始了”大刀阔斧”的改革。

它把 TCP 协议的部分特性挪到了应用层，把原来的”Header+Body”的消息”打散”为数个小片的二进制”帧”（Frame），用”HEADERS”帧存放头数据、”DATA”帧存放实体数据。

这种做法有点像是”Chunked”分块编码的方式，也是”化整为零”的思路，但 HTTP/2 数据分帧后”Header+Body”的报文结构就完全消失了，协议看到的只是一个个的”碎片”。

虚拟的”流”

HTTP/2 为此定义了一个”流”（Stream）的概念，它是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID。你可以想象把它成是一个虚拟的”数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文。

因为”流”是虚拟的，实际上并不存在，所以 HTTP/2 就可以在一个 TCP 连接上用”流”同时发送多个”碎片化”的消息，这就是常说的”多路复用”（ Multiplexing）——多个往返通信都复用一个连接来处理。

在”流”的层面上看，消息是一些有序的”帧”序列，而在”连接”的层面上看，消息却是乱序收发的”帧”。多个请求 / 响应之间没有了顺序关系，不需要排队等待，也就不会再出现”队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。

为了更好地利用连接，加大吞吐量，HTTP/2 还添加了一些控制帧来管理虚拟的”流”，实现了优先级和流量控制，这些特性也和 TCP 协议非常相似。

HTTP/2 还在一定程度上改变了传统的”请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建”流”主动向客户端发送消息。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为”服务器推送”（Server Push，也叫 Cache Push）。

强化安全

出于兼容的考虑，HTTP/2 延续了 HTTP/1 的”明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密。

但由于 HTTPS 已经是大势所趋，而且主流的浏览器 Chrome、Firefox 等都公开宣布只支持加密的 HTTP/2，所以”事实上”的 HTTP/2 是加密的。也就是说，互联网上通常所能见到的 HTTP/2 都是使用”https”协议名，跑在 TLS 上面。

为了区分”加密”和”明文”这两个不同的版本，HTTP/2 协议定义了两个字符串标识符：”h2”表示加密的 HTTP/2，”h2c”表示明文的 HTTP/2，多出的那个字母”c”的意思是”clear text”。

在 HTTP/2 标准制定的时候（2015 年）已经发现了很多 SSL/TLS 的弱点，而新的 TLS1.3 还未发布，所以加密版本的 HTTP/2 在安全方面做了强化，要求下层的通信协议必须是 TLS1.2 以上，还要支持前向安全和 SNI，并且把几百个弱密码套件列入了”黑名单”，比如 DES、RC4、CBC、SHA-1 都不能在 HTTP/2 里使用，相当于底层用的是”TLS1.25”。

协议栈

下面的这张图对比了 HTTP/1、HTTPS 和 HTTP/2 的协议栈，你可以清晰地看到，HTTP/2 是建立在”HPack””Stream””TLS1.2”基础之上的，比 HTTP/1、HTTPS 复杂了一些。

虽然 HTTP/2 的底层实现很复杂，但它的”语义”还是简单的 HTTP/1，之前学习的知识不会过时，仍然能够用得上。

我们的实验环境在新的域名 上启用了 HTTP/2 协议，你可以把之前”进阶篇””安全篇”的测试用例都走一遍，再用 Wireshark 抓一下包，实际看看 HTTP/2 的效果和对老协议的兼容性（例如 http://www.metroid.net/11-1 ）。

在今天这节课专用的 URI”/30-1”里，你还可以看到服务器输出了 HTTP 的版本号”2”和标识符”h2”，表示这是加密的 HTTP/2，如果改用 https://www.chrono.com/30-1 访问就会是”1.1”和空。

你可能还会注意到 URI 里的一个小变化，端口使用的是”8443”而不是”443”。这是因为 443 端口已经被”www.chrono.com”的 HTTPS 协议占用，Nginx 不允许在同一个端口上根据域名选择性开启 HTTP/2，所以就不得不改用了”8443”。

课外小贴士

1. 在早期还有一个”HTTP-NG”(HTTP NextGeneration)项目，最终失败了。
2. HTTP/2 的”前身”SPDY 在压缩头部时使用了 gzip，但发现会受到”CRIME”攻击，所以开发了专用的压缩算法 HPACK
3. HTTP/2 里的”流”可以实现 HTTP/1 里的”管道”(pipeline)功能，而且综合性能更好，所以”管道”在 HTTP/2 里就被废弃了。
4. HTTP/2 要求必须实现的密码套件是”TLSECDHE RSA WITH AES 128 GCM SHA256”，比 TLS1.2 默认的”TLS_RSA WITHAES_128_CBC_SHA”的安全强度高了很多。
5. 实验环境的 启用了 RSA和 ECC 双证书，在浏览器里可以看到实际连接时用的会是 ECC 证书。另外，这个域名还用到了重定向跳转技术，使用 301跳转，把”80/443”端口的请求重定向到HTTP/2 的”8443”

HTTP2内核剖析

连接前言

由于 HTTP/2”事实上”是基于 TLS，所以在正式收发数据之前，会有 TCP 握手和 TLS 握手，这两个步骤相信你一定已经很熟悉了，所以这里就略过去不再细说。

TLS 握手成功之后，客户端必须要发送一个”连接前言”（connection preface），用来确认建立 HTTP/2 连接。

这个”连接前言”是标准的 HTTP/1 请求报文，使用纯文本的 ASCII 码格式，请求方法是特别注册的一个关键字”PRI”，全文只有 24 个字节：

PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

在 Wireshark 里，HTTP/2 的”连接前言”被称为”Magic”，意思就是”不可知的魔法”。

所以，就不要问”为什么会是这样”了，只要服务器收到这个”有魔力的字符串”，就知道客户端在 TLS 上想要的是 HTTP/2 协议，而不是其他别的协议，后面就会都使用 HTTP/2 的数据格式。

实际测试

实际测试发现，tls握手的过程中，服务器回给客户端的Encrypted Extensions 中会包含 application_layer_protocol_negotiation 并来表明服务器支持 http 2

头部压缩

确立了连接之后，HTTP/2 就开始准备请求报文。

因为语义上它与 HTTP/1 兼容，所以报文还是由”Header+Body”构成的，但在请求发送前，必须要用”HPACK”算法来压缩头部数据。

“HPACK”算法是专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不同，它是一个”有状态”的算法，需要客户端和服务器各自维护一份”索引表”，也可以说是”字典”（这有点类似 brotli），压缩和解压缩就是查表和更新表的操作。

为了方便管理和压缩，HTTP/2 废除了原有的起始行概念，把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式，并且给这些”不是头字段的头字段”起了个特别的名字——“伪头字段”（pseudo-header fields）。而起始行里的版本号和错误原因短语因为没什么大用，顺便也给废除了。

为了与”真头字段”区分开来，这些”伪头字段”会在名字前加一个”:”，比如”:authority” “:method” “:status”，分别表示的是域名、请求方法和状态码。

现在 HTTP 报文头就简单了，全都是”Key-Value”形式的字段，于是 HTTP/2 就为一些最常用的头字段定义了一个只读的”静态表”（Static Table）。

下面的这个表格列出了”静态表”的一部分，这样只要查表就可以知道字段名和对应的值，比如数字”2”代表”GET”，数字”8”代表状态码 200。

但如果表里只有 Key 没有 Value，或者是自定义字段根本找不到该怎么办呢？

这就要用到”动态表”（Dynamic Table），它添加在静态表后面，结构相同，但会在编码解码的时候随时更新。

比如说，第一次发送请求时的”user-agent”字段长是一百多个字节，用哈夫曼压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号”65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好。

你可以想象得出来，随着在 HTTP/2 连接上发送的报文越来越多，两边的”字典”也会越来越丰富，最终每次的头部字段都会变成一两个字节的代码，原来上千字节的头用几十个字节就可以表示了，压缩效果比 gzip 要好得多。

二进制帧

头部数据压缩之后，HTTP/2 就要把报文拆成二进制的帧准备发送。

HTTP/2 的帧结构有点类似 TCP 的段或者 TLS 里的记录，但报头很小，只有 9 字节，非常地节省（可以对比一下 TCP 头，它最少是 20 个字节）。

二进制的格式也保证了不会有歧义，而且使用位运算能够非常简单高效地解析。

帧开头是 3 个字节的长度（但不包括头的 9 个字节），默认上限是 2^14，最大是 2^24，也就是说 HTTP/2 的帧通常不超过 16K，最大是 16M。

长度后面的一个字节是帧类型，大致可以分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧属于数据帧，存放的是 HTTP 报文，而 SETTINGS、PING、PRIORITY 等则是用来管理流的控制帧。

HTTP/2 总共定义了 10 种类型的帧，但一个字节可以表示最多 256 种，所以也允许在标准之外定义其他类型实现功能扩展。这就有点像 TLS 里扩展协议的意思了，比如 Google 的 gRPC 就利用了这个特点，定义了几种自用的新帧类型。

第 5 个字节是非常重要的帧标志信息，可以保存 8 个标志位，携带简单的控制信息。常用的标志位有END_HEADERS表示头数据结束，相当于 HTTP/1 里头后的空行（”\r\n”），END_STREAM表示单方向数据发送结束（即 EOS，End of Stream），相当于 HTTP/1 里 Chunked 分块结束标志（”0\r\n\r\n”）。

报文头里最后 4 个字节是流标识符，也就是帧所属的”流”，接收方使用它就可以从乱序的帧里识别出具有相同流 ID 的帧序列，按顺序组装起来就实现了虚拟的”流”。

流标识符虽然有 4 个字节，但最高位被保留不用，所以只有 31 位可以使用，也就是说，流标识符的上限是 2^31，大约是 21 亿。

好了，把二进制头理清楚后，我们来看一下 Wireshark 抓包的帧实例：

在这个帧里，开头的三个字节是”00010a”，表示数据长度是 266 字节。

帧类型是 1，表示 HEADERS 帧，负载（payload）里面存放的是被 HPACK 算法压缩的头部信息。

标志位是 0x25，转换成二进制有 3 个位被置 1。PRIORITY 表示设置了流的优先级，END_HEADERS 表示这一个帧就是完整的头数据，END_STREAM 表示单方向数据发送结束，后续再不会有数据帧（即请求报文完毕，不会再有 DATA 帧 /Body 数据）。

最后 4 个字节的流标识符是整数 1，表示这是客户端发起的第一个流，后面的响应数据帧也会是这个 ID，也就是说在 stream[1] 里完成这个请求响应。

流与多路复用

弄清楚了帧结构后我们就来看 HTTP/2 的流与多路复用，它是 HTTP/2 最核心的部分。

在上一讲里我简单介绍了流的概念，不知道你”悟”得怎么样了？这里我再重复一遍：流是二进制帧的双向传输序列。

要搞明白流，关键是要理解帧头里的流 ID。

在 HTTP/2 连接上，虽然帧是乱序收发的，但只要它们都拥有相同的流 ID，就都属于一个流，而且在这个流里帧不是无序的，而是有着严格的先后顺序。

比如在这次的 Wireshark 抓包里，就有”0、1、3”一共三个流，实际上就是分配了三个流 ID 号，把这些帧按编号分组，再排一下队，就成了流。

在概念上，一个 HTTP/2 的流就等同于一个 HTTP/1 里的”请求 - 应答”。在 HTTP/1 里一个”请求 - 响应”报文来回是一次 HTTP 通信，在 HTTP/2 里一个流也承载了相同的功能。

你还可以对照着 TCP 来理解。TCP 运行在 IP 之上，其实从 MAC 层、IP 层的角度来看，TCP 的”连接”概念也是”虚拟”的。但从功能上看，无论是 HTTP/2 的流，还是 TCP 的连接，都是实际存在的，所以你以后大可不必再纠结于流的”虚拟”性，把它当做是一个真实存在的实体来理解就好。

HTTP/2 的流有哪些特点呢？我给你简单列了一下：

1. 流是可并发的，一个 HTTP/2 连接上可以同时发出多个流传输数据，也就是并发多请求，实现”多路复用”；
2. 客户端和服务器都可以创建流，双方互不干扰；
3. 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个”请求 - 应答”来回；
4. 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；
5. 流可以设置优先级，让服务器优先处理，比如先传 HTML/CSS，后传图片，优化用户体验；
6. 流 ID 不能重用，只能顺序递增，客户端发起的 ID 是奇数，服务器端发起的 ID 是偶数；
7. 在流上发送”RST_STREAM”帧可以随时终止流，取消接收或发送；
8. 第 0 号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制。

从这些特性中，我们还可以推理出一些深层次的知识点。

比如说，HTTP/2 在一个连接上使用多个流收发数据，那么它本身默认就会是长连接，所以永远不需要”Connection”头字段（keepalive 或 close）。

你可以再看一下 Wireshark 的抓包，里面发送了两个请求”/31-1”和”/favicon.ico”，始终用的是”56095<->8443”这个连接，对比一下[第 8 讲]，你就能够看出差异了。

又比如，下载大文件的时候想取消接收，在 HTTP/1 里只能断开 TCP 连接重新”三次握手”，成本很高，而在 HTTP/2 里就可以简单地发送一个”RST_STREAM”中断流，而长连接会继续保持。

再比如，因为客户端和服务器两端都可以创建流，而流 ID 有奇数偶数和上限的区分，所以大多数的流 ID 都会是奇数，而且客户端在一个连接里最多只能发出 2^30，也就是 10 亿个请求。

所以就要问了：ID 用完了该怎么办呢？这个时候可以再发一个控制帧”GOAWAY”，真正关闭 TCP 连接。

流状态转换

流很重要，也很复杂。为了更好地描述运行机制，HTTP/2 借鉴了 TCP，根据帧的标志位实现流状态转换。当然，这些状态也是虚拟的，只是为了辅助理解。

HTTP/2 的流也有一个状态转换图，虽然比 TCP 要简单一点，但也不那么好懂，所以今天我只画了一个简化的图，对应到一个标准的 HTTP”请求 - 应答”。

最开始的时候流都是”空闲”（idle）状态，也就是”不存在”，可以理解成是待分配的”号段资源”。

当客户端发送 HEADERS 帧后，有了流 ID，流就进入了”打开”状态，两端都可以收发数据，然后客户端发送一个带”END_STREAM”标志位的帧，流就进入了”半关闭”状态。

这个”半关闭”状态很重要，意味着客户端的请求数据已经发送完了，需要接受响应数据，而服务器端也知道请求数据接收完毕，之后就要内部处理，再发送响应数据。

响应数据发完了之后，也要带上”END_STREAM”标志位，表示数据发送完毕，这样流两端就都进入了”关闭”状态，流就结束了。

刚才也说过，流 ID 不能重用，所以流的生命周期就是 HTTP/1 里的一次完整的”请求 - 应答”，流关闭就是一次通信结束。

下一次再发请求就要开一个新流（而不是新连接），流 ID 不断增加，直到到达上限，发送”GOAWAY”帧开一个新的 TCP 连接，流 ID 就又可以重头计数。

你再看看这张图，是不是和 HTTP/1 里的标准”请求 - 应答”过程很像，只不过这是发生在虚拟的”流”上，而不是实际的 TCP 连接，又因为流可以并发，所以 HTTP/2 就可以实现无阻塞的多路复用。

课外小贴士

1. 你一定很好奇 HTTP/2”连接前言”的来历吧其实把里面的字符串连起来就是”PRISM”，也就是 2013 年斯诺登爆出的”棱镜计划”
2. 在 HTTP/1 里头字段是不区分大小写的，这在实践中造成了一些混乱，写法很随意，所以HTTP/2 做出了明确的规定，要求所有的头字段必须全小写，大写会认为是格式错误。
3. HPACK 的编码规则比较复杂，使用了一些特殊的标志位，所以在 Wireshark 抓包里不会直接看到字段的索引号，需要按照规则解码。
4. HEADERS 帧后还可以接特殊的”CONTINUATION”帧，发送特别大的头，最后一个”CONTINUATION”需要设置标志位 END HEADERS表示头结束。
5. 服务器端发起推送流需要使用”PUSH PROMISE”帧，状态转换与客户端流基本类似，只是方向不同。
6. 在”RST _STREAM”和”GOAWAY”帧里可以携带 32 位的错误代码，表示终止流的原因它是真正的”错误”与状态码的含义是不同的。

HTTP3展望

在前面的两讲里，我们一起学习了 HTTP/2，你也应该看到了 HTTP/2 做出的许多努力，比如头部压缩、二进制分帧、虚拟的”流”与多路复用，性能方面比 HTTP/1 有了很大的提升，”基本上”解决了”队头阻塞”这个”老大难”问题。

HTTP/2 的”队头阻塞”

等等，你可能要发出疑问了：为什么说是”基本上”，而不是”完全”解决了呢？

这是因为 HTTP/2 虽然使用”帧””流””多路复用”，没有了”队头阻塞”，但这些手段都是在应用层里，而在下层，也就是 TCP 协议里，还是会发生”队头阻塞”。

这是怎么回事呢？

让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个”请求 - 响应”分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是”段”）。

在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的”丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能”干着急”。

我举个简单的例子：

客户端用 TCP 发送了三个包，但服务器所在的操作系统只收到了后两个包，第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来，”停下”等着客户端重传那个丢失的包，这样就又出现了”队头阻塞”。

由于这种”队头阻塞”是 TCP 协议固有的，所以 HTTP/2 即使设计出再多的”花样”也无法解决。

Google 在推 SPDY 的时候就已经意识到了这个问题，于是就又发明了一个新的”QUIC”协议，让 HTTP 跑在 QUIC 上而不是 TCP 上。

而这个”HTTP over QUIC”就是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃，真正”完美”地解决了”队头阻塞”问题。

不过 HTTP/3 目前还处于草案阶段，正式发布前可能会有变动，所以今天我尽量不谈那些不稳定的细节。

这里先贴一下 HTTP/3 的协议栈图，让你对它有个大概的了解。

QUIC 协议

从这张图里，你可以看到 HTTP/3 有一个关键的改变，那就是它把下层的 TCP”抽掉”了，换成了 UDP。因为 UDP 是无序的，包之间没有依赖关系，所以就从根本上解决了”队头阻塞”。

你一定知道，UDP 是一个简单、不可靠的传输协议，只是对 IP 协议的一层很薄的包装，和 TCP 相比，它实际应用的较少。

不过正是因为它简单，不需要建连和断连，通信成本低，也就非常灵活、高效，”可塑性”很强。

所以，QUIC 就选定了 UDP，在它之上把 TCP 的那一套连接管理、拥塞窗口、流量控制等”搬”了过来，”去其糟粕，取其精华”，打造出了一个全新的可靠传输协议，可以认为是”新时代的 TCP”。

QUIC 最早是由 Google 发明的，被称为 gQUIC。而当前正在由 IETF 标准化的 QUIC 被称为 iQUIC。两者的差异非常大，甚至比当年的 SPDY 与 HTTP/2 的差异还要大。

gQUIC 混合了 UDP、TLS、HTTP，是一个应用层的协议。而 IETF 则对 gQUIC 做了”清理”，把应用部分分离出来，形成了 HTTP/3，原来的 UDP 部分”下放”到了传输层，所以 iQUIC 有时候也叫”QUIC-transport”。

接下来要说的 QUIC 都是指 iQUIC，要记住，它与早期的 gQUIC 不同，是一个传输层的协议，和 TCP 是平级的。

QUIC 的特点

QUIC 基于 UDP，而 UDP 是”无连接”的，根本就不需要”握手”和”挥手”，所以天生就要比 TCP 快。

就像 TCP 在 IP 的基础上实现了可靠传输一样，QUIC 也基于 UDP 实现了可靠传输，保证数据一定能够抵达目的地。它还引入了类似 HTTP/2 的”流”和”多路复用”，单个”流”是有序的，可能会因为丢包而阻塞，但其他”流”不会受到影响。

为了防止网络上的中间设备（Middle Box）识别协议的细节，QUIC 全面采用加密通信，可以很好地抵御窜改和”协议僵化”（ossification）。

而且，因为 TLS1.3 已经在去年（2018）正式发布，所以 QUIC 就直接应用了 TLS1.3，顺便也就获得了 0-RTT、1-RTT 连接的好处。

但 QUIC 并不是建立在 TLS 之上，而是内部”包含”了 TLS。它使用自己的帧”接管”了 TLS 里的”记录”，握手消息、警报消息都不使用 TLS 记录，直接封装成 QUIC 的帧发送，省掉了一次开销。

QUIC 内部细节

由于 QUIC 在协议栈里比较偏底层，所以我只简略介绍两个内部的关键知识点。

QUIC 的基本数据传输单位是包（packet）和帧（frame），一个包由多个帧组成，包面向的是”连接”，帧面向的是”流”。

QUIC 使用不透明的”连接 ID”来标记通信的两个端点，客户端和服务器可以自行选择一组 ID 来标记自己，这样就解除了 TCP 里连接对”IP 地址 + 端口”（即常说的四元组）的强绑定，支持”连接迁移”（Connection Migration）。

比如你下班回家，手机会自动由 4G 切换到 WiFi。这时 IP 地址会发生变化，TCP 就必须重新建立连接。而 QUIC 连接里的两端连接 ID 不会变，所以连接在”逻辑上”没有中断，它就可以在新的 IP 地址上继续使用之前的连接，消除重连的成本，实现连接的无缝迁移。

QUIC 的帧里有多种类型，PING、ACK 等帧用于管理连接，而 STREAM 帧专门用来实现流。

QUIC 里的流与 HTTP/2 的流非常相似，也是帧的序列，你可以对比着来理解。但 HTTP/2 里的流都是双向的，而 QUIC 则分为双向流和单向流。

QUIC 帧普遍采用变长编码，最少只要 1 个字节，最多有 8 个字节。流 ID 的最大可用位数是 62，数量上比 HTTP/2 的 2^31 大大增加。

流 ID 还保留了最低两位用作标志，第 1 位标记流的发起者，0 表示客户端，1 表示服务器；第 2 位标记流的方向，0 表示双向流，1 表示单向流。

所以 QUIC 流 ID 的奇偶性质和 HTTP/2 刚好相反，客户端的 ID 是偶数，从 0 开始计数。

HTTP/3 协议

了解了 QUIC 之后，再来看 HTTP/3 就容易多了。

因为 QUIC 本身就已经支持了加密、流和多路复用，所以 HTTP/3 的工作减轻了很多，把流控制都交给 QUIC 去做。调用的不再是 TLS 的安全接口，也不是 Socket API，而是专门的 QUIC 函数。不过这个”QUIC 函数”还没有形成标准，必须要绑定到某一个具体的实现库。

HTTP/3 里仍然使用流来发送”请求 - 响应”，但它自身不需要像 HTTP/2 那样再去定义流，而是直接使用 QUIC 的流，相当于做了一个”概念映射”。

HTTP/3 里的”双向流”可以完全对应到 HTTP/2 的流，而”单向流”在 HTTP/3 里用来实现控制和推送，近似地对应 HTTP/2 的 0 号流。

由于流管理被”下放”到了 QUIC，所以 HTTP/3 里帧的结构也变简单了。

帧头只有两个字段：类型和长度，而且同样都采用变长编码，最小只需要两个字节。

HTTP/3 里的帧仍然分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧传输数据，但其他一些帧因为在下层的 QUIC 里有了替代，所以在 HTTP/3 里就都消失了，比如 RST_STREAM、WINDOW_UPDATE、PING 等。

头部压缩算法在 HTTP/3 里升级成了”QPACK”，使用方式上也做了改变。虽然也分成静态表和动态表，但在流上发送 HEADERS 帧时不能更新字段，只能引用，索引表的更新需要在专门的单向流上发送指令来管理，解决了 HPACK 的”队头阻塞”问题。

另外，QPACK 的字典也做了优化，静态表由之前的 61 个增加到了 98 个，而且序号从 0 开始，也就是说”:authority”的编号是 0。

HTTP/3 服务发现

讲了这么多，不知道你注意到了没有：HTTP/3 没有指定默认的端口号，也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。

那么，该怎么”发现”HTTP/3 呢？

这就要用到 HTTP/2 里的”扩展帧”了。浏览器需要先用 HTTP/2 协议连接服务器，然后服务器可以在启动 HTTP/2 连接后发送一个”Alt-Svc”帧，包含一个”h3=host:port”的字符串，告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。

浏览器收到”Alt-Svc”帧，会使用 QUIC 异步连接指定的端口，如果连接成功，就会断开 HTTP/2 连接，改用新的 HTTP/3 收发数据。

课外小贴士

1. 根据当前的标准草案，QUIC 已经不再是”Quick UDP Internet Connections”(快速UDP 互联网连接)的缩写了，”QUIC”就是”QUIC”
2. QUIC 早期还有一个”前向纠错”(ForwardError Correction)的特性，通过发送 xor 冗余数据来实现数据校验和恢复，但目前此特性已经被”搁置”，也许会在以后的版本里出现。
3. QUIC 虽然是个传输层协议，但它并不由操作系统内核实现，而是运行在用户空间，所以能够不受操作系统的限制，快速迭代演化，有点像 Intel 的 DPDK。
4. QUIC 里的包分为”长包”和”短包”两类,”长包”的第一个字节高位是1，格式比较完整，而短包只有目标连接 ID。
5. QUIC 和 HTTP/3 的变长编码使用第一个字节的高两位决定整数的长度，最多是8个字节(64 位)，所以最大值是 2^62。
6. HTTP/3 的帧不再需要 END HEADERS 标志位和 CONTINUATION 帧，因为帧的长度足够大(2^62)，无论是多大的头都可以用一个帧传输。

我应该迁移到HTTP2吗

HTTP/2 的优点

1. 完全保持了与 HTTP/1 的兼容
2. 在安全上，HTTP/2 对 HTTPS 在各方面都做了强化。下层的 TLS 至少是 1.2，而且只能使用前向安全的密码套件（即 ECDHE），这同时也就默认实现了”TLS False Start”，支持 1-RTT 握手，所以不需要再加额外的配置就可以自动实现 HTTPS 加速。
3. 与 HTTP/1”并发多个连接”不同，HTTP/2 的”多路复用”特性要求对一个域名（或者 IP）只用一个 TCP 连接，所有的数据都在这一个连接上传输，这样不仅节约了客户端、服务器和网络的资源，还可以把带宽跑满，让 TCP 充分”吃饱”。
4. 支持”优先级”和”服务器推送”

HTTP/2 的缺点

1. 在 TCP 级别还是存在”队头阻塞”的问题
2. 在移动网络中发生 IP 地址切换的时候，下层的 TCP 必须重新建连，要再次”握手”，经历”慢启动”，而且之前连接里积累的 HPACK 字典也都消失了，必须重头开始计算，导致带宽浪费和时延。
3. HTTP/2 对一个域名只开一个连接，所以一旦这个连接出问题，那么整个网站的体验也就变差了。

应用层协议协商（ALPN）

最后说一下 HTTP/2 的”服务发现”吧。

你有没有想过，在 URI 里用的都是 HTTPS 协议名，没有版本标记，浏览器怎么知道服务器支持 HTTP/2 呢？为什么上来就能用 HTTP/2，而不是用 HTTP/1 通信呢？

答案在 TLS 的扩展里，有一个叫”ALPN”（Application Layer Protocol Negotiation）的东西，用来与服务器就 TLS 上跑的应用协议进行”协商”。

客户端在发起”Client Hello”握手的时候，后面会带上一个”ALPN”扩展，里面按照优先顺序列出客户端支持的应用协议。

就像下图这样，最优先的是”h2”，其次是”http/1.1”，以前还有”spdy”，以后还可能会有”h3”。

服务器看到 ALPN 扩展以后就可以从列表里选择一种应用协议，在”Server Hello”里也带上”ALPN”扩展，告诉客户端服务器决定使用的是哪一种。因为我们在 Nginx 配置里使用了 HTTP/2 协议，所以在这里它选择的就是”h2”。

这样在 TLS 握手结束后，客户端和服务器就通过”ALPN”完成了应用层的协议协商，后面就可以使用 HTTP/2 通信了。

课外小贴士

1. Nginx 也支持明文形式的 HTTP/2(即”h2c”)在配置”listen”指令时不添加”ss!”参数即可但无法使用 Chrome等浏览器直接测试，因为浏览器只支持”h2”。
2. HTTP/2 的优先级只使用一个字节，优先级最低是 0，最高是 255，一些过时的书刊和网上资料中把 HTTP/2 的优先级写成了 2^31，是非常错误的。
3. ALPN 的前身是 Google 的 NPN(NextProtocol Negotiation)，它与 ALPN 的协商过程刚好相反，服务器提供支持的协议列表，由客户端决定最终使用的协议。
4. 明文的 HTTP/2(“h2c”)不使用 TLS，也就无法使用 ALPN 进行”协议协商”，所以需要使用头字段”Connection: Upgrade”升级到HTTP/2，服务器返回状态码 101切换协议。
5. 目前国内已经有不少大网站迁移到了 HTTP/2,比如www.qq.com、www.tmall.com，你可以用 Chrome的开发者工具检查它们的 Protocol。

Nginx

进程池

你也许听说过，Nginx 是个”轻量级”的 Web 服务器，那么这个所谓的”轻量级”是什么意思呢？

“轻量级”是相对于”重量级”而言的。”重量级”就是指服务器进程很”重”，占用很多资源，当处理 HTTP 请求时会消耗大量的 CPU 和内存，受到这些资源的限制很难提高性能。

而 Nginx 作为”轻量级”的服务器，它的 CPU、内存占用都非常少，同样的资源配置下就能够为更多的用户提供服务，其奥秘在于它独特的工作模式。

在 Nginx 之前，Web 服务器的工作模式大多是”Per-Process”或者”Per-Thread”，对每一个请求使用单独的进程或者线程处理。这就存在创建进程或线程的成本，还会有进程、线程”上下文切换”的额外开销。如果请求数量很多，CPU 就会在多个进程、线程之间切换时”疲于奔命”，平白地浪费了计算时间。

Nginx 则完全不同，”一反惯例”地没有使用多线程，而是使用了”进程池 + 单线程”的工作模式。

Nginx 在启动的时候会预先创建好固定数量的 worker 进程，在之后的运行过程中不会再 fork 出新进程，这就是进程池，而且可以自动把进程”绑定”到独立的 CPU 上，这样就完全消除了进程创建和切换的成本，能够充分利用多核 CPU 的计算能力。

在进程池之上，还有一个”master”进程，专门用来管理进程池。它的作用有点像是 supervisor（一个用 Python 编写的进程管理工具），用来监控进程，自动恢复发生异常的 worker，保持进程池的稳定和服务能力。

不过 master 进程完全是 Nginx 自行用 C 语言实现的，这就摆脱了外部的依赖，简化了 Nginx 的部署和配置。

I/O 多路复用

Nginx 利用了 Linux 内核里的一件”神兵利器”，I/O 多路复用接口，”大名鼎鼎”的 epoll。

多阶段处理

有了”进程池”和”I/O 多路复用”，Nginx 是如何处理 HTTP 请求的呢？

Nginx 在内部也采用的是”化整为零”的思路，把整个 Web 服务器分解成了多个”功能模块”，就好像是乐高积木，可以在配置文件里任意拼接搭建，从而实现了高度的灵活性和扩展性。

Nginx 的 HTTP 处理有四大类模块：

handler 模块：直接处理 HTTP 请求；
filter 模块：不直接处理请求，而是加工过滤响应报文；
upstream 模块：实现反向代理功能，转发请求到其他服务器；
balance 模块：实现反向代理时的负载均衡算法。
因为 upstream 模块和 balance 模块实现的是代理功能，Nginx 作为”中间人”，运行机制比较复杂，所以我今天只讲 handler 模块和 filter 模块。

不知道你有没有了解过”设计模式”这方面的知识，其中有一个非常有用的模式叫做”职责链”。它就好像是工厂里的流水线，原料从一头流入，线上有许多工人会进行各种加工处理，最后从另一头出来的就是完整的产品。

Nginx 里的 handler 模块和 filter 模块就是按照”职责链”模式设计和组织的，HTTP 请求报文就是”原材料”，各种模块就是工厂里的工人，走完模块构成的”流水线”，出来的就是处理完成的响应报文。

下面的这张图显示了 Nginx 的”流水线”，在 Nginx 里的术语叫”阶段式处理”（Phases），一共有 11 个阶段，每个阶段里又有许多各司其职的模块。

我简单列几个与我们的课程相关的模块吧：

1. charset 模块实现了字符集编码转换；（[第 15 讲]）
2. chunked 模块实现了响应数据的分块传输；（[第 16 讲]）
3. range 模块实现了范围请求，只返回数据的一部分；（[第 16 讲]）
4. rewrite 模块实现了重定向和跳转，还可以使用内置变量自定义跳转的 URI；（[第 18 讲]）
5. not_modified 模块检查头字段”if-Modified-Since”和”If-None-Match”，处理条件请求；（[第 20 讲]）
6. realip 模块处理”X-Real-IP””X-Forwarded-For”等字段，获取客户端的真实 IP 地址；（[第 21 讲]）
7. ssl 模块实现了 SSL/TLS 协议支持，读取磁盘上的证书和私钥，实现 TLS 握手和 SNI、ALPN 等扩展功能；（[安全篇]）
8. http_v2 模块实现了完整的 HTTP/2 协议。（[飞翔篇]）

在这张图里，你还可以看到 limit_conn、limit_req、access、log 等其他模块，它们实现的是限流限速、访问控制、日志等功能，不在 HTTP 协议规定之内，但对于运行在现实世界的 Web 服务器却是必备的。

课外小贴士

1. Nginx 自 1.7.11 开始引入了”多线程”，但只是作为辅助手段，卸载阻塞的磁盘 //O 操作，主要的 HTTP 请求处理使用的还是单线程里的epoll。
2. Nginx 的”PRECONTENT”阶段在 1.13.3 之前叫”TRY_FILES”，仅供 Nginx 内部使用，用户不可介入。
3. 正文里的”流水线”图没有画出 hlter 模块所在的位置，它其实是在 CONTENT 阶段的末尾专门”过滤”响应数据。

OpenResty

OpenResty 是什么？

OpenResty 并不是一个全新的 Web 服务器，而是基于 Nginx，它利用了 Nginx 模块化、可扩展的特性，开发了一系列的增强模块，并把它们打包整合，形成了一个”一站式”的 Web 开发平台。

虽然 OpenResty 的核心是 Nginx，但它又超越了 Nginx，关键就在于其中的 ngx_lua 模块，把小巧灵活的 Lua 语言嵌入了 Nginx，可以用脚本的方式操作 Nginx 内部的进程、多路复用、阶段式处理等各种构件。

目前 OpenResty 有两个分支，分别是开源、免费的”OpenResty”和闭源、商业产品的”OpenResty+”，运作方式有社区支持、OpenResty 基金会、OpenResty.Inc 公司，还有其他的一些外界赞助（例如 Kong、CloudFlare），正在蓬勃发展。

顺便说一下 OpenResty 的官方 logo，是一只展翅飞翔的海鸥，选择海鸥是因为”鸥”与 OpenResty 的发音相同。另外，这个 logo 的形状也像是左手比出的一个”OK”姿势，正好也是一个”O”。

高效率的 Lua

OpenResty 能够高效运行的一大”秘技”是它的”同步非阻塞”编程范式，如果你要开发 OpenResty 应用就必须时刻铭记于心。

“同步非阻塞”本质上还是一种”多路复用”，我拿上一讲的 Nginx epoll 来对比解释一下。

epoll 是操作系统级别的”多路复用”，运行在内核空间。而 OpenResty 的”同步非阻塞”则是基于 Lua 内建的”协程”，是应用程序级别的”多路复用”，运行在用户空间，所以它的资源消耗要更少。

OpenResty 里每一段 Lua 程序都由协程来调度运行。和 Linux 的 epoll 一样，每当可能发生阻塞的时候”协程”就会立刻切换出去，执行其他的程序。这样单个处理流程是”阻塞”的，但整个 OpenResty 却是”非阻塞的”，多个程序都”复用”在一个 Lua 虚拟机里运行。

下面的代码是一个简单的例子，读取 POST 发送的 body 数据，然后再发回客户端：

ngx.req.read_body()                  -- 同步非阻塞 (1)

local data = ngx.req.get_body_data()
if data then
    ngx.print("body: ", data)        -- 同步非阻塞 (2)
end

代码中的”ngx.req.read_body”和”ngx.print”分别是数据的收发动作，只有收到数据才能发送数据，所以是”同步”的。

但即使因为网络原因没收到或者发不出去，OpenResty 也不会在这里阻塞”干等着”，而是做个”记号”，把等待的这段 CPU 时间用来处理其他的请求，等网络可读或者可写时再”回来”接着运行。

假设收发数据的等待时间是 10 毫秒，而真正 CPU 处理的时间是 0.1 毫秒，那么 OpenResty 就可以在这 10 毫秒内同时处理 100 个请求，而不是把这 100 个请求阻塞排队，用 1000 毫秒来处理。

除了”同步非阻塞”，OpenResty 还选用了LuaJIT作为 Lua 语言的”运行时（Runtime）”，进一步”挖潜增效”。

LuaJIT 是一个高效的 Lua 虚拟机，支持 JIT（Just In Time）技术，可以把 Lua 代码即时编译成”本地机器码”，这样就消除了脚本语言解释运行的劣势，让 Lua 脚本跑得和原生 C 代码一样快。

另外，LuaJIT 还为 Lua 语言添加了一些特别的增强，比如二进制位运算库 bit，内存优化库 table，还有 FFI（Foreign Function Interface），让 Lua 直接调用底层 C 函数，比原生的压栈调用快很多。

阶段式处理

和 Nginx 一样，OpenResty 也使用”流水线”来处理 HTTP 请求，底层的运行基础是 Nginx 的”阶段式处理”，但它又有自己的特色。

Nginx 的”流水线”是由一个个 C 模块组成的，只能在静态文件里配置，开发困难，配置麻烦（相对而言）。而 OpenResty 的”流水线”则是由一个个的 Lua 脚本组成的，不仅可以从磁盘上加载，也可以从 Redis、MySQL 里加载，而且编写、调试的过程非常方便快捷。

下面我画了一张图，列出了 OpenResty 的阶段，比起 Nginx，OpenResty 的阶段更注重对 HTTP 请求响应报文的加工和处理。

OpenResty 里有几个阶段与 Nginx 是相同的，比如 rewrite、access、content、filter，这些都是标准的 HTTP 处理。

在这几个阶段里可以用”xxx_by_lua”指令嵌入 Lua 代码，执行重定向跳转、访问控制、产生响应、负载均衡、过滤报文等功能。因为 Lua 的脚本语言特性，不用考虑内存分配、资源回收释放等底层的细节问题，可以专注于编写非常复杂的业务逻辑，比 C 模块的开发效率高很多，即易于扩展又易于维护。

OpenResty 里还有两个不同于 Nginx 的特殊阶段。

一个是”init 阶段”，它又分成”master init”和”worker init”，在 master 进程和 worker 进程启动的时候运行。这个阶段还没有开始提供服务，所以慢一点也没关系，可以调用一些阻塞的接口初始化服务器，比如读取磁盘、MySQL，加载黑白名单或者数据模型，然后放进共享内存里供运行时使用。

另一个是”ssl 阶段”，这算得上是 OpenResty 的一大创举，可以在 TLS 握手时动态加载证书，或者发送”OCSP Stapling”。

还记得[第 29 讲]里说的”SNI 扩展”吗？Nginx 可以依据”服务器名称指示”来选择证书实现 HTTPS 虚拟主机，但静态配置很不灵活，要编写很多雷同的配置块。虽然后来 Nginx 增加了变量支持，但它每次握手都要读磁盘，效率很低。

而在 OpenResty 里就可以使用指令”ssl_certificate_by_lua”，编写 Lua 脚本，读取 SNI 名字后，直接从共享内存或者 Redis 里获取证书。不仅没有读盘阻塞，而且证书也是完全动态可配置的，无需修改配置文件就能够轻松支持大量的 HTTPS 虚拟主机。

课外小贴士

1. Nginx 自己也意识到了静态配置文件的缺点所以引入了 JavaScript 作为可编程配置脚本实现了一定程度上的的动态配置，另外还单独开发了类似 Envoy 的全动态应用服务器”Nginx Unit”.
2. OpenResty其实还有一个”官方”的中文名字,叫”鸥锐”，来自于 OpenResty 的谐音，但知道的人很少，用的人就更少了。
3. OpenResty 还提供一个命令行工具”resty”可以解释运行 Lua 代码，利用它就能够写出比肩 Shell、Python、Perl 的高效脚本，而且100% 无阻塞。
4. 在 OpenResty 1.13.6.2 之前，LuaJIT 的虚拟机最多只能使用 2GB 内存，如果操作超长字符串就很容易发生内存分配失败错误。现在的OpenResty默认启用了新的”GC64”模式，内存的上限是 128TB。
5. 你还可以对比着 Node.js 来理解 OpenResty。Node.js 也是一个应用服务开发平台，使用的是脚本语言 JavaScript，运行在 V8 虚拟机上下层的支撑平台 libuv 利用 epol 实现了高性能,

WAF

网络应用防火墙

“网络应用防火墙”（Web Application Firewall），简称为”WAF”。

你可能对传统的”防火墙”比较熟悉。传统”防火墙”工作在三层或者四层，隔离了外网和内网，使用预设的规则，只允许某些特定 IP 地址和端口号的数据包通过，拒绝不符合条件的数据流入或流出内网，实质上是一种网络数据过滤设备。

WAF 也是一种”防火墙”，但它工作在七层，看到的不仅是 IP 地址和端口号，还能看到整个 HTTP 报文，所以就能够对报文内容做更深入细致的审核，使用更复杂的条件、规则来过滤数据。

说白了，WAF 就是一种”HTTP 入侵检测和防御系统”。

通常一款产品能够称为 WAF，要具备下面的一些功能：

1. IP 黑名单和白名单，拒绝黑名单上地址的访问，或者只允许白名单上的用户访问；
2. URI 黑名单和白名单，与 IP 黑白名单类似，允许或禁止对某些 URI 的访问；
3. 防护 DDoS 攻击，对特定的 IP 地址限连限速；
4. 过滤请求报文，防御”代码注入”攻击；
5. 过滤响应报文，防御敏感信息外泄；
6. 审计日志，记录所有检测到的入侵操作。

听起来 WAF 好像很高深，但如果你理解了它的工作原理，其实也不难。

它就像是平时编写程序时必须要做的函数入口参数检查，拿到 HTTP 请求、响应报文，用字符串处理函数看看有没有关键字、敏感词，或者用正则表达式做一下模式匹配，命中了规则就执行对应的动作，比如返回 403/404。

如果你比较熟悉 Apache、Nginx、OpenResty，可以自己改改配置文件，写点 JS 或者 Lua 代码，就能够实现基本的 WAF 功能。

比如说，在 Nginx 里实现 IP 地址黑名单，可以利用”map”指令，从变量 $remote_addr 获取 IP 地址，在黑名单上就映射为值 1，然后在”if”指令里判断：

map $remote_addr $blocked {
    default       0;
    "1.2.3.4"     1;
    "5.6.7.8"     1;
}
 
 
if ($blocked) {
    return 403 "you are blocked.";  
}

Nginx 的配置文件只能静态加载，改名单必须重启，比较麻烦。如果换成 OpenResty 就会非常方便，在 access 阶段进行判断，IP 地址列表可以使用 cosocket 连接外部的 Redis、MySQL 等数据库，实现动态更新：

local ip_addr = ngx.var.remote_addr

local rds = redis:new()
if rds:get(ip_addr) == 1 then 
    ngx.exit(403) 
end

全面的 WAF 解决方案

介绍一下 WAF 领域里的最顶级产品了：ModSecurity，它可以说是 WAF 界”事实上的标准”。

ModSecurity 是一个开源的、生产级的 WAF 工具包，历史很悠久，比 Nginx 还要大几岁。它开始于一个私人项目，后来被商业公司 Breach Security 收购，现在则是由 TrustWave 公司的 SpiderLabs 团队负责维护。

ModSecurity 最早是 Apache 的一个模块，只能运行在 Apache 上。因为其品质出众，大受欢迎，后来的 2.x 版添加了 Nginx 和 IIS 支持，但因为底层架构存在差异，不够稳定。

所以，这两年 SpiderLabs 团队就开发了全新的 3.0 版本，移除了对 Apache 架构的依赖，使用新的”连接器”来集成进 Apache 或者 Nginx，比 2.x 版更加稳定和快速，误报率也更低。

ModSecurity 有两个核心组件。第一个是”规则引擎”，它实现了自定义的”SecRule”语言，有自己特定的语法。但”SecRule”主要基于正则表达式，还是不够灵活，所以后来也引入了 Lua，实现了脚本化配置。

ModSecurity 的规则引擎使用 C++11 实现，可以从 GitHub 上下载源码，然后集成进 Nginx。因为它比较庞大，编译很费时间，所以最好编译成动态模块，在配置文件里用指令”load_module”加载：

load_module modules/ngx_http_modsecurity_module.so;

只有引擎还不够，要让引擎运转起来，还需要完善的防御规则，所以 ModSecurity 的第二个核心组件就是它的”规则集”。

ModSecurity 源码提供一个基本的规则配置文件”modsecurity.conf-recommended”，使用前要把它的后缀改成”conf”。

有了规则集，就可以在 Nginx 配置文件里加载，然后启动规则引擎：

modsecurity on;
modsecurity_rules_file /path/to/modsecurity.conf;

“modsecurity.conf”文件默认只有检测功能，不提供入侵阻断，这是为了防止误杀误报，把”SecRuleEngine”后面改成”On”就可以开启完全的防护：

#SecRuleEngine DetectionOnly
SecRuleEngine  On

基本的规则集之外，ModSecurity 还额外提供一个更完善的规则集，为网站提供全面可靠的保护。这个规则集的全名叫”OWASP ModSecurity 核心规则集”（Open Web Application Security Project ModSecurity Core Rule Set），因为名字太长了，所以有时候会简称为”核心规则集”或者”CRS”。

CRS 也是完全开源、免费的，可以从 GitHub 上下载：

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

其中有一个”crs-setup.conf.example”的文件，它是 CRS 的基本配置，可以用”Include”命令添加到”modsecurity.conf”里，然后再添加”rules”里的各种规则。

Include /path/to/crs-setup.conf
Include /path/to/rules/*.conf

你如果有兴趣可以看一下这些配置文件，里面用”SecRule”定义了很多的规则，基本的形式是”SecRule 变量 运算符 动作”。不过 ModSecurity 的这套语法”自成一体”，比较复杂，要完全掌握不是一朝一夕的事情，我就不详细解释了。

另外，ModSecurity 还有强大的审计日志（Audit Log）功能，记录任何可疑的数据，供事后离线分析。但在生产环境中会遇到大量的攻击，日志会快速增长，消耗磁盘空间，而且写磁盘也会影响 Nginx 的性能，所以一般建议把它关闭：

SecAuditEngine off  #RelevantOnly
SecAuditLog /var/log/modsec_audit.log

课外小贴士

1. “CC 攻击”(Challenge Collapsar)是”DDoS”的一种，它使用代理服务器发动攻击。
2. ModSecurity 名字里的”Mod”来源于 Apache扩展模块的命名惯例，例如”mod_php”mod_proxy””mod_cache”
3. ModSecurity 也使用了”阶段式处理”，所以可以很容易地融合进 Nginx，不过它只有5个阶段:request headers、request body.response headers、response body、logging.
4. TrustWave 公司还提供比”OWASP CRS”更高级更全面的规则集，叫”TrustwaveSpiderLabs Rules”，但它是商业产品，必须购买后才能使用。
5. 在 Nginx 上还可以使用另一个 WAF 模块:Naxsi，虽然它的功能也很强大，但与ModSecurity 并不兼容。
6. OpenResty生态系统里也已经有了多个比较成熟的纯 Lua WAF，可以在 GitHub 上搜索关键词”ngx lua waf”，而商业版的 OpenResty+则基于 ModSecurity的核心规则集，使用 Lua重新实现了一套自有引擎。

CDN

WebSocket

WebSocket 的帧结构

WebSocket 用的也是二进制帧，有之前 HTTP/2、HTTP/3 的经验，相信你这次也能很快掌握 WebSocket 的报文结构。

不过 WebSocket 和 HTTP/2 的关注点不同，WebSocket 更侧重于”实时通信”，而 HTTP/2 更侧重于提高传输效率，所以两者的帧结构也有很大的区别。

WebSocket 虽然有”帧”，但却没有像 HTTP/2 那样定义”流”，也就不存在”多路复用””优先级”等复杂的特性，而它自身就是”全双工”的，也就不需要”服务器推送”。所以综合起来，WebSocket 的帧学习起来会简单一些。

下图就是 WebSocket 的帧结构定义，长度不固定，最少 2 个字节，最多 14 字节，看着好像很复杂，实际非常简单。

开头的两个字节是必须的，也是最关键的。

第一个字节的第一位”FIN”是消息结束的标志位，相当于 HTTP/2 里的”END_STREAM”，表示数据发送完毕。一个消息可以拆成多个帧，接收方看到”FIN”后，就可以把前面的帧拼起来，组成完整的消息。

“FIN”后面的三个位是保留位，目前没有任何意义，但必须是 0。

第一个字节的后 4 位很重要，叫”Opcode”，操作码，其实就是帧类型，比如 1 表示帧内容是纯文本，2 表示帧内容是二进制数据，8 是关闭连接，9 和 10 分别是连接保活的 PING 和 PONG。

第二个字节第一位是掩码标志位”MASK”，表示帧内容是否使用异或操作（xor）做简单的加密。目前的 WebSocket 标准规定，客户端发送数据必须使用掩码，而服务器发送则必须不使用掩码。

第二个字节后 7 位是”Payload len”，表示帧内容的长度。它是另一种变长编码，最少 7 位，最多是 7+64 位，也就是额外增加 8 个字节，所以一个 WebSocket 帧最大是 2^64。

长度字段后面是”Masking-key”，掩码密钥，它是由上面的标志位”MASK”决定的，如果使用掩码就是 4 个字节的随机数，否则就不存在。

这么分析下来，其实 WebSocket 的帧头就四个部分：”结束标志位 + 操作码 + 帧长度 + 掩码”，只是使用了变长编码的”小花招”，不像 HTTP/2 定长报文头那么简单明了。

我们的实验环境利用 OpenResty 的”lua-resty-websocket”库，实现了一个简单的 WebSocket 通信，你可以访问 URI”/38-1”，它会连接后端的 WebSocket 服务”ws://127.0.0.1⁄38-0”，用 Wireshark 抓包就可以看到 WebSocket 的整个通信过程。

下面的截图是其中的一个文本帧，因为它是客户端发出的，所以需要掩码，报文头就在两个字节之外多了四个字节的”Masking-key”，总共是 6 个字节。

而报文内容经过掩码，不是直接可见的明文，但掩码的安全强度几乎是零，用”Masking-key”简单地异或一下就可以转换出明文。

WebSocket 的握手

和 TCP、TLS 一样，WebSocket 也要有一个握手过程，然后才能正式收发数据。

这里它还是搭上了 HTTP 的”便车”，利用了 HTTP 本身的”协议升级”特性，”伪装”成 HTTP，这样就能绕过浏览器沙盒、网络防火墙等等限制，这也是 WebSocket 与 HTTP 的另一个重要关联点。

WebSocket 的握手是一个标准的 HTTP GET 请求，但要带上两个协议升级的专用头字段：

• “Connection: Upgrade”，表示要求协议”升级”；
• “Upgrade: websocket”，表示要”升级”成 WebSocket 协议。

另外，为了防止普通的 HTTP 消息被”意外”识别成 WebSocket，握手消息还增加了两个额外的认证用头字段（所谓的”挑战”，Challenge）：

• Sec-WebSocket-Key：一个 Base64 编码的 16 字节随机数，作为简单的认证密钥；
• Sec-WebSocket-Version：协议的版本号，当前必须是 13。

服务器收到 HTTP 请求报文，看到上面的四个字段，就知道这不是一个普通的 GET 请求，而是 WebSocket 的升级请求，于是就不走普通的 HTTP 处理流程，而是构造一个特殊的”101 Switching Protocols”响应报文，通知客户端，接下来就不用 HTTP 了，全改用 WebSocket 协议通信。（有点像 TLS 的”Change Cipher Spec”）

WebSocket 的握手响应报文也是有特殊格式的，要用字段”Sec-WebSocket-Accept”验证客户端请求报文，同样也是为了防止误连接。

具体的做法是把请求头里”Sec-WebSocket-Key”的值，加上一个专用的 UUID “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，再计算 SHA-1 摘要。

encode_base64(sha1(Sec-WebSocket-Key + '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'))

客户端收到响应报文，就可以用同样的算法，比对值是否相等，如果相等，就说明返回的报文确实是刚才握手时连接的服务器，认证成功。

握手完成，后续传输的数据就不再是 HTTP 报文，而是 WebSocket 格式的二进制帧了。

课外小贴士

1. WebSocket 标准诞生于 2011年，比 HTTP/2要大上四岁。
2. 最早 WebSocket 只能从 HTTP/1.1升级，因为HTTP/2 取消了”Connection”头字段和协议升级机制，不能跑在 HTTP/2 上，所以就有草案提议扩展 HTTP/2 支持 WebSocket，后来形成了 RFC8441。
3. 虽然 WebSocket 完全借用了 HTTP 的 URI 形式，但也有一点小小的不兼容:不支持 URI后面的”#”片段标识”#”必须被编码为”%23”
4. WebSocket 强制要求客户端发送数据必须使用掩码，这是为了提供最基本的安全防护，让每次发送的消息都是随机、不可预测的，抵御”缓存中毒”攻击。但如果运行在 SSL/TLS 上,采用加密通信，那么掩码就没有必要了。
5. WebSocket 协议里的 PING、PONG 帧对于保持长连接很重要，可以让链路上总有数据在传输，防止被服务器、路由、网关认为是”无效连接”而意外关闭。

HTTP性能优化面面观

HTTP 服务器

衡量服务器性能的主要指标有三个：吞吐量（requests per second）、并发数（concurrency）和响应时间（time per request）。

HTTP 客户端

Chrome 等浏览器自带的开发者工具也可以很好地观察客户端延迟指标，面板左边有每个 URI 具体消耗的时间，面板的右边也是类似的瀑布图。

点击某个 URI，在 Timing 页里会显示出一个小型的”瀑布图”，是这个资源消耗时间的详细分解，延迟的原因都列的清清楚楚，比如下面的这张图：

图里面的这些指标都是什么含义呢？我给你解释一下：

1. 因为有”队头阻塞”，浏览器对每个域名最多开 6 个并发连接（HTTP/1.1），当页面里链接很多的时候就必须排队等待（Queued、Queueing），这里它就等待了 1.62 秒，然后才被浏览器正式处理；
2. 浏览器要预先分配资源，调度连接，花费了 11.56 毫秒（Stalled）;
3. 连接前必须要解析域名，这里因为有本地缓存，所以只消耗了 0.41 毫秒（DNS Lookup）；
4. 与网站服务器建立连接的成本很高，总共花费了 270.87 毫秒，其中有 134.89 毫秒用于 TLS 握手，那么 TCP 握手的时间就是 135.98 毫秒（Initial connection、SSL）；
5. 实际发送数据非常快，只用了 0.11 毫秒（Request sent）；
6. 之后就是等待服务器的响应，专有名词叫 TTFB（Time To First Byte），也就是”首字节响应时间”，里面包括了服务器的处理时间和网络传输时间，花了 124.2 毫秒；
7. 接收数据也是非常快的，用了 3.58 毫秒（Content Dowload）。

从这张图你可以看到，一次 HTTP”请求 - 响应”的过程中延迟的时间是非常惊人的，总时间 415.04 毫秒里占了差不多 99%。

所以，客户端 HTTP 性能优化的关键就是：降低延迟。

课外小贴士

1. 在 Chrome 开发者工具的瀑布图里可以看到有两条蓝色和红色的竖线。蓝线表示的是”DOMReady”，也就是说浏览器已经解析完 HTML文档的 DOM 结构;红线表示的是”LoadComplete”，即已经下载完页面包含的所有资源(JS、CSS、图片等)。
2. Nginx 默认不支持 br 压缩算法，需要安装一个第三方模块 ngx_brotli。