関連するブログ、参照この一連のオタクの時間-ネットワークプロトコルについての何か
ネットワークプロトコルについて楽しく話す-講義19 | HTTPDNS：オンラインの世界のアドレス帳も間違っている
前のセクションでは、DNSの2つの機能について学びました。1つ目は、名前に基づいて特定のアドレスを見つけることです。もう1つは、複数のアドレスの負荷を分散することです。アクセスする複数のアドレスの1つを選択できます。 。
ただし、このアドレス帳は間違った方向を示していることもあります。500メートル離れたところに食事をする場所があるのは明らかです。5キロ離れていることをお勧めします。なぜそのような状況があるのですか？
覚えてる？DNSの解決要求を発行する場合、まず、オペレーターのローカルDNSサーバーに接続します。このサーバーは、DNSツリー全体を解決し、解決の結果をクライアントに返します。しかし、ローカルDNSサーバーは、ローカルガイドとして、しばしば独自の「慎重な思考」を持っています。
従来のDNSの問題は何ですか？
1.ドメイン名キャッシュの問題
ローカルでキャッシュを行うことができます。つまり、すべてのリクエストが信頼できるDNSサーバーに送信されるわけではありませんが、1回の訪問後に結果がローカルにキャッシュされ、他の人が尋ねに来たときに、これを直接返します。データをキャッシュします。
これは、ツアーガイドがレストランに行って自分の住所を覚えていることに相当し、観光客が尋ねると、アドレス帳を確認せずに自分の記憶に基づいて答えます。このようによくある問題は、他の人のレストランが明らかに動いたことです。ガイドとしてキャッシュを更新しなかったため、この場所に到着したところ、レストランが衣料品店になっていることがわかりました。とてもがっかり？
さらに、一部のオペレーターは一部の静的ページをオペレーターのサーバーにキャッシュするため、ユーザーが要求したときにオペレーター間でアクセスする必要がなくなり、速度が向上するだけでなく、オペレーター間のトラフィック計算も減少します。コスト。ドメイン名の解決中、ユーザーは実際のWebサイトではなく、このキャッシュされたサーバーに誘導されます。
多くの場合、問題は見られませんが、ページが更新されると、ユーザーは古いページにアクセスし、問題が発生します。たとえば、レストランが新しい料理を発売したと聞いて、それを試してみたいと思ったとします。ツアーガイドは、ここでの食事も同じだと言っています。一部の観光客はそれを大丈夫と思うでしょうが、新しい料理を試してみたい人にとって、ツアーガイドがあなたを連れて行くように言ったけれども実際に新しい料理を食べなかったとしたら、あなたもとてもがっかりしますか？
次に、ローカルキャッシュがあります。これにより、グローバルロードバランシングが失敗することがよくあります。キャッシュが最後にキャッシュされたとき、キャッシュ内のアドレスは、必ずしも顧客に最も近い場所であるとは限りません。このアドレスを顧客に返すと、間違いなくバイパスされます。ロード。
前回、お客様が西湖の酢を食べたがったのと同じように、ツアーガイドは西湖のそばにレストランがあることを知っていました。観光客はその当時西湖にいたのですが、次に顧客が霊陰寺にいて西湖の酢を食べたいと思ったとき、ツアーガイドも西湖を指し示しました。横にあるもの、これは遠すぎます。
2.ドメイン転送の問題
キャッシングの問題は、ローカルドメイン名解決サービスが信頼できるDNSサーバーを引き続き検索することを示していますが、毎回ではありません。これはまだ大きなツアーガイドであり、大きな仲介者であると言えます。小さなツアーガイドや小さな仲介者もいますが、リクエストを受けた後、直接他のオペレーターに転送して分析を依頼し、外部委託するだけです。
問題は、それがオペレーターAの顧客である場合、自身のオペレーターのDNSサーバーにアクセスすることです。オペレーターAが権限のあるDNSサーバーに照会すると、権限のあるDNSサーバーは、ユーザーがオペレーターAに属していることを認識し、それをAのデプロイメントに返します。同じオペレーターへのアクセスがはるかに速くなるように、オペレーターのWebサイトアドレス。
ただし、オペレーターAは遅延しており、解析された要求をオペレーターBに転送します。オペレーターBが権限のあるDNSサーバーに照会すると、権限のあるサーバーはユーザーがオペレーターBであると誤って認識し、オペレーターBに戻ります。ウェブサイトのアドレスその結果、顧客の訪問ごとにオペレーターを通過する必要があり、速度は非常に遅くなります。
3.エクスポートNATの問題
以前にゲートウェイについて説明したとき、エクスポート時に多くのコンピュータールームがNAT、つまりネットワークアドレス変換で構成され、このゲートウェイから送信されるパケットが新しいIPアドレスに置き換えられることがわかります。 、IPアドレスを元に戻すので、アクセスに問題はありません。
ただし、ネットワークアドレスが変換されると、権威あるDNSサーバーはこのアドレスを使用して、どのオペレーターからの顧客であるかを判別できなくなり、変換されたアドレスがオペレーターを誤って判断し、クロスオペレーターを引き起こす可能性が高くなりますご覧ください。
4.ドメイン名の更新の問題
ローカルDNSサーバーは、さまざまな地域やさまざまなオペレーターによって独立して展開されます。ドメイン名解決キャッシュの実装戦略も異なります。一部は遅延し、ドメイン名解決結果のTTL時間制限を無視します。信頼できるDNSサーバーが変更を解決すると、解決結果がネットワーク全体に有効になる期間は非常に長くなります。しかし、DNSスイッチングでは、有効時間に対するシーンの要件が比較的高い場合があります。
たとえば、デュアルマシンルームに展開する場合、DNSはマシンルーム全体のロードバランシングと障害復旧に使用されます。コンピュータルームで問題が発生した場合、権限のあるDNSを変更して、ドメイン名が新しいIPアドレスを指すようにする必要がありますが、更新が遅すぎると、多くのユーザーがアクセス例外を抱えることになります。
まるでホテル、レストラン、交通機関の変化に気を配り、より勤勉で献身的なツアーガイドがいるようで、尋ねると最新の情報が得られることがよくあります。一部のツアーガイドは怠惰で、8年前のツアーガイドの言葉は変更されていません。
5.遅延の問題を分析する
前のセクションのDNSクエリプロセスから判断すると、DNSクエリプロセスは複数のDNSサーバーを再帰的にトラバースして最終的な解決結果を取得する必要があります。これにより、特定の遅延が発生し、解決タイムアウトも発生します。
HTTPDNSの動作モード
DNS解決には非常に多くの問題があるため、どうすればよいですか？IPアドレスを直接使用するように戻すことはできますか？これは明らかに不適切なので、HTTPDNSがあります。
実際、HTTPNDSは従来のDNS解決を採用していませんが、HTTPプロトコルに基づいて、複数の場所と複数のオペレーターに分散されたDNSサーバークラスターを構築しています。クライアントがDNS解決を必要とする場合、クライアントはHTTPプロトコルを介してサーバークラスターに直接要求し、最も近いアドレスを取得します。
これは、HTTPプロトコルに基づく独自のドメイン名解決を実装し、統一されたアドレス帳を使用する代わりに独自のアドレス帳を作成する各企業に相当します。ただし、デフォルトのドメイン名解決はDNSであるため、HTTPDNSを使用するにはデフォルトのDNSパスをバイパスする必要があり、デフォルトのクライアントは使用できません。HTTPDNSを使用するものは多くの場合モバイルアプリケーションであり、モバイル端末でHTTPDNSをサポートするクライアントSDKを埋め込む必要があります。
独自のHTTPDNSサーバーと独自のSDKを通じて、ローカルツアーガイドに依存することから、旅行戦略、無料旅行、プレイ方法、プレイ方法を実行するための独自のオンラインクエリまで。このようにして、あなたはプロではないツアーガイドに頼るのを避け、彼を恥ずかしくすることはできません。
私はしてみましょうHTTPDNSの私の作業モードを解決
クライアントのSDKでサーバーを動的に要求し、HTTPDNSサーバーのIPリストを取得して、ローカルにキャッシュします。ドメイン名は継続的に解決されるため、SDKはDNSドメイン名解決の結果もローカルにキャッシュします。
モバイルアプリケーションがアドレスにアクセスする場合は、まずローカルキャッシュがあるかどうかを確認し、ある場合は直接戻ります。このキャッシュとローカルDNSキャッシュの違いは、これはオペレーター全体ではなく、モバイルアプリケーション自体によって行われることです。更新方法と更新時期は、モバイルアプリケーションのクライアントがサーバーと調整してこれを行うことができます。
ローカルで利用できない場合は、HTTPDNSサーバーをリクエストする必要があります。ローカルHTTPDNSサーバーのIPリストでHTTPリクエストを選択すると、アクセスするWebサイトのIPリストが返されます。
リクエストの仕方はこんな感じです。
curl http://106.2.xxx.xxx/d?dn=c.m.163.com
{"dns":[{"host":"c.m.163.com","ips":["223.252.199.12"],"ttl":300,"http2":0}],"client":{"ip":"106.2.81.50","li
モバイルクライアントは、携帯電話がどのキャリアとどのアドレスにあるかを自然に知っています。これは直接のHTTP通信であるため、HTTPDNSサーバーはこの情報を正確に把握できるため、正確なグローバルロードバランシングを実行できます。
もちろん、これらすべてが機能しない場合は、従来のLocalDNSに切り替えて解決することができます。これは、アクセスしないよりも優れています。HTTPDNSは上記の問題をどのように解決しますか？
実際には、2つの大きな問題に帰着します。1つは解析速度と更新速度のバランスであり、もう1つはインテリジェントなスケジューリングで、対応するソリューションはHTTPDNSのキャッシュ設計とスケジューリング設計です。
HTTPDNSキャッシュ設計
DNS解決プロセスは複雑で、通信の数が多いため、解決速度に大きな影響を与えます。解析を高速化するためにキャッシュがありますが、これはキャッシュの更新速度がタイムリーではないという問題を引き起こします。最も恐ろしいのは、これらの2つの側面が他の人、つまりローカルDNSサーバーの手にあるということです。これはカスタマイズされません。クライアントとして行うことはできません。
HTTPDNSは、自分の手で解決速度と更新速度を制御するためのものです。一方では、解析のプロセスでローカルDNSサービスの再帰呼び出しの大規模な循環は必要ありません。HTTP要求は直接処理されます。リアルタイムで更新されると、すぐに機能します。他方、解析の速度を向上させるために、ローカルキャッシュもあります。キャッシュはクライアントSDKで維持され、有効期限と更新時間は自分で制御できます。
HTTPDNSのキャッシュ設計戦略は、アプリケーションアーキテクチャの一般的なキャッシュ設計パターンでもあり、クライアント、キャッシュ、データソースの3つの層に分かれています。
- アプリケーションアーキテクチャの場合は、アプリケーション、キャッシュ、およびデータベースです。一般的なものは、Tomcat、Redis、MySQLです。
- HTTPDNSの場合は、モバイルクライアント、DNSキャッシュ、およびHTTPDNSサーバーです。
キャッシュモードである限り、キャッシュの有効期限、更新、および不整合の問題があり、解決策は非常に似ています。
たとえば、DNSはメモリにキャッシュされ、ストレージに永続化することもできるため、APPの再起動後、最後に蓄積された頻繁にアクセスしたWebサイトの分析結果をストレージからできるだけ早くロードできます。キャッシュに。これは、Redisがメモリベースのキャッシュと少し似ていますが、再起動時またはマスターとスレーブが切り替えられたときにデータが完全に失われないように、永続化する機能も提供します。
SDKのキャッシュは、キャッシュの有効期限に厳密に従います。キャッシュがヒットしないか、期限が切れていて、クライアントが期限切れのレコードの使用を許可していない場合は、レコードが更新されるように解決を開始します。
解析は同期的に実行できます。つまり、HTTPDNSインターフェイスを直接呼び出し、最新のレコードを返し、キャッシュを更新します。または、非同期的に、解析タスクをバックグラウンドに追加し、バックグラウンドタスクがHTTPDNSインターフェイスを呼び出します。
同期更新の利点はリアルタイムが優れていることですが、欠点は、複数の要求が期限切れであることが判明した場合、HTTPDNSが同時に複数回要求されることであり、これは実際には無駄です。
同期更新メソッドは、アプリケーションアーキテクチャのキャッシュのキャッシュアサイドメカニズムに対応します。つまり、最初に読み取りキャッシュが読み取られ、読み取りデータベースはヒットせず、同時に結果がキャッシュに書き込まれます。
非同期更新の利点は、複数の要求が古くなっていて、HTTPDNSの1つの要求タスクに結合され、1回だけ実行されるため、HTTPDNSのプレッシャーが軽減されることです。同時に、期限切れ間際にプリロードするタスクを作成して、期限切れ後のリフレッシュを防ぐことができます。これをプリロードと呼びます。
その欠点は、現在の要求が期限切れのデータを取得するときに、クライアントが期限切れのデータの使用を許可している場合、リスクを負う必要があることです。期限切れのデータを引き続き要求できる場合は問題ありません。要求できない場合は、一度失敗し、次のキャッシュ更新後に要求が成功します。
非同期更新メカニズムは、アプリケーションアーキテクチャのキャッシュのRefresh-Aheadメカニズムに対応しています。つまり、ビジネスはキャッシュにアクセスし、期限が切れたときに定期的にキャッシュを更新します。
よく知られているアプリケーションキャッシュGuavaキャッシュには、RefreshAfterWriteメカニズムがあります。同時の複数のキャッシュアクセスミスが発生し、ソースへの同時トリガーが発生した場合、1つの要求のみをソースモードに戻すことができます。アプリケーションアーキテクチャのキャッシュでは、データのウォームアップまたはプリロードのメカニズムがよく使用されます。
HTTPDNSスケジューリング設計
クライアントはSDKに組み込まれているため、ローカルDNSのさまざまなキャッシュ、転送、NATのために、権威あるDNSサーバーがクライアントの場所とオペレーターを誤解することはなく、直接的な情報を取得できます。
クライアントでは、携帯電話がどの国、どのオペレーター、どの州、さらにはどの市にあるかを知ることができます。HTTPDNSサーバーは、この情報に基づいて、返す最適なサービスノードを選択できます。
複数のノードがある場合は、地理的な場所だけでなく、エラー率、要求時間、サーバーの負荷、ネットワークの状態なども考慮して、包括的な選択を行います。ノードがダウンしているか、パフォーマンスがダウンしている場合は、できるだけ早く切り替えることができます。
これを行うには、クライアントはHTTPDNSから返されたIPを使用してビジネスアプリケーションにアクセスする必要があります。クライアントSDKは、エラー率、リクエスト時間、その他のネットワークリクエストの品質データなどのネットワークリクエストデータを収集し、統計背景に送信して分析し、さまざまなIPのサービス品質を表示するために集計します。
サーバー側では、アプリケーションはHTTPDNS管理インターフェースを呼び出すことにより、さまざまなサービス品質の優先度と重みを構成できます。HTTPDNSは、地理的な位置と回線の状態に基づいてこれらの戦略に基づいてランキングを計算し、現在の高品質で低遅延のIPアドレスを優先します。
インテリジェントスケジューリングを通じてHTTPDNSから返された結果も、クライアントにキャッシュされます。キャッシングがスケジューリングをゆがめるのを防ぐために、クライアントは、さまざまなモバイルネットワークオペレーターのWIFIのSSIDに従って、さまざまな次元でデータをキャッシュできます。オペレーターやWIFIによって結果は異なります。
まとめ
これでこのセクションは終わりです。まとめましょう。次の2つの重要なポイントを覚えておく必要があります。
- 従来のDNSには、解決が遅い、タイムリーに更新できないなど、多くの問題があります。キャッシング、転送、NATの問題により、クライアントはロケーションとオペレーターを誤解し、トラフィックのスケジューリングに影響を与えます。
- HTTPDNSは、クライアントSDKとサーバーを使用して、HTTP経由でDNSを直接呼び出して解決し、従来のDNSのこれらの欠点を回避し、インテリジェントなスケジューリングを実装します。
最後に、私はあなたに2つの思考質問を残しておきます。
- HTTPDNSを使用するには、HTTPDNSサーバーにドメイン名の解決を要求する必要がありますが、クライアントはHTTPDNSサーバーのアドレスまたはドメイン名をどのようにして知るのでしょうか。
- HTTPDNSのインテリジェントなスケジューリングは、主にクライアントが最も近いサーバーを選択できるようにすることであり、クライアントに近い場所へのリソース分散を行うことでクライアントのアクセスを高速化する別のメカニズムがあります。どのテクノロジを知っていますか？
