なぜDNSの遅延がLAN内のホームサーバーアプリを遅く感じさせるのか？

ホームサーバーアプリは高速なLAN上でも遅く感じることがあります。クライアントが新しい接続を開始する前にホスト名を解決しなければならず、そのルックアップが空のキャッシュ、利用できないリゾルバー、またはフォールバックパスで待機すると、アプリが応答する前に一時停止が発生するためです。

これはDNSがすべてのHTTPリクエストの前に実行されるわけでも、確立済み接続のスループットを低下させるわけでもありません。DNSはクライアントが新しいアドレス結果や新しい接続を必要とするときに最も目立つため、最初の読み込みが遅く感じられ、後のナビゲーションは通常通りに感じられます。

DNSの遅延は接続開始を遅らせるが、すべてのアプリリクエストを遅らせるわけではない

ブラウザやクライアントがホスト名を開くと、そのリゾルバーはネットワークスタックが使用できるアドレスを返す必要があります。DNSリゾルバーモデルでは、その応答はキャッシュ情報または一つ以上のネームサーバーから来ることが許されているため、宛先サーバーが変わらなくてもルックアップ時間は変動します。

一度アドレスと接続が利用可能になると、後続のリクエストはそれらを再利用できます。例えばHTTP/2は、リクエストとレスポンスの交換を接続上の独立したストリームに関連付けます。このHTTP/2ストリーム多重化が、多くのリソースがそれぞれ新しい接続やDNSルックアップを必要としない理由の一つです。

LANではその違いがよりわかりやすくなります。ペイロード転送やサーバーの往復は短時間で済むことが多い一方、リゾルバーの再試行やフォールバックはそれらの前に別の待ち時間として残ります。ユーザーは合計時間を体感し、アプリ、ストレージ、またはネットワークのせいにすることがありますが、遅延はアプリケーショントラフィックが始まる前に発生しています。

LAN上でのホームサーバーのホスト名解決方法

ブラウザおよびオペレーティングシステムのキャッシュ

クライアントはすでに使用可能なアドレス結果を保持している場合があります。キャッシュヒットはネットワークDNS交換の必要をなくしますが、期限切れまたは存在しないエントリはリクエストを解決パスの先へ送ります。ブラウザ、オペレーティングシステム、および再帰的リゾルバーのキャッシュは別々の層であるため、それらの状態は常に同時に変わるわけではありません。

設定されたLANリゾルバー

ローカルキャッシュデータが利用できない場合、クライアントは通常、ルーター、専用のローカルDNSサービス、または別の再帰的リゾルバーなど、設定されたリゾルバーに問い合わせます。そのリゾルバーは、権威のあるローカルゾーンから応答したり、自身のキャッシュから応答したり、他の場所でクエリを追跡したりできます。サーバーがLAN上にあるからといって、関与するすべてのリゾルバーが同じくらい近くて健全であるとは限りません。

検索ドメイン、mDNS、およびフォールバックパス

短いホスト名や.localで終わる名前は異なるメカニズムに従うことがあります。.local名のマルチキャストDNSルールはこれらのクエリをリンクローカルマルチキャストに送りますが、実装によっては他のメカニズムも同時に使用されることがあります。検索サフィックスやフォールバック動作により、通常のユニキャストDNSの説明では捉えられない試行が追加されることがあります。

キャッシュミスとリゾルバのタイムアウトは異なる停止を生み出す

キャッシュミスは自動的に障害を意味しません。回答を別のソースから取得する必要があるため、初回の検索はキャッシュされた検索より時間がかかることがあります。タイムアウトは異なります：リゾルバが待機期間内に有用な応答を受け取れず、別のサーバーやトランスポートで再試行する可能性があります。

現在のDNS失敗と再試行のガイダンスは、失敗、到達不能なサーバー、再試行、キャッシュされた失敗を区別しています。また、同一の未解決質問は独立した上流クエリとして発行されるのではなく結合されることがあるため、DNS遅延はアプリのリソース数で機械的に乗算すべきではないと指摘しています。

目に見えるパターンは単一の平均値よりも情報量が多いことが多いです。常に小さい初回読み込み遅延、コールドキャッシュ遅延、不規則な長い停止は異なる状態を示し、単一の「遅いDNS」という一般的なラベルでまとめるべきではありません。

1つのアプリ画面は複数のホスト名を含むことがある

ローカルのダッシュボードは、メインドキュメントをあるホスト名から読み込みつつ、API、WebSocketエンドポイント、認証サービス、プラグイン、フォント、カバー画像、更新チェックのために他の名前にアクセスすることがあります。画面がローカルに見えるためにはメインアプリだけがローカルであればよく、その依存関係のグラフは複数のオリジンをまたぐこともあります。

新しいオリジンごとに別の名前解決と接続の機会が生まれますが、遅延は必ずしも直線的に加算されるわけではありません。ブラウザは作業を同時に実行でき、リゾルバは一致する質問をキャッシュまたは結合でき、複数の同一オリジンのリソースが接続を共有することもあります。

実際の問題は「ページにファイルがいくつあるか」ではなく、「インターフェースが使えるようになるまでに必要な異なる名前と新しい接続経路がいくつあるか」です。小さくてもブロックするAPI依存は、後で並列に読み込まれる多くの画像よりも重要な場合があります。

なぜ最初の読み込みは遅く、リフレッシュは速く感じるのか

最初の訪問にはDNSルックアップ、新しいTCP接続、TLSハンドシェイク、認証、初期アプリケーション処理が含まれることがあります。リフレッシュはアドレスキャッシュ、既存接続、HTTPキャッシュエントリ、ウォームアップ済みのアプリケーションデータの恩恵を同時に受けることができます。

それは、より速いリフレッシュがDNSが唯一の原因である証明ではなく、有用な手がかりであることを意味します。DNSを特定するには、ルックアップフェーズを接続確立やサーバーレスポンスから分離し、完全な最初の読み込みの差をリゾルバ時間として扱わないことが必要です。

名前がローカルの場合、リゾルバの場所が最も重要

内部ホスト名には、その名前空間を理解する解決メカニズムが必要です。ローカルの権威ゾーン、分割DNS構成、mDNS名は回答をLANに関連付けたままにできますが、一般的なパブリックリゾルバはその内部名の記録を持たないかもしれません。

これは、すべてのローカルホスト名が外部リゾルバに送られて遅い処理を経て最終的に成功するという意味ではありません。名前や設定によっては、即時の否定応答、再試行、または別のメカニズムへのフォールバックが起こることがあります。リゾルバの配置は、単に物理的に近いサーバーがあるからではなく、どのシステムが正しく応答できるかを変えるため重要です。

DNSは遅い最初のレスポンスの唯一の原因ではない

アプリケーションの起動、データベースクエリ、ストレージI/O、リバースプロキシのルーティング、認証、TLSはすべて、名前解決が完了した後の最初の可視レスポンスを遅延させる可能性があります。ホスト名と制御されたアドレスベースのテストが同じくらい遅い場合、ボトルネックはDNSである可能性は低いです。

アドレスベースの比較にも限界があります。HTTPS証明書や仮想ホスティングは名前に依存し、リバースプロキシは要求されたホスト名に応じて同じIPを異なるアプリケーションにルーティングすることがあります。失敗したり挙動が異なるアドレステストは、クリーンなDNSベンチマークとは言えません。

症状の境界を慎重に使いましょう：DNSは、未キャッシュの名前使用、リゾルバの失敗、新しい接続経路の周辺で待機が集中する場合に妥当です。ルックアップ時間が無視できるほど短いのに最初のバイトまでの時間が長い場合は、DNSの可能性は低くなります。

DNS時間をTCP、TLS、アプリ時間から分離する

有用な遅延チェーンは、DNSルックアップ、接続設定、該当する場合のセキュア接続設定、リクエスト開始、レスポンス開始、コンテンツ転送です。W3CのNavigation Timing フェーズモデルは、キャッシュからのドメイン情報の場合も含め、ドメインルックアップと接続のタイムスタンプを別々に公開しています。

個々のページリソースについては、Resource Timingインターフェースがルックアップ、接続、リクエスト、レスポンスの各フェーズを分離します。クロスオリジンのプライバシールールにより一部の詳細が隠されることがあり、タイミングフィールドが欠落していることが必ずしも遅延ゼロの証拠ではありません。

Pingとファイルコピーのスループットは異なる質問に答えます。Pingは到達可能性とネットワークの往復動作を測定し、大きな転送は確立されたデータ経路を測定します。どちらもアプリが最初の接続を開く前に発生する可能性のあるホスト名解決を分離しません。

よくある質問

DNSはホームサーバーアプリ内のすべてのクリックに影響しますか？

いいえ。DNSはクライアントが新しいまたは期限切れの結果の名前解決を必要とする場合に重要です。キャッシュされたアドレス、持続的な接続、マルチプレックスされたリクエストにより、多くのやり取りは新しいネットワークDNSクエリなしで進行できます。

なぜIPアドレスでの読み込みはホスト名より速いのですか？

ホスト名をバイパスすると名前解決がそのテスト経路から除外されるため、違いはDNSを示唆するかもしれません。ただし、証明書、仮想ホスト、リダイレクト、リバースプロキシルールによりアドレス経路の動作が異なることがあるため、決定的ではありません。

mDNSは通常のローカルDNSより遅いことがありますか？

mDNSはリンクローカルマルチキャストを使用し、他のルックアップメカニズムと共存するため、動作が異なる場合があります。遅くなるかどうかはクライアント、ネットワーク、名前、キャッシュ、フォールバック動作に依存し、普遍的なmDNSのペナルティではありません。

パブリックDNSを変更するとローカルホームサーバーの名前解決が速くなりますか？

それは、そのパブリックリゾルバーが実際に成功または失敗の経路の一部である場合のみです。ローカルゾーンに保持されている名前やmDNSを通じて解決される名前は適切なローカルメカニズムを必要とし、無関係なパブリックリゾルバーを変更しても効果がない場合があります。

なぜ再起動や長時間のアイドル後にアプリが再び遅くなるのですか？

再起動や長時間のアイドル状態はキャッシュされたアドレスデータを消去し、再利用可能な接続を閉じることがあります。また、アプリ自体もウォームキャッシュを失う可能性があります。したがって、次の起動ではDNSだけでなく複数の起動段階が繰り返されることがあります。

DNSはホームNASのスループットではなく、アプリの起動時間を変える

低遅延で信頼性の高い名前解決は、最初の接続や新しいアプリの依存関係をより応答性の高いものに感じさせますが、ディスク速度や確立されたLAN転送のスループットを向上させるわけではありません。接続開始前のDNSの役割を診断し、その後TCP、TLS、アプリケーションの応答を個別に測定してから、ホームサーバーを責めてください。