HTTP - ShuWa

1. HTTP 基本概念#

1.HTTP は何ですか？#

HTTP は超テキスト転送プロトコル、つまり HyperText Transfer Protocol です。
HTTP の名前「超テキストプロトコル転送」は、三つの部分に分けることができます：

超テキスト：普通のテキストを超えたテキストであり、文字、画像、動画などの混合体で、最も重要なのはハイパーリンクであり、ある超テキストから別の超テキストにジャンプできます。
伝送：二点間で双方向にデータを伝送すること
プロトコル：コンピュータ間の通信の規範を確立すること（2 つ以上の参加者）

2.HTTP の一般的なステータスコードは何ですか？#

1xx 系のステータスコードは情報を示すもので、プロトコル処理の中間状態の一つで、実際にはあまり使用されません。
2xx 系のステータスコードは、サーバーがクライアントのリクエストを正常に処理したことを示し、私たちが最も望む状態です。
「200 OK」は最も一般的な成功ステータスコードで、すべてが正常であることを示します。HEAD リクエストでない場合、サーバーが返すレスポンスヘッダーには必ずボディデータがあります。
「204 No Content」も一般的な成功ステータスコードで、200 OK と基本的に同じですが、レスポンスヘッダーにはボディデータがありません。
「206 Partial Content」は、HTTP のチャンクダウンロードや再開に適用され、レスポンスで返されるボディデータがリソースのすべてではなく、その一部であることを示し、サーバーが正常に処理した状態でもあります。
3xx 系のステータスコードは、クライアントがリクエストしたリソースに変更があったことを示し、クライアントは新しい URL を使用してリクエストを再送信する必要がある、つまりリダイレクトです。
「301 Moved Permanently」は永久的なリダイレクトを示し、リクエストされたリソースが存在しなくなったことを示し、新しい URL を使用して再度アクセスする必要があります。
「302 Found」は一時的なリダイレクトを示し、リクエストされたリソースはまだ存在しますが、一時的に別の URL を使用してアクセスする必要があることを示します。
301 と 302 は、レスポンスヘッダーで Location フィールドを使用して、次にジャンプする URL を示し、ブラウザは自動的に新しい URL にリダイレクトします。
「304 Not Modified」はリダイレクトの意味を持たず、リソースが変更されていないことを示し、既存のキャッシュファイルにリダイレクトされることを示し、キャッシュ制御に使用されます。
4xx 系のステータスコードは、クライアントが送信したメッセージに誤りがあり、サーバーが処理できないことを示します、つまりエラーコードの意味です。
「400 Bad Request」は、クライアントのリクエストメッセージにエラーがあることを示しますが、一般的なエラーです。
「403 Forbidden」は、サーバーがリソースへのアクセスを禁止していることを示し、クライアントのリクエストが誤っているわけではありません。
「404 Not Found」は、リクエストされたリソースがサーバー上に存在しないか見つからないことを示し、したがってクライアントに提供できません。
5xx 系のステータスコードは、クライアントのリクエストメッセージが正しいが、サーバー処理中に内部エラーが発生したことを示し、サーバー側のエラーコードに属します。
「500 Internal Server Error」は 400 タイプと同様に、一般的なエラーコードで、サーバーで何が起こったのかはわかりません。
「501 Not Implemented」は、クライアントのリクエスト機能がまだサポートされていないことを示し、「近日中にオープン予定」という意味に似ています。
「502 Bad Gateway」は、通常、サーバーがゲートウェイまたはプロキシとして動作しているときに返されるエラーコードで、サーバー自体は正常に動作しているが、バックエンドサーバーへのアクセス中にエラーが発生したことを示します。
「503 Service Unavailable」は、サーバーが現在非常に忙しく、クライアントに応答できないことを示し、「ネットワークサービスが忙しいため、後で再試行してください」という意味に似ています。

3.HTTP の一般的なフィールドは何ですか？#

Host フィールド：クライアントがリクエストを送信する際に、サーバーのドメイン名を指定するために使用されます。
Content-Length フィールド：サーバーがデータを返す際に、Content-Length フィールドがあり、今回の応答データの長さを示します。HTTP プロトコルは、キャリッジリターンと改行を HTTP ヘッダーの境界として設定し、Content-Length フィールドを HTTP ボディの境界として設定します。この二つの方法は「バッファリング」の問題を解決するためにあります。
Connection フィールド：Connection フィールドは、クライアントがサーバーに「HTTP 長接続」メカニズムを使用するよう要求する際に最もよく使用されます。他のリクエストを再利用するためです。HTTP/1.1 バージョンのデフォルト接続はすべて長接続ですが、古いバージョンの HTTP と互換性を持たせるために、Connection ヘッダーの値を Keep-Alive に指定する必要があります。
Content-Type フィールド：Content-Type フィールドは、サーバーが応答する際に、クライアントに今回のデータがどの形式であるかを知らせるために使用されます。
Content-Encoding フィールド：Content-Encoding フィールドは、データの圧縮方法を示します。サーバーが返すデータがどの圧縮形式を使用しているかを示します gzip

4.GET と POST#

GET メソッドは安全かつ冪等です。なぜなら、それは「読み取り専用」操作であり、何度操作してもサーバー上のデータは安全であり、毎回の結果は同じだからです。したがって、GET リクエストのデータはキャッシュすることができ、このキャッシュはブラウザ自体に（ブラウザがリクエストを発信するのを完全に回避する）することも、プロキシ（nginx など）にすることもできます。また、ブラウザでは GET リクエストをブックマークとして保存することができます。
POST は「データの追加または提出」の操作であり、サーバー上のリソースを変更するため、安全ではありません。また、データを複数回提出すると、複数のリソースが作成されるため、冪等ではありません。したがって、ブラウザは一般的に POST リクエストをキャッシュしませんし、POST リクエストをブックマークとして保存することもできません。

5.HTTP キャッシュ#

1. 強制キャッシュ#

強制キャッシュは、以下の二つの HTTP レスポンスヘッダー（Response Header）フィールドを利用して実現されます。これらは、リソースがクライアントにキャッシュされる有効期限を示します：

Cache-Control は相対的な時間です；
Expires は絶対的な時間です；

Cache-Control の優先度は Expires よりも高いです。
プロセスは以下の通りです：

ブラウザが初めてサーバーリソースにアクセスするリクエストを行うと、サーバーはこのリソースを返す際に、レスポンスヘッダーに Cache-Control を追加し、Cache-Control に有効期限の大きさを設定します；
ブラウザが再度サーバー内のリソースにアクセスするリクエストを行うと、リクエストリソースの時間と Cache-Control に設定された有効期限の大きさを比較して、そのリソースが期限切れかどうかを計算します。期限切れでなければ、そのキャッシュを使用し、そうでなければサーバーに再リクエストします；
サーバーが再度リクエストを受け取ると、再びレスポンスヘッダーの Cache-Control を更新します。

2. 協議キャッシュ#

リクエストのレスポンスコードが 304 で、これはブラウザにローカルキャッシュのリソースを使用できることを知らせるもので、通常、このサーバーがクライアントにキャッシュを使用できるかどうかを通知する方法を協議キャッシュと呼びます。

第一の方法：リクエストヘッダーの If-Modified-Since フィールドとレスポンスヘッダーの Last-Modified フィールドを使用します。これらのフィールドの意味は：

レスポンスヘッダーの Last-Modified：このレスポンスリソースの最終変更時間を示します；
リクエストヘッダーの If-Modified-Since：リソースが期限切れになったとき、レスポンスヘッダーに Last-Modified の宣言があることを発見し、再度リクエストを行う際に Last-Modified の時間を持参します。サーバーがリクエストを受け取ると、If-Modified-Since があれば、リクエストされたリソースの最終変更時間（Last-Modified）と比較します。最終変更時間が新しい（大きい）場合、リソースが再度変更されたことを示し、最新のリソースを返します。HTTP 200 OK；最終変更時間が古い（小さい）場合、リソースに新しい変更がないことを示し、HTTP 304 でキャッシュを使用します。

第二の方法：リクエストヘッダーの If-None-Match フィールドとレスポンスヘッダーの ETag フィールドを使用します。これらのフィールドの意味は：

レスポンスヘッダーの Etag：レスポンスリソースの一意の識別子；
リクエストヘッダーの If-None-Match：リソースが期限切れのとき、ブラウザがレスポンスヘッダーに Etag があることを発見し、再度サーバーにリクエストを行う際に、リクエストヘッダーの If-None-Match 値を Etag の値に設定します。サーバーがリクエストを受け取ると、比較を行い、リソースが変更されていなければ 304 を返し、リソースが変更されていれば 200 を返します。

ETag と Last-Modified フィールド情報をサーバーに持参した場合、ETag の優先度が高くなります。

なぜ ETag の優先度が高いのか？それは ETag が Last-Modified のいくつかの難しい問題を解決できるからです：

ファイルの内容を変更しない場合でも、ファイルの最終変更時間が変わることがあり、これによりクライアントはそのファイルが変更されたと認識し、再度リクエストを行うことになります；
一部のファイルは秒単位で変更されることがあり、If-Modified-Since が検出できる粒度は秒単位ですが、ETag を使用することで、クライアントが 1 秒以内に何度も更新できることが保証されます；
一部のサーバーはファイルの最終変更時間を正確に取得できません。

2.HTTP と HTTPS#

1.HTTP と HTTPS の違いは何ですか？#

HTTP は超テキスト転送プロトコルであり、情報は平文で転送され、安全リスクの問題があります。HTTPS は HTTP の不安全な欠陥を解決し、TCP と HTTP のネットワーク層の間に SSL/TLS セキュリティプロトコルを追加することで、メッセージを暗号化して転送できるようにします。
HTTP 接続の確立は比較的簡単で、TCP の三回のハンドシェイクの後に HTTP メッセージの転送が行われます。一方、HTTPS は TCP の三回のハンドシェイクの後に、SSL/TLS のハンドシェイクプロセスを行う必要があり、暗号化メッセージの転送に入ります。
両者のデフォルトポートは異なり、HTTP のデフォルトポート番号は 80、HTTPS のデフォルトポート番号は 443 です。
HTTPS プロトコルは、CA（証明書認証機関）にデジタル証明書を申請する必要があり、サーバーのアイデンティティが信頼できることを保証します。

2.HTTPS は HTTP のどの問題を解決しましたか？#

HTTP は平文で転送されるため、以下の三つのリスクが存在します：

盗聴リスク、例えば通信リンク上で通信内容を取得でき、ユーザーの情報が漏洩しやすい。
改ざんリスク、例えば強制的にゴミ広告を埋め込むこと、視覚的な汚染、ユーザーの目が悪くなる可能性がある。
なりすましリスク、例えば淘宝ウェブサイトを装うこと、ユーザーの金銭が失われやすい。

HTTPS は上記の三つのリスクをどのように解決しますか？

混合暗号化方式を使用して情報の機密性を実現し、盗聴のリスクを解決します。
ハッシュアルゴリズムを使用して完全性を実現し、データに一意の「指紋」を生成し、指紋はデータの完全性を検証するために使用され、改ざんのリスクを解決します。
サーバーの公開鍵をデジタル証明書に含めることで、なりすましのリスクを解決します。

混合暗号化#

HTTPS は対称暗号化と非対称暗号化を組み合わせた「混合暗号化」方式を採用しています：

通信確立前に非対称暗号化方式で「セッションキー」を交換し、その後は非対称暗号化を使用しません。
通信中はすべて対称暗号化の「セッションキー」方式で平文データを暗号化します。

「混合暗号化」方式を採用する理由：

対称暗号化は一つの鍵を使用し、計算速度が速く、鍵は秘密にする必要がありますが、安全な鍵交換ができません。
非対称暗号化は二つの鍵を使用します：公開鍵と秘密鍵。公開鍵は自由に配布でき、秘密鍵は秘密にする必要があり、鍵交換の問題を解決しますが、速度は遅いです。

ハッシュアルゴリズム + デジタル署名#

送信内容が改ざんされないことを保証するために、内容の「指紋」を計算し、その指紋を内容と一緒に相手に送信します。
相手が受け取った後、まず内容の「指紋」を計算し、送信者が送った「指紋」と比較します。「指紋」が同じであれば、内容は改ざんされていないことを示し、そうでなければ内容が改ざんされたと判断できます。
コンピュータではハッシュアルゴリズム（ハッシュ関数）を使用して内容のハッシュ値、つまり内容の「指紋」を計算します。このハッシュ値は一意であり、ハッシュ値から内容を推測することはできません。
ハッシュアルゴリズムを使用することで、内容が改ざんされないことを保証できますが、「内容 + ハッシュ値」が中間者によって置き換えられないことを保証することはできません。なぜなら、ここにはクライアントが受け取ったメッセージがサーバーからのものであるかどうかの証明が欠けているからです。
このような状況を避けるために、コンピュータでは非対称暗号化アルゴリズムを使用します。二つの鍵があります：

一つは公開鍵で、これはすべての人に公開できます；
もう一つは秘密鍵で、これは本人が管理し、漏洩してはいけません。
公開鍵で暗号化し、秘密鍵で復号化します。この目的は、内容の転送の安全性を保証することです。なぜなら、公開鍵で暗号化された内容は他の人が復号化できず、秘密鍵を持つ人だけが実際の内容を復号化できるからです；
秘密鍵で暗号化し、公開鍵で復号化します。この目的は、メッセージがなりすましされないことを保証することです。なぜなら、秘密鍵は漏洩できないため、公開鍵が秘密鍵で暗号化された内容を正常に復号化できる場合、そのメッセージは秘密鍵を持つ人から送信されたことを証明できます。

したがって、非対称暗号化の用途は主に「秘密鍵で暗号化し、公開鍵で復号化」することでメッセージのアイデンティティを確認することです。私たちが一般に言うデジタル署名アルゴリズムは、この方法を使用していますが、秘密鍵で暗号化される内容は内容そのものではなく、内容のハッシュ値です。

デジタル証明書#

身分証明のプロセスが欠けている場合、万が一公開鍵が偽造されていたらどうなるのでしょう？

権威ある機関 CA（デジタル証明書認証機関）を通じて、サーバーの公開鍵をデジタル証明書（デジタル証明書認証機関が発行）に含めます。証明書が信頼できる限り、公開鍵も信頼できます。

3.HTTPS はどのように接続を確立しますか？その間に何が交互に行われましたか？#

TLS の「ハンドシェイク段階」では四回の通信が行われ、異なる鍵交換アルゴリズムが使用されます。TLS ハンドシェイクプロセスは異なる場合があります。現在一般的に使用されている鍵交換アルゴリズムは二つあります：RSA アルゴリズムと ECDHE アルゴリズム。
TLS プロトコルの詳細なプロセス：

ClientHello
最初に、クライアントがサーバーに暗号通信リクエストを発信します、つまり ClientHello リクエストです。
このステップでは、クライアントは主にサーバーに以下の情報を送信します：
（1）クライアントがサポートする TLS プロトコルバージョン、例えば TLS 1.2 バージョン。
（2）クライアントが生成したランダム数（Client Random）、後で「セッションキー」を生成する条件の一つとして使用されます。
（3）クライアントがサポートする暗号スイートのリスト、例えば RSA 暗号アルゴリズム。
SeverHello
サーバーがクライアントのリクエストを受け取った後、クライアントに応答を発信します、つまり SeverHello です。サーバーの応答内容は以下の通りです：
（1）TLS プロトコルバージョンの確認、ブラウザがサポートしていない場合は暗号通信を終了します。
（2）サーバーが生成したランダム数（Server Random）、これも後で「セッションキー」を生成する条件の一つとして使用されます。
（3）確認された暗号スイートのリスト、例えば RSA 暗号アルゴリズム。
（4）サーバーのデジタル証明書。
クライアントの応答
クライアントはサーバーの応答を受け取った後、まずブラウザまたはオペレーティングシステム内の CA 公開鍵を使用して、サーバーのデジタル証明書の真実性を確認します。
証明書に問題がなければ、クライアントはデジタル証明書からサーバーの公開鍵を取り出し、それを使用してメッセージを暗号化し、サーバーに以下の情報を送信します：
（1）ランダム数（pre-master key）。このランダム数はサーバーの公開鍵で暗号化されます。
（2）暗号通信アルゴリズム変更通知、以降の情報は「セッションキー」で暗号化通信されることを示します。
（3）クライアントハンドシェイク終了通知、クライアントのハンドシェイク段階が終了したことを示します。この項目は、以前のすべての内容の発生データを要約し、サーバーの検証に供します。
上記の第一項のランダム数は、ハンドシェイク段階の第三のランダム数であり、サーバーに送信されるため、このランダム数はクライアントとサーバーの両方で同じです。
サーバーとクライアントはこの三つのランダム数（Client Random、Server Random、pre-master key）を持ち、次に双方が協議した暗号アルゴリズムを使用して、今回の通信の「セッションキー」を生成します。
サーバーの最終応答
サーバーはクライアントの第三のランダム数（pre-master key）を受け取った後、協議した暗号アルゴリズムを使用して今回の通信の「セッションキー」を計算します。
次に、クライアントに最後の情報を送信します：
（1）暗号通信アルゴリズム変更通知、以降の情報は「セッションキー」で暗号化通信されることを示します。
（2）サーバーハンドシェイク終了通知、サーバーのハンドシェイク段階が終了したことを示します。この項目は、以前のすべての内容の発生データを要約し、クライアントの検証に供します。

これで、TLS のハンドシェイク段階はすべて終了しました。次に、クライアントとサーバーは暗号通信に入り、通常の HTTP プロトコルを使用しますが、「セッションキー」で内容が暗号化されます。

RSA アルゴリズム#

上記の接続プロセスは RSA アルゴリズムを使用して接続を確立するプロセスです。これはクライアントとサーバー間の安全な通信を保証しますが、依然として欠陥があります：
RSA 鍵協議アルゴリズムの最大の問題は前方秘匿性をサポートしていないことです。
なぜなら、クライアントがランダム数（対称暗号鍵を生成する条件の一つ）をサーバーに送信する際に公開鍵で暗号化され、サーバーは受け取った後、秘密鍵で復号化してランダム数を取得するからです。したがって、サーバーの秘密鍵が漏洩した場合、過去に第三者に傍受されたすべての TLS 通信の暗号文が解読されてしまいます。
この問題を解決するために、後に ECDHE 鍵協議アルゴリズムが登場しました。現在ほとんどのウェブサイトが使用しているのは ECDHE 鍵協議アルゴリズムです。

ECDHE アルゴリズム#

ECDHE 鍵協議アルゴリズムは DH アルゴリズムの進化版であるため、まず DH アルゴリズムから説明します。

DH アルゴリズム#

DH アルゴリズムは非対称暗号アルゴリズムであり、鍵交換に使用できます。このアルゴリズムの核心的な数学的思想は離散対数です。
離散対数は対数演算の基礎に「剰余演算」を加えたもので、余りを取ることを意味します。プログラミング言語の演算子は「%」であり、mod で表すこともできます。離散対数の概念は以下の図の通りです：

上図の底数 a とモジュラス p は離散対数の共通パラメータであり、公開されています。b は真数、i は対数です。対数がわかれば、上記の公式を使用して真数を計算できます。しかし逆に、真数がわかっても対数を推測することは非常に難しいです。
特に、モジュラス p が非常に大きな素数である場合、底数 a と真数 b がわかっても、現在のコンピュータの計算能力では離散対数を計算することはほぼ不可能です。これが DH アルゴリズムの数学的基礎です。

上図のように：a と b はそれぞれの秘密鍵であり、A と B はそれぞれの公開鍵であり、G P は公開情報です。この K は小紅と小明の間で使用される対称暗号鍵であり、セッション鍵として使用できます。

DHE アルゴリズム#

E は ephemeral（一時的）を意味し、双方の秘密鍵は毎回の鍵交換通信時にランダムに生成され、一時的です。
このように、もし優れたハッカーがある通信プロセスの秘密鍵を解読した場合でも、他の通信プロセスの秘密鍵は依然として安全です。なぜなら、各通信プロセスの秘密鍵は互いに無関係であり、独立しているからです。これにより「前方安全」が保証されます。

ECDHE アルゴリズム#

DHE アルゴリズムは計算性能が良くないため、大量の乗算を行う必要があるため、DHE アルゴリズムの性能を向上させるために、現在広く使用されている鍵交換アルゴリズムである ECDHE アルゴリズムが登場しました。

ECDHE アルゴリズムは DHE アルゴリズムの基礎の上に、ECC 楕円曲線の特性を利用して、より少ない計算量で公開鍵と最終的なセッション鍵を計算できます。

小紅と小明が ECDHE 鍵交換アルゴリズムを使用するプロセス：

双方は事前にどの楕円曲線を使用するか、曲線上の基点 G を決定します。これらの二つのパラメータはすべて公開されています；
双方はそれぞれランダムな数を生成して秘密鍵 d とし、基点 G と掛け算して公開鍵 Q（Q = dG）を得ます。この時、小紅の公私鍵は Q1 と d1、小明の公私鍵は Q2 と d2 です；
双方はそれぞれの公開鍵を交換し、最終的に小紅は点（x1，y1） = d1Q2 を計算し、小明は点（x2，y2） = d2Q1 を計算します。楕円曲線上では乗法の交換法則と結合法則が成り立つため、d1Q2 = d1d2G = d2d1G = d2Q1 となります。したがって、双方の x 座標は同じであり、これが共有鍵、つまりセッション鍵です。

このプロセスでは、双方の秘密鍵はすべてランダムで一時的に生成され、公開されていません。公開情報（楕円曲線、公開鍵、基点 G）から楕円曲線上の離散対数（秘密鍵）を計算することは非常に難しいです。

ハンドシェイクプロセス#

TLS 第一次ハンドシェイク
クライアントは最初に「Client Hello」メッセージを発信します。このメッセージには、クライアントが使用する TLS バージョン番号、サポートする暗号スイートのリスト、生成したランダム数（Client Random）が含まれます。
TLS 第二次ハンドシェイク
サーバーはクライアントの「挨拶」を受け取った後、同様に「Server Hello」メッセージを返します。このメッセージには、サーバーが確認した TLS バージョン番号、ランダム数（Server Random）が含まれ、クライアントの暗号スイートリストから適切な暗号スイートが選択されます。
次に、サーバーは自分のアイデンティティを証明するために「Certificate」メッセージを送信し、証明書をクライアントに送信します。
このステップは RSA ハンドシェイクプロセスとは大きく異なります。なぜなら、サーバーは ECDHE 鍵協議アルゴリズムを選択したため、証明書を送信した後に「Server Key Exchange」メッセージを送信します。
このプロセスでサーバーは三つのことを行います：

x25519 という名前の楕円曲線を選択し、楕円曲線の基点 G も決定します。これらはすべてクライアントに公開されます；
ランダム数を生成してサーバーの楕円曲線の秘密鍵とし、ローカルに保持します；
基点 G と秘密鍵を使用してサーバーの楕円曲線の公開鍵を計算し、これをクライアントに公開します。

この楕円曲線の公開鍵が第三者によって改ざんされないことを保証するために、サーバーは RSA 署名アルゴリズムを使用してサーバーの楕円曲線の公開鍵に署名します。
その後、「Server Hello Done」メッセージが送信され、サーバーはクライアントに「これが私が提供する情報です。挨拶は終了しました」と示します。
TLS 第三次ハンドシェイク
クライアントはサーバーの証明書を受け取った後、当然証明書が合法であるかを確認します。証明書が合法であれば、サーバーのアイデンティティに問題はありません。証明書の確認プロセスは証明書チェーンを逐次確認し、証明書の真実性を確認し、証明書の公開鍵で署名を確認します。これによりサーバーのアイデンティティが確認され、問題がなければ次に進むことができます。
クライアントはランダム数を生成してクライアントの楕円曲線の秘密鍵とし、サーバーが前に提供した情報を基にクライアントの楕円曲線の公開鍵を生成し、「Client Key Exchange」メッセージをサーバーに送信します。
最終的なセッション鍵は「クライアントのランダム数 + サーバーのランダム数 + x（ECDHE アルゴリズムで計算された共有鍵）」の三つの材料から生成されます。
セッション鍵を計算した後、クライアントは「Change Cipher Spec」メッセージを送信し、サーバーに以降は対称アルゴリズムで暗号化通信を行うことを通知します。
次に、クライアントは「Encrypted Handshake Message」メッセージを送信し、以前に送信したデータを要約し、対称鍵で暗号化してサーバーに検証を行わせ、今回生成された対称鍵が正常に使用できるかを確認します。
TLS 第四次ハンドシェイク
最後に、サーバーも同様の操作を行い、「Change Cipher Spec」と「Encrypted Handshake Message」メッセージを送信します。双方が暗号化と復号化が問題ないことを確認すれば、ハンドシェイクは正式に完了します。これにより、暗号化された HTTP リクエストとレスポンスを正常に送受信できるようになります。

4.HTTPS のアプリケーションデータはどのように完全性を保証しますか？#

TLS は実装上、ハンドシェイクプロトコルとレコードプロトコルの二層に分かれています：

TLS ハンドシェイクプロトコルは、前述の TLS 四回ハンドシェイクプロセスであり、暗号アルゴリズムの協議と対称鍵の生成を担当し、以降はこの鍵を使用してアプリケーションデータ（つまり HTTP データ）を保護します；
TLS レコードプロトコルはアプリケーションデータを保護し、その完全性と出所を検証します。したがって、HTTP データの暗号化はレコードプロトコルを使用します；

TLS レコードプロトコルは主にメッセージ（HTTP データ）の圧縮、暗号化およびデータの認証を担当し、プロセスは以下の図の通りです：

具体的なプロセスは以下の通りです：

まず、メッセージは複数の短いセグメントに分割され、それぞれのセグメントが圧縮されます。
次に、圧縮されたセグメントにはメッセージ認証コード（MAC 値、これはハッシュアルゴリズムによって生成されます）が追加されます。これは完全性を保証し、データの認証を行うためです。メッセージ認証コードの MAC 値を追加することで、改ざんを識別できます。同時に、再生攻撃を防ぐために、メッセージ認証コードを計算する際には、セグメントのエンコーディングも追加されます。
次に、圧縮されたセグメントとメッセージ認証コードは一緒に対称鍵で暗号化されます。
最後に、上記の暗号化されたデータにデータタイプ、バージョン番号、圧縮後の長さから構成されるヘッダーが追加され、最終的なメッセージデータとなります。

レコードプロトコルが完了した後、最終的なメッセージデータはトランスポート制御プロトコル (TCP) 層に渡されて転送されます。

5.HTTPS セキュリティの中間者サーバー#

HTTPS は本当に安全ですか？
クライアントがブラウザを通じてサーバーに HTTPS リクエストを発信すると、「偽の基地局」によって「中間者サーバー」に転送されます。したがって、クライアントは「中間者サーバー」と TLS ハンドシェイクを完了し、その後この「中間者サーバー」が本当のサーバーと TLS ハンドシェイクを完了します。

結論：中間者サーバーとクライアントは TLS ハンドシェイクプロセス中に、自ら偽造した証明書をブラウザに送信しました。この偽造された証明書はブラウザ（クライアント）によって不正であると認識され、ユーザーにその証明書に問題があることを警告します。
もしユーザーが中間者サーバーの証明書を受け入れた場合、中間者はブラウザが発信した HTTPS リクエスト内のデータを解読でき、またサーバーがブラウザに応答した HTTPS レスポンスデータも解読できます。つまり、中間者はブラウザとサーバー間の HTTPS リクエストとレスポンスのデータを「盗み見る」ことができるのです。
したがって、HTTPS プロトコル自体には現在までに何の脆弱性もありません。たとえ中間者攻撃が成功したとしても、本質的にはクライアントの脆弱性（ユーザーが続行をクリックしたり、悪意のある偽造ルート証明書をインポートされたりすること）を利用したものであり、HTTPS が不十分に安全であるわけではありません。

3.HTTP/1.1、HTTP/2、HTTP/3 の進化#

1. HTTP/1.1 は HTTP/1.0 に比べてどのような性能が向上しましたか？#

接続方式 : HTTP/1.0 は短接続で、HTTP/1.1 は長接続をサポートします。
ステータス応答コード : HTTP/1.1 では大量のステータスコードが新たに追加され、エラー応答ステータスコードだけでも 24 種類が追加されました。例えば、100 (Continue)—— 大きなリソースのリクエスト前の予熱リクエスト、206 (Partial Content)—— 範囲リクエストの識別コード、409 (Conflict)—— リクエストが現在のリソースの規定と衝突していること、410 (Gone)—— リソースが永久に移転され、既知の転送先がないこと。
キャッシュメカニズム : HTTP/1.0 では主にヘッダーの If-Modified-Since, Expires をキャッシュ判断の基準として使用していましたが、HTTP/1.1 ではエンティティタグ、If-Unmodified-Since、If-Match、If-None-Match など、より多くの選択肢を提供するキャッシュヘッダーを導入しました。
帯域幅：HTTP/1.0 では、クライアントが特定のオブジェクトの一部だけを必要とする場合でも、サーバーが全体を送信し、断点再開機能をサポートしていない現象がありました。HTTP/1.1 では、リクエストヘッダーに range ヘッダーを導入し、リソースの一部だけをリクエストすることができ、返すコードは 206（Partial Content）となります。これにより、開発者は帯域幅と接続を十分に活用できるようになります。
Host ヘッダー（Host Header）処理 : HTTP/1.1 では Host ヘッダーを導入し、同じ IP アドレス上で複数のドメイン名をホスティングできるようにし、仮想ホスト機能をサポートします。一方、HTTP/1.0 では Host ヘッダーが存在せず、仮想ホストを実現できません。

2. HTTP/2.0 は HTTP/1.1 に比べてどのような性能が向上しましたか？#

IO マルチプレクシング（Multiplexing）：HTTP/2.0 は同じ接続上で複数のリクエストとレスポンスを同時に転送できます（HTTP/1.1 の長接続のアップグレード版と見なすことができます）。HTTP/1.1 では直列方式を使用し、各リクエストとレスポンスは独立した接続を必要とします。これにより、HTTP/2.0 は複数のリクエストを処理する際により効率的で、ネットワーク遅延を減少させ、性能を向上させます。
バイナリフレーム（Binary Frames）：HTTP/2.0 はデータ転送にバイナリフレームを使用しますが、HTTP/1.1 はテキスト形式のメッセージを使用します。バイナリフレームはよりコンパクトで効率的であり、転送データ量と帯域幅消費を減少させます。
ヘッダー圧縮（Header Compression）：HTTP/1.1 はボディ圧縮をサポートしていますが、ヘッダー圧縮はサポートしていません。HTTP/2.0 はヘッダー圧縮をサポートし、ネットワークオーバーヘッドを減少させます。
サーバープッシュ（Server Push）：HTTP/2.0 はサーバープッシュをサポートし、クライアントがリソースをリクエストする際に、他の関連リソースを一緒にプッシュすることで、クライアントのリクエスト回数と遅延を減少させます。一方、HTTP/1.1 ではクライアントが自分でリクエストを送信して関連リソースを取得する必要があります。

3. HTTP/3 はどのような最適化を行いましたか？#

転送プロトコル：HTTP/2.0 は TCP プロトコルに基づいて実装されていますが、HTTP/3.0 は QUIC（Quick UDP Internet Connections）プロトコルを追加して信頼性のある転送を実現し、TLS/SSL と同等のセキュリティを提供し、接続と転送の遅延を低減します。QUIC は UDP のアップグレード版と見なすことができ、その基礎の上に暗号化、再送信などの多くの機能が追加されています。HTTP/3.0 は以前は HTTP-over-QUIC と呼ばれており、この名前からもわかるように、HTTP/3 の最大の改造は QUIC を使用することです。
接続確立：HTTP/2.0 は従来の TCP 三回ハンドシェイクプロセスを経る必要があります（一般的に 3 回の RTT）。QUIC プロトコルの特性により、HTTP/3.0 は TCP 三回ハンドシェイクの遅延を回避でき、最初の接続時にデータを送信することができます（0 RTT、ゼロ往復時間）。
ヘッダー阻塞：HTTP/2.0 は複数のリクエストを一つの TCP 接続でマルチプレクシングしますが、パケットロスが発生するとすべての HTTP リクエストがブロックされます。QUIC プロトコルの特性により、HTTP/3.0 はある程度ヘッダー阻塞（Head-of-Line blocking、略称：HOL blocking）問題を解決します。一つの接続が複数の異なるデータストリームを確立し、これらのデータストリームは独立して互いに影響を与えません。特定のデータストリームでパケットロスが発生しても、そのデータストリームには影響がありません（本質的にはマルチプレクシング + ポーリングです）。
エラー回復：HTTP/3.0 はより優れたエラー回復メカニズムを持ち、パケットロスや遅延などのネットワーク問題が発生した場合、より迅速に回復と再送信を行うことができます。一方、HTTP/2.0 は TCP のエラー回復メカニズムに依存しています。
セキュリティ：HTTP/2.0 と HTTP/3.0 はセキュリティに高い要求を持ち、暗号化通信をサポートしていますが、実装には違いがあります。HTTP/2.0 は TLS プロトコルを使用して暗号化しますが、HTTP/3.0 は QUIC プロトコルに基づいており、内蔵の暗号化と認証メカニズムを含んでおり、より強力なセキュリティを提供できます。