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的子流。

                         A
       A                 |
      / \      ==>       D
     B   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 ->root
  b.jpg ->|

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

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

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

  a.jpg    ->|style.css->b.js->a.js -> index.html ->root
  b.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 B
  streams := make(map[uint32]*stream)
  a := &stream{
    parent: nil,
    weight: 16,
  }
  streams[1] = a
  b := &stream{
    parent: a,
    weight: 16,
  }
  streams[2] = b
  adjustStreamPriority(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 stream
  streams := make(map[uint32]*stream)
  a := &stream{
    parent: nil,
    weight: 16,
  }
  streams[1] = a
  b := &stream{
    parent: nil,
    weight: 16,
  }
  streams[2] = b
  c := &stream{
    parent: nil,
    weight: 16,
  }
  streams[3] = c
  adjustStreamPriority(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/

http2-stream-optima-prioritation

动机

依赖树的构建

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

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

go http2 依赖树构建测试代码

go http2 专有标志的演示

ref

Reco

引用和评论

Spring Boot 构建一个RESTful Web服务

状态码 406， Not Acceptable, (Spring Boot)

NGINX 知识总结

TLSv1.3 Support：主流 Web 客户端和服务端对 TLSv1.3 的支持情况

如何设置Fiddler来拦截Java代码发送的HTTP请求，进行各种问题排查

Spring-Boot实现HTTP大文件断点续传分片下载-大视频分段渐进式播放

一键生成 HTTP + gRPC 混合架构微服务代码：更简单、更灵活、更兼容的微服务系统构建方式