HTTP優先度制御の今後とビデオ配信

A1f8ed12fefd7759ef8838e62ee409a6?s=47 kazuho
December 11, 2019

 HTTP優先度制御の今後とビデオ配信

HTTP/2と3にむけて検討が進んでいる新しい優先度制御の仕組みと、それがビデオ配信にもたらす最適化の可能性について解説します。

A1f8ed12fefd7759ef8838e62ee409a6?s=128

kazuho

December 11, 2019
Tweet

Transcript

  1. HTTPの
 新しい優先度制御と
 ビデオ配信
 Kazuho Oku


  2. 自己紹介
 • オープンソースHTTPサーバ「H2O」主開発者
 ◦ CDN等で採用
 ◦ HTTP, TLS, QUICスタックを実装
 •

    IETFでの標準化に参加
 ◦ 103 Early Hints (RFC 8297)
 ◦ Encrypted SNI (draft-ietf-tls-esni)
 ◦ HTTP Priorities (draft-kazuho-httpbis-priority)

  3. • HTTP/2優先度制御 - 非推奨へ
 • HTTP/2と3に適用可能な新しい優先度制御
 • 新優先度制御手法とビデオ配信
 アジェンダ


  4. ウェブページの優先度制御
 • だいたい以下の順に配信するのが正解
 ◦ JS, CSS (レンダリングをブロックするもの)
 ◦ HTML
 ◦

    画像
 ◦ 非同期読み込みのJS
 • 最適な順序はウェブサイト毎に異なります
 ◦ https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html 

  5. HTTP/2優先度制御 - Firefox
 source: https://datatracker.ietf.org/meeting/105/materials/slides-105-httpbis-sessa-http3-priorities-01


  6. HTTP/2優先度制御 - Chrome
 source: https://datatracker.ietf.org/meeting/105/materials/slides-105-httpbis-sessa-http3-priorities-01


  7. HTTP/2優先度制御 - 問題点
 • クライアント・サーバ双方が正しく実装する必要あり
 ◦ だが、仕様が複雑で実装品質がまちまち
 ◦ 結果、うまく働いていないことも多い
 •

    サーバによる優先度介入が不可能
 ◦ クライアント毎に構築する「木」の形が違うため
 ↓
 HTTP/2の優先度制御は非推奨へ

  8. HTTPワーキンググループの現状
 • HTTP/3の標準化が進行中
 • 並行して、HTTP/2と3の両方で機能する、より単純な新しい優 先度制御手法を標準化することに
 ◦ "Extensible Prioritization Scheme

    for HTTP"
 ▪ 著者: Kazuho Oku (Fastly), Lucas Pardue (Cloudflare)
 ▪ 現在Call for Adoptionの結果待ち
 

  9. 新手法 - 設計方針
 • ウェブページの優先度指定に必要な機能を実装
 ◦ HTTP/2の現手法と同等以上の性能を確保
 ◦ HTTPのバージョン関係なく動作
 ◦

    HTTP/3に間に合うよう必要最小限の機能
 ◦ サーバによる優先度介入をサポート
 • 将来にむけた拡張性を担保

  10. 新手法 - 絶対値による優先度指定
 time
 urgency
 GET /index.html
 Priority: u=1, i=?1


    GET /style.css
 Priority: u=0
 GET /image.jpg
 Priority: u=4, i=?1
 GET /analytics.js
 Priority: u=5

  11. 新手法 - 8段階の絶対的優先度 ("u")
 Name
 Urgency
 Examples
 prerequisite
 0
 CSS,

    JS in <HEAD> 
 default
 1
 HTML, fonts
 supplementary
 2
 (server-only)
 3
 hero images
 4
 images
 5
 async JS
 6
 (server-only)
 background
 7
 prefetch, file download 
 wiggle room for clients 

  12. 新手法 - 「インクリメンタル」フラグ ("i")
 • インクリメンタルにデータを処理できるかを表すフラグ
 ◦ 画像 => true,

    CSS, JS => false

  13. 新手法 - 絶対値による優先度指定
 time
 urgency
 GET /index.html
 Priority: u=1, i=?1


    GET /style.css
 Priority: u=0
 GET /image.jpg
 Priority: u=4, i=?1
 GET /analytics.js
 Priority: u=5

  14. 新手法 - サーバによる優先度介入
 • サーバの指定したパラメータが、クライアントの指定値をオー バーライド
 • 例: Async JSを画像よりも高優先度に変更


    
 GET /critical.js Priority: u=5 GET /critical.js Priority: u=5 200 OK Priority: u=1 H2 terminator origin server
  15. 新手法 - 拡張性
 • 任意のパラメータを追加可能
 • 想定される第一の利用用途がビデオストリーミング
 ◦ 具体的には、これから議論
 GET

    /index.html
 Priority: u=1, i=?1

  16. 新手法 - 拡張性
 • 任意のパラメータを追加可能
 • 想定される第一の利用用途がビデオストリーミング
 ◦ 具体的には、これから議論
 GET

    /index.html
 Priority: u=1, i=?1, hoge=foo

  17. ビデオストリーミングの優先度制御
 • ウェブページの優先度制御とは要件が異なる
 ◦ ウェブページ - ファイルの優先度は固定
 ◦ ビデオストリーミング -

    .tsの優先度は時間と共に変化
 ▪ 再生直前の.ts - 優先度最高
 ▪ 再生後の.ts - 優先度ゼロ...
 • 優先度を、どのようにパラメータ化するか

  18. ビデオストリーミングの優先度制御
 • 再生タイミングを指定する?


  19. ビデオストリーミングの優先度制御
 • 再生タイミングを指定する?
 time
 GET /filePart271.ts
 Priority: playat=193031;dur=10
 GET /filePart272.ts


    Priority: playat=193041;dur=10
 GET /filePart273.ts
 Priority: play=193051;dur=10

  20. ビデオストリーミングの優先度制御
 • 再生タイミングを指定する?
 ◦ あるいは、不要になった.tsのリクエストは、クライアントが キャンセルすればいい?


  21. ビデオストリーミングの優先度制御
 • 全ての.tsがIフレームを含まない場合、ファイル間の順序指定 も必要?


  22. ビデオストリーミングの優先度制御
 • 全ての.tsがIフレームを含まない場合、ファイル間の順序指定 も必要?
 time
 GET /filePart271.0.ts
 GET /filePart271.1.ts
 Priority:

    after=/filePart271.0.ts
 GET /filePart271.2.ts
 Priority: after=/filePart271.1.ts

  23. 何が必要か、教えてください m(__)m