http各个版本（11.12）对比

http 各个版本（11.12）对⽐
⽬录:
参考的⽂章:
http1.1 长连接
HTTP1.1默认使⽤长连接，可有效减少TCP 的三次握⼿开销。

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建⽴⼀个TCP 连接，服务器完成请求处理后⽴即断开TCP 连接
当⼀个⽹页⽂件中包含了很多图像的地址的时候，那就需要很多次的http 请求和响应，每次请求和响应都需要⼀个单独的连接，每次连接只是传输⼀个⽂档和图像，上⼀次和下⼀次请求完全分离。

即使图像⽂件都很⼩，但是客户端和服务器端每次建⽴和关闭连接却是⼀个相对⽐较费时的过程，并且会严重影响客户机和服务器的性能。

当⼀个⽹页⽂件中包含JavaScript ⽂件，CSS ⽂件等内容时，也会出现类似上述的情况。

为了克服HTTP 1.0的这个缺陷，HTTP 1.1⽀持持久连接（HTTP/1.1的默认模式使⽤带流⽔线的持久连接），在⼀个TCP 连接上可以传送多个HTTP 请求和响应，减少了建⽴和关闭连接的消耗和延迟。

⼀个包含有许多图像的⽹页⽂件的多个请求和应答可以在⼀个连接中传输，但每个单独的⽹页⽂件的请求和应答仍然需要使⽤各⾃的连接。

HTTP 1.1还允许客户端不⽤等待上⼀次请求结果返回，就可以发出下⼀次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。

通过请求头中connection 字段在表明是否⽀持长链接
在http1.1中，client 和server 都是默认对⽅⽀持长链接的(即connection 的值默认我Keep-Alive)， 如果client 使⽤http1.1协议，但⼜不希望使⽤长链接，则需要在header 中指明connection 的值为closer(connection 默认为Keep-Alive)；如果server ⽅也不想⽀持长链接，则在response 中也需要明确说明connection 的值为closer 。

不论request 还是response 的header 中包含了值为closer 的connection ，都表明当前正在使⽤的tcp 链接在当天请求处理完毕后会被断掉。

以后client 再进⾏新的请求时就必须创建新的tcp 链接了。

HTTP 1.1⽀持只发送header 信息(不带任何body 信息)
如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。

客户端如果接受到100，才开始把请求body 发送到服务器。

这样当服务器返回401的时候，客户端就可以不⽤发送请求body 了，节约了带宽。

另外HTTP 还⽀持传送内容的⼀部分。

这样当客户端已经有⼀部分的资源后，只需要跟服务器请求另外的部分资源即可。

这是⽀持⽂件断点续传的基础。

RANGE:bytes 是HTTP/1.1新增内容，HTTP/1.0每次传送⽂件都是从⽂件头开始，即0字节处开始。

RANGE:bytes=XXXX 表⽰要求服务器从⽂件XXXX 字节处开始传送，这就是我们平时所说的断点续传！
http1.1 host 请求头
HTTP1.0是没有host 域的，HTTP1.1才⽀持这个参数。

1.0中WEB 浏览器⽆法使⽤主机头名来明确表⽰要访问服务器上的哪个WEB 站点，这样就⽆法使⽤WEB 服务器在同⼀个IP 地址和端⼝号上配置多个虚拟WEB 站点。

在HTTP 1.1中增加Host 请求头字段后，WEB 浏览器可以使⽤主机头名来明确表⽰要访问服务器上的哪个WEB 站###
点，这才实现了在⼀台WEB 服务器上可以在同⼀个IP 地址和端⼝号上使⽤不同的主机名来创建多个虚拟WEB 站点。

HTTP 1.1还提供了与⾝份认证、状态管理和Cache 缓存等机制相关的请求头和响应头。

HTTP2.0使⽤多路复⽤技术(Multiplexing)
多路复⽤允许同时通过单⼀的 HTTP/2 连接发起多重的请求-响应消息。

"HTTP1.1在同⼀时间对于同⼀个域名的请求数量有限制，超过限制就会阻塞请求"。

多路复⽤底层采⽤增加⼆进制分帧层的⽅法，使得不改变原来的语义、⾸部字段的情况下提⾼传输性能，降低延迟。

⼆进制分帧将所有传输信息分割为更⼩的帧，⽤⼆进制进⾏编码，多个请求都在同⼀个TCP 连接上完成，可以承载任意数量的双向数据流。

HTTP/2更有效的使⽤TCP 连接，得到性能上的提升。

⼆进制分帧层把数据转换为⼆进制的同时，也把数据分成了⼀个⼀个的帧。

帧是HTTP/2中数据传输的最⼩单位；每个帧都有stream_ID 字段，表⽰这个帧属于哪个流，接收⽅把stream_ID 相同的所有帧组合到⼀起就是被传输的内容了。

⽽流是HTTP/2
中的⼀个逻辑上的概念，它代表着HTTP/1.1中的⼀个请求或者⼀个响应，协议规定client 发给server 的流的stream_ID 为奇
数，server 发给client 的流ID 是偶数。

需要注意的是，流只是⼀个逻辑概念，便于理解和记忆的，实际并不存在。

在⼀个TCP 链接中，可以同时双向地发送帧，⽽且不同流中的帧可以交错发送，不需要等某个流发送完，才发送下⼀个。

也就是
说在⼀个TCP 连接中，可以同时传输多个流，即可以同时传输多个HTTP 请求和响应，这种同时传输不需要遵循先⼊先出等规
定，因此也不会产⽣阻塞，效率极⾼。

HTTP/2新增⾸部压缩（Server Push ）:采⽤HPACK 算法
在 HTTP/1 中，HTTP 请求和响应都是由「状态⾏、请求 / 响应头部、消息主体」三部分组成。

⼀般⽽⾔，消息主体都会经过
gzip 压缩，或者本⾝传输的就是压缩过后的⼆进制⽂件（例如图⽚、⾳频），但状态⾏和头部却没有经过任何压缩，直接以纯⽂本传输。

随着 Web 功能越来越复杂，每个页⾯产⽣的请求数也越来越多，根据 HTTP Archive 的统计，当前平均每个页⾯都会产⽣上百
个请求。

越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent 、Cookie 这类不会频繁变动的内
容，完全是⼀种浪费。

Hapck 原理:具体规则可以描述为：通信双⽅共同维护了⼀份静态表，包含了常见的头部名称与值的组合根据先⼊先出的原则，维护⼀份可动态添加内容的动态表
⽤基于该静态哈夫曼码表的哈夫曼编码数据
当要发送⼀个请求时，会先将其头部和静态表对照，对于完全匹配的键值对，可以直接使⽤⼀个数字表⽰，如method:
GET ，对于头部名称匹配的键值对，可以将名称使⽤⼀个数字传输，同时告诉服务端将它添加到动态表中，以后的相同键
值对就⽤⼀个数字表⽰了。

这样，像cookie 这些不经常变动的值，只⽤发送⼀次就好了。

HTTP/2新增服务端推送（Header Compression ）即服务器发送/user.html 时，就可以主动把/user.js 和style.css push 给浏览器，使资源提前达到浏览器；除了静态⽂件，还可以推送⽐较耗时的API ，只是需要提前将参数和cookie 等信息通过某个⽅式告知服务端（如和路由关联）。

Apache 、GO 的net/http 、node-spdy 都实现了server push （但ngnix 没有=_=）
Server push 是HTTP/2协议⾥⾯唯⼀⼀个需要开发者⾃⼰配置的功能。

其他功能都是服务器和浏览器⾃动实现，⽆需开发者介⼊。

在HTTP1.1时代，也有提前获取资源的⽅法，如preload 和prefetch ，前者是在页⾯解析初期就告诉浏览器，这个资源是浏览器马上要⽤到的，可以⽴刻发送对资源的请求，当需要⽤到该资源时就可以直接⽤⽽不⽤等待请求和响应的返回了；后者是当前页⾯⽤不到但下⼀页⾯可能会⽤到的资源，优先级较低，只有当浏览器空闲时才会请求prefetch 标记的资源。

从应⽤层⾯上看，preload 和server push 并没有什么区别，但是server push 减少浏览器请求的时间，略优于preload ，在⼀些场景中，可以将两者结合使⽤。

###。