HTTPプロトコルとキャッシュの原理分析についての深い理解

3.2 キャッシュの実装原理

3.2.1 Webキャッシュとは

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

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

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

3.2.2 キャッシュの利点

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

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

3.2.3 キャッシュに関連する HTTP 拡張メッセージヘッダー

Expires: 応答コンテンツの有効期限が切れる時刻、グリニッジ標準時 GMT を示します

Cache-Control: キャッシュされたコンテンツのより詳細な制御

Last-Modified: 応答でリソースが最後に変更された時刻

ETag: 応答内のリソースのチェック値。一定期間サーバー上で一意に識別されます。

Date: サーバー時間

If-Modified-Since: クライアントがアクセスしたリソースが最後に変更された時間 (Last-Modified と同じ)。

If-None-Match: クライアントがアクセスしたリソースのチェック値。ETag と同じです。

3.2.4 クライアントキャッシュを有効にするための共通プロセス

サーバーがリクエストを受信すると、200OK でリソースの Last-Modified ヘッダーと ETag ヘッダーを送り返します。クライアントはリソースをキャッシュに保存し、記録します。これら 2 つの属性です。クライアントが同じリクエストを送信する必要がある場合、リクエスト内に If-Modified-Since と If-None-Match という 2 つのヘッダーが含まれます。 2 つのヘッダーの値は、応答の Last-Modified ヘッダーと ETag ヘッダーの値です。サーバーは、これら 2 つのヘッダーによってローカル リソースが変更されていないと判断し、クライアントはそれを再度ダウンロードする必要がなく、304 応答を返します。共通のプロセスを以下の図に示します。

3.2.5 Web キャッシュのメカニズム

HTTP/1.1 でのキャッシュの目的は、多くの場合、送信されるリクエストの数を減らすことであり、多くの場合、キャッシュはありません。完全な応答を送信する必要があります。前者はネットワーク ループの数を減らします。HTTP はこの目的で「有効期限」メカニズムを利用します。後者はネットワーク アプリケーションの帯域幅を削減します。HTTP はこの目的で「検証」メカニズムを使用します。

HTTP は 3 つのキャッシュ メカニズムを定義します:

1) 鮮度: 応答メッセージをソース サーバーで再チェックできるようにし、サーバーとクライアントによって制御できます。たとえば、Expires 応答ヘッダーは、ドキュメントが利用できなかった時間を示します。 Cache-Control の max-age フラグは、最大キャッシュ時間を示します。

2) 検証: キャッシュされた応答がまだ利用可能かどうかを確認するために使用されます。たとえば、応答に Last-Modified 応答ヘッダーがある場合、キャッシュは If-Modified-Since を使用して変更されたかどうかを判断し、状況に応じてリクエストを送信するかどうかを決定できます。3) 無効化:別のリクエストがキャッシュを通過すると、多くの場合、副作用が発生します。たとえば、URL がキャッシュされた応答に関連付けられているが、その後に POST、PUT、および DELETE リクエストが続く場合、キャッシュは期限切れになります。

3.3 ブレークポイント再開とマルチスレッドダウンロードの実装原理

HTTP プロトコルの GET メソッドは、リソースの特定の部分のみのリクエストをサポートします;

206 Partial Content 部分コンテンツ応答;

Range 要求されたリソース範囲;

Content-Range 応答のリソース範囲。

接続が切断されて再接続されると、クライアントはブレークポイントの再開を達成するためにリソース全体を再要求するのではなく、リソースの未ダウンロードの部分のみを要求します。

ブロックされたリクエストリソースの例:

Eg1: Range: bytes=306302-: このリソースの306302バイトから最後までの部分をリクエストします。

Eg2: Content-Range: bytes 306302-604047/604048: 応答で示されます。これはリソースの 306302 ～ 604047 バイトを伝送し、リソースには合計 604048 バイトがあります。クライアントは、同じリソースの異なるフラグメントを同時に要求することで、特定のリソースの同時ブロック ダウンロードを実現します。高速ダウンロードの目的を達成するため。現在普及している FlashGet と Thunder は基本的にこの原理を使用しています。

マルチスレッドダウンロードの原理:

ダウンロード ツールは、HTTP リクエストを発行する複数のスレッドを開きます。

各 http リクエストはリソース ファイルの一部のみをリクエストします: Content-Range: バイト 20000-40000/47000。各スレッドのダウンロードしたファイルをマージします。

3.4 https通信プロセス

3.4.1 https

HTTPS（正式名称：Hypertext Transfer Protocol over Secure Socket Layer）とは、簡単に言えば、セキュリティを目的としたHTTPチャネルです。つまり、HTTP に SSL 層が追加されています。HTTPS のセキュリティ基盤は SSL です。暗号化の詳細については、「SSL」を参照してください。

下の図を参照してください:

httpsで使用されるポート番号は443です。