HTTP

Transcript

1. HTTPの歴史とこれから インフラ屋として何を対応しなければならないか考えてみる 「HTTPのこと、わかってる？」って美少女に言われたら興奮する？ いやしないか・・・ @インフラ勉強会 BY INDUCTOR
2. お前だれやねん  Inductor(Twitter: _inductor_)  インフラ勉強会でAdminをやっています  4/1からとあるECサイトを運営している会社でサーバーを作ったり いじったりする仕事をします  前職(今日まで所属)はWebのバックエンドやAndroidアプリ開発などを やっていました  その前はデータセンター内で運用・監視のSEをやっていました  ただのポンコツエンジニアです
3. HTTPってなんだっけ？
4. HTTPってなに？  HyperText Transfer Protocol(ハイパーテキスト転送プロトコル)の略称  HTMLやXMLなどの”マークアップ言語”で記述された 「ハイパーテキスト」を転送するために作られたプロトコル  データの中身が重要なので、TCPで通信する  現在ではその高い汎用性から、画像や音声など、 様々なデータのやり取りにも応用して利用されている
5. HTTPの歴史と進化
6. HTTPの誕生とHTTP/0.9  もともとは、CERNで生まれたHTMLを世に届けるためのプロトコル として、科学者が草案を作った(1990年頃)  1991年にHTTP/0.9として産声を上げ、ドキュメント化された  TCP-IPでドメイン/IPアドレスに接続する基本的な部分は全く同じ  デフォルトで使用されるポートも80番だった  GETリクエストとそのレスポンスのみというシンプルな構成  データをサーバーに送ったり、動的にデータを授受するなどの仕様は 組み込まれていなかった  https://www.w3.org/Protocols/HTTP/AsImplemented.html
7. RFCの策定とHTTP/1.0  1996年にRFC 1945として仕様が公開された  GET / HEAD / POSTメソッドのサポート  サーバーにデータを送る仕組みができた  レスポンスにヘッダーの概念が追加された  Content-TypeとかUser-Agentなど、今でも一般的に使われるものができた  ステータスコードが追加された  バージョンの概念が増えたので、プロトコルのバージョンを 明示するようになった 成約が多かった0.9から大きく拡張され、様々なことができるようになった！
8. HTTP/1.1 “現在の”デファクトスタンダード  1999年にRFC 2068として標準化  HTTPセッションがコネクションごとに切れなくなり、 明示的にCloseしない限り持続するようになった  3-way handshakeのオーバーヘッドが大幅に減った  パイプラインが追加され、リクエストごとに待ち時間を 気にしなくてよくなった  PUTやDELETEなどのメソッドが追加された  Hostヘッダが追加され、Virtual Hostという概念が使えるようになった！
9. HTTPS(HTTP over SSL/TLS)の登場  HTTPSは、HTTPをもとにした新しいプロトコル・・・というわけではなく、 HTTP通信を、その下のレイヤにあるSSL/TLSという暗号化技術で秘匿化す るマルチレイヤにまたがった通信方式  既存のHTTPプロトコルを”置き換える”のではなく、 SSLのレイヤで被せているだけ  SSLのエンドポイント間において通信を暗号化することにより、 中継区間でのデータ改竄や盗聴などを防ぐ
10. SSLの簡単なしくみ  公開鍵認証と共通鍵認証のハイブリッド  最初の鍵交換時のみ公開鍵を使う  接続確立後はクライアントごとに独立の 共通鍵で通信する  SSHでよく使われる鍵認証は公開鍵認証 画像引用元: http://www.netsurf.ad.jp/hojin/sv/namae_de_web/ssl_opt.html
11. 公開鍵認証とは  公開鍵・秘密鍵と呼ばれる2種類の鍵を使った認証方法  公開鍵：みんなに渡す暗号化をかけるための鍵  秘密鍵：サーバーだけが持つ復号化用の鍵  初回リクエスト時に公開鍵を受け取ったクライアントが、情報を公開鍵で 暗号化した上でサーバーに送信→サーバー側は秘密鍵を使って中を見る  サーバー上にある秘密鍵でしか中身がわからないよ！という仕組み  メリット：どのユーザーに対しても同じ公開鍵を渡せるので、鍵の管理が 楽。秘密鍵をサーバーから盗まれない限りは(理論上)安全  デメリット：クライアント側とサーバー側で異なる鍵を使うため処理が複 雑、また、パフォーマンスも悪い
12. 共通鍵認証とは  暗号化・復号化に同じ鍵を用いる暗号方式  一般的な普通の物理的な鍵と同じ  みんなで同じ鍵を使うとみんながデータを見れてやばいので、普通はクラ イアントごとに別々の鍵を生成して管理する  メリット：鍵の種類が1つなので計算速度が速い  デメリット：クライアントが増える毎に鍵の数が多くなるので管理が大変。 また、共通鍵を最初に渡すときに情報が盗まれてしまうと、復号されてし まうのでやばい
13. 改めて、SSLの簡単なしくみ  公開鍵認証と共通鍵認証のハイブリッド  最初の鍵交換時のみ公開鍵を使う  接続確立後はクライアントごとに独立の 共通鍵で通信する  SSHでよく使われる鍵認証は公開鍵認証 画像引用元: http://www.netsurf.ad.jp/hojin/sv/namae_de_web/ssl_opt.html
14. 現状におけるHTTPの問題点と これから起こるであろう動きについて
15. HTTP/1.1に見える課題  1999年に作られたプロトコル  インターネットの進化の速度から考えると、もう既におじいちゃん  個人情報を扱う201x年において、暗号化通信が非標準  スノーデン事件によって、Full Secureな通信の需要が高まった  HTTP1.1+TLSにおいても、TLS1.0のような既に非安全となったプロトコルが 未だに横行している  Ref: http://www.intellilink.co.jp/article/pcidss/18.html  不完全なパイプライン  リクエストはどんどん投げることができても、 サーバーはすべて順番通りに返す必要がある  画像や動画などの重いデータがあったり、バックエンドの処理でもたつくと 他のコンテンツを転送するまでに無駄な待ち時間が生じる
16. Google「もっとがんばってこ？？」
17. SPDY(スピーディ)の登場  2012年頃にGoogleが提唱した、HTTP1.xをラップする新しい通信プロトコル  ストリームを仮想的に多重化し、今まで順番に通信せざるを得なかった 不完全なパイプラインを一気に通信できるようにした  ヘッダ部分をテキストからバイナリに変更、さらに圧縮し、 データ部ではない部分によって発生する余計な通信量を減らした  (SPDYそのものの仕組み上はいらないけど実装上そうなっている) TLS1.2による暗号化通信が必須  2015年には軒並みブラウザでの対応が完了  モバイル市場においても、Android3、iOS8において対応済み  IE11すら対応
18. HTTP/2！！！  SPDYの最終型であったSPDY/4をさらに進め、RFC 2616として 2015年2月に正式なHTTPプロトコルとして標準化  策定にはGoogleほか、Microsoft、Facebookなどが参画し、 それぞれの提案・フィードバックによって仕様を協議・確定した  サーバープッシュによる新たなユーザー体験(サーバー側から 動的に情報を通知できる)  イメージとしてはアプリのプッシュ通知をブラウザ上でやるようなもの  Youtubeでチャンネル登録していると最新の動画などが通知されたりする  PWA、SPAなどで利用されるケースが増えている  HTTPのバージョンとしては、実に16年ぶりとなるオフィシャルアップデート  Windows10のIE11ほか、Safari9、Chrome31、Firefox34以降にて標準対応  WebサーバーはWin10のIIS、nginx 1.9.5、Apache 2.4.17以降にて対応
19. HTTP/2についてまとめると・・・  むっちゃ古いHTTPプロトコルを、後方互換性を維持したまま改善しようと頑張った Googleさんたちの努力の結果  唯一ボトルネックになりうるのがTLS1.2が導入必須であること  古い暗号化方式はわりと捨てている  HTTPS化できない事情がある場合は使えない  具体的な導入方法は？  OpenSSL 1.0.2以上でコンパイルされたnginx、Apache、Caddy、h2oなどの Webサーバを使ってhttp2のコンフィグを有効化するだけ  NodeJSなどのアプリケーションサーバーでも使えたと思う  パフォーマンスはどうなん？  改善しやすいパターン、そうじゃないパターンがある  通信が複数回に分けて発生するパターンとか、物理的距離によって通信そのものに時間的コストが 生じるパターンなどは改善しがち  国内でシンプルなページを提供するだけのレベルだと、違いはほとんど感じられない  サーバープッシュが要件として含まれている場合は導入必須
20. So, what will happen in the nearly future?
21. HTTP/2の限界  HTTP/2では互換性が重視されたが故に導入しなかった新しい考え方も多い  HTTPプロトコルの構造そのものが古い  そもそもTCPベースの時点で遅い  どんなにトラフィックをさばけるようにNWの部分を増強しても パフォーマンスの改善に限界があるため、通信のボトルネックに なっているRTT(Round Trip Time)の部分をどう改善する？
22. Google「じゃあTCPやめたろｗｗ」
23. QUICプロトコルの登場  Googleが2013年から開発している新しい通信プロトコル  TCPより圧倒的に速いUDPをベースとして、データの整合性チェックや暗 号化などを含め、HTTP/2が有している機能をすべてQUICとして再実装 (!?)
24. ただ速いだけじゃないQUIC  UDP上でセッションIDを管理するため、IPアドレスが変わろうが セッションIDが復元できる(モバイル通信やWiFiアクセスポイント 切り替えなどに強い)  UDPの上のレイヤをすべて自前で実装しているので、最初のACKとかも 全部暗号化できる  TCPとかいう激遅プロトコルを改善するという試みからの開放  OSのTCPライブラリがどうとかどうでもよくなる  LINEとかAkamaiも既に導入事例を作っていて、パフォーマンスの改善が 報告されている
25. QUIC、いい事だらけなの？  まだ標準化は終わっていない(ドラフトが出続けている)  Googleの実装であるgQUICと標準化仕様であるIETF QUICとで現在は完全に 分かれている  お互いに情報交換はしているものの、仕様的な部分でいろいろな違いもある  TLS1.3(こちらもまだ標準化未完了)の導入が必須となるため、そちら側の理解も 必要になる  TLS 1.3については、2017年にBluecoatのプロキシとちょっとした事件があったため、 抵抗を感じる人が多いかもしれない  透過性の問題などはまだまだGoogleでも議論が続いていた(という記憶)  TLS1.3においても、従来の暗号化通信で問題になっていたRTTなどの遅延問題が 改善される見込み  で、今はどうなってんの？  今のところ、コア仕様を固めて2018年11までに提出するのが目標  いまいますぐにどうかなるというわけではない
26. どうすりゃいいの？  QUICだけじゃなく、TLS1.3の動向にも気を使う必要がある  GoogleのサービスをChromeで利用すると、QUICが有効になっている 可能性が高いので、”場合によっては”管理部のインフラ屋さんとかは L7FWを使ってQUICを明示的に無効にする必要があるかもしれない  新しい技術をものすごく嫌がる人がいるが(気持ちもわかる)、 悪ではなく、ただの新しい技術なので、温かい目で見守ってほしい  アプリ屋さんともちゃんと相談して、ミドルウェアの 選定・対応を検討していきたい
27. まとめ  HTTPみたいな身近かつ十分成熟したプロトコルも、 実は日々進化するためにいろいろ動きがある  身近な技術の動向をキャッチアップすることも、 インフラエンジニアとしては大事なスキル(を僕は思っている)  QUIC流行れ  僕より詳しい人、続きをどうかお願いします  https://speakerdeck.com/shigeki/yun-yong-falseguan-dian- karajian-tatlspurotokorufalsedong-ki  大津さんの資料がすごくよくまとまっていてわかりやすい  flano_yukiさんのブログも良いです！！！
28. ご静聴ありがとうございました！