关于HTTP 2.0

关于HTTP 2.0

HTTP自互联网时代到来之后，几乎成为了使用最多的应用层协议。先来回顾一下http的历史：
http也就是超文本传输协议，对应的传输的文本叫做超文本标记语言也就是html，这是最初的使用场景，也就是用来发布和接受html界面的，什么叫做超文本呢，就是说不单单是文本，能通过计算机处理文本的方式处理对应内容从而具有排版、图片还有可读性什么的。这个规范和协议是由Internel Engineering Task Force（互联网工程工作小组）共同研究给出的RFC，然后使用最广的是RFC 2616定义的HTTP 1.1。关于RFC还有草案什么的，我之前从开始学网络就有点迷，然后总结了下，顺道来看一下RFC和草案的一些概念。
首先IETF是国际互联网工程任务组，一个公开的民间组织，来维护互联网工作，一些草案什么的都是IETF中提出的，具体过程是这样的：
1、发布一份互联网草案
2、接受关于草案的评论
3、根据评论修改你的草案
4、重复1至3步骤数遍
5、请求领域总监将草案带至IESG(如果是个人提交)。如果草案出自一个正式工作组，则由工作组主席向领域总监提交草案。
6、根据IESG讨论结果修改草案(结果可能是草案被否决)
7、等待RFC编辑处编辑出版你的草案
然后草案是一种可以使用但是随时可能发生修改的，而成为RFC之后，就算是一种标准啦，但是RFC通常包含这么几种：建议标准、草案标准、互联网标准(有时称作"完全标准")、试验性协议、信息文档、历史标准。只有前三种是具体的IETF标准。

现存问题

1、TCP建立连接时三次握手有1.5个RTT（round-trip time）的延迟。
2、如TCP在建立连接的初期有慢启动（slow start）的特性。
http1.0被抱怨最多的就是连接无法复用，和head of line blocking这两个问题。理解这两个问题有一个十分重要的前提：客户端是依据域名来向服务器建立连接，一般PC端浏览器会针对单个域名的server同时建立6～8个连接，手机端的连接数则一般控制在4～6个。显然连接数并不是越多越好，资源开销和整体延迟都会随之增大。

三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

线头阻塞（Head-of-line blocking, HOL）

线头阻塞是一种出现在缓存式通信网络交换中的一种现象。交换通常由缓存式输入端口、一个交换架构以及缓存式输出端口组成。当在相同的输入端口上到达的包被指向不同的输出端口的时候就会出现线头阻塞。由于输入缓存以及交换设计的FIFO特性，交换架构在每一个周期中只能交换缓存头部的包。如果某一缓存头部的包由于拥塞而不能交换到一个输出端口，那么该缓存中余下的包也会被线头包所阻塞，即使这些包的目的端口并没有拥塞。
解决线头阻塞问题的一个方法就是使用虚拟输出队列（Virtual Output Queue）
SPDY基础功能

多路复用（multiplexing）。

多路复用通过多个请求stream共享一个tcp连接的方式，解决了http1.x holb（head of line blocking）的问题，降低了延迟同时提高了带宽的利用率。
请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
header压缩。前面提到过几次http1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。SPDY对header的压缩率可以达到80%以上，低带宽环境下效果很大。

SPDY高级功能

server推送（server push）。http1.x只能由客户端发起请求，然后服务器被动的发送response。开启server push之后，server通过X-Associated-Content header（X-开头的header都属于非标准的，自定义header）告知客户端会有新的内容推送过来。在用户第一次打开网站首页的时候，server将资源主动推送过来可以极大的提升用户体验。
server暗示（server hint）。和server push不同的是，server hint并不会主动推送内容，只是告诉有新的内容产生，内容的下载还是需要客户端主动发起请求。server hint通过X-Subresources header来通知，一般应用场景是客户端需要先查询server状态，然后再下载资源，可以节约一次查询请求。

连接共享

http2.0要解决的一大难题就是多路复用（MultiPlexing），即连接共享。上面协议解析中提到的stream id就是用作连接共享机制的。一个request对应一个stream并分配一个id，这样一个连接上可以有多个stream，每个stream的frame可以随机的混杂在一起，接收方可以根据stream id将frame再归属到各自不同的request里面。
前面还提到过连接共享之后，需要优先级和请求依赖的机制配合才能解决关键请求被阻塞的问题。http2.0里的每个stream都可以设置又优先级（Priority）和依赖（Dependency）。优先级高的stream会被server优先处理和返回给客户端，stream还可以依赖其它的sub streams。优先级和依赖都是可以动态调整的。动态调整在有些场景下很有用，假想用户在用你的app浏览商品的时候，快速的滑动到了商品列表的底部，但前面的请求先发出，如果不把后面的请求优先级设高，用户当前浏览的图片要到最后才能下载完成，显然体验没有设置优先级好。同理依赖在有些场景下也有妙用。

ProtocolBuffer设计用于解决这一类问题：
1、很方便引入新字段，而中间服务器可以忽略这些字段，直接传递过去而无需理解所有的字段。
2、格式可以自描述，并且可以在多种语言中使用(C++、Java等)