1 HTTP 基本概念
- HTTP是 Hyper Text Transfer Protocol（ 超文本传输协定）的缩写。
- HTTP 协定（HyperText Transfer Protocol，超文本传输协定）是用于从 WWW 服务器传输超文本到本地浏览器的传送协定。它能够使浏览器更加高效，使网络传输缩小。它不仅保障计算机正确疾速地传输超文本文档，还确定传输文档中的哪一部分，以及哪局部内容首先显示 (如文本先于图形) 等。
- HTTP 是一个应用层协定，由申请和响应形成，是一个规范的客户端服务器模型。HTTP 是一个无状态的协定。
- HTTP 协定是一种应用层的传输协定，用于客户端和服务器之间的通信。
2 HTTP 罕用办法
| 办法 | 作用 | 阐明 | 反对版本 |
|---|---|---|---|
| GET | 获取资源 | GET 办法用来申请 URL 指定的资源。指定的资源经服务器端解析后返回响应内容 | 1.0/1.1 |
| POST | 传输实体主体 | POST 办法用来传输实体的主体 | 1.0/1.1 |
| PUT | 传输文件 | 就像 FTP 协定的文件上传一样，要求在申请报文主体中蕴含文件的内容，而后保留到申请 URL 指定的地位。不太罕用。 | 1.0/1.1 |
| HEAD | 取得报文首部 | HEAD 办法和 GET 办法一样，只是不返回报文主体局部。用于确认 URL 的有效性及资源更新的日期工夫等。 | 1.0/1.1 |
| DELETE | 删除文件 | DELETE 办法用来删除文件，是 PUT 的相同办法。DELETE 办法按申请 URL 删除指定的资源。也不罕用 | 1.0/1.1 |
| OPTIONS | 询问反对的办法 | OPTIONS 办法用来查问针对申请 URL 指定的资源反对的办法 | 1.1 |
| TRACE | 追踪门路 | TRACE 办法是让 Web 服务器端将之前的申请通信环回给客户端办法。客户端能够用 TRACE 办法查问发送进来的申请时怎么被加工批改的。不罕用，还容易引发 XST 攻打 | 1.1 |
| CONNECT | 要求用隧道协定链接代理 | CONNECT 办法要求在与代理服务器通信时建设隧道，实现用隧道协定进行 TCP 通信。次要应用 SSL 和 TSL 协定把通信内容加密后经网络隧道传输 | 1.1 |
2.1 OPTIONS 办法详解
OPTIONS 申请即 预检申请 ，可用于检测服务器容许的 http 办法。当发动跨域申请时，因为平安起因，触发肯定条件时浏览器会在正式申请之前 主动 先发动 OPTIONS 申请，即 CORS 预检申请，服务器若承受该跨域申请，浏览器才持续发动正式申请。
满足以下条件属于简略申请
- 申请形式只能是 GET、POST、HEAD
- HTTP 申请头限度这几种字段（Accept、Accept-Language、Content-Type、DPR、Downlink、Save-Data、Viewport-Width、Width）
- Content-Type：只能取 application/x-www-form-urlencoded、multipart/form-data、text/plain
- 申请中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象能够应用
- 申请中没有应用 ReadableStream 对象
3 申请报文与响应报文
3.1 申请报文
一个 HTTP 申请报文由申请行（request line）、申请头部（header）、空行和申请数据 4 个局部组成，下图给出了申请报文的个别格局。
1. 申请行
申请行分为三个局部：申请办法、申请地址和协定版本
2. 申请头部
申请头部为申请报文增加了一些附加信息，由“名 / 值”对组成，每行一对，名和值之间应用冒号分隔。
常见申请头如下：
| 申请头 | 阐明 |
|---|---|
| Accept | 可承受的响应内容类型（Content-Types） |
| Accept-Encoding | 可承受的字符集 |
| Accept-Language | 可承受的响应内容的编码方式 |
| Cache-Control | 用来指定以后的申请 / 回复中的，是否应用缓存机制。 |
| Connection | 由之前服务器通过Set-Cookie（见下文）设置的一个 HTTP 协定 Cookie |
| Cookie | 示意服务器的域名以及服务器所监听的端口号。如果所申请的端口是对应的服务的规范端口（80），则端口号能够省略。 |
| Host | 示意服务器的域名以及服务器所监听的端口号。如果所申请的端口是对应的服务的规范端口（80），则端口号能够省略。 |
| Referer | 示意浏览器所拜访的前一个页面，能够认为是之前拜访页面的链接将浏览器带到了以后页面。Referer其实是 Referrer 这个单词，但 RFC 制作规范时给拼错了，起初也就一误再误应用 Referer 了。 |
| User-Agent | 浏览器的身份标识字符串 |
3. 申请数据
可选局部，比方 GET 申请就没有申请数据。
而一个 POST 办法就会有申请体
响应报文
HTTP 响应报文次要由状态行、响应头部、空行以及响应数据组成。
1. 状态行
由 3 局部组成，别离为：协定版本，状态码，状态码形容。（状态码会在前面介绍）
2. 响应头部
与申请头部相似，为响应报文增加了一些附加信息
常见响应头部如下：
| 响应头 | 阐明 |
|---|---|
| Access-Control-Allow-Origin | 指定哪些网站能够 跨域源资源共享 |
| Age | 响应对象在代理缓存中存在的工夫，以秒为单位 |
| Cache-Control | 告诉从服务器到客户端内的所有缓存机制，示意它们是否能够缓存这个对象及缓存无效工夫。其单位为秒 |
| Connection | 针对该连贯所预期的选项 |
| Content-Type | 以后内容的 MIME 类型 |
| Location | 用于在进行重定向，或在创立了某个新资源时应用。 |
| Status | 通用网关接口的响应头字段，用来阐明以后 HTTP 连贯的响应状态。 |
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 一起发送到客户端，省去了客户端反复申请的步骤。正因为没有发动申请，建设连贯等操作，所以动态资源通过服务端推送的形式能够极大地晋升速度。