Weitere ähnliche Inhalte
Ähnlich wie HTTP/2の現状とこれから (20)
Mehr von shigeki_ohtsu (15)
Kürzlich hochgeladen (10)
HTTP/2の現状とこれから
- 2. 自己紹介
• 名前: 大津 繁樹
• 所属: 株式会社インターネットイニシアティブ(IIJ) アプリケーション開発部
• Twitter: @jovi0608
• ブログ: ぼちぼち日記 http://d.hatena.ne.jp/jovi0608/
• GitHub: https://github.com/shigeki/
• 新技術の検証・評価を行ってます。 (Node.js, io.js,SPDY, HTTP/2,HTML5)
• iij-http2の開発を通じてIETFのHTTP/2標準化作業に参画中
- 3. HTTP/2 はRFC化目前です
• HTTP/2
• IESGレビュー終了。コメントを受け
てドラフトを改訂。その後承認見込
• HPACK
• IESG承認済(1/23)
発行プロセスが順調なら桜が咲く前にはRFC化かも
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2
Frame Layer
HTTP/1.1
Semantics
- 4. 内容
• これまで
• HTTP/1.1の問題点のおさらい (+デモ)
• 現状 (SPDY, HTTP/2)
• SPDY, HTTP/2の対応状況
• HTTP/2の最終仕様の概要 (いくつかピックアップ)
• これから
• HTTP/2の拡張 → HTTP/3の展望
• HTTP/2の応用:WebPush + Push API (Service Worker+ Server Push)
• 新プロトコル: QUIC (+デモ)
- 6. HTTPプロトコルの年表
1990 1995 2000 2005 2010 2015
Webの
始まり
HTTP/0.9 HTTP/1.0
RFC1945
HTTP/1.1
RFC2068
HTTP/1.1
RFC2616
HTTP/1.1
RFC7230-5
HTTP/2
SPDY/2
SPDY/3
SPDY/3.1
httpbis WG
暗黒の時代
HTTP-NG
中止
- 8. 1. HTTP Head of Line Blocking
クライアント サーバ
HTTP/1.1
1本のTCP接続
HTTP リクエスト
HTTPレスポンス
待ち時間
HTTP リクエスト
- 15. 3. HTTP/1.1は処理が煩雑なテキストプロトコル
HTTP/1.1 200 OK
Content-Type: image/jpeg
Transfer-Encoding: chunked
Trailer: Foo
123
{binary data}
0
Foo: bar
Status-Lineは一行目 空白は1つ
ヘッダ名は大文字・小文
字区別せず
ヘッダ領域の区切り
はCRLF一つ
:の後に空白を許可
CRLFで改行、複数行
対応は廃止
レスポンスデータがchunkedであ
り、サイズはまだ不定
一番最後にFooヘッダが付与
されることを宣言
続くデータが123バイト
であることを宣言
データ終了の合図
Trailヘッダ
chunk終了合図
のCRLF
- 16. HTTP/2はきっちりしたバイナリープロトコル
00 00 00 01
01 04
00 00 1a
88 5c 82 08
・・・・・・
73 ff
00 00 00 01
00 00
00 00 7b
{binary data}
:status = 200
content-length = 123
content-type = image/jpeg
trailer = Foo
HEADERS
DATA
フレーム長:28バイト
フレーム長:123バイト
フレームタイプ:HEADERS, END_HEADERSフラグ
ストリームID: 1
ストリームID: 1
フレームタイプ:DATA, フラグなし
(* 記載スペースの都合上Trailer HEADERSは省いています)
データの
位置・サイズ・型
が明確
- 18. デモ: SPDY 対 SSL(HTTP/1.1)
HTTP Head of Line Blocking の違い
1. 少数画像 vs 多数画像。
2. 3枚目の画像毎に3秒のレスポンス遅延を入れる。
- 26. HTTP/1.1セマンティクスと非互換なところ
• ホップ-バイ-ホップ ヘッダの利用禁止
• ホップ-バイ-ホップ間の通信制御はHTTP/2フレームの役割であるため、
HTTPヘッダによる制御を禁止。
• Connection, Transfer-Encoding, TE, Upgrade, Keep-Alive, Proxy-Connection
ヘッダは利用禁止。
• TE: trailers だけ例外
• Status Code: 101 (Switching Protocols) も禁止
クライアント プロキシ プロキシ プロキシ サーバ
hophop hop
End-To-Endヘッダだけ許可
- 30. HTTP/2の応用 WebPush
いろんな場面でプッシュ通知は必要
1. ブラウザ上でアプリが動作している時
• チャット等の通常のアプリ通知
2. ブラウザは立ち上げているがアプリは動作していない時
• SNSのメッセージやweb feedを受ける
3. ブラウザも立ち上げていない時
• WebRTCによる入電でウェブアプリを立ち上げる
4. 1つのブラウザでアプリを複数インスタンス立ち上げてい
る。又は、異なるブラウザで同一のアプリを動作させてい
る。
• そのうちの1つにだけプッシュ通知したい。
• 全部にプッシュ通知をブロードキャストしたい。
• 複数アカウントでメール利用など。
- 31. HTTP/2の応用 Service Worker+ Server Push
プッシュサーバ
アプリケーション
サーバ
Webアプリの通信
HTTPS必須
5. Service Worker上で
Pushイベントが発生。
ArrayBuffer, blob, json,
textの形式でプッシュ
データを取り出せる。
2. HTTP PUTのリクエスト
ボディにプッシュメッ
セージを付けて送信
4. HTTP/2サーバプッシュを利用
してクライアントに通知
3. 複数アプリのプッシュ
通知をチャネルで区別し、
一つの接続上で送信
1. クライアントからプッシュサーバ名と登録IDを通知
Service
Worker
ウェブ
アプリ
ブラウザ
Push API
クライアント
- 32. Service Workerからこう見える
// 登録されたService Workerのコード
this.onpush = function(event) {
console.log(event.data);
// event.data は、ArrayBuffer, blob, json, text形式
// ここでIndexedDBにdataを書き込んだり、
// 開いているウィンドウにdataを送ったり、
// Notificationを表示したりなどができる。
}
Web Pushは、複数のブラウザ、複数のアプリインスタンス、アプ
リの起動・停止中等様々な場面でもプッシュ通知が行える
- 33. 新プロトコル: QUIC
(Quic UDP Internet Connections)
IP(IPv4/IPv6)
UDP
TCP
TLS
QUIC
SPDY
HTTP
暗号化・認証
セッション確立、フロー制御
エラー補正, 輻輳制御
• Googleが独自に開発しているプロトコル
• UDP上でTCP+TLS相当+αの機能を実装
• 最短0-RTTで再接続、暗号通信を必須化
• TCPと同様の輻輳制御で帯域の公平化
• 独自の誤り訂正と再送機能でパケットロス
によるTCPのHead of Line Blockingを回避
• Googleの全サービスで運用中、Chrome
のフィールドテスト中(*)
• Stable版: 0.2%(Desktop), 2%(Android)
• Beta版: 25%(Desktop), 50%(Android)
• 知らない間に使っているかも?
• 今年にライブラリ化を予定
(* 割合は2014/08時点のGoogleの公表値)