http2-stream-optima-prioritation

谈及http/2，大家都会认为多播、服务器推送是最重要的。可是优先级调度一样非常关键。尽管客户端请求可以通过多播一次发出，服务器相应也可以通过多播，推送提高带宽利用率，然而，不分主次的使用，很可能会导致页面加载时间更长。因为高优先级的资源本应优先传递，却因为多播而必须和低优先级资源竞争，导致整体延误。

曾有人以spdy协议做过实验[1]，准备：
1. 服务器启用spdy
2. 客户端关闭 webkit的资源加载调度特性( ResourceLoadScheduler)，不在节流，而是立刻发送全部请求

这样，本来由客户端做的节流以便调度优先级，转化为由支持SPDY服务器来做调度。加上多播和压缩，期望是会带来性能提升的。然而事与愿违：这样做的结果比起单纯的HTTP实际上是更慢了。细究发现，实验服务器（ngnix beta）并没有做优先级管理。目前，nginx的SPDY并不完善的，却被贸然的相对广泛的采用。

为什么说http/2，却以spdy举例？因为spdy就是http/2的前身，并且一直并行演化中。

动机

基于http实现的browser，采用的是对低优先级资源节流的做法，避免在高优先级资源没有完成前被低优先级资源挤占了带宽。

这样做是合理的，但是也带来了问题——就是在启动连接到文档的dom装入之间对带宽的利用不足：即使关键资源准备时间很长，网络再空闲，期间也不可以传递其他低优先级资源。

为了充分利用带宽，考虑到http2是多播的，这样的想法就是合理的了：客户端解析html后获知的全部资源，设定好资源（流）优先级，一次性发出给服务器。这样，优先级的调度就到了服务器一侧：不再由客户端通过节流的方式来体现优先级，而是把优先级作为一个提示，发给服务器，由服务器来完成最终的优先级调度。

服务器的做法可以有很多。简单幼稚的一个可行实现，就是按照优先级信息排出队列，次序做出响应即可。当然，http/2的实际做法采用的是依赖树算法（后面会细化此算法）。

尽管优先级信息看起来应该是一个代表优先级高低的数字字段，但是这样的认识实际上是一个误解。优先级信息不是一个数字字段，而是3个字段。认识到这个误解的可能存在对于理解以下内容是非常重要的。

http2 客户端发送新建的流和现有流的依赖关系和依赖权重建议给服务器，以及对现有流调整依赖关系和依赖权重的建议给服务器，由服务器根据这些信息来构建依赖流的关系树，然后由这个依赖树来决定为每个流确定发送次序以及分配计算资源，从而完成对流定优先级的效果。

比起直接了当的单一优先级数值，采用依赖流+权重的方式，可以更好的表达浏览器渲染约束需要的依赖关系。渲染一个页面本身就是一个资源传递依赖的过程。比如脚本会阻塞html的解析，最终的布局依赖于外部的样式表。

依赖树的构建

和优先级有关的Frame有两种，分别为 HEADER,PRIORITATION 。新建流的终端可以在HEADER中包含优先级信息来对流标记优先级。对于已存在的流，PRIORITATION可以用来改变流优先级。

这些字段是：

E ： 1位的标记用于标识流依赖是否是专用的。可选。
Stream Dependency ： StreamID。31位流 .可选。
Weight : 流的8位权重标记。添加一个1-256的值来存储流的权重。

对于HEADER,PRIORITATION而言，这3个字段都是可选的，标志 Flags:PRIORITY 设置表明此3个字段存在与否。

可以通过Stream Dependency 指定依赖另外一个流。当指定了一个依赖流，流会作为一个子流加入依赖树内。比如:B流，C流依赖于A流（左下图），如果D流通过HEADER frame创建，并同时指定依赖A流，那么依赖树就会变成右下图那样，b，d，c的次序不重要。

       A                 A/ \      ==>      /|\B   C             B D C

E 为专有标记。如果这个标记被设置，就意味着当前流将会独自占有父亲流，本来的兄弟流要成为当前流的子流。以上图为例，如果D流设置了E标志，那么D独自占有A流为父亲，B,C 则成为D的子流。

                         AA                 |/ \      ==>       DB   C              / \B   C

每个依赖都会指定Weight权重，这个权重用来作为和其他兄弟流（同样依赖一个流的其他流）分配资源的筹码。有同一个父亲的子流们应该按照权重值按比例分配资源。比如B依赖A权重4，C依赖A权重12，如果A已经完成，理想情况下，B得到它的1/4资源，C得到它的3/4的资源。

依赖、并发、优先级调整的案例

假设一个index.html

  <html><body><script src="a.js"></script><img src="a.jpg" width="100" height="100"/><img src="b.jpg" width="100" height="100"/><link rel="stylesheet" type="text/css" href="style.css"></body>

依赖于a.js

  document.write('<script src="b.js"></script>');

依赖于b.js:

  document.write('<div>blocker</div>');

依赖于style.css:

  div {border: 1px solid #000;}

这样的情况，如今是如何传输的呢？index.html被接收然后解析，文档解析器(Document Parser)会发现a.js,发出请求并且被阻塞；接下来，探测解析器（Speculative Parser ),继续探测发现a.jpg,b.jpg,style.css 并向服务器发出资源请求，然后a.js获得并被解析执行，发现依赖b.js,然后发出b.js资源请求，然后文档解析器再次被阻塞... 。如图：

    client                             server|--------------get index.html------> ||<----index.html         ----------- ||--------------get a.js      ------> ||--------------get a.jpg     ------> ||--------------get b.jpg     ------> ||--------------get style.css ------> ||<----a.js      -------------------- ||--------------get b.js      ------> ||<----a.jpg     -------------------- ||<----b.jpg     -------------------- ||<----style.css -------------------- ||<----b.js      -------------------- |

分析完毕，结论也就出来了：非常低效。唯有style.css,b.js完成，整个页面才完成加载，而关键的b.js因为被其他不重要的资源（img）竞争而传递缓慢。

采用了优先级帧（PRIORITITION)，依赖树算法，并发技术的http2，有可能改善这样情况，只要适合加入 PRIORITITION 帧，按照依赖算法计算优先级即可。

    client                             server|--------------1.get index.html----------------> ||<----index.html ------------------------------- ||--------------2.get a.js      (parent 1）-----> ||--------------3.get a.jpg     (parent 2)------> ||--------------4.get b.jpg    (parent 2) ------> ||--------------5.get style.css(parent 2 E)-----> ||<----a.js                  -------------------- ||--------------6.get b.js(parent 2 E)    ------> ||<----b.js       ------------------------------- ||<----style.css  ------------------------------- ||<----a.jpg      ------------------------------- ||<----b.jpg      ------------------------------- |

当1.get.index.html的时候，依赖树为

index.html ->root

当2.get a.js 时，在HEADER 帧内指定流依赖id为 1 （parent 1），因此，流2依赖于流1,依赖树为：

   a.js -> index.html ->root

相应的，3.get a.jpg

  a.jpg -> a.js -> index.html ->root

相应的，4.get b.jpg

  a.jpg ->|a.js -> index.html ->rootb.jpg ->|

相应的，5.get style.css(parent 2 E)，E技术前面提到的字段E ，表示独占父亲流。

  a.jpg    ->|style.css->a.js -> index.html ->rootb.jpg    ->|

相应的，6.get b.js(parent 2 E)，E表示独占。

  a.jpg    ->|style.css->b.js->a.js -> index.html ->rootb.jpg    ->|

这样，就可以在分析（动态）发现更高优先级资源的时候，调整依赖树，从而调整优先级次序，保证浏览器立刻需求的资源可以不必和晚点要的资源发生带宽竞争。

Webkit 的传统资源优先级方法：代码实例

webkit的ResourceLoadSchedule，就是首先载入影响绘制的html，js，css，第一次绘制完毕，dom加载完成，才放出更多的资源（如img）请求。

https://github.com/adobe/chromium/blob/master/content/browser/renderer_host/resource_dispatcher_host_impl.cc net::RequestPriority DetermineRequestPriority(ResourceType::Type type) {switch (type) {case ResourceType::MAIN_FRAME:case ResourceType::SUB_FRAME:return net::HIGHEST;case ResourceType::STYLESHEET:case ResourceType::SCRIPT:case ResourceType::FONT_RESOURCE:return net::MEDIUM;case ResourceType::SUB_RESOURCE:case ResourceType::OBJECT:case ResourceType::MEDIA:case ResourceType::WORKER:case ResourceType::SHARED_WORKER:case ResourceType::XHR:return net::LOW;case ResourceType::IMAGE:case ResourceType::FAVICON:return net::LOWEST;case ResourceType::PREFETCH:case ResourceType::PRERENDER:return net::IDLE;default:NOTREACHED();return net::LOW;}
}

go http2 依赖树构建测试代码

来自于 :https://github.com/bradfitz/http2/blob/master/priority_test.go

func TestPriority(t *testing.T) {// A -> B// move A's parent to Bstreams := make(map[uint32]*stream)a := &stream{parent: nil,weight: 16,}streams[1] = ab := &stream{parent: a,weight: 16,}streams[2] = badjustStreamPriority(streams, 1, PriorityParam{Weight:    20,StreamDep: 2,})if a.parent != b {t.Errorf("Expected A's parent to be B")}if a.weight != 20 {t.Errorf("Expected A's weight to be 20; got %d", a.weight)}if b.parent != nil {t.Errorf("Expected B to have no parent")}if b.weight != 16 {t.Errorf("Expected B's weight to be 16; got %d", b.weight)}
}

go http2 专有标志的演示

实现了final的协议，因此可以看到依赖树的测试代码是比较完善的，颇有演示概念的价值
来自于 :https://github.com/bradfitz/http2/blob/master/priority_test.go

func TestPriorityExclusiveZero(t *testing.T) {// A B and C are all children of the 0 stream.// Exclusive reprioritization to any of the streams// should bring the rest of the streams under the// reprioritized streamstreams := make(map[uint32]*stream)a := &stream{parent: nil,weight: 16,}streams[1] = ab := &stream{parent: nil,weight: 16,}streams[2] = bc := &stream{parent: nil,weight: 16,}streams[3] = cadjustStreamPriority(streams, 3, PriorityParam{Weight:    20,StreamDep: 0,Exclusive: true,})if a.parent != c {t.Errorf("Expected A's parent to be C")}if a.weight != 16 {t.Errorf("Expected A's weight to be 16; got %d", a.weight)}if b.parent != c {t.Errorf("Expected B's parent to be C")}if b.weight != 16 {t.Errorf("Expected B's weight to be 16; got %d", b.weight)}if c.parent != nil {t.Errorf("Expected C to have no parent")}if c.weight != 20 {t.Errorf("Expected C's weight to be 20; got %d", b.weight)}
}

ref

[1]. Proposal for Stream Dependencies in SPDY
https://docs.google.com/document/d/1pNj2op5Y4r1AdnsG8bapS79b11iWDCStjC...

[2]. draft-ietf-httpbis-http2-15 - Hypertext Transfer Protocol version 2 - https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#section-5.3

[3]. Prioritization Is Critical To SPDY - Insouciant - https://insouciant.org/tech/prioritization-is-critical-to-spdy/