SlideShare a Scribd company logo
HTTP/2, QUIC入門
セキュリティキャンプ 2015
2015年8月12日
IIJ 大津 繁樹
更新版資料の置場 http://goo.gl/cX1M17
自己紹介
• 大津 繁樹
• 株式会社 インターネットイニシアティブ
• プロダクト本部 アプリケーション開発部サービス開発2課
• NodeJS Technical Committee メンバー
• (主にTLS/CRYPTO/OpenSSLバインディングを担当)
• IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。
• ブログ: http://d.hatena.ne.jp/jovi0608/
はじめに
• HTTP/2とQUICの概要を学んでいただきます。
• HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。
ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の
レベルの技術は見につきません。
• QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理
解するには相当の努力が必要です。
• 残念ながら2時間の時間では概要以上の技術レベルを取得する
のは難しいと思われます。
本講義の目的
• HTTP/2とQUICの技術的概要を知ることを目的とします。
• 概要レベル以上の技術を身につけるためHPACKについて詳細を
解説し、演習をしていただきます。
• できればHTTP/2データの解析ができるところまで目指します。
• 課題内容は空白にしています。講義当日にお知らせします。
本講義の内容
• HTTP/1.1からHTTP/2へ
• HTTP/2の仕組み概要
• HPACK詳細
• HTTP/2解析
• QUIC概要
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2
Frame Layer
HTTP/1.1
Semantics
HTTP/1.1からHTTP/2へ
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
RFC7540
SPDY/2
SPDY/3
SPDY/3.1
httpbis WG
暗黒の時代
HTTP-NG
中止
HPACK
RFC7541
HTTP/2サポート状況
http://caniuse.com/#feat=http2
HTTP転送サイズとリクエスト数の遷移
(2012/7/1~2015/7/1)
http://httparchive.org/trends.php?s=All&minlabel=Jul+1+2012&maxlabel=Jul+1+2015#bytesTotal&reqTotal
3年で
転送サイズ: 96%増
リクエスト数:20%増
(単一Webサイトの統計平均)
回線帯域を増速していくと
0
500
1000
1500
2000
2500
3000
3500
0 2 4 6 8 10 12
HTTP経由のダウンロード時間[ms]
回線帯域[MBps]
More Bandwidth does’nt matter よりデータ引用
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
ページの表示時間は、
これ以上短縮できない。
Make the Web Faster: Google の試験
RTT(Round Trip Time)を小さくしていくと
0
500
1000
1500
2000
2500
3000
3500
4000
4500
050100150200250300
HTTP経由のダウンロード時間[ms]
RTT[ms]
ちゃんと下がる
More Bandwidth does’nt matter よりデータ引用
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
Webページの表示速度を速くするには、回線速度増強よりRTT(の影
響)を小さくするかが重要。でも物理的な制限で難しい。
Make the Web Faster: Google の試験
SPDY(スピーディ)の登場(2009年)
• RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。
• SPDYは、Webページの表示速度を速くするためのプロトコル
として当初社内プロジェクトから生まれた。
• 既に3年以上に渡りGoogleの全サービスで利用され、Twitterや
Facebook、LINEなど大規模なシステムに導入されている。
ブラウザの拡張プラ
グイン(SPDY
Indicator)を使うと
SPDYを使っている
サイトがわかる
HTTP/1.1の問題点のおさらい
1. HTTP Head of Line Blocking
2. ネットワーク通信の利用が非効率
3. 曖昧でテキスト処理が煩雑
1. HTTP Head of Line Blocking
クライアント サーバ
HTTP/1.1
1本のTCP接続
HTTP リクエスト
HTTPレスポンス
待ち時間
HTTP リクエスト
HTTP/1.1
ブラウザは最大同時4~6TCP接続に制限
最大同時並列6
HTTP/2
100以上の同時リクエストが可能
全部同時
2. HTTP/1.1はネットワーク通信の利用が非効率
クライアント サーバ
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
それぞれのTCP接続が独立して輻輳制御を行う
HTTP/1.1は非効率なプロトコル
0
10
20
30
40
50
60
10 15 20 25 30 35 40 45
輻輳ウィンドウサイズ(mss)
時間(sec)
HTTP/1.1+SSLの輻輳ウィンドウサイズの変遷
SSL1
SSL2
SSL3
SSL4
SSL5
SSL6
6本のTCPがバラバラに
輻輳制御。帯域を有効
に使いきれてない
HTTP/2(SPDY)は効率的なプロトコル
0
10
20
30
40
50
60
60 65 70 75 80 85 90 95
輻輳ウィンドウサイズ(mss)
時間(sec)
SPDY利用時の輻輳ウィンドウサイズの変遷
SPDY
1本のTCPで最高速まで利
用。帯域を最大限に効率的
に使っている。
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
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は省いています)
データの
位置・サイズ・型
が明確
HTTP/2の仕組み概要
HTTP/2の技術的な特徴
•HTTP/1.1のセマンティックスを変えない。
•サーバへのTCP接続数を1つに限定
•TLSと連携してプロトコルを自動選択
•バイナリープロトコル(テキストデータの曖昧さを排除)
•全2重多重化通信
•フロー制御、優先度指定
•サーバプッシュ機能
HTTP/2の技術的な特徴
• SPDYのプロトコルアーキテクチャはそのまま利用
• SPDYの無駄なヘッダフィールドやフレームタイプを統廃合
し、簡略化
• SPDYの実運用で明らかとなったフロー制御・優先度制御と
いった課題へ対応する
• TLS利用を前提とするSPDYに対し、平文接続も利用可能に
する 。
• ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化し
たヘッダ送受信仕様(HPACK)を策定する
HTTP/2初期ニゴシエーション
3種類で2段階(その1)
あらかじめサーバがHTTP/2対応とわかって
いる場合、直接第2段階の接続方法を行う。
(DNSレコードや HTTPヘッダによるリダイレ
クト)
HTTP/1.1の接続後 Upgradeヘッダを使っ
て、HTTP/2 に接続をアップグレードす
る。
TLS接続時にALPN拡張フィールドを利用
してHTTP/2に接続を行う。(1) TLS + ALPN
(2) HTTP Upgrade
(3) 事前知識に
よるDirect接続
詳細後述
WebSocket
と一緒
詳細仕様
検討中
暗号化通信
平文通信
ALPN (Application Layer Protocol Negotiation)
クライアント
サーバー
1. ClientHello + ALPN拡張
2. ServerHello + ALPN拡張
サーバ側でプロトコルを決定し、通知する
h2
3. TLS 証明書・暗号化情報交換
プロトコルリストをサーバに送信
h2,spdy/3.1,http/1.1
HTTP/2で通信
TLSハンドシェイク
HTTP/2初期ニゴシエーション
3種類で2段階(その2)
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0¥r¥n
¥r¥n
SM¥r¥n
¥r¥n
クライアントから謎の24byteのマジックコード
をサーバに送り、初期情報(SETTINGSフレーム
を交換する)
SETTINGS
(初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含
む)
間違えてHTTP/1.1
サーバに接続した
場合は即切断され
る
演習:
• http2.koulayer.com にTLS接続をして http2 のハンドシェイクの
一部を見る。
• options に {NPNProtocols: ['h2'] } を追加し、HTTP/2のコネク
ションヘッダを送信する。
• サーバから返信されたデータを hex で標準出力に出す。
// TLS接続のサンプル
var tls = require('tls');
var opts = {host: host, port: 443};
var client = tls.connect(opts, function() {
client.on('data', function(c) {
});
client.write();
};
HTTP/2のデータフレーム(binary)
ペイロード長(24bit)
タイプ(8bit) フラグ(8bit)
X ストリームID(31bit)
ペイロードデータ(ペイロード長bit)
タイプ フレーム種類 タイプ フレーム種類
0x00 DATA 0x05 PUSH_PROMISE
0x01 HEADERS 0x06 PING
0x02 PRIORITY 0x07 GOAWAY
0x03 RST_STREAM 0x08 WINDOW_UPDATE
0x04 SETTINGS 0x09 CONTINUATION
デフォルトは14bit(16K),
24bit(16M)まで拡張可
フレームヘッダ
9バイト
演習: SETTINGS(Type:0x04)をパースする
SETTINGSフレームフォーマット
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
Length (24)
Type(8) Flags(8)
R Stream Identifier(31) (必ず0)
Identifier(16)
Value(32)
Identifier name
0x01 SETTINGS_HEADER_TABLE_SIZE
0x02 SETTINGS_ENABLE_PUSH
0x03 SETTINGS_MAX_CONCURRENT_STREAMS
0x04 SETTINGS_INITIAL_WINDOW_SIZE
0x05 SETTINGS_MAX_FRAME_SIZE
0x06 SETTINGS_MAX_HEADER_LIST_SIZE
前の演習でサーバから送信されたSETTINGS
フレームを解析し、フレームの各項目を
JSONで出力しなさい。
演習:SETTINGS AckとSETTINGSをサー
バに送る。
• サーバから受け取った SETTINGS の返信として、フラグフィー
ルドに Ack (0x01) を付けたSETTINGSフレームをサーバに送る。
• SETTINGS Ack は、Identifier/Value は付けないのでヘッダのみ
の送信になります。
• 次にクライアントからSETTINGSをサーバに送信します。
id/valueは好きな項目を好きな値で構いません。(なしでも
可)
フロー制御
クライアント
サーバA
サーバB
Reverse
Proxy
高速
低速
AとBからのデータを
バランスよく返す
WINDOW_UPDATE
WINDOW_UPDATE
サーバは、Window Size が
0になったらデータ送信を
停止
Window Size
を増加させる
サーバA,B への
ウィンドウサイ
ズ更新を調整
TCPコネクション、ストリーム毎にフロー制御が可能
プライオリティ
クライアント Reverse
Proxy
コンテンツ
HTML
画像
CSS, js
HTML
CSS JS
画像1 画像2 画像3 画像4
依存性と重みを指定
weight:16 weight:16
プライオリティのユースケース
• ファイルタイプ(HTML/CSS/JS/画像)に応
じた返答順序の指定
• タブ切り替えによる重みの上げ下げ
• 分割されたビデオデータなど順番が明示的
に決められている場合
Firefoxのプライオリティ依存機能
Stream:0x0
Stream:0x3
Leader
Stream:0x5
Unblocked
Stream:0x7
Background
weight:201 weight:1
weight:101
Stream:0xb
Follower
Stream:0x9
Speculative
weight:1
weight:1
css,js
ファイル
html,images等
その他
XHR
非同期js
明示的な
バックグラウンド
リクエスト
beacon等
大きなバック
グラウンド
リクエスト
idle
ストリーム
サーバプッシュ機能
コンテンツリクエスト
クライアント
サーバ
画像のHTTPリクエストを予約
コンテンツのレスポンス
画像データキャッシュ
サーバはコンテンツ
の中身を判断し,あ
らかじめコンテンツ
に含まれている画像
のリクエストを予約
する.
予約された画像リクエスト
はクライアントからサーバ
に送らずに,クライアント
はサーバ側からの画像デー
タの送付を待つ
サーバから送信され
た画像データは,ク
ライアントのキャッ
シュに保存
HPACK詳細
HPACKとは
• HTTP/2で用いられるヘッダ圧縮技術
• もともとSPDYでは gzipを使ったヘッダ圧縮を行っていたが暗
号化通信下でも情報が漏えい可能となるCRIME攻撃手法が公開
され、クライアントからサーバへのヘッダ圧縮が無効になって
いた。
• そこでHTTP/2専用でHTTPヘッダに特化した圧縮技術仕様
HPACKの開発を行った。
GET / HTTP/1.1
Host: www.google.co.jp
User-Agent: Mozilla/5.0 XXXXX
Accept: text/html,application/xhtml+xml,XXX
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTPヘッダの特徴とHPACKの方針
• HTTPヘッダは Name Value の集まり
• HTTPヘッダは繰り返し同じデータが送られることが多い
• リクエストパスなど頻繁に変わるものもある
• クッキーなどbase64エンコーディングされているようなものも
あり、使われる文字・記号種に偏りがある
• CRIMEの脅威を避けつつ、送受信するデータ量の圧縮ができる
ようにする
HPACK概要
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3., value3
……
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3., value3
……
X番のエントリー(nameX, valueX)送信します。
X番のエントリーのnameXを使うけど値は別の
valueX'のヘッダを送信します。後で使うからテー
ブルに追加しておいて。
クライアント・サーバ両者でインデックス番号が付いたヘッダ
テーブルを保持。そのインデックスを参照する情報を送る。
最も圧縮ができる時は、番号を通知するだけでよくなる。
HPACKエンコーディング種類
種類 Indexed Header
Field
Representation
Literal Header Field Representation Dynamic Table
Size UpdateLiteral Header
Field with
Incremental
Indexing
Literal Header
Field without
Indexing
Literal Header
Field Never
Indexed
最初の1バイト 1XXXXXXX 01XXXXXX 0000XXXX 0001XXXX 001XXXXX
ヘッダテーブル
中のエントリを
参照する方式
ヘッダテーブ
ルにエントリ
を追加する方
式
ヘッダテーブル
にエントリを追
加しない方式
ヘッダテーブル
にエントリを追
加しない方式
Proxy先にも強
要させる
ヘッダテーブル
のサイズ変更
番号だけ 文字も送る 制御用
Header Table
index header name header value
1 :authority
2 :method GET
3 :method POST
4 :path /
5 :path /index.html
…
60 via
61 www-authenticate
62 name2 value2
63 name1 value2
…
…
Static Table(変わらない)
Literal Header Field with Incremental
Indexing はここにエントリーを追加
Dynamic Table(追加される)
ヘッダテーブルサイズ
初期値:4096バイト
エントリー追加でサイ
ズ超過したら最後のエ
ントリーを取り除く
Indexed Header
Field Representationはこの
index番号だけを参照して
ヘッダ情報を伝える。
Literal Header Fieldでnameだけがテーブル
に存在するものは、index番号を参照する。
HPACKはビットの世界
0 1 X X X X X
X X X X X X X
X X X X X X X
ヘッダビット(1~4bits)
種類によって変わる 中途半端なオフセットから始まるこ
こに任意のサイズの整数値や文字列
などのヘッダ情報を無駄なく入れ込
むにはどうしたらよいだろうか?
整数値の入れ込み方: Integer Representation
文字列の入れ込み方: String Literal Representation
Integer Representation
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7
なんかのヘッダビット ここの領域に整数を格納したい
0~2^5-1
まで大丈夫
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1 32以上はど
うする?
どうしたらここ
に桁を上げる
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
続く前の整数表示と違うなんかのデータ
整数と続くデー
タの切れ目をど
う判断する?
Integer Representation
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1
続く前の整数表示と違うなんかのデータ
じゃどうするか?
最上位ビットは整数表示に使わない。
継続フラグ
1:次のバイトに整数表示が続く
0:このバイトで終わり
prefix length
127超で
桁上がり
種類によって prefix
lengthを指定
演習:Integer Representation
• 3 bit prefix で 3 を表す
• 3 bit prefix で 10 を表す
• 3 bit prefix で 150 を表す
• 4 bit prefix の 0x04 の整数は?
• 4 bit prefix の 0x0f04 の整数は?
• 4 bit prefix の 0x0fc601 の整数は?
String Literal Representation
0 1 2 3 4 5 6 7
H 文字列長 (7-bit prefix)
文字列データ
Huffman符号化
をしているか
文字列長を7bit-
prefixでエン
コード
文字列長分デー
タを入れる
0 1 2 3 4 5 6 7
0 0 0 0 0 0 0 1
0 1 1 0 0 0 0 1
H:0
Huffman符号化
せず
文字列長:1
文字列: 0x61(a)
ハフマン符号化せずに一文字の a を表すと
文字列を表すには、文字列長とデータの2つが必要
文字列データの更なる圧縮のためHuffman符号化をサポート
Huffman符号化
• 通常データで利用される文字種や記号には偏りがある。
• 頻度情報から良く使われるものに短いビット列を割り当て、そ
うでないものに長いビットを割り当てて符号化すると統計的に
全体のデータ量を削減することができる。
文字・記号 割当ビット 長さ
a 00011 5 bits (3bits分お得)
< 111111111111100 15bits (7bits分損)
HPACKのHuffman符号化
• String Literal Representation中の文字列をHuffman符号化できる
様にしてデータ量を圧縮する。
• 先頭の1ビットをHuffman符号化を行っているかのフラグにする
• Google Chromeで収集したHTTPヘッダ文字種の頻度情報の統計
からHuffman木を生成し、符号を割り当てた。
https://httpwg.github.io/specs/rfc7541.html#huffman.code
• 文字列の最後がバイト境界でない場合は、EOS(All bits 1)で埋め
る。
Root
0
1
0
0 1
1
0
0
0 1
1
2 a
!
0
s t
0
c e
1
i o
1
1
0
%
1
- .
0
/ 3
1
4 5
0
0
6 7
1
8 9
1
0
0 1
1
0
1
0 1
0
= A
1
_ b
0
0
d f
1
g h
1
0
l m
1
n p
0
0
r u
1
1
0
: B
1
C D
1
1
1
0
0
0
0
0
1
1
10
#
HPACKのHuffman木
Hello!のHuffman符号化
文字 符号 符号長
! 1111111000 10
H 1100011 7
e 00101 5
l 101000 6
o 00111 5
H e l l o ! EOS
1100011 00101 101000 101000 00111 1111111000 1
40 bits
40/48=83.3 約17%削減
演習: Huffman符号化
• abc をハフマン符号でエンコードしてHex文字列で出力する。
• 0x21231f をハフマン符号デコードしてみる。
文字 ascii 符号 符号長
a 0x61 00011 5
b 0x62 100011 6
c 0x63 00100 5
演習: String Literal
• Huffman符号化せず abc を String Literal で表してみる。
• Huffman符号化して abc を String Literal で表してみる。
• String Literalで符号化された 0x03626164 の文字は何か?
• String Literalで符号化された 0x821C64の文字は何か?
Indexed Header Field Representation
0 1 2 3 4 5 6 7
1 Index (7-bit prefix)
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Header Tableの indexの
name value 両方をその
まま使う
Literal Header Field with Incremental
Indexing
0 1 2 3 4 5 6 7
0 1 Index (6-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 1 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
61 … …
62 … …
63 … …
… … …
Indexed Name
New Name
Header Tableの indexの
nameだけ使う。
ここで使われた name,
valueを62番目に挿入す
る。
Literal Header Field without Indexing
0 1 2 3 4 5 6 7
0 0 0 0 Index (4-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 0 0 0 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Indexed Name
New Name
Header Tableの indexの
nameだけ使う。
Header Tableの変更はなし
Literal Header Field Never Indexed
0 1 2 3 4 5 6 7
0 0 0 1 Index (4-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 0 0 1 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Indexed Name
New Name
Header Tableの変更はなし
Header Tableの indexの
nameだけ使う。
without IndexingとNever Indexed
• HPACKではCRIME攻撃が困難になったが完全に防げるわけではない。
• なぜならHeaderTableへのindex化によって圧縮サイズが変わり、その
情報を手掛かりに機密データの推測が理論的に可能となる。
• セキュリティ的に機密度の高いデータ(パスワード・クッキー情報)
は、ヘッダテーブルにインデックスしないことを明示的に示すため
Never Indexedが設けられた。途中でもProxyでも方式変更を禁止する。
Proxy
Never Indexed (機密的に重要)
途中で方式を変えちゃいけない
without Indexing with indexing
変えてもOK
Dynamic Table Size Update
0 1 2 3 4 5 6 7
0 0 1 Max Size(5-bit prefix)
Header Table
index
1
2
3
…
…
Header TableのMaxSizeを変更する。
小さくなる場合は、サイズが超えた
分エントリーを最後から削除する。
SETTINGS_HEADER_TABLE_SIZEで指定
した以下の値であること
演習: HPACK
Indexed Representation
Header Table
index header name header value
1 :authority
2 :method GET
4 :path /
7 :scheme https
• 以下の3つのヘッダをIndexed Representationでエンコードし
てhex文字列で出力しなさい。
• [{name: ':method', value: 'GET'}, {name: ':path', value: '/'}, {name:
':scheme', value: 'https'}]
演習: HPACK
Literal Header Field without Indexing
• [{name: ':authority', value: 'http2.koulayer.com'}] をLiteral Header
Field without Indexing(Indexed Name)でエンコードし、hex文字
列で出力しなさい。(Huffman符号化しなくてもよい)
Header Table
index header name header value
1 :authority
2 :method GET
4 :path /
7 :scheme https
HTTP/2 クライアントの実装
演習:HTTP/2 リクエストの送信
• 前の演習で作成した[{name: ':method', value: 'GET'}, {name:
':path', value: '/'}, {name: ':scheme', value: 'https'}, {name:
':authority', value: 'http2.koulayer.com'}]] のHPACKエンコーディ
ングデータを使ってHEADERフレームを作成し、SETTING-Ack
後のサーバに送信しなさい。
HEADERSフレームフォーマット
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
Length (24)
Type(8)
0x01
Flags(8)
END_HEADERS (0x4)のみ
R Stream Identifier(31) (idは1を利用する)
Header Block
演習: HTTP/2 レスポンスの解析
• サーバからHEADERとDATAフレームが返信されてくるので、
データを解析してJSON形式で出力しなさい。
DATAフレームフォーマット
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
Length (24)
Type(8)
0x00
Flags(8)
R Stream Identifier(31)
Data
QUIC概要
TCPの問題点
• TCP Head of Line Blocking.
• 3方向ハンドシェイクのコスト.
• initcwnd(初期輻輳ウィンドウ)が小さくスロースタート
• パケットロスによる大きなバックオフ(待ち時間)
• カーネルのソケットバッファの増大
• NATのタイムアウトとIPのローミング
• 経路途中のTCP Buffer Bloat
TCP Fast
Open
initCWND10
TCP cubic
Random packet
drop in router
TCP_NOT_SENT_LOWAT
解決策は提示されているが、OSや中継機の機能追加が必要
これは非常に時間がかかる。
TLSの問題点
• TLSのハンドシェイクネゴシエーションのコスト
• ChangeCipherSpecが来るまで待たないといけない
• 負荷分散のバグによるClientHelloのサイズ制限
• サーバから送信する証明書チェーンの肥大
• 再接続や再ネゴシエーションはコストがかかり最適化できてな
い
Ballooning
Extension
TLS Ticket, Channel
ID
TLS False Start
TLSのライブラリや中継機のバージョンアップが必要
SPDY
TCP HoLブロックとTCP+TLSハンドシェイク
5 4 3 1
ロス!
67
ブロック!
TCP
syn
syn+ack
ack
ClientHello
ServerHello
Certificate
Server Key Exchange
Client Key Exchange Change Cipher Spec
FInished
Application Data
TCP
ハンドシェイク
Change Cipher Spec
Finished
TLS
ハンドシェイク
SPDY SPDYSPDY SPDY
SPDYSPDY
新プロトコル: QUIC
(Quic UDP Internet Connections)
IP(IPv4/IPv6)
UDP
TCP
TLS
QUIC
HTTP/2
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の公表値)
QUIC 1-RTTハンドシェイク(新規)
クライアント サーバ
CHLO (STK, VER, CCS, PDMD, SCID)
REJ(STK, SNO, SCFG)
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
Source Address Token
TLS1.3のknown_configrationに近い
0-RTT (再接続)
クライアント サーバ
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
Source Address Token
TLS1.3のknown_configrationに近い
演習:QUIC

More Related Content

What's hot

コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
 
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Shin Ohno
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
 
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
信之 岩永
 
Spring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作るSpring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作る
Go Miyasaka
 
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
Samir Hammoudi
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safeKumazaki Hiroki
 
とある診断員とSQLインジェクション
とある診断員とSQLインジェクションとある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
 
Apache Arrow
Apache ArrowApache Arrow
Apache Arrow
Kouhei Sutou
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
Tetsutaro Watanabe
 
Glibc malloc internal
Glibc malloc internalGlibc malloc internal
Glibc malloc internal
Motohiro KOSAKI
 
CyberChefの使い方(HamaCTF2019 WriteUp編)
CyberChefの使い方(HamaCTF2019 WriteUp編)CyberChefの使い方(HamaCTF2019 WriteUp編)
CyberChefの使い方(HamaCTF2019 WriteUp編)
Shota Shinogi
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向
shigeki_ohtsu
 
gRPC入門
gRPC入門gRPC入門
gRPC入門
Kenjiro Kubota
 
Scapyで作る・解析するパケット
Scapyで作る・解析するパケットScapyで作る・解析するパケット
Scapyで作る・解析するパケット
Takaaki Hoyo
 
.NET 7期待の新機能
.NET 7期待の新機能.NET 7期待の新機能
.NET 7期待の新機能
TomomitsuKusaba
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
murachue
 

What's hot (20)

コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
 
Spring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作るSpring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作る
 
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safe
 
とある診断員とSQLインジェクション
とある診断員とSQLインジェクションとある診断員とSQLインジェクション
とある診断員とSQLインジェクション
 
Apache Arrow
Apache ArrowApache Arrow
Apache Arrow
 
MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法MongoDBが遅いときの切り分け方法
MongoDBが遅いときの切り分け方法
 
Glibc malloc internal
Glibc malloc internalGlibc malloc internal
Glibc malloc internal
 
CyberChefの使い方(HamaCTF2019 WriteUp編)
CyberChefの使い方(HamaCTF2019 WriteUp編)CyberChefの使い方(HamaCTF2019 WriteUp編)
CyberChefの使い方(HamaCTF2019 WriteUp編)
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向
 
gRPC入門
gRPC入門gRPC入門
gRPC入門
 
Scapyで作る・解析するパケット
Scapyで作る・解析するパケットScapyで作る・解析するパケット
Scapyで作る・解析するパケット
 
.NET 7期待の新機能
.NET 7期待の新機能.NET 7期待の新機能
.NET 7期待の新機能
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 

Similar to HTTP/2, QUIC入門

RouterBOARD with OpenFlow
RouterBOARD with OpenFlowRouterBOARD with OpenFlow
RouterBOARD with OpenFlow
Toshiki Tsuboi
 
Windowsのパケットモニタ作成
Windowsのパケットモニタ作成Windowsのパケットモニタ作成
Windowsのパケットモニタ作成
Shinichi Hirauchi
 
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Panda Yamaki
 
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
You_Kinjoh
 
VHDL-2008が好きなんです
VHDL-2008が好きなんですVHDL-2008が好きなんです
VHDL-2008が好きなんです
windy12806
 
SystemC Tutorial
SystemC TutorialSystemC Tutorial
SystemC Tutorialkocha2012
 
産学間連携推進室(AC部屋) 2012 成果報告会
産学間連携推進室(AC部屋) 2012 成果報告会産学間連携推進室(AC部屋) 2012 成果報告会
産学間連携推進室(AC部屋) 2012 成果報告会Hirotaka Kawata
 
ORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みするORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みする
Yusuke Naka
 
OSセキュリティチュートリアル
OSセキュリティチュートリアルOSセキュリティチュートリアル
OSセキュリティチュートリアルKuniyasu Suzaki
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
 
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみようHokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Panda Yamaki
 
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
日本ヒューレット・パッカード株式会社
 
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
Yusuke Naka
 
パケットフィルタリングの考え方
パケットフィルタリングの考え方パケットフィルタリングの考え方
パケットフィルタリングの考え方Koiwa Hidekazu
 
Cvim saisentan 半精度浮動小数点数 half
Cvim saisentan 半精度浮動小数点数 halfCvim saisentan 半精度浮動小数点数 half
Cvim saisentan 半精度浮動小数点数 half
tomoaki0705
 
Trema day 1
Trema day 1Trema day 1
Trema day 1
ykuga
 
PIC RoR Heroku
PIC RoR HerokuPIC RoR Heroku
PIC RoR Heroku
mgwsuzuki
 
HaskellではじめるCortex-M3組込みプログラミング
HaskellではじめるCortex-M3組込みプログラミングHaskellではじめるCortex-M3組込みプログラミング
HaskellではじめるCortex-M3組込みプログラミングKiwamu Okabe
 
Bluetooth通信の 仕組みと活用法紹介
Bluetooth通信の仕組みと活用法紹介Bluetooth通信の仕組みと活用法紹介
Bluetooth通信の 仕組みと活用法紹介
Takehiko YOSHIDA
 

Similar to HTTP/2, QUIC入門 (20)

RouterBOARD with OpenFlow
RouterBOARD with OpenFlowRouterBOARD with OpenFlow
RouterBOARD with OpenFlow
 
Cpu cache arch
Cpu cache archCpu cache arch
Cpu cache arch
 
Windowsのパケットモニタ作成
Windowsのパケットモニタ作成Windowsのパケットモニタ作成
Windowsのパケットモニタ作成
 
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
 
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
HTML5と WebSocket / WebRTC / Web Audio API / WebGL 技術解説
 
VHDL-2008が好きなんです
VHDL-2008が好きなんですVHDL-2008が好きなんです
VHDL-2008が好きなんです
 
SystemC Tutorial
SystemC TutorialSystemC Tutorial
SystemC Tutorial
 
産学間連携推進室(AC部屋) 2012 成果報告会
産学間連携推進室(AC部屋) 2012 成果報告会産学間連携推進室(AC部屋) 2012 成果報告会
産学間連携推進室(AC部屋) 2012 成果報告会
 
ORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みするORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みする
 
OSセキュリティチュートリアル
OSセキュリティチュートリアルOSセキュリティチュートリアル
OSセキュリティチュートリアル
 
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
 
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみようHokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう
 
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
企業の成長を飛躍させるクラウドを ~クラウド勝者に導く次世代インフラとは~
 
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
実践 WebRTC 〜最新事例と開発ノウハウの紹介〜
 
パケットフィルタリングの考え方
パケットフィルタリングの考え方パケットフィルタリングの考え方
パケットフィルタリングの考え方
 
Cvim saisentan 半精度浮動小数点数 half
Cvim saisentan 半精度浮動小数点数 halfCvim saisentan 半精度浮動小数点数 half
Cvim saisentan 半精度浮動小数点数 half
 
Trema day 1
Trema day 1Trema day 1
Trema day 1
 
PIC RoR Heroku
PIC RoR HerokuPIC RoR Heroku
PIC RoR Heroku
 
HaskellではじめるCortex-M3組込みプログラミング
HaskellではじめるCortex-M3組込みプログラミングHaskellではじめるCortex-M3組込みプログラミング
HaskellではじめるCortex-M3組込みプログラミング
 
Bluetooth通信の 仕組みと活用法紹介
Bluetooth通信の仕組みと活用法紹介Bluetooth通信の仕組みと活用法紹介
Bluetooth通信の 仕組みと活用法紹介
 

More from shigeki_ohtsu

Node最新トピックス
Node最新トピックスNode最新トピックス
Node最新トピックス
shigeki_ohtsu
 
HTTP/2の現状とこれから
HTTP/2の現状とこれからHTTP/2の現状とこれから
HTTP/2の現状とこれから
shigeki_ohtsu
 
Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法
shigeki_ohtsu
 
Technical Overview of QUIC
Technical  Overview of QUICTechnical  Overview of QUIC
Technical Overview of QUIC
shigeki_ohtsu
 
Node-v0.12の新機能について
Node-v0.12の新機能についてNode-v0.12の新機能について
Node-v0.12の新機能についてshigeki_ohtsu
 
httpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートhttpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートshigeki_ohtsu
 
第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモshigeki_ohtsu
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)shigeki_ohtsu
 
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tHTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tshigeki_ohtsu
 
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)shigeki_ohtsu
 
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話shigeki_ohtsu
 
httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話shigeki_ohtsu
 
Node.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたNode.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたshigeki_ohtsu
 
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するそうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
 
SPDYの中身を見てみよう
SPDYの中身を見てみようSPDYの中身を見てみよう
SPDYの中身を見てみようshigeki_ohtsu
 
node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成
shigeki_ohtsu
 

More from shigeki_ohtsu (18)

Node最新トピックス
Node最新トピックスNode最新トピックス
Node最新トピックス
 
HTTP/2の現状とこれから
HTTP/2の現状とこれからHTTP/2の現状とこれから
HTTP/2の現状とこれから
 
Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法Node-v0.12のTLSを256倍使いこなす方法
Node-v0.12のTLSを256倍使いこなす方法
 
Technical Overview of QUIC
Technical  Overview of QUICTechnical  Overview of QUIC
Technical Overview of QUIC
 
Node-v0.12の新機能について
Node-v0.12の新機能についてNode-v0.12の新機能について
Node-v0.12の新機能について
 
httpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポートhttpbis interim@チューリッヒ レポート
httpbis interim@チューリッヒ レポート
 
第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ第43回HTML5とか勉強会 SPDY/QUICデモ
第43回HTML5とか勉強会 SPDY/QUICデモ
 
HTTP/2.0がもたらす Webサービスの進化(後半)
HTTP/2.0がもたらすWebサービスの進化(後半)HTTP/2.0がもたらすWebサービスの進化(後半)
HTTP/2.0がもたらす Webサービスの進化(後半)
 
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_tHTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
HTTP/2.0 HPAC-03 エンコーディング手法 by tatsuhiro_t
 
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)httpbis interim@シアトル レポート(第2回HTTP/2.0接続試験)
httpbis interim@シアトル レポート (第2回HTTP/2.0接続試験)
 
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
Node の HTTP/2.0 モジュール iij-http2 の実装苦労話
 
httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話httpbis interim とhttp2.0相互接続試験の話
httpbis interim とhttp2.0相互接続試験の話
 
Stream2の基本
Stream2の基本Stream2の基本
Stream2の基本
 
Node.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りましたNode.js で SPDYのベンチマーク体験サイトを作りました
Node.js で SPDYのベンチマーク体験サイトを作りました
 
SPDYの話
SPDYの話SPDYの話
SPDYの話
 
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解するそうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
そうだったのか! よくわかる process.nextTick() node.jsのイベントループを理解する
 
SPDYの中身を見てみよう
SPDYの中身を見てみようSPDYの中身を見てみよう
SPDYの中身を見てみよう
 
node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成node-gypを使ったネイティブモジュールの作成
node-gypを使ったネイティブモジュールの作成
 

Recently uploaded

無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
Yuki Miyazaki
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
ssuserfcafd1
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
iPride Co., Ltd.
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
Osaka University
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
kitamisetagayaxxx
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
sugiuralab
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
Shinichi Hirauchi
 
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
osamut
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
Seiya Shimabukuro
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
Takuya Minagawa
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
azuma satoshi
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
ARISE analytics
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
Osaka University
 

Recently uploaded (14)

無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
無形価値を守り育てる社会における「デー タ」の責務について - Atlas, Inc.
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDDなぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
なぜそのDDDは効果が薄いのか?名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風?のDDD
 
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
Microsoft Azureで生成AIを使ってみた話 2024/6/14の勉強会で発表されたものです。
 
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
生成AIの実利用に必要なこと-Practical Requirements for the Deployment of Generative AI
 
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptxiMacwoSu_Gong_de_barabaranishitaHua_.pptx
iMacwoSu_Gong_de_barabaranishitaHua_.pptx
 
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
ヒアラブルへの入力を想定したユーザ定義型ジェスチャ調査と IMUセンサによる耳タッチジェスチャの認識
 
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
気ままなLLMをAgents for Amazon Bedrockでちょっとだけ飼いならす
 
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMMハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
ハイブリッドクラウド研究会_Hyper-VとSystem Center Virtual Machine Manager セッションMM
 
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
20240621_AI事業者ガイドライン_セキュリティパートの紹介_SeiyaShimabukuro
 
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT  vol112 発表資料)
ろくに電子工作もしたことない人間がIoT用ミドルウェアを作った話(IoTLT vol112 発表資料)
 
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobody
 
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
【JSAI2024】LLMエージェントの人間との対話における反芻的返答の親近感向上効果_v1.1.pdf
 
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
協働AIがもたらす業務効率革命 -日本企業が押さえるべきポイント-Collaborative AI Revolutionizing Busines...
 

HTTP/2, QUIC入門