分散ソフトウェア アーキテクチャ - ドメイン名解決システム

透明多段シャントシステムの設計原理

利用者が情報システムを利用する際、リクエストはブラウザから始まり、DNSの導きでシステムの入口を見つけ、ゲートウェイ、ロードバランサ、キャッシュ、サービスクラスタといった一連の設備を経て、最終的にアクセスされます。システムの終わり データベース サーバーに保存されている情報は、段階的にユーザーのブラウザに返されます。

このプロセスでは、多くの技術的コンポーネントを通過する必要があります。次に、システム設計者として、システム内ではさまざまな設備やコンポーネントが異なる値を持つことを認識する必要があります。

  • クライアントまたはネットワークのエッジには、ローカルキャッシュ、コンテンツ配信ネットワーク、リバース プロキシなど、ユーザーのリクエストに迅速に応答し、背面の I/O および CPU への負荷を回避できるコンポーネントがいくつかあります。

  • 一部のコンポーネントの処理能力はリニアに拡張でき、スケールしやすいため、低コストでマシンを積み重ねてユーザー数に見合った同時性能を得ることができ、ビジネスロジックのメインキャリアとして活用するのがよいでしょう。一般的なクラスターでは、サービス ノードを自動スケーリングできます

  • 一部のコンポーネントの安定したサービスはシステムの運用にグローバルな影響を与えるため、高可用性を維持するために、サービス登録センターや構成センターなどのフォールトトレラントなバックアップを常に維持する必要があります

  • 一部の施設は本質的にシングルポイント コンポーネントであり、システムの入り口にあるルーティング、ゲートウェイ、ロード バランサー、システムの入口にある従来のリレーショナル データベースなど、処理能力を向上させるためにはマシン自体のネットワーク、ストレージ、およびコンピューティング パフォーマンスのアップグレードにのみ依存できます。リクエストチェーンの終端などは、典型的な簡単に作成できるシングルポイントコンポーネントです。

したがって、システムのトラフィックを計画するときは、これらのコンポーネントの値の違いを十分に理解する必要があります。シンプルでユニバーサル デザインの 2 つの原則を次に示します。

  1. 単一点コンポーネントをできる限り最小限に抑え、一部の単一点が避けられない場合は、単一点コンポーネントへの流れを最小限に抑えます。

たとえば、ユーザーがデータベースに保存されているユーザー アバター画像を取得したい場合、ブラウザ キャッシュ、コンテンツ配信ネットワーク、リバース プロキシ、Web サーバー、ファイル サーバー、データベースなどはすべてこの画像を提供できます。したがって、単一ポイント部分 (データベースなど) へのほとんどのトラフィックの収集を回避しながら、リクエストを最も適切なコンポーネントに誘導することが適切であり、同時に、処理結果の正確性またはほとんどの部分を保証することができます。システムに障害が発生した場合でも、修復措置を自動的かつ迅速に実装できます。これが、システム アーキテクチャにおけるマルチレベル シャントの重要性です。

  1. オッカムのかみそりの原理

エンティティは必要なしに増殖させるべきではありません

——オッカムの剃刀、オッカムのウィリアム

ニーズを満たすことができる限り、最もシンプルなシステムが最適なシステムです。

DNS の仕組み

ドメインネームシステム(英語: Domain Name System、略称: DNS)は、インターネットのサービスです。ドメイン名と IP アドレスを相互にマッピングする分散データベースとして、人々がインターネットに簡単にアクセスできるようにします。DNS は UDP ポート 53 を使用します。現在、各レベルのドメイン名の長さの制限は 63 文字であり、ドメイン名の合計の長さは 253 文字を超えることはできません。その機能は、人間が理解しやすいドメイン名アドレス (www.baidu.com など) をコンピュータが処理しやすい IP アドレス (14.119.104.254 など) に変換することです。

2 つの名詞を見てください。

  • 権威DNS: 特定のドメイン名の変換を担当するDNSサーバー。権限とは、サーバーがドメイン名の最終結果を決定することを意味します。
  • ルート ドメイン ネーム サーバー (ルート DNS): 固定のクエリ不要のトップレベル ドメイン名 (トップレベル ドメイン) サーバーを指します。デフォルトでオペレーティング システム コードに組み込まれていると想定できます。世界中にはルート ドメイン ネーム サーバーのグループが合計 13 あります (ルート ドメイン名の各グループは、エニーキャストを通じて大規模なミラー グループを確立しています)。13 という制限の理由は、DNS が主にデータの送信プロトコルとして UDP を使用しているためです。 IPV4 における UDP データ パケットの最大有効値は 512 バイトで、最大 13 セットのアドレス レコードを保存できます。

DNS 解決の手順は次のとおりです。

  1. クライアントはローカル DNS キャッシュをチェックして、ドメイン名のアドレス レコードが存在し、生きているかどうかを確認します (キャッシュは TTL (Time to Live 生存時間) に従って無効になります)。
  2. クライアントは、ローカル オペレーティング システムで構成されたローカル DNS (ローカル DNS、ユーザーによって手動で設定されるか、DHCP またはダイヤルアップによって割り当てられたときに PPP サーバーから自動的に取得される) にアドレスを送信します。
  3. ローカル DNS はクエリ要求を受信すると、www.baidu.com の権威サーバーがあるかどうか --> baidu.com の権威サーバーがあるかどうか --> 存在するか、の順で自身のアドレス レコードを検索します。 com には権限のあるサーバーがあります。クエリがない場合、ローカル DNS は常に最後のドットで表されるルート ドメイン ネーム サーバーを見つけます。
  4. ローカル DNS が新しいと仮定すると、そこにはどのドメイン名にも権限のあるサーバー レコードが存在しないため、DNS クエリ要求はステップ 3 のシーケンスに従います。ルート ドメイン ネーム サーバーが見つかったら、権限のあるサーバー レコードを取得します。 com の権威サーバーを通過し、baidu.com の権威サーバー アドレス レコードを取得するなどして、最終的に www.baidu.com を説明できる権威サーバー アドレスを見つけます。
  5. www.baidu.com の権威サーバーを通じて、そのアドレス レコードをクエリします。ここでいうアドレス レコードは、必ずしも IP アドレスを指すわけではありません。RFC 仕様では、数十種類のアドレス レコードが定義されています。たとえば、IPV4 の IP アドレスは A レコード、IPV6 の AAAA レコード、ホスト エイリアスなどです。 CNAMEレコードなどを待ちます。

DNS システムのマルチレベル迂回の設計は、DNS システムがグローバル ネットワーク トラフィックの中断のない影響に耐えられるようにすることを目的としていますが、欠点がないわけではありません。典型的な問題は、応答速度に影響することです。極端な場合には、ドメイン名解決により、クエリ結果が見つかるまでに各ドメイン名が複数回再帰的に実行される可能性があり、これが送信の応答速度に大きな影響を与えます。
次の図を例に挙げると、DNS クエリには約 310 ミリ秒かかります。
最初のDNSリクエストに時間がかかる
そのため、この問題を回避するために、DNS プリフェッチ (DNS プリフェッチ) と呼ばれる特別なフロントエンド最適化方法があります。 , 次に、Web ページが読み込まれるときにリンク リクエストが生成され、以下に示すように、ブラウザーにドメイン名を事前に解釈するよう求められます。

<link rel="dns-prefetch" href="//domain.not-icyfenx.cn">

そして、おそらくより深刻なもう 1 つの欠陥は、DNS の階層的なクエリにより、各レベルが中間者攻撃の脅威にさらされる可能性があり、結果としてハイジャックのリスクが生じることです
ルート ドメイン ネーム サーバーと再帰チェーンの最上位にあるリンクを攻撃することは非常に困難であり、それらはすべて非常に専門的なセキュリティ保護手段を備えています。ただし、再帰チェーンの最下部にあるローカル DNS サーバーやローカル オペレーターの多くのローカル DNS サーバーは、セキュリティ保護が比較的緩く、多くの地域のオペレーターでさえ積極的にサーバーをハイジャックし、間違った IP を返します。この IP でユーザー リクエストをプロキシすることで、利益を得るために、特定の種類のリソース (主に HTML) に広告を挿入します。
この状況に対応して、近年、新しい DNS 動作モードである HTTPDNS (DNS over HTTPS、DoH とも呼ばれます) が登場しました。UDP トランスポート プロトコルに基づく DNS ドメイン名解決を置き換え、独自の DNS 解決サービスを HTTPS プロトコルに基づくクエリ サービスとして公開し、オペレーティング システムの代わりにプログラムを通じて権威 DNS または信頼できるローカル DNS から直接解決データを取得します。これにより、従来のローカル DNS がバイパスされます。このアプローチの利点は、「仲介業者が価格差を稼ぐ」環境を回避し、根本的なドメイン名ハイジャックの心配がなくなり、ドメイン名の検証の遅さ、ソース IP の不正確さ、および信頼性の低いものによって引き起こされるスマート回線切り替えエラーを効果的に回避できることです。ローカルDNSの質問です。

おすすめ

転載: blog.csdn.net/zkkzpp258/article/details/131500038