実際の作業シナリオで遭遇した http プロトコルに関連するいくつかの内容についての私の理解を要約します。
サーバーがロード バランサーの背後にある場合、同じリソースへのリクエストが異なるバックエンド マシンに分散される可能性があります。ETag の計算はファイル属性に依存するため、異なるマシン上の同じコンテンツを持つファイルは異なる ETag を生成する可能性があります。コンテンツが変更されていないオリジナル ファイルは ETag 検証に合格しませんでした。ここには 2 つの解決策があります。1 つは、ファイル コンテンツの md5 値を直接計算するなど、etag の計算がローカル マシンに依存しないことです。もう 1 つは、負荷時に同じ URL リクエストを同じバックエンド マシンに分散することです。バランサー。
実際のビジネス シナリオでは、http キャッシュは非常に優れた用途をいくつか示します:
ロゴ、広告画像など、クライアントが頻繁にアクセスする必要がある静的ファイルなど、クライアントのリソースを最大限に活用します。 .、完全にクライアント上でローカルにキャッシュできます。これにより、ネットワーク リクエストが減少し、クライアントの表示が高速化され、サーバー リクエストの負荷が軽減されます。
ニュースやブログなどの静的コンテンツの一部が検索エンジン クローラーによってクロールされる場合、キャッシュ パラメーターを制御することで、クローラーのクロール頻度を減らし、リソースの不必要な浪費を減らすことができます。
静的リソースが CDN を使用している場合、http キャッシュを設定すると CDN ノードにファイルが保存され、オリジンに戻る CDN の数が減り、ネットワークの遅延とオリジン サーバーの負荷が軽減されます。
2. ブレークポイントリクエスト
Accept-Ranges: サーバーがブレークポイントのダウンロードをサポートしている場合、クライアントはこの応答ヘッダーをクライアントに返します。これを認識すると、ブレークポイントリクエストを送信できます。
Content-Length: 現在のリクエストによって返されるデータ量をクライアントに伝える応答情報の長さ。ここで、head メソッドを使用してリクエストを送信すると、特定のデータは返されませんが、Content-Length は完全なデータのサイズを返すことに注意してください。
Range/Content-Range: クライアントはリクエストを行うときに Range という名前のヘッダーを送信し、データのどの部分をリクエストしたいかをサーバーに伝えます。例: Range: bytes=0-1023 は、バイト 0 ～ 1023 を要求することを意味します。その後、サーバーはこれらの 1024 バイトのコンテンツをクライアントに返し、Content-Range が応答ヘッダーに含まれます。つまり、Content-Range: バイト 0 ～ 1023/4096、この 4096 が合計ファイル サイズです。クライアントの次のリクエストは 1024 番目のバイトから開始できます、範囲: bytes=1024-xxxx
3. Encoding
Accept-Encoding/Content-Encoding: 前者はクライアントがサポートするメッセージ エンコーディング タイプです。デフォルトはidentityで、オプションの値にはgzip、compressなどが含まれます。後者はサーバー側応答情報の内容エンコーディングタイプであり、圧縮が一般的に使用されます。圧縮の利点は明らかであり、サーバー側の圧縮による CPU 消費量と比較して、ネットワーク送信のコストを大幅に削減できます。一般的な形式: Content-Encoding: gzip、deflate、compress。通常、html、js、css、xml、json などの応答結果を圧縮して送信できます。
Transfer-Encoding: 応答ヘッダー。応答メッセージの転送エンコーディング タイプは、ネットワーク送信の形式を指定します。一般に、これは次の形式になります: Transfer-Encoding: chunked。サーバーが動的コンテンツを生成し、応答情報の具体的な長さがわからない場合、この指定されたブロックを通じてそれを送信し、処理した量のデータを返すことができるため、データの準備ができるまで待って返す必要はありません。一斉に。上記のgzipなどのコンテンツエンコードと組み合わせることで、ブロック単位で圧縮して送信することができます。さらに、このエンコーディングを使用して送信する場合、コンテンツが完全に生成されていないため、Content-Length を確認できないことに注意してください。
4. その他
X-Forward-For: リクエストヘッダー。特にプロキシ (フォワードまたはリバース) 経由でサーバーにアクセスする場合、またはサーバーが負荷分散デバイスの背後にある場合に、ユーザーの実際の IP を識別するために使用されます。形式: X-forward-For: client、proxy1、proxy2、... 一番左の IP はクライアントに最も近い IP です。
User-Agent: リクエスト ヘッダー。クライアントの基本情報を識別するためにサーバーによって使用されるリクエスト ヘッダー。一般に、これは検索クローラーを識別するときに役立ちます。また、一部のシナリオでは、これを使用してクライアント統計を実行することもできます。
Referer: リクエストヘッダー。クライアントがサーバーにアクセスするとき、このリファラーはリクエストのソース (リンク元の Web サイトなど) を指定します。これは一部の統計でよく使用されます。さらに、もう 1 つの重要な用途は、リソースのホットリンク対策が必要なシナリオで不正なリクエスト ソースをフィルタリングすることです (ただし、このリファラーはクライアントによって偽造される可能性があります)。
Location: 応答ヘッダー。この Location ヘッダーは 301/302 ステータス コードの応答ヘッダーに含まれ、必要なリソースにアクセスするために新しいアドレスを使用するようにクライアントに指示します。
Connection: request/response ヘッダー。http/1.1 では、クライアントとサーバーはデフォルトで接続を維持します。つまり、どちらかの当事者が接続を維持したくない場合は、この値を次のように設定できます。デフォルトでは、クライアントとサーバーは長時間の接続を維持するため、クライアントはこの接続を使用して複数の http リクエストを送信でき、頻繁な接続作成による消費を削減できます。このパラメータの場合、接続キープアライブ時間やサーバ カーネルの一部のネットワーク パラメータ設定（tcp 用）など、サーバ側でさらに多くの設定が必要になる場合があります。
セッションとクッキー
http リクエストはステートレスなリクエストですが、インターネット アプリケーションでは、対話型操作を完了するためにユーザー ステータス情報を識別する必要があることがよくあります。たとえば、ユーザー認証ではユーザーのログイン ステータスを記録する必要があり、ショッピング カート アプリケーションでは商品を記憶する必要があります。広告配信アプリケーションはユーザーの履歴閲覧行動などを記録する必要があります。ここではセッションとCookieが使用されます。
セッション: http リクエストとレスポンスのプロセス中のクライアントとサーバー間の対話状態を指します。この情報は、メモリ、データベースなどのサーバー側に保存されます。各セッションにはサーバーによって生成される一意の識別子があり、クライアントが次のリクエストでこの識別子を使用して、サーバーがクライアントのステータスを判断しやすくできるように、この識別子もクライアントに保存する必要があります。
セッションのクライアントサポート:
Cookieを介してセッションIDを保存し、リクエスト時にサーバーに送信します。
URL パラメーターにセッション ID を含めてサーバーと通信します。
フォームの非表示フィールドにセッションIDを入れてサーバーと通信します。
セッション共有の問題:
分散アプリケーションでは、通常、http サーバーがリバース プロキシまたは負荷分散デバイスの背後にインストールされるため、セッション共有の問題が発生します。つまり、同じユーザーからの複数のリクエストが複数の異なるマシンに分散される可能性があります。セッションをマシンのローカル メモリに保存すると、ユーザーのセッションを複数のマシン間で共有できなくなります。一般に、この問題は 2 つの方法で解決できます:
セッションを分散メモリ (例: memcached) または集中ストレージ (例: データベース) に保存します。
同じユーザーのリクエストをリバース プロキシまたは負荷分散デバイス上の同じマシンに分散します (ここでは、マシンがダウンした後のリクエストの再分散の問題に対処する必要があります)。
Cookie: クライアント上でステートフルな情報を維持します。セキュリティ上の理由から、各 Cookie コンテンツは特定のドメインまたはパスに属します。
セッション Cookie: 有効期限は指定されていません。メモリに保存され、ブラウザを閉じると期限切れになります。
永続 Cookie: 有効期限を指定し、ブラウザーにローカルに保存されます。
詳細については、http://en.wikipedia.org/wiki/HTTP_cookie を参照してください。
Cookie にはセキュリティ上の問題があることに注意してください。
ここでは、私が仕事中に遭遇した http プロトコルに関連するいくつかの内容についての私の理解をまとめました。http プロトコルにはまだ調査する必要があることがたくさんあり、http についての理解を続ける必要があります。プロトコルはアプリケーションの開発に大きな利便性をもたらします。
最後に、2 つの非常に重要な http デバッグ ツールをお勧めします。fiddler (Windows) と charles (Mac) には http プロキシ機能があり、ブラウザベースではない http アプリケーション (モバイル アプリなど) の場合、これら 2 つのツールを使用して、 httpリクエストを監視します。
以上がHTTP プロトコルの概要と深い理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
