共计 2718 个字符，预计需要花费 7 分钟才能阅读完成。
HTTP1.0 和 HTTP1.1 的一些区别
缓存解决
在 HTTP1.0 中次要应用 header 里的 If-Modified-Since（比拟资源最初的更新工夫是否统一）,Expires（资源的过期工夫（取决于客户端本地工夫））来做为缓存判断的规范。
HTTP1.1 则引入了更多的缓存控制策略：
Entity tag：资源的匹配信息If-Unmodified-Since：比拟资源最初的更新工夫是否不统一If-Match：比拟 ETag 是否统一If-None-Match：比拟 ETag 是否不统一
等更多可供选择的缓存头来管制缓存策略。
带宽优化
HTTP1.0 中，存在一些节约带宽的景象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，并且不反对断点续传性能。
HTTP 1.1 默认反对断点续传。
Host 头解决
在 HTTP1.0 中认为每台服务器都绑定一个惟一的 IP 地址，因而，申请音讯中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的倒退，在一台物理服务器上能够存在多个虚拟主机，并且它们共享一个 IP 地址。HTTP1.1 的申请音讯和响应音讯都应反对 Host 头域，且申请音讯中如果没有 Host 头域会报告一个谬误（400 Bad Request）。
长连贯
HTTP1.0 须要应用 keep-alive 参数来告知服务器端要建设一个长连贯，而 HTTP1.1 默认反对长连贯，肯定水平上补救了 HTTP1.0 每次申请都要创立连贯的毛病。
HTTP 是基于 TCP/IP 协定的，创立一个 TCP 连贯是须要通过三次握手的, 有肯定的开销，如果每次通信都要从新建设连贯的话，对性能有影响。因而最好能维持一个长连贯，能够用个长连贯来发多个申请。
HTTP1.1 反对长连贯（PersistentConnection）和申请的流水线（Pipelining）解决，在一个 TCP 连贯上能够传送多个 HTTP 申请和响应，缩小了建设和敞开连贯的耗费和提早。
谬误告诉的治理
在 HTTP1.1 中新增了 24 个谬误状态响应码，如 409（Conflict）示意申请的资源与资源的以后状态发生冲突；410（Gone）示意服务器上的某个资源被永久性的删除。
新增申请形式
- PUT：申请服务器存储一个资源
- DELETE：申请服务器删除标识的资源
- OPTIONS：申请查问服务器的性能，或者查问与资源相干的选项和需要
- CONNECT：保留申请以供未来应用
- TRACE：申请服务器回送收到的申请信息，次要用于测试或诊断
HTTP2.0 与 HTTP1.X 的区别
HTTP1.X 版本的缺点概括来说是：线程阻塞，在同一时间，同一域名的申请有肯定的数量限度，超过限度数目的申请会被阻塞。
二进制分帧
HTTP1.x 的解析是基于文本。基于文本协定的格局解析存在人造缺点，文本的表现形式有多样性，要做到健壮性思考的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种思考 HTTP2.0 的协定解析决定采纳二进制格局，实现不便且强壮。
HTTP2.0 在 应用层 (HTTP2.0) 和传输层 (TCP/UDP) 之间减少一个二进制分帧层。在不改变 HTTP1.X 的语义、办法、状态码、URI 以及首部字段的状况下, 解决了 HTTP1.1 的性能限度，改良传输性能，实现低提早和高吞吐量。在二进制分帧层中，HTTP2.0 会将所有传输的信息宰割为更小的音讯和帧（frame）, 并对它们采纳二进制格局的编码，其中 HTTP1.X 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 外面。
- 帧：HTTP2.0 数据通信的最小单位音讯：指 HTTP2.0 中逻辑上的 HTTP 音讯。例如申请和响应等，音讯由一个或多个帧组成。
- 流：存在于连贯中的一个虚构通道。流能够承载双向音讯，每个流都有一个惟一的整数 ID。
多路复用（MultiPlexing）
多路复用容许同时通过繁多的 HTTP2.0 连贯发动多重的申请 - 响应音讯。即是连贯共享，进步了连贯的利用率，升高提早。即每一个 request 都是是用作连贯共享机制的。一个 request 对应一个 id，这样一个连贯上能够有多个 request，每个连贯的 request 能够随机的混淆在一起，接管方能够依据 request 的 id 将 request 再归属到各自不同的服务端申请外面。
在 HTTP1.1 协定中浏览器客户端在同一时间，针对同一域名下的申请有肯定数量限度。超过限度数目的申请会被阻塞。这也是为何一些站点会有多个动态资源 CDN 域名的起因之一。
当然 HTTP1.1 也能够多建设几个 TCP 连贯，来反对解决更多并发的申请，然而创立 TCP 连贯自身也是有开销的。
TCP 连贯有一个预热和爱护的过程，先检查数据是否传送胜利，一旦胜利过，则缓缓加大传输速度。因而对应刹时并发的连贯，服务器的响应就会变慢。所以最好能应用一个建设好的连贯，并且这个连贯能够反对刹时并发的申请。
HTTP2.0 能够很容易的去实现多流并行而不必依赖建设多个 TCP 连贯，同个域名只须要占用一个 TCP 连贯，打消了因多个 TCP 连贯而带来的延时和内存耗费。HTTP2.0 把 HTTP 协定通信的根本单位放大为一个一个的帧，这些帧对应着逻辑流中的音讯。并行地在同一个 TCP 连贯上双向替换音讯。
header 压缩
HTTP1.x 的 header 带有大量信息，而且每次都要反复发送，HTTP2.0 应用 HPACK 算法对 header 的数据进行压缩，缩小须要传输的 header 大小，通信单方各自 cache 一份 header fields 表，差量更新 HTTP 头部，既防止了反复 header 的传输，又减小了须要传输的大小。
header 采取的压缩策略：
- HTTP2.0 在客户端和服务器端应用“首部表”来跟踪和存储之前发送的键-值对，对于雷同的数据，不再通过每次申请和响应发送；
- 首部表在 HTTP2.0 的连贯存续期内始终存在，由客户端和服务器独特渐进地更新;
- 每个新的首部键-值对要么被追加到以后表的开端，要么替换表中之前的值。
服务端推送（server push）
服务端推送是一种在客户端申请之前发送数据的机制。
服务端能够在发送页面 HTML 时被动推送其它资源，而不必等到浏览器解析到相应地位，发动申请再响应。例如服务端能够被动把 JS 和 CSS 文件推送给客户端，而不须要客户端解析 HTML 时再发送这些申请。
服务器端推送的这些资源其实存在客户端的某处中央，客户端间接从本地加载这些资源就能够了，不必走网络，速度天然是快很多的。
参考文章：
- HTTP1.0，HTTP1.1，HTTPS 和 HTTP2.0 的区别
- 一文读懂 HTTP/2 个性
- ps：集体技术博文 Github 仓库，感觉不错的话欢送 star，给我一点激励持续写作吧~