共计 3584 个字符，预计需要花费 9 分钟才能阅读完成。
一、定义
http 协定：超文本传输协定（通信协议），用于从服务器传输超文本到本地浏览，建设再 TCP/IP 协定根底上
三个特点：
1、无连贯
是限度每次连贯只解决一个申请。服务器解决完客户的申请，并收到客户的应答后，即断开连接。采纳这种形式能够节俭传输工夫
2、无状态
是指协定对于事务处理没有记忆能力。短少状态意味着如果后续解决须要后面的信息，则它必须重传，这样可能导致每次连贯传送的数据量增大。另一方面，在服务器不须要先前信息时它的应答就较快
3、灵便
容许传输任意类型的数据对象。传输的类型由 Content-Type（Content-Type 是 HTTP 包中用来示意内容类型的标识）加以标记
HTTP/0.9 版本
特点：构造简略，仅有 GET 申请，纯文本格式
例如 GET /index.html
示意：TCP 建设连贯后，客户端向服务端申请 index.html 页面，协定规定，服务端只能返字符串，返回后即敞开 TCP 链接，如果申请的页面不存在，也不反悔任何错误码，这也是无状态的一个体现
HTTP/1.0 版本
相比拟上一个版本减少了如下次要内容：
- 减少了 post 申请，丰盛了浏览器与客户端的互动伎俩
- 传输数据不限于文本，能够是图片、视频、二进制文件等内容
- 减少了协定版本号
- 减少的响应状态码
- 引入了 HTTP HEADER（头部）概念，让 HTTP 解决申请更加灵便
GET /HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>其中 content-type 是体现灵便的字段，咱们常见的 value 值包含：text/html, text/css, image/png, application/javascript, application/x-www-form-urlencoded form, Multipart/form-data，以上数据统称为 MIME 类型。
1.0 的毛病：
连贯无奈复用 ：每个 TCP 连贯只能发送一个申请。发送数据结束，连贯就敞开，如果还要申请其余资源，就必须再新建一个连贯。
为了解决这个问题，有些浏览器在申请时，用了一个非标准的 Connection 字段：Connection: keep-alive，示意 TCP 能够复用，直到被动敞开链接。
下面是又没有 keep-alive 的区别，然而这不是规范字段，不同实现的行为可能不统一，因而不是基本的解决办法，并且 TCP 的新建老本很高，因为每次链接服务端和客户端都须要通过三次握手，并且开始时发送的速率较慢。
HTTP/1.1 版本
也就是目前地位用的最多的一个版本，相比拟 1.0 版本减少了：
- 长久链接，默认 TCP 不敞开，能够被多个申请复用，不必申明 connection:keep-alive 字段
- 新增了 PUT、PATCH、OPTIONS、DELETE 申请办法，也新增了许多状态码
- 强制 HOST 头：HTTP1.0 中认为每台服务器都绑定一个惟一的 IP 地址，因而，申请音讯中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的倒退，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的申请音讯和响应音讯都应反对 Host 头域，且申请音讯中如果没有 Host 头域会报告一个谬误（400 Bad Request）。有了 Host 字段，就能够将申请发往同一台服务器上的不同网站，为虚拟主机的衰亡打下了根底
- 缓存解决：HTTP/1.0 应用 Pragma:no-cache + Last-Modified/If-Modified-Since + Expire 来作为缓存判断的规范；HTTP/1.1 引入了更多的缓存控制策略：Cache-Control、Etag/If-None-Match
-
管道机制（pipelining）：即在同一个 TCP 链接外面，客户端能够共事发送多个申请。从而进一步改善 HTTP 协定的效率问题
例如：客户端须要申请两个资源。以前的做法是，在同一个 TCP 连贯外面，先发送 A 申请，而后期待服务器做出回应，收到后再收回 B 申请。管道机制则是容许浏览器同时收回 A 申请和 B 申请，然而服务器还是依照程序，先回应 A 申请，实现后再回应 B 申请, 通过下图能够很清晰的看出区别
1.1 毛病：
尽管 1.1 版容许复用 TCP 连贯，然而同一个 TCP 连贯外面，所有的数据通信是按秩序进行的。服务器只有解决完一个回应，才会进行下一个回应。要是后面的回应特地慢，前面就会有许多申请排队等着。这称为“队头梗塞 ”（Head-of-line blocking）
解决方案：
1、缩小申请数量（雪碧图）
2、多开长久链接，如下图中并行的申请，就是多开了几个 TCP 链接，然而浏览器也有规定，同一域名下 TCP 开启的个数时无限，个别不超过 10 个，这也是 SEO 中，将资源 CDN 的起因。
个人见解：1.1 版本中减少了许多头部的标识，使得申请更加的灵便，例如类型、缓存等等！利用好了能大幅晋升申请效率，也能够当作优化的重点去攻克！然而也有太多的字段须要去学习，有利有弊吧! 接下来就是重点 HTTP/2
HTTP/ 2 版本
为什么是 2 而不是 2.0，因为规范委员会不筹备公布子版本，下一个版本将是 HTTP/3
1、二进制传输：在 HTTP1.x 中，咱们是通过文本的形式传输数据。基于文本的形式传输数据存在很多缺点，文本的表现形式有多样性，因而要做到健壮性思考的场景必然有很多，然而二进制则不同，只有 0 和 1 的组合，因而抉择了二进制传输，实现不便且强壮。为了保障 HTTP 不受影响，那就须要在应用层（HTTP2.0）和传输层（TCP or UDP）之间减少一个二进制分帧层。在二进制分帧层上，HTTP2.0 会将所有传输的信息分为更小的音讯和帧，并采纳二进制格局编码，其中 HTTP1.x 的首部信息会被封装到 Headers frame，而 Request Body 则封装到 Data frame。
2、头部压缩（Header Compression）：专门为头部压缩设计了 Hpack 算法，简略来说就是客户端和服务端独特保护一份雷同的动态表和动静表，在编码时间接用表的 index 代替，能够大幅升高头部大小
3、服务端推送（server push）：容许服务器未经请求，次要向客户端发送资源。
客户端申请一个网页，这个网页外面蕴含很多动态资源。失常状况下，客户端必须收到网页后，解析 HTML 源码，发现有动态资源，再收回动态资源申请。其实，服务器能够预期到客户端申请网页后，很可能会再申请动态资源，所以就被动把这些动态资源随着网页一起发给客户端了
4、多路复用：也是最重要的一项，起因是 1.X 版本中的“队头阻塞”，这外面有三个比拟重要的概念
- 音讯：逻辑上的 http 音讯，比方一系列 Data frame 和 一个 Header frame 组成的申请音讯
- 帧（frame）：最小的数据单位
- 流（stream）：多个帧组成数据流，每个帧会标识出该帧属于哪个流，艰深讲流是连贯中的一个虚构信道，能够承载双向音讯传输，每一个流都有惟一的标识，为了避免两个流 ID 抵触，客户端发动的流具备奇数 ID，服务端发动的流具备偶数 ID，所有的 HTTP2 通信都在一个 TCP 链接上实现，这个连贯能够承载任意数量的双向数据流 Stream。相应地，每个数据流以 音讯的模式发送，而音讯由一 或多个帧组成，这些帧能够乱序发送，而后依据每个帧首部的流标识符从新组装。
举个例子，每个申请是一个数据流，数据流以音讯的形式发送，而音讯又分为多个帧，帧头部记录着 stream id 用来标识所属的数据流，不同属的帧能够在连贯中随机混淆在一起。接管方能够依据 stream id 将帧再归属到各自不同的申请当中去。
另外，多路复用（连贯共享）可能会导致要害申请被阻塞。HTTP2 里每个数据流都能够设置优先级和依赖，优先级高的数据流会被服务器优先解决和返回给客户端，数据流还能够依赖其余的子数据流。
可见，HTTP2 实现了真正的并行传输，它可能在一个 TCP 上进行任意数量 HTTP 申请。而这个弱小的性能则是基于“二进制分帧”的个性。
宏观上看，基于二进制分帧层，htp2 能够在共享 TCP 链接的根底上，同时发送申请和响应，HTTP 音讯被合成为独立的帧，交织收回，最初在另一端依据 ID 和首部将它们重新组合起来。
以上就是 HTTP2 次要的特点，接下来会是 HTTP3 的特点，未完待续。。。。
