[网络通信协议]HTTP各版本

HTTP1.0

是一种无状态、无连接的应用层协议。

特点

HTTP1.0规定浏览器和服务器保持短暂的连接，

浏览器的每次请求都需要与服务器建立一个TCP连接，

服务器处理完成后立即断开TCP连接（无连接），

服务器不跟踪每个客户端也不记录过去的请求（无状态）。

缺点

无连接的特性导致最大的性能缺陷就是无法复用连接。

​ 每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。

队头阻塞（head of line blocking）

​ 由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

身份认证和状态记录

​ 借助cookie/session机制

HTTP1.1

继承了HTTP1.0简单的特点，克服了诸多HTTP1.0性能上的问题。

优点

长连接

HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。

管道机制

HTTP1.1支持请求管道化（pipelining）。基于HTTP1.1的长连接，管线化使得请求能够“并行”传输。

请求可以同时发出，但是响应必须按照请求发出的顺序依次返回，性能在一定程度上得到了改善，简单图示如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iOqGPDZJ-1576468802091)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image002.gif)]

需要注意的是，服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）。

不允许同时存在两个并行的响应。

无法解决队头阻塞（head of line blocking）的问题。

同时“管道化”技术存在各种各样的问题，所以很多浏览器要么根本不支持它，要么就直接默认关闭，并且开启的条件很苛刻…而且实际上好像并没有什么用处。

分块传输

可以没必要等待数据完全处理完毕再返回，服务器产生部分数据，那么就发送部分数据，很明此种方式更加优秀一些，可以节省很多等待时间。

host字段

使得一个服务器能够用来创建多个Web站点

在头部增加host字段最大的受益者应该是资金微弱的个人站长。

因为在部署网站的时候没有必要买昂贵的独立服务器，只要买虚拟主机即可，成本大大降低。

此字段可以指定请求的服务器域名，下面是本站的一个HTTP请求头的截图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4pSLBHGF-1576468802095)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image004.gif)]

缓存处理

强缓存和协商缓存

cache-contro字段

断点传输

缺点

（1）.此版本的网络延迟问题主要由于队头堵塞导致，虽然通过持久性连接得到改善，但是每一个请求的响应依然需要按照顺序排队，如果前面的响应处理较为耗费时间，那么同样非常耗费性能。

（2）.还有此版本虽然引进了管道机制，但是当前存在诸多问题，且默认处于关闭状态。

解决上述问题导致的延迟，可以有两种方式，一种是在当前版本基础上通过各种现有技术手段实现，另一种是应用http2版本，虽然当前浏览器支持或者其他方面问题较多，相信不远的将来此版本一定会得到广泛应用。

HTTP2.0

HTTP/2（超文本传输协议第2版，最初命名为HTTP 2.0），是HTTP协议的的第二个主要版本，使用于万维网。HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY****协议（是Google开发的基于TCP的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验）。

二进制分帧

HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。

可见，虽然HTTP2.0的协议和HTTP1.x协议之间的规范完全不同了，但是实际上HTTP2.0并没有改变HTTP1.x的语义。

简单来说，HTTP2.0只是把原来HTTP1.x的header和body部分用frame重新封装了一层而已。

比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。

多路复用（连接共享）

下面是几个概念：

· 流（stream）：已建立连接上的双向字节流。

· 消息：与逻辑消息对应的完整的一系列数据帧。

· 帧（frame）：HTTP2.0通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id）。

从图中可见，所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。

每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（stream id）重新组装。

举个例子，每个请求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记录着stream id用来标识所属的数据流，不同属的帧可以在连接中随机混杂在一起。接收方可以根据stream id将帧再归属到各自不同的请求当中去。

另外，多路复用（连接共享）可能会导致关键请求被阻塞。HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量HTTP请求。而这个强大的功能则是基于“二进制分帧”的特性。

HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载一个页面。

头部压缩

在HTTP1.x中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500~800字节的负荷。

比如说cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发送给服务器。（由于cookie比较大且每次都重复发送，一般不存储信息，只是用来做状态记录和身份认证）

HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。

假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。

服务器推送

服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。

当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。

优点

1、采用二进制格式传输数据，而非http1.1文本格式，二进制格式在协议的解析和优化扩展上带来了跟多的优势和可能

2、对消息头采用Hpack进行压缩传输，能够节省消息头占用的网络流量，http1.1每次请求，都会携带大量冗余的头信息，浪费了很多宽带资源。

3、异步连接多路复用

4、Server Push，服务器端能够更快的把资源推送到客户端。

5、保持与HTTP 1.1语义的向后兼容性也是该版本的一个关键。

区别对比

HTTP2.0与HTTP 1.1的区别

HTTP/2采用二进制格式而非文本格式

HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行

使用报头压缩，HTTP/2降低了开销

HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

HTTP1.1的合并请求是否适用于HTTP2.0

没有必要，是因为这跟HTTP2.0的头部压缩有很大的关系。

在头部压缩技术中，客户端和服务器均会维护两份相同的静态字典和动态字典。

在静态字典中，包含了常见的头部名称以及头部名称与值的组合。静态字典在首次请求时就可以使用。那么现在头部的字段就可以被简写成静态字典中相应字段对应的index。

而动态字典跟连接的上下文相关，每个HTTP/2连接维护的动态字典是不尽相同的。动态字典可以在连接中不听的进行更新。

也就是说，原本完整的HTTP报文头部的键值对或字段，由于字典的存在，现在可以转换成索引index，在相应的端再进行查找还原，也就起到了压缩的作用。

所以，同一个连接上产生的请求和响应越多，动态字典累积得越全，头部压缩的效果也就越好，所以针对HTTP/2网站，最佳实践是不要合并资源。

另外，HTTP2.0多路复用使得请求可以并行传输，而HTTP1.1合并请求的一个原因也是为了防止过多的HTTP请求带来的阻塞问题。而现在HTTP2.0已经能够并行传输了，所以合并请求也就没有必要了。