[コンピュータ ネットワーク ノート 6] アプリケーション層 (3) HTTP Cookie、キャッシュ コントロール、プロキシ サービス、短い接続と長い接続

HTTP クッキー

HTTP のCookieメカニズムは、応答ヘッダー フィールドSet-Cookieと要求ヘッダー フィールドCookie の2 つのフィールドを使用します。

Cookie では複数のキーと値のペアを設定でき、複数のSet-Cookieフィールドを応答ヘッダーに設定でき、複数のキーと値のペアをリクエスト ヘッダー Cookie の後にセミコロンで区切って設定できます。

有効期限と最大有効期間

Cookie の有効期間は、Expires プロパティとMax-Ageプロパティを使用して設定できます。

• Expires は絶対的な有効期限、つまり一般に「有効期限」として知られる期限を表します。
• Max-Age は、相対的な有効期間を秒単位で表します。ブラウザは、メッセージを受信した時点にMax-Ageを加算することで、有効期限の絶対時刻を取得できます。

ExpiresとMax-Age は同時に表示される可能性があり、この 2 つの有効期限は一致している場合も一致していない場合もありますが、ブラウザはMax-Ageを優先して有効期限を計算します。

ドメインとパス

他の Web サイトによる盗用を避けるために、ブラウザーがCookie を特定のサーバーと URL にのみ送信できるように、Cookie の範囲を設定する必要があります。

「ドメイン」と「パス」は、 Cookie が属するドメイン名とパスを指定します。Cookieを送信する前に、ブラウザはURIからホスト部分とパス部分を抽出し、Cookie 属性を比較します。条件が満たされない場合、 Cookie はリクエスト ヘッダーで送信されません。

HTTPのみ

属性「HttpOnly 」は、このCookie がHTTPプロトコルを通じてのみ送信され、他の方法でのアクセスが禁止されていることをブラウザに伝えます。ブラウザのJSエンジンは、スクリプト攻撃を防ぐために関連するすべての API を無効にしますdocument.cookie。

同じサイト

もう 1 つの属性「SameSite」は「クロスサイト リクエスト フォージェリ」 ( XSRF ) 攻撃を防ぐことができます。これを「 SameSite=Strict 」に設定すると、ジャンプ リンクのあるサイト間でCookie が送信されるのを厳しく制限できますが、「SameSite=Lax」は少し緩めです。GET / HEADなどの安全なメソッドを許可しますが、 POST のクロスサイト送信は禁止します。

HTTPキャッシュ制御

一般に、ブラウザは応答コンテンツを取得した後、その応答コンテンツをディスク ファイルにキャッシュします。

ブラウザがローカル ディスク キャッシュ内のコンテンツを直接使用するかどうかは、キャッシュ ポリシーによって異なります。ブラウザには、ディスク上のキャッシュされたページを定期的にクリアするキャッシュ クリーニング ポリシーもあります。

キャッシュ戦略: ストアなし

クライアントは、フラッシュ セール ページなど、非常に頻繁に変更される一部のデータに使用されるキャッシュを使用することはできません。

キャッシュ戦略: max-age

時間計算の開始点は、クライアントがメッセージを受信した時間ではなく、応答メッセージの作成時間です。つまり、リンク送信プロセス中にすべてのノードが費やした時間が含まれます。

リソースの有効期間をマークするためにサーバーが使用するヘッダー フィールドは「Cache-Control 」で、その中の値「 max-age=30」はリソースの有効期間です。これはブラウザに「これは」と伝えるのと同じです。ページは 30 秒間のみキャッシュできるため、期限切れとみなされます。」、使用できません。( max-ageには、移動に費やした時間が含まれます。実際の有効時間は、移動に費やした時間から差し引く必要があります) ）

キャッシュ戦略: サーバーとクライアントの連携

クライアントはCache-Control: max-age=0を送信して、クライアントはキャッシュを使用しないが、ブラウザはキャッシュを使用して前後に移動することをサーバーに伝えます。サーバーがmax-age=0を認識すると、最新に生成されたメッセージがブラウザに送り返されます。

キャッシュポリシー: キャッシュなし

クライアントによって送信される" Cache-Control:no-cache " の意味は、基本的に" Cache-Control:max-age=0 " と同じです。バックグラウンド サーバーがそれをどのように理解するかによって異なります。通常、この 2 つの効果は次のとおりです。同じ。

サーバーが「Cache-Control:no-cache」を送信するときは、キャッシュが許可されていないことを意味するのではなく、キャッシュできることを意味しますが、使用する前に、サーバーにアクセスして、有効期限が切れているかどうか、および有効期限が切れているかどうかを確認する必要があります。最新バージョンがあります。

キャッシュの有効期限が切れたことを確認する方法

クライアントにHEADリクエストを送信させると、サーバーがLast-Modifiedを通じて変更時刻を返すことができます。

次に、クライアントはそれをキャッシュされたデータと比較し、変更がない場合はキャッシュを使用してネットワーク トラフィックを節約し、変更がない場合は別のGETリクエストを送信して最新バージョンを取得します。しかし、このような 2 つのリクエストのネットワーク コストは高すぎます。

条件付きリクエスト

サーバーは、If-Modified-Sinceの値をLast-Modifiedセグメントと比較します。それらが等しい場合は、変更されていないことを意味し、304で応答します。

If -Modified-Sinceの値がLast-Modifiedと等しくない場合は、変更されていることを意味し、ステータス コード200で応答し、データを返します。

If-Modified-Since および Last-Modified を使用する場合の欠点:

1. 最小時間単位は秒であり、リソース更新速度が秒未満の場合、キャッシュは使用できません。

2. ファイルがサーバー経由で動的に生成される場合、ファイルは変更されていない可能性がありますが、このメソッドの更新時間は常に生成時間となるため、キャッシュとして機能しません。

解決策: Etag と If-None-Match

Etag と If-None Match

ETagは「Entity Tag」の略で、リソースの一意の識別子を表します。

サーバーは、ETagフィールドを含む応答ヘッダーを送信します。クライアントはETagフィールド値を取得して次のリクエストを行うとき、リクエスト ヘッダーのIf-None-Matchフィールドを使用して値を送信します。サーバーは値を取得して比較します。 ETagを使用します。ETagが等しい場合、リソースは変更されていないことを意味します。サーバーはステータス コード304を返し、クライアントはローカル ディスクを使用してファイルをキャッシュします。

サーバーがEtagと等しくないと判断した場合は、リソースが変更されたことを意味し、サーバーはステータス コード200を返し、新しいリソース ファイルの内容をbodyで返します。

サーバー側のキャッシュ制御戦略とクライアント側のキャッシュ制御戦略の詳細なフローチャート: https://www.processon.com/view/link/62bec42a6376897b9fcfdb47

HTTPプロキシサービス

プロキシは、HTTP プロトコルにおけるリクエスターとレスポンダー間のリンクであり、「中継ステーション」として、クライアントのリクエストとサーバーのレスポンスの両方を転送できます。

フォワードプロキシ

フォワード プロキシ: クライアントに近く、クライアントに代わってリクエストをサーバーに送信します。

プロキシサーバーがクライアントアクセス制御を実行する方法:

リバースプロキシ

リバース プロキシ: サーバーに近く、サーバーに代わってクライアントの要求に応答します。

リバースプロキシ負荷分散：

リバース プロキシの最も基本的な機能の 1 つは負荷分散です。ソース サーバーがクライアントに直面するときにブロックされるため、クライアントにはプロキシ サーバーのみが表示され、ソース サーバーが何台あるか、それらがどのような IP アドレスであるかはわかりません。

したがって、プロキシ サーバーはリクエストを分散する「権限」を持ち、後続のどのサーバーがリクエストに応答するかを決定できます。

リバース プロキシのその他の機能:

• ① ヘルスチェック: 「ハートビート」などのメカニズムを使用してバックエンドサーバーを監視し、障害が見つかった場合は直ちにクラスターを「追い出し」、高いサービス可用性を確保します。
• ② セキュリティ保護: プロキシされたバックエンドサーバーを保護し、IP アドレスやトラフィックを制限し、ネットワーク攻撃や過負荷に抵抗します。
• ③ 暗号化オフロード: 外部ネットワークには SSL/TLS 暗号化通信認証を使用しますが、安全なイントラネット上では暗号化を行わないため、暗号化と復号化のコストが不要になります。
• ④データフィルタリング：上流および下流のデータを傍受し、ポリシー変更要求または応答を任意に指定します
• ⑤ コンテンツキャッシュ：サーバー応答の一時保存と再利用

プロキシ関連のヘッダーフィールド

プロキシ サーバーは、フィールド「Via」を使用してプロキシの ID を示す必要があります。「Via」はプロキシのホスト名 (またはドメイン名) を追加します。

Viaフィールドはクライアントとソースサーバーがプロキシの有無を判断する問題を解決するだけであり、相手の本当の情報を知ることはできません。

• 「_ _ _ _
• 「_ _

HTTP キャッシュ プロキシ

サーバーへの負荷を軽減するために、サーバーにも対応するキャッシュが用意されており、HTTP のサーバー キャッシュ機能は主にリバース プロキシ サーバー(つまり、キャッシング プロキシ) によって実装されます。

CDN

CDN :コンテンツ配信ネットワークはネットワーク アプリケーション サービスであり、正式名称はコンテンツ デリバリー ネットワークまたはコンテンツ配信ネットワークであり、その主な機能は「長距離」でのネットワーク アクセス速度の遅さの問題を解決することです。

• ① エッジノードがキャッシュエージェントとして機能する
• ②お近くに訪問

CDN は主に静的リソースをキャッシュします。「静的リソース」: 画像や音声など。「動的リソース」とは、データの内容が「動的に変化する」ことを意味します。つまり、バックグラウンドサービスによって計算および生成され、商品の在庫、Weiboのファンの数など、アクセスするたびに異なります。等

CDN の原理:

• ① ユーザーが Web サイトのページ上のコンテンツ URL をクリックすると、ローカル DNS システムによって解析された後、DNS システムは最終的に CNAME が指す CDN 専用 DNS サーバーにドメイン名解決権限を引き渡します。

• ② CDN の DNS サーバーは、CDN のグローバル負荷分散デバイスの IP アドレスをローカル ドメイン ネーム サーバーに返します。

• ③ ローカル ドメイン ネーム サーバーは、CDN グローバル ロード バランシング デバイスの IP アドレスをクライアントに返します。

• ④ CDN グローバル負荷分散デバイスは、ユーザーの IP アドレスとユーザーが要求したコンテンツ URL に基づいて、ユーザーのリージョン内のリージョナル負荷分散デバイスを選択し、このデバイスへの要求を開始するようにユーザーに指示します。

• ⑤ 地域負荷分散装置は、ユーザー
  の IP アドレスに基づいてユーザーに最も近いサーバーを判断する、
  要求された URL に含まれるコンテンツ名に基づいて判断するなど、ユーザーにサービスを提供するために適切なキャッシュ サーバーを選択します。どのサーバーにユーザーが必要とするコンテンツがあるか。
  各サーバーの現在の負荷ステータスをクエリして、どのサーバーがまだサービス機能を持っているかを判断します。

• ⑥ 上記の状況を総合的に分析した後、リージョナル負荷分散装置はキャッシュサーバのIPアドレスをグローバル負荷分散装置に返却します。

• ⑦ グローバル負荷分散装置は、サーバーのIPアドレスをユーザーに返します。

• ⑧ 利用者がキャッシュサーバにリクエストを送信すると、キャッシュサーバは利用者のリクエストに応じて、利用者が要求したコンテンツを利用者端末に送信します。このキャッシュ サーバーにユーザーが必要とするコンテンツがないにもかかわらず、地域バランシング デバイスがそれをユーザーに割り当てている場合、このサーバーは、ソース サーバーまで追跡されるまで、上位レベルのキャッシュ サーバーからコンテンツを要求します。コンテンツをローカルにプルします。

簡単にまとめると、CDN負荷分散装置はユーザーに最も近いキャッシュサーバーのIPアドレスをユーザーに返し、このキャッシュサーバーにユーザーが必要とするコンテンツがない場合は、追跡されるまで上位のキャッシュサーバーにリクエストを送信します。ソース サーバーに戻され、コンテンツはローカルにプルされます。

HTTP の短い接続と長い接続

短い接続

クライアントとサーバー間の接続プロセス全体は非常に短く、サーバーとの接続状態が長期間維持されないため、これは ショート接続と呼ばれます。

TCP プロトコルでは接続の確立と終了が非常に「コストのかかる」操作であるため、短い接続の欠点は非常に深刻です。

TCP では、接続を確立するには「3 ウェイ ハンドシェイク」が必要で、3 つのデータ パケットを送信して 1 RTT が必要です。接続を閉じるには「4 つのハンドシェイク」が必要で、4 つのデータ パケットには 2 RTT が必要です。

長い接続

クライアントとサーバーは長期間の接続を維持するため、ロング接続と呼ばれます。

コストの償却: TCP の接続と切断には非常に時間がかかるため、時間コストは元の「要求 - 応答」から複数の「要求 - 応答」に均等に割り当てられます。

長時間接続の実装方法: heartbeat。つまり、一定の間隔内で、TCP接続は非常に短い無意味なメッセージの送信に使用され、ゲートウェイが自身を「アイドル接続」として定義できなくなり、ゲートウェイが自身の接続を閉じることができなくなります。

長時間接続するとパフォーマンスが大幅に向上するため、HTTP/1.1 のすべての接続ではデフォルトで長時間接続が有効になります。

接続関連のヘッダーフィールド

リクエスト ヘッダーで長い接続メカニズムの使用を明示的に要求することもできます。使用されるフィールドはConnectionで、値は「keep-alive」です。

ただし、クライアントが明示的に長い接続を必要とするかどうかに関係なく、サーバーが長い接続をサポートしている場合は、常に応答メッセージに「Connection:keep-alive」フィールドを追加して、クライアントに次のように伝えます。常にこの TCP を使用してデータを送受信します。」

長時間接続のデメリット

TCP 接続が長期間閉じられない場合、サーバーはその状態をメモリに保存する必要があり、これによりサーバーのリソースが消費されます。接続されていないアイドル状態の長い接続が多数存在すると、サーバーのリソースがすぐに枯渇してしまい、サーバーは本当にサービスを必要とするユーザーにサービスを提供できなくなります。

したがって、長い接続も適切なタイミングで閉じる必要があり、サーバーへの接続を永久に維持することはできません。クライアントとサーバーの両方が適切な方法で接続を閉じることができます。

クライアントは長い接続を積極的に閉じます

クライアント側では、リクエスト ヘッダーに「Connection:close」フィールドを追加して、サーバーに「この通信の後に接続を閉じる」ように指示できます。

サーバーはこのフィールドを確認すると、クライアントが接続を積極的に閉じようとしていることを認識するため、このフィールドを応答メッセージに追加し、送信後にTCP接続を閉じます。

サーバーは長い接続を積極的に閉じます

通常、サーバーは積極的に接続を閉じませんが、いくつかの戦略を使用することもできます。Nginx を例に挙げると、次の 2 つの方法があります。

• ①「keepalive_timeout」コマンドを使用して、長い接続のタイムアウトを設定します。一定時間内に接続でデータの送受信がない場合、アイドル状態の接続がシステム リソースを占有するのを避けるために、接続はアクティブに切断されます。

• ②「keepalive_requests」コマンドを使用して、長い接続で送信できるリクエストの最大数を設定します。たとえば、1000 に設定すると、Nginx はこの接続で 1000 件のリクエストを処理した後にアクティブに切断します。

行頭ブロック

キューの先頭にあるリクエストの処理が遅すぎるために遅延すると、キュー内の後続のリクエストはすべて一緒に待機する必要があり、この問題はキューの先頭でブロックされることになります。

行頭ブロックの問題を解決するにはどうすればよいですか?

• 同時接続 + ドメイン名のシャーディング

• 「同時接続」: つまり、ブラウザ プロセスがドメイン名への複数の長い接続を同時に開始します。
  
  
  注: HTTP プロトコルとブラウザでは、ドメイン名への同時接続の数が 6 ～ 8 に制限されています。

• ドメイン名のシャーディング: サーバーは複数の異なるドメイン名を使用して同じ IP を指すため、サーバーの負荷を軽減できます。
  
  

  一般に、企業は同じ IP を指すために複数の異なるドメイン名を使用します。各ドメイン名は 6 ～ 8 個のロング接続をサポートできるため、3 つのドメイン名で 18 ～ 24 個のロング接続をサポートできます。

HTTP 1.1 と HTTP 1.0 のいくつかの違い

HTTP 1.0は1996 年に初めて Web ページで使用され、当時は一部の比較的単純な Web ページとネットワーク リクエストにのみ使用されていましたが、HTTP 1.1 が主要なブラウザのネットワーク リクエストで広く使用され始めたのは1999 年のことです。同時に、 HTTP 1.1 は現在最も広く使用されている HTTP プロトコルでもあります。主な違いは主に次の点に反映されます。

1. キャッシュ処理については、HTTP 1.0 では主にヘッダー内のIf-Modified-SinceとExpires がキャッシュ判定の基準として使用されていましたが、HTTP 1.1 ではEntity タグ、If-Unmodified-Since、If-Match、If-None-Matchおよびその他のオプションのキャッシュ ヘッダーを使用して、キャッシュ戦略を制御します。
2. 帯域幅の最適化とネットワーク接続の使用。HTTP 1.0 では、帯域幅を浪費する現象がいくつかあります。たとえば、クライアントはオブジェクトの一部のみを必要としますが、サーバーはオブジェクト全体を送信し、ブレークポイント再開機能をサポートしません。 HTTP 1.1 では、リクエスト ヘッダーにrangeヘッダー フィールドが導入されており、これによりリソースの特定の部分、つまりリターン コードが206 (部分コンテンツ) のみをリクエストできるようになり、開発者が帯域幅と帯域幅を最大限に活用することを自由に選択できるようになります。接続。
3. エラー通知の管理のために、24 の新しいエラー ステータス応答コードが HTTP 1.1 に追加されました。たとえば、409 ( Conflict ) は、要求されたリソースがリソースの現在のステータスと競合していることを示し、410 ( Gone ) は、リソースがオンになっていることを示します。サーバーは完全に削除されます。
4. Host ヘッダーは必須です。HTTP 1.0 では、各サーバーは一意の IP アドレスにバインドされていると見なされます。そのため、リクエスト メッセージ内の URL はホスト名を渡しません。しかし、仮想ホスト技術の発展により、物理サーバー上に複数の仮想ホスト (マルチホーム Web サーバー) が存在し、IP アドレスを共有できるようになりました。HTTP 1.1 リクエスト メッセージとレスポンス メッセージはHostヘッダー フィールドをサポートする必要があり、リクエスト メッセージにHostヘッダー フィールドがない場合、エラー ( 400 Bad Request ) が報告されます。
5. 永続的な接続はデフォルトで有効になっています。HTTP 1.1 は永続的な接続 (PersistentConnection) とリクエスト パイプライン (Pipelining) 処理をサポートしています。複数の HTTP リクエストと応答を TCP 接続で送信できるため、接続の確立と終了の消費と遅延が削減されます。HTTP 1.1 ではConnection:keep-alive はHTTP 1.0ではデフォルトでオンになっており、リクエストごとに接続を作成する必要がある HTTP 1.0 の欠点をある程度補います。

HTTP 1.0 と HTTP 1.1 の最大の違いは、HTTP 1.1 は長い接続をサポートし、TCP の確立と終了の回数を減らし、1 つの TCP 接続で複数の HTTP リクエストを実行できることです。