Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webを早くする技術(HTTP)

 Webを早くする技術(HTTP)

Haru(utsushiiro)

July 31, 2017
Tweet

More Decks by Haru(utsushiiro)

Other Decks in Programming

Transcript

  1. ▷ Table of contents ◦ HTTPとは ◦ HTTP 1.1 ▪

    Keep-Alive ▪ Pipelining ◦ プロトコル以外の部分での高速化 ◦ SPDY ◦ HTTP 2 ◦ QUIC
  2. ▷ 1991年 HTTP/0.9 ▷ 1996年 HTTP/1.0 RFC 1945 ▷ 1999年

    HTTP/1.1 RFC 2068 ▷ 2015年 HTTP/2 RFC 7045 HTTPの変遷
  3. Keep-Alive (HTTP/1.1) HTTP Request HTTP Response HTTP Request HTTP Response

    一連のリクエストの 最初と最後だけ
  4. Pipelining (HTTP/1.1) HTTP Request 1 HTTP Response 1 HTTP Request

    2 HTTP Request 3 HTTP Response 2 HTTP Response 3
  5. Domain Sharding ブラウザは先述したHead of Line Blocking等 の影響を 小さくするために, 1ドメインに対して同時に複数のコネク ションを貼っている

    Domain Shardingはリソースを複数のドメインに分散させ て更に同時接続数を増やす方法 ※ 画像を別ドメインにするサイトが多いが   理由としてはこれ↑とセキュリティ向上  
  6. HTTP/2 SPDYをベースにHTTP/2が策定(RFC 7540) 1. 優先度付全二重多重化通信 2. プロトコルのバイナリベース化 3. HTTPヘッダーの圧縮 4.

    フロー制御 1, 2, 3については後述. 4では主にHTTPのレイヤで, TCPのフロー制御の様なこ とをやるための枠組み(window size 制御)を仕様化して いる.
  7. コネクションを使いまわすメリット Keep-alive や HTTP/2 のストリームは 一つのコネクション使いまわす 3 way handshake のオーバヘッドだけでなく

    スロースタート等によるwindow sizeの調整に かかる時間のオーバヘッドも減らせる. また, 複数のコネクションを立てるのに比べて 効率的な輻輳制御が行われる(※). ※ 従来の複数では輻輳制御がそれぞれ独立して   行われるため, 帯域を効率的に使うのが難しい
  8. TCPのHead of Line Blocking HTTP/2ではHTTPのHoL Blockingを防げる しかし, TCPのHoL Blockingは防げない ▷

    TCPのHoL Blockingとは TCPでは先頭のパケットがロスすると 後続のパケットを処理することができない また, HTTP/2は1本のコネクション上で多重化する分 複数使っていた頃よりこれの影響が大きい恐れがある
  9. なぜUDPベース? 長期的な目標はTCPやTLSの改善 しかし, TCP/TLSの改良(提案, 実装, 検証 … etc)には 時間がかかる UDPで理論を実践した後に,

    有効な機能をTCP/TLSの 後続バージョンにフィードバックする (もちろん)UDPを用いるので先述した TCPのHoL Blockingは起きない(ようになってる)
  10. QUICでやろうとしていること ▷ TCPやTLSの処理の効率化 ◦ 接続の確立時に必要なRTTを減らす (TFOやTLS False Startと同じ考え) ▷ パケット損失の影響を低減

    ◦ パケットレベルの前方誤り訂正 ◦ 暗号化のブロックやパケットの境界を整理 ▷ 再接続(接続の維持)の簡易化 ◦ 後述