HTTP プロトコルの概要と深い理解

実際の作業シナリオで遭遇した http プロトコルに関連するいくつかの内容についての私の理解を要約します。

リクエストとレスポンス

リクエストの形式

例: GET /api/index.json HTTP/1.1

例: Accept: */* ; User -Agent: Mozilla/4.0;……

[] 例: id=1×tamp=xxxxxx

応答形式

: HTTP/1.1 200 OK

例: Content-Type: application/json;......

[] 例: { "id":1,"username": "testuser"}

ステータスコード

httpステータスコードは60近くありますが、ここでは主に、日常的に多かれ少なかれ遭遇するであろう、異常な状況下で生成されるいくつかの一般的なステータスコードを記録します。アプリケーションの問題を理解し、特定するのに役立ちます。

206 - ブレークポイントのダウンロード中に使用されます。クライアントはコンテンツの一部を要求し、サーバーはコンテンツのこの部分を正常に返しました。このステータスは現時点で使用されます。

301 - 永久ジャンプ。元のアドレスは存在せず、URL は別のアドレスを指します。これは主に検索エンジンに関連しており、クローラーの検索動作に影響します。

302 - 一時的なジャンプ。サーバーは新しい URL をクライアントに返し、クライアントは引き続きこの URL にアクセスしてコンテンツを取得できます。

304 - リソースは変更されていません。クライアントはローカルにキャッシュされたコンテンツを使用できます。これは静的コンテンツ アクセスでは一般的です。

413 - リクエスト エンティティが大きすぎます。よくある状況は、大きなファイルをアップロードするが、サーバー (nginx など) の制限を超えることです。または、リクエスト ヘッダーまたはリクエスト本文がバックエンド サーバー (Tomcat など) の設定を超えています (たとえば、現在のドメイン名の下に Cookie が多すぎて、リクエスト ヘッダーの制限を超えています)

416 - ブレークポイントの再開に関連、クライアントリクエストのスコープがサーバー上のファイルサイズを超えています。

500 - サーバー内部エラー。通常の結果を返すことができません。たとえば、最も一般的なアプリケーションは、処理されない null ポインタ例外をスローします。

502 - ゲートウェイ エラー。一般的な状況は、リバース プロキシ バックエンド サーバー (樹脂や Tomcat など) が起動されていないことです。

503 - サービスが利用できません。たとえば、サーバーの負荷が高すぎるか、サーバーがサービスを停止しました。

504 - ゲートウェイのタイムアウト。たとえば、リクエスト期間がサーバーの応答時間制限を超えています。

ヘッダー

httpヘッダーは、リクエストヘッダーとレスポンスヘッダーの2つのカテゴリに分類されます。以下は私たちがよく使うヘッダーです

1. キャッシュ制御

インターネット Web サイト アプリケーションでは、ほとんどどこでもキャッシュが使用されます。HTTP ベースのサービスでは、クライアントのキャッシュで頻繁に変更されない一部のコンテンツも制御できます。これにより、キャッシュされたコンテンツを複数回の訪問で再利用できるようになり、アクセスが高速化され、ユーザー エクスペリエンスが向上します。 http プロトコルは、キャッシュ制御用の http ヘッダーをいくつか規定しています。

Cache-Control (HTTP/1.1)/Pragma (HTTP/1.0): クライアントがキャッシュするかどうか、およびキャッシュが持続する期間を示します。デフォルト値はプライベートです。これは、コンテンツがユーザーのプライベートスペースにキャッシュされることを意味します。例: Cache-Control: max-age=86400、must-revalidate、これは、要求されたリソースが 1 日キャッシュされ (max-age の単位は秒、相対時間)、有効期限が切れた後に再チェックする必要があることをクライアントに伝えます。 。

Expires: クライアント (強制更新が必要ない場合) がサーバーにリクエストを送信せずにローカル キャッシュを直接読み取ることができる期間を指定します。

注:

優先度: キャッシュ制御 > 有効期限

パラメータの詳細な説明: http://condor.depaul.edu/dmumaugh/readings/handouts/SE435/HTTP/node24.html

異なるブラウザー異なる動作(更新、戻る、アドレス バーへの入力など) は実装に違いがある可能性があります。

Last-Modified/If-Modified-Since: Last-Modified は、サーバーからクライアントに返されたリソースの最後に変更されたタイムスタンプです。そのため、クライアントは次のリクエスト (強制更新など) を行うときに If-Modified-Since パラメータを持ち込んで、リソースが更新されたかどうかを確認します。更新がない場合、サーバーは 304 ステータス コードを返します。クライアントはローカルにキャッシュされたリソースを直接取得します。現時点では、要求のオーバーヘッドのみが発生し、ネットワーク送信のオーバーヘッドは発生しません。注: タイムスタンプはグリニッジ標準時 (GMT) である必要があります。例: Last-Modified:Sat, 19 Oct 2013 09:20:15 GMT

ETag/If-None-Match: ETag は、以下に基づいて特定のアルゴリズムを通じて生成されます。ファイル属性 リソース識別子は、クライアントによって要求されたリソースが更新されたかどうかを判断するためにも使用されます。サーバーが ETag 値をクライアントに返すと、次回クライアントが ETag 値を要求したときに、リソースが更新されているかどうかを確認するために If-None-Match パラメーターが提供されます。更新されていない場合は、304 ステータス コードが返されます。 。 (効果は基本的に Last-Modified と同じです)

注:

ETag を計算する必要がありますが、これはコンピューティング リソースが限られているサーバーの消費となるため、一部の Web サイトでは ETag を直接使用しません。

サーバーがロード バランサーの背後にある場合、同じリソースへのリクエストが異なるバックエンド マシンに分散される可能性があります。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 サイトの他の関連記事を参照してください。