（建议精读）HTTP灵魂之问，巩固你的 HTTP 知识体系

上回就已经承诺过你们，必定会出 HTTP 的系列文章，今天终于整理完成了。做为一个 web 开发，HTTP 几乎是每天要打交道的东西，但我发现大部分人对 HTTP 只是浅尝辄止，对更多的细节及原理就了解不深了，在面试的时候感受很是吃力。这篇文章就是为了帮助你们树立完整的 HTTP 知识体系，并达到必定的深度，从容地应对各类灵魂之问，也同时提高本身做为一个 web 开发的专业素养吧。这是本文的思惟导图:javascript

001. HTTP 报文结构是怎样的？

对于 TCP 而言，在传输的时候分为两个部分:TCP头和数据部分。css

而 HTTP 相似，也是header + body的结构，具体而言:html

起始行 + 头部 + 空行 + 实体

因为 http 请求报文和响应报文是有必定区别，所以咱们分开介绍。前端

起始行

对于请求报文来讲，起始行相似下面这样:java

GET /home HTTP/1.1

也就是方法 + 路径 + http版本。node

对于响应报文来讲，起始行通常张这个样:web

HTTP/1.1 200 OK

响应报文的起始行也叫作状态行。由http版本、状态码和缘由三部分组成。面试

值得注意的是，在起始行中，每两个部分之间用空格隔开，最后一个部分后面应该接一个换行，严格遵循ABNF语法规范。算法

头部

展现一下请求头和响应头在报文中的位置:chrome

无论是请求头仍是响应头，其中的字段是至关多的，并且牵扯到http很是多的特性，这里就不一一列举的，重点看看这些头部字段的格式：

字段名不区分大小写

字段名不容许出现空格，不能够出现下划线 _

字段名后面必须 紧接着:

空行

很重要，用来区分开头部和实体。

问: 若是说在头部中间故意加一个空行会怎么样？

那么空行后的内容所有被视为实体。

实体

就是具体的数据了，也就是body部分。请求报文对应请求体, 响应报文对应响应体。

002. 如何理解 HTTP 的请求方法？

有哪些请求方法？

http/1.1规定了如下请求方法(注意，都是大写):

GET: 一般用来获取资源
HEAD: 获取资源的元信息
POST: 提交数据，即上传数据
PUT: 修改数据
DELETE: 删除资源(几乎用不到)
CONNECT: 创建链接隧道，用于代理服务器
OPTIONS: 列出可对资源实行的请求方法，用来跨域请求
TRACE: 追踪请求-响应的传输路径

GET 和 POST 有什么区别？

首先最直观的是语义上的区别。

然后又有这样一些具体的差异:

从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
从参数的角度，GET 通常放在 URL 中，所以不安全，POST 放在请求体中，更适合传输敏感信息。
从 幂等性的角度， GET是幂等的，而 POST不是。( 幂等表示执行相同的操做，结果也是相同的)
从 TCP的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，若是服务器响应 100(continue)，而后发 body 部分。( 火狐浏览器除外，它的 POST 请求只发一个 TCP 包)

003: 如何理解 URI？

URI, 全称为(Uniform Resource Identifier), 也就是统一资源标识符，它的做用很简单，就是区分互联网上不一样的资源。

可是，它并非咱们常说的网址, 网址指的是URL, 实际上URI包含了URN和URL两个部分，因为 URL 过于普及，就默认将 URI 视为 URL 了。

URI 的结构

URI 真正最完整的结构是这样的。

可能你会有疑问，好像跟平时见到的不太同样啊！先别急，咱们来一一拆解。

scheme 表示协议名，好比http, https, file等等。后面必须和://连在一块儿。

user:passwd@ 表示登陆主机时的用户信息，不过很不安全，不推荐使用，也不经常使用。

host:port表示主机名和端口。

path表示请求路径，标记资源所在位置。

query表示查询参数，为key=val这种形式，多个键值对之间用&隔开。

fragment表示 URI 所定位的资源内的一个锚点，浏览器能够根据这个锚点跳转到对应的位置。

举个例子:

https://www.baidu.com/s?wd=HTTP&rsv_spt=1

这个 URI 中，https即scheme部分，www.baidu.com为host:port部分（注意，http 和 https 的默认端口分别为80、443），/s为path部分，而wd=HTTP&rsv_spt=1就是query部分。

URI 编码

URI 只能使用ASCII, ASCII 以外的字符是不支持显示的，并且还有一部分符号是界定符，若是不加以处理就会致使解析出错。

所以，URI 引入了编码机制，将全部非 ASCII 码字符和界定符转为十六进制字节值，而后在前面加个%。

如，空格被转义成了%20，三元被转义成了%E4%B8%89%E5%85%83。

004: 如何理解 HTTP 状态码？

RFC 规定 HTTP 的状态码为三位数，被分为五类:

1xx: 表示目前是协议处理的中间状态，还须要后续操做。
2xx: 表示成功状态。
3xx: 重定向状态，资源位置发生变更，须要从新请求。
4xx: 请求报文有误。
5xx: 服务器端发生错误。

接下来就一一分析这里面具体的状态码。

1xx

101 Switching Protocols。在HTTP升级为WebSocket的时候，若是服务器赞成变动，就会发送状态码 101。

2xx

200 OK是见得最多的成功状态码。一般在响应体中放有数据。

204 No Content含义与 200 相同，但响应头后没有 body 数据。

206 Partial Content顾名思义，表示部份内容，它的使用场景为 HTTP 分块下载和断电续传，固然也会带上相应的响应头字段Content-Range。

3xx

301 Moved Permanently即永久重定向，对应着302 Found，即临时重定向。

好比你的网站从 HTTP 升级到了 HTTPS 了，之前的站点不再用了，应当返回301，这个时候浏览器默认会作缓存优化，在第二次访问的时候自动访问重定向的那个地址。

而若是只是暂时不可用，那么直接返回302便可，和301不一样的是，浏览器并不会作缓存优化。

304 Not Modified: 当协商缓存命中时会返回这个状态码。详见浏览器缓存

4xx

400 Bad Request: 开发者常常看到一头雾水，只是笼统地提示了一下错误，并不知道哪里出错了。

403 Forbidden: 这实际上并非请求报文出错，而是服务器禁止访问，缘由有不少，好比法律禁止、信息敏感。

404 Not Found: 资源未找到，表示没在服务器上找到相应的资源。

405 Method Not Allowed: 请求方法不被服务器端容许。

406 Not Acceptable: 资源没法知足客户端的条件。

408 Request Timeout: 服务器等待了太长时间。

409 Conflict: 多个请求发生了冲突。

413 Request Entity Too Large: 请求体的数据过大。

414 Request-URI Too Long: 请求行里的 URI 太大。

429 Too Many Request: 客户端发送的请求过多。

431 Request Header Fields Too Large请求头的字段内容太大。

5xx

500 Internal Server Error: 仅仅告诉你服务器出错了，出了啥错咱也不知道。

501 Not Implemented: 表示客户端请求的功能还不支持。

502 Bad Gateway: 服务器自身是正常的，但访问的时候出错了，啥错误咱也不知道。

503 Service Unavailable: 表示服务器当前很忙，暂时没法响应服务。

005: 简要归纳一下 HTTP 的特色？HTTP 有哪些缺点？

HTTP 特色

HTTP 的特色归纳以下:

灵活可扩展，主要体如今两个方面。一个是语义上的自由，只规定了基本格式，好比空格分隔单词，换行分隔字段，其余的各个部分都没有严格的语法限制。另外一个是传输形式的多样性，不只仅能够传输文本，还能传输图片、视频等任意数据，很是方便。
可靠传输。HTTP 基于 TCP/IP，所以把这一特性继承了下来。这属于 TCP 的特性，不具体介绍了。
请求-应答。也就是一发一收、有来有回，固然这个请求方和应答方不仅仅指客户端和服务器之间，若是某台服务器做为代理来链接后端的服务端，那么这台服务器也会扮演请求方的角色。
无状态。这里的状态是指通讯过程的上下文信息，而每次 http 请求都是独立、无关的，默认不须要保留状态信息。

HTTP 缺点

无状态

所谓的优势和缺点仍是要分场景来看的，对于 HTTP 而言，最具争议的地方在于它的无状态。

在须要长链接的场景中，须要保存大量的上下文信息，以避免传输大量重复的信息，那么这时候无状态就是 http 的缺点了。

但与此同时，另一些应用仅仅只是为了获取一些数据，不须要保存链接上下文信息，无状态反而减小了网络开销，成为了 http 的优势。

明文传输

即协议里的报文(主要指的是头部)不使用二进制数据，而是文本形式。

这固然对于调试提供了便利，但同时也让 HTTP 的报文信息暴露给了外界，给攻击者也提供了便利。WIFI陷阱就是利用 HTTP 明文传输的缺点，诱导你连上热点，而后疯狂抓你全部的流量，从而拿到你的敏感信息。

队头阻塞问题

当 http 开启长链接时，共用一个 TCP 链接，同一时刻只能处理一个请求，那么当前请求耗时过长的状况下，其它的请求只能处于阻塞状态，也就是著名的队头阻塞问题。接下来会有一小节讨论这个问题。

006: 对 Accept 系列字段了解多少？

对于Accept系列字段的介绍分为四个部分: 数据格式、压缩方式、支持语言和字符集。

数据格式

上一节谈到 HTTP 灵活的特性，它支持很是多的数据格式，那么这么多格式的数据一块儿到达客户端，客户端怎么知道它的格式呢？

固然，最低效的方式是直接猜，有没有更好的方式呢？直接指定能够吗？

答案是确定的。不过首先须要介绍一个标准——MIME(Multipurpose Internet Mail Extensions, 多用途互联网邮件扩展)。它首先用在电子邮件系统中，让邮件能够发任意类型的数据，这对于 HTTP 来讲也是通用的。

所以，HTTP 从MIME type取了一部分来标记报文 body 部分的数据类型，这些类型体如今Content-Type这个字段，固然这是针对于发送端而言，接收端想要收到特定类型的数据，也能够用Accept字段。

具体而言，这两个字段的取值能够分为下面几类:

text：text/html, text/plain, text/css 等
image: image/gif, image/jpeg, image/png 等
audio/video: audio/mpeg, video/mp4 等
application: application/json, application/javascript, application/pdf, application/octet-stream

压缩方式

固然通常这些数据都是会进行编码压缩的，采起什么样的压缩方式就体如今了发送方的Content-Encoding字段上，一样的，接收什么样的压缩方式体如今了接受方的Accept-Encoding字段上。这个字段的取值有下面几种：

gzip: 当今最流行的压缩格式
deflate: 另一种著名的压缩格式
br: 一种专门为 HTTP 发明的压缩算法

// 发送端
Content-Encoding: gzip
// 接收端
Accept-Encoding: gizp

支持语言

对于发送方而言，还有一个Content-Language字段，在须要实现国际化的方案当中，能够用来指定支持的语言，在接受方对应的字段为Accept-Language。如:

// 发送端
Content-Language: zh-CN, zh, en
// 接收端
Accept-Language: zh-CN, zh, en

字符集

最后是一个比较特殊的字段, 在接收端对应为Accept-Charset，指定能够接受的字符集，而在发送端并无对应的Content-Charset, 而是直接放在了Content-Type中，以charset属性指定。如:

// 发送端
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Charset: charset=utf-8

最后以一张图来总结一下吧:

007: 对于定长和不定长的数据，HTTP 是怎么传输的？

定长包体

对于定长包体而言，发送端在传输的时候通常会带上Content-Length, 来指明包体的长度。

咱们用一个nodejs服务器来模拟一下:

const http = require('http');

const server = http.createServer();

server.on('request', (req, res) => {
  if(req.url === '/') {
    res.setHeader('Content-Type', 'text/plain');
    res.setHeader('Content-Length', 10);
    res.write("helloworld");
  }
})

server.listen(8081, () => {
  console.log("成功启动");
})

启动后访问: localhost:8081。

浏览器中显示以下:

helloworld

这是长度正确的状况，那不正确的状况是如何处理的呢？

咱们试着把这个长度设置的小一些:

res.setHeader('Content-Length', 8);

重启服务，再次访问，如今浏览器中内容以下:

hellowor

那后面的ld哪里去了呢？实际上在 http 的响应体中直接被截去了。

而后咱们试着将这个长度设置得大一些:

res.setHeader('Content-Length', 12);

此时浏览器显示以下:

直接没法显示了。能够看到Content-Length对于 http 传输过程起到了十分关键的做用，若是设置不当能够直接致使传输失败。

不定长包体

上述是针对于定长包体，那么对于不定长包体而言是如何传输的呢？

这里就必须介绍另一个 http 头部字段了:

Transfer-Encoding: chunked

表示分块传输数据，设置这个字段后会自动产生两个效果:

Content-Length 字段会被忽略
基于长链接持续推送动态内容

咱们依然以一个实际的例子来模拟分块传输，nodejs 程序以下:

const http = require('http');

const server = http.createServer();

server.on('request', (req, res) => {
  if(req.url === '/') {
    res.setHeader('Content-Type', 'text/html; charset=utf8');
    res.setHeader('Content-Length', 10);
    res.setHeader('Transfer-Encoding', 'chunked');
    res.write("<p>来啦</p>");
    setTimeout(() => {
      res.write("第一次传输<br/>");
    }, 1000);
    setTimeout(() => {
      res.write("第二次传输");
      res.end()
    }, 2000);
  }
})

server.listen(8009, () => {
  console.log("成功启动");
})

访问效果入下:

用 telnet 抓到的响应以下:

注意，Connection: keep-alive及以前的为响应行和响应头，后面的内容为响应体，这两部分用换行符隔开。

响应体的结构比较有意思，以下所示:

chunk长度(16进制的数)
第一个chunk的内容
chunk长度(16进制的数)
第二个chunk的内容
......
0

最后是留有有一个空行的，这一点请你们注意。

以上即是 http 对于定长数据和不定长数据的传输方式。

008: HTTP 如何处理大文件的传输？

对于几百 M 甚至上 G 的大文件来讲，若是要一口气所有传输过来显然是不现实的，会有大量的等待时间，严重影响用户体验。所以，HTTP 针对这一场景，采起了范围请求的解决方案，容许客户端仅仅请求一个资源的一部分。

如何支持

固然，前提是服务器要支持范围请求，要支持这个功能，就必须加上这样一个响应头:

Accept-Ranges: none

用来告知客户端这边是支持范围请求的。

Range 字段拆解

而对于客户端而言，它须要指定请求哪一部分，经过Range这个请求头字段肯定，格式为bytes=x-y。接下来就来讨论一下这个 Range 的书写格式:

0-499表示从开始到第 499 个字节。
500- 表示从第 500 字节到文件终点。
-100表示文件的最后100个字节。

服务器收到请求以后，首先验证范围是否合法，若是越界了那么返回416错误码，不然读取相应片断，返回206状态码。

同时，服务器须要添加Content-Range字段，这个字段的格式根据请求头中Range字段的不一样而有所差别。

具体来讲，请求单段数据和请求多段数据，响应头是不同的。

举个例子:

// 单段数据
Range: bytes=0-9
// 多段数据
Range: bytes=0-9, 30-39

接下来咱们就分别来讨论着两种状况。

单段数据

对于单段数据的请求，返回的响应以下:

HTTP/1.1 206 Partial Content
Content-Length: 10
Accept-Ranges: bytes
Content-Range: bytes 0-9/100

i am xxxxx

值得注意的是Content-Range字段，0-9表示请求的返回，100表示资源的总大小，很好理解。

多段数据

接下来咱们看看多段请求的状况。获得的响应会是下面这个形式:

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


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

i am xxxxx
--00000010101
Content-Type: text/plain
Content-Range: bytes 20-29/96

eex jspy e
--00000010101--

这个时候出现了一个很是关键的字段Content-Type: multipart/byteranges;boundary=00000010101，它表明了信息量是这样的:

请求必定是多段数据请求
响应体中的分隔符是 00000010101

所以，在响应体中各段数据之间会由这里指定的分隔符分开，并且在最后的分隔末尾添上--表示结束。

以上就是 http 针对大文件传输所采用的手段。

009: HTTP 中如何处理表单数据的提交？

在 http 中，有两种主要的表单提交的方式，体如今两种不一样的Content-Type取值:

application/x-www-form-urlencoded
multipart/form-data

因为表单提交通常是POST请求，不多考虑GET，所以这里咱们将默认提交的数据放在请求体中。

application/x-www-form-urlencoded

对于application/x-www-form-urlencoded格式的表单内容，有如下特色:

其中的数据会被编码成以 &分隔的键值对
字符以 URL编码方式编码。

如：

// 转换过程: {a: 1, b: 2} -> a=1&b=2 -> 以下(最终形式)
"a%3D1%26b%3D2"

multipart/form-data

对于multipart/form-data而言:

请求头中的 Content-Type字段会包含 boundary，且 boundary的值有浏览器默认指定。例: Content-Type: multipart/form-data;boundary=----WebkitFormBoundaryRRJKeWfHPGrS4LKe。
数据会分为多个部分，每两个部分之间经过分隔符来分隔，每部分表述均有 HTTP 头部描述子包体，如 Content-Type，在最后的分隔符会加上 --表示结束。

相应的请求体是下面这样:

Content-Disposition: form-data;name="data1";
Content-Type: text/plain
data1
----WebkitFormBoundaryRRJKeWfHPGrS4LKe
Content-Disposition: form-data;name="data2";
Content-Type: text/plain
data2
----WebkitFormBoundaryRRJKeWfHPGrS4LKe--

小结

值得一提的是，multipart/form-data 格式最大的特色在于:每个表单元素都是独立的资源表述。另外，你可能在写业务的过程当中，并无注意到其中还有boundary的存在，若是你打开抓包工具，确实能够看到不一样的表单元素被拆分开了，之因此在平时感受不到，是觉得浏览器和 HTTP 给你封装了这一系列操做。

并且，在实际的场景中，对于图片等文件的上传，基本采用multipart/form-data而不用application/x-www-form-urlencoded，由于没有必要作 URL 编码，带来巨大耗时的同时也占用了更多的空间。

010: HTTP1.1 如何解决 HTTP 的队头阻塞问题？

什么是 HTTP 队头阻塞？

从前面的小节能够知道，HTTP 传输是基于请求-应答的模式进行的，报文必须是一发一收，但值得注意的是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是著名的HTTP队头阻塞问题。

并发链接

对于一个域名容许分配多个长链接，那么至关于增长了任务队列，不至于一个队伍的任务阻塞其它全部任务。在RFC2616规定过客户端最多并发 2 个链接，不过事实上在如今的浏览器标准中，这个上限要多不少，Chrome 中是 6 个。

但其实，即便是提升了并发链接，仍是不能知足人们对性能的需求。

域名分片

一个域名不是能够并发 6 个长链接吗？那我就多分几个域名。

好比 content1.sanyuan.com 、content2.sanyuan.com。

这样一个sanyuan.com域名下能够分出很是多的二级域名，而它们都指向一样的一台服务器，可以并发的长链接数更多了，事实上也更好地解决了队头阻塞的问题。

011: 对 Cookie 了解多少？

Cookie 简介

前面说到了 HTTP 是一个无状态的协议，每次 http 请求都是独立、无关的，默认不须要保留状态信息。但有时候须要保存一些状态，怎么办呢？

HTTP 为此引入了 Cookie。Cookie 本质上就是浏览器里面存储的一个很小的文本文件，内部以键值对的方式来存储(在chrome开发者面板的Application这一栏能够看到)。向同一个域名下发送请求，都会携带相同的 Cookie，服务器拿到 Cookie 进行解析，便能拿到客户端的状态。而服务端能够经过响应头中的Set-Cookie字段来对客户端写入Cookie。举例以下:

// 请求头
Cookie: a=xxx;b=xxx
// 响应头
Set-Cookie: a=xxx
set-Cookie: b=xxx

Cookie 属性

生存周期

Cookie 的有效期能够经过Expires和Max-Age两个属性来设置。

Expires即 过时时间
Max-Age用的是一段时间间隔，单位是秒，从浏览器收到报文开始计算。

若 Cookie 过时，则这个 Cookie 会被删除，并不会发送给服务端。

做用域

关于做用域也有两个属性: Domain和path, 给 Cookie 绑定了域名和路径，在发送请求以前，发现域名或者路径和这两个属性不匹配，那么就不会带上 Cookie。值得注意的是，对于路径来讲，/表示域名下的任意路径都容许使用 Cookie。

安全相关

若是带上Secure，说明只能经过 HTTPS 传输 cookie。

若是 cookie 字段带上HttpOnly，那么说明只能经过 HTTP 协议传输，不能经过 JS 访问，这也是预防 XSS 攻击的重要手段。

相应的，对于 CSRF 攻击的预防，也有SameSite属性。

SameSite能够设置为三个值，Strict、Lax和None。

a. 在Strict模式下，浏览器彻底禁止第三方请求携带Cookie。好比请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其余网站请求都不能。

b. 在Lax模式，就宽松一点了，可是只能在 get 方法提交表单况或者a 标签发送 get 请求的状况下能够携带 Cookie，其余状况均不能。

c. 在None模式下，也就是默认模式，请求会自动携带上 Cookie。

Cookie 的缺点

容量缺陷。Cookie 的体积上限只有4KB，只能用来存储少许的信息。
性能缺陷。Cookie 紧跟域名，无论域名下面的某一个地址需不须要这个 Cookie ，请求都会携带上完整的 Cookie，这样随着请求数的增多，其实会形成巨大的性能浪费的，由于请求携带了不少没必要要的内容。但能够经过Domain和Path指定做用域来解决。
安全缺陷。因为 Cookie 以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，而后进行一系列的篡改，在 Cookie 的有效期内从新发送给服务器，这是至关危险的。另外，在HttpOnly为 false 的状况下，Cookie 信息能直接经过 JS 脚原本读取。

012: 如何理解 HTTP 代理？

咱们知道在 HTTP 是基于请求-响应模型的协议，通常由客户端发请求，服务器来进行响应。

固然，也有特殊状况，就是代理服务器的状况。引入代理以后，做为代理的服务器至关于一个中间人的角色，对于客户端而言，表现为服务器进行响应；而对于源服务器，表现为客户端发起请求，具备双重身份。

那代理服务器究竟是用来作什么的呢？

功能

负载均衡。客户端的请求只会先到达代理服务器，后面到底有多少源服务器，IP 都是多少，客户端是不知道的。所以，这个代理服务器能够拿到这个请求以后，能够经过特定的算法分发给不一样的源服务器，让各台源服务器的负载尽可能平均。固然，这样的算法有不少，包括随机算法、轮询、一致性hash、LRU(最近最少使用)等等，不过这些算法并非本文的重点，你们有兴趣本身能够研究一下。
保障安全。利用心跳机制监控后台的服务器，一旦发现故障机就将其踢出集群。而且对于上下行的数据进行过滤，对非法 IP 限流，这些都是代理服务器的工做。
缓存代理。将内容缓存到代理服务器，使得客户端能够直接从代理服务器得到而不用到源服务器那里。下一节详细拆解。

X-Forwarded-For产生的问题

前面能够看到，X-Forwarded-For这个字段记录的是请求方的 IP，这意味着每通过一个不一样的代理，这个字段的名字都要变，从客户端到代理1，这个字段是客户端的 IP，从代理1到代理2，这个字段就变为了代理1的 IP。

可是这会产生两个问题:

意味着代理必须解析 HTTP 请求头，而后修改，比直接转发数据性能降低。
在 HTTPS 通讯加密的过程当中，原始报文是不容许修改的。

由此产生了代理协议，通常使用明文版本，只须要在 HTTP 请求行上面加上这样格式的文本便可:

// PROXY + TCP4/TCP6 + 请求方地址 + 接收方地址 + 请求端口 + 接收端口
PROXY TCP4 0.0.0.1 0.0.0.2 1111 2222
GET / HTTP/1.1
...

这样就能够解决X-Forwarded-For带来的问题了。

013: 如何理解 HTTP 缓存及缓存代理？

关于强缓存和协商缓存的内容，我已经在【说一说浏览器缓存】作了详细分析，小结以下:

首先经过 Cache-Control 验证强缓存是否可用

若是强缓存可用，直接使用
不然进入协商缓存，即发送 HTTP 请求，服务器经过请求头中的 If-Modified-Since或者 If-None-Match这些 条件请求字段检查资源是否更新

若资源更新，返回资源和200状态码
不然，返回304，告诉浏览器直接从缓存获取资源

这一节咱们主要来讲说另一种缓存方式: 代理缓存。

为何产生代理缓存？

对于源服务器来讲，它也是有缓存的，好比Redis, Memcache，但对于 HTTP 缓存来讲，若是每次客户端缓存失效都要到源服务器获取，那给源服务器的压力是很大的。

由此引入了缓存代理的机制。让代理服务器接管一部分的服务端HTTP缓存，客户端缓存过时后就近到代理缓存中获取，代理缓存过时了才请求源服务器，这样流量巨大的时候能明显下降源服务器的压力。

那缓存代理到底是如何作到的呢？

总的来讲，缓存代理的控制分为两部分，一部分是源服务器端的控制，一部分是客户端的控制。

源服务器的缓存控制

private 和 public

在源服务器的响应头中，会加上Cache-Control这个字段进行缓存控制字段，那么它的值当中能够加入private或者public表示是否容许代理服务器缓存，前者禁止，后者为容许。

好比对于一些很是私密的数据，若是缓存到代理服务器，别人直接访问代理就能够拿到这些数据，是很是危险的，所以对于这些数据通常是不会容许代理服务器进行缓存的，将响应头部的Cache-Control设为private，而不是public。

proxy-revalidate

must-revalidate的意思是客户端缓存过时就去源服务器获取，而proxy-revalidate则表示代理服务器的缓存过时后到源服务器获取。

s-maxage

s是share的意思，限定了缓存在代理服务器中能够存放多久，和限制客户端缓存时间的max-age并不冲突。

讲了这几个字段，咱们不妨来举个小例子，源服务器在响应头中加入这样一个字段:

Cache-Control: public, max-age=1000, s-maxage=2000

至关于源服务器说: 我这个响应是容许代理服务器缓存的，客户端缓存过时了到代理中拿，而且在客户端的缓存时间为 1000 秒，在代理服务器中的缓存时间为 2000 s。

客户端的缓存控制

max-stale 和 min-fresh

在客户端的请求头中，能够加入这两个字段，来对代理服务器上的缓存进行宽容和限制操做。好比：

max-stale: 5

表示客户端到代理服务器上拿缓存的时候，即便代理缓存过时了也没关系，只要过时时间在5秒以内，仍是能够从代理中获取的。

又好比:

min-fresh: 5

表示代理缓存须要必定的新鲜度，不要等到缓存恰好到期再拿，必定要在到期前 5 秒以前的时间拿，不然拿不到。

only-if-cached

这个字段加上后表示客户端只会接受代理缓存，而不会接受源服务器的响应。若是代理缓存无效，则直接返回504（Gateway Timeout）。

以上即是缓存代理的内容，涉及的字段比较多，但愿能好好回顾一下，加深理解。

014: 什么是跨域？浏览器如何拦截响应？如何解决？

在先后端分离的开发模式中，常常会遇到跨域问题，即 Ajax 请求发出去了，服务器也成功响应了，前端就是拿不到这个响应。接下来咱们就来好好讨论一下这个问题。

什么是跨域

回顾一下 URI 的组成:

浏览器遵循同源政策(scheme(协议)、host(主机)和port(端口)都相同则为同源)。非同源站点有这样一些限制:

不能读取和修改对方的 DOM
不读访问对方的 Cookie、IndexDB 和 LocalStorage
限制 XMLHttpRequest 请求。(后面的话题着重围绕这个)

当浏览器向目标 URI 发 Ajax 请求时，只要当前 URL 和目标 URL 不一样源，则产生跨域，被称为跨域请求。

跨域请求的响应通常会被浏览器所拦截，注意，是被浏览器拦截，响应实际上是成功到达客户端了。那这个拦截是如何发生呢？

首先要知道的是，浏览器是多进程的，以 Chrome 为例，进程组成以下：

WebKit 渲染引擎和V8 引擎都在渲染进程当中。

当xhr.send被调用，即 Ajax 请求准备发送的时候，其实还只是在渲染进程的处理。为了防止黑客经过脚本触碰到系统资源，浏览器将每个渲染进程装进了沙箱，而且为了防止 CPU 芯片一直存在的Spectre 和 Meltdown漏洞，采起了站点隔离的手段，给每个不一样的站点(一级域名不一样)分配了沙箱，互不干扰。具体见YouTube上Chromium安全团队的演讲视频。

在沙箱当中的渲染进程是没有办法发送网络请求的，那怎么办？只能经过网络进程来发送。那这样就涉及到进程间通讯(IPC，Inter Process Communication)了。接下来咱们看看 chromium 当中进程间通讯是如何完成的，在 chromium 源码中调用顺序以下:

可能看了你会比较懵，若是想深刻了解能够去看看 chromium 最新的源代码，IPC源码地址及Chromium IPC源码解析文章。

总的来讲就是利用Unix Domain Socket套接字，配合事件驱动的高性能网络并发库libevent完成进程的 IPC 过程。

好，如今数据传递给了浏览器主进程，主进程接收到后，才真正地发出相应的网络请求。

在服务端处理完数据后，将响应返回，主进程检查到跨域，且没有cors(后面会详细说)响应头，将响应体所有丢掉，并不会发送给渲染进程。这就达到了拦截数据的目的。

接下来咱们来讲一说解决跨域问题的几种方案。

CORS

CORS 实际上是 W3C 的一个标准，全称是跨域资源共享。它须要浏览器和服务器的共同支持，具体来讲，非 IE 和 IE10 以上支持CORS，服务器须要附加特定的响应头，后面具体拆解。不过在弄清楚 CORS 的原理以前，咱们须要清楚两个概念: 简单请求和非简单请求。

浏览器根据请求方法和请求头的特定字段，将请求作了一下分类，具体来讲规则是这样，凡是知足下面条件的属于简单请求:

请求方法为 GET、POST 或者 HEAD
请求头的取值范围: Accept、Accept-Language、Content-Language、Content-Type(只限于三个值 application/x-www-form-urlencoded、 multipart/form-data、 text/plain)

浏览器画了这样一个圈，在这个圈里面的就是简单请求, 圈外面的就是非简单请求，而后针对这两种不一样的请求进行不一样的处理。

简单请求

请求发出去以前，浏览器作了什么？

它会自动在请求头当中，添加一个Origin字段，用来讲明请求来自哪一个源。服务器拿到请求以后，在回应时对应地添加Access-Control-Allow-Origin字段，若是Origin不在这个字段的范围中，那么浏览器就会将响应拦截。

所以，Access-Control-Allow-Origin字段是服务器用来决定浏览器是否拦截这个响应，这是必需的字段。与此同时，其它一些可选的功能性的字段，用来描述若是不会拦截，这些字段将会发挥各自的做用。

Access-Control-Allow-Credentials。这个字段是一个布尔值，表示是否容许发送 Cookie，对于跨域请求，浏览器对这个字段默认值设为 false，而若是须要拿到浏览器的 Cookie，须要添加这个响应头并设为true, 而且在前端也须要设置withCredentials属性:

let xhr = new XMLHttpRequest();
xhr.withCredentials = true;

Access-Control-Expose-Headers。这个字段是给 XMLHttpRequest 对象赋能，让它不只能够拿到基本的 6 个响应头字段（包括Cache-Control、Content-Language、Content-Type、Expires、Last-Modified和Pragma）, 还能拿到这个字段声明的响应头字段。好比这样设置:

Access-Control-Expose-Headers: aaa

那么在前端能够经过 XMLHttpRequest.getResponseHeader('aaa') 拿到 aaa 这个字段的值。

非简单请求

非简单请求相对而言会有些不一样，体如今两个方面: 预检请求和响应字段。

咱们以 PUT 方法为例。

var url = 'http://xxx.com';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'xxx');
xhr.send();

当这段代码执行后，首先会发送预检请求。这个预检请求的请求行和请求体是下面这个格式:

OPTIONS / HTTP/1.1
Origin: 当前地址
Host: xxx.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header

预检请求的方法是OPTIONS，同时会加上Origin源地址和Host目标地址，这很简单。同时也会加上两个关键的字段:

Access-Control-Request-Method, 列出 CORS 请求用到哪一个HTTP方法
Access-Control-Request-Headers，指定 CORS 请求将要加上什么请求头

这是预检请求。接下来是响应字段，响应字段也分为两部分，一部分是对于预检请求的响应，一部分是对于 CORS 请求的响应。

预检请求的响应。以下面的格式:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0

其中有这样几个关键的响应头字段:

Access-Control-Allow-Origin: 表示能够容许请求的源，能够填具体的源名，也能够填 *表示容许任意源请求。
Access-Control-Allow-Methods: 表示容许的请求方法列表。
Access-Control-Allow-Credentials: 简单请求中已经介绍。
Access-Control-Allow-Headers: 表示容许发送的请求头字段
Access-Control-Max-Age: 预检请求的有效期，在此期间，不用发出另一条预检请求。

在预检请求的响应返回后，若是请求不知足响应头的条件，则触发XMLHttpRequest的onerror方法，固然后面真正的CORS请求也不会发出去了。

CORS 请求的响应。绕了这么一大转，到了真正的 CORS 请求就容易多了，如今它和简单请求的状况是同样的。浏览器自动加上Origin字段，服务端响应头返回Access-Control-Allow-Origin。能够参考以上简单请求部分的内容。

JSONP

虽然XMLHttpRequest对象遵循同源政策，可是script标签不同，它能够经过 src 填上目标地址从而发出 GET 请求，实现跨域请求并拿到响应。这也就是 JSONP 的原理，接下来咱们就来封装一个 JSONP:

const jsonp = ({ url, params, callbackName }) => {
  const generateURL = () => {
    let dataStr = '';
    for(let key in params) {
      dataStr += `${key}=${params[key]}&`;
    }
    dataStr += `callback=${callbackName}`;
    return `${url}?${dataStr}`;
  };
  return new Promise((resolve, reject) => {
    // 初始化回调函数名称
    callbackName = callbackName || Math.random().toString.replace(',', '');
    // 建立 script 元素并加入到当前文档中
    let scriptEle = document.createElement('script');
    scriptEle.src = generateURL();
    document.body.appendChild(scriptEle);
    // 绑定到 window 上，为了后面调用
    window[callbackName] = (data) => {
      resolve(data);
      // script 执行完了，成为无用元素，须要清除
      document.body.removeChild(scriptEle);
    }
  });
}

固然在服务端也会有响应的操做, 以 express 为例:

let express = require('express')
let app = express()
app.get('/', function(req, res) {
  let { a, b, callback } = req.query
  console.log(a); // 1
  console.log(b); // 2
  // 注意哦，返回给script标签，浏览器直接把这部分字符串执行
  res.end(`${callback}('数据包')`);
})
app.listen(3000)

前端这样简单地调用一下就行了:

jsonp({
  url: 'http://localhost:3000',
  params: {
    a: 1,
    b: 2
  }
}).then(data => {
  // 拿到数据进行处理
  console.log(data); // 数据包
})

和CORS相比，JSONP 最大的优点在于兼容性好，IE 低版本不能使用 CORS 但能够使用 JSONP，缺点也很明显，请求方法单一，只支持 GET 请求。

Nginx

Nginx 是一种高性能的反向代理服务器，能够用来轻松解决跨域问题。

what？反向代理？我给你看一张图你就懂了。

正向代理帮助客户端访问客户端本身访问不到的服务器，而后将结果返回给客户端。

反向代理拿到客户端的请求，将请求转发给其余的服务器，主要的场景是维持服务器集群的负载均衡，换句话说，反向代理帮其它的服务器拿到请求，而后选择一个合适的服务器，将请求转交给它。

所以，二者的区别就很明显了，正向代理服务器是帮客户端作事情，而反向代理服务器是帮其它的服务器作事情。

好了，那 Nginx 是如何来解决跨域的呢？

好比说如今客户端的域名为client.com，服务器的域名为server.com，客户端向服务器发送 Ajax 请求，固然会跨域了，那这个时候让 Nginx 登场了，经过下面这个配置:

server {
  listen  80;
  server_name  client.com;
  location /api {
    proxy_pass server.com;
  }
}

Nginx 至关于起了一个跳板机，这个跳板机的域名也是client.com，让客户端首先访问 client.com/api，这固然没有跨域，而后 Nginx 服务器做为反向代理，将请求转发给server.com，当响应返回时又将响应给到客户端，这就完成整个跨域请求的过程。

其实还有一些不太经常使用的方式，你们了解便可，好比postMessage，固然WebSocket也是一种方式，可是已经不属于 HTTP 的范畴，另一些奇技淫巧就不建议你们去死记硬背了，一方面历来不用，名字都可贵记住，另外一方面临时背下来，面试官也不会对你印象加分，由于看得出来是背的。固然没有背并不表明减分，把跨域原理和前面三种主要的跨域方式理解清楚，经得起更深一步的推敲，反而会让别人以为你是一个靠谱的人。

015: TLS1.2 握手的过程是怎样的？

以前谈到了 HTTP 是明文传输的协议，传输保文对外彻底透明，很是不安全，那如何进一步保证安全性呢？

由此产生了 HTTPS，其实它并非一个新的协议，而是在 HTTP 下面增长了一层 SSL/TLS 协议，简单的讲，HTTPS = HTTP + SSL/TLS。

那什么是 SSL/TLS 呢？

SSL 即安全套接层（Secure Sockets Layer），在 OSI 七层模型中处于会话层(第 5 层)。以前 SSL 出过三个大版本，当它发展到第三个大版本的时候才被标准化，成为 TLS（传输层安全，Transport Layer Security），并被当作 TLS1.0 的版本，准确地说，TLS1.0 = SSL3.1。

如今主流的版本是 TLS/1.2, 以前的 TLS1.0、TLS1.1 都被认为是不安全的，在不久的未来会被彻底淘汰。所以咱们接下来主要讨论的是 TLS1.2, 固然在 2018 年推出了更加优秀的 TLS1.3，大大优化了 TLS 握手过程，这个咱们放在下一节再去说。

TLS 握手的过程比较复杂，写文章以前我查阅了大量的资料，发现对 TLS 初学者很是不友好，也有不少知识点说的含糊不清，能够说这个整理的过程是至关痛苦了。但愿我下面的拆解可以帮你理解得更顺畅些吧 : ）

传统 RSA 握手

先来讲说传统的 TLS 握手，也是你们在网上常常看到的。我以前也写过这样的文章，(传统RSA版本)HTTPS为何让数据传输更安全，其中也介绍到了对称加密和非对称加密的概念，建议你们去读一读，再也不赘述。之因此称它为 RSA 版本，是由于它在加解密pre_random的时候采用的是 RSA 算法。

TLS 1.2 握手过程

如今咱们来说讲主流的 TLS 1.2 版本所采用的方式。

刚开始你可能会比较懵，先别着急，过一遍下面的流程再来看会豁然开朗。

step 1: Client Hello

首先，浏览器发送 client_random、TLS版本、加密套件列表。

client_random 是什么？用来最终 secret 的一个参数。

加密套件列表是什么？我举个例子，加密套件列表通常张这样:

TLS_ECDHE_WITH_AES_128_GCM_SHA256

意思是TLS握手过程当中，使用ECDHE算法生成pre_random(这个数后面会介绍)，128位的AES算法进行对称加密，在对称加密的过程当中使用主流的GCM分组模式，由于对称加密中很重要的一个问题就是如何分组。最后一个是哈希摘要算法，采用SHA256算法。

其中值得解释一下的是这个哈希摘要算法，试想一个这样的场景，服务端如今给客户端发消息来了，客户端并不知道此时的消息究竟是服务端发的，仍是中间人伪造的消息呢？如今引入这个哈希摘要算法，将服务端的证书信息经过这个算法生成一个摘要(能够理解为比较短的字符串)，用来标识这个服务端的身份，用私钥加密后把加密后的标识和本身的公钥传给客户端。客户端拿到这个公钥来解密，生成另一份摘要。两个摘要进行对比，若是相同则能确认服务端的身份。这也就是所谓数字签名的原理。其中除了哈希算法，最重要的过程是私钥加密，公钥解密。

step 2: Server Hello

能够看到服务器一口气给客户端回复了很是多的内容。

server_random也是最后生成secret的一个参数, 同时确认 TLS 版本、须要使用的加密套件和本身的证书，这都不难理解。那剩下的server_params是干吗的呢？

咱们先埋个伏笔，如今你只须要知道，server_random到达了客户端。

step 3: Client 验证证书，生成secret

客户端验证服务端传来的证书和签名是否经过，若是验证经过，则传递client_params这个参数给服务器。

接着客户端经过ECDHE算法计算出pre_random，其中传入两个参数:server_params和client_params。如今你应该清楚这个两个参数的做用了吧，因为ECDHE基于椭圆曲线离散对数，这两个参数也称做椭圆曲线的公钥。

客户端如今拥有了client_random、server_random和pre_random，接下来将这三个数经过一个伪随机数函数来计算出最终的secret。

step4: Server 生成 secret

刚刚客户端不是传了client_params过来了吗？

如今服务端开始用ECDHE算法生成pre_random，接着用和客户端一样的伪随机数函数生成最后的secret。

注意事项

TLS的过程基本上讲完了，但还有两点须要注意。

第一、实际上 TLS 握手是一个双向认证的过程，从 step1 中能够看到，客户端有能力验证服务器的身份，那服务器能不能验证客户端的身份呢？

固然是能够的。具体来讲，在 step3中，客户端传送client_params，实际上给服务器传一个验证消息，让服务器将相同的验证流程(哈希摘要 + 私钥加密 + 公钥解密)走一遍，确认客户端的身份。

第二、当客户端生成secret后，会给服务端发送一个收尾的消息，告诉服务器以后的都用对称加密，对称加密的算法就用第一次约定的。服务器生成完secret也会向客户端发送一个收尾的消息，告诉客户端之后就直接用对称加密来通讯。

这个收尾的消息包括两部分，一部分是Change Cipher Spec，意味着后面加密传输了，另外一个是Finished消息，这个消息是对以前全部发送的数据作的摘要，对摘要进行加密，让对方验证一下。

当双方都验证经过以后，握手才正式结束。后面的 HTTP 正式开始传输加密报文。

RSA 和 ECDHE 握手过程的区别

ECDHE 握手，也就是主流的 TLS1.2 握手中，使用ECDHE实现pre_random的加密解密，没有用到 RSA。
使用 ECDHE 还有一个特色，就是客户端发送完收尾消息后能够提早抢跑，直接发送 HTTP 报文，节省了一个 RTT，没必要等到收尾消息到达服务器，而后等服务器返回收尾消息给本身，直接开始发请求。这也叫TLS False Start。

016: TLS 1.3 作了哪些改进？

TLS 1.2 虽然存在了 10 多年，经历了无数的考验，但历史的车轮老是不断向前的，为了得到更强的安全、更优秀的性能，在2018年就推出了 TLS1.3，对于TLS1.2作了一系列的改进，主要分为这几个部分:强化安全、提升性能。

强化安全

在 TLS1.3 中废除了很是多的加密算法，最后只保留五个加密套件:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_GCM_8_SHA256

能够看到，最后剩下的对称加密算法只有 AES 和 CHACHA20，以前主流的也会这两种。分组模式也只剩下 GCM 和 POLY1305, 哈希摘要算法只剩下了 SHA256 和 SHA384 了。

那你可能会问了, 以前RSA这么重要的非对称加密算法怎么不在了？

我以为有两方面的缘由:

第一、2015年发现了FREAK攻击，即已经有人发现了 RSA 的漏洞，可以进行破解了。

第二、一旦私钥泄露，那么中间人能够经过私钥计算出以前全部报文的secret，破解以前全部的密文。

为何？回到 RSA 握手的过程当中，客户端拿到服务器的证书后，提取出服务器的公钥，而后生成pre_random并用公钥加密传给服务器，服务器经过私钥解密，从而拿到真实的pre_random。当中间人拿到了服务器私钥，而且截获以前全部报文的时候，那么就能拿到pre_random、server_random和client_random并根据对应的随机数函数生成secret，也就是拿到了 TLS 最终的会话密钥，每个历史报文都能经过这样的方式进行破解。

但ECDHE在每次握手时都会生成临时的密钥对，即便私钥被破解，以前的历史消息并不会收到影响。这种一次破解并不影响历史信息的性质也叫前向安全性。

RSA 算法不具有前向安全性，而 ECDHE 具有，所以在 TLS1.3 中完全取代了RSA。

提高性能

握手改进

流程以下:

大致的方式和 TLS1.2 差很少，不过和 TLS 1.2 相比少了一个 RTT，服务端没必要等待对方验证证书以后才拿到client_params，而是直接在第一次握手的时候就可以拿到, 拿到以后当即计算secret，节省了以前没必要要的等待时间。同时，这也意味着在第一次握手的时候客户端须要传送更多的信息，一口气给传完。

这种 TLS 1.3 握手方式也被叫作1-RTT握手。但其实这种1-RTT的握手方式仍是有一些优化的空间的，接下来咱们来一一介绍这些优化方式。

会话复用

会话复用有两种方式: Session ID和Session Ticket。

先说说最先出现的Seesion ID，具体作法是客户端和服务器首次链接后各自保存会话的 ID，并存储会话密钥，当再次链接时，客户端发送ID过来，服务器查找这个 ID 是否存在，若是找到了就直接复用以前的会话状态，会话密钥不用从新生成，直接用原来的那份。

但这种方式也存在一个弊端，就是当客户端数量庞大的时候，对服务端的存储压力很是大。

于是出现了第二种方式——Session Ticket。它的思路就是: 服务端的压力大，那就把压力分摊给客户端呗。具体来讲，双方链接成功后，服务器加密会话信息，用Session Ticket消息发给客户端，让客户端保存下来。下次重连的时候，就把这个 Ticket 进行解密，验证它过没过时，若是没过时那就直接恢复以前的会话状态。

这种方式虽然减少了服务端的存储压力，但与带来了安全问题，即每次用一个固定的密钥来解密 Ticket 数据，一旦黑客拿到这个密钥，以前全部的历史记录也被破解了。所以为了尽可能避免这样的问题，密钥须要按期进行更换。

总的来讲，这些会话复用的技术在保证1-RTT的同时，也节省了生成会话密钥这些算法所消耗的时间，是一笔可观的性能提高。

PSK

刚刚说的都是1-RTT状况下的优化，那能不能优化到0-RTT呢？

答案是能够的。作法其实也很简单，在发送Session Ticket的同时带上应用数据，不用等到服务端确认，这种方式被称为Pre-Shared Key，即 PSK。

这种方式虽然方便，但也带来了安全问题。中间人截获PSK的数据，不断向服务器重复发，相似于 TCP 第一次握手携带数据，增长了服务器被攻击的风险。

总结

TLS1.3 在 TLS1.2 的基础上废除了大量的算法，提高了安全性。同时利用会话复用节省了从新生成密钥的时间，利用 PSK 作到了0-RTT链接。

017: HTTP/2 有哪些改进？

因为 HTTPS 在安全方面已经作的很是好了，HTTP 改进的关注点放在了性能方面。对于 HTTP/2 而言，它对于性能的提高主要在于两点:

头部压缩
多路复用

固然还有一些颠覆性的功能实现:

设置请求优先级
服务器推送

这些重大的提高本质上也是为了解决 HTTP 自己的问题而产生的。接下来咱们来看看 HTTP/2 解决了哪些问题，以及解决方式具体是如何的。

头部压缩

在 HTTP/1.1 及以前的时代，请求体通常会有响应的压缩编码过程，经过Content-Encoding头部字段来指定，但你有没有想过头部字段自己的压缩呢？当请求字段很是复杂的时候，尤为对于 GET 请求，请求报文几乎全是请求头，这个时候仍是存在很是大的优化空间的。HTTP/2 针对头部字段，也采用了对应的压缩算法——HPACK，对请求头进行压缩。

HPACK 算法是专门为 HTTP/2 服务的，它主要的亮点有两个：

首先是在服务器和客户端之间创建哈希表，将用到的字段存放在这张表中，那么在传输的时候对于以前出现过的值，只须要把索引(好比0，1，2，...)传给对方便可，对方拿到索引查表就好了。这种 传索引的方式，能够说让请求头字段获得极大程度的精简和复用。

HTTP/2 当中废除了起始行的概念，将起始行中的请求方法、URI、状态码转换成了头字段，不过这些字段都有一个":"前缀，用来和其它请求头区分开。

其次是对于整数和字符串进行 哈夫曼编码，哈夫曼编码的原理就是先将全部出现的字符创建一张索引表，而后让出现次数多的字符对应的索引尽量短，传输的时候也是传输这样的 索引序列，能够达到很是高的压缩率。

多路复用

HTTP 队头阻塞

咱们以前讨论了 HTTP 队头阻塞的问题，其根本缘由在于HTTP 基于请求-响应的模型，在同一个 TCP 长链接中，前面的请求没有获得响应，后面的请求就会被阻塞。

后面咱们又讨论到用并发链接和域名分片的方式来解决这个问题，但这并无真正从 HTTP 自己的层面解决问题，只是增长了 TCP 链接，分摊风险而已。并且这么作也有弊端，多条 TCP 链接会竞争有限的带宽，让真正优先级高的请求不能优先处理。

而 HTTP/2 便从 HTTP 协议自己解决了队头阻塞问题。注意，这里并非指的TCP队头阻塞，而是HTTP队头阻塞，二者并非一回事。TCP 的队头阻塞是在数据包层面，单位是数据包，前一个报文没有收到便不会将后面收到的报文上传给 HTTP，而HTTP 的队头阻塞是在 HTTP 请求-响应层面，前一个请求没处理完，后面的请求就要阻塞住。二者所在的层次不同。

那么 HTTP/2 如何来解决所谓的队头阻塞呢？

二进制分帧

首先，HTTP/2 认为明文传输对机器而言太麻烦了，不方便计算机的解析，由于对于文本而言会有多义性的字符，好比回车换行究竟是内容仍是分隔符，在内部须要用到状态机去识别，效率比较低。因而 HTTP/2 干脆把报文所有换成二进制格式，所有传输01串，方便了机器的解析。

原来Headers + Body的报文格式现在被拆分红了一个个二进制的帧，用Headers帧存放头部字段，Data帧存放请求体数据。分帧以后，服务器看到的再也不是一个个完整的 HTTP 请求报文，而是一堆乱序的二进制帧。这些二进制帧不存在前后关系，所以也就不会排队等待，也就没有了 HTTP 的队头阻塞问题。

通讯双方均可以给对方发送二进制帧，这种二进制帧的双向传输的序列，也叫作流(Stream)。HTTP/2 用流来在一个 TCP 链接上来进行多个数据帧的通讯，这就是多路复用的概念。

可能你会有一个疑问，既然是乱序首发，那最后如何来处理这些乱序的数据帧呢？

首先要声明的是，所谓的乱序，指的是不一样 ID 的 Stream 是乱序的，但同一个 Stream ID 的帧必定是按顺序传输的。二进制帧到达后对方会将 Stream ID 相同的二进制帧组装成完整的请求报文和响应报文。固然，在二进制帧当中还有其余的一些字段，实现了优先级和流量控制等功能，咱们放到下一节再来介绍。

服务器推送

另外值得一说的是 HTTP/2 的服务器推送(Server Push)。在 HTTP/2 当中，服务器已经再也不是彻底被动地接收请求，响应请求，它也能新建 stream 来给客户端发送消息，当 TCP 链接创建以后，好比浏览器请求一个 HTML 文件，服务器就能够在返回 HTML 的基础上，将 HTML 中引用到的其余资源文件一块儿返回给客户端，减小客户端的等待。

总结

固然，HTTP/2 新增那么多的特性，是否是 HTTP 的语法要从新学呢？不须要，HTTP/2 彻底兼容以前 HTTP 的语法和语义，如请求头、URI、状态码、头部字段都没有改变，彻底不用担忧。同时，在安全方面，HTTP 也支持 TLS，而且如今主流的浏览器都公开只支持加密的 HTTP/2, 所以你如今能看到的 HTTP/2 也基本上都是跑在 TLS 上面的了。最后放一张分层图给你们参考:

018: HTTP/2 中的二进制帧是如何设计的？

帧结构

HTTP/2 中传输的帧结构以下图所示:

每一个帧分为帧头和帧体。先是三个字节的帧长度，这个长度表示的是帧体的长度。

而后是帧类型，大概能够分为数据帧和控制帧两种。数据帧用来存放 HTTP 报文，控制帧用来管理流的传输。

接下来的一个字节是帧标志，里面一共有 8 个标志位，经常使用的有 END_HEADERS表示头数据结束，END_STREAM表示单方向数据发送结束。

后 4 个字节是Stream ID, 也就是流标识符，有了它，接收方就能从乱序的二进制帧中选择出 ID 相同的帧，按顺序组装成请求/响应报文。

流的状态变化

从前面能够知道，在 HTTP/2 中，所谓的流，其实就是二进制帧的双向传输的序列。那么在 HTTP/2 请求和响应的过程当中，流的状态是如何变化的呢？

HTTP/2 其实也是借鉴了 TCP 状态变化的思想，根据帧的标志位来实现具体的状态改变。这里咱们以一个普通的请求-响应过程为例来讲明：

最开始二者都是空闲状态，当客户端发送Headers帧后，开始分配Stream ID, 此时客户端的流打开, 服务端接收以后服务端的流也打开，两端的流都打开以后，就能够互相传递数据帧和控制帧了。

当客户端要关闭时，向服务端发送END_STREAM帧，进入半关闭状态, 这个时候客户端只能接收数据，而不能发送数据。

服务端收到这个END_STREAM帧后也进入半关闭状态，不过此时服务端的状况是只能发送数据，而不能接收数据。随后服务端也向客户端发送END_STREAM帧，表示数据发送完毕，双方进入关闭状态。

若是下次要开启新的流，流 ID 须要自增，直到上限为止，到达上限后开一个新的 TCP 链接重头开始计数。因为流 ID 字段长度为 4 个字节，最高位又被保留，所以范围是 0 ~ 2的 31 次方，大约 21 亿个。

流的特性

刚刚谈到了流的状态变化过程，这里顺便就来总结一下流传输的特性:

并发性。一个 HTTP/2 链接上能够同时发多个帧，这一点和 HTTP/1 不一样。这也是实现多路复用的基础。
自增性。流 ID 是不可重用的，而是会按顺序递增，达到上限以后又新开 TCP 链接从头开始。
双向性。客户端和服务端均可以建立流，互不干扰，双方均可以做为 发送方或者 接收方。
可设置优先级。能够设置数据帧的优先级，让服务端先处理重要资源，优化用户体验。

以上就是对 HTTP/2 中二进制帧的介绍，但愿对你有所启发。

参考

《web协议详解与抓包实战——陶辉》

《透视 HTTP 协议》——chrono

Chromium IPC 源码

前端开发者必备的Nginx知识 ——conardli

本文分享自微信公众号 - 牧码的星星（gh_0d71d9e8b1c3）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。