Httpを振り返ってみる

わんくま同盟東京勉強会 #103
HTTPを振り返ってみる
がる

自己紹介
• 古庄(道明)と申します
• Webでは「がる」というハンドルでふらついて
おります
• 本職は技術者です。現役プログラマーです
• あわせて設計とかインフラとか教育とか色々
やってます
• おいちゃんです

本講の目的
• 昔を懐かしむ事です(マテ
• 基本的に「年寄りの昔話」的なお話をじっくりと
できれば、と思ってます(笑

HTTPって、なに？
• Hypertext Transfer Protocol
– ハイパーテキスト・トランスファー・プロトコル
– 「ハイパーテキスト」をトランスファーするプロトコル
• Hypertextとは？
– 複数の文書（テキスト）を相互に関連付け、結び付
ける仕組み
• ものすごく要約すると「Aタグによるリンク」(笑
– wikipediaなんかは、非常に「ハイパーテキスト」な
一例かと思います

ちょっとだけ前提
• HTTPは基本的に「サーバとクライアント」で出
来ています
– クライアントは「これ頂戴」を依頼する人(達)
– サーバは「頂戴って依頼」を処理する人(達)
• 一般的には「これ頂戴」がリクエスト(request)、
返信をレスポンス(response)と言います
– おいちゃんは「ちょうだい(リクエスト)」「あいよ(レス
ポンス)」ってよく言います(笑

HTTP0.9登場
• そんな「ハイパーテキスト」をやり取りするプロ
トコルとして、HTTP0.9が登場！！
– 1991年にドキュメント化されました
• そんなHTTP0.9の「ちょうだい」「あいよ」を見
てみましょう

アクセスログ(一例)
telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
GET /index.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
以下略

• ちょうだい(リクエスト)
– GET /index.html
• あいよ(レスポンス)
– <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 3.2 Final//EN">
<HTML>
<HEAD>
以下略

かみ砕いて
• リクエストは「このコンテンツ頂戴」一行
– 先頭のGETは固定
• レスポンスは「頂戴」って依頼されたファイル
の中身そのもの
– 想定は「HTMLファイルのみ」
• ………画像は？
– 答：そんなものはない！！ｗ
或いは文脈で適宜判断(笑

HTTP 0.9要約
• 身もふたもないシンプルプロトコル
• でもこれが「HTTPのもっとも基本(原始的)な
姿」であります
– 「ハイパーテキスト」の最低限は、これで実際に実
現可能なんですよねぇ

HTTP1.0爆誕
• 1996年5月、HTTP1.0爆誕生
• いきなり山盛りに仕様が増えました！！

前提としての「HEADとBODY」という概念
• 主としてレスポンス(実際にはリクエストにもあ
る)に、「HEADとBODY」という概念が登場し
ました
• おおざっぱにはこんな感じです
– HEAD：コンテンツに付帯する情報
– BODY：コンテンツ本体

telnet localhost 80
Trying 127.0.0.1...
GET /index.html HTTP/1.0
User-Agent: telnet
Accept-Language: ja
HTTP/1.1 200 OK
Date: Sun, 27 Nov 2016 00:39:49 GMT
Server: (略)
Last-Modified: Sat, 09 May 2015 13:41:52 GMT
ETag: "12a0070-fd5-515a64ea8e800"
Accept-Ranges: bytes
Content-Length: 4053
Connection: close
Content-Type: text/html
<HTML>
<HEAD>
以下略

• ちょうだい
– GET /index.html HTTP/1.0
User-Agent: telnet
Accept-Language: ja

• あいよ(HEAD)
– HTTP/1.1 200 OK
Date: Sun, 27 Nov 2016 00:39:49 GMT
Server: (略)
Last-Modified: Sat, 09 May 2015 13:41:52
GMT
ETag: "12a0070-fd5-515a64ea8e800"
Connection: close

• あいよ(BODY)
– <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 3.2 Final//EN">
<HTML>
<HEAD>

• リクエストは「複数行」を指定可能です
– 一行目は「GET コンテンツ名 HTTP/1.0」
– 二行目以降に「色々なリクエスト」を追記
– リクエストの終了は「CRLF(改行) CRLF (改行) 」
• レスポンスは「HEADとBODY」に分かれます
– 分かれ目は「CRLF(改行) CRLF (改行) 」
• 改めて、アクセスログを見てみましょう

telnet localhost 80
Trying 127.0.0.1...
User-Agent: telnet
Accept-Language: ja
HTTP/1.1 200 OK
Date: Sun, 27 Nov 2016 00:39:49 GMT
Server: (略)
ETag: "12a0070-fd5-515a64ea8e800"
Connection: close
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=shift_jis">

• HTTP1.0で、いきなり色々な情報の応酬が可
能になりました
• いくつかをかみ砕いて、残りを駆け足で、見て
いきましょう

「GET /index.html HTTP/1.0」
• 「GET /index.html HTTP/1.0」
• １番目のGETは「メソッド(Method)」と呼称
– どんなデータをどんな風に欲しかったりupした
かったりするか、で変化します
• ２番目の「コンテンツ」はお好きなものを
• ３番目のバージョン表記は(当然)固定

メソッド(Method)
• GET
– もっとも基本。「すべてのHTTP1.0に従うサーバー
でサポートされなくてはならない」。
– URIで指定されたオブジェクトを取得する、という
意味を持つ
• HEAD
– これも基本で「すべてのHTTP1.0に従うサーバー
でサポートされなくてはならない」。
– サーバーがレスポンスにオブジェクトボディーを返
してはならないことを除けば、GETと同じ。

• POST
– 様々なデータの送信を行う(メッセージの投稿、ス
クリプトにデータを送信、等)
• PUT
– オブジェクトが蓄積されることを要求(POSTとの違
いは後程)
• あとは「DELETE」「LINK」「UNLINK」がある
– 詳細は省略(笑

• まぁもっともよく使われるのはGET、ついで
POSTの使用頻度が高い
• 理由の一つに「HTTPではいくつものメソッドが
規定されているが、HTML(のform)ではGET
とPOSTしか規定されていない」とかいう身も
ふたもない理由があります B-p
– 詳細な理由はわりと謎。
ググると面白い議論とか経緯とか出てきます(笑

メソッド(Method)についてもうチョイ
• 大まかに、以下のような使い分けが多い
• GET
– 本質的に「冪等」であるべきであり、かつ副作用が
ない：read系コンテンツを想定
– システム制限的に、リクエストメソッドに「長さ制
限」がかかる事がちょいちょいある
• POST
– 本質的に「冪等でない」：write系コンテンツを想定
– システム的なリクエスト長制限が(ほぼ)ない

２行目以降のリクエストメソッド
• 前提としてのフォーマット
– "ヘッダ名" ":" "ヘッダ値" [CRLF]
• ヘッダ名(＆ヘッダ値)は「あらかじめ決まって
いるもの」以外は「受け取るけど挙動の保障
はしない」

２行目以降のリクエストメソッド：General-Header
• General-Header
– 「ちょうだい」と「あいよ」両方で使用できるヘッダ
• Date
– 「ちょうだい」とか「あいよ」をした日付
• Date: Tue, 15 Nov 1994 08:12:31 GMT
• Connection
– 実験的ヘッダ。HTTP1.1でがっつり本筋に。
• その他：「Forwarded」「Mandatory」
「Message-ID」「MIME-Version」

２行目以降のリクエストメソッド：Request-Header
• Request-Header
– リクエスト用のヘッダ
• User-Agent
– 「どんなブラウザで見てるの？」情報
• ガラケーの時は「色々な情報」があって…
• Authorization
– 認証(と言い張れない程度に脆いなにか)用
– 詳細は後程

• Pragma
– 関わってくる「proxyサーバ」等への指示
– HTTP1.0時点では「no-cache」のみ定義
• Pragma: no-cache
• 意味は「キャッシュすんなコノヤロウ」
• If-Modified-Since
– 「更新があった？」を確認するヘッダ
• If-Modified-Since: Tue, 15 Nov 1994 08:12:31 GMT
• 上述日付以降に更新があったらコンテンツを「あいよ」
• 上述日付以降にコンテンツ更新がなかったら304 Not
Modified を返し、コンテンツを返さない(ことで節約)

• Referer
– 「どこからそのページに要求が来たのかを知るこ
とができる」ヘッダ
– 色々と間違えるとセキュリティホールを生みます
• Accept、 Accept-Encoding、 Accept-
Language
– 許容可能な「メディアフォーマット(MIME type)」
「圧縮タイプ」「自然言語(日本語とか英語とか)」を
指定できる
• 残り：「Proxy-Authorization」「From」

レスポンス header（Response-Header)
• Response-Header
• Status-Line
– レスポンスの１行目
– 「リクエストが成功したか失敗したか」のお返事
• 1xx: 未定義（将来の使用のために予約）
• 2xx: 成功 - リクエストされたアクションを適切に受理、理解
• 3xx: リダイレクション（Redirection） - リクエストを完了する
ために別の追加アクションがなされる必要がある。
• 4xx: クライアントエラー - リクエストに間違った構文があるか、
または実行がもともと不可能である。
• 5xx: サーバーエラー - サーバーはリクエストを遂行できな
かった。

• Server
– 「あいよ」で応答してくれたサーバの情報各種
– 「バージョンを隠す」事も多いかなぁ…
• WWW-Authenticate
– 認証(とも呼べない程度の脆いなにか)用
– 詳しくは後述
• あとは「Proxy-Authenticate」「Retry-After」

レスポンス header（Object-Header)
• Content-Length
– コンテンツの長さ(サイズ)
• Content-Type
– コンテンツの種別(media-type)
• 「HTML」とか「画像(jpeg)」とか
• Content-Encoding
– 圧縮されてたりすると付いてくる
• Content-Language
– 「日本語」とか「英語」とか

• Expires
– 「このコンテンツの有効期限」
– 動的なHTMLはできるだけ短くするほうがいい
• Last-Modified
– このコンテンツの「最終更新時間」のご連絡
• Location
– 「このコンテンツはお引越ししましたよ」のご連絡
• 残り：「Allow」「Content-Transfer-Encoding」
「Version」等

まとめて
• HTTP0.9から1.0で、いきなり「リニューアル大
オープン」くらいの勢いで色々と変更！！
• いわゆる「WWW」のベースが、大体規約化さ
れました

HTTP1.0のうち「基本アクセス認証法(Basic Access
Authentication Scheme)」
• 先に書いておきます「おもちゃです雑な作りの
南京錠です」
• 流れは以下の通り
– とあるコンテンツを「ちょうだい」
– 「401 Unauthorized」で「あいよ」
(意味は「認証情報よこせ」)
– Authorizationヘッダつけて再度「ちょうだい」
– (Authorizationヘッダの内容が正しければ)
「200 OK」で「あいよ」

• Authorizationヘッダの分解
– Authorization: Basic BASE64文字列
• BASE64文字列の作られ方
– base64( "id" ":" "password" )
– 「ユーザ名とパスワードをコロン（:）で連結したもの
を BASE64 形式にエンコードしたもの」
• この文字列を「通信毎に、都度」送信してます
• おもちゃです。

Cookieのお話
• Cookieは「個体識別(認証用とか)に必要だよ
ねぇ」ってんで作成されました
• …が、実はHTTP1.0では「規定されてません」
– 元々は「ネットスケープコミュニケーションズ社」が
1994年に提案、実装
– RFCで標準化されたのは1997年(RFC 2109)
– 2000年(RFC2965)、2011年(RFC6265)で更新
– RFC6265では「事実上追加されてた」 httponly属
性やsecure属性等が明記された

Cookieって、なに？
• HTTPは本来的には「ステートレス(状態を持
たない)プロトコル」
• なので「誰が」アクセスしてきたか、とか、不知
• でも「個体識別したい」ってニーズが出てきた
– 「 ○ ○さんこんにちは」
– 「このサイトにｎ回来てくださいましたね」
– ECの買い物籠
– ログイン認証
• 「じゃぁなんか仕組み作るべ」でCookie爆誕

• 大まかにはこんな仕様
– 「あいよ(レスポンス)」で、状態を区別する識別子
をHTTPレスポンスヘッダに含めて返す
– 「ちょうだい」の時に、同じサーバからもらった識別
子をHTTPリクエストヘッダに含めて「ちょうだい」
する

• 少し噛み砕くとこんな仕様
– 「あいよ(レスポンス)」の時
• 識別子は「name=value」の形で渡す
• 識別子の有効期限を渡す
• 「このサーバで有効にして」を渡す(デフォは自ドメイン)
• 「このディレクトリで有効にして」を渡す(デフォはカレント)
– 「ちょうだい(リクエスト)」の時
• 「サーバ、ディレクトリ」が一致した識別子を渡す
• ただし、有効期限が古かったら渡さない

ちょっと面倒なバージョン問題
• ExpiresかMax-Ageか
– どちらも「Cookieの寿命」にまつわるヘッダ
• Expires=Tue, 15 Nov 1994 08:12:31 GMT
• Max-Age=600
– Expiresは「有効期限(日付)」、Max-Ageは「受け
取ってからの有効秒数」を指示
– ネットスケープ仕様はExpiresのみ、のちのRFCで
はMax-Ageが追加された…けど、 Max-Age使わ
れてない…

• set-cookie2
– RFC2965で提案された「新しい」Cookieの設定の
仕方
• 「set-cookie」ヘッダからの置き換え
– 今一つヒットせず広がらず…
– RFC6265で、(無事)廃止
• 「提案があっても、受け入れられにくいものは
見事にすたれるよねぇ」事案でございます

httponly属性とsecure属性
• 前提として…
– サーバでやり取りしてるCookieを、JavaScriptが
(不正に)覗き見するの困る！！
– httpsでやり取りしてるCookieがhttpで見れると、
セキュリティ上困る！！
• 「とりあえず作っちゃえ」で、なんとなくhttponly
属性とsecure属性が追加
• 「なんとなく」だと面倒なんで、RFC6265で正
式に文章化

• 「提案があって受け入れられやすいっていうか
必要なものは、とっとと実装するよねぇ」事案
でございます

で、結局Cookieって？
• 「個人毎の、state(状態)を管理する」もの
• データは「クライアント側」に保存される
– から、改ざんも割と容易なので注意
• ある程度、長さ制限とか個数制限があるよ！
– １ドメインあたりのCookieの値の数
• １ドメインで50個のクッキー(RFC6265)
– 最大長(byte)
• クッキーの変数名も含めたすべての文字列長を4096
バイトに収める(RFC6265)

SSLについて
• SSL → Secure Sockets Layer
– 現在はTLS(Transport Layer Security)
• でもまぁ慣習的に「SSL」って言っちゃいますねぇ
• 端的には「安全なhttp通信」のための決まり
– httpって安全じゃないの？
• そもそも「インターネット通信」が安全じゃない
• パケット覗けるし
• パケット改ざんできるし
• 「通信相手を偽る(騙る)」事もできるし

SSLの大まかな歴史
• SSL 1.0をネットスケープ社が設計…していた
が「そもそも大きな脆弱性あるよねぇ」でボツ
• 1.0の問題を修正して再設計、2.0が出てきた
…けど「ダウングレード攻撃(選択可能アルゴ
リズム中、最弱のを使わせる事が出来る)」が
露見
• 2.0の問題をフィックスして3.0が爆誕…も、
POODLE攻撃という手法で「暗号解読が可
能」な事が発覚

• 問題が色々あった(実際、2.0は2011/3に
RFC6176で、3.0は2015/6にRFC7568で、そ
れぞれ"使用禁止"扱い)ので……
• 1999年、TLSと名前を変えて1.0を発表
• 1.0から更に暗号強度を高めたり、新しく発見
された攻撃手法に対応した1.1が2006年発表
• ハッシュ方式やブロック暗号方式を追加した
1.2が2008年に発表
• 現在、1.3を絶賛提案中

SSLの大まかな仕組み
• ものすごくおおざっぱには
– 「お互いが使用可能な暗号方式の一覧」を、サー
バ側とクライアント側でお互いに提示
– お話合いの末に「じゃぁ今回はこの暗号方式でい
きましょう」を決定
– 加えて(共通鍵方式の暗号が使われるので)「今回
用の暗号鍵」を交換
– 以降、通信の全部を「共通鍵暗号方式で暗号化し
て」通信

前提としての、簡単な暗号知識
• ハッシュ
– 任意長の文字列を「決まった長さのミンチ肉」にす
る手法
– ファイル指紋とか呼称される事もある
– 正真性(完全性)の確認に使われる
• 対称暗号(共通鍵暗号)
– 同じ鍵で「暗号化」「復号」を行う
– 大体「ブロック暗号」なので、ブロック長(8 byteと
か)の長さで暗号化する

• パディング方式
– ブロック暗号で「8byteで割り切れない」文字列を
扱う時に、後ろに「詰め物」を入れる方式
• PKCS#5 Padding、を割とよく見かけます
• 暗号利用モード
– ブロック長よりも長いメッセージを暗号化するとき
の決まりごと
– ECBは、「もっとも単純」で「使っちゃいけない」
モード
– CBCがよく使われている

• 公開鍵暗号
– 「公開鍵」と「秘密鍵」を使う暗号
• 「公開鍵」で暗号化し、「秘密鍵」で復号する
– 「公開鍵」と「秘密鍵」は、数学的に「関連性のあ
る」値が設定される
– RSA(公開鍵暗号の１方式)の場合…
• 公開鍵：数Eと数N
• 秘密鍵：数Dと数N
• 暗号文＝平文^E mod N
• 平文＝暗号文^D mod N

(ややこしいんで流していきましょうｗ)
• 数E、D、Nの求め方
– 大きな素数q、大きな素数pを作る
– N ＝ p * q
– Lを求める。Lは「(p - 1)と(q - 1)の最小公倍数」
– Eを求める。Eは「１以上L未満、かつ、EとLの最大
公約数が１になる」ような値
– Dを求める。以下の数式に合致する値を見つける
１＜ D ＜ L
E ＊ D mod L = 1

• デジタル署名
– 端的には「なりすまし防止」のための技術
– 例えば「サーバの成りすまし」をチェックする場合
• サーバは、メッセージを「自分の秘密鍵」で暗号化
• クライアントは
– 対称サーバの「公開鍵」を入手：公開鍵なんで、公開されてる
– サーバからの「暗号化」メッセージを「公開鍵で復号」
– 復号できたら「成りすましてないだろう」
• これは「秘密鍵は漏れてない」「公開鍵暗号形式的に、
公開鍵から秘密鍵は(ほぼ)作れない」「ペアの鍵じゃな
いと、復号できない」性質を利用

「通信の全部を「暗号化して」通信」までの前提
• 第一フェーズ：ご挨拶と手持ち暗号の開示
– ClientHello、ServerHello
• 第二フェーズ：サーバ/クライアント証明書の開
示(と確認)
– Certificate、 ServerKeyExchange、
CertifiateRequest、 ServerHelloDone

• 第三フェーズ：クライアントからサーバに対して、
鍵共有に必要な情報の共有
– Certificate、 ClientKeyExchange、
CertificateVerify
• 第四フェーズ：暗号方式切り替えの確認
– Change Cipher Spec、Finished、Change
Cipher Spec、Finished

通信の「クライアント(左)」と「サーバ(右)」の区分け
• ClientHello
• ServerHello
• Certificate
• ServerKeyExchange
• CertifiateRequest
• ServerHelloDone
• Certificate
• ClientKeyExchange
• CertificateVerify
• Change Cipher Spec
• Finished
• Change Cipher Spec
• Finished

第一フェーズ：ご挨拶と手持ち暗号の開示
• クライアントは以下をサーバに伝える(ClientHello)
– TLSのバージョンのリスト、現在時刻、クライアント
乱数、セッションID、通信に用いる暗号方式のリス
ト、ハッシュアルゴリズムのリスト、通信内容の圧
縮方法のリスト
• サーバは「もっとも好ましい」ものを選択して
「使うことが決定した」以下を伝える(ServerHello)
– 使うTLSのバージョン、現在時刻、サーバ乱数、
セッションID、通信に用いる暗号方式、ハッシュア
ルゴリズム、通信内容の圧縮方法

第二フェーズ：サーバ証明書の開示(と確認)
• サーバはクライアントに対して「自身の証明
書」を、自身の秘密鍵で「公開鍵暗号による暗
号化」を行ってから送る(Certificate)
– 通常、このタイミングで「証明書の精査」をする
• 接続ドメインの「公開鍵」を、認証局と呼ばれるところか
ら取り寄せる
• 送られてきた暗号文を、入手した公開鍵で復号する
• 中身をチェック
– 有効期限
– ドメイン名
等

• 暗号方式によっては「追加情報が欲しい」ケー
スがあるので送る(ServerKeyExchange)
– 例えば、RSA、DH_DSSの時は不要
• (クライアント証明書が必要な設定の場合)
サーバからクライアントに「クライアント証明書
を送ってください」の旨を送る(CertifiateRequest)
• 「サーバ側からの通信が一段落した」旨を送る
(ServerHelloDone)

第三フェーズ：クライアント証明書の開示(と確認)
• (「クライアント証明書を送ってください」の依頼
があった場合)クライアント証明書を送る
(Certificate)
• クライアント側から、後で「共通鍵暗号方式で
暗号化して通信」するために必要な鍵を作る
ための情報(プレマスターシークレット)を送る
(ClientKeyExchange)
– 使用する暗号方式によっても異なるが、基本的に
は「クライアント側で作った乱数」を「サーバの公開
鍵で暗号化」して送る

• (「クライアント証明書を送ってください」の依頼
があった場合)自身の証明のために
「 ClientHello メッセージから現在までの、この
メッセージを除く、送信または受信したすべて
のハンドシェイクメッセージ」を自身の秘密鍵
で暗号化したものを送る(CertificateVerify)

第四フェーズ：暗号方式切り替えの確認
• 以降の暗号方式を「さっき(第一フェーズで)ネ
ゴった方式と、さっき(第三フェーズで)ネゴった
鍵」に変更します宣言(ChangeCipherSpec)
• この通信を終わります(Finished)
• 暗号方式の変更了解(ChangeCipherSpec)
• この通信を終わります(Finished)

一言でSSLを片づけると
• 安全性を担保するために「大量の暗号技術系
の集合体のような」方式
• ただ、各暗号方式には「弱いのも強いのもあ
る」ので、「弱いのを組み合わせれば」弱くなる
• あと、ぶっちゃけ「処理が重い」
– ので、昔は「SSLアクセラレータ」なんてハードウェ
アもありました
– 今は、ロードバランサにやってもらう事も多いか
なぁ…特にAWSとかだと

参考：opensslで対応の一覧を見る
• openssl ciphers -v
– 暗号スイートの名前、プロトコルのバージョン、鍵
交換に使われる暗号化アルゴリズム(Kx)、認証に
使われる暗号化アルゴリズム(Au)、アプリケー
ション層の暗号化に使われる暗号化アルゴリズム
(En)、メッセージの検証に使われるハッシュアル
ゴリズム(Mac)
• 例：TSL1.2、鍵交換DH(ディフィー・ヘルマン)、認証
RSA、アプリAES、検証SHA-256
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1

で、HTTP1.1
• HTTP1.0で機能が豊富に増えてCookieで個
体認証が出来てSSLでセキュリティが確保さ
れた…のですが、まだまだ困りごとがありまし
て
• その結果として、1997年1月に、HTTP1.1が
発表されました(RFC 2068)
– そのあと、 1999年6月に改修(RFC 2616)
– 2014年6月に改修(RFC 7230～RFC 7237)

HTTP1.1の大まかな改修ポイント
• Host リクエストヘッダ
– 完全な新規さんです
– いわゆる「IPアドレス枯渇問題」と関連があります
• Connection リクエストヘッダ（Keep-Alive接続)
– チューニングで色々困るんで明示的に出てきまし
た！！
– HTTP1.0で「Connection」って名前の実験的な
ヘッダが、実用化されました！！

Host リクエストヘッダ
• 今までは基本的に「１サーバ＝１IP ＝１ドメ
イン」でした
– 「１サーバ＝ｎIP」「１IP ＝１ドメイン」は普通にあり
ましたし、(IPベースの)VirtualHost設定で問題なく
捌けてました
• でも「IPアドレス枯渇問題」もあり、ちっちゃな
サーバや共有サーバもあり「１サーバ＝１IP
＝ｎドメイン」へのニーズが高まりました
– 「ドメイン毎にIPとか渡してられっかい！！」

• 今までのVirtualHostの設定は「このIPアドレ
スへの接続ならこの設定」という設定でしたが
…「１IP ｎドメイン」だと、うまくいきません
• そこで「HTTPリクエストヘッダ」の中に「アクセ
スしたいドメイン名を入れる」事で「このドメイン
への接続ならこの設定」という設定が書けるよ
うにしました
• それが「Host リクエストヘッダ」です

telnet localhost 80
Trying 127.0.0.1...
Host: www.m-fr.net
User-Agent: telnet
Accept-Language: ja
Connection: close
HTTP/1.1 200 OK
Date: Sun, 27 Nov 2016 07:30:39 GMT
Server: (略)
ETag: "12a0070-fd5-515a64ea8e800"
Connection: close
<HTML>
以下略

telnet localhost 80
Trying 127.0.0.1...
Host: www.grid-works-guild.net
User-Agent: telnet
Accept-Language: ja
Connection: close
HTTP/1.1 200 OK
Date: Sun, 27 Nov 2016 07:31:59 GMT
Server: (略)
Last-Modified: Thu, 16 Jul 2015 23:14:52 GMT
ETag: "12f8674-33a-51b063d139300"
Content-Length: 826
Connection: close
<html>
<head>
<title>Grid Works Guild 格子組 Web Page</title>
以下略

• 同じサーバへのアクセスですが、HTTPリクエ
ストヘッダの「Host」の値が違うので「設定が
違う(＝DocumentRootの場所が違う)」ので、
同じindex.htmlを取得しても「別のコンテンツ
が出てくる」感じです。

Connection: Keep-Aliveについて
• Connection: Keep-Aliveは端的には「しばらく
接続きらないでおいて」というリクエストなので
すが…
• それを理解するためには、HTTPの「ぶつ切り
紙芝居」のお話と「チューニングのお話」が必
要になってきますので、少々、ぐるりと回り道
をいたします

大本のHTTPと「最近のWebPage」
• HTTPアクセス。ちょっと細かく書くと
– TCPの3way ハンドシェイク
• 接続開始するよ？(SYN)
• OK。こっちからも接続していい？(SYN・ACK)
• OK(ACK)
– HTTP
• ちょうだい
• あいよ
– TCP切断
• 切断するよ？(FIN)、OKこっちも切断(FIN・ACK)、切断(ACK)

• 最近のWebPageは…
– HTML本体を「ちょうだい/あいよ」
– HTMLの中をレンダリング…
• CSSファイルを(複数)「ちょうだい/あいよ」
• JavaScriptファイルを(複数)「ちょうだい/あいよ」
• 画像ファイルを大量に「ちょうだい/あいよ」
– 1Pageに何個アイコン？それぞれ１アクセスですよ？
• 下手すると1Pageで100リクエスト近く…
– 50リクエストは、ぶっちゃけ「ざら」です

• 100リクエスト、毎回「TCPの3wayハンドシェイ
ク」やりたい？？？重くない？？？
• そこで「Connection: Keep-Alive」！！
• Keep-Aliveすると「１回のTCP接続で、何回も
リクエストを投げられる」！！
– 一定時間でコネクトを切られる。Apacheの場合は
「KeepAliveTimeout」で設定、デフォは15秒
• なので「TCPのハンドシェイク」がお得！
– リクエストの最後は「 Connection: Close」を!!

ついでにチューニング回りのお話
• ちなみに「1Pageで100リクエストあるなら、同
時に100リクエスト投げればいいぢゃない」と
か思いがちですが
• 鯖屋さんからしたら「ただのDoS攻撃」です
• 「１Pageの同時リクエスト」は紳士協定が存在
– HTTP1.1では「同時接続は２つまで」！！
– 多くのブラウザは６程度
– 「増やすと便利」記事書くと、鯖屋さんがマサカリを
全力で投げてきますｗ

• HTTPパイプラインというのがありまして…
– 「１つのTCP上で複数のHTTPリクエストを重ねて
流せる(１リクエストのレスポンスを待たずに、次の
リクエストを流せる)
• 便利！ …かと思いきや…
– レスポンスは「リクエストの順番」でしか返せない
仕様なので、あんまり効果がない…
• 結果「あんまり流行ってない」

HTTP1.1用チューニング各種
• CSSやJavaScriptは…
– １ファイルにまとめる
– コメントとか改行とか出来るだけ削ってコンパクト
にする
– gzip圧縮して送る
• 画像を１枚にまとめる(CSSスプライト)
– 複数の画像を「１枚の画像」にまとめる
– CSSで、表示領域(width, height)とbackground-
position(表示位置の調整)で画像を出す

• 画像をdateとして埋め込む(data URLスキーム)
– HTMLのIMGエレメントで、こんな書き方をします
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUh...
– ブラウザによっては長さ制限があるので、あんま
り長いのは控えた方が安全
• CSSでアイコン作る
– 頑張ると、CSS「だけで」アイコンが作れたりします
– シンプルなアイコンセットのCSSは、割とネットで
拾えたりしますんで適宜

• ドメインシャーディング
– 「同時接続の制限数」は１ドメインあたりなので
– 「画像は別ドメイン」なら、「１ドメインあたり６接続」
でも「２ドメインで12接続」いけるので、早い！ｗ
• 画像(JSやCSSも時々)の寿命を延ばす
– HTTP1.1であれば「Cache-Control」ヘッダでコン
トロールできるので、Apacheの設定などで「画像
には一定時間のキャッシュをする」ようなヘッダを
追記させる

• Webフォント
– 「どうしてもこのフォントで表示したい」って場合、
いちいちフォントを個別にダウンロードさせるより
は「Webフォント」を使った方が軽い(らしい)
• 実感も体感もないので、不明な領域です(笑

チューニングまとめ
• 昨今のリッチなコンテンツは、結構色々な事
やって、頑張ってチューニングしてます
– いやうちのPageみたく「１Page １リクエストで済む
(画像もCSSもJSもなし)」なら困らないのですがｗ

メソッド(Method)のお話その２
• HTTP1.1で、メソッドが幾分「増えたり減った
り」しました
わりと重要な側面があるので見ていきましょう
• 1.0と1.1のどっちにもあるメソッド
– GET
– HEAD
– POST
– PUT
– DELETE

• HTTP1.0にあって、1.1で廃止になった子
– LINK
– UNLINK
• HTTP1.1で新設された子
– CONNECT
– OPTIONS
– TRACE

• GETとHEAD
– GETは「指定されたコンテンツを(中身(BODY)ま
で全部)レスポンスする」のに対して、HEADは「指
定されたコンテンツの、中身(BODY)は返さずに
HEADだけ返す」メソッド
• POSTとPUTの違い
– PUTは冪等性があるので「同じリクエストを何回
送っても結果は同じ」である、とされる
– POSTは冪等性がないので「同じリクエストを複数
回送ると二重投稿とかになる」とされる

• DELETEは、まぁ「削除」的な意味合い
– 「指定されたコンテンツを削除する」とか言われる
• OPTIONSは「サーバがサポートしている
optionを調べる」のに使う
• CONNECTは「プロキシをすり抜けるトンネル
を確立することを求める」のに使う
• TRACEは「サーバが受け取ったHTTPリクエ
ストをそのまま返す」。
– …用途が見えない(苦笑

HTMLにおける現状
• 相変わらず「GETとPOST」のみｗ
• とりあえず「そんなに困らない」んじゃないか
なぁ、的雑感が、割とあちこちで
• なお「GETで"冪等性のない更新"」も可能です
が、お作法的にあんまりやらないほうがよいで
す
• ログインformでGETとかやると、死ねますｗ
– 例：URIにIDとパスワードが出てくる＋Referer

JavaScriptとかPHPとか
• 「HTMLではサポートしていない」例えばPUT
メソッドとかDELETEメソッドですが
• JavaScriptからの通信だと、指定が可能だっ
たりします
– 例えばjQueryのajaxメソッドですと「type」でメソッ
ドを指定可能で、ここにDELETEとか仕込めます

• PHPにLaravelというフレームワークがあるの
ですが
• ここのルーティングで「リクエストメソッドが
PUTの時」や「リクエストメソッドがDELTEの
時」といった記述が可能になっています
• CakePHP3、Symfony3などでも可能なようで
す

メソッド(Method)のお話その２まとめ
• 一番プリミティブには「GETとPOST」が、確実
にサポートされている範囲です
• ただ、最近「それ以外のメソッド」に対する(ちゃ
んと使おうという)動きが出てきています
• 「本来のHTTPだと」色々と決められているメ
ソッドなので、ゆるやかに「HTTPに沿うよう
に」変化していく………の、かも、しれません

Server Name Indication（SNI）
• Host(HTTP 1.1)とSSLの複合技のお話です
• ドメインベースのVirtualHostでは「HTTPリク
エストの、Hostヘッダの中身」みて、設定の振
り分けをします
• SSLは「(HTTPリクエストを含む)通信全体を
暗号化」します。復号には「通信対象のドメイ
ン名」が必要です
• ………あれ？

• SSLの通信を復号するためには、ドメイン名が
必要です
• ドメイン名はHTTPリクエストの中に書いてあり
ます
• HTTPリクエストを見るためには、SSL通信を
復号する必要があります
• SSL通信を復号するためには、ドメイン名が必
要です
• 以下loop

• 対策その１：port番号を変える
– URI'sにはport番号が指定できるので変えればで
きますが…あんまりURIの見た目がよろしくない
– 今更ではありますが。ガラケー(特にAU)は「デフォ
ルトポート以外はアクセス不許可」とか言われた
ので色々とアウト
• 対策その２：IPアドレスを別々にする
– だから「IPアドレス枯渇してる」って言ってるだべ
さ！！

じゃぁどうする？
• そこで「Server Name Indication（SNI）」！！
– TLS拡張(RFC4366)の一つ
– SSLハンドシェイクのタイミングで「ホスト名を伝え
てくれる」ので、SSL暗号化の通信をひも解く前に
「ホスト名」がわかる！！
• 注意点
– ブラウザによっては非対応
• でもまぁ最近のならまずもって平気
– 先日、うちの子が「アプリのブラウザがSNI非対応
だたorz」と泣いていたので、その辺は注意ｗ

SPDY
• ラスト２つｗ
• SPDY
– Googleが提唱しているHTTP互換のプロトコル
– SSL必須
– HTTP(S)を高速化するためのあれやこれや
– HTTP 2.0のたたき台になった
• HTTP 2.0で言及できるので、この程度でｗ
– SPDYは3.1が最後のバージョンとなり、SPDY/4
は HTTP/2 に吸収された

HTTP2.0
• 2015年5月にRFC7540が出ました！！
– HTTP1.1の初手(1997年1月)から考えると、実に
18年ぶりにバージョンアップ！！
• 基本的には「HTTPのパフォーマンスの向上」

• バイナリフレーム
– UNIX文化を背負ってず～っと「テキストによる通
信」だったのですが、「バイナリのほうが効率よい
よねぇ」ってことで、ヘッダがバイナリになりました
– バイナリフォーマットなので、通信帯域も送受信後
のパース処理も、楽になってます
• 差分ヘッダ
– 「同じデータは送らない」事で無駄を省きます！
– 圧縮もしてますが、gzip圧縮だとCRIMEという攻
撃手法が見つかってるので、方式を変えてます

• ストリームによる多重化
– 「HTTPパイプライン」に似てますが、ストリームに
よる多重化は「非同期に送受信ができる」ほかに
「ストリームの優先度が設定できる」ので、実用的
になりました！！
• サーバープッシュ
– あらかじめサーバ側が把握している場合に限られ
るのですが「リクエストないけどこのファイル使うよ
ね」ってコンテンツを、サーバ側が(クライアントの
リクエスト無しに)プッシュできる機能です！

• 注意点
– 普及はこれからなんで、まぁ気長に
– 「大型コンテンツ」以外は、そんなに旨味が大きい
わけでもない、かもしれない
– 「HTTP1.1のころのチューニング手法」が、場合に
よっては仇になる(ドメインシャーディングとか)
• まぁ「Webを使う側」的には気にしないでいい
ので、ある意味気楽ですｗ

総まとめ
• えらい長くかかりました…が、25年くらいの歴
史を振り返ってるのでこんなもんでしょうｗ
• 時代…というか「その時に提供されているコン
テンツの質とか種類とか」に従って、HTTPも
色々と改良やら工夫やらが加えられています
• でも基本は「ちょうだい」「あいよ」です
• そんな「複雑でシンプル」なHTTPの世界を楽
しんでいただければ、とてもうれしいです＾＾

Httpを振り返ってみる

More Related Content

Viewers also liked

Similar to Httpを振り返ってみる

Httpを振り返ってみる