HTTPを振り返ってみる

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

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

わんくま同盟東京勉強会 #103 本講の目的 • 昔を懐かしむ事です(マテ • 基本的に「年寄りの昔話」的なお話をじっくりとできれば、と思ってます(笑

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

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

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

わんくま同盟東京勉強会 #103 アクセスログ(一例) 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> 以下略

わんくま同盟東京勉強会 #103 • ちょうだい(リクエスト) – GET /index.html • あいよ(レスポンス)
– <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> 以下略

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

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

わんくま同盟東京勉強会 #103 HTTP1.0爆誕 • 1996年5月、HTTP1.0爆誕生 • いきなり山盛りに仕様が増えました！！

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

to localhost.localdomain (127.0.0.1). Escape character is '^]'. 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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> 以下略

わんくま同盟東京勉強会 #103 • ちょうだい – GET /index.html HTTP/1.0 User-Agent:
telnet Accept-Language: ja

わんくま同盟東京勉強会 #103 • あいよ(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" Accept-Ranges: bytes Content-Length: 4053 Connection: close Content-Type: text/html

わんくま同盟東京勉強会 #103 • あいよ(BODY) – <!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 3.2 Final//EN"> <HTML> <HEAD>

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

to localhost.localdomain (127.0.0.1). Escape character is '^]'. 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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META http-equiv="Content-Type" content="text/html; charset=shift_jis">

わんくま同盟東京勉強会 #103 • HTTP1.0で、いきなり色々な情報の応酬が可能になりました • いくつかをかみ砕いて、残りを駆け足で、見ていきましょう

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

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 • 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 を返し、コンテンツを返さない(ことで節約)

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

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

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

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

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

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 ちょっと面倒なバージョン問題 • 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使われてない…

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

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

わんくま同盟東京勉強会 #103 • 「提案があって受け入れられやすいっていうか必要なものは、とっとと実装するよねぇ」事案でございます

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

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 (ややこしいんで流していきましょうｗ) • 数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

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

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

わんくま同盟東京勉強会 #103 • 第三フェーズ：クライアントからサーバに対して、鍵共有に必要な情報の共有 – Certificate、 ClientKeyExchange、 CertificateVerify
• 第四フェーズ：暗号方式切り替えの確認 – Change Cipher Spec、Finished、Change Cipher Spec、Finished

わんくま同盟東京勉強会 #103 通信の「クライアント(左)」と「サーバ(右)」の区分け • ClientHello • ServerHello • Certificate
• ServerKeyExchange • CertifiateRequest • ServerHelloDone • Certificate • ClientKeyExchange • CertificateVerify • Change Cipher Spec • Finished • Change Cipher Spec • Finished

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 参考：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

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

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

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

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

わんくま同盟東京勉強会 #103 telnet localhost 80 Trying 127.0.0.1... Connected to
localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /index.html HTTP/1.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: (略) 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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> 以下略

わんくま同盟東京勉強会 #103 telnet localhost 80 Trying 127.0.0.1... Connected to
localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /index.html HTTP/1.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" Accept-Ranges: bytes Content-Length: 826 Connection: close Content-Type: text/html <html> <head> <title>Grid Works Guild 格子組 Web Page</title> 以下略

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

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

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

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

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

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

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 • HTTP1.0にあって、1.1で廃止になった子 – LINK – UNLINK •
HTTP1.1で新設された子 – CONNECT – OPTIONS – TRACE

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

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

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

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

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

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

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

わんくま同盟東京勉強会 #103 • SSLの通信を復号するためには、ドメイン名が必要です • ドメイン名はHTTPリクエストの中に書いてあります •
HTTPリクエストを見るためには、SSL通信を復号する必要があります • SSL通信を復号するためには、ドメイン名が必要です • 以下loop

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

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

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

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

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

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

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

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

HTTPを振り返ってみる

HTTPを振り返ってみる

More Decks by gallu

Other Decks in Programming

Featured

Transcript