HTTP
- 意味: アプリケーション層で動作するハイパーテキスト転送プロトコル。
- 使用ポート: 80。
- トランスポート層プロトコル: TCP に基づきます。
- ネットワーク要求を開始するために HTTP によって使用されるメソッド: GET、POST。これら 2 つの方法の違いは次のとおりです。
- GET メソッドを使用したデータ送信は、送信されたパラメータが URL に配置され、データ漏洩につながるため安全ではありません。また、データ送信に POST メソッドを使用した場合は、POST 内のすべての操作がユーザーには見えないため、安全ではありません。
- GET メソッドで送信される URL パラメータの長さには制限がありますが、POST には制限がありません。
- GET メソッドは ASCII タイプのパラメータのみを送信できますが、POST には制限がありません。
- GET メソッドでは URL エンコードのみを使用できますが、POST では複数のエンコード メソッドを使用できます。
- GET リクエストはブラウザによってアクティブにキャッシュできますが、POST リクエストはキャッシュできないため、手動で設定する必要があります。
- GET パラメータは URL に配置され、POST パラメータはリクエストボディに配置されます。
- GETメソッドの伝送効率は高く、POSTメソッドの伝送効率は低くなります。
最初の 6 つの違いは理解しやすいですが、7 番目の違いは理解しにくいかもしれません。
GET の方が効率的なのはなぜですか?
GET では TCP パケットが 1 つだけ生成されるのに対し、POST では TCP パケットが 2 つ生成されるためです。詳細には、GET リクエストが送信されると、ブラウザーはヘッダー情報とデータを一緒に送信し、サーバーは 200 (データが正常に返された) で応答します。POST リクエストが送信されると、ブラウザーは最初にヘッダー情報を送信し、次にサーバーが 100 (リクエストが受信されたことを示す) で応答します。その後、ブラウザーはデータの送信を続け、サーバーは最終的に次のように応答します。 200 (データは正常に返されました)。GET はステップが 1 つ少ないため、消費時間が少なくなり、効率が高くなります。
HTTPリクエストメッセージのデータ構造
GET /index.jsp HTTP/1.1
Accept-Language: zh-cn
Connection: Keep-Alive
Host: www.jxsd.cn
Content-Length: 28
userName=tom&password=123456
复制代码上図のように、HTTPリクエストメッセージのデータ構造は、リクエストライン、リクエストヘッダ、空行、リクエストデータに分かれています。
リクエストライン:
- リクエストメソッドフィールド: GET、POSTなど。
- URL フィールド: アクセスされる相対値 (/index.jsp など)。
- HTTP バージョン番号フィールド: HTTP/1.1 または HTTP/1.0。
リクエストヘッダー:
- Accept-Language: ブラウザーによって受け入れられる言語タイプ。たとえば、zh-cn は簡体字中国語を意味し、zh は中国語を意味します。
- 接続: このリクエストの処理後に接続を続行するか切断するか。
- ホスト: クライアントは、このヘッダー情報を通じて、アクセスしたいホストのドメイン名をサーバーに伝えます。
- Content-Length: リクエストメッセージボディの長さを示します。
- ユーザーエージェント: ブラウザの種類。
- Accept-Charset: Unicode 文字エンコーディングを表す UTF-8 など、ブラウザーで受け入れられる文字セット。
- Accept-Encoding: ブラウザーがデコードできるエンコード方式 (gzip など)。
- 注意点: ほとんどのリクエストヘッダー情報は必要ありませんが、Content-Length は POST メソッドに使用する必要があり、Host は HTTP/1.1 に存在する必要があります。
空白行:
- 空行はリクエスト ヘッダーとリクエスト データを分離し、リクエスト ヘッダーがここで終了することをサーバーに示します。
データのリクエスト:
- リクエストメソッドが GET の場合、この項目は空でデータはありません。
- 要求されたメソッドが POST の場合、このアイテムは送信するデータを配置します。
HTTPレスポンスメッセージのデータ構造
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞
复制代码上に示したように、HTTP 応答メッセージのデータ構造には、応答行、応答ヘッダー、および応答本文が含まれます。
応答行:
- HTTP バージョン番号
- HTTPステータスコード
- ステータスコードの説明
- 一般的な HTTP ステータス コードは次のとおりです。
応答ヘッダー:
レスポンスヘッダにはサーバの基本情報やデータの説明が記述されており、サーバはこれらのデータの記述を通じてクライアントにデータの操作方法を通知します。
- 日付：世界標準時、
- Content-Type: 次のドキュメントが属する MIME タイプ (「text/html」など)。
- Content-Length: コンテンツの長さ。
- 許可: サーバーでサポートされているリクエスト メソッド (GET、POST など)
- Content-Encoding: ドキュメントのエンコード方式。
- 場所: ステータス コード 302 と組み合わせて使用され、受信者を新しい URL にリダイレクトします。ブラウザがドキュメントを受信する場所を示します。
- Expires: 返されたデータをキャッシュする期間をブラウザーに指示します。0 または -1 はキャッシュなしを意味します。
- Last-Modified: ドキュメントが最後に変更された時刻。
- 更新: 時間を秒単位で更新するようにブラウザに指示します。
- サーバー: ブラウザーにサーバーの種類を伝えます。
応答本文:
応答本文は応答のメッセージ本文です。純粋なデータの場合は純粋なデータが返されます。リクエストが HTML ページの場合は HTML コードが返されます。
HTTP 接続の確立と切断のプロセス
- TCP は、3 ウェイ ハンドシェイクを通じて接続を確立します。
- ブラウザはリクエスト メッセージとリクエスト データをサーバーに送信します。
- サーバーは応答メッセージと応答データをブラウザーに送信します。
- TCP は 4 つの波で切断されます。
概略図は次のとおりです。
HTTP ではリクエストごとに 3 ウェイ ハンドシェイクが必要ですか?
- HTTP/0.9 または HTTP/1.0 の場合、HTTP はリクエストごとに 3 ウェイ ハンドシェイクを必要とします。
- 現在使用されている HTTP/1.1 プロトコルは使用されません。クライアントとサーバー間の永続的な接続を維持するキープアライブ パラメーターをサポートしており、クライアントは定期的にハートビート パケットをサーバーに送信して、クライアントがまだアクティブであることを示します。
キープアライブ機能
- デッドノードがないか確認します。主な目的は、接続がすぐに失敗するかどうかを確認し、再接続することです。
- 非アクティブによる接続の切断を防ぎます。オペレーティング システムは、リソースを節約するために非アクティブなプロセスを解放し、キープアライブを通じて定期的にハートビート パケットを送信します。これは、オペレーティング システムに、私がアクティブであり、私を殺さないように伝えるためです。
HTTPの特徴
- 接続なし: 接続ごとに 1 つのリクエストのみが処理され、処理が完了すると接続が切断されます。
- ステートレス: クライアントからの各リクエストは独立しています。サーバーはクライアントの状態を保存しません。つまり、クライアントがサーバーに対して 2 回目のリクエストを開始した場合でも、サーバーは最初のリクエストと同じ応答を返します。
http/1.1 は永続的な接続であるのに、http の特徴の 1 つは接続がないのではないかと疑問に思う人もいるかもしれませんが、これは矛盾していますか?
- 矛盾してないよ。
- http/1.1 は永続的な接続です。つまり、http データを送信する TCP 接続は切断されず、次回 http データが送信されるときも、引き続きこの TCP 接続で実行されます。
- http の特徴はコネクションレスです。ここでのコネクションレスとは、TCP 接続が確立された後のクライアントとサーバー間の接続、つまり上記の HTTP 接続フローチャートのステップ 4 と 5 で、リクエストとレスポンスの後、接続が切断されました。
http の特徴の 1 つはステートレスですが、サーバーが特定の操作を実行するためにクライアントを識別したい場合、これは実現できるのでしょうか? と疑問に思う人もいるでしょう。
- 達成することができます。
- Cookie はユーザーのリクエストを識別するために使用できます。Cookie 属性を通じて、ブラウザがサーバーに対して 2 回目のリクエストを開始すると、サーバーはリクエスタを「認識」できます。
- Cookie の実装は次のとおりです。サーバーはブラウザを使用しているユーザーに固有の識別コードを生成し、この識別コードは応答メッセージの Set-Cookie を通じてユーザーに返されます。ブラウザの Cookie ファイルには識別コードが保存され、次回ユーザーがリクエストを開始すると、メッセージにこの値が含まれます。
HTTP/1.0 と HTTP/1.1 の違い
- HTTP/1.0 は接続ごとに 1 つの要求と応答のみを実行でき、Host フィールドはありません。
- HTTP/1.1 は接続ごとに複数のリクエストと応答を行うことができ、Host フィールドが必要です。
HTTP1.1の2つの動作方式
- 非パイプライン: ブラウザーは、前の応答を受信するまで次の要求を送信しません。
- パイプライン: ブラウザーは最初のリクエストを送信した後、応答を受信せずに 2 番目のリクエストを送信できます。
HTTPS
HTTP との違い:
SSL 層プロトコル: SSL (Secure Sockets Layer) は、トランスポート層でネットワーク接続を暗号化するために使用されるセキュリティ プロトコルです。
httpsプロセス
HTTPS リクエストには実際には 2 つの HTTP 送信が含まれており、8 つのステップに細分化できます。
- クライアントはサーバーへの HTTPS リクエストを開始し、サーバーのポート 443 に接続します。
- 非対称暗号化には、サーバー側に公開鍵と秘密鍵という鍵ペアがあり、秘密鍵はサーバー側で保管され、公開することはできません。公開鍵は誰にでも送信できます。
- サーバーは独自の公開キーをクライアントに送信します。
- クライアントはサーバーから公開鍵を受け取った後、公開鍵をチェックしてその正当性を検証しますが、公開鍵に問題がある場合は HTTPS 通信を続行できません。ここでは、サーバーから送信されたデジタル証明書の正当性を検証します。公開キーが修飾されている場合、クライアントは対称暗号化に使用されるキーであるランダムな値を生成します。このキーをクライアント キー、つまりクライアント キーと呼びます。次に、サーバーの公開キーを使用してクライアント キーを非対称に暗号化し、クライアント キーが暗号文になるようにします。ここまでで、HTTPS での最初の HTTP リクエストは終了します。
- クライアントは HTTPS で 2 番目の HTTP リクエストを開始し、暗号化されたクライアント キーをサーバーに送信します。
- サーバーは、クライアントから送信された暗号文を受信すると、独自の秘密キーを使用して非対称的に復号化します。復号化された平文はクライアント キーであり、その後、クライアント キーを使用してデータを対称的に暗号化し、データが暗号文になります。 。
- 次に、サーバーは暗号化された暗号文をクライアントに送信します。
- クライアントは、サーバーから送信された暗号文を受信し、クライアント キーを使用して対称的に復号化し、サーバーから送信されたデータを取得します。このようにして、HTTPS での 2 番目の HTTP リクエストが終了し、HTTPS 通信全体が完了します。
クライアントはデジタル証明書の正当性をどのように検証するか
- 電子証明書には、証明書を発行した組織が含まれています。クライアントは組織名を取得後、ブラウザのルート証明書を検索します。電子証明書に該当する組織が見つからない場合は、その組織が不正な証明書を発行していることを意味します。認証されておらず、デジタル証明書は違法です。
対称暗号化と非対称暗号化の意味と違い
- 非対称暗号化/非対称復号化では、暗号化と復号化では異なるキーが使用されますが、対称暗号化/対称復号化では、暗号化と復号化では同じキーが使用されます。
- 非対称暗号化では、キーが失われ、暗号化されたデータが公開されるため、対称暗号化よりも安全です。
- 非対称暗号の計算方法は、大きな数値の乗算、大きな数値の法などの演算を必要とするため、より複雑で速度が遅くなりますが、対称暗号はビット演算を使用するため高速です。
HTTPS 確立中の 3 つの乱数
- クライアントは初めて乱数を生成するリクエストを送信します。
- サーバーはリクエストに応答するときに乱数を生成します。
- クライアントは乱数を再度生成し、その乱数はサーバーの公開キーによって非対称に暗号化されます。
HTTPS の 3 つの乱数の役割
- クライアントは、サーバーの公開鍵の正当性を検証した後、3番目の乱数を生成します。このとき、クライアントは3つの乱数を持っています。これらの3つの乱数に従って、クライアントは新しい鍵を生成します(セッションシークレット)。
- サーバーの場合、秘密キーを使用して公開キーを非対称復号化した後、クライアントの 3 番目の乱数が取得されます。つまり、サーバーもこれら 3 つの乱数を持っています。これらの 3 つの乱数に従って、サービスは最後に、新しいキー (セッション シークレット) も生成します。
- 新しいキーはクライアントとサーバーの両方で同じです。その後のデータ送信では、対称暗号化と対称復号化にこのキー (セッション シークレット) が使用されます。
さらに技術的な記事については、公式アカウント Duxiong Jun にご注目ください。