مزايا الأداء
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
مقدمة: أسباب زمن استجابة نظام أسماء النطاقات وتخفيفه
نظرًا لتزايد تعقيد صفحات الويب وزيادة مستوى الرجوع إلى الموارد من نطاقات عديدة، يمكن أن تصبح عمليات بحث نظام أسماء النطاقات بمثابة عقبة كبيرة في تجربة التصفح.
كلما احتاج العميل إلى الاستعلام عن محلل نظام أسماء النطاقات عبر الشبكة، يمكن أن يكون وقت الاستجابة المُدخل كبيرًا، بناءً على القرب وعدد خوادم الأسماء التي يجب على المحلل الاستعلام عنها (نادر الحدوث أكثر من 2، لكن يمكن أن يحدث ذلك).
على سبيل المثال، تعرض لقطة الشاشة التالية التوقيتات التي تم الإبلاغ عنها بواسطة أداة قياس أداء الويب سرعة الصفحة.
ويمثل كل شريط موردًا تتم الإشارة إليه من الصفحة، وتشير المقاطع السوداء
إلى عمليات بحث نظام أسماء النطاقات.
في هذه الصفحة، يتم إجراء 13 عملية بحث خلال أول 11 ثانية يتم فيها تحميل الصفحة.
على الرغم من أنّ العديد من عمليات البحث يتم إجراؤها بالتوازي، إلا أنّ لقطة الشاشة تُظهر أنّه يجب 5 مرات بحث تسلسلي، وهو ما يمثّل عدة ثوانٍ من إجمالي وقت تحميل الصفحة الذي يبلغ 11 ثانية.
هناك مكونان لوقت استجابة نظام أسماء النطاقات:
- وقت الاستجابة بين العميل (المستخدم) وخادم تحليل نظام أسماء النطاقات (DNS).
وفي معظم الحالات، ترجع أسباب ذلك إلى القيود المعتادة لوقت إرسال البيانات واستقبالها في الأنظمة المتصلة بالشبكة، ومنها: المسافة الجغرافية بين أجهزة العميل والخادم، وازدحام الشبكة، وفقدان الحزم، وتأخيرات إعادة الإرسال الطويلة (ثانية واحدة في المتوسط)، والخوادم المحملة بشكل زائد، وهجمات الحرمان من الخدمة، وما إلى ذلك.
- وقت الاستجابة بين تحليل الخوادم وخوادم الأسماء الأخرى.
ويرجع مصدر وقت الاستجابة هذا في المقام الأول إلى العوامل التالية:
- ذاكرة التخزين المؤقت مفقودة.
إذا تعذّر عرض استجابة من ذاكرة التخزين المؤقت لبرنامج حل، ولكن يتطلب إرسال طلبات بحث متكررة عن خوادم أسماء أخرى، سيكون وقت استجابة الشبكة المضافة مهمًا، لا سيما إذا كانت الخوادم الموثوقة بعيدة عن المواقع الجغرافية.
- يتم توفير المتطلبات اللازمة.
في حال تحميل برامج تعيين نظام أسماء النطاقات بشكلٍ زائد، يجب أن تضع هذه البرامج في قائمة انتظار طلبات واستجابات تحليل نظام أسماء النطاقات، وقد تبدأ في إسقاط الحزم وإعادة إرسالها.
- الزيارات الضارة:
حتى إذا كانت خدمة نظام أسماء النطاقات محدودة الإدارة، يمكن أن تتسبب حركة بيانات الحرمان من الخدمات في وضع حمل غير مبرر
على الخوادم.
وبالمثل، قد تتضمن الهجمات المصممة بأسلوب Kaminsky ملء برامج التعيين
بطلبات بحث مضمونة لتجاوز ذاكرة التخزين المؤقت وتتطلب طلبات صادرة
لحل المشكلة.
نعتقد أنّ عامل اختفاء ذاكرة التخزين المؤقت هو السبب الأكثر شيوعًا لوقت استجابة نظام أسماء النطاقات،
ونناقشه بمزيد من التفصيل أدناه.
ذاكرة التخزين المؤقت مفقودة
وحتى إذا كان برنامج التعيين يحتوي على موارد محلية وفيرة، يصعب تجنُّب حالات التأخير الأساسية
المرتبطة بالتحدّث إلى خوادم الأسماء البعيدة.
بعبارة أخرى، على افتراض توفير برنامج التعيين بشكل جيد بما يكفي بحيث لا تستغرق نتائج ذاكرة التخزين المؤقت أي وقت من جهة الخادم، تظل ذاكرة التخزين المؤقت المفقودة مكلفة للغاية من حيث وقت الاستجابة.
للتعامل مع الخطأ، يجب أن يتحدث برنامج التعيين إلى خادم واحد على الأقل، ولكن في الغالب إلى خادمين أو أكثر
من خوادم الأسماء الخارجية.
عند تشغيل زاحف الويب Googlebot، لاحظنا أنّ متوسط وقت الدقة
يبلغ 130 ملي ثانية لخوادم الأسماء التي تستجيب.
ومع ذلك، تنتهي مهلة 4-6% كاملة من الطلبات بسبب فقدان حزمة بروتوكول مخطط بيانات المستخدم (UDP) وعدم إمكانية الوصول إلى الخوادم.
إذا أخذنا في الاعتبار حالات الفشل مثل فقدان الحزم، وخوادم الأسماء المعطلة، وأخطاء إعداد نظام أسماء النطاقات، وما إلى ذلك، فإن متوسط الوقت الفعلي للحل الشامل بين الأطراف هو 300-400 ملي ثانية.
ومع ذلك، هناك تباين كبير ونطاق طويل.
على الرغم من أنّ معدّل الخطأ في ذاكرة التخزين المؤقت قد يختلف من خوادم إلى نظام أسماء النطاقات، إلا أنّه من الصعب جدًا تجنّب حدوث أخطاء في ذاكرة التخزين المؤقت، وذلك للأسباب التالية:
- حجم الإنترنت ونموه.
فببساطة، مع نمو الإنترنت، سواء من خلال إضافة مستخدمين جدد أو إضافة مواقع جديدة، يحظى معظم المحتوى باهتمام هامشي.
وفي حين أنّ بعض المواقع الإلكترونية (وبالتالي أسماء نظام أسماء النطاقات) تحظى بشعبية كبيرة، فإنّ معظمها يحظى باهتمام عدد قليل من المستخدمين فقط ولا يتم الوصول إليها إلا نادرًا، لذلك ينتج عن معظم الطلبات عدم توفّر ذاكرة التخزين المؤقت.
- قيم مدة البقاء (TTL) منخفضة.
يعني الاتجاه نحو قيم أقل لمدة DNS TTL أن الحلول تحتاج إلى عمليات بحث أكثر تكرارًا.
- عزل ذاكرة التخزين المؤقت.
عادةً ما يتم نشر خوادم نظام أسماء النطاقات خلف أجهزة موازنة الحمل التي تخصص استعلامات
إلى أجهزة مختلفة عشوائيًا.
ينتج عن ذلك احتفاظ كل خادم فردي بذاكرة تخزين مؤقت منفصلة بدلاً من القدرة على إعادة استخدام درجات الدقة المخزَّنة مؤقتًا من وحدة تخزين مجمّعة مشتركة.
إجراءات الحدّ
لقد طبّقنا العديد من الطرق في نظام أسماء النطاقات العامة من Google لتسريع أوقات البحث في نظام أسماء النطاقات.
بعض هذه الأساليب قياسية إلى حد ما، والبعض الآخر تجريبي:
- توفير الخوادم بشكل كافٍ للتعامل مع التحميل من زيارات العميل، بما في ذلك حركة المرور الضارة.
- منع هجمات الحرمان من الخدمات وهجمات التضخيم.
على الرغم من أنّ هذه مشكلة أمان في الغالب، وتؤثّر في برامج التعيين المغلقة أقل من تلك المفتوحة، إلّا أنّ منع هجمات الحرمان من الخدمات يكون له فائدة أيضًا في الأداء من خلال التخلص من عبء الزيارات الإضافي الواقع على خوادم نظام أسماء النطاقات.
للحصول على معلومات عن الأساليب التي نستخدمها لتقليل احتمالات حدوث هجمات، يُرجى الاطّلاع على صفحة مزايا الأمان.
- موازنة التحميل للتخزين المؤقت المشترك، لتحسين معدل نتائج ذاكرة التخزين المؤقت المجمّعة عبر مجموعة العرض.
- توفير تغطية عالمية للقرب من جميع المستخدمين.
توفير مجموعات عرض بشكل كافٍ
ويجب أن تؤدي برامج تعيين نظام أسماء النطاقات في التخزين المؤقت إلى إجراء عمليات أكثر تكلفة من خوادم الأسماء الموثوقة، وذلك لأن العديد من الاستجابات لا يمكن عرضها من الذاكرة،
وبدلاً من ذلك، فإنها تتطلب الاتصال بخوادم أسماء أخرى وبالتالي تتطلب
الكثير من إدخال/إخراج الشبكة.
بالإضافة إلى ذلك، تكون برامج التعيين المفتوحة عرضة بشكل كبير لمحاولات خداع ذاكرة التخزين المؤقت،
مما يؤدي إلى زيادة معدل فقدان ذاكرة التخزين المؤقت (مثل هذه الهجمات ترسل على وجه التحديد طلبات لأسماء مزيّفة لا يمكن حلها من ذاكرة التخزين المؤقت)، ولهجمات الحرمان من الخدمات التي تضيف إلى الحمل على حركة المرور.
إذا لم يتم توفير برامج التعيين بشكل كافٍ ويتعذّر عليها مواكبة التحميل، قد يكون لذلك تأثير سلبي للغاية على الأداء.
حيث يتم إسقاط الحزم ويجب إعادة إرسالها، ويجب وضع طلبات خادم الأسماء في قائمة الانتظار، وما إلى ذلك.
كل هذه العوامل تضيف إلى التأخيرات.
لذلك، من المهم أن يتم تزويد برامج تعيين نظام أسماء النطاقات بالإدخالات
والإخراج الكبير.
وهذا يشمل التعامل مع هجمات الحرمان من الخدمات الموزعة المحتملة، التي يكون الحل الوحيد لها هو التوفير الزائد في العديد من الأجهزة.
في الوقت نفسه، من المهم عدم خفض معدل نتائج ذاكرة التخزين المؤقت عند إضافة أجهزة، فهذا يتطلب تطبيق سياسة فعالة لموازنة التحميل، وهي سياسة نناقشها أدناه.
توزيع الحمل للتخزين المؤقت المشترك
في الواقع، يمكن أن يؤدي توسيع نطاق البنية الأساسية لبرنامج التعيين من خلال إضافة أجهزة إلى نتائج عكسية وتقليل معدّل نتائج ذاكرة التخزين المؤقت إذا لم تتم موازنة التحميل بشكل صحيح.
في عملية النشر النموذجية، يتم وضع أجهزة متعددة وراء جهاز لموازنة الحمل يوزِّع حركة البيانات على كل جهاز بالتساوي، وذلك باستخدام خوارزمية بسيطة مثل Round robin.
وينتج عن ذلك أن كل جهاز يحتفظ بذاكرة التخزين المؤقت المستقلة الخاصة به،
بحيث يتم عزل المحتوى المخزَّن مؤقتًا على جميع الأجهزة.
إذا تم توزيع كل طلب بحث وارد على جهاز عشوائي، وبناءً على طبيعة عدد الزيارات، يمكن زيادة معدّل فقدان ذاكرة التخزين المؤقت الفعّال بشكل متناسب.
على سبيل المثال، بالنسبة إلى الأسماء ذات قيم TTL الطويلة التي يتم الاستعلام عنها بشكل متكرر، يمكن زيادة معدل فقدان ذاكرة التخزين المؤقت من خلال عدد الأجهزة في المجموعة.
(بالنسبة إلى الأسماء التي تحتوي على قيم مدة البقاء (TTL) قصيرة جدًا أو التي يتم الاستعلام عنها بشكل غير متكرر أو التي تؤدي إلى استجابات غير قابلة للتخزين المؤقت (0 مدة البقاء وأخطاء)، لا يتأثر معدل الخطأ في ذاكرة التخزين المؤقت بإضافة الأجهزة).
لزيادة معدل النتائج للأسماء القابلة للتخزين المؤقت، من المهم تحميل خوادم موازنة التحميل بحيث لا تكون ذاكرة التخزين المؤقت مجزأة.
في نظام أسماء النطاقات العام من Google، لدينا مستويان من التخزين المؤقت.
تحتوي ذاكرة التخزين المؤقت الصغيرة لكل جهاز على الأسماء الأكثر شيوعًا، وذلك في إحدى مجموعات الأجهزة القريبة جدًا من المستخدم.
إذا لم تتمكن من تنفيذ طلب بحث من ذاكرة التخزين المؤقت هذه، سيتم إرساله إلى مجموعة أخرى من الأجهزة التي تقسّم ذاكرة التخزين المؤقت حسب الأسماء.
بالنسبة إلى ذاكرة التخزين المؤقت من المستوى الثاني هذه، يتم إرسال جميع طلبات البحث التي تحمل الاسم نفسه إلى الجهاز نفسه، حيث يتم تخزين الاسم مؤقتًا أو ليس كذلك.
توزيع مجموعات عرض الإعلانات على مستوى التغطية الجغرافية الواسعة
بالنسبة إلى برامج التعيين المغلقة، لا يمثل هذا في الواقع مشكلة.
بالنسبة إلى برامج التعيين المفتوحة، كلما اقتربت الخوادم من المستخدمين، قلّ وقت الاستجابة الذي سيظهر لهم عند نهاية البرنامج.
بالإضافة إلى ذلك، قد يؤدي توفّر تغطية جغرافية كافية إلى تحسين وقت الاستجابة التام بين الأطراف بشكل غير مباشر، لأنّ خوادم الأسماء عادةً ما تعرض نتائج محسَّنة للموقع الجغرافي الخاص ببرنامج محلل نظام أسماء النطاقات.
وهذا يعني أنه إذا استضاف موفر المحتوى مواقع إلكترونية مكررة في جميع أنحاء العالم، ستعرض خوادم أسماء مقدّم المحتوى عنوان IP في مكان قريب من برنامج تعيين نظام أسماء النطاقات.
تتم استضافة "نظام أسماء النطاقات العام من Google" في مراكز البيانات حول العالم، ويستخدم توجيه أي بث لإرسال المستخدمين إلى أقرب مركز بيانات جغرافيًا.
بالإضافة إلى ذلك، يدعم "نظام أسماء النطاقات العام من Google" الشبكة الفرعية لعميل EDNS (ECS)، وهي امتداد لبروتوكول نظام أسماء النطاقات لبرامج التعيين لإعادة توجيه موقع العميل إلى خوادم الأسماء،
التي يمكنها عرض استجابات حسّاسة للموقع الجغرافي تم تحسينها لعنوان IP للعميل الفعلي، بدلاً من عنوان IP للمحلل.
يُرجى قراءة هذه الأسئلة الشائعة للاطّلاع على التفاصيل.
نظام أسماء النطاقات العام من Google يرصد تلقائيًا خوادم الأسماء
التي تتوافق مع الشبكة الفرعية لعميل EDNS.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eDNS lookups significantly impact website loading speed, especially with resource-heavy pages referencing multiple domains.\u003c/p\u003e\n"],["\u003cp\u003eDNS latency stems from network factors between clients and resolvers and between resolvers and other name servers, with cache misses being a primary contributor.\u003c/p\u003e\n"],["\u003cp\u003eCache misses are difficult to avoid due to the Internet's vastness, short DNS record lifespans, and isolated caching systems across servers.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS employs strategies like global server distribution, load balancing, and security measures to mitigate DNS latency and enhance performance.\u003c/p\u003e\n"]]],["DNS latency, a significant factor in web browsing speed, is primarily caused by client-resolver latency and resolver-name server latency. Cache misses, due to internet growth, low TTL values, and cache isolation, are a dominant factor. Mitigations include adequately provisioning servers to handle traffic, preventing DoS attacks, load-balancing for shared caching, and ensuring global server coverage. Google Public DNS uses techniques such as two-level caching and EDNS client subnet support to minimize lookup times.\n"],null,["# Performance Benefits\n\nIntroduction: causes and mitigations of DNS latency\n---------------------------------------------------\n\nAs web pages become more complex, referencing resources from numerous domains,\nDNS lookups can become a significant bottleneck in the browsing experience.\nWhenever a client needs to query a DNS resolver over the network, the latency\nintroduced can be significant, depending on the proximity and number of\nname servers the resolver has to query (more than 2 is rare, but it can happen).\nAs an example, the following screen shot shows the timings reported by the\n[Page Speed](/speed/pagespeed) web performance measurement tool.\nEach bar represents a resource referenced from the page; the black segments\nindicate DNS lookups.\nIn this page, 13 lookups are made in the first 11 seconds in which the page is\nloaded.\nAlthough several of the lookups are done in parallel, the screen shot shows that\n5 serial lookup times are required, accounting for several seconds of the total\n11 seconds page load time.\n\nThere are two components to DNS latency:\n\n- Latency between the client (user) and DNS resolving server. In most cases this is largely due to the usual round-trip time (RTT) constraints in networked systems: geographical distance between client and server machines; network congestion; packet loss and long retransmit delays (one second on average); overloaded servers, denial-of-service attacks and so on.\n- Latency between resolving servers and other name servers. This source of latency is caused primarily by the following factors:\n - Cache misses. If a response cannot be served from a resolver's cache, but requires recursively querying other name servers, the added network latency is considerable, especially if the authoritative servers are geographically remote.\n - Underprovisioning. If DNS resolvers are overloaded, they must queue DNS resolution requests and responses, and may begin dropping and retransmitting packets.\n - Malicious traffic. Even if a DNS service is overprovisioned, DoS traffic can place undue load on the servers. Similarly, Kaminsky-style attacks can involve flooding resolvers with queries that are guaranteed to bypass the cache and require outgoing requests for resolution.\n\nWe believe that the cache miss factor is the most dominant cause of DNS latency,\nand discuss it further below.\n\n### Cache misses\n\nEven if a resolver has abundant local resources, the fundamental delays\nassociated with talking to remote name servers are hard to avoid.\nIn other words, assuming the resolver is provisioned well enough so that cache\nhits take zero time on the server-side, cache misses remain very expensive in\nterms of latency.\nTo handle a miss, a resolver has to talk to at least one, but often two or more\nexternal name servers.\nOperating the Googlebot web crawler, we have observed an average resolution time\nof 130 ms for name servers that respond.\nHowever, a full 4-6% of requests simply time out, due to UDP packet loss and\nservers being unreachable.\nIf we take into account failures such as packet loss, dead name servers, DNS\nconfiguration errors, etc., the **actual** average end-to-end resolution time is\n300-400 ms.\nHowever, there is high variance and a long tail.\n\nThough the cache miss rate may vary among DNS servers, cache misses are\nfundamentally difficult to avoid, for the following reasons:\n\n- Internet size and growth. Quite simply, as the Internet grows, both through the addition of new users and of new sites, most content is of marginal interest. While a few sites (and consequently DNS names) are very popular, most are of interest to only a few users and are accessed rarely; so the majority of requests result in cache misses.\n- Low time-to-live (TTL) values. The trend towards lower DNS TTL values means that resolutions need more frequent lookups.\n- Cache isolation. DNS servers are typically deployed behind load balancers which assign queries to different machines at random. This results in each individual server maintaining a separate cache rather than being able to reuse cached resolutions from a shared pool.\n\n### Mitigations\n\nIn Google Public DNS, we have implemented several approaches to speeding up DNS\nlookup times.\nSome of these approaches are fairly standard; others are experimental:\n\n- [Provisioning servers adequately](#provision) to handle the load from client traffic, including malicious traffic.\n- Preventing DoS and amplification attacks. Although this is mostly a security issue, and affects closed resolvers less than open ones, preventing DoS attacks also has a benefit for performance by eliminating the extra traffic burden placed on DNS servers. For information on the approaches we are using to minimize the chance of attacks, see the page on [security benefits](/speed/public-dns/docs/security).\n- [Load-balancing for shared caching](#loadbalance), to improve the aggregated cache hit rate across the serving cluster.\n- [Providing global coverage](#geography) for proximity to all users.\n\nProvisioning serving clusters adequately\n----------------------------------------\n\nCaching DNS resolvers have to perform more expensive operations than\nauthoritative name servers, since many responses cannot be served from memory;\ninstead, they require communication with other name servers and thus demand a\nlot of network input/output.\nFurthermore, open resolvers are highly vulnerable to cache poisoning attempts,\nwhich increase the cache miss rate (such attacks specifically send requests for\nbogus names that can't be resolved from cache), and to DoS attacks, which add to\nthe traffic load.\nIf resolvers are not provisioned adequately and cannot keep up with the load,\nthis can have a very negative impact on performance.\nPackets get dropped and need to be retransmitted, name server requests have to\nbe queued, and so on.\nAll of these factors add to delays.\n\nTherefore, it's important for DNS resolvers to be provisioned for high-volume\ninput/output.\nThis includes handling possible DDoS attacks, for which the only effective\nsolution is to over-provision with many machines.\nAt the same time, however, it's important not to reduce the cache hit rate when\nyou add machines; this requires implementing an effective load-balancing policy,\nwhich we discuss below.\n\nLoad-balancing for shared caching\n---------------------------------\n\nScaling resolver infrastructure by adding machines can actually backfire and\n**reduce** the cache hit rate if load balancing is not done properly.\nIn a typical deployment, multiple machines sit behind a load balancer that\nequally distributes traffic to each machine, using a simple algorithm such as\nround robin.\nThe result of this is that each machine maintains its own independent cache,\nso that the cached content is isolated across machines.\nIf each incoming query is distributed to a random machine, depending on the\nnature of the traffic, the effective cache miss rate can be increased\nproportionally.\nFor example, for names with long TTLs that are queried repeatedly, the cache\nmiss rate can be increased by the number of machines in the cluster.\n(For names with very short TTLs, that are queried very infrequently, or that\nresult in uncacheable responses (0 TTL and errors), the cache miss rate is not\nreally affected by adding machines.)\n\nTo boost the hit rate for cacheable names, it's important to load-balance\nservers so that the cache is not fragmented.\nIn Google Public DNS, we have two levels of caching.\nIn one pool of machines, very close to the user, a small per-machine cache\ncontains the most popular names.\nIf a query cannot be satisfied from this cache, it is sent to another pool of\nmachines that partition the cache by names.\nFor this second level cache, all queries for the same name are sent to the same\nmachine, where the name is either cached or it isn't.\n\nDistributing serving clusters for wide geographical coverage\n------------------------------------------------------------\n\nFor closed resolvers, this is not really an issue.\nFor open resolvers, the closer your servers are located to your users,\nthe less latency they will see at the client end.\nIn addition, having sufficient geographical coverage can indirectly improve\nend-to-end latency, as name servers typically return results optimized for the\nDNS resolver's location.\nThat is, if a content provider hosts mirrored sites around the world, that\nprovider's name servers will return the IP address in closest proximity to the\nDNS resolver.\n\nGoogle Public DNS is hosted in data centers worldwide, and uses anycast routing\nto send users to the geographically closest data center.\n\nIn addition, Google Public DNS supports [EDNS client subnet (ECS)](https://tools.ietf.org/html/rfc7871), a DNS\nprotocol extension for resolvers to forward client location to name servers,\nwhich can return location-sensitive responses optimized for the actual client\nIP address, rather than the resolver's IP address.\nPlease read [this FAQ](/speed/public-dns/faq#cdn) for details.\nGoogle Public DNS [automatically detects name servers](//groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM)\nthat support EDNS Client Subnet."]]
