tryangle株式会社
丸末皓太
→ いろんな方法でリクエストやレスポンスのヘッダを圧縮する
HTTP/1.1のヘッダは大きい
HTTP/1.1ではbodyをエンコードするのにgzipでサイズを圧縮する機構がある
膨大なHTTPリクエスト/レスポンスのログのヘッダの文字の出現頻度を集計し、ハフマンツリーを作成
高頻度で使われる文字列とは母音とか
この「ヘッダ圧縮」だけ取り上げて深めてみても面白そうなトピックだなと感じた
ちなみに「hpack」で検索するとhaskellのツールがでてくるが 、コレは関係ない
→ 1回でたくさんリクエストを送っても耐える
Type | フレームの種類 | 役割 |
---|---|---|
0 | DATA | リクエスト/レスポンスのボディ部分に相当 |
1 | HEADERS | リクエスト/レスポンスのヘッダ部分に相当 |
2 | PRIORITY | ストリームの優先順位を指定(クライアントのみ送信可能) |
3 | RST_STREAM | エラーなどの理由でストリームを終了するために用いる |
4 | SETTING | 接続設定を変更する |
5 | PUSH_PROMISE | サーバプッシュを予告します(サーバのみ送信可能) |
6 | PING | 接続の生存状態を調べる |
7 | GOAWAY | エラーなどの理由で接続を終了するために用いる |
8 | WINDOW_UPDATE | ウインドウサイズを変更する |
9 | CONTINUATION | サイズの大きなHEADERS/PUSH_PROMISEフレームの断片 |
→ リソースに優先順位を付けることでUXが向上
先ほど紹介した2番のPRIORITYフレームを用いる
偶数であることからもわかるように、クライアント側で指定する
サーバー側はクライアントから来たこの優先度は別に無視することもできる
例えば、A,B,Cという画像かなにかがあって、これらに対して8,16,32のように重み付けをすると、
1:2:3の割合でリソースが割り当てられることが期待される
→ サーバーが次にくるレスポンスを先読みしてリクエストを返す
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>マジ卍</title>
</head>
<body>
<h1>おはようございます!!!!!!!!</h1>
<img alt="超おもしろい画像" src="omosiro.png">
</body>
</html>
→ 機械語で通信
→ 通信路の渋滞をなくす!