CDNの概要
CDNは誰にでもよく知られています。ここでは簡単な紹介です。
CDNを使用すると、ユーザーは、実際にサービスを提供するマシンにアクセスする代わりに、リソースにアクセスするときに、ユーザーに非常に近いCDNノードからリソースを取得できます。CDNは
- ユーザーが必要なコンテンツをより速く入手できるようにする
- バックボーンネットワークトラフィックを削減する
- サーバーの負荷を軽減
CDNは3つの段階を経ています
最初のフェーズ1995年、インターネットの発明者であるティムは、最初のCDNサービス会社であるアカマイを設立しました。
インターネット開発のクライマックスである第2ステージ1999〜2001、CDNは急速に発展しました
第3段階では、2001年にインターネットが崩壊し、CDN企業が破産し、ティムの企業も破産しました。2002年に始まり、ブロードバンドのアップグレード、ゲーム、ビデオ開発により、CDNが開発されました。
CDNは20年以上の開発経験がありますが、まだ標準仕様を形成しておらず、各企業の具体的な実装は異なります。この記事では、1つのタイプについてのみ説明し、CDNについて理解を深めていただければ幸いです。
CDNリクエストプロセス
CDNリクエストのプロセスは下図に示すとおりです。以下に簡単に紹介します。左側の実線のボックスはDNSルックアップフェーズで、右側の点線のボックスはCDNのスコープです。https://www.processon.com/view/link/5ed5175e0791291d5dba30ea
DNSルックアップフェーズ
ユーザーがブラウザでevent.mi.comなどのリンクをリクエストすると、ブラウザはドメイン名に対応するIPアドレスを見つける必要があります
-
最初に、マシンのDNSクライアントにレコードがあるかどうか、レコードがないかどうかを確認します
-
ローカルDNSサーバーにレコードがない場合は、ローカルDNSサーバーから取得します。
-
ルートドメインネームサーバー（全世界で13のルートドメインネームサーバー）から検索すると、ルートドメイン名はcomドメインネームサーバーのアドレスを返します
-
ローカルDNSサーバーはcomドメインネームサーバーからルックアップし、comドメインネームサーバーはevent.mi.comの信頼できるドメインネームサーバーアドレスを返します。
- 権限のあるドメイン名DNSサーバー：ドメイン名のすべての情報が含まれています
- 信頼できるドメインネームサーバーを見つけた後、ドメイン名にCNAMEがあることがわかります。このCNAMEは通常、CDNのグローバルロードバランシングシステムを指します。
-
DNS Aレコード
- Aレコードの形式は「domain name-ip」で、レコードはドメイン名に対応するサーバーのIPアドレスです
-
DNS CNAME
CNAMEはドメイン名のエイリアスで、通常2つの機能があります
1）複数のドメイン名が同じサービスIPをポイントしているサービスIPが変更された場合、変更する必要があるAレコードは1つだけです。たとえば、ドメイン名www.abc.comのAレコードは1.1.1.1であり、ドメイン名mail.abc.comおよびstudy.abc.comのエイリアスはwww.abc.comに設定できるため、サービスがIPアドレスを変更したときにのみ、 www.abc.comのAレコードを変更する必要があります。他のドメイン名を変更する必要がなく、メンテナンスコストを削減できます
2）CDNでのCNAMEの役割も非常に重要です。CDNでドメイン名をハングアップするには、ドメイン名のCNAMEをCDNプロバイダーから提供されたドメイン名に設定して、CDNプロバイダーがDNSを介してCDNにトラフィックを転送できるようにする必要があります。さらに、ドメイン名のCNAMEがCDNのドメイン名に設定された後、ドメイン名のAレコードは存在できません。通常、nslookupコマンドとdigコマンドを使用してDNS解決を表示できます下の図に示すように、ドメイン名event.mi.comのCNAMEはBaishan Cloudのドメイン名であることがわかります。さらに、Baishan Cloudのドメイン名にも対応するCNAMEがあることがわかります。これは主に、後で説明する負荷分散のためです。
3）このモジュールで説明するDNS解決は反復検索を使用します。DNSは再帰的な検索方法も提供します。興味がある場合は、2つの違いを確認できます
CDNステージ
上記のDNS解決プロセスを通じて、CDNオペレーターは要求を正常に転送しました
- CDNのグローバルロードバランシングシステムを実装する方法はたくさんありますが、より一般的なソリューションであるDNSベースのグローバルロードバランシングシステムを次に示します。
-
まず、システムはDNSで、ドメイン名を解決できます
-
第二に、システムには負荷分散機能があります。通常、CDNの負荷分散戦略には、静的負荷分散（ユーザーの地理的な場所、ネットワークオペレーターなどに基づいて異なるサーバーを選択する）と動的負荷分散（サーバートラフィック、パフォーマンス、負荷などの動的データに基づいてサーバーを選択する）の2種類があります。動的負荷分散はより多くのリソースを消費するため、グローバル負荷分散システムは一般に静的負荷分散戦略を使用し、地域負荷分散システムは一般に動的負荷分散戦略を使用します。
-
最後に、グローバルな負荷分散システムは、静的な負荷分散戦略に基づいて、リクエスタに適切なリージョンの負荷分散システムIPを選択します。
-
PS：一般に、グローバルロードバランシングシステムにはバックアップシステムがあり、バックアップシステムの構成は現在のシステムとまったく同じです。CDNがDDosに攻撃されていることが検出されると、バックアップシステムがアクティブになり、バックアップシステムのIPがDNSに追加され、IP設定のキャッシュ時間が長くなります。このソリューションにより、DDos攻撃を減らすことができます。
-
PS：ロードバランシングには4つのレベルのロードバランシングと7つのレベルのロードバランシングがあります。いわゆる4および7レベルはOSIの7つのレイヤーに対応します。4番目のレイヤーはIPなどに基づくロードバランシングのみを実行でき、7番目のレイヤーは要求された情報を取得できます。 Cookieなどはロードバランシングを実行します。一般的に使用されるnginxは、4レベルのロードバランシングと7レベルのロードバランシングを実行できます。
- クライアントは、サービスを提供するCDNキャッシュサーバーを決定するCDN地域負荷分散システムを要求します。地域の負荷分散システムは通常、動的な戦略を使用します。このため、地域内のCDNキャッシュサーバーのさまざまな情報（セッションキャパシティ、往復時間、トラフィック、キャッシュの場所など）を収集するには、別のサーバーが必要です。
- ここでは、キャッシュの場所に基づいてCDNキャッシュサーバーを選択する方法について簡単に紹介します。このメソッドの実装原理は非常に単純です。要求されたURLは、特定のアルゴリズムによってCDNキャッシュサーバーと照合され、URLが将来再び要求された場合でも、キャッシュサーバーにヒットします。この方法の利点は、スペースを節約できることです。リクエストは1つのサーバーにのみ保存され、冗長性はありません。不利な点は、それがホットURLである場合、サーバーの負荷が高すぎ、サーバーに問題がある場合、すべての要求がソースに返される可能性があることです。
-
地域負荷分散システムによって提供されるCDNキャッシュサーバーがキャッシュされていないか、キャッシュが無効な場合、上位レベルのCDNキャッシュサーバーにリクエストが送信されます。一般的に使用されるプロトコルはICP / HTCP / CARPなどです。もちろん、Pragma、Expires、Cache-Control、Last-Modified、Etagなど、Webの基本的な知識を使用してキャッシュの無効化を判断します。
-
上位のCDNキャッシュサーバーがまだキャッシュされていないか期限切れでない場合は、元のマシンにファイルを要求し、要求が成功した後にそれをキャッシュします。
CDNの使用に関するいくつかの問題
CDNは高い同時実行性に対して非常に役立ちます。この記事「一般的なキャッシュテクニック」を参照してください。
ただし、CDNを使用すると、いくつかの問題が発生する場合があります。ここでは、発生した問題について説明します。
ファイルの取得に時間がかかりすぎる
最近問題が発生しました。CDNで50KBの画像を取得するには120秒かかりました。
これは、CDNメーカーのロードバランシング構成に問題があるためです。間違った構成では、画像を取得するために、地球の半分を移動する必要があります。その後、CDNの製造元に構成を変更させた後、0.2秒しかかかりません。
間違ったファイルを取得する
製品には製品サイトが必要であり、製品サイトはjsファイルを参照します。製品サイトが変更されるたびにjs名は変更されませんが、base.js？v01からbase.js？v02のようにjsタグは変更されます。jsファイルは有効期限なしに設定されており、バージョン番号が変更された場合は、前提となるソースに返されます。
製品サイトがjsバージョンと一致しない場合、製品サイトはページを開けない、一部の機能が使用できないなどのエラーを生成します。製品サイトとjsが一致しない2つの状況があります
- 製品サイトは新バージョン、jsは旧バージョン
この状況は通常、jsが最初にソースに戻るマシンにリリースされたときにリリースされなかったが、新しい製品サイトが最初にリリースされたため、新しい製品サイトが新しいjsを要求すると、ソースに戻るマシンを要求して戻るソースマシンはまだ古いバージョンなので、古いjsは新しいjsキャッシュとして扱われます。これが発生すると、通常、新しいjsバージョンが生成され、解放操作が再度実行されます。
- 製品サイトは旧バージョン、jsは新バージョンです
この状況には多くの理由があり、対処することはしばしば困難です。これが発生するための前提条件は、新しいjsがソースマシンにリリースされており、古い製品サイトがまだリリースされていないことです。
- CDNサービスプロバイダーが1つしかない場合、ユーザーがすべて海外にいて、現時点で中国の製品サイトにアクセスすると、グローバルな負荷分散戦略に従って、このリクエストは国内で最初のリクエストであり、CDNにキャッシュがありません。取得されたjsはこれは新しいjsですが、この発生の確率は比較的小さく、影響は大きくありません
- 複数のCDNサービスプロバイダーがある場合、これが発生する可能性は非常に高くなります。サービスプロバイダーが異なればサービスエリアも異なり、運用と保守も異なるサービスプロバイダーのトラフィックを展開する可能性があるため、jsリクエストがCDNにまったくないため、元の状態に戻る場合があります。この場合、CDNキャッシュは通常、バージョン契約を強制するために削除されますが、それでもユーザーに影響を与える可能性があります
- 別の状況では、ファイルが1つのCDNキャッシュサーバーにのみキャッシュされている場合、サーバーに障害が発生すると、元に戻ることも発生します。ただし、サーバーが損傷する可能性は高くなく、CDNサーバーの上位層にキャッシュサーバーがあるため、この状況はまれです。
多数の原点復帰要求
これが起こった後、サーバーはしばしば圧倒されます。これは、ほとんどのCDNサービスプロバイダーがURL全体に基づいてCDNヒットを判断するためです。URLがGoogle広告を通じて宣伝されている場合、後で別のサフィックスが追加され、ヒットしません。これが発生しないようにするには、操作とメンテナンスを使用して特別な構成を作成し、指定されたクエリパラメーターの変更のみがソースに戻るようにするか（操作とメンテナンスは、後のメンテナンスにつながらないため、この操作を望まない場合があります）、または独自のサービスのパフォーマンスを向上させます。
やっと
私の記事が気に入ったら、私のパブリックアカウント（プログラマーMala Tang）をフォローできます。
データ
- https://cloud.tencent.com/developer/article/1349559
- https://www.cnblogs.com/liyuanhong/articles/7353974.html
- https://www.jianshu.com/p/4d8df62d55e3
- https://blog.csdn.net/jiajiren11/article/details/80071312?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineFromMachineFromMach 2.nonecase
- DNS機能の概要とCDNでの使用法
- https://mp.weixin.qq.com/s?__biz=Mzg3MjA4MTExMw==&mid=2247486200&idx=1&sn=197c0905028104e1ae32dc6bed7941f5&chksm=cef5f94ef982705874cf1a852e2f3e4879e59cb0705d1aed5a12cd91f845fba1869b58cb8863&scene=21#wechat_redirect