[ネットワーク原則 3] アプリケーション層プロトコル HTTP および HTTPS

HTTP

HTTPとは何ですか

HTTP: ハイパーテキスト転送プロトコル。これは広く使用されている should-layer プロトコルです。

いわゆる「ハイパーテキスト」の意味は、送信されるコンテンツがテキスト (html、css など) だけでなく、画像、ビデオ、オーディオ、その他のバイナリ データなどの他のリソースも含まれることです。

完全なアプリケーションはフロントエンド + バックエンドで構成され、フロントエンドとバックエンド間の通信は HTTP に依存します。これは、消費者がオンラインで物を購入するのと同じです。販売者と購入者の間に宅配会社が必要であり、HTTP が宅配会社です。リクエスト メソッド GET/POST は、さまざまな種類の宅配便タイプ (標準宅配便、速達宅配便など) に相当します。 .) 速達)。

作業過程

ブラウザに「URL」を入力すると、ブラウザは対応するサーバーにHTTP リクエスト（リクエスト）を送信します。リクエストを受信した相手のサーバーは、計算・処理を経てHTTP レスポンス（応答）を返します。

F12 で Chrome の開発者ツールを開き、[ネットワーク] タブに切り替えます。次に、ページを更新して、以下に示すような効果を確認します。各レコードは HTTP リクエスト/レスポンスです。

プロトコル形式

HTTP はテキスト形式のプロトコルです。Chrome 開発者ツールまたは Fiddler を使用してパケットをキャプチャし、HTTP リクエスト/レスポンスの詳細を分析できます。左側のウィンドウにはすべての HTTP リクエスト/レスポンスが表示され、リクエストを選択して詳細を表示でき
ます
。右上 HTTP リクエストのメッセージ内容を表示（Raw タブに切り替えて詳細なデータ形式を表示） 右下
HTTP レスポンスのメッセージ内容を表示（Raw タブに切り替えて詳細なデータ形式を表示）

合意

HTTPリクエスト

上記のプロトコル コンテンツに対して http リクエストを分析します。

方法

GET メソッド: GET は最も一般的に使用される HTTP メソッドであり、サーバー上のリソースを取得するためによく使用されます。ブラウザに URL を直接入力すると、ブラウザは GET リクエストを送信します
POST メソッド: POST メソッドも一般的なメソッドで、主にユーザーが入力したデータをサーバー (ログイン ページなど) に送信するために使用されます。 ）。

GET と POST の違い:
① GET で要求されたデータは URL を介して渡されます。つまり、データは URL の後ろに ? で区切られ、パラメーターは & 記号で区切られます。したがって、GET リクエストには送信データのサイズに制限があり、通常は数千文字以内です。POSTリクエストはHTTPリクエストのリクエストボディにデータを入れて送信するもので、サイズ制限がなく大量のデータを送信することができます。
②GETリクエストで送信されるデータは平文のため、傍受・改ざんが容易です。POST リクエストによって送信されるデータはリクエストボディに配置されるため、比較的プライベートです。
③GETリクエストをキャッシュできるため、ブラウザが再度同じURLをリクエストした場合、キャッシュから直接データを取得することができ、アクセスを高速化します。ただし、データを送信するたびにサーバーの状態が変化する可能性があるため、POST リクエストはキャッシュできません。
④GETで要求したデータはブラウザの履歴やサーバーログに保存されるため、悪意のあるプログラムに悪用されやすくなります。ただし、POST リクエストは履歴やサーバー ログに保存されないため、比較的安全です。

URL

私たちが通常「URL」と呼ぶものは、実際には URL (Uniform Resource Locator ユニフォーム リソース ロケーター) です。インターネット上のすべてのファイルには一意の URL があり、ファイルの場所とブラウザがそれをどのように処理するかを示す情報が含まれています。

http : プロトコル スキーム名。一般的なものは http と https ですが、その他のタイプもあります (たとえば、mysql にアクセスするときに使用される jdbc:mysql)。

user:pass : ログイン情報 現在のWebサイトの本人認証はURLによる認証が原則行われなくなり、省略されることが一般的となります。
www.example.jp : サーバーアドレス これは「ドメイン名」であり、DNS システムを通じて特定の IP アドレスに解決されます (IP アドレスは ping コマンドで確認できます)。
80 : ポート番号。ポート番号を省略すると、ブラウザはプロトコルの種類に応じて使用するポートを自動的に決定します。たとえば、http プロトコルはデフォルトでポート 80 を使用し、https プロトコルはデフォルトでポート 443 を使用します。 dir/index.htm:
階層を含むファイル パス。
? : パラメータの開始記号
uid=1 : クエリ文字列 (クエリ文字列) 基本的にはキーと値のペア構造です キーと値のペアは & で区切られます キーと値は = で区切られます この部分はクエリ文字列とも呼ばれ、その中のキーや値の値や数はプログラマが完全に合意することで、必要な情報をカスタマイズしてサーバーに送信することができます。
ch1 : フラグメント識別子。主にページをジャンプしたり、タグをすばやく見つけたりするために使用されます。

URLのエンコードとデコード

/ ? : のような文字は URL によって特別な意味として認識されているため、これらの文字はランダムに出現することはできません。たとえば、パラメータでこれらの特殊文字が必要な場合は、最初に特殊文字をエスケープする必要があります。

バージョン

HTTP のバージョン番号は HTTP1.1 として広く使用されています。

リクエストヘッダー

キーと値のキーと値のペア。各キーと値のペアは 1 行を占めます。キーと値を区切るにはセミコロンを使用します。
共通ヘッダー:
Host : サーバーホストのアドレスとポートを示す
Content-Length : ボディ内のデータ長を示す
Content-Type : リクエストされたボディ内のデータ形式を示す
application/x-www-form-urlencoded : form form 送信されたデータ形式。
application/json : データは json 形式です
User-Agent (UA) : ブラウザ/オペレーティング システムの属性を示します
Referer : ページがどのページからリダイレクトされるかを示します
Cookie : Cookie はクライアントがデータを保存するためのメカニズムです。アプリケーションのシナリオは、ユーザーのログイン情報を保存することです。

ローカルCookieを削除すると、再度Webサイトにアクセスした際にログインしていないと判断されます。

セッション: どのユーザーがサーバーにアクセスしたかを識別します。
セッションはサーバー側で動作し、サーバーは現在のセッションに関連するデータを保存するために使用できるセッション オブジェクトを作成します。サーバーはセッションを保存するためのマップを維持し、キーとして sessionld を生成し、値としてセッションを生成します。

各セッション自体もマップであり、キーと値をカスタマイズできます。サーバーは、応答ヘッダーの set-cookie を通じて sessionld をクライアントに返します。クライアントは、リクエストのたびに sessionld をサーバーに送信します。サーバーは、どのクライアントがリクエストを送信したかを区別し、Map から目的のセッションを取得できます。サーバーによって維持され、現在のセッションのために保存されたデータ。

ワークフロー: ユーザーがログインすると、サーバーはセッションに新しいレコードを追加し、sessionId/トークンをクライアントに返します (たとえば、HTTP 応答の Set-Cookie フィールドを通じて)。後でクライアントがサーバーにリクエストを送信するときは、リクエストに sessionld/token を含める必要があります。(例: HTTP リクエストの Cookie フィールドに含めます) サーバーはリクエストを受信すると、リクエスト内の sessionId/token に従ってセッション情報内の対応するユーザー情報を取得し、以降の操作を続行します。

リクエストボディ

プログラマがパラメータを渡すことに関連します。

HTTPレスポンス

ステータスコード

ページへのアクセス結果が成功か失敗か、その他かを示します。
200:これは最も一般的なステータス コードで、アクセスが成功したことを示します。
404 Not Found : リソースが見つかりませんでした。ブラウザは相手サーバー上のリソースにアクセスするために URL を入力しますが、その URL で特定されるリソースが存在しない場合は 404 が表示されます。
403 Forbidden : アクセスが拒否されていることを示します。通常、一部のページでは、ユーザーがアクセスするには特定の権限が必要です (ログイン後のみ)。ユーザーがログインせずに直接アクセスすると、403 が表示されやすくなります。
500 Internal Server Error : サーバーに内部エラーがあります。通常、このステータス コードは、コード実行プロセス中にサーバーが何らかの特殊な状況に遭遇した場合 (サーバーが異常クラッシュした場合) に生成されます。
504 ゲートウェイ タイムアウト: サーバーの負荷が比較的重い場合、サーバーは 1 つのリクエストを処理するのに長い時間がかかり、タイムアウトが発生する可能性があります。
302 一時的に移動: 一時的なリダイレクト、一時的な移動。301と同じですね。ただし、リソースは一時的に移動されるだけです。クライアントは、元の URI を引き続き使用する必要があります。
301 Moved Permanently : 永続的なリダイレクト。ブラウザがこの応答を受信すると、後続のリクエストは自動的に新しいアドレスに変更されます。301 はまた、Location フィールドを使用してリダイレクト先の新しいアドレスを示します。

応答ヘッダー

レスポンスヘッダの基本的な形式はリクエストヘッダと同様であり、Content-TypeやContent-Lengthなどの属性の意味もリクエストのものと一致します。
レスポンスにおけるContent-Typeの共通値は以下の通りです。
1. text/html : 本文データ形式はHTML
2. text/css： 本文データ形式はCSS
3. application/javascript : 本文データ形式はJavaScript
4. application /json : 本体データの形式は JSON です

HTTPS

HTTPプロトコルの内容は平文で送信されるため、送信中に改ざんされるケースがあります。HTTPS もアプリケーション層プロトコルであり、HTTP プロトコルに基づいた暗号化層が導入されています。

HTTPS実行処理

クライアントは HTTPS を使用してサーバーにアクセスします。
サーバーはデジタル証明書を返し、非対称暗号化を使用してクライアントに公開キーを生成します (秘密キーはサーバー自体によって保持されます)。
クライアントはデジタル証明書が有効であるかどうかを検証し、無効な場合はアクセスを終了します。有効な場合は、 ① 対称暗号化を使用して共有
秘密鍵を生成します。
② 対称暗号化された共有秘密鍵を使用してデータを暗号化します。
③ 非対称暗号化を使用します。公開鍵暗号化（対称暗号化生成） 共有秘密鍵;
④ 暗号化された秘密鍵とデータをサーバーに送信します。
サーバー側は、秘密キーを使用してクライアントの共有秘密キー (対称暗号化を使用して生成) を復号​​化し、その共有秘密キーを使用してデータの特定のコンテンツを復号化します。その後、クライアントとサーバーは、共有秘密キーを使用して暗号化されたコンテンツと対話します。
対称暗号化の効率は非対称暗号化の効率よりもはるかに高いため、非対称暗号化は初期段階でキーがネゴシエートされる場合にのみ使用され、その後の送信には対称暗号化が引き続き使用されます。

暗号化

暗号化とは、平文(送信する情報) に一連の変換を実行して、暗号文を生成することです。ネットワーク伝送においては、平文が直接伝送されるのではなく、暗号化された「暗号文」が伝送されるようになりました。復号化とは、暗号文に対して一連の変換を実行し、平文に復元する
ことです。暗号化と復号化のプロセスでは、このプロセスを支援するために 1 つ以上の中間データが必要になることが多く、そのようなデータはキー と呼ばれます。暗号化方式は数多くありますが、全体としては対称暗号化と非対称暗号化の2 つのカテゴリに分類できます。

対称暗号化

対称暗号化とは、実際には、同じ「鍵」を使用して平文を暗号文に暗号化し、暗号文を平文に復号することです。送信者と受信者は通信するために秘密キーを共有する必要があるため、対称暗号化アルゴリズムは機密性とパフォーマンスの点で非常に効率的になります。

しかし、サーバーは実際には同時に多くのクライアントにサービスを提供します。クライアントの数が非常に多い場合、全員が使用する秘密キーは異なっていなければなりません (同じであると、キーが拡散しやすくなり、ハッカーがそれを入手する可能性もあります)。したがって、サーバは各クライアント端末と各キーとの対応関係を維持する必要があり、これも非常に面倒である。理想的には、クライアントとサーバーが接続を確立するときに、両者がネゴシエーションして、今度はキーが何であるかを決定します。しかし、キーが平文で直接送信された場合、ハッカーはキーを取得することができます~~ この時点では、その後の暗号化操作は役に立ちません。したがって、鍵の送信も暗号化する必要があります!しかし、鍵を対称的に暗号化したい場合は、やはり「鍵の鍵」をネゴシエーションして決定する必要があり、「ニワトリとニワトリのどちらが先か」という問題になります。卵」 現時点では、鍵の送信に対称暗号化を使用することは現実的ではないため、非対称暗号化を導入する必要があります。

非対称暗号化

非対称暗号化では、「公開鍵」と「秘密鍵」と呼ばれる 2 つの鍵を使用し、送信者は受信者の公開鍵を使用して暗号化し、受信者は秘密鍵を使用して復号化します。公開鍵と秘密鍵はペアになっており、最大の欠点は演算速度が非常に遅いことであり、対称暗号化に比べてはるかに遅いです。

次に、次の疑問が再び生じます:クライアントはどのようにして公開鍵を取得するのでしょうか? クライアントは公開鍵がハッカーによって偽造されたものではないとどのように判断するのでしょうか?

証明書

クライアントとサーバーが接続を確立すると、サーバーはクライアントに証明書を返します。この証明書には先ほどの公開鍵が含まれており、Web サイトの識別情報も含まれています。
この証明書は、この Web サイトのアイデンティティとなる個人の ID カードのようなもので、HTTPS Web サイトを構築するには、CA 機関に証明書を申請する必要があります (公安局での ID カードの申請と同様)。

---

続けてください~