温故知新，HTTP/2

去年年底，据国际互联网工程任务组( IETF )消息，HTTP-over-QUIC 实验性协议将被重命名为 HTTP/3，即有望成为 HTTP 协议的第三个正式版本，也就是说HTTP/3可能要来了。 该消息是如此的惹人注目，是因为HTTP是我们身边的协议，Web应用都离不开它。

#a6c5c3c4024fb292cf290cabc67fdf5e#

温故知新，梳理一下过往，或许更能够理解未来。

HTTP1.x的过往

HTTP协议大约诞生在我上大一的时候，好像是HTTP0.9，客户端请求和服务器响应都是ascii码，客户端以回车符结尾，服务器返回HTML。后来的HTTP1.0，服务器响应增加了很多状态，请求和响应也多了很多的header，响应的内容也不再局限于纯文本了。

HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型，是一个无状态的协议。HTTP是建立在TCP之上的，每个请求都要经历三次握手和慢启动。客户端是依据域名来向服务器建立连接，一般PC端的浏览器支持同域6～8个连接，手机端的连接数则一般控制在4～6个。连接数不是越多越好，资源开销和整体延迟都会随之增大。

HTTP 1.1 导致了2000年的互联网热潮。HTTP1.1 支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。RANGE:bytes是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXX表示要求服务器从文件XXX字节处开始传送，这大概就是平时所说的断点续传。

相关的部分协议标准如下：

现如今，Web应用不再单纯是web 网页，还有支持多设备和多媒体。 一个SPA的应用可能有上百的连接，模块拆分导致了更多的请求，大部分时间都消耗在网络上。HTTP 1.x header 往往较大，且无法压缩。TCP协议利用过低，不可复用连接，连接数限制且协议过于庞大。

HTTP1.x遇到的问题和解决方案

HTTP1.x主要存在连接无法复用和head of line blocking这两个问题。在第一个请求没有收到回复之前，后续从应用层发出的请求只能排队。网络通畅的时候性能影响不大，一旦第一个请求没有抵达服务器，或者response因为网络阻塞没有及时返回，就会影响所有后续请求。

HTTP1.0协议头里可以设置Connection:Keep-Alive。在header里设置Keep-Alive可以在一定时间内复用连接，具体复用时间的长短可以由服务器控制，一般在15秒左右，这与运营商蜂窝网络的linger time相关。HTTP1.1之后Connection的默认值就是Keep-Alive，如果要关闭连接复用需要显式的设置Connection:Close。这对PC端浏览器的体验帮助很大，因为大部分的请求在集中在一小段时间以内。但移动app的请求比较分散且时间跨度相对较大，一般会从应用层寻求其它解决方案，长连接方案或者伪长连接方案。

为了解决HTTP连接复用，可以采用长轮询，HTTP streaming和websocket等方式。

和传统的HTTP短链接相比，长连接轮询会在用户增长的时候极大的增加服务器压力。移动端网络环境复杂，像wifi和4g的网络切换等，这些场景都需要考虑重建连接。长轮询方式稳定性并不好，需要做好数据可靠性的保证，比如重发和ack机制。而且，response有可能会被中间代理cache住，要处理好业务数据的过期机制。

HTTP streaming是通过在server response的头部里增加"Transfer Encoding: chunked"来告诉客户端后续还会有新的数据。如果永远不会结束，客户端就会一直处于等待response的过程中。代理服务器会等待服务器的response结束之后才会将结果推送到请求客户端。对于streaming这种业务数据无法按照请求来做分割，所以客户端每收到一块数据都需要自己做协议解析。显然这个数据通道也是单向的，还有个缺陷就是不会产生重复的header数据。