http プロトコルの概要とそれに関する知識

0.0742017.08.29 00:22:51 ワード数 11,800 読み取り 913

http プロトコルには、http0.9、http1.0、http1.1、および http2 の 3 つのバージョンがあります。ただし、現在ブラウザでは http1.1 標準が使用されています。この記事では、http1.1 バージョンに焦点を当て、http2 についても説明します。特徴。

はじめに

早速ですが、HTTP は Hyper Text Transfer Protocol (ハイパーテキスト転送プロトコル) です。TCP/IP に基づくアプリケーション層プロトコルです。主に Web サーバーからローカルブラウザにハイパーテキストを送信するために使用されます。リクエストとレスポンスの構成は標準です。クライアントサーバーモデル。

http と https の違いについて簡単に説明します: https プロトコルは SSL+TLS で実行され、http と ssl に基づいて構築されます。http との最大の違いはそのセキュリティであり、異なる接続を使用します。使用されるメソッドとポートは次のとおりです。 (443、httpは80) また、httpsはセキュリティを確保するため、キーを返してサーバーとの暗号化アルゴリズムを確認する必要があり、この場合サーバーとのハンドシェイク回数が増加し、パフォーマンスやパフォーマンスに影響を与えます。面倒なこと。

2. http の主な機能

1 クライアント/サーバーモードをサポート

2 シンプルかつ高速: クライアントに必要なのは、サーバーにサービスを要求するための送信方法とパスだけです。一般的に使用されるリクエストのメソッドは、GET、HEAD、および POST です。http サーバーの各プロトコルは単純であるため、プログラムのサイズが小さく、通信速度が非常に高速です。

3 柔軟性: http では、あらゆるタイプのデータオブジェクトの送信が可能です。送信されるタイプは、リクエストヘッダーの Content-Type によってマークされます。

4 HTTP 0.9 および 1.0 は非永続接続を使用します: 各接続は 1 つのリクエストのみの処理に制限されており、サーバーがクライアントのリクエストを処理し、クライアントの応答を受信した後、接続は切断されます。この方法により、送信時間が節約されます。HTTP 1.1 は永続的な接続を使用します。Web オブジェクトごとに新しい接続を作成する代わりに、1 つの接続で複数のオブジェクトを転送できます (これはヘッダー情報に関連付けられた接続によって制御されます)。

5 http はステートレスプロトコルです。ステートレスとは、トランザクション処理用のメモリが不足していることを指します。ステートがないことは、後続の処理で以前の情報が必要な場合に再送信する必要があることを意味し、その結果、接続ごとに送信されるデータ量が増加する可能性があります。

(ステートレスプロトコル: プロトコルの状態とは、今回送信された情報を次の送信で「記憶」する能力を指します。http は、メモリの記憶を確保するために、この接続によって送信された情報を次の接続まで維持しません。サーバ。

例: たとえば、顧客が Web ページを取得した後、ブラウザを閉じ、ブラウザを再度起動して Web サイトにログインしますが、サーバーは顧客がブラウザを一度閉じたことを認識しません。Web サーバーは多くのブラウザからの同時アクセスに直面する必要があるため、同時アクセスに対する Web サーバーの処理能力を向上させるために、HTTP プロトコルを設計する際に、Web サーバーが HTTP 応答メッセージとドキュメントを送信するときに、Web ブラウザーがリクエストを行ったプロセスのステータス情報は保存されません。ブラウザーがわずか数秒以内に同じオブジェクトに 2 回アクセスすると、サーバープロセスはすでに応答メッセージを送信しているため、2 番目のサービス要求を受け入れない可能性があります。Web サーバーはリクエストを送信した Web ブラウザプロセスに関する情報を保存しないため、HTTP プロトコルはステートレスプロトコルです。

）

ステートレスな HTTP プロトコルと Connection: keep-alive の違い:

HTTP はステートレス接続指向のプロトコルです。ステートレスであることは、HTTP が TCP 接続を維持できないことを意味するものではなく、HTTP が UDP プロトコルを使用する (接続なし) ことを意味するものでもありません。

HTTP/1.1 以降、接続機能を維持するためにキープアライブがデフォルトで有効になっています。簡単に言えば、Web ページを開いたときに、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。 client このサーバー上の Web ページに再度アクセスすると、この確立された接続が引き続き使用されます。

Keep-Alive は接続を永続的に維持するものではなく、さまざまなサーバーソフトウェア (Apache など) で設定できる保持時間を設定します。

バージョン 1.1 では、パイプラインメカニズムも導入されました。つまり、同じ TCP 接続で、クライアントは複数のリクエストを同時に送信できます。これにより、HTTP プロトコルの効率がさらに向上します。

たとえば、クライアントは 2 つのリソースを要求する必要があります。以前のアプローチでは、最初に同じ TCP 接続でリクエスト A を送信し、次にサーバーの応答を待ち、リクエスト B を受信した後に送信するというものでした。パイプライン機構により、ブラウザは A リクエストと B リクエストを同時に発行できますが、サーバーは A リクエストに順番に応答し、完了後に B リクエストに応答します。

3 つのワークフロー

http 操作はトランザクションと呼ばれ、作業プロセスは 4 つのステップに分けることができます。

1) まず、クライアントとサーバーは接続を確立する必要があります。ハイパーリンクをクリックするとすぐに HTTP 作業が開始されます (接続が確立されます)。

2) その後、クライアントはサーバーにリクエストを送信します。リクエストの形式は次のとおりです: URL (Uniform Resource Identifier)、プロトコルのバージョン番号、その後にリクエスト修飾子を含む MIME 情報、クライアント情報、および考えられるコンテンツが続きます。(リクエストを送信)

3) サーバーはリクエストを受信すると、対応する応答情報を返します。その形式は、情報のプロトコルバージョン番号を含むステータス行と、その後にリクエスト修飾子、クライアント情報、および考えられるコンテンツを含む MIME 情報が続きます。(リクエストへの回答)

4) クライアントはサーバーから返された情報を受信し、ブラウザを通じてユーザーの表示画面に表示します。その後、クライアントはサーバーとの接続を切断します (切断)

上記のプロセスは、クライアントがプロキシサーバーを通過した後、Web サーバーに到達する場合があります。

HTTP はトランスポート層の TCP/IP プロトコルに基づいているため、TCP はエンドツーエンドの接続指向プロトコルです。いわゆるエンドツーエンドはプロセス間の通信として理解できるため、HTTP は送信を開始する前に TCP 接続を確立する必要があります。TCP 接続のプロセスでは、図に示すように、いわゆる「3 ウェイハンドシェイク」が必要です。形。接続されると、転送を開始できます。HTTP は、転送が完了するまでの間、TCP 接続を切断しません。これは、HTTP 1.1 のデフォルトの動作です (Connection ヘッダーによって設定されます)。

4つの URLを詳しく解説

URL: ネットワーク上のリソースを記述するために使用される URI (Uniform Resource Identifier) の一種である、Uniform Resource Locator 基本的な形式は次のとおりです: schema://host[:port#]/path/.../[ ;url-params][?クエリ文字列][#anchor]

スキームは下位層で使用されるプロトコルを指定します (例: http、https、ftp)

ホストHTTPサーバーのIPアドレスまたはドメイン名

「:」に続くのはポートで、デフォルトは 80 です。

path: リソースにアクセスするためのパスです

「;」に続くのは url-params: URL パラメーターであり、キャッシュ識別子 (セッション ID) として使用できます。

クエリ文字列: http サーバーに送信されるデータ。クエリパラメータとも言え、& 記号で区切られています。

「#」に続くのはアンカーです

5つのリクエストメッセージ

5.1 要求されたメッセージの形式は次のとおりです。

1) リクエスト行 (GET /images/logo.gif HTTP/1.1 など)。これは、get メソッドを使用して /images ディレクトリから logo.gif ファイルをリクエストすることを意味し、プロトコルバージョンは http1.1 です。

2) リクエストヘッダー (Accept-Language: en など)

3) 空白行

4) オプションのメッセージ本文

リクエスト行とタイトルはキャリッジリターンとラインフィードで終わる必要があり、空の行にはキャリッジリターンとラインフィードのみが含まれている必要があります。

5.2 リクエスト方法

最初の 3 つは既に http0.9 および http1.0 プロトコルに含まれており、最後の 5 つは http1.1 の後に追加されます。

GET: 特定のリソースにリクエストを送信します。

POST: 指定されたリソースにデータを送信して、リクエスト (フォームの送信やファイルのアップロードなど) を処理します。データはリクエストに含まれており、POST リクエストにより、新しいリソースが作成されたり、既存のリソースが変更されたりする場合があります。

HEAD: GET リクエストと一致するレスポンスをサーバーに要求しますが、レスポンスボディは返されません。この方法を使用すると、応答コンテンツ全体を送信しなくても、応答ヘッダーに含まれるメタ情報を取得できます。このメソッドは、ハイパーリンクの有効性、アクセス可能かどうか、最近更新されたかどうかをテストするためによく使用されます (その後、主に応答ヘッダー情報を取得するために使用されます)。

PUT: 最新のコンテンツを指定されたリソースの場所にアップロードします

オプション: 特定のリソースに対してサーバーによってサポートされている HTTP リクエストメソッドを返します。

DELETE: Request-URI で識別されるリソースの削除をサーバーに要求します。

TRACE: テストまたは診断のためにサーバーが受信したリクエストをエコーします。

CONNECT: http1.1 プロトコルは、パイプラインへの接続を変更できるプロキシサーバー用に予約されています。

PATCH: リソースに部分的な変更を適用するために使用され、仕様 RFC5789 に追加されました。

要約すると、GET メソッドはサーバー内のデータの取得に使用され、POST メソッドはサーバー内のリソースデータの変更に使用され、PUT はデータのアップロードに使用され、DELETE はサーバー内のリソースの削除に使用され、HEAD はデータの取得に使用されます。応答ヘッダー情報。

GET と POST の違い:

1) 送信されたデータの場所が異なります。GET は URL の後にあり、POST は HTTP パッケージの本文内にあります。

2) GET によって送信されるデータのサイズは、ブラウザーには URL の長さに関する制限があるため、最大 1024 バイトに制限されていますが、POST によって送信されるデータには制限がありません。

3) POST は GET より安全です。GET は URL 上の一部の情報を公開し、送信されたデータは URL に表示されます。ページをキャッシュできるか、他のユーザーがアクセスできる場合は、ユーザーアカウントのパスワードは、歴史記録の資料

4) GET メソッドでは変数の値を取得するために Request.QueryString を使用する必要がありますが、POST メソッドでは変数の値を取得するために Request.Form を使用します。

6 つの応答メッセージ

クライアントはサーバーにリクエストを送信し、サーバーはステータス行で応答します。応答内容には、メッセージプロトコルのバージョン、成功またはエラーコード、サーバー情報、エンティティのメタ情報、および必要なエンティティのコンテンツが含まれます。応答クラスのカテゴリに応じて、サーバー応答にエンティティコンテンツが含まれる場合がありますが、すべての応答にエンティティコンテンツが含まれるわけではありません。

フォーマット：

http プロトコルのバージョンスペースステータスコードスペース Reason-Phrase のキャリッジリターンとラインフィード (Reason-Phrase は単純なテキストの説明)。

7 つの http ステータス応答コード

1XX (情報タイプ): リクエストが受信され、処理が継続されることを示します。

2XX (成功応答): アクションが正常に受信、理解され、受信されたことを示します。

Follow 200: リクエストが正常に完了し、リクエストされたリソースがクライアントに送り返されたことを示します。

3XX (リダイレクト): 指定されたアクションを完了するには、さらなる処理を受け入れる必要があります

304: 要求された Web ページは最後のリクエスト以降変更されていないことに注意してください。サーバーがこの応答を返すとき、Web ページのコンテンツは返されません。これは、最後のドキュメントがキャッシュされており、引き続き使用できることを意味します。

4XX (クライアントエラークラス): リクエストに不正な構文が含まれているか、正しく実行できません。

404 に注意してください。404 エラーは、サーバーには接続できますが、サーバーは要求された Web ページを取得できず、要求されたリソースが存在しないことを示します。例: 間違った URL が入力されました

5XX (サーバー側エラークラス): サーバーは正しいリクエストを正しく実行できません

8つのヘッダー情報

8.1 一般的な HTTP リクエストヘッダー

If-Modified-Since: ブラウザ側でキャッシュされたページの最終変更時刻をサーバーに送信すると、サーバーはこの時刻をサーバー上の実際のファイルの最終変更時刻と比較します。時間が一致している場合は、304 が返され、クライアントはローカルキャッシュファイルを直接使用します。時間が一致しない場合は、200 と新しいファイルの内容が返されます。受信後、クライアントは古いファイルを破棄し、新しいファイルをキャッシュしてブラウザに表示します。(これは後で説明する比較キャッシュに関連します。反対は Last-Modified 応答ヘッダーです)

If-None-Match: If-None-Match は ETag で動作します。動作原理は、HTTP 応答ヘッダーに ETag 情報を追加することです。ユーザーが再度リソースをリクエストすると、If-None-Match 情報 (ETag の値) が HTTP リクエストヘッダーに追加されます。サーバーは、リソースの ETag が変更されていない (リソースが更新されていない) ことを確認すると、304 ステータスを返し、クライアントにローカルキャッシュファイルを使用するように指示します。それ以外の場合は、200 ステータスと新しいリソースと Etag が返されます (これは比較キャッシュにも関連しており、上記の If-Modified-Since/Last-Modified ペアよりも優先されます)。

キャッシュ制御: リクエストとレスポンスが続くキャッシュメカニズムを指定します。キャッシュディレクティブは一方向であり (応答に表示されるキャッシュディレクティブがリクエストに表示されない場合もあります)、独立しています (リクエストメッセージまたは応答メッセージで Cache-Control を設定しても、別のメッセージの処理中のキャッシュ処理は変更されません)。）。リクエスト中のキャッシュ命令には、no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached が含まれ、応答メッセージ内の命令には、public、private、no-cache、no が含まれます。 -store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。(リクエストヘッダーとレスポンスヘッダーの両方で、強制キャッシュについて)

キャッシュ制御:パブリッククライアントとサーバーの両方がキャッシュ可能

キャッシュ制御:プライベートクライアントがキャッシュできる

キャッシュ制御: キャッシュなしでは、キャッシュされたデータを検証するためにキャッシュを比較する必要があります

Cache-Control:no-store すべてのコンテンツはキャッシュされず、強制キャッシュも、比較キャッシュもトリガーされません。

Cache-Control:max-age キャッシュされたコンテンツは xxx 秒後に期限切れになります。

Cache-Control:min-fresh は、クライアントが現在時刻に指定された時間を加えた時間よりも短い応答時間で応答を受信できることを示します。

Cache-Control:max-stale は、クライアントがタイムアウト期間を超えて応答メッセージを受信できることを示します。max-stale メッセージの値を指定すると、クライアントはタイムアウト期間の指定された値を超える応答メッセージを受信する可能性があります。

受け入れる: ブラウザが受け入れることができる MIME タイプ。例: Accept: text/html は、ブラウザがサーバーポストバックのタイプを text/html として受け入れることができることを意味します。これは、私たちがよく HTML ドキュメントと呼ぶものです。

Accept-Encoding: ブラウザは受け入れることができるエンコード方式を宣言します。通常は、圧縮方式、圧縮をサポートするかどうか、サポートする圧縮方式 (gzip、deflate) を指定します。

Accept-Language: ブラウザは、受け入れる言語を宣言します。言語と文字セットの違い: 中国語は言語であり、中国語には big5、gb2312、gbk などの複数の文字セットがあります。

Accept-Charset: ブラウザで受け入れられる文字セット

ユーザーエージェント: クライアントが使用するオペレーティングシステムとブラウザの名前とバージョンをHTTPサーバーに伝えます。

Content-Type：例：Content-Type: application/x-www-form-urlencoded。

接続: 例:

接続: キープアライブ Web ページが開かれるとき、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアントがサーバー上の Web ページに再度アクセスすると、確立された接続が引き続き使用されます。接続です。HTTP 1.1 はデフォルトで永続的な接続を作成します。ページに複数の要素 (アプレット、画像など) が含まれている場合、永続的な接続を利用すると、ダウンロード時間が大幅に短縮されます。これを実現するには、サーブレットは応答で Content-Length ヘッダーを送信する必要があります。これを実現する最も簡単な方法は、まずコンテンツを ByteArrayOutputStream に書き込み、次にコンテンツを正式に書き出す前にそのサイズを計算することです。

Connection: close は、リクエストの完了後、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続が閉じられることを意味します。クライアントがリクエストを再度送信するときは、TCP 接続を再確立する必要があります。

リファラー: ユーザーが現在リクエストしているページにアクセスするための URL が含まれます。

ホスト: (このヘッダーフィールドはリクエストの送信時に必要です) これは主に、リクエストされたリソースのインターネットホストとポート番号を指定するために使用されます。通常は HTTP URL から抽出されます (http1.1 プロトコルに含まれている必要があります)

例: ブラウザに「http://www.guet.edu.cn/index.html」と入力すると、ブラウザから送信されるリクエストメッセージにはホストリクエストヘッダーフィールドが含まれます。ホスト: http://www.guet .edu.cn、ここではデフォルトのポート番号 80 が使用されます。ポート番号を指定する場合は、次のようになります。ホスト: ポート番号を指定します。

Cookie: 最も重要なリクエストヘッダーの 1 つで、Cookie の値を HTTP サーバーに送信します。

Content-Length: リクエストメッセージボディの長さを示します。

認可：認可情報

8.2 一般的な HTTP 応答ヘッダー

許可: サーバーがサポートするリクエストメソッド (GET、POST など)

Date: メッセージが送信された時刻を示し、時刻の記述形式はrfc822で定義されています。

期限切れ: ドキュメントが期限切れになったとみなされる時期を示します。そのため、ドキュメントはキャッシュされなくなり、サーバーから再度取得され、キャッシュが更新されます。

P3P: ドメイン間で Cookie を設定するために使用され、iframe のドメイン間での Cookie へのアクセスの問題を解決できます。

Set-Cookie: クライアントブラウザに Cookie を送信するために使用される非常に重要なヘッダーであり、書き込まれる各 Cookie によって Set-Cookie が生成されます。

例: Set-Cookie: sc=4c31523a; パス=/; ドメイン=.acookie.taabao.com

ETag: If-None-Match と組み合わせて使用されます。

Last-Modified: リソースの最終変更日時を示すために使用されます。Last-Modified は、setDateHeader メソッドを使用して設定することもできます。

Content-Type: WEB サーバーは、応答するオブジェクトのタイプと文字セットをブラウザーに伝えます。

例: Content-Type: text/html;charset=utf-8

Content-Length: エンティティ本体の長さをバイト単位で格納された 10 進数で示します。

Content-Encoding: WEB サーバーは、応答内のオブジェクトを圧縮するために使用する圧縮方法 (gzip、deflate) を示します。

Content-Range: エンティティ全体の一部の挿入位置を指定するために使用され、エンティティ全体の長さも示します。

コンテンツ言語: WEB サーバーは、応答するオブジェクトによって使用される自然言語をブラウザーに伝えます。

繋がり：

例: 接続: キープアライブ Web ページが開かれるとき、クライアントとサーバー間の HTTP データの送信に使用される TCP 接続は閉じられません。クライアントがサーバー上の Web ページに再度アクセスしても、接続は継続されます。この確立されたリンクを使用します。

場所: 新しい URL アドレスを含む新しい場所にリダイレクトするために使用されます。

更新: ブラウザがドキュメントを更新するまでの時間を秒単位で示します。

抜粋: http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.html

9 つの HTTP キャッシュメカニズム

WEB キャッシュ (キャッシュ) は、Web サーバーとクライアントの間に配置されます。

キャッシュは、リクエストに応じて、HTML ページ、画像、ファイルなどの出力コンテンツのコピーを保存します。次のリクエストが来たとき、同じ URL の場合、キャッシュはそのコピーを直接使用してアクセスリクエストに応答します。ソースサーバーにリクエストを再度送信します。

HTTP プロトコルは、Web キャッシュが可能な限り適切に機能するように関連するヘッダーを定義します。

9.1 キャッシュの利点

応答遅延の短縮: リクエストはオリジンサーバーではなくキャッシュサーバー (クライアントに近い) から処理されるため、プロセスにかかる時間が短縮され、Web サーバーの応答が速くなったように見えます。

ネットワーク帯域幅消費量の削減: レプリカが再利用されると、クライアントの帯域幅消費量が削減され、顧客は帯域幅コストを節約し、帯域幅要件の増加を制御し、管理を容易にすることができます。

9.2 http メッセージのキャッシュに関連するヘッダーフィールド

以下で使用できるヘッダー情報の一部を一般的に理解するために、キャッシュに関連する次のヘッダーフィールドを紹介します。

1. 共通ヘッダフィールド（リクエストメッセージとレスポンスメッセージの両方で使用できるフィールド）

2. リクエストヘッダーフィールド

3. 応答ヘッダーフィールド

4. エンティティヘッダーフィールド

9.3 キャッシュ方法

キャッシュとは、実際にはブラウザに保存されている情報を何らかのポリシールールに基づいて利用するかどうかを決定するもので、このキャッシュ情報はブラウザ内に存在するキャッシュデータベース（ローカルキャッシュとも言えます）と考えることができます。

サーバーへのリクエストを再度開始する必要があるかどうかに応じて分類され、2 つのカテゴリ (強制キャッシュと比較キャッシュ)に分類できます。

必須タイプではサーバーへのリクエストは必要ありませんが、比較キャッシュではサーバーへのリクエストが必要です。

9.3.1 強制キャッシュ

データがすでにキャッシュされていて、キャッシュ時間が期限切れになっていない場合は、強制キャッシュを使用します。

http1.0 の強制キャッシュには、Pragma (キャッシュの無効化を示す) と Expires (キャッシュの有効化とキャッシュ時間の定義) の 2 つのフィールドがあります。同時に使用すると、Pragma の優先順位が高くなりますが、応答メッセージの Expires で定義されたキャッシュ時間は、サーバー上の時刻を基準とします。クライアント上の時刻がサーバー上の時刻と一致しない場合 (特に、ユーザーが自分のコンピュータのシステム時間を変更した場合()、キャッシュ時間は無意味になる可能性があります。この問題を解決するために、http1.1 では新しいフィールド: Cache-Control (マスタリングに重点を置き、これをベンチマークとして使用します)を使用します。

注: http プロトコルとの下位互換性を保つために、多くの Web サイトでこれら 2 つのフィールドが依然として使用されていることがわかりますが、実際、これらは 2 つの使い捨てフィールドです。

キャッシュ制御

使用法: "キャッシュ制御":"キャッシュディレクティブ"

リクエストヘッダーとして使用する場合、cache-directive のオプションの値は次のとおりです。

応答ヘッダーとして使用される場合、cache-directive のオプションの値は次のとおりです。

実際には、プライベート、パブリック、no-cache、max-age、および no-store の 5 つの値に焦点を当てます。デフォルトはプライベートです。

プライベート: クライアントはキャッシュできます

public: クライアントとプロキシサーバーの両方をキャッシュできます (フロントエンドの学生はパブリックとプライベートを同じものとして考えることができます)

max-age=xxx: キャッシュされたコンテンツは xxx 秒後に期限切れになります

no-cache: キャッシュされたデータを検証するには比較キャッシュを使用する必要があります

no-store: すべてのコンテンツはキャッシュされず、強制キャッシュも比較キャッシュもトリガーされません。

例えば：

この図では、Cache-Control は max-age のみを指定しているため、デフォルトはプライベートで、キャッシュ時間は 31536000 秒 (365 日) です。

つまり、365 日以内にこのデータを再度リクエストすると、キャッシュデータベース内のデータが直接取得され、直接使用されます。

9.3.2 キャッシュの比較

キャッシュの比較: つまり、キャッシュが使用できるかどうかを判断するために比較が必要です。ブラウザが初めてデータを要求すると、サーバーはキャッシュ識別子とデータをクライアントに返し、クライアントは両方をキャッシュデータベースにバックアップします。再度データを要求する場合、クライアントはバックアップしたキャッシュIDをサーバーに送信し、サーバーはキャッシュIDに基づいて判定を行い、判定成功後はステータスコード304を返し、クライアントに相対的なデータ要求であることを通知します。成功し、キャッシュされたデータが使用できることを確認します。

キャッシュによって解決される問題を比較してください: キャッシュ時間が期限切れになりましたが、サーバーはリソースを更新していません。このとき、クライアントがサーバーにリソースの再送信を要求すると、帯域幅と時間が無駄になります。キャッシュを比較することは、クライアントが現在保存しているキャッシュファイルが実際にすべてのクライアント自身のファイルと一致していることをサーバーに知らせることであり、クライアントが独自のキャッシュを直接使用できるようになり、キャッシュの再利用率が向上します。

比較キャッシュは、リクエストヘッダとレスポンスヘッダのキャッシュ識別子に基づいて判定される。

キャッシュで使用されるキャッシュ識別フィールドを比較する

最終変更日 / 変更日以降

最終更新日：

サーバーがリクエストに応答すると、ブラウザーにリソースの最終変更時刻が通知されます。

変更日以降：

サーバーを再度リクエストする場合、このフィールドを使用して、最後のリクエスト中にサーバーから返されたリソースの最終変更時刻をサーバーに通知します。

リクエストを受信した後、サーバーは、If-Modified-Since ヘッダーがリクエストされたリソースの最終変更時刻と比較されていることを確認します。

リソースの最終変更時刻が If-Modified-Since よりも大きい場合、リソースが再度変更されたことを意味し、リソースコンテンツ全体が応答され、ステータスコード 200 が返されます。

リソースの最終変更時刻が If-Modified-Since 以下の場合は、リソースに新しい変更がないことを意味し、HTTP 304 で応答して、ブラウザーに保存されたキャッシュの使用を継続するように指示します。

Last-Modified は優れていますが、特に優れているわけではありません。リソースがサーバー上で変更されても、その実際のコンテンツがまったく変更されていない場合、Last-Modified 時刻が一致しないため、エンティティ全体がクライアントに返されるからです(クライアントキャッシュに同一のリソースがある場合)

ETag/ If-None-Match (Last-Modified/If-Modified-Since よりも高い優先度)

前述の Last-Modified の不正確性の可能性を解決するために、Http1.1 では ETag エンティティヘッダーフィールドも導入されました。

Etag は、リソースを識別するために暗号化アルゴリズムを使用してサーバーによって計算される一意の識別子として理解できます。クライアントが最初のリクエストを行うと、サーバーはそれをデータとともにクライアントに送信し、クライアントは ETag フィールドを保持します. を作成し、次のリクエストと一緒にサーバーに渡します。サーバーは、クライアントから送信された ETag が自身のサーバー上のリソースの ETag と一致するかどうかを比較するだけでよく、リソースがクライアントに対して変更されているかどうかを適切に判断できます。

Eタグ：

サーバーがリクエストに応答すると、サーバー上の現在のリソースの一意の識別子がブラウザーに通知されます (生成ルールはサーバーによって決定されます)。

一致しない場合：

再度サーバーに要求する場合、このフィールドを使用して、クライアントキャッシュデータの一意の識別子をサーバーに通知します。

サーバーはリクエストを受信し、If-None-Match ヘッダーがあることを検出すると、それをリクエストされたリソースの一意の識別子と比較します。

異なる場合は、リソースが再び変更されたことを示し、リソースの内容全体に応答してステータスコード 200 を返します。

これは、リソースに新たな変更がないことを示し、HTTP 304 で応答し、保存されたキャッシュを使用し続けるようにブラウザに指示します。

注: 同時に 2 つのフィールドのペアがある場合は、キャッシュを使用する前に両方のペアが通過する必要があります。

要約する

強制キャッシュの場合、サーバーはブラウザにキャッシュ時間を通知します。キャッシュ時間中、次のリクエストはキャッシュを直接使用します。時間内にない場合は、比較キャッシュポリシーが実行されます。

比較キャッシュでは、キャッシュ情報の Etag と Last-Modified がリクエストを通じてサーバーに送信され、サーバーによって検証され、ステータスコード 304 が返された場合、ブラウザはキャッシュを直接使用します。

ブラウザの最初のリクエスト:

ブラウザが再度リクエストすると、次のようになります。

抜粋: http://www.cnblogs.com/vajoy/p/5341664.html、http://www.cnblogs.com/chenqf/p/6386163.html

10. HTTP ステートレスの問題を解決する

10.1 Cookie による状態情報の保存

Cookieとは、実際にはユーザーを識別するために、クライアント上に保存されたり、Webサイトによってユーザーのローカル端末（クライアント側）に保存されたりするデータ（通常は暗号化されています）です。サーバーによって一時的にユーザーのコンピュータに保存されるデータ（.txt形式）です。テキストファイル）、HTTP送信のステータスは、サーバーによってコンピュータを識別するために使用されます。Web サイトを閲覧すると、Webサーバーはまず小さな情報をユーザーのコンピュータに送信し、Web サイト上で入力したテキストや選択肢を Cookie に記録します。

Cookie を通じて、サーバーはリクエスト 2 とリクエスト 1 が同じクライアントからのものであることを明確に知ることができます。

10.2 セッションを介したステータス情報の保存

セッションメカニズムはサーバー側のメカニズムであり、サーバーは情報を保存するためにハッシュテーブルに似た構造を使用します (またはハッシュテーブルを使用する場合もあります)。

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッション ID と呼ばれるセッション識別子が既に含まれているかどうかを確認します。セッション ID が含まれている場合は、このクライアントが以前に使用されたことを意味します。セッションを作成すると、サーバーはセッション ID に従ってセッションを取得し、それを使用します (取得できない場合は、新しいセッションを作成する可能性があります)。クライアントリクエストにセッション ID が含まれていない場合は、セッションが作成されます。クライアントとセッションは、このセッションで生成されます。関連付けられたセッション ID。セッション ID の値は、反復的でなく、偽造のパターンが簡単に見つからない文字列である必要があります。このセッション ID は、このセッションでクライアントに返されます。ストレージへの応答。

セッションの実装:

1. Cookie を使用して達成する

サーバーは各セッションに一意の JSESSIONID を割り当て、それを Cookie を通じてクライアントに送信します。

クライアントが新しいリクエストを開始すると、この JSESSIONID が Cookie ヘッダーに含まれます。このようにして、サーバーはクライアントに対応するセッションを見つけることができます。

2. URL ライトバックを使用して実現します

URL ライトバックとは、サーバーがブラウザーページに送信されるすべてのリンクに JSESSIONID パラメーターを含めることを意味します。これにより、クライアントがいずれかのリンクをクリックすると、JSESSIONID がサーバーに送信されます。ブラウザにサーバーリソースのURLを直接入力してリソースをリクエストした場合、セッションは照合されません。

Tomcat の Session 実装では、最初に Cookie と URL ライトバックの両方のメカニズムが使用されますが、クライアントが Cookie をサポートしていることが判明した場合は、引き続き Cookie を使用し、URL ライトバックの使用を停止します。Cookie が無効になっている場合は、必ず URL ライトバックを使用してください。JSP 開発がセッションを処理しているときは、ページ内のリンクに必ず response.encodeURL() を使用してください。

10.3. フォーム変数による状態の維持

Cookie に加えて、フォーム変数を使用して状態を維持することもできます。たとえば、Asp.net は、次のように、ViewState と呼ばれる Input="hidden" ボックスを通じて状態を維持します。

この原理は Cookie と似ていますが、各リクエストとレスポンスに添付される情報がフォーム変数になる点が異なります。

10.4. QueryString による状態の維持

QueryString は、要求されたアドレスの末尾に情報を保存することによって、サーバーに情報を送信します。通常、フォームと組み合わせて使用されます。典型的な QueryString は、次のようなものです: www.xxx.com/xxx.aspx?var1=value&var2=value2

注: ここで私自身の意見を共有したいと思います。状態を維持するということは、サーバーが特定の状態を識別することを意味すると感じています。これは実際にはセッションのメカニズムに非常によく似ています。詳細は以下を参照してください。

11 個のクッキーとセッション

11.1 意味

クッキーの仕組み

Cookie は、サーバーによってローカルマシンに保存される小さなテキストであり、リクエストごとに同じサーバーに送信されます。IETF RFC 2965 HTTP 状態管理メカニズムは、一般的な Cookie 仕様です。Web サーバーは、HTTP ヘッダーを使用してクライアントに Cookie を送信します。クライアント端末では、ブラウザがこれらの Cookie を解析し、ローカルファイルに保存します。これらの Cookie は、同じサーバーへのリクエストに自動的にバインドされます 。

具体的には、Cookie メカニズムはクライアント側で状態を維持するソリューションを使用します。これはユーザー側のセッション状態の保存メカニズムであり、ユーザーはクライアント側で Cookie サポートを有効にする必要があります。Cookie の役割は、HTTP プロトコルのステートレスな欠陥を解決するための取り組みです。

オーソドックスな Cookie の配布は HTTP プロトコルを拡張することで実現され、サーバーは HTTP 応答ヘッダーに特別な命令行を追加し、その命令に従って対応する Cookie を生成するようブラウザに指示します。ただし、JavaScript などの純粋なクライアント側スクリプトも Cookie を生成する可能性があります。Cookie の使用は、特定の原則に従ってブラウザによってバックグラウンドでサーバーに自動的に送信されます。ブラウザは、保存されているすべての Cookie をチェックします。宣言された Cookie のスコープが、リクエストされるリソースの場所以上である場合、Cookie はリクエストされたリソースの HTTP リクエストヘッダーに添付され、サーバーに送信されます。

Cookie の内容には主に、名前、値、有効期限、パス、ドメインが含まれます。パスとドメインを合わせて Cookie のスコープを形成します。有効期限が設定されていない場合、この Cookie の有効期間はブラウザセッション中であることを意味し、ブラウザウィンドウを閉じると Cookie は消えます。ブラウザーのセッション中に保持されるこのタイプの Cookie は、セッション Cookie と呼ばれます。セッション Cookie は通常、ハードディスクではなくメモリに保存されますが、もちろん、この動作は仕様で指定されていません。有効期限が設定されている場合、ブラウザは Cookie をハードディスクに保存します。ブラウザを閉じて再度開いても、設定された有効期限を超えるまでこれらの Cookie は有効です。ハードドライブに保存された Cookie は、2 つの IE ウィンドウなど、異なるブラウザプロセス間で共有できます。ブラウザが異なれば、メモリに保存された Cookie の処理方法も異なります。(そのため、メモリクッキーやハードディスククッキーもあります)

セッションメカニズムでは、サーバー側で状態を維持するソリューションが使用されます。同時に、サーバー側で状態を維持するソリューションではクライアント側でも ID を保存する必要があるため、セッションメカニズムでは ID を保存するという目的を達成するために Cookie メカニズムを使用する必要があることもわかりました。Session は、グローバル変数を管理する便利な方法を提供します。

セッションはユーザーごとに行われます。変数の値はサーバーに保存されます。セッション ID は、どのユーザーのセッション変数であるかを区別するために使用されます。この値は、アクセス時にユーザーのブラウザを通じてサーバーに返されます。クライアントが Cookie を無効にすると、この値は、get によってサーバーに返されるように設定することもできます。

セキュリティの観点: セッションを使用するサイトにアクセスしてマシン上に Cookie を作成する場合、顧客が保存した情報を勝手に読み取らないようにするため、サーバー側のセッションメカニズムをより安全にすることをお勧めします。

セッションメカニズム

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッション識別子 (セッション ID と呼ばれる) が既に含まれているかどうかを確認します。含まれている場合は、このクライアントに対して以前にセッションが作成されたことを意味します。サーバーはセッション ID に従ってセッションを取得し、それを使用します (取得できない場合は、新しいセッションが作成されます)。クライアントリクエストにセッション ID が含まれていない場合は、クライアント用にセッションが作成され、このセッションに関連付けられたセッション ID が生成されます。セッション ID の値は、繰り返されず、模倣するパターンが簡単に見つからない文字列である必要があります。このセッション ID は、保存のためにこの応答でクライアントに返されます。

このセッション ID を保存する方法には Cookie を使用できるため、対話プロセス中にブラウザはルールに従ってこの ID をサーバーに自動的に表示できます。通常、この Cookie の名前は SEEESIONID に似ています。ただし、Cookie は人為的に無効にすることができ、Cookie が無効になっている場合でもセッション ID をサーバーに戻す他のメカニズムが必要です。

頻繁に使用される手法は URL 書き換えと呼ばれ、URL パスの末尾にセッション ID を直接追加します。フォーム隠しフィールドと呼ばれる手法もあります。つまり、サーバーはフォームを自動的に変更し、非表示フィールドを追加して、フォームの送信時にセッション ID をサーバーに返すことができるようにします。

11.2 機能

これらはすべて状態を維持できるメカニズムです。

11.3 相違点

11.3.1 アクセス方法の違い

Cookie は ASCII 文字列のみを保存できます

セッションにはあらゆる種類のデータを保存できます

11.3.2 プライバシーポリシーの違い

Cookie はクライアントのブラウザに保存され、クライアントに表示されます。クライアント上の一部のプログラムは、Cookie の内容をスヌープ、コピー、さらには変更する可能性があります。セッションはサーバーに保存され、クライアントに対して透過的であるため、機密情報が漏洩するリスクはありません。

Cookie を選択する場合は、アカウントのパスワードなどの機密情報を Cookie に書き込まないようにすることをお勧めします。Google や Baidu のように Cookie 情報を暗号化し、サーバーに送信した後に復号化して、その人だけが Cookie 内の情報を読み取ることができるようにするのが最善です。Session を選択すると非常に簡単ですが、いずれにしてもサーバー上に配置されるため、Session 内のプライバシーは効果的に保護されます。

11.3.3 有効期限の違い

Google を使用したことのある人は、Google にログインしていれば、Google ログイン情報が長期間有効であることを知っています。Google はユーザーのログイン情報を永続的に記録するため、ユーザーはアクセスするたびに再度ログインする必要はありません。この効果を実現するには、Cookie を使用することをお勧めします。Cookie の有効期限属性を非常に大きな数値に設定するだけです。

Session は JSESSIONID という名前の Cookie に依存しており、Cookie JSESSIONID のデフォルトの有効期限は -1 であるため、ブラウザが閉じている限りセッションは無効になるため、Session は情報が永続的に有効であるという効果を得ることができません。URL アドレスの書き換えを使用してこれを実現することはできません。また、セッションタイムアウトの設定が長すぎると、サーバーに蓄積されるセッションが増えるほど、メモリオーバーフローが発生しやすくなります。

11.3.4 さまざまなサーバー圧力

セッションはサーバー側に保存され、各ユーザーがセッションを生成します。同時にアクセスするユーザーが多い場合、大量のセッションが生成され、大量のメモリを消費します。したがって、Google、Baidu、Sina などの同時訪問数が非常に多い Web サイトでは、Session を使用してユーザーセッションを追跡する可能性は低いです。

Cookie はクライアント側に保存され、サーバーのリソースを占有しません。同時に読んでいるユーザーが多い場合は、Cookie が良い選択です。Google、Baidu、Sina にとっては、Cookie が唯一の選択肢かもしれません。

11.3.5 ブラウザのサポートの違い

Cookie はクライアントのブラウザでサポートされている必要があります。クライアントが Cookie を無効にしている場合、または Cookie をサポートしていない場合、セッション追跡は無効になります。WAP 上のアプリケーションに関しては、通常の Cookie は役に立ちません。

クライアントのブラウザが Cookie をサポートしていない場合は、セッションと URL アドレスの書き換えを使用する必要があります。セッションプログラムを使用するすべての URL を書き換える必要があることに注意してください。書き換えないと、セッショントラッキングが無効になります。WAP アプリケーションの場合、セッション + URL アドレスの書き換えが唯一のオプションとなる場合があります。

クライアントが Cookie をサポートしている場合、Cookie はこのブラウザウィンドウとサブウィンドウ内で有効になるように設定する (有効期限を -1 に設定する) か、すべてのブラウザウィンドウで有効になるように設定する (有効期限を 2 に設定する) ことができます。整数 0 より大きい値）。ただし、Session は、このリーダーウィンドウとそのサブウィンドウ内でのみ有効です。2 つのブラウザウィンドウが互いに独立している場合、それらは 2 つの異なるセッションを使用します。(セッションはIE8では別のウィンドウに関連しています)

11.3.6 クロスドメインサポートの違い

Cookie はクロスドメインアクセスをサポートします。たとえば、ドメイン属性が「.biaodianfu.com」に設定されている場合、サフィックス「.biaodianfu.com」を持つすべてのドメイン名が Cookie にアクセスできます。クロスドメイン Cookie は現在、Google、Baidu、Sina などのインターネットで一般的に使用されています。セッションはクロスドメイン名アクセスをサポートしません。セッションは、それが存在するドメイン名内でのみ有効です。

Cookie のみを使用する場合、またはセッションのみを使用する場合は、期待どおりの結果が得られない場合があります。現時点では、Cookie とセッションを同時に使用するようにしてください。Cookie とセッションの組み合わせは、実際のプロジェクトにおいて多くの予期せぬ効果をもたらします。

11.4 連絡先

クライアントは初めてサーバーにリクエストを送信します。このとき、サーバーは一意のセッション ID を生成し、(Cookie を介して) クライアントに返します。これはクライアントのメモリに保存され、ブラウザウィンドウに相当します。 HTTPプロトコルの特性上、今回は接続が切れてしまいました。

このクライアントが将来サーバーにリクエストを送信するとき、リクエストには Cookie が含まれます。Cookie にはセッション ID が含まれているため、サーバーはこれが今のクライアントであることを認識します。

言い換えれば、Cookie はセッション ID の識別子を保存できます。

からの抜粋: http://blog.csdn.net/weixin_37196194/article/details/55806366

http2 の 12 の新機能

http2 2015年リリース

12.1 バイナリプロトコル

HTTP/1.1 バージョンのヘッダー情報はテキスト (ASCII エンコーディング) である必要があり、データ本体はテキストまたはバイナリです。HTTP/2 は完全なバイナリプロトコルであり、ヘッダー情報とデータ本体は両方ともバイナリであり、ヘッダー情報フレームとデータフレームを総称して「フレーム」と呼びます。

バイナリプロトコルの利点の 1 つは、追加のフレームを定義できることです。HTTP/2 は 10 種類近くのフレームを定義し、将来の高度なアプリケーションの基礎を築きます。テキストを使用してこの関数を実装すると、データの解析が非常に面倒になるため、バイナリ解析の方がはるかに便利です。

12.2 複数のタスク

HTTP/2 は TCP 接続を再利用するため、クライアントとブラウザの両方が 1 つの接続で、順番に 1 対 1 に対応することなく複数のリクエストまたは応答を同時に送信できるため、「ヘッドオブラインの輻輳」が回避されます。(キューヘッドブロックとは、クライアントまたはサーバーがメッセージを送信するときに、データの一部が大きすぎると時間がかかり、後で送信を待機するものが大量に発生して輻輳が発生することを意味します)

例えば、TCP接続において、サーバーはAリクエストとBリクエストを同時に受信したため、先にAリクエストに応答しましたが、処理に時間がかかることが判明したため、Aリクエストの処理済み部分を送信しました。リクエストを送信し、B リクエストに応答し、完了したら A リクエストの残りの部分を送信します。

このような双方向のリアルタイム通信は多重化と呼ばれます。

12.3 データパケット

マルチタスク機能により、http2 データパケットは順不同で送信され、同じ接続内の連続したデータパケットが異なる応答に属する可能性があります。したがって、パケットがどの応答に属するかを示すためにパケットにマークを付ける必要があります。

HTTP/2 では、各リクエストまたは応答のすべてのデータパケットをデータストリームと呼びます。各データストリームには一意の番号があります。データパケットが送信されるときは、どのデータフローに属しているかを区別するためにデータフロー ID をマークする必要があります。また、クライアントが送信するデータストリームのIDは常に奇数、サーバーが送信するデータストリームのIDは偶数であることも規定されている。

データストリームが途中で送信されると、クライアントとサーバーの両方が信号 (RST_STREAM フレーム) を送信してデータストリームをキャンセルできます。バージョン 1.1 でデータフローをキャンセルする唯一の方法は、TCP 接続を閉じることです。これは、HTTP/2 が TCP 接続を開いたままにし、他のリクエストに使用できるようにしながら、リクエストをキャンセルできることを意味します。

クライアントはデータストリームの優先順位を指定することもできます。優先順位が高いほど、サーバーはより早く応答します。

12.4 ヘッダー圧縮

HTTP プロトコルはステートレスであり、すべての情報をすべてのリクエストに添付する必要があります。したがって、Cookie やユーザーエージェントなど、リクエスト内の多くのフィールドが繰り返され、すべてのリクエストにまったく同じ内容を含める必要があるため、大量の帯域幅が無駄になり、速度にも影響します。

HTTP/2 はこれを最適化し、ヘッダー圧縮を導入しました。一方では、ヘッダー情報は送信前に gzip または compress を使用して圧縮されますが、他方では、クライアントとサーバーは同時にヘッダー情報テーブルを維持し、すべてのフィールドがこのテーブルに格納され、インデックス番号が付けられます。が生成されるため、今後同じフィールドが送信されなくなります。インデックス番号のみが送信されるため、速度が向上します。

12.5 サーバープッシュ

HTTP/2 を使用すると、サーバーはリクエストなしでリソースをクライアントにアクティブに送信できます。これはサーバープッシュと呼ばれます。

一般的なシナリオは、クライアントが多くの静的リソースを含む Web ページを要求することです。通常の状況では、クライアントは Web ページを受信し、HTML ソースコードを解析し、静的リソースを見つけて、静的リソースリクエストを発行する必要があります。実際、サーバーは、クライアントが Web ページをリクエストした後、静的リソースを再度リクエストする可能性が高いと予想できるため、これらの静的リソースを Web ページとともにクライアントに積極的に送信します。

ここで検索して、Ruan Yifeng のブログにある http プロトコルに関する記事を読むことができます。短くて簡潔です。

Web フロントエンド ブラウザの章 - HTTP プロトコルに関する知識の概要