SlideShare a Scribd company logo
HTTP2最速実装
~入門編~
前田 薫 (@mad_p)
http2 ハッカソン #1 2014/02/23
ドラフト12に合わせ修正 2014/05/12
1
はじめに
• 今日の目標
• HTTP2の処理系を最小限の労力で作れるようになる(性能は求めない)
• HTTP2.0 最速実装法が実装できるようになる
• https://github.com/http2jp/http2jp.github.io/wiki/HTTP2.0-
%E6%9C%80%E9%80%9F%E5%AE%9F%E8%A3%85%E6%B3%95
• HTTP2, HPACKの概要を理解する
• http://tools.ietf.org/html/draft-ietf-httpbis-http2-12 (このスライドはドラフト12ベースです)
• http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-07
2
目次
• HTTP2 Overview
• HTTP2の開始
• Frame定義
• HTTPメッセージの交換
• Stream管理
• HPACK(ヘッダ圧縮)
• まとめ
3
おさらい: HTTP 1.1
client server
①Request
②Response
4
connection
HTTP 1.1 REQUEST/RESPONSE
• テキスト形式、行指行
5
GET / HTTP/1.1
User-Agent: curl/7.30.0
Host: localhost
Accept: */*
HTTP/1.1 200 OK
Content-Length: 44
Content-Type: text/html
<html><body><h1>It
works!</h1></body></html>
CR+LF
Header Status
Request
Header
Body
CR+LF
HTTP2 OVERVIEW
6
HTTP2 OVERVIEW
7
client server
connection
①Request
②Response
stream
③Server-Push
CONNECTIONとSTREAM
• Connectionの中にstreamがある
• Streamは双方向
• Streamは複数同時に存在してもよい
• Streamはinterleaveして送信される
• Streamには番号がついている
• Clientからスタートしたら奇数、
• Serverからだと偶数
• Stream 0番を全体の制御に使う
• Request, Responseはstreamの中を通る 8
Stream 1
Stream 2
Stream 3
STREAMとFRAME
• StreamはFrameという単位で送信される
9
client server
FRAME
• バイナリ形式
• 1オクテット = 8ビット
• 左から右、上から下の順で送出 10
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...) ...
+---------------------------------------------------------------+
HTTPメッセージのFRAME表現
• HTTP 1.1 Request
• Request行
• Header部
• Body部(POST, PUTなど)
• HTTP 2
• HEADERS frame(s)
• Request行、Status行とヘッダ部を含む
• DATA frames
11
HTTP/1.1 200 OK
Content-Length: 44
Content-Type: text/html
<html><body><h1>It
works!</h1></body></html>
:status: 200
content-length: 44
content-type: text/html
<html><body><h1>It
works!</h1></body></html>
HEADERS
DATA
HTTP2の開始
12
HTTP2の開始
• HTTP2でフレームを送りあって通信するまでに、接続を確立する手順
• HTTP 1.1
• 1. TCP接続を確立
• 2. (httpsスキームの場合) TLSの確立
• 3. リスエスト送信
• 4. レスポンス受信
• HTTP 2
• 1. Connectionの確立(最初のフレームの送出) → 詳細は次ページ
• 2. その後のフレーム送受信 13
CONNECTION確立の方法
• TLS ALPN (Application Layer Protocol Negotiation extension)
• TLSの拡張
• http://d.hatena.ne.jp/ASnoKaze/20130207/1360249692
• http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05
• クライアントがClientHelloで使いたいプロトコルのリストを送る
• サーバーがその中から使うものを決めてServerHelloで知らせる
• TLS NPN (Next Protocol Negotiation extention) ALPNまでのつなぎ
• https://technotes.googlecode.com/git/nextprotoneg.html
• HTTP 1.1からのUpgrade
• HTTP 1.1形式のリクエスト内に「Upgradeヘッダ」を書く、SETTINGSをヘッダとして送る
• 事前知識によってTCP接続後にいきなりHTTP2 ← 最速実装ではこれを使います 14
HTTP2 CONNECTION PREFACE
• クライアント → サーバー
• 24オクテットのナゾの文字列を送る (HTTP 1.1からのUpgrade時も)
• 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
• アスキーの内容は「PRI * HTTP/2.0rnrnSMrnrn」 (PRISMが入ってるのは洒落)
• その後ろにSETTINGSフレーム(後述)を送る
• サーバー → クライアント
• SETTINGSフレームを送る
• SETTINGSフレーム: フロー制御、ヘッダ圧縮、同時接続ストリーム数などパラメータ
を通知
15
FRAME定義
16
フレームについて
• HTTPストリームの内容をフレームに分解して送る
• ひとつのフレームで送れるペイロードは16383オクテットまで
• バイナリ形式
17
00 40 01 05 00 00 00 01
00 07 3a 6d 65 74 68 6f
64 03 47 45 54 00 07 3a
73 63 68 65 6d 65 04 68
74 74 70 00 0a 3a 61 75
74 68 6f 72 69 74 79 0f
31 30 36 2e 31 38 36 2e
31 31 32 2e 31 31 36 00
05 3a 70 61 74 68 01 2f
FRAME FORMAT
• フレームヘッダ 8オクテット
• Length: ペイロードのオクテット数
• Type HEADERS, DATAなどフレームの種類を表わす整数
• Flags: タイプごとに定められた付加情報を持つ。特にEND_STREAM,END_HEADERSフラグが重要
• Stream Identifier: 31bitのストリームID
• フレームペイロード: タイプごとに定められたデータ内容
18
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 TYPES
Type 意味 Type番号(draft 12)
DATA データ 0x0
HEADERS ヘッダ 0x1
PRIORITY ストリームの優先度 0x2
RST_STREAM ストリームの異常終了 0x3
SETTINGS コネクションのパラメータ 0x4
PUSH_PROMISE サーバープッシュ 0x5
PING 死活監視+遅延測定 0x6
GOAWAY コネクション終了 0x7
WINDOW_UPDATE フロー制御パラメータ 0x8
CONTINUATION HEADERS, PUSH_PROMISEの続き 0x9
ALTSVC プロトコル切り換えの可能性を示す 0xa
BLOCKED フロー制御デバッグ情報(draft-12のみ) 0xb 19
DATA FRAME(TYPE 0X0)
• Data:
• データ自体を運ぶ。HTTP Bodyに相当
• 長さはペイロードの残り全部
• Pad High, Pad Low: パディングの長さ
• Padding: パディング
• DATAフレームのフラグ: フレームヘッダの中のFlagsフィールドに置く
• END_STREAM(0x1): ストリームの終了を示す
• END_SEGMENT(0x2): 中継時に合体させてはいけない範囲を示す
• PAD_LOW(0x8), PAD_HIGH(0x10): パディング長フィールドを使うかどうか示す
• COMPRESSED(0x20): Dataがフレーム単位でgzip圧縮されているかを示す
20
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) |
+---------------+---------------+-------------------------------+
| Data (*) ...
+---------------------------------------------------------------+
| Padding (*) ...
+---------------------------------------------------------------+
HEADERS FRAME(TYPE 0X1)
• Header Block Segment
• Key-valueペアの列を運ぶ
• HTTP Headerに相当
• HPACK形式で圧縮したもの
• E, Stream Dependency, Weight:
• ストリームの優先度情報
• Pad High, Pad Low, Padding: DATAフレームと同様
• HEADERフレームのフラグ
• END_STREAM(0x1),END_SEGMENT(0x2), PAD_LOW(0x8), PAD_HIGH(0x10): DATAと同じ
• END_HEADERS(0x4): ヘッダブロックがこのフレームで完結することを示す
• PRIORITY(0x20): 優先度情報フィールド3つを使うかどうかを示す 21
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 (*) ...
+---------------------------------------------------------------+
SETTINGS FRAME(TYPE 0X4)
• 5オクテットを1組として、ペイロード長
ぶんの設定が入っている
• 接続確立時におたがいに送り合う
• 接続中に送ってもよい
• SETTINGSフレームのストリームIDは必ず0
• SETTINGSフレームのフラグ
• ACK(0x1): 相手から送信されたSETTINGに対するACKを示す。このときペイロードは空
• SETTINGSを受け取ったら必すACKを返す(接続時の最初も)
• Identifier: 設定の種類を表わす識別子 Value: 設定値
22
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) |
+---------------------------------------------------------------+
SETTINGで定義されている設定
• 以下の設定のすべてを実装しないといけない(最速実装では無視します)
• SETTINGS_HEADER_TABLE_SIZE (1): ヘッダ圧縮に使うテーブルサイズ(初期値:4096)
• SETTINGS_ENABLE_PUSH (2):
• サーバーからのpushを許すかどうか(初期値1: 許可)。クライアント側からの指定のみ意味がある
• SETTINGS_MAX_CONCURRENT_STREAMS (3):
• 同時にactive状態になってよいストリーム数。100以上を推奨(初期値:制限なし)
• SETTINGS_INITIAL_WINDOW_SIZE (4):
• 受信バッファサイズの初期値。フロー制御で使う。2^31 – 1 まで(初期値:65535)
• SETTINGS_COMPRESS_DATA (5):
• DATAフレームのgzip圧縮を使ってよいかどうか(初期値0:禁止) 23
GOAWAY FRAME(0X7)
• これ以上ストリームを作るの禁止
• コネクションの終了を意図している
(でも送出側は作ってもいいことになっている)
• GOAWAYフレームのストリームIDは必ず0
• Last-Stream-ID: 処理中の最終ストリームID
• 相手が直前に送ったものがアプリ層に届いたかわかる
• Error Code: エラー情報
24
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| Last-Stream-ID (31) |
+-+-------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
| Additional Debug Data (*) |
+---------------------------------------------------------------+
これ以外のFRAME TYPES
• 以下のフレームタイプは最速実装では使いません
• PRIORITY
• RST_STREAM
• PUSH_PROMISE
• PING
• WINDOW_UPDATE
• CONTINUATION
• ALTSVC
• BLOCKED
25
HTTPメッセージの交換
26
HTTPリクエスト/レスポンスの表現
• リクエスト行、レスポンス行、ヘッダ部の情報をHEADERSフレームで
表現
• フレーム長制限を超える場合はCONTINUATIONを使う(最速実装では使いません)
• おさまり切る場合はEND_HEADERSフラグをつける
• ボディ部をDATAフレームで表現
• ボディ部が存在しない場合はDATAフレームを生成せず、HEADERSに
END_STREAMフラグをつける
• DATAフレームは複数になってもよい。最後のものにはEND_STREAMフラグをつ
ける
• HEADERS, DATAフレームを順に送出
27
HEADERSの作り方
• リクエストには以下のヘッダ名を使う。リクエスト行の要素はコロンつ
きのヘッダ名を使う
• :method HTTPメソッド。GET, POSTなど
• :scheme httpまたはhttpsのどちらか
• :authority リクエストURIのauthority部分 www.example.com:8080など
• :path パス
• レスポンスではステータスを:status に入れる
• この後HPACKで圧縮し、Frame headerと連結する
28
STREAM管理
29
STREAM IDの割当
• いままでに使った番号より大きな番号を使わないといけない
• クライアント発の場合には奇数を使う
• サーバー発の場合には偶数を使う(最速実装では使いません)
• ストリームID 0(ゼロ)はコネクション全体の制御を使うために予約
• SETTINGSのMAX_CONCURRENT_STREAMSより多くのストリームを
同時に作ってはいけない
• Open, half-closeのものを数える
• 番号を使いつくしたら? → 新しいコネクションを作る 30
STREAM STATE DIAGRAM
• ストリームのライフタイム定義
• Idle: 未作成
• Open: 使用中
• Half closed:
• 片側だけ使用中の状態
• 片方からEND_STREAMを送った場合
• Closed: 終了
• Reservedは最速実装では使いませ
ん
31
+--------+
PP | | PP
,--------| idle |--------.
/ | | 
v +--------+ v
+----------+ | +----------+
| | | H | |
,---| reserved | | | reserved |---.
| | (local) | v | (remote) | |
| +----------+ +--------+ +----------+ |
| | ES | | ES | |
| | H ,-------| open |-------. | H |
| | / | |  | |
| v v +--------+ v v |
| +----------+ | +----------+ |
| | half | | | half | |
| | closed | | R | closed | |
| | (remote) | | | (local) | |
| +----------+ | +----------+ |
| | v | |
| | ES / R +--------+ ES / R | |
| `----------->| |<-----------' |
| R | closed | R |
`-------------------->| |<--------------------'
+--------+
HPACK(ヘッダ圧縮)
32
HPACKの必要性
• なにしろでかいんですよ、HTTPヘッダーって。同じ情報を何度も送るし
• SPDYではzlibで圧縮していましたが、CRIME/BREACHアタックが出現
• 圧縮率観測攻撃:
• データをつっこんでやって、圧縮されるかどうか見ると、同じペイロード内の情報
(セッションクッキーなど)を調べることができてしまう
• 今日この後で勉強しましょう
• HPACK: 圧縮率観測攻撃に耐える圧縮形式として設計
33
HPACKの圧縮手段
• Huffman Encoding
• よく使う文字を少ないビット数で表現する
• Static Table Indexing
• よく使うヘッダをあらかじめ定義しておき、番号で指定する
• Header Table Indexing
• 最近送信したヘッダと同一だったら番号で指定する
• Reference Set Difference
• 最後に送出したヘッダとの差分だけを送る
34
HPACK最速実装
• 必ずリテラルで、Huffmanなしで、Without Indexモードで送る
• 各ヘッダを以下の形式でエンコード
• H: 0にする
• Lengthは
• 126 (2^7 – 2)以下はそのまま入れる
• 127以上は最初に127
• 127を引いた残りを128進数で、
最後のもの以外はMSBを立てる
35
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 |
+---+---+-----------------------+
| H | Name Length (7+) |
+---+---------------------------+
| Name String (Length octets) |
+---+---------------------------+
| H | Value Length (7+) |
+---+---------------------------+
| Value String (Length octets) |
+-------------------------------+
ヘッダの最速実装の例
36
:method: GET
:scheme: http
:path: /
:authority: www.example.com
00 07 3a 6d 65 74 68 6f 44
03 47 45 54
00 07 3a 73 63 68 65 6d 65
04 68 74 74 70
:
00 に続いて長さ7
そしてヘッダ名 :method
長さ3
そしてヘッダ値 GET
00 :scheme
httpこれをくり返し、全体の長さを数え
て、
先頭にフレームヘッダをつける
長さ64オクテット(0x40)、stream_id =
1,、END_STREAM、END_HEADERS
の場合
00 40 01 05 00 00 00 01
最速実装のリクエスト・レスポンス
37
38
client server
CONNECTION PREFACE
SETTINGS
SETTINGS
HEADERS
HEADERS
DATA
GOAWAY
:method GET
:
Stream ID = 1
END_HEADERS,
END_STREAM
Stream ID = 1
END_HEADERS,
Stream ID = 1
END_STREAM
SETTINGS ACK
SETTINGS ACK
serverからEND_STREAMが
来たらGOAWAYを送り、
TCP接続を切断
39
client server
50 52 49 20 2a 20 48 54
54 50 2f 32 2e 30 0d 0a
0d 0a 53 4d 0d 0a 0d 0a
00 40 01 05 00 00 00 01
00 07 3a 6d 65 74 68 6f
64 03 47 45 54 00 07 3a
73 63 68 65 6d 65 04 68
74 74 70 00 0a 3a 61 75
74 68 6f 72 69 74 79 0f
31 30 36 2e 31 38 36 2e
31 31 32 2e 31 31 36 00
05 3a 70 61 74 68 01 2f
CONNECTION PREFACE
00 00 04 00 00 00 00 00SETTINGS
HEADERS
00 0f 04 00 00 00 00 00
03 00 00 00 64
04 00 00 ff ff
02 00 00 00 00
SETTINGS
以下略
00 00 04 01 00 00 00 00SETTINGS ACK
00 00 04 01 00 00 00 00SETTINGS ACK
まとめ
40
HTTP2最速実装に向けて
• HTTP2の概要
• コネクション、ストリーム、フレーム
• HTTP Request / Responseの表現形式
• HEADERSフレーム、DATAフレーム
• HTTP2の開始シーケンス
• HPACKで楽をする実装方法
41
今日やらなかったこと
• その他の開始ハンドシェイク
• TLSからのALPN, HTTPからのUpgrade
• フロー制御、優先度制御
• エラー処理
42

More Related Content

What's hot

Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
 
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門Akihiro Kuwano
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
 
"SRv6の現状と展望" ENOG53@上越
"SRv6の現状と展望" ENOG53@上越"SRv6の現状と展望" ENOG53@上越
"SRv6の現状と展望" ENOG53@上越
Kentaro Ebisawa
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
 
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
NTT DATA OSS Professional Services
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
ネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのかネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのか
Jun Kato
 
TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話
Kazuho Oku
 
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
Motonori Shindo
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
Uptime Technologies LLC (JP)
 
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
NTT DATA Technology & Innovation
 
メルカリ・ソウゾウでは どうGoを活用しているのか?
メルカリ・ソウゾウでは どうGoを活用しているのか?メルカリ・ソウゾウでは どうGoを活用しているのか?
メルカリ・ソウゾウでは どうGoを活用しているのか?
Takuya Ueda
 
(2017.6.9) Neo4jの可視化ライブラリまとめ
(2017.6.9) Neo4jの可視化ライブラリまとめ(2017.6.9) Neo4jの可視化ライブラリまとめ
(2017.6.9) Neo4jの可視化ライブラリまとめ
Mitsutoshi Kiuchi
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku0825
 

What's hot (20)

Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
 
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
"SRv6の現状と展望" ENOG53@上越
"SRv6の現状と展望" ENOG53@上越"SRv6の現状と展望" ENOG53@上越
"SRv6の現状と展望" ENOG53@上越
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
 
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
 
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
ネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのかネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのか
 
TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話
 
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
 
PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門PostgreSQLアーキテクチャ入門
PostgreSQLアーキテクチャ入門
 
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
 
メルカリ・ソウゾウでは どうGoを活用しているのか?
メルカリ・ソウゾウでは どうGoを活用しているのか?メルカリ・ソウゾウでは どうGoを活用しているのか?
メルカリ・ソウゾウでは どうGoを活用しているのか?
 
(2017.6.9) Neo4jの可視化ライブラリまとめ
(2017.6.9) Neo4jの可視化ライブラリまとめ(2017.6.9) Neo4jの可視化ライブラリまとめ
(2017.6.9) Neo4jの可視化ライブラリまとめ
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 

Viewers also liked

MessagePack(msgpack): Compact and Fast Serialization Library
MessagePack(msgpack): Compact and Fast Serialization LibraryMessagePack(msgpack): Compact and Fast Serialization Library
MessagePack(msgpack): Compact and Fast Serialization Library
Takatoshi Kondo
 
Unpack mechanism of the msgpack-c
Unpack mechanism of the msgpack-cUnpack mechanism of the msgpack-c
Unpack mechanism of the msgpack-c
Takatoshi Kondo
 
Developing the fastest HTTP/2 server
Developing the fastest HTTP/2 serverDeveloping the fastest HTTP/2 server
Developing the fastest HTTP/2 server
Kazuho Oku
 
http2 最速実装 v2
http2 最速実装 v2 http2 最速実装 v2
http2 最速実装 v2
Yoshihiro Iwanaga
 
HTTP/2入門
HTTP/2入門HTTP/2入門
HTTP/2入門
渉 米須
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)shigeki_ohtsu
 
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後  #html5j #html5j_b大規模運用で見えるWebプロトコルの理想と現実、そして今後  #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
Yahoo!デベロッパーネットワーク
 

Viewers also liked (7)

MessagePack(msgpack): Compact and Fast Serialization Library
MessagePack(msgpack): Compact and Fast Serialization LibraryMessagePack(msgpack): Compact and Fast Serialization Library
MessagePack(msgpack): Compact and Fast Serialization Library
 
Unpack mechanism of the msgpack-c
Unpack mechanism of the msgpack-cUnpack mechanism of the msgpack-c
Unpack mechanism of the msgpack-c
 
Developing the fastest HTTP/2 server
Developing the fastest HTTP/2 serverDeveloping the fastest HTTP/2 server
Developing the fastest HTTP/2 server
 
http2 最速実装 v2
http2 最速実装 v2 http2 最速実装 v2
http2 最速実装 v2
 
HTTP/2入門
HTTP/2入門HTTP/2入門
HTTP/2入門
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)
 
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後  #html5j #html5j_b大規模運用で見えるWebプロトコルの理想と現実、そして今後  #html5j #html5j_b
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
 

Similar to HTTP2 最速実装 〜入門編〜

PostgreSQL Unconference #29 Unicode IVS
PostgreSQL Unconference #29 Unicode IVSPostgreSQL Unconference #29 Unicode IVS
PostgreSQL Unconference #29 Unicode IVS
Noriyoshi Shinoda
 
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
Yahoo!デベロッパーネットワーク
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
onozaty
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64FFRI, Inc.
 
MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)
yoyamasaki
 
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについてCentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
Nobuyuki Sasaki
 
Amalgam8 application switch for cloud native services
Amalgam8   application switch for cloud native servicesAmalgam8   application switch for cloud native services
Amalgam8 application switch for cloud native services
Takehiko Amano
 
Locondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupLocondo 20190215@ec tech_group
Locondo 20190215@ec tech_group
Shinya Sugiyama
 
5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範
Ivan Tu
 
JOSUG 34th Meetup
JOSUG 34th Meetup JOSUG 34th Meetup
JOSUG 34th Meetup
irix_jp
 
MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要
Shinya Sugiyama
 
Control distribution of virtual machines
Control distribution of virtual machinesControl distribution of virtual machines
Control distribution of virtual machinesirix_jp
 
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1Hideki Saito
 
Halide による画像処理プログラミング入門
Halide による画像処理プログラミング入門Halide による画像処理プログラミング入門
Halide による画像処理プログラミング入門
Fixstars Corporation
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
Kohei KaiGai
 
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
NTT DATA Technology & Innovation
 
システムパフォーマンス勉強会#8
システムパフォーマンス勉強会#8システムパフォーマンス勉強会#8
システムパフォーマンス勉強会#8
shingo suzuki
 
osoljp 2011.08
osoljp 2011.08osoljp 2011.08
osoljp 2011.08
@ otsuka752
 
HTTP/2, QUIC入門
HTTP/2, QUIC入門HTTP/2, QUIC入門
HTTP/2, QUIC入門
shigeki_ohtsu
 
MariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそうMariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそう
KAWANO KAZUYUKI
 

Similar to HTTP2 最速実装 〜入門編〜 (20)

PostgreSQL Unconference #29 Unicode IVS
PostgreSQL Unconference #29 Unicode IVSPostgreSQL Unconference #29 Unicode IVS
PostgreSQL Unconference #29 Unicode IVS
 
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
ヤフーのRDBと最新のMySQLの検証結果#yjdsw3
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64
 
MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)MySQL 5.7 InnoDB 日本語全文検索(その2)
MySQL 5.7 InnoDB 日本語全文検索(その2)
 
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについてCentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
CentOS 8で標準搭載! 「389-ds」で構築する 認証サーバーについて
 
Amalgam8 application switch for cloud native services
Amalgam8   application switch for cloud native servicesAmalgam8   application switch for cloud native services
Amalgam8 application switch for cloud native services
 
Locondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupLocondo 20190215@ec tech_group
Locondo 20190215@ec tech_group
 
5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範
 
JOSUG 34th Meetup
JOSUG 34th Meetup JOSUG 34th Meetup
JOSUG 34th Meetup
 
MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要MySQL8.0 SYS スキーマ概要
MySQL8.0 SYS スキーマ概要
 
Control distribution of virtual machines
Control distribution of virtual machinesControl distribution of virtual machines
Control distribution of virtual machines
 
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
沖縄オープンラボラトリ OpenStackハンズオンセミナー午後1
 
Halide による画像処理プログラミング入門
Halide による画像処理プログラミング入門Halide による画像処理プログラミング入門
Halide による画像処理プログラミング入門
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
 
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
 
システムパフォーマンス勉強会#8
システムパフォーマンス勉強会#8システムパフォーマンス勉強会#8
システムパフォーマンス勉強会#8
 
osoljp 2011.08
osoljp 2011.08osoljp 2011.08
osoljp 2011.08
 
HTTP/2, QUIC入門
HTTP/2, QUIC入門HTTP/2, QUIC入門
HTTP/2, QUIC入門
 
MariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそうMariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそう
 

More from Kaoru Maeda

Emacs TypeScript
Emacs TypeScriptEmacs TypeScript
Emacs TypeScript
Kaoru Maeda
 
IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)
Kaoru Maeda
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report Authorization
Kaoru Maeda
 
IETF97 Update oauth tokbind
IETF97 Update oauth tokbindIETF97 Update oauth tokbind
IETF97 Update oauth tokbind
Kaoru Maeda
 
IETF96 Update oauth tokbind
IETF96 Update oauth tokbindIETF96 Update oauth tokbind
IETF96 Update oauth tokbind
Kaoru Maeda
 
Ietf95 http2
Ietf95 http2Ietf95 http2
Ietf95 http2
Kaoru Maeda
 
http2study 20160423 IETF95 Report
http2study 20160423 IETF95 Reporthttp2study 20160423 IETF95 Report
http2study 20160423 IETF95 Report
Kaoru Maeda
 
From an Experience of Vulnerability Reporting
From an Experience of Vulnerability ReportingFrom an Experience of Vulnerability Reporting
From an Experience of Vulnerability Reporting
Kaoru Maeda
 
HTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのかHTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのか
Kaoru Maeda
 
IETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUICIETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUIC
Kaoru Maeda
 
IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方
Kaoru Maeda
 
Tokbind-fido
Tokbind-fidoTokbind-fido
Tokbind-fido
Kaoru Maeda
 
IETF92報告IoT関連
IETF92報告IoT関連IETF92報告IoT関連
IETF92報告IoT関連
Kaoru Maeda
 
IETF91報告arcmedia-mcic
IETF91報告arcmedia-mcicIETF91報告arcmedia-mcic
IETF91報告arcmedia-mcic
Kaoru Maeda
 
Ietf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauthIetf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauth
Kaoru Maeda
 
IETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG ReportIETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG Report
Kaoru Maeda
 
HTTP/2 Local activities in Japan
HTTP/2 Local activities in JapanHTTP/2 Local activities in Japan
HTTP/2 Local activities in Japan
Kaoru Maeda
 
IETF90 Web関連WG報告 #isocjp
IETF90 Web関連WG報告 #isocjpIETF90 Web関連WG報告 #isocjp
IETF90 Web関連WG報告 #isocjp
Kaoru Maeda
 
IETF90 IoT関連WG報告 #isocjp
IETF90 IoT関連WG報告 #isocjpIETF90 IoT関連WG報告 #isocjp
IETF90 IoT関連WG報告 #isocjp
Kaoru Maeda
 
HTTP/2 draft 14 preview and IETF90 httpbis WG Report
HTTP/2 draft 14 preview and IETF90 httpbis WG ReportHTTP/2 draft 14 preview and IETF90 httpbis WG Report
HTTP/2 draft 14 preview and IETF90 httpbis WG Report
Kaoru Maeda
 

More from Kaoru Maeda (20)

Emacs TypeScript
Emacs TypeScriptEmacs TypeScript
Emacs TypeScript
 
IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)IETF103の話題から (HTML5 Conf 2018)
IETF103の話題から (HTML5 Conf 2018)
 
IETF102 Report Authorization
IETF102 Report AuthorizationIETF102 Report Authorization
IETF102 Report Authorization
 
IETF97 Update oauth tokbind
IETF97 Update oauth tokbindIETF97 Update oauth tokbind
IETF97 Update oauth tokbind
 
IETF96 Update oauth tokbind
IETF96 Update oauth tokbindIETF96 Update oauth tokbind
IETF96 Update oauth tokbind
 
Ietf95 http2
Ietf95 http2Ietf95 http2
Ietf95 http2
 
http2study 20160423 IETF95 Report
http2study 20160423 IETF95 Reporthttp2study 20160423 IETF95 Report
http2study 20160423 IETF95 Report
 
From an Experience of Vulnerability Reporting
From an Experience of Vulnerability ReportingFrom an Experience of Vulnerability Reporting
From an Experience of Vulnerability Reporting
 
HTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのかHTTP/2: ぼくたちのWebはどう変わるのか
HTTP/2: ぼくたちのWebはどう変わるのか
 
IETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUICIETF93 Prague報告Web関連+QUIC
IETF93 Prague報告Web関連+QUIC
 
IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方IETF93プレ勉強会、ARTエリアの歩き方
IETF93プレ勉強会、ARTエリアの歩き方
 
Tokbind-fido
Tokbind-fidoTokbind-fido
Tokbind-fido
 
IETF92報告IoT関連
IETF92報告IoT関連IETF92報告IoT関連
IETF92報告IoT関連
 
IETF91報告arcmedia-mcic
IETF91報告arcmedia-mcicIETF91報告arcmedia-mcic
IETF91報告arcmedia-mcic
 
Ietf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauthIetf91報告 httpbis-httpauth
Ietf91報告 httpbis-httpauth
 
IETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG ReportIETF91 Honolulu httpbis WG Report
IETF91 Honolulu httpbis WG Report
 
HTTP/2 Local activities in Japan
HTTP/2 Local activities in JapanHTTP/2 Local activities in Japan
HTTP/2 Local activities in Japan
 
IETF90 Web関連WG報告 #isocjp
IETF90 Web関連WG報告 #isocjpIETF90 Web関連WG報告 #isocjp
IETF90 Web関連WG報告 #isocjp
 
IETF90 IoT関連WG報告 #isocjp
IETF90 IoT関連WG報告 #isocjpIETF90 IoT関連WG報告 #isocjp
IETF90 IoT関連WG報告 #isocjp
 
HTTP/2 draft 14 preview and IETF90 httpbis WG Report
HTTP/2 draft 14 preview and IETF90 httpbis WG ReportHTTP/2 draft 14 preview and IETF90 httpbis WG Report
HTTP/2 draft 14 preview and IETF90 httpbis WG Report
 

Recently uploaded

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
Matsushita Laboratory
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
Takayuki Nakayama
 
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさJSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
0207sukipio
 
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
Toru Tamaki
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
chiefujita1
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
Matsushita Laboratory
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
t m
 

Recently uploaded (10)

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
 
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさJSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
 
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
論文紹介:When Visual Prompt Tuning Meets Source-Free Domain Adaptive Semantic Seg...
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
TaketoFujikawa_物語のコンセプトに基づく情報アクセス手法の基礎検討_JSAI2024
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
 

HTTP2 最速実装 〜入門編〜

  • 1. HTTP2最速実装 ~入門編~ 前田 薫 (@mad_p) http2 ハッカソン #1 2014/02/23 ドラフト12に合わせ修正 2014/05/12 1
  • 2. はじめに • 今日の目標 • HTTP2の処理系を最小限の労力で作れるようになる(性能は求めない) • HTTP2.0 最速実装法が実装できるようになる • https://github.com/http2jp/http2jp.github.io/wiki/HTTP2.0- %E6%9C%80%E9%80%9F%E5%AE%9F%E8%A3%85%E6%B3%95 • HTTP2, HPACKの概要を理解する • http://tools.ietf.org/html/draft-ietf-httpbis-http2-12 (このスライドはドラフト12ベースです) • http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-07 2
  • 3. 目次 • HTTP2 Overview • HTTP2の開始 • Frame定義 • HTTPメッセージの交換 • Stream管理 • HPACK(ヘッダ圧縮) • まとめ 3
  • 4. おさらい: HTTP 1.1 client server ①Request ②Response 4 connection
  • 5. HTTP 1.1 REQUEST/RESPONSE • テキスト形式、行指行 5 GET / HTTP/1.1 User-Agent: curl/7.30.0 Host: localhost Accept: */* HTTP/1.1 200 OK Content-Length: 44 Content-Type: text/html <html><body><h1>It works!</h1></body></html> CR+LF Header Status Request Header Body CR+LF
  • 8. CONNECTIONとSTREAM • Connectionの中にstreamがある • Streamは双方向 • Streamは複数同時に存在してもよい • Streamはinterleaveして送信される • Streamには番号がついている • Clientからスタートしたら奇数、 • Serverからだと偶数 • Stream 0番を全体の制御に使う • Request, Responseはstreamの中を通る 8 Stream 1 Stream 2 Stream 3
  • 10. FRAME • バイナリ形式 • 1オクテット = 8ビット • 左から右、上から下の順で送出 10 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...) ... +---------------------------------------------------------------+
  • 11. HTTPメッセージのFRAME表現 • HTTP 1.1 Request • Request行 • Header部 • Body部(POST, PUTなど) • HTTP 2 • HEADERS frame(s) • Request行、Status行とヘッダ部を含む • DATA frames 11 HTTP/1.1 200 OK Content-Length: 44 Content-Type: text/html <html><body><h1>It works!</h1></body></html> :status: 200 content-length: 44 content-type: text/html <html><body><h1>It works!</h1></body></html> HEADERS DATA
  • 13. HTTP2の開始 • HTTP2でフレームを送りあって通信するまでに、接続を確立する手順 • HTTP 1.1 • 1. TCP接続を確立 • 2. (httpsスキームの場合) TLSの確立 • 3. リスエスト送信 • 4. レスポンス受信 • HTTP 2 • 1. Connectionの確立(最初のフレームの送出) → 詳細は次ページ • 2. その後のフレーム送受信 13
  • 14. CONNECTION確立の方法 • TLS ALPN (Application Layer Protocol Negotiation extension) • TLSの拡張 • http://d.hatena.ne.jp/ASnoKaze/20130207/1360249692 • http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05 • クライアントがClientHelloで使いたいプロトコルのリストを送る • サーバーがその中から使うものを決めてServerHelloで知らせる • TLS NPN (Next Protocol Negotiation extention) ALPNまでのつなぎ • https://technotes.googlecode.com/git/nextprotoneg.html • HTTP 1.1からのUpgrade • HTTP 1.1形式のリクエスト内に「Upgradeヘッダ」を書く、SETTINGSをヘッダとして送る • 事前知識によってTCP接続後にいきなりHTTP2 ← 最速実装ではこれを使います 14
  • 15. HTTP2 CONNECTION PREFACE • クライアント → サーバー • 24オクテットのナゾの文字列を送る (HTTP 1.1からのUpgrade時も) • 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a • アスキーの内容は「PRI * HTTP/2.0rnrnSMrnrn」 (PRISMが入ってるのは洒落) • その後ろにSETTINGSフレーム(後述)を送る • サーバー → クライアント • SETTINGSフレームを送る • SETTINGSフレーム: フロー制御、ヘッダ圧縮、同時接続ストリーム数などパラメータ を通知 15
  • 17. フレームについて • HTTPストリームの内容をフレームに分解して送る • ひとつのフレームで送れるペイロードは16383オクテットまで • バイナリ形式 17 00 40 01 05 00 00 00 01 00 07 3a 6d 65 74 68 6f 64 03 47 45 54 00 07 3a 73 63 68 65 6d 65 04 68 74 74 70 00 0a 3a 61 75 74 68 6f 72 69 74 79 0f 31 30 36 2e 31 38 36 2e 31 31 32 2e 31 31 36 00 05 3a 70 61 74 68 01 2f
  • 18. FRAME FORMAT • フレームヘッダ 8オクテット • Length: ペイロードのオクテット数 • Type HEADERS, DATAなどフレームの種類を表わす整数 • Flags: タイプごとに定められた付加情報を持つ。特にEND_STREAM,END_HEADERSフラグが重要 • Stream Identifier: 31bitのストリームID • フレームペイロード: タイプごとに定められたデータ内容 18 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...) ... +---------------------------------------------------------------+
  • 19. FRAME TYPES Type 意味 Type番号(draft 12) DATA データ 0x0 HEADERS ヘッダ 0x1 PRIORITY ストリームの優先度 0x2 RST_STREAM ストリームの異常終了 0x3 SETTINGS コネクションのパラメータ 0x4 PUSH_PROMISE サーバープッシュ 0x5 PING 死活監視+遅延測定 0x6 GOAWAY コネクション終了 0x7 WINDOW_UPDATE フロー制御パラメータ 0x8 CONTINUATION HEADERS, PUSH_PROMISEの続き 0x9 ALTSVC プロトコル切り換えの可能性を示す 0xa BLOCKED フロー制御デバッグ情報(draft-12のみ) 0xb 19
  • 20. DATA FRAME(TYPE 0X0) • Data: • データ自体を運ぶ。HTTP Bodyに相当 • 長さはペイロードの残り全部 • Pad High, Pad Low: パディングの長さ • Padding: パディング • DATAフレームのフラグ: フレームヘッダの中のFlagsフィールドに置く • END_STREAM(0x1): ストリームの終了を示す • END_SEGMENT(0x2): 中継時に合体させてはいけない範囲を示す • PAD_LOW(0x8), PAD_HIGH(0x10): パディング長フィールドを使うかどうか示す • COMPRESSED(0x20): Dataがフレーム単位でgzip圧縮されているかを示す 20 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) | +---------------+---------------+-------------------------------+ | Data (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+
  • 21. HEADERS FRAME(TYPE 0X1) • Header Block Segment • Key-valueペアの列を運ぶ • HTTP Headerに相当 • HPACK形式で圧縮したもの • E, Stream Dependency, Weight: • ストリームの優先度情報 • Pad High, Pad Low, Padding: DATAフレームと同様 • HEADERフレームのフラグ • END_STREAM(0x1),END_SEGMENT(0x2), PAD_LOW(0x8), PAD_HIGH(0x10): DATAと同じ • END_HEADERS(0x4): ヘッダブロックがこのフレームで完結することを示す • PRIORITY(0x20): 優先度情報フィールド3つを使うかどうかを示す 21 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 (*) ... +---------------------------------------------------------------+
  • 22. SETTINGS FRAME(TYPE 0X4) • 5オクテットを1組として、ペイロード長 ぶんの設定が入っている • 接続確立時におたがいに送り合う • 接続中に送ってもよい • SETTINGSフレームのストリームIDは必ず0 • SETTINGSフレームのフラグ • ACK(0x1): 相手から送信されたSETTINGに対するACKを示す。このときペイロードは空 • SETTINGSを受け取ったら必すACKを返す(接続時の最初も) • Identifier: 設定の種類を表わす識別子 Value: 設定値 22 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) | +---------------------------------------------------------------+
  • 23. SETTINGで定義されている設定 • 以下の設定のすべてを実装しないといけない(最速実装では無視します) • SETTINGS_HEADER_TABLE_SIZE (1): ヘッダ圧縮に使うテーブルサイズ(初期値:4096) • SETTINGS_ENABLE_PUSH (2): • サーバーからのpushを許すかどうか(初期値1: 許可)。クライアント側からの指定のみ意味がある • SETTINGS_MAX_CONCURRENT_STREAMS (3): • 同時にactive状態になってよいストリーム数。100以上を推奨(初期値:制限なし) • SETTINGS_INITIAL_WINDOW_SIZE (4): • 受信バッファサイズの初期値。フロー制御で使う。2^31 – 1 まで(初期値:65535) • SETTINGS_COMPRESS_DATA (5): • DATAフレームのgzip圧縮を使ってよいかどうか(初期値0:禁止) 23
  • 24. GOAWAY FRAME(0X7) • これ以上ストリームを作るの禁止 • コネクションの終了を意図している (でも送出側は作ってもいいことになっている) • GOAWAYフレームのストリームIDは必ず0 • Last-Stream-ID: 処理中の最終ストリームID • 相手が直前に送ったものがアプリ層に届いたかわかる • Error Code: エラー情報 24 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| Last-Stream-ID (31) | +-+-------------------------------------------------------------+ | Error Code (32) | +---------------------------------------------------------------+ | Additional Debug Data (*) | +---------------------------------------------------------------+
  • 25. これ以外のFRAME TYPES • 以下のフレームタイプは最速実装では使いません • PRIORITY • RST_STREAM • PUSH_PROMISE • PING • WINDOW_UPDATE • CONTINUATION • ALTSVC • BLOCKED 25
  • 27. HTTPリクエスト/レスポンスの表現 • リクエスト行、レスポンス行、ヘッダ部の情報をHEADERSフレームで 表現 • フレーム長制限を超える場合はCONTINUATIONを使う(最速実装では使いません) • おさまり切る場合はEND_HEADERSフラグをつける • ボディ部をDATAフレームで表現 • ボディ部が存在しない場合はDATAフレームを生成せず、HEADERSに END_STREAMフラグをつける • DATAフレームは複数になってもよい。最後のものにはEND_STREAMフラグをつ ける • HEADERS, DATAフレームを順に送出 27
  • 28. HEADERSの作り方 • リクエストには以下のヘッダ名を使う。リクエスト行の要素はコロンつ きのヘッダ名を使う • :method HTTPメソッド。GET, POSTなど • :scheme httpまたはhttpsのどちらか • :authority リクエストURIのauthority部分 www.example.com:8080など • :path パス • レスポンスではステータスを:status に入れる • この後HPACKで圧縮し、Frame headerと連結する 28
  • 30. STREAM IDの割当 • いままでに使った番号より大きな番号を使わないといけない • クライアント発の場合には奇数を使う • サーバー発の場合には偶数を使う(最速実装では使いません) • ストリームID 0(ゼロ)はコネクション全体の制御を使うために予約 • SETTINGSのMAX_CONCURRENT_STREAMSより多くのストリームを 同時に作ってはいけない • Open, half-closeのものを数える • 番号を使いつくしたら? → 新しいコネクションを作る 30
  • 31. STREAM STATE DIAGRAM • ストリームのライフタイム定義 • Idle: 未作成 • Open: 使用中 • Half closed: • 片側だけ使用中の状態 • 片方からEND_STREAMを送った場合 • Closed: 終了 • Reservedは最速実装では使いませ ん 31 +--------+ PP | | PP ,--------| idle |--------. / | | v +--------+ v +----------+ | +----------+ | | | H | | ,---| reserved | | | reserved |---. | | (local) | v | (remote) | | | +----------+ +--------+ +----------+ | | | ES | | ES | | | | H ,-------| open |-------. | H | | | / | | | | | v v +--------+ v v | | +----------+ | +----------+ | | | half | | | half | | | | closed | | R | closed | | | | (remote) | | | (local) | | | +----------+ | +----------+ | | | v | | | | ES / R +--------+ ES / R | | | `----------->| |<-----------' | | R | closed | R | `-------------------->| |<--------------------' +--------+
  • 33. HPACKの必要性 • なにしろでかいんですよ、HTTPヘッダーって。同じ情報を何度も送るし • SPDYではzlibで圧縮していましたが、CRIME/BREACHアタックが出現 • 圧縮率観測攻撃: • データをつっこんでやって、圧縮されるかどうか見ると、同じペイロード内の情報 (セッションクッキーなど)を調べることができてしまう • 今日この後で勉強しましょう • HPACK: 圧縮率観測攻撃に耐える圧縮形式として設計 33
  • 34. HPACKの圧縮手段 • Huffman Encoding • よく使う文字を少ないビット数で表現する • Static Table Indexing • よく使うヘッダをあらかじめ定義しておき、番号で指定する • Header Table Indexing • 最近送信したヘッダと同一だったら番号で指定する • Reference Set Difference • 最後に送出したヘッダとの差分だけを送る 34
  • 35. HPACK最速実装 • 必ずリテラルで、Huffmanなしで、Without Indexモードで送る • 各ヘッダを以下の形式でエンコード • H: 0にする • Lengthは • 126 (2^7 – 2)以下はそのまま入れる • 127以上は最初に127 • 127を引いた残りを128進数で、 最後のもの以外はMSBを立てる 35 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | +---+---+-----------------------+ | H | Name Length (7+) | +---+---------------------------+ | Name String (Length octets) | +---+---------------------------+ | H | Value Length (7+) | +---+---------------------------+ | Value String (Length octets) | +-------------------------------+
  • 36. ヘッダの最速実装の例 36 :method: GET :scheme: http :path: / :authority: www.example.com 00 07 3a 6d 65 74 68 6f 44 03 47 45 54 00 07 3a 73 63 68 65 6d 65 04 68 74 74 70 : 00 に続いて長さ7 そしてヘッダ名 :method 長さ3 そしてヘッダ値 GET 00 :scheme httpこれをくり返し、全体の長さを数え て、 先頭にフレームヘッダをつける 長さ64オクテット(0x40)、stream_id = 1,、END_STREAM、END_HEADERS の場合 00 40 01 05 00 00 00 01
  • 38. 38 client server CONNECTION PREFACE SETTINGS SETTINGS HEADERS HEADERS DATA GOAWAY :method GET : Stream ID = 1 END_HEADERS, END_STREAM Stream ID = 1 END_HEADERS, Stream ID = 1 END_STREAM SETTINGS ACK SETTINGS ACK serverからEND_STREAMが 来たらGOAWAYを送り、 TCP接続を切断
  • 39. 39 client server 50 52 49 20 2a 20 48 54 54 50 2f 32 2e 30 0d 0a 0d 0a 53 4d 0d 0a 0d 0a 00 40 01 05 00 00 00 01 00 07 3a 6d 65 74 68 6f 64 03 47 45 54 00 07 3a 73 63 68 65 6d 65 04 68 74 74 70 00 0a 3a 61 75 74 68 6f 72 69 74 79 0f 31 30 36 2e 31 38 36 2e 31 31 32 2e 31 31 36 00 05 3a 70 61 74 68 01 2f CONNECTION PREFACE 00 00 04 00 00 00 00 00SETTINGS HEADERS 00 0f 04 00 00 00 00 00 03 00 00 00 64 04 00 00 ff ff 02 00 00 00 00 SETTINGS 以下略 00 00 04 01 00 00 00 00SETTINGS ACK 00 00 04 01 00 00 00 00SETTINGS ACK
  • 41. HTTP2最速実装に向けて • HTTP2の概要 • コネクション、ストリーム、フレーム • HTTP Request / Responseの表現形式 • HEADERSフレーム、DATAフレーム • HTTP2の開始シーケンス • HPACKで楽をする実装方法 41
  • 42. 今日やらなかったこと • その他の開始ハンドシェイク • TLSからのALPN, HTTPからのUpgrade • フロー制御、優先度制御 • エラー処理 42