1 HTTP 基本概念

• HTTP是 Hyper Text Transfer Protocol（ 超文本传输协定）的缩写。
• HTTP 协定（HyperText Transfer Protocol，超文本传输协定）是用于从 WWW 服务器传输超文本到本地浏览器的传送协定。它能够使浏览器更加高效，使网络传输缩小。它不仅保障计算机正确疾速地传输超文本文档，还确定传输文档中的哪一部分，以及哪局部内容首先显示 (如文本先于图形) 等。
• HTTP 是一个应用层协定，由申请和响应形成，是一个规范的客户端服务器模型。HTTP 是一个无状态的协定。
• HTTP 协定是一种应用层的传输协定，用于客户端和服务器之间的通信。

2 HTTP 罕用办法

2.1 OPTIONS 办法详解

OPTIONS 申请即 预检申请 ，可用于检测服务器容许的 http 办法。当发动跨域申请时，因为平安起因，触发肯定条件时浏览器会在正式申请之前 主动 先发动 OPTIONS 申请，即 CORS 预检申请，服务器若承受该跨域申请，浏览器才持续发动正式申请。
满足以下条件属于简略申请

1. 申请形式只能是 GET、POST、HEAD
2. HTTP 申请头限度这几种字段（Accept、Accept-Language、Content-Type、DPR、Downlink、Save-Data、Viewport-Width、Width）
3. Content-Type：只能取 application/x-www-form-urlencoded、multipart/form-data、text/plain
4. 申请中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象能够应用
5. 申请中没有应用 ReadableStream 对象

3 申请报文与响应报文

3.1 申请报文

一个 HTTP 申请报文由申请行（request line）、申请头部（header）、空行和申请数据 4 个局部组成，下图给出了申请报文的个别格局。

1. 申请行

申请行分为三个局部：申请办法、申请地址和协定版本

2. 申请头部

申请头部为申请报文增加了一些附加信息，由“名 / 值”对组成，每行一对，名和值之间应用冒号分隔。
常见申请头如下：

3. 申请数据

可选局部，比方 GET 申请就没有申请数据。
而一个 POST 办法就会有申请体

响应报文

HTTP 响应报文次要由状态行、响应头部、空行以及响应数据组成。

1. 状态行

由 3 局部组成，别离为：协定版本，状态码，状态码形容。（状态码会在前面介绍）

2. 响应头部

与申请头部相似，为响应报文增加了一些附加信息
常见响应头部如下：

4 响应状态码

和申请报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言通知客户端本次申请的处理结果。
HTTP 的响应状态码由 5 段组成：

1xx 音讯，个别是通知客户端，申请曾经收到了，正在解决，别急 …

• 100 Continue — 服务器仅接管到局部申请，然而一旦服务器并没有回绝该申请，客户端应该持续发送其余的申请。
• 101 Switching Protocols — 服务器转换协定：服务器将听从客户的申请转换到另外一种协定。
• 102 Processing — 由 WebDAV(RFC 2518)扩大的状态码，代表解决将被继续执行。

2xx 解决胜利，个别示意：申请收悉、我明确你要的、申请已受理、曾经解决实现等信息.

• 200 OK：申请胜利
• 201 Created: 罕用于 POST，PUT 申请，表明申请曾经胜利，并新建了一个资源。并在响应体中返回门路。
• 202 Accepted: 申请曾经接管到，但没有响应，稍后也不会返回一个异步申请后果。该状态码实用于期待其余过程解决或者批处理的场景
• 203 No-Authoritative Information: 表明响应返回的元信息（meta-infomation）和最后的服务器不同，而是从本地或者第三方获取的。次要用于其余资源的镜像和备份。除了后面的状况，首选还是 200
• 204 No Content: 申请没有数据返回，然而头信息有用。用户代理 (浏览器) 会更新缓存的头信息。
• 205 Reset Content: 通知用户代理（浏览器）重置发送该申请的文档。
• 206 Partical Content: 当客户端应用 Range 申请头时，返回该状态码。

3xx 重定向到其它中央。它让客户端再发动一个申请以实现整个解决。

• 301 永久性重定向
• 302 临时性重定向
• 304 Not Modified: 资源未变更。

4xx 解决产生谬误，责任在客户端，如客户端的申请一个不存在的资源，客户端未被受权，禁止拜访等。

• 400 Bad Request: 申请语法有问题，服务器无奈辨认。没有 host 申请头字段，或者设置了超过一个的 host 申请头字段。
• 401 UnAuthorized: 客户端未受权该申请。不足无效的身份认证凭证，个别可能是未登陆。登陆后个别都解决问题。
• 403 Forbidden: 服务器回绝响应。权限有余。
• 404 Not Found: URL 有效或者 URL 无效然而没有资源。
• 405 Method Not Allowed: 申请形式 Method 不容许。然而 GET 和 HEAD 属于强制形式，不能返回这个状态码。
• 406 Not Acceptable: 资源类型不合乎服务器要求。
• 407 Proxy Authorization Required: 须要代理受权。
• 408 Request Timeout：服务器将不再应用的连贯敞开。响应头会有 Connection: close。
• 426 Upgrade Required: 通知客户端须要降级通信协议。

5xx 解决产生谬误，责任在服务端，如服务端抛出异样，路由出错，HTTP 版本不反对等。

• 500 Internal Server Error: 服务器外部谬误，未捕捉。
• 502 Bad Gateway: 服务器作为网关应用时，收到上游服务器返回的有效响应。
• 503 Service Unavailable: 无奈服务。个别产生在因保护而停机或者服务过载。个别还会随同着返回一个响应头 Retry-After: 阐明复原服务的预计工夫。
• 504 Gateway Timeout: 网关超时。服务器作为网关或者代理，不能及时从上游服务器获取响应返回给客户端。
• 505 Http Version Not Supported: 收回的申请 http 版本服务器不反对。如果申请通过 http2 发送，服务器不反对 http2.0，就会返回该状态码。

5 浏览器缓存机制

咱们依据是否须要向服务器从新发动 HTTP 申请将缓存过程分为两个局部，别离是 强制缓存 和协商缓存。

5.1 强制缓存

强制缓存就是向浏览器缓存查找该申请后果，并依据该后果的缓存规定来决定是否应用该缓存后果的过程，强制缓存的状况次要有三种(暂不剖析协商缓存过程)，如下：

• 不存在该缓存后果和缓存标识，强制缓存生效，则间接向服务器发动申请（跟第一次发动申请统一）
• 存在该缓存后果和缓存标识，然而后果曾经生效，强制缓存生效，则应用协商缓存（暂不剖析）
• 存在该缓存后果和缓存标识，且该后果没有还没有生效，强制缓存失效，间接返回该后果

当浏览器向服务器发送申请的时候，服务器会将 缓存规定 放入 HTTP 响应的报文的 HTTP 头中和申请后果一起返回给浏览器，管制强制缓存的字段别离是 Expires 和 Cache-Control，其中 Cache-Conctrol 的优先级比 Expires 高

2.1.2Cache-Control

在 HTTP/1.1 中，Cache-Control 是最重要的规定，次要用于管制网页缓存，次要取值为：

• public：所有内容都将被缓存（客户端和代理服务器都可缓存）
• private：所有内容只有客户端能够缓存，Cache-Control 的默认取值
• no-cache：客户端缓存内容，然而是否应用缓存则须要通过协商缓存来验证决定
• no-store：所有内容都不会被缓存，即不应用强制缓存，也不应用协商缓存
• max-age=xxx (xxx is numeric)：缓存内容将在 xxx 秒后生效

5.2 协商缓存

协商缓存就是强制缓存生效后，浏览器携带缓存标识向服务器发动申请，由服务器依据缓存标识决定是否应用缓存的过程，次要有以下两种状况：

• 协商缓存失效，返回 304
• 协商缓存失败，返回 200 和申请后果

协商缓存的标识也是在响应报文的 HTTP 头中和申请后果一起返回给浏览器的，管制协商缓存的字段别离有：Last-Modified / If-Modified-Since 和 Etag / If-None-Match，其中 Etag / If-None-Match 的优先级比 Last-Modified / If-Modified-Since 高。

2.2.1Last-Modified / If-Modified-Since

• Last-Modified 是服务器响应申请时，返回该资源文件在服务器最初被批改的工夫
• If-Modified-Since 则是客户端再次发动该申请时，携带上次申请返回的 Last-Modified 值，通过此字段值通知服务器该资源上次申请返回的最初被批改工夫。服务器收到该申请，发现申请头含有 If-Modified-Since 字段，则会依据 If-Modified-Since 的字段值与该资源在服务器的最初被批改工夫做比照，若服务器的资源最初被批改工夫大于 If-Modified-Since 的字段值，则从新返回资源，状态码为 200；否则则返回 304，代表资源无更新，可持续应用缓存文件

Etag / If-None-Match

• Etag 是服务器响应申请时，返回以后资源文件的一个惟一标识
• If-None-Match 是客户端再次发动该申请时，携带上次申请返回的惟一标识 Etag 值，通过此字段值通知服务器该资源上次申请返回的惟一标识值。服务器收到该申请后，发现该申请头中含有 If-None-Match，则会依据 If-None-Match 的字段值与该资源在服务器的 Etag 值做比照，统一则返回 304，代表资源无更新，持续应用缓存文件；不统一则从新返回资源文件，状态码为 200

6 版本比照

http 协定目前有 4 个版本，其中 1.0、1.1 版本在互联网上被宽泛应用，2.0 版本目前开始逐渐失去利用，是新一代的 http 协定。

• http/0.9 版本：1991 年, 原型版本，性能简陋，只有一个命令 GET, 只反对纯文本内容，该版本已过期。
• http/1.0 版本: 1996 年 5 月, 反对 cache, MIME, method 等。
• http/1.1 版本: 1997 年 1 月, 默认建设长久连贯，并能很好地配合代理服务器工作。还反对以管道形式在同时发送多个申请，以便升高线路负载，进步传输速度。
• http/2 版本: 2015 年 5 月作为互联网规范正式公布, 头部信息和数据体都是二进制，引入头信息压缩机制等。

http1.0 版本

• 任何格局的内容都能够发送，这使得互联网不仅能够传输文字，还能传输图像、视频、二进制等文件。
• 除了 GET 命令，还引入了 POST 命令和 HEAD 命令。
• http 申请和回应的格局扭转，除了数据局部，每次通信都必须包含头信息（HTTP header），用来形容一些元数据。

http1.1 版本

• http1.1 是目前最为支流的 http 协定版本，从 1997 年公布至今，仍是支流的 http 协定版本。
• 引入了长久连贯（persistent connection），即 TCP 连贯默认不敞开，能够被多个申请复用，不必申明 Connection: keep-alive。
• 引入了管道机制（pipelining），即在同一个 TCP 连贯里，客户端能够同时发送多个申请，进一步改良了 HTTP 协定的效率。
• 新增办法：PUT、PATCH、OPTIONS、DELETE。
• http 协定不带有状态，每次申请都必须附上所有信息。申请的很多字段都是反复的，节约带宽，影响速度。

http2 版本

 为了解决 1.1 版本利用率不高的问题，提出了 HTTP/2.0 版本。减少双工模式，即不仅客户端可能同时发送多个申请，服务端也能同时解决多个申请，解决了队头梗塞的问题（HTTP2.0 应用了多路复用的技术，做到同一个连贯并发解决多个申请，而且并发申请的数量比 HTTP1.1 大了好几个数量级）；HTTP 申请和响应中，状态行和申请 / 响应头都是些信息字段，并没有真正的数据，因而在 2.0 版本中将所有的信息字段建设一张表，为表中的每个字段建设索引，客户端和服务端独特应用这个表，他们之间就以索引号来示意信息字段，这样就防止了 1.0 旧版本的反复繁琐的字段，并以压缩的形式传输，进步利用率。另外也减少服务器推送的性能，即不经申请服务端被动向客户端发送数据。
二进制协定

HTTP/1.1 版的头信息必定是文本（ASCII 编码），数据体能够是文本，也能够是二进制。HTTP/2 则是一个彻底的二进制协定，头信息和数据体都是二进制，并且统称为 ” 帧 ”（frame）：头信息帧和数据帧。

二进制协定的一个益处是，能够定义额定的帧。HTTP/2 定义了近十种帧，为未来的高级利用打好了根底。如果应用文本实现这种性能，解析数据将会变得十分麻烦，二进制解析则不便得多。

多工

HTTP/2 复用 TCP 连贯，在一个连贯里，客户端和浏览器都能够同时发送多个申请或回应，而且不必依照程序一一对应，这样就防止了 ” 队头梗塞 ”。

举例来说，在一个 TCP 连贯外面，服务器同时收到了 A 申请和 B 申请，于是先回应 A 申请，后果发现处理过程十分耗时，于是就发送 A 申请曾经解决好的局部，接着回应 B 申请，实现后，再发送 A 申请剩下的局部。

这样双向的、实时的通信，就叫做多工（Multiplexing）。

数据流

因为 HTTP/2 的数据包是不按程序发送的，同一个连贯外面间断的数据包，可能属于不同的回应。因而，必须要对数据包做标记，指出它属于哪个回应。

HTTP/2 将每个申请或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个举世无双的编号。数据包发送的时候，都必须标记数据流 ID，用来辨别它属于哪个数据流。另外还规定，客户端收回的数据流，ID 一律为奇数，服务器收回的，ID 为偶数。

数据流发送到一半的时候，客户端和服务器都能够发送信号（RST_STREAM帧），勾销这个数据流。1.1 版勾销数据流的惟一办法，就是敞开 TCP 连贯。这就是说，HTTP/2 能够勾销某一次申请，同时保障 TCP 连贯还关上着，能够被其余申请应用。

客户端还能够指定数据流的优先级。优先级越高，服务器就会越早回应。

头信息压缩

HTTP 协定不带有状态，每次申请都必须附上所有信息。所以，申请的很多字段都是反复的，比方 Cookie 和User Agent，截然不同的内容，每次申请都必须附带，这会节约很多带宽，也影响速度。

HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息应用 gzip 或compress压缩后再发送；另一方面，客户端和服务器同时保护一张头信息表，所有字段都会存入这个表，生成一个索引号，当前就不发送同样字段了，只发送索引号，这样就进步速度了。

服务器推送

HTTP/2 容许服务器未经请求，被动向客户端发送资源，这叫做服务器推送（server push）。

意思是说，当咱们对反对 HTTP2.0 的 web server 申请数据的时候，服务器会顺便把一些客户端须要的资源一起推送到客户端，省得客户端再次创立连贯发送申请到服务器端获取。这种形式十分适合加载动态资源。

服务器端推送的这些资源其实存在客户端的某处中央，客户端间接从本地加载这些资源就能够了，不必走网络，速度天然是快很多的。

常见场景是客户端申请一个网页，这个网页外面蕴含很多动态资源。失常状况下，客户端必须收到网页后，解析 HTML 源码，发现有动态资源，再收回动态资源申请。其实，服务器能够预期到客户端申请网页后，很可能会再申请动态资源，所以就被动把这些动态资源随着网页一起发给客户端了。

服务端推送能把客户端所须要的资源随同着 index.html 一起发送到客户端，省去了客户端反复申请的步骤。正因为没有发动申请，建设连贯等操作，所以动态资源通过服务端推送的形式能够极大地晋升速度。