http2 最速実装 v2

Yoshihiro Iwanaga
Yoshihiro IwanagaSoftware Developer at IIJ
HTTP/2 最速実装 v2
@y_iwanaga_
ゴール
HTTP/2 クライアント  を
最⼩小限の時間  で実装できる状態になる
1.  HTTP/2 仕様 を理解
2.  実装に便利な ツール・情報源 を把握
HTTP/2 仕様
1. 全体像を掴む
HTTP/1.0, 1.1 どこがダメなの?
設計思想、⽬目的を知ると理理解が早くなる。
それをもとに HTTP/2 はどんな仕様になったの?
接続確⽴立立からレスポンス受信まで
2. 実装解説
30分で HTTP/2 の全要素を解説するのは無理理。
今⽇日は最⼩小限の要素に厳選。
HTTP/1.1 の問題
ブラウザから
張れる接続数の上限: 5
client server
1 リクエストで  TCP コネクションを 1 つ消費。
6個⽬目のリクエストは
送信を待たないといけない。
リクエストを
6個  送りたい
※  Keep-‐‑‒Alive  は  3-‐‑‒way  handshake  を省省略略できるだけ。結局待つことになる。
HTTP/2 では
1つのTCPコネクションで
        複数のリクエストを送信
Client Server
request
response
server push
HTTP/1.1 もう1つの問題
パフォーマンスを改善していくと、
通信の遅延がボトルネックになる
ネットワーク品質は⼿手が出せない場合が多い。
けど、送受信するデータサイズを⼩小さくすれば改善できる。
⼀一般論論
HTTP/2 では
・情報をより⼩小さいデータサイズで表現
・出来るだけ CPU とメモリの消費でカバー
設計⽅方針
以上を実現するために
TCP  コネクション  1  つで
複数のリクエストを扱うためには
各リクエストの境界を判別する必要がある
HTTP/2  では  Frame  で分割
Client Server
req1req2
res1 res2 res1
続き
TCP ペイロードの中に複数のデータを連結させる
Frame の定義
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
http2-spec の 4.1. Frame Format
Frame の全体像
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
その後に  Frame Payload が続く
最初の 64bit に  Frame Header
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
R:  Reserved.  今は  0  を⼊入れることになっている。
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
Length:    Frame  Payload  のサイズ
※ Frame Header のサイズを⾜足しちゃダメ  J
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
Type:    Frame  Type  を番号で指定。
Frame の種類
Type  ID タイプ名 意味
0x0 DATA HTTP/1  の  Body  に相当
0x1 HEADERS HTTP/1  の  Header  に相当
0x2 PRIORITY ストリームの優先度度
0x3 RST_STREAM ストリームの異異常終了了
0x4 SETTINGS ストリームの設定
0x5 PUSH_PROMISE サーバプッシュ
0x6 PING 死活監視、遅延測定
0x7 GOAWAY コネクション終了了
0x8 WINDOW_UPDATE フロー制御設定
0x9 CONTINUATION
HEADERS,  PUSH_̲PROMISE
の続き
0xa ALTSVC プロトコル切切り替え
0xb BLOCKED フロー制御デバッグ情報
(draft-‐‑‒12のみ)
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
Flags:  各  bit  で複数オプションの  On/Off  を表現
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
Stream  ID:  各リクエスト、レスポンスを識識別するための  ID
Stream  ID  の意義
データがフラグメントした場合、
どの Frame の続きなのか判断したい。
そのために  Stream  ID  を利利⽤用
Client Serverres2 res1
続き
res1
の⼀一部
stream ID の管理理ルール
Client Server
1
2
3
5
4
6
・client  →  server  は奇数
・server  →  client  は偶数
・0  は全体の制御で利利⽤用
Frame の仕様
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| R | Length (14) | Type (8) | Flags (8) |	
+-+-+-----------+---------------+-------------------------------+	
|R| Stream Identifier (31) |	
+-+-------------------------------------------------------------+	
| Frame Payload (0...) ...	
+---------------------------------------------------------------+
Frame  Payload:    Frame  Type  によって構造が違う。
                  後ほど説明。
Client Server
req1req3 req2
res1 res2 res1
続き
res3
必要な情報は出揃った。いざ実装!
順番
ServerClient
0. プロトコルネゴシエーション
1. Magic Octet
2. SETTINGS Frame
3. SETTINGS Frame ACK
4. SETTINGS Frame ACK
5. HEADERS Frame で GET /
6. HEADERS Frame
7. DATA Frame
HTTP/2
接続確⽴立立
HTML
1. Magic Octet
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0rnrnSMrnrn
HTTP/2  をサポートしているか最終チェック
HTTP/2 をサポートしないサーバに
ALPN しないで直接 HTTP/2リクエストした時に問題を出さないように。
HTTP/1.1 では「PRI メソッドは存在しない」と処理理して終了了。
送信するデータ
順番
ServerClient
0. プロトコルネゴシエーション
1. Magic Octet
2. SETTINGS Frame
3. SETTINGS Frame ACK
4. SETTINGS Frame ACK
5. HEADERS Frame で GET /
6. HEADERS Frame
7. DATA Frame
HTTP/2
接続確⽴立立
HTML
2〜~4.  SETTINGS  Frame
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| Identifier (8)|	
+---------------+-----------------------------------------------+	
| Value (32) |	
+---------------------------------------------------------------+
下記を 0 個以上。
※ 受信側は、Payload Length で個数が分かる。
payload  の定義
Step 2: Server へ  Stream ID = 0, payload 無しで送信
Step 3: Server から Stream ID =0, flags = 0x1 (ACK), payload を受信
Step 4: Client から Stream ID = 0, flags = 0x1 (ACK), payload 無しで送信
順番
ServerClient
0. プロトコルネゴシエーション
1. Magic Octet
2. SETTINGS Frame
3. SETTINGS Frame ACK
4. SETTINGS Frame ACK
5. HEADERS Frame で GET /
6. HEADERS Frame
7. DATA Frame
HTTP/2
接続確⽴立立
HTML
5. HEADERS Frame
最後の難関
0 1 2 3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| Pad High? (8) | Pad Low? (8) |	
+-+-------------+---------------+-------------------------------+	
|E| Stream Dependency? (31) |	
+-+-------------+-----------------------------------------------+	
| Weight? (8) |	
+-+-------------+-----------------------------------------------+	
| Header Block Fragment (*) ...	
+---------------------------------------------------------------+	
| Padding (*) ...	
+---------------------------------------------------------------+
flags                  =  END_̲HEADERS  |  END_̲STREAM
stream  ID  =  1
Header Block Fragment: Payload はここだけになる。
                        ※ 仕様は HPACK-07 に記載されている。
最短  HPACK
http://example.com/  を  GET  する場合
0 1 2 3 4 5 6 7	
+---+---+---+---+---+---+---+---+	
| 0 | 0 | 0 | 1 | 0 |	
+---+---+-----------------------+	
| 0 | Name Length (7+) |	
+---+---------------------------+	
| Name String (Length octets) |	
+---+---------------------------+	
| 0 | Value Length (7+) |	
+---+---------------------------+	
| Value String (Length octets) |	
+-------------------------------+
Name Value
:scheme http
:authority example.com
:path /
:method GET
Header  Block  の定義
(Literal  Header  Field  never  Indexed  &  ASCII  Encoding  パターン)
サーバに送信する情報
最後に、4つの Header Block を連結すれば、最短 HPACK 完了了!
:scheme は  7 ⽂文字
:scheme は ASCII で  0x3a736368656d65
http は  4 ⽂文字
http は ASCII で  0x68747470
順番
ServerClient
0. プロトコルネゴシエーション
1. Magic Octet
2. SETTINGS Frame
3. SETTINGS Frame ACK
4. SETTINGS Frame ACK
5. HEADERS Frame で GET /
6. HEADERS Frame
7. DATA Frame
HTTP/2
接続確⽴立立
HTML
6〜~7.  レスポンス受信
まずは Data Frame の payload を⾒見見て感動しましょう  J
この後紹介するサーバ実装は、Indexed で Huffman Encoding
7.  DATA  Frame  受信
6.  HEADERS  Frame  受信
この payload に HTML が⼊入ってます。
ここをきちんと実装するにはすごく時間がかかります。
これは後回しにして、先に DATA Frame を⾒見見てみましょう。
実装を効率率率よく進めるために
•  仕様ドキュメント
– HTTP/2-‐‑‒12
•  http://tools.ietf.org/html/draft-‐‑‒ietf-‐‑‒httpbis-‐‑‒
http2-‐‑‒12
– HPACK-‐‑‒07
•  http://tools.ietf.org/html/draft-‐‑‒ietf-‐‑‒httpbis-‐‑‒
header-‐‑‒compression-‐‑‒07
•  Public  Test  Server
– nghttp2  (h12c,  upgrade/direct)
•  http://nghttp2.org/
テストサーバ  Docker file
•  nghttp2
– Direct 接続⽤用 (ALPN 無し)
•  https://gist.github.com/tsahara/
7332972d057370d2e686
– ALPN 有り
•  https://gist.github.com/tsahara/
e6831656d7e2ff99ce7e
提供:tsahara さん
backup slides
エンコーディング
•  Huffman
– 出現頻度度の⾼高い⽂文字を少ない bit で表現
– でも、今回の実装では使わない
•  ASCII
– ⾮非圧縮。簡単。
– 今回の実装ではこちらを使う
インデックス
index Header  Name Header  Value
1 :authority
2 :method GET
3 :method POST
4 :path /
5 :path /index.html
6 :scheme http
7 :scheme https
8 :status 200
9 :status 204	
(以下略略)
よく使うヘッダ名と値を  番号で指定
http://tools.ietf.org/html/	
draft-ietf-httpbis-header-compression-07#appendix-B
今回の実装では利利⽤用しません。
リファレンスセット
•  ヘッダの差分のみを送信するためのテー
ブル
– 何度度も同じデータを送信しないで済む。
– そのために、サーバとクライアントで学習
テーブルを同期する必要がある。
– 今回の実装では利利⽤用しません
1 of 37

Recommended

HTTP2 最速実装 〜入門編〜 by
HTTP2 最速実装 〜入門編〜HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜Kaoru Maeda
32K views42 slides
HTTP/2の現状とこれから by
HTTP/2の現状とこれからHTTP/2の現状とこれから
HTTP/2の現状とこれからshigeki_ohtsu
113.6K views35 slides
監視 Overview by
監視 Overview監視 Overview
監視 OverviewIIJ
277 views30 slides
HTTPを理解する by
HTTPを理解するHTTPを理解する
HTTPを理解するIIJ
557 views41 slides
ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ by
ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウ
ElasticSearch+Kibanaでログデータの検索と視覚化を実現するテクニックと運用ノウハウKentaro Yoshida
65.5K views70 slides

More Related Content

What's hot

Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26 by
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26
Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26Yahoo!デベロッパーネットワーク
17.9K views72 slides
「Diameter勉強会 3」講義用スライド配布用 20141020 by
「Diameter勉強会 3」講義用スライド配布用 20141020「Diameter勉強会 3」講義用スライド配布用 20141020
「Diameter勉強会 3」講義用スライド配布用 20141020マジセミ by (株)オープンソース活用研究所
3.7K views41 slides
中小規模サービスのApacheチューニング by
中小規模サービスのApacheチューニング中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング勲 國府田
8K views42 slides
これからLDAPを始めるなら 「389-ds」を使ってみよう by
これからLDAPを始めるなら 「389-ds」を使ってみようこれからLDAPを始めるなら 「389-ds」を使ってみよう
これからLDAPを始めるなら 「389-ds」を使ってみようNobuyuki Sasaki
4.2K views54 slides
認証の課題とID連携の実装 〜ハンズオン〜 by
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜Masaru Kurahayashi
9K views170 slides
OpenStackをさらに”使う”技術 概要と基礎操作 by
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作irix_jp
5.5K views84 slides

What's hot(20)

中小規模サービスのApacheチューニング by 勲 國府田
中小規模サービスのApacheチューニング中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング
勲 國府田8K views
これからLDAPを始めるなら 「389-ds」を使ってみよう by Nobuyuki Sasaki
これからLDAPを始めるなら 「389-ds」を使ってみようこれからLDAPを始めるなら 「389-ds」を使ってみよう
これからLDAPを始めるなら 「389-ds」を使ってみよう
Nobuyuki Sasaki4.2K views
認証の課題とID連携の実装 〜ハンズオン〜 by Masaru Kurahayashi
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
OpenStackをさらに”使う”技術 概要と基礎操作 by irix_jp
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作
irix_jp5.5K views
PenTesterが知っている危ないAWS環境の共通点 by zaki4649
PenTesterが知っている危ないAWS環境の共通点 PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点
zaki464939.2K views
UEFI時代のブートローダ by Takuya ASADA
UEFI時代のブートローダUEFI時代のブートローダ
UEFI時代のブートローダ
Takuya ASADA25K views
Apache Kafka 0.11 の Exactly Once Semantics by Yoshiyasu SAEKI
Apache Kafka 0.11 の Exactly Once SemanticsApache Kafka 0.11 の Exactly Once Semantics
Apache Kafka 0.11 の Exactly Once Semantics
Yoshiyasu SAEKI6.2K views
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File) by Tetsuya Hasegawa
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
SSHパケットの復号ツールを作ろう_v1(Decrypt SSH .pcap File)
Tetsuya Hasegawa3K views
コンテナネットワーキング(CNI)最前線 by Motonori Shindo
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo31.7K views
10分で分かるLinuxブロックレイヤ by Takashi Hoshino
10分で分かるLinuxブロックレイヤ10分で分かるLinuxブロックレイヤ
10分で分かるLinuxブロックレイヤ
Takashi Hoshino16.3K views
Red Hat Update Infrastructure 2.0 by Etsuji Nakai
Red Hat Update Infrastructure 2.0Red Hat Update Infrastructure 2.0
Red Hat Update Infrastructure 2.0
Etsuji Nakai10K views
CloudFront経由でのCORS利用 by Yuta Imai
CloudFront経由でのCORS利用CloudFront経由でのCORS利用
CloudFront経由でのCORS利用
Yuta Imai12.1K views
SPAセキュリティ入門~PHP Conference Japan 2021 by Hiroshi Tokumaru
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru99.6K views
コンテナにおけるパフォーマンス調査でハマった話 by Yuta Shimada
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
Yuta Shimada2.2K views

Similar to http2 最速実装 v2

L2 over L3 ecnaspsulations by
L2 over L3 ecnaspsulationsL2 over L3 ecnaspsulations
L2 over L3 ecnaspsulationsMotonori Shindo
38.9K views35 slides
ネットワークプログラマビリティ勉強会 by
ネットワークプログラマビリティ勉強会ネットワークプログラマビリティ勉強会
ネットワークプログラマビリティ勉強会Tomoya Hibi
2.6K views46 slides
DB tech showcase_tokyo2018_LOCONDO by
DB tech showcase_tokyo2018_LOCONDODB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDOShinya Sugiyama
9.2K views46 slides
Locondo 20190215@ec tech_group by
Locondo 20190215@ec tech_groupLocondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupShinya Sugiyama
959 views42 slides
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1 by
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1Hideki Saito
2.9K views64 slides
Rubykansai 81 by
Rubykansai 81Rubykansai 81
Rubykansai 81Satomi Tsujita
552 views44 slides

Similar to http2 最速実装 v2 (20)

L2 over L3 ecnaspsulations by Motonori Shindo
L2 over L3 ecnaspsulationsL2 over L3 ecnaspsulations
L2 over L3 ecnaspsulations
Motonori Shindo38.9K views
ネットワークプログラマビリティ勉強会 by Tomoya Hibi
ネットワークプログラマビリティ勉強会ネットワークプログラマビリティ勉強会
ネットワークプログラマビリティ勉強会
Tomoya Hibi2.6K views
DB tech showcase_tokyo2018_LOCONDO by Shinya Sugiyama
DB tech showcase_tokyo2018_LOCONDODB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDO
Shinya Sugiyama9.2K views
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1 by Hideki Saito
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
Hideki Saito2.9K views
Amalgam8 application switch for cloud native services by Takehiko Amano
Amalgam8   application switch for cloud native servicesAmalgam8   application switch for cloud native services
Amalgam8 application switch for cloud native services
Takehiko Amano2.2K views
VMware NSXがサポートするトンネル方式について by Motonori Shindo
VMware NSXがサポートするトンネル方式についてVMware NSXがサポートするトンネル方式について
VMware NSXがサポートするトンネル方式について
Motonori Shindo4.2K views
Control distribution of virtual machines by irix_jp
Control distribution of virtual machinesControl distribution of virtual machines
Control distribution of virtual machines
irix_jp13.5K views
MariaDB Columnstore 使いこなそう by KAWANO KAZUYUKI
MariaDB Columnstore 使いこなそうMariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそう
KAWANO KAZUYUKI4.1K views
MySQL 5.7 InnoDB 日本語全文検索(その2) by yoyamasaki
MySQL 5.7 InnoDB 日本語全文検索(その2)MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)
yoyamasaki4.8K views
Segment Routing @ SDN Japan 2013 by Miya Kohno
Segment Routing @ SDN Japan 2013Segment Routing @ SDN Japan 2013
Segment Routing @ SDN Japan 2013
Miya Kohno82 views
130719 01 by openrtm
130719 01130719 01
130719 01
openrtm774 views
BGP as a method for Abstraction by Miya Kohno
BGP as a method for AbstractionBGP as a method for Abstraction
BGP as a method for Abstraction
Miya Kohno82 views
MySQL 入門的なはなし by Yuya Takeyama
MySQL 入門的なはなしMySQL 入門的なはなし
MySQL 入門的なはなし
Yuya Takeyama2.7K views
Apache Drill で日本語を扱ってみよう + オープンデータ解析 by MapR Technologies Japan
Apache Drill で日本語を扱ってみよう + オープンデータ解析Apache Drill で日本語を扱ってみよう + オープンデータ解析
Apache Drill で日本語を扱ってみよう + オープンデータ解析
Oracleの実行計画を読んでみよう! #dbts2017 by Ryota Watabe
Oracleの実行計画を読んでみよう!  #dbts2017Oracleの実行計画を読んでみよう!  #dbts2017
Oracleの実行計画を読んでみよう! #dbts2017
Ryota Watabe16.2K views

More from Yoshihiro Iwanaga

Arduino and johnny-five, creating IoT device in easiest way by
Arduino and johnny-five, creating IoT device in easiest wayArduino and johnny-five, creating IoT device in easiest way
Arduino and johnny-five, creating IoT device in easiest wayYoshihiro Iwanaga
2.4K views17 slides
Node.js Tutorial at Hiroshima by
Node.js Tutorial at HiroshimaNode.js Tutorial at Hiroshima
Node.js Tutorial at HiroshimaYoshihiro Iwanaga
17.7K views83 slides
Web Technology for Hardware Control (html5 conference 2015) by
Web Technology for Hardware Control (html5 conference 2015)Web Technology for Hardware Control (html5 conference 2015)
Web Technology for Hardware Control (html5 conference 2015)Yoshihiro Iwanaga
3.2K views15 slides
Map by
MapMap
MapYoshihiro Iwanaga
584 views1 slide
Mongodb World 2014 by
Mongodb World 2014Mongodb World 2014
Mongodb World 2014Yoshihiro Iwanaga
1.1K views21 slides
JavaScript と Arduino でオリジナルデバイスを作ろう by
JavaScript と Arduino でオリジナルデバイスを作ろうJavaScript と Arduino でオリジナルデバイスを作ろう
JavaScript と Arduino でオリジナルデバイスを作ろうYoshihiro Iwanaga
5.7K views40 slides

More from Yoshihiro Iwanaga(11)

Recently uploaded

パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可 by
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可Hitachi, Ltd. OSS Solution Center.
10 views22 slides
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向 by
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Hitachi, Ltd. OSS Solution Center.
109 views26 slides
光コラボは契約してはいけない by
光コラボは契約してはいけない光コラボは契約してはいけない
光コラボは契約してはいけないTakuya Matsunaga
28 views17 slides
定例会スライド_キャチs 公開用.pdf by
定例会スライド_キャチs 公開用.pdf定例会スライド_キャチs 公開用.pdf
定例会スライド_キャチs 公開用.pdfKeio Robotics Association
146 views64 slides
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」 by
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」PC Cluster Consortium
28 views36 slides

Recently uploaded(7)

光コラボは契約してはいけない by Takuya Matsunaga
光コラボは契約してはいけない光コラボは契約してはいけない
光コラボは契約してはいけない
Takuya Matsunaga28 views
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」 by PC Cluster Consortium
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」
PCCC23:東京大学情報基盤センター 「Society5.0の実現を目指す『計算・データ・学習』の融合による革新的スーパーコンピューティング」
PCCC23:富士通株式会社 テーマ1「次世代高性能・省電力プロセッサ『FUJITSU-MONAKA』」 by PC Cluster Consortium
PCCC23:富士通株式会社 テーマ1「次世代高性能・省電力プロセッサ『FUJITSU-MONAKA』」PCCC23:富士通株式会社 テーマ1「次世代高性能・省電力プロセッサ『FUJITSU-MONAKA』」
PCCC23:富士通株式会社 テーマ1「次世代高性能・省電力プロセッサ『FUJITSU-MONAKA』」

http2 最速実装 v2

  • 2. ゴール HTTP/2 クライアント  を 最⼩小限の時間  で実装できる状態になる 1.  HTTP/2 仕様 を理解 2.  実装に便利な ツール・情報源 を把握
  • 3. HTTP/2 仕様 1. 全体像を掴む HTTP/1.0, 1.1 どこがダメなの? 設計思想、⽬目的を知ると理理解が早くなる。 それをもとに HTTP/2 はどんな仕様になったの? 接続確⽴立立からレスポンス受信まで 2. 実装解説
  • 5. HTTP/1.1 の問題 ブラウザから 張れる接続数の上限: 5 client server 1 リクエストで  TCP コネクションを 1 つ消費。 6個⽬目のリクエストは 送信を待たないといけない。 リクエストを 6個  送りたい ※  Keep-‐‑‒Alive  は  3-‐‑‒way  handshake  を省省略略できるだけ。結局待つことになる。
  • 10. TCP  コネクション  1  つで 複数のリクエストを扱うためには 各リクエストの境界を判別する必要がある HTTP/2  では  Frame  で分割 Client Server req1req2 res1 res2 res1 続き TCP ペイロードの中に複数のデータを連結させる
  • 11. Frame の定義 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ http2-spec の 4.1. Frame Format
  • 12. Frame の全体像 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ その後に  Frame Payload が続く 最初の 64bit に  Frame Header
  • 13. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ R:  Reserved.  今は  0  を⼊入れることになっている。
  • 14. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Length:    Frame  Payload  のサイズ ※ Frame Header のサイズを⾜足しちゃダメ  J
  • 15. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Type:    Frame  Type  を番号で指定。
  • 16. Frame の種類 Type  ID タイプ名 意味 0x0 DATA HTTP/1  の  Body  に相当 0x1 HEADERS HTTP/1  の  Header  に相当 0x2 PRIORITY ストリームの優先度度 0x3 RST_STREAM ストリームの異異常終了了 0x4 SETTINGS ストリームの設定 0x5 PUSH_PROMISE サーバプッシュ 0x6 PING 死活監視、遅延測定 0x7 GOAWAY コネクション終了了 0x8 WINDOW_UPDATE フロー制御設定 0x9 CONTINUATION HEADERS,  PUSH_̲PROMISE の続き 0xa ALTSVC プロトコル切切り替え 0xb BLOCKED フロー制御デバッグ情報 (draft-‐‑‒12のみ)
  • 17. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Flags:  各  bit  で複数オプションの  On/Off  を表現
  • 18. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Stream  ID:  各リクエスト、レスポンスを識識別するための  ID
  • 19. Stream  ID  の意義 データがフラグメントした場合、 どの Frame の続きなのか判断したい。 そのために  Stream  ID  を利利⽤用 Client Serverres2 res1 続き res1 の⼀一部
  • 20. stream ID の管理理ルール Client Server 1 2 3 5 4 6 ・client  →  server  は奇数 ・server  →  client  は偶数 ・0  は全体の制御で利利⽤用
  • 21. Frame の仕様 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Frame  Payload:    Frame  Type  によって構造が違う。                   後ほど説明。
  • 22. Client Server req1req3 req2 res1 res2 res1 続き res3 必要な情報は出揃った。いざ実装!
  • 23. 順番 ServerClient 0. プロトコルネゴシエーション 1. Magic Octet 2. SETTINGS Frame 3. SETTINGS Frame ACK 4. SETTINGS Frame ACK 5. HEADERS Frame で GET / 6. HEADERS Frame 7. DATA Frame HTTP/2 接続確⽴立立 HTML
  • 24. 1. Magic Octet 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a PRI * HTTP/2.0rnrnSMrnrn HTTP/2  をサポートしているか最終チェック HTTP/2 をサポートしないサーバに ALPN しないで直接 HTTP/2リクエストした時に問題を出さないように。 HTTP/1.1 では「PRI メソッドは存在しない」と処理理して終了了。 送信するデータ
  • 25. 順番 ServerClient 0. プロトコルネゴシエーション 1. Magic Octet 2. SETTINGS Frame 3. SETTINGS Frame ACK 4. SETTINGS Frame ACK 5. HEADERS Frame で GET / 6. HEADERS Frame 7. DATA Frame HTTP/2 接続確⽴立立 HTML
  • 26. 2〜~4.  SETTINGS  Frame 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier (8)| +---------------+-----------------------------------------------+ | Value (32) | +---------------------------------------------------------------+ 下記を 0 個以上。 ※ 受信側は、Payload Length で個数が分かる。 payload  の定義 Step 2: Server へ  Stream ID = 0, payload 無しで送信 Step 3: Server から Stream ID =0, flags = 0x1 (ACK), payload を受信 Step 4: Client から Stream ID = 0, flags = 0x1 (ACK), payload 無しで送信
  • 27. 順番 ServerClient 0. プロトコルネゴシエーション 1. Magic Octet 2. SETTINGS Frame 3. SETTINGS Frame ACK 4. SETTINGS Frame ACK 5. HEADERS Frame で GET / 6. HEADERS Frame 7. DATA Frame HTTP/2 接続確⽴立立 HTML
  • 28. 5. HEADERS Frame 最後の難関 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pad High? (8) | Pad Low? (8) | +-+-------------+---------------+-------------------------------+ |E| Stream Dependency? (31) | +-+-------------+-----------------------------------------------+ | Weight? (8) | +-+-------------+-----------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+ flags                  =  END_̲HEADERS  |  END_̲STREAM stream  ID  =  1 Header Block Fragment: Payload はここだけになる。                         ※ 仕様は HPACK-07 に記載されている。
  • 29. 最短  HPACK http://example.com/  を  GET  する場合 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 1 | 0 | +---+---+-----------------------+ | 0 | Name Length (7+) | +---+---------------------------+ | Name String (Length octets) | +---+---------------------------+ | 0 | Value Length (7+) | +---+---------------------------+ | Value String (Length octets) | +-------------------------------+ Name Value :scheme http :authority example.com :path / :method GET Header  Block  の定義 (Literal  Header  Field  never  Indexed  &  ASCII  Encoding  パターン) サーバに送信する情報 最後に、4つの Header Block を連結すれば、最短 HPACK 完了了! :scheme は  7 ⽂文字 :scheme は ASCII で  0x3a736368656d65 http は  4 ⽂文字 http は ASCII で  0x68747470
  • 30. 順番 ServerClient 0. プロトコルネゴシエーション 1. Magic Octet 2. SETTINGS Frame 3. SETTINGS Frame ACK 4. SETTINGS Frame ACK 5. HEADERS Frame で GET / 6. HEADERS Frame 7. DATA Frame HTTP/2 接続確⽴立立 HTML
  • 31. 6〜~7.  レスポンス受信 まずは Data Frame の payload を⾒見見て感動しましょう  J この後紹介するサーバ実装は、Indexed で Huffman Encoding 7.  DATA  Frame  受信 6.  HEADERS  Frame  受信 この payload に HTML が⼊入ってます。 ここをきちんと実装するにはすごく時間がかかります。 これは後回しにして、先に DATA Frame を⾒見見てみましょう。
  • 32. 実装を効率率率よく進めるために •  仕様ドキュメント – HTTP/2-‐‑‒12 •  http://tools.ietf.org/html/draft-‐‑‒ietf-‐‑‒httpbis-‐‑‒ http2-‐‑‒12 – HPACK-‐‑‒07 •  http://tools.ietf.org/html/draft-‐‑‒ietf-‐‑‒httpbis-‐‑‒ header-‐‑‒compression-‐‑‒07 •  Public  Test  Server – nghttp2  (h12c,  upgrade/direct) •  http://nghttp2.org/
  • 33. テストサーバ  Docker file •  nghttp2 – Direct 接続⽤用 (ALPN 無し) •  https://gist.github.com/tsahara/ 7332972d057370d2e686 – ALPN 有り •  https://gist.github.com/tsahara/ e6831656d7e2ff99ce7e 提供:tsahara さん
  • 35. エンコーディング •  Huffman – 出現頻度度の⾼高い⽂文字を少ない bit で表現 – でも、今回の実装では使わない •  ASCII – ⾮非圧縮。簡単。 – 今回の実装ではこちらを使う
  • 36. インデックス index Header  Name Header  Value 1 :authority 2 :method GET 3 :method POST 4 :path / 5 :path /index.html 6 :scheme http 7 :scheme https 8 :status 200 9 :status 204 (以下略略) よく使うヘッダ名と値を  番号で指定 http://tools.ietf.org/html/ draft-ietf-httpbis-header-compression-07#appendix-B 今回の実装では利利⽤用しません。