[備忘録10]作って学ぶブラウザのしくみ / HTTPを実装する/ HTTPとは

この章では、簡単なHTTPクライアントを実装する。URLを指定するとHTTPレスポンスが返ってくるプログラムと、その挙動を確かめるための簡単なアプリケーションをWasabiOSで動かすことが目標

HTTPとは

TCP/IPにおけるアプリケーション層に位置する。ユーザに一番近いプロトコルであり、Webアプリケーションを書いたことがある人なら馴染みがあるものだと思う。
ここでは、HTTPを送受信するプログラムを書くことによってインターネット上での情報のやり取りの理解を深めることが目的。

[HTTPの基本的な仕事]

• クライアントとサーバー間でテキスト形式のリクエスト、レスポンスを交換すること。
  • 以下は、ブラウザ、DNSサーバー、Webサーバー間でHTTPがどのようにデータをやり取りするかをMermaidで表現するシーケンス図です。

[クライアントとサーバ間での情報のやり取り]
サーバはリクエストに対するレスポンスを生成する。
クライアントは、サーバーが作成したレスポンスを受信して解釈する。

[HTTP1.1の特徴]

• 以前は、１つのTCP接続で１つのリクエスト、１つのレスポンスのみを処理していた。
  TCP接続を接続するためには、3回のやり取りをしないといけない。これによりHTTP接続に毎回TCP接続を確立するための余計なやり取りがあった。（ref:3-way handshaking)

• 現在はRFC2068で**持続的接続(keep alive)**が導入されたので、一度確立したTCP接続を再利用できます。

  • keep aliveなし
  • keep aliveあり

• さらに、RFC2068で**パイプライン化(Pipelineg)**も導入され、他院いつTCP接続上でレスポンスを待たずに複数のリクエストを送信できるようになった。

  • パイプラインを使用する際は、リクエストとレスポンスの順番が大切で、サーバはリクエストを受信した順序と同じ順番で応答を送信する必要がある。しかも、もし１つのレスポンスが遅延、紛失したときは、それ以降のレスポンスも使用不可になる。これをヘッドオブラインブロッキング（HOLブロッキング）と呼ぶ。また、一部のサーバやプロキシはパイプラインをサポートしていないこともあり、この機能は現在あまり使用されていない

[HTTP2の特徴]

RFC7540では、マルチプレクシング、ヘッダ圧縮、サーバプッシュ、優先度付け、フロー制御などが導入された。

• マルチプレクシング(multiplexing)
  • 1つのTCP接続上にストリームと呼ばせる亜k層的な説を句を複数作成することで、複数のリクエストとレスポンスを同時に処理できる。これにより、リクエストの待ち時間やTCP接続の数を減らし、ページの読み込み速度を向上させる。
    • これによりhttp1.1のRFC2068で導入されたパイプラインが代替されるようになった。
• ヘッダ圧縮(Header Compression)
  • HPACKと呼ばれる手法ではHTTPヘッダの圧縮が導入され、通信量を削減できる
• サーバープッシュ(Server Push)
  • サーバーがクライアントに対して必要なリソースを自動的にプッシュできる。これにより、クライアントがリソースを要求する前に必要なリソースを送信でき、ページの読み込み速度を向上させる。
    • 2022年にはchromeブラウザはHTTP2のサーバプッシュのサポートを廃止した
    • 複雑な実装とオーバーヘッドが大きかったから使用率が１%未満だったそう。
• 優先度付け(Prioritization)
  • リクエストに優先度をつけることができる。
• フロー制御(Flow Control)
  • 受信側のキャパシティに合わせて送信側のデータ量を超背できる、

[HTTP3の特徴]

• QUIC(Wuick UDP Internet Connections)プロトコルをベースにしている。QUICはUDP上で通信を行うため、従来のTCPよりも高俗な通信を実現する。