狠狠撸

狠狠撸Share a Scribd company logo
1
HTTP を理解する
2022.8.1 14:00?16:00
技術研究所
山本和彦
2
自己紹介
山本和彦
IIJ 技術研究所
プロトコルを実装して検証し標準化に貢献する
メール、迷惑メール対策、DNS、HTTP/1.1、HTTP/2、TLS 1.3、
QUIC、HTTP/3
IIJエンジニアブログ 「QUICをゆっくり解説」
Internet Infrastructure Review(IIR)Vol.52
「HaskellによるQUICの実装」
ほとんど Haskell でプログラミング
3
おしながき
HTTP/0.9
HTTP/1.0
HTTP/1.1
HTTP/2
HTTP/3
4
バージョン
HTTP/0.9
標準化される前のHTTP
HTTP/1.0
標準化されたHTTP
HTTP/1.1
IPv4アドレスが足らなくなった時代のHTTP
HTTP/2
多重化されたHTTP
HTTP/3
QUICを利用したHTTP
5
URL
http://www.iij.ad.jp/dev/
どう解釈する?
6
URLの解釈
http://www.iij.ad.jp/dev/
www.iij.ad.jp の
TCP 80番ポートにアクセスして
/dev/ を GET
7
ちなみに
URL の // の部分は
失敗だと言われています
8
HTTP/0.9
% gtelnet www.iij.ad.jp 80
GET /dev/↓
ワインライナー
9
gtelnet がおかしくなったら?
Escape character is ’^]’.
Control を押しながら ] を押せ
10
HTTP/1.0
% gtelnet www.iij.ad.jp 80
GET /dev/ HTTP/1.0↓
↓
GET の最後にバージョン
なぜリターンは2回必要なのか?
11
RFC
Request For Comments
インターネットのプロトコルを定める仕様書
仕様書なのに「コメントください」とは?
HTTP/1.0
RFC 1945 (1996)
HTTP/1.1
RFC 2068 (1997)
RFC 2616 (1999)
RFC 7230, 7231, 7232, 7233, 7234, 7235 (2014)
RFC 9112 (2022)
12
RFC 1945
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Full-Request ; HTTP/1.0 messages
Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line
*( General-Header
| Request-Header
| Entity-Header )
CRLF
[ Entity-Body ]
Request-Line = Method SP Request-URI SP
HTTP-Version CRLF
13
空行はヘッダ群の終わり
14
HTTP/1.1
% gtelnet www.iij.ad.jp 80
GET /dev/ HTTP/1.1↓
Host: www.iij.ad.jp↓
Connection: close↓
↓
Host: ヘッダが必須
Connection: close がないとコネクションを継続
15
ヘッダ
ヘッダキー: ヘッダ値
メールのヘッダが参考にされた
要求ヘッダ
クライアントが送るヘッダ
応答ヘッダ
サーバが送るヘッダ
16
要求ヘッダ
Accept-Charset
Host
If-Modified-Since
Referer
Referrer ではない
User-Agent
Connection
例
Host: www.w3.org
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Referer: http://www.example.org/Overview.html
17
HTTP/1.0 と HTTP/1.1 の違い
Host: ヘッダ
HTTP/1.1 で必須
1つのIPv4アドレスで、複数のドメインをホスト
サーバにドメイン名を教える役目
Connection: ヘッダ
HTTP/1.0 のコネクションはデフォルトでは持続しない
Connection: Keep-Alive で持続
HTTP/1.1 のコネクションはデフォルトで持続する
Connection: close で持続しない
18
メソッド
GET
リソースの取得
HEAD
リソースの状態をチェック
POST
リソース自体のセマンティックスに応じた処理
同じ結果にならないことがある
PUT
リソースの更新
何度やっても同じ結果
DELETE
リソースの削除
CONNECT
HTTPS (TLS)でプロキシへ接続
19
メソッドとCRUD
Create
POST
Read
GET
POST -- URLパラメータの2000文字制限にひっかかる場合
Update
PUT
Delete
DELETE
20
HTTP/0.9 の応答
% gtelnet www.iij.ad.jp 80
GET /dev/↓
<html>
<head>Hello</head>
<body>Hello</body>
</html>
クイズ:応答データの大きさはどうやって分かる?
21
HTTP/1.1 の応答
% gtelnet www.iij.ad.jp 80
GET /dev/ HTTP/1.1↓
Host: www.iij.ad.jp↓
↓
HTTP/1.0 301 Moved Permanently
Date: Thu, 29 Jul 2021 05:34:21 GMT
Content-Length: 217
Content-Type: text/html; charset=iso-8859-1
↓
<html><head>
...
<<<コネクションは継続>>>
クイズ:応答データの大きさはどうやって分かる?
22
応答ステータス
1xx -- 情報
100 Continue
2xx -- 成功
200 OK
201 Created
206 Partial Content
3xx -- 向け直し
301 Moved Permanently
4xx -- クライアントエラー
400 Bad Request
404 Not Found
405 Method Not Allowed
5xx -- サーバーエラー
500 Internal Server Error
23
応答ヘッダ
Server
Last-Modified
Content-Length
Content-Encoding
Content-Range
Content-Type
Date
例
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
24
HTTP/1.1 でのストリーミング
応答データの大きさが、あらかじめ分からない
Transfer-Encoding: chunked
7rn
Mozillarn
9rn
Developerrn
7rn
Networkrn
0rn
rn
25
HTTP/2
26
HTTP/1.1 の問題点
27
同期性
HTTP/1.1 は同期的なプロトコル
サーバ: ある要求を処理した後、応答を返す
クライアント:応答が返ってきたら、次の要求を出す
Head-of-line ブロッキング
ある要求への応答に時間がかかると、すべての処理が止まる
28
低い並列性
1つのコネクション上では高々1つの仕事
要求が1つ、応答が1つ、なにもない
要求応答パイプラインイングは事実上使われてない
同時コネクションの数はドメインごとに6つ
29
ドメインシャーディング
ドメインを増やして並列性を上げる
コンテンツが分散し、管理が困難になる
30
非効率なヘッダ
帯域の浪費
要求ヘッダの長さの平均は800バイト
似通った要求ヘッダが毎回送られる
GET /roversync/ HTTP/1.1
Host: rover.ebay.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
rv:16.0) Gecko/20100101 Firefox/16.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://www.ebay.com/
Cookie: ebay=%5Esbf%3D%23%5E; dp1=bpbf/%2380000000000055
276504d^u1p/QEBfX0BAX19AQA**5276504d^; cssg=c67883f113a
0a56964e646c6ffaa1abe; s=CgAD4ACBQlm5NYzY3ODgzZjExM2EwY
TU2OTY0ZTY0NmM2ZmZhYTFhYmUBSgAYUJZuTTUwOTUxY2NkLjAuMS4z
LjE1MS4zLjAuMeN+7JE*; nonsession=CgAFMABhSdlBNNTA5NTFjY
2QuMC4xLjEuMTQ5LjMuMC4xAMoAIFn7Hk1jNjc4ODNmMTEzYTBhNTY5
NjRlNjQ2YzZmZmFhMWFjMQDLAAFQlSPVMX8u5Z8*
31
HTTP/2
2012年9月からIETFで標準化がスタート
4つの提案の中からGoogleのSPDYがベースに選ばれた
3年間の議論
2015年5月にRFCになった
RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)
RFC 7541: HPACK: Header Compression for HTTP/2
2022年に改訂
RFC 9113: HTTP/2
特徴
HTTP ヘッダなどの意味は変わらない
トランスポートのみが変更され効率的になった
32
HTTP/2による解決
33
フレームの非同期性と高い並列性
高い並列性
利用されるコネクションは1つ
複数のフレームが多重化される
非同期性
準備ができた応答から返してよい
34
HTTP/3
35
HTTP/2 の問題点
36
TCP の HoL ブロッキング
37
HTTP/3 による解決
38
QUIC
2016年6月からIETF で標準化がスタート
Google の QUIC がベース
5年間の議論
2021年5月にRFCになった
RFC 8999: Version-Independent Properties of QUIC
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
RFC 9001: Using TLS to Secure QUIC
RFC 9002: QUIC Loss Detection and Congestion Control
HTTP/3
RFC 9114: HTTP/3
RFC 9204: QPACK: Field Compression for HTTP/3
39
QUICのプロトコル階層
40
QUIC や QPACK がどのように
HoLを解決したかは
「QUICをゆっくり解説」
を読んでください。
41
最近のRFC構成
RFC9110: HTTP Semantics
HTTPのバージョンに依存しないヘッダなどの意味
RFC9111: HTTP Caching
RFC9112: HTTP/1.1
ヘッダはテキストそのまま
本文は、コンテンツそのままか、チャンクなど
RFC9113: HTTP/2
ヘッダは HPACK を使ったバイナリ
本文はフレームで分割
RFC9114: HTTP/3
ヘッダは QPACK を使ったバイナリ
本文はQUICのフレームで分割

More Related Content

贬罢罢笔を理解する