HTTPプロトコルの歴史

HTTP 1.0

1. リクエスト・ヘッダとレスポンス・ヘッダが導入されました。
2. キャッシュ機構、ユーザエージェント、ステータスコードなどの基本情報を提供します。

問題：非効率的な接続と低い伝送速度

HTTP1.1

1. 持続的接続の追加 接続: keep-alive
2. Hostフィールドは、サーバーがHost値の違いによって異なる処理を行えるように、現在のドメインアドレスを示すために追加されます。
3. チャンク転送メカニズムはこの問題を解決するために導入されたもので、サーバーはデータを任意の大きさのチャンクに分割し、それぞれのチャンクは前のチャンクの長さで送信され、最後に長さゼロのチャンクが送信データの完了を示すために使用されます。これにより、動的コンテンツをサポートします。
4. Cookie

問題：帯域幅が十分に利用されていない原因

1. TCP スロースタート
2. 複数のTCPコネクションが同時に開いている場合、これらのコネクションが一定量の帯域幅を奪い合います。
3. HTTP/1.1キューヘッダのブロック問題

知識：スロースタートやTCPコネクション同士の帯域幅の競合はTCP独自のメカニズムによるもので、ヘッダーブロックはHTTP/1.1のメカニズムによるものです。

HTTP2.0

http 1.1の欠点に対処するため、HTTP 2.0の解決策は、ドメイン名に対して1つの長いTCP接続のみを使用し、キューヘッダーのブロック問題を排除することです。

1. 多重化 - バイナリフレームレイヤーの導入
   • バイナリフレーミングレイヤーによって処理された後、フレームはリクエストID番号を持つ個々のフレームに変換され、プロトコルスタックを介してサーバーに送信されます。
   • サーバーは全てのフレームを受け取ると、同じ ID を持つ全てのフレームを一つの完全なリクエストメッセージにまとめます。
   • それからサーバはリクエストを処理し、処理された応答行、応答ヘッダー、 応答ボディをバイナリフレーミングレイヤーに送ります。
   • 再び、バイナリフレームレイヤーはレスポンスデータをリクエスト ID 番号を持つ個々のフレームに変換し、スタックを通してブラウザに送ります。
   • ブラウザはレスポンスフレームを受け取ると、ID番号に基づいてフレームデータを対応するリクエストに送信します。
2. リクエストの優先順位を設定できます。
3. サーバープッシュ
4. ヘッダー圧縮

問題：TCPヘッダーのブロッキング例：HTTP/2では、複数のリクエストがTCPパイプで実行され、いずれかのストリームでパケットロスが発生すると、そのTCPコネクション内のすべてのリクエストがブロックされます。HTTP/1.1とは異なり、HTTP/1.1を使用する場合、ブラウザはドメイン名ごとに6つのTCPコネクションを開き、そのうちの1つがブロックされても、他の5つのコネクションはデータ転送を継続できます。HTTP/1.1とは異なり、HTTP/1.1の場合、ブラウザはドメインごとに6つのTCPコネクションを開き、そのうちの1つがヘッダーによってブロックされても、残りの5つのコネクションはデータ転送を継続できます。そのため、パケットロス率が高くなればなるほど、HTTP/2の転送効率はどんどん悪くなっていきます。いくつかのテストデータでは、システムが2%のパケットロス率に達した場合、HTTP/1.1の転送効率はHTTP/2よりも優れています。

Think: TCPプロトコルには、キューヘッドのブロッキングやコネクション確立の遅延といった欠点があります。答えは「非常に難しい」です。 理由：TCPプロトコルの硬直性

1. 中間装置の剛性
   • インターネットは複数のネットワークが相互に接続されたメッシュ構造になっており、インターネットを正常に運用するためには、インターネットの各所に中間装置と呼ばれる様々な機器を構築する必要があります。
   • この中間装置には、ルーター、ファイアウォール、NAT、スイッチなど、さまざまな種類があり、それぞれに目的があります。これらは通常、めったにアップグレードされないソフトウェアに依存しており、一度設定されるとめったに更新されない多数のTCP機能を使用しています。
   • クライアント側でTCPプロトコルがアップグレードされても、新しいプロトコルのパケットがこれらの中間デバイスを通過すると、中間デバイスがパケットの内容を理解できず、データが破棄されてしまうことがあります。これが中間デバイスの硬直性であり、TCPアップデートの大きな障害となります。
2. オペレーティング・システムによる制限
   • TCPプロトコルはオペレーティング・システムのカーネルに実装されており、アプリケーションによってのみ使用され、変更されることはありません。オペレーティング・システムの更新がソフトウェアの更新に遅れることがよくあるため、カーネル内のTCPプロトコルを自由に更新することは非常に困難です。

HTTP 3.0

この問題はTCPプロトコルを修正することで解決できないため、TCPとUDPしか認識できない中間デバイスの硬直性から、TCPプロトコルをバイパスすることを考え、UDPプロトコルをベースにした別の機能セットを実装することを選択します。

1. UDPをベースに、複数のデータストリームや伝送信頼性といったTCPライクな機能を実装したもので、 QUICプロトコルと呼ばれています。

• フロー制御、伝送信頼性といったTCPのような機能を実装 - UDPは信頼性のある伝送を提供しませんが、QUICは信頼性のあるデータ伝送を保証するためにUDPの上にレイヤーを追加します。パケットの再送、輻輳制御、その他TCPにある多くの機能を提供します。
• 統合TLS暗号化
• HTTP/2に多重化を実装 - TCPヘッダーのブロッキングを排除
• クイック・ハンドシェイク機能の実装

挑戦

1. 現状では、サーバーもブラウザもHTTP/3をより完全にサポートしていません。
2. HTTP/3の導入も非常に問題があります。これは、システムカーネルがTCPと同じ程度にUDPに最適化されていないためで、QUICの大きな障害となっています。
3. 硬直した中間デバイスの問題。これらのデバイスはTCPよりもUDPに最適化されておらず、QUICプロトコルを使用した場合、統計的に約3%から7%のパケットロス率があります。
4. HTTP/3は、HTTP/2とは根本的に異なる基礎となるプロトコルを移動させるため、よりゆっくりと成長するでしょう。

究極

• ご視聴ありがとうございました。