HTTP/0.9
Http0.9只用于传输html文件 1991年主要用于学术交流。
采用了基于请求和响应的模式，客户端发请求，服务器响应数据。
客户端->构建请求->通过DNS查询IP地址->三次握手建立TCP连接->客户端发起请求->服务器响应->四次回收断开TCP连接。
Http是基于TCP协议的，客户端基于IP和端口与服务器建立TCP连接，建立连接的过程就是TCP协议的三次握手的过程。
建立TCP连接之后，会发送一个GET请求行的信息。
HTTP1.0
解决多种类型下载，通过请求头和响应头。有了响应头，浏览器会使用gzip方式来解压文件，再按照UTF-8的编码格式来处理原始文件，最后按照HTML的方式来解析文件。
引入了请求状态码，用来告知浏览器服务器最终的处理结果
引入
cache机制，用来减轻服务器压力，缓存已经下载过的数据用户代理，服务器统计客户端的基础信息
如何实现多种类型文件的下载？
HTTP/0.9建立连接后，只会发送类型GET/index.html这样简单的请求命令，没有告诉服务器更多的信息。同样服务器会直接返回数据给浏览器，不会告诉浏览器关于服务器返回的文件信息。
为了让客户端和服务器能够深入的交流，HTTP/1.0引入了请求头和响应头，他们都以key-value形式保存的，在HTTP发送请求时，会带上请求头信息。服务器返回数据时，会先返回响应头信息。
HTTP/1.1
- 改进持久连接,在一个TCP连接上可以传输多个HTTP请求，只要浏览器或服务器没有明确断开连接，那么该TCP连接会一直保持。使用
connection:keep-alive来进行标识。在浏览器上可以通过Protocol字段看到http版本（打开调试工具，切到network右键http请求的标题，然后会出现一个弹框，勾选Protocol即可）。每次http通信，都需要经历TCP连接，输出HTTP数据，断开TCP连接3个阶段
HTTP/2
http2一个域名只使用一个TCP长连接和消除队头阻塞问题。
有哪些变化？主要是性能优化
HTTP1.X以换行符作为纯文本的分隔符。
HTTP/2将所有传输的信息分割为更小的消息和帧，并对他们采用二进制格式的编码。数据流以消息的形式发送，而消息由一个或多个帧组成，帧可以在数据流上乱序发送，然后再根据每个帧首部的流标识符重新组装。二进制分帧是HTTP/2的基石，其他优化都是再这一基础上来实现的。
多路复用
-
在http1.x中，如果想并发多个请求，必须使用多个TCP连接，且浏览器为了控制资源，还会对单个域名有6-8的个数限制。针对这一问题，可以使用合并请求、图片精灵、散列域名等。
在HTTP/2中，有了二进制分帧之后，http2.0不再依赖TCP去实现多流并行了
同域名下所有通信都在单连接上完成
单个连接可以承载任意数量的双向数据流
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。
同个域名只需要占用一个TCP连接，消除了因多个TCP连接而带来得延时和内存消耗。
单个连接上可以并行交错得请求和响应，之间互不干扰。
-
流优先级
在HTTP/2中，每个请求都可以带一个31bit得优先值，0表示最高优先级，数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同得流时采取不同得策略，以最优的方式发送流、消息和帧。
-
服务器推送
服务器除了响应客户端的请求外，还可以向客户端额外推送资源。
服务器推送的资源有自己独立的URL，可以被浏览器缓存，可以达到多页面共享
资源推送遵守同源策略，服务器不可随便推送第三方资源给客户端
客户端可以拒绝推送过来的资源
可以通过额外的http头部，列出需要服务器推送哪些资源。
服务器可以解析请求的Html，推测出客户端接下来需要请求的资源，然后提前向客户端推送。
-
头部压缩
HTTP/2在客户端和服务器端使用”首部表“来跟踪和存储之前发送的键-值对，不再通过每次请求和响应发送。
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新。
每个新的首部键-值对要么被追加到当前表的末尾，妖魔替换表中之前的值。
-
应用层协商协议
客户端、服务器都需要升级才能支持HTTP 2.0，升级过程中就存在HTTP1.1、HTTP 2.0并存的情况，APLN解决
客户端发起请求，如果支持HTTP/2，则带upgrade头部:
服务器不支持，则拒绝升级，通过HTTP1.1返回响应
服务器支持，则接受升级，切换到新分帧，使用HTTP/2通信。
无论是那种情况，都不需要额外的往返，如果客户端通过记录或者其他方式，知道服务器支持HTTP/2，则直接使用HTT/2通信，无需再协议协商。
