HTTPに関するよくある質問

以下から学ぶ: xiaolincoding.com

序文

HTTPはアプリケーション層で非常に重要なプロトコルであり、試験でも面接でも合格する可能性が高いです。この記事では、HTTP に関するよくある質問と簡単な解決策をいくつか示し、それを基に読者が情報を確認し、自分で修正することができます。この記事のほとんどの質問は、グラフィック ネットワーク入門 | Xiaolincoding (xiaolincoding.com)からのものです。まだ見ていない場合は、まず Xiaolin グラフィック シリーズを読んでから、この記事を読んで印象を深めていただくことをお勧めします。あなたは圧倒されています。

質問

1.HTTPとは何ですか?

HTTP の正式名は HyperTextTransferProtocolで、ハイパーテキスト転送プロトコルです。ハイパーテキストとは、テキスト、画像、ビデオなど、通常のテキストを超えたテキストを指します。伝送プロトコルとは、2 つのエンティティ間の情報伝送の仕様と標準を指します。まとめると、HTTP は、2 つのエンティティ間でのテキスト、画像、ビデオなどのハイパーテキスト データの送信を定義する標準および仕様です。

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

1xx はプロンプト メッセージで、現在のプロトコルがまだ中間状態にあり、追加の操作が必要であることを示します。

2xx は成功情報で、メッセージが正しく受信され、処理されました。

3xx はリダイレクト情報であり、クライアントはリダイレクトされたアドレスに再度アクセスする必要があります。

4xx はクライアント エラーです。送信されたリクエストが正しくないため、サーバーはリクエストを行うことができません。

5xx はサーバーのエラー メッセージです。サーバー内で何らかのエラーが発生しました。

3.HTTP の共通フィールドは何ですか?

**ホストフィールド:**ドメイン名。

** Content-Length フィールド: ** この応答メッセージの長さを示します。

** Connection フィールド: ** 値が Keep-Alive の場合、これは長い接続であることを意味します。クライアントがリクエストを送信すると、一方がリンクを切断するまで長い接続が使用されます。

** Content-Type フィールド: ** 応答情報の形式を示します

Content-Encoding フィールド: 応答情報の圧縮形式を示します。

4.GETとPOSTの違いは何ですか?

RFC 仕様によれば、GET は特定のリソースを要求するために使用され、読み取り専用です。POST には、サーバー上の特定のリソースの処理を要求する本文が含まれています。

通常、GET パラメータは URL に含まれ、POST パラメータは通常、本文に含まれます。ただし、本文にデータが含まれていればPOSTが安全であるというわけではなく、攻撃者がPOSTの本文を傍受し、中のデータを取得する可能性があるため、安全な通信をしたい場合はhttpsを使用する必要があります。

5.GET と POST は安全で冪等ですか?

安全とは、リクエストによってサーバー上の一部のリソースが破壊されないことを意味します。冪等性とは、同じリクエストがサーバーに複数回送信され、同じ結果が得られることを意味します。

仕様によれば、GET リクエストは読み取り専用リクエストであり、サーバー リソースに追加の変更を加えないため、GET は安全かつ冪等です。POST リクエストはサーバー上の一部のリソースの処理を行うため、POST リクエストは安全ではなく、部分的に冪等です。

ただし、仕様に従って実行される場合、サーバーのコーディング方法に応じて、GET にサーバーを変更するためのリクエストを含めることもできます。

6.HTTPキャッシュの実装方法は何ですか?

めったに変更されない一部のデータについては、毎回サーバーにリクエストする必要はなく、ローカルにキャッシュして次のリクエストで直接表示できます。

HTTP の実装方法には、主に強制キャッシュ (アクティブ キャッシュ) とネゴシエート キャッシュがあります。

7. 強制キャッシュとは何ですか?

強制キャッシュとは、ブラウザーが特定のリクエストでローカル キャッシュを使用できると判断している限り、データをサーバーに送信せずにローカル データを直接使用することを意味します。キャッシュを使用するかどうかの決定はブラウザーにあるため、アクティブキャッシュとも呼ばれます。

強制キャッシュは、次の 2 つのフィールドを通じて実行されます。

• Cache-Control、は相対時間です。
• Expires、は絶対時間です。

具体的なプロセスは次のとおりです。

• ユーザーがブラウザを通じて初めてサーバーにリクエストを送信すると、サーバーはリクエストを返すときにこれら 2 つのフィールドを設定して、返されたリソースの有効期限を示すことができます。

• ブラウザが同じリクエストを 2 回目に送信するときは、前のリクエストのこれら 2 つのフィールドをチェックして、キャッシュの有効期限が切れているかどうかを確認できます。有効期限が切れていない場合は、ローカル データを直接使用します。有効期限が切れている場合は、リクエストが行われます。また。

• サーバーはリクエストを再度受信した後、これら 2 つのフィールドをリセットして戻ります。

8. ネゴシエーションキャッシュとは何ですか?

一部のリクエストの応答コードは です304。これは、サーバーがローカル リソースが使用できることをクライアントに通知することを意味します。キャッシュが使用できるかどうかをブラウザに通知するこの方法は、ネゴシエーション キャッシュと呼ばれます。ネゴシエーション キャッシュは通常、要求ヘッダーのフィールドIf-Modified-Sinceと応答ヘッダーのフィールドを通じて実装されます。Last-Modified

9. HTTP/1.1 の利点は何ですか?

• クロスプラットフォームでは、HTTP プロトコルが実装されている限り、通信と対話に HTTP プロトコルを使用できます。
• シンプルですぐに始められます。
• 柔軟で拡張が容易なアプリケーション層プロトコルであり、TLS ハンドシェイクの追加など、基盤となるプロトコルは可変です

10. HTTP/1.1 の欠点は何ですか?

• 安全性が十分ではなく、平文で送信され、メッセージが完全で新しいものであることを確認できず、サーバーの身元を確認するプロセスがありません。
• ステートレスでは、いくつかの関連操作を完了するのがさらに面倒になります。しかし、これは Cookie テクノロジーを使用することで解決でき、各リクエストに Cookie を送信することで、サーバーは最後のインタラクションに関する情報を知ることができます。

11. HTTP/1.1 はどのように動作しますか?

パフォーマンスは比較的平均的ですが、HTTP/1.0 と比較すると大幅に向上しています。

• 長い接続

HTTP/1.0 では、リクエストが送信されるたびに 3 ウェイ ハンドシェイクと 4 回のウェーブが必要となり、多くの時間とリソースが消費されます。HTTP/1.1 は長い接続を使用します。3 ウェイ ハンドシェイクの後、クライアントとサーバーは、一方の当事者がアクティブにリンクを切断するか、サーバーがあまりにも長い時間が経過してアクティブに切断されるまで、TCP 通信のラウンドで HTTP プロトコルと複数回対話できます。リンクを解除します。

• パイプライン化と行頭ブロック

長い接続を実現した後、クライアントは一度に複数のリクエストをサーバーに順番に送信できますが、旧バージョンとは異なり、各レスポンスが返信された後にのみ次のリクエストを送信できます。ただし、サーバーは依然として一度に 1 つのリクエストしか処理できません。連続して送信されたリクエストの 1 つが何らかの理由でブロックされると、その後キューに入れられたすべてのリクエストもブロックされ、クライアントはリクエストを継続することになります。データがない場合は、これは行頭ブロックです。

後続の HTTP/2.0 および HTTP/3.0 は、主に HTTP/1.1 のパフォーマンスに最適化されています。

12. HTTP と HTTPS の違いは何ですか?

• HTTP は安全ではありません。HTTPS は、主に整合性検証、サーバー側 ID 認証、およびデータ暗号化の機能を実装する、いくつかの暗号化ソリューションを通じて HTTP に SSL/TLS セキュリティ プロトコルを追加します。

• HTTP ではデータ送信に TCP スリーウェイ ハンドシェイクのみが必要ですが、HTTPS ではデータ送信に SSL/TLS ハンドシェイク プロセスも必要です。

• 2 つのポートは異なります。HTTP はポート 80、HTTPS はポート 443 です。

13. HTTPS は HTTP のどのような問題を解決しますか?

• データ転送中。ハイブリッド暗号化アルゴリズムを使用して機密性を確保し、非対称暗号化アルゴリズムを使用してキー交換を完了し、対称暗号化アルゴリズムを使用して後続の会話を完了します。
• ハッシュ関数を使用して、コンテンツ全体が改ざんできないようにします。
• デジタル証明書メカニズムを使用してサーバーの信頼性を確保し、中間者攻撃を回避します。

14. HTTPS はどのように接続を確立しますか? どのようなやりとりがあったのでしょうか？

リンクを構築する際の主な目標は 3 つあります。

• クライアントはサーバー証明書を検証し、サーバーの正しい実際の公開キーを取得します。
• 非対称暗号に基づいて対称セッションキーを交換する
• セッションキーを使用して、後続の対話で暗号化通信を完了します

15. HTTPS アプリケーション データの整合性はどのように確保されますか?

**整合性を確保するための中核はハッシュ関数です。**具体的には、メッセージを複数のフラグメントに分割し、各フラグメントを圧縮し、圧縮された各フラグメントに対してハッシュ関数を使用して MAC 識別コードに変換します。その後の MAC コードの検証により、識別できます。このデータが改ざんされているかどうか。

16. HTTPS は必ずしも安全で信頼できるものですか?

プロトコルの観点から見ると、現時点では非常に安全で信頼性があります。このセキュリティの源は暗号の原理です。たとえば、離散対数問題により、公開鍵から秘密鍵を導き出すことができません。暗号化の問題が解読されていないため、HTTPS にはセキュリティ上の問題はありません。

しかし、サーバーまたはクライアントに対する攻撃によっては、セキュリティ上の問題が発生することがあります。具体的には、サーバーの秘密鍵が漏洩すると、攻撃者はサーバーになりすましてクライアントと通信することができます。真ん中の攻撃。クライアントの場合、クライアントのマシン上のルート証明書ライブラリが変更され、悪意のあるノードの証明書が追加されると、悪意のあるノードは自身を通常のノードに偽装してクライアントと通信することができます。

17. HTTP/1.1 では HTTP/1.0 に比べてどのようなパフォーマンスの向上がありますか?

• 長い接続を使用すると、リクエストごとに 3 回のハンドシェイクと 4 回のウェーブのプロセスを実行する必要がなくなります。
• パイプライン メカニズムを使用すると、次のリクエストを送信する前にリアルタイムで応答を待つことなく、多くのリクエストを一度に送信できます。

しかし、まだいくつかの問題があります。

• ヘッドには圧縮がなく、ヘッドが大きくなるほど速度は遅くなります。
• リクエストはクライアントからのみ開始でき、サーバーは受動的にのみ応答できます。
• サーバーはリクエストの順序で応答します。サーバーの応答が遅い場合、クライアントはデータをリクエストできなくなります。つまり、キューの先頭がブロックされます。

18. HTTP/2 に対してどのような最適化が行われましたか?

主に以下の作業を完了しました。

• 頭部圧縮
• バイナリ形式
• サポートストリームは同時送信もサポートします。
• サーバーは積極的にジョブをプッシュできます

1. ヘッド圧縮

HTTP/2ではヘッダ圧縮を行うため、連続したリクエストで同じリクエストヘッダがあった場合、重複した部分が削除されます。

2. バイナリ形式

HTTP/1.1 のフィールドはすべて文字列構造ですが、HTTP/2 では一部のフィールドがバイナリ ビット (フラグ ビット) に変換されます。

3. ストリーム、同時送信、サーバーアクティブプッシュをサポート

HTTP/1.1 の TCP 接続では、リクエストは 1 つずつしか処理できません。リクエストの処理が非常に遅い場合、後続のリクエストはブロックされます。これがヘッドオブライン ブロックです。

HTTP/2 では、ストリームの概念が導入され、複数のストリームが 1 つの TCP リンクを再利用します。

異なる HTTP リクエストを異なるストリームにカプセル化できます。各ストリームには異なるストリーム ID があり、同時に送信して同時に受け入れることができます。後で、ストリーム ID を介してリクエストと応答を組み立てることができます。

サーバーの場合、ストリームをアクティブに作成してクライアントに送信できます。クライアントによって作成されたストリームは奇数であり、サーバーのストリームは偶数です。

現在、HTTP/2 は最下層で TCP プロトコルを使用しているため、パフォーマンスの制限は主に TCP プロトコルのパフォーマンスの制限によるものです。たとえば、TCP は受信したバイトが完全である必要があることを保証しており、これにより後続のリクエストはただし、前のリクエストが受信される前に、TCP はデータを上位層に配信しません。

19. HTTP/3 に対してどのような最適化が行われましたか?

HTTP/3 の最大の変更点は、基盤となる TCP プロトコルを UDP プロトコルに変更し、同時にアプリケーション層に QUIC (「クイック」と発音) を実装してパフォーマンスを向上させたことです。現在、HTTP/3のRFCはリリースされていますが、普及率はまだ高くありません。

20.HTTP/1.1 最適化のアイデア?

• 送信されるリクエストの数を減らす
• サーバー側の応答サイズを削減する

最初のアイデアでは、まずキャッシュのアイデアを広範囲に使用できます。一部の静的データの場合、より多くのデータをローカルに保存すると、送信されるリクエストの数を減らすことができます。第二に、クライアント側では、最初に複数回リクエストされた小さなファイルを 1 つのリクエストにマージして、一度に 1 つの大きなリソースをリクエストできます。たとえば、BASE64 を使用して複数の画像をエンコードした後、複数の画像を一度に送信できます。最後に、リクエストの送信を遅らせることもできます。つまり、あまり必要のない一部のリソースについては、リクエストを一時的に送信せず、必要に応じてサーバーにリクエストを送信します。

2 番目のアイデアは圧縮です。圧縮は可逆圧縮と非可逆圧縮に分けられます。これは特定のビジネス シナリオに従って選択する必要があります。ビジネス シナリオがデータに対してそれほど正確ではない場合 (小さなテクスチャなど)、非可逆圧縮を使用できます。圧縮するとデータ量が大幅に削減されます。

21.HTTPSを最適化するにはどうすればよいですか?

HTTPS は、HTTP に基づいて TSL の層を追加し、主に以下を実装します。

• 証明書認証では、クライアントはサーバーの証明書を検証して真の身元を確認する必要があります。
• 非対称暗号化を使用して対称キーを交換するハイブリッド暗号化メカニズム、ECDHE を使用します。
• 以降の対称鍵を使用した暗号化通信

まず、いくつかの一般的な最適化シナリオを検討します。

• ハードウェアの最適化。つまり、速度を向上させるために効率的な暗号化と復号化をサポートするハードウェア サポートを使用します。
• ソフトウェアの最適化、一部のアルゴリズムの最適化

HTTPS に追加された上記の 3 つのポイントを最適化することもできます。

証明書の場合、第一に、証明書のサイズを削減できます。つまり、同じセキュリティでも楕円曲線パラメータに必要なバイト数が少なくなるため、楕円曲線暗号化を使用できます。第二に、証明書の検証手順を削減できます。従来の検証 検証する場合は、証明書チェーンを確認し、証明書失効リストをダウンロードして、証明書の有効期限が切れているかどうかを確認する必要があります。証明書のステータスを照会するように変更できます。サーバーは定期的に CA に証明書ステータスを照会し、CA は署名済みステータスを返します。したがって、サーバーが CA によって署名された証明書ステータスを含むクライアントの要求を返すと、煩雑な証明書チェーンを回避して直接検証できます。プロセス。

秘密鍵交換アルゴリズムについては、交換に楕円曲線暗号化を使用してみてください。これにより速度が向上し、TLS アップグレード後はハンドシェイクを 4 回から 3 回に変更できます。

対称キーの場合、リクエストごとにいくつかのセッション キーをネゴシエートする必要がある場合、非常に面倒になりますが、この状況を解決するために、セッション ID ソリューションを採用することができます。つまり、クライアントとサーバーの両方がこのシークレットを保存します。キーはセッション ID によって識別されます。ユーザーは次回の送信時にセッション ID を持ち込むことができ、サーバーはセッション ID のステータスを照会します。セッション ID がまだ存在する場合、以降の通信はこの対称秘密キーを介して直接行われます。セッション チケット スキームを使用することもできます。つまり、サーバーは独自の秘密キーの 1 つを使用して対称秘密キーを暗号化し、それをクライアントに送信します。次回クライアントが送信するときは、この暗号化された秘密キーが使用されます。サーバーが独自の秘密キーを使用してメッセージを復号化でき、復号化された秘密キーが通常どおりに使用できる場合は、この秘密キーを直接通信に使用できるため、暗号化メッセージの必要性が回避されます。サーバーが多数のクライアントを維持するための対称キー。セキュリティを確保するため、有効期限の設定には注意してください。

22. HTTP プロトコルを使用した後でも、RPC プロトコルが必要なのはなぜですか?

現在、HTTP およびほとんどの RPC プロトコルは TCP に基づいているため、最初に TCP プロトコルについて説明する必要があります。TCP は、信頼性の高い接続指向のバイト ストリーム ベースのサービスのみを提供し、上位層ではバイト ストリームのみが表示されます。つまり、メッセージには境界がありません。そこで、TCPをベースにして登場したのがRPCとHTTPですが、実はこの2つは方向性が異なるのですが、HTTPは、各社のホームページが異なり、使用している技術も異なるため、主にブラウザに適応するために登場しました。時刻はブラウザ上で表示するためHTTPを使用します。RPC は現在、特に APP やクライアントの台頭以降、主に企業内で使用されていますが、RPC プロトコルはカスタマイズ性が高いため、最適化およびカスタマイズして各企業の内部通信プロトコルを開発し、パフォーマンスを向上させることができます。つまり、どちらも双方向なので、両方が必要です。

23. HTTP プロトコルがあるのに、なぜ WebSocket が必要なのでしょうか?

WebSocket は主に、双方の間で全二重通信を実現するために使用されます。つまり、サーバーはメッセージをクライアントにアクティブにプッシュできます。

QR コードをスキャンしてログインするなど、サーバーがクライアントに情報をアクティブにプッシュするための実装方法は何ですか?

• 投票を続けてください。つまり、サーバーが QR コードが正常にログインしたという情報を返すまで、クライアントはサーバーにリクエストを送信し続けます。

• 長いポーリング。クライアントはサーバーにリクエストを送信し、長時間待機し、成功せずに時間が経過した場合は別のリクエストを送信します。成功情報が返されるまで。

• 通信にはWebSocketプロトコルを使用します。WebSocket は、HTTP と同様、TCP ベースのプロトコルです。3 回の TCP ハンドシェイクを経験した後、 HTTP プロトコルを使用して WebSocket プロトコルにアップグレードします。以降の通信には WebSocket プロトコル形式が使用されます。