HTTPの歴史とこれから 

3月 31日 @ 16:00 ～ 17:00 主催者: inductor

資料

• スライド
  • https://speakerdeck.com/inductor/http 

講演

HTTPの誕生

• 1990　CERNによってHTMLを世に届けるために誕生
• 1991 HTTP/0.9として　ドキュメント化
  • →紙一枚程度の建て付けだった

RFCの策定とHTTP/1.0

• 1996年位策定公開
• GET/HEAD／POSTメッソドサポート
• レスポンスにヘッダーの概念が追加
• ステータスコードも追加　404など
• 標準化/バージョンの搭載→結果として前バージョンが0.9化した

HTTP/1.1 今のデファクト

• 1990 RFC2068で標準化
• HTTPのコネクトがコネクションごとに切れない→CLOSEしない限り3-way しなくて良い
• PUT/DELETEメッソドサポート
• Virtual hostが仕様に追加された
• Virtual hostは一つのサーバで複数のドメインを管理できる仕組み
  • 例　レンタルサーバ
    • a.com
    • b.com
• 仕様追加以前は http://example.com/~ユーザ名/index.html  みたいな ~ (チルダ) がURLによく入っている構成

HTTPSの登場

• HTTPSという新しい概念ではない
  • HTTP+SSL/TLS →　HTTPS
• 旧来の暗号化されていないHTTP通信を、別レイヤーの暗号化技術SSL/TLSを利用することで 通信が秘匿化できるようになった。

秘匿化の方法

• 公開鍵認証
  • パフォーマンス悪い（ユーザごとに鍵を持つため、処理が煩雑）
• 共通鍵認証 - サーバーがクライアントごとに鍵を生成して管理する - 鍵の種類が一つのため、処理早い - クライアントごとに鍵を持つため、鍵の管理が大変 - 最初に渡す時盗まれると大変
• SSl　公開鍵、共通鍵ハイブリッド
  • 最初の鍵交換で共通鍵を公開鍵の方法を使い渡す
  • 渡した後は共通鍵方式で通信

HTTPの問題点と今後の動き

• 課題
  • プロトコル自体が古い
  • インターネット進化の速度にあっていない
  • 安全の点で節穴
  • スノーデンさん事件参考
  • 古い暗号化プロトコルがいまだに横行している 
  • パイプラインが不完全
    • 処理がキュー状態になって逐次処理していくので途中で処理がもたつくと全体が遅延してしまう。

Googleからの新たな提案が・・・

SPDY(スピーディ)

• 2012年頃に提唱された

• 旧来の順番に処理しなければならない通信を仮想的に多重化することで高速化させることに成功

• TLS1.2による暗号化通信が必須

• 2015年に軒並みのプラウザで対応済み

HTTP/2

• SPDY/4.0をさらにすすめ、RFC2616としてHTTPプロトコルとして標準化

• GoogleだけでなくMicroSoftやFacebookなどが参画し提案・フィードバックによって仕様を協議・確定した。

• サーバからクライアント側に通信を送れる→PUSH通知などに使用されている

• Chromeなどから通知の許可を求められていますなどが出るのがそれ

• HTTPのバージョンとしては、実に16年ぶりとなるオフィシャルアップデート

• Windows10のIE11ほか、Safari9、Chorme31、FireFox34以降にて標準対応

• WEBサーバがWIN10、nginx1.9.5、Apache2.4.17以降で対応

HTTP2についてまとめると・・・

• HTTPの久方ぶりのオフィシャルアップデートになるので環境から更改する必要がある場合がある
• TLS1.2の導入が必須である

導入方法

• OoenSSL1.0.2以降でコンパイルしたnginx、ApacheなどのWEBサーバーでhttp2のコンフィグを有効化する

パフォーマンス

• 通信が複数回に分けて行われる(コネクションがすぐ切れるパターン、通信拠点の物理的距離が離れている場合)場合は、改善しそう
• 国内のシンプルなページではそこまで変わらない
• 通信コストがサービスは改善しそう
• プッシュ通知をする場合は必須

HTTP2の限界

• あくまでHTTPの拡張でしかない

  • →考え方が古い

• TCPの方法が遅い

  • →3Wayハンドシェイクによる通信遅延＋SEQ、ACKによる管理による通信遅延

QUIC(Quick UDP Internet Connections)プロトコル

• googleが開発中
  • UDPベースで早い
  • データの整合性チェックや暗号化も全て行なってくれてる

QUICの特性・メリット

• UDP上でセッションIDを管理している

  • →セッションIDが復元できる！

• UDOの上のレイヤを全て自前で実装しているので、最初のACKなども全部暗号化する

  • →既存の仕組み（通信のOSI7層参照モデル）も変わる？

• 使用事例： 　LINE、AKAMAIで既に実装されていて、複数の改善事例が！

QUICの現状・デメリット

• 標準化が未完了
  • Googleが開発していたとはいえ、GoogleのQUICと
  • 標準化機関のQUICの仕様に違いがあり、最終的に標準化された仕様がどのようになるのか不透明
• TLS1.3の導入も必須(TLS1.3自体も標準化がまだされていない)
  • 普及がされていないため、現状問題あり

• 今後は？ →コア仕様の確定を目指す(2018/11まで)

今後の動向に対する私見

• QUICも大事だがTLS1.3の動向も大事

• Googleのサービスだとデフォルト実装を"勝手に"されてしまっている場合があるので明示的に無効化する必要があるかもしれない。

• アプリ屋、インフラそれぞれが対応できるかを考えす必要がある

まとめ

• HTTPのような成熟したプロトコルも日々動きがある 最新の技術のキャッチアップ大事、絶対 QUIC流行ってほしい

資料

使用資料

• https://speakerdeck.com/inductor/http 
• 技術的な使用については以下参照
  • https://speakerdeck.com/shigeki/yun-yong-falseguan-dian-karajian-tatlspurotokorufalsedong-ki 
• flanno_yukiさんのブログも詳しく書かれている

講演

参加者の声

• QUIC
  • UDP/TCP + SSL/TLS がmixin したものですね
• UTL,HTTP,HTMLの最初の設計者であるティム・バーナーズ＝リーは ナイト・コマンダーの称号を授与されている。

Q & A

(Discord 上に質問が流れたらピックアップお願いします)

• Q.HTTPのデータをUDPでやり取りすることも可能ではあるんですか？

  • A.

• Q.クライアントが繋ぎに行く途中で、鍵を横取りしたら丸見えって場合もありますか？

  • A.

• Q. QUICってTCPあたりの層の話なので、HTTPとはまた独立した話って認識で良いです？

  • A.googleが考えた最強のHTTP
  • 複数のレイヤにまたがっているため、TCPだけとは言えない
  • 難しい質問