تأخیر کم DNS کلیدی برای مرور سریع اینترنت است. برای به حداقل رساندن آن، مهم است که سرورهای DNS را با دقت انتخاب کنید و . اما اولین قدم این است که از شر سوالات بیهوده خلاص شوید.
به همین دلیل است که DNS در ابتدا به عنوان یک پروتکل بسیار قابل کش طراحی شد. مدیران منطقه یک زمان زنده (TTL) را برای ورودی های فردی تعیین می کنند و حل کننده ها از این اطلاعات هنگام ذخیره ورودی ها در حافظه استفاده می کنند تا از ترافیک غیرضروری جلوگیری کنند.
آیا کش موثر است؟ چند سال پیش، تحقیقات کوچک من نشان داد که کامل نبود. بیایید نگاهی به وضعیت فعلی بیندازیم.
برای جمع آوری اطلاعات وصله کردم برای ذخیره مقدار TTL برای پاسخ. به عنوان حداقل TTL رکوردهای آن برای هر درخواست ورودی تعریف می شود. این یک نمای کلی خوب از توزیع TTL ترافیک واقعی ارائه می دهد، و همچنین محبوبیت درخواست های فردی را در نظر می گیرد. نسخه وصله شده سرور چندین ساعت کار کرد.
مجموعه داده‌های حاصل از 1 رکورد (نام، نوع تعداد، TTL، مهر زمانی) تشکیل شده است. در اینجا توزیع کلی TTL است (محور X TTL در ثانیه است):
جدا از یک ضربه جزئی در 86 (بیشتر برای رکوردهای SOA)، کاملاً واضح است که TTLها در محدوده پایینی قرار دارند. بیایید نگاه دقیق تری بیندازیم:
بسیار خوب، TTLهای بیشتر از 1 ساعت از نظر آماری معنی دار نیستند. سپس بیایید روی محدوده 0-3600 تمرکز کنیم:
اکثر TTL ها از 0 تا 15 دقیقه هستند:
اکثریت قریب به اتفاق از 0 تا 5 دقیقه هستند:
خیلی خوب نیست
توزیع تجمعی مشکل را آشکارتر می کند:
نیمی از پاسخ های DNS دارای TTL 1 دقیقه یا کمتر و سه چهارم TTL 5 دقیقه یا کمتر هستند.
اما صبر کنید، در واقع بدتر است. پس از همه، این TTL از سرورهای معتبر است. با این حال، حل‌کننده‌های کلاینت (مانند روترها، کش‌های محلی) یک TTL را از حل‌کننده‌های بالادستی دریافت می‌کنند و هر ثانیه کاهش می‌یابد.
بنابراین مشتری می تواند در واقع از هر ورودی به طور متوسط برای نیمی از TTL اصلی قبل از ارسال درخواست جدید استفاده کند.
شاید این TTL های بسیار پایین فقط برای درخواست های غیرمعمول اعمال می شود و نه وب سایت ها و API های محبوب؟ بیایید نگاهی بیندازیم:
محور X TTL است، محور Y محبوبیت پرس و جو است.
متأسفانه، پرطرفدارترین پرس‌و‌جوها نیز بدترین موارد برای ذخیره‌سازی حافظه پنهان هستند.
بیایید بزرگنمایی کنیم:
حکم: واقعاً بد است. قبلاً بد بود، اما بدتر شد. کش DNS عملاً بی فایده شده است. از آنجایی که افراد کمتری از حل‌کننده DNS ISP خود استفاده می‌کنند (به دلایل خوب)، افزایش تأخیر قابل توجه‌تر می‌شود.
کش DNS فقط برای محتوایی که هیچ کس از آن بازدید نمی کند مفید است.
لطفاً توجه داشته باشید که نرم افزار ممکن است TTLهای پایین را تفسیر کنید.
چرا؟
چرا رکوردهای DNS روی TTL پایین تنظیم شده است؟
- متعادل کننده های بار قدیمی با تنظیمات پیش فرض باقی مانده اند.
- افسانه هایی وجود دارد مبنی بر اینکه تعادل بار DNS به TTL بستگی دارد (این درست نیست - از زمان Netscape Navigator، مشتریان یک آدرس IP تصادفی را از مجموعه ای از RR ها انتخاب کرده اند و اگر نمی توانند متصل شوند، به طور شفاف آدرس IP دیگری را امتحان کرده اند)
- مدیران می خواهند فوراً تغییرات را اعمال کنند، بنابراین برنامه ریزی آسان تر است.
- مدیر یک سرور DNS یا متعادل کننده بار وظیفه خود را به کار بردن پیکربندی مورد نیاز کاربران و نه افزایش سرعت سایت ها و خدمات می بیند.
- TTL های پایین به شما آرامش می دهد.
- افراد در ابتدا TTL های پایینی را برای آزمایش تعیین می کنند و سپس فراموش می کنند که آنها را تغییر دهند.
من "failover" را در لیست قرار ندادم زیرا روز به روز کمتر مرتبط می شود. اگر نیاز دارید که کاربران را به شبکه دیگری هدایت کنید تا فقط یک صفحه خطا را در زمانی که کاملاً همه چیز خراب است نشان دهید، تاخیر بیش از 1 دقیقه احتمالا قابل قبول است.
علاوه بر این، TTL یک دقیقه ای به این معنی است که اگر سرورهای DNS معتبر برای بیش از 1 دقیقه مسدود شوند، هیچ کس دیگری نمی تواند به خدمات وابسته دسترسی پیدا کند. و اگر علت یک خطای پیکربندی یا هک باشد، افزونگی کمکی نخواهد کرد. از سوی دیگر، با TTL های معقول، بسیاری از مشتریان به استفاده از پیکربندی قبلی ادامه می دهند و هرگز متوجه چیزی نمی شوند.
سرویس‌های CDN و متعادل‌کننده‌های بار تا حد زیادی مقصر TTLهای پایین هستند، به‌ویژه زمانی که CNAMEها را با TTLهای پایین و رکوردها را با TTLهای کم (اما مستقل) ترکیب می‌کنند:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
هر زمان که CNAME یا هر یک از رکوردهای A منقضی شود، یک درخواست جدید باید ارسال شود. هر دو دارای TTL 30 ثانیه ای هستند، اما یکسان نیست. میانگین واقعی TTL 15 ثانیه خواهد بود.
اما صبر کن! از این هم بدتر است. برخی از حل کننده ها در این موقعیت با دو TTL پایین مرتبط بسیار بد رفتار می کنند:
$ مته raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 در CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
حل‌کننده Level3 احتمالاً روی BIND اجرا می‌شود. اگر به ارسال این درخواست ادامه دهید، یک TTL 1 همیشه برگردانده خواهد شد. raw.githubusercontent.com هرگز کش نیست.
در اینجا نمونه دیگری از چنین وضعیتی با دامنه بسیار محبوب وجود دارد:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
حداقل سه رکورد CNAME. آی. یکی TTL مناسبی دارد، اما کاملاً بی فایده است. سایر CNAME ها دارای TTL اولیه 60 ثانیه هستند، اما برای دامنه ها akamai.net حداکثر TTL 20 ثانیه است و هیچ کدام در فاز نیستند.
دامنه‌هایی که دائماً دستگاه‌های اپل را نظرسنجی می‌کنند چطور؟
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
مشکل مشابه فایرفاکس و TTL در اکثر مواقع در زمان استفاده از حل‌کننده Level1 در 3 ثانیه گیر می‌کند.
دراپ باکس؟
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 در CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 در یک مته 162.125.67.3 $ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 در CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
در هنگام ضبط safebrowsing.googleapis.com مقدار TTL مانند دامنه های فیس بوک 60 ثانیه است. و باز هم از دیدگاه مشتری این مقادیر نصف می شوند.
تنظیم حداقل TTL چطور؟
با استفاده از نام، نوع درخواست، TTL، و مهر زمانی ذخیره شده اولیه، اسکریپتی نوشتم تا 1,5 میلیون درخواست را که از طریق حل‌کننده ذخیره‌سازی عبور می‌کنند، شبیه‌سازی کنم تا حجم درخواست‌های غیرضروری ارسال‌شده به دلیل منقضی‌شده حافظه پنهان را تخمین بزنم.
47,4 درصد از درخواست ها پس از انقضای سابقه موجود انجام شده است. این بی دلیل زیاد است.
اگر حداقل TTL تنظیم شود چه تاثیری بر حافظه پنهان خواهد داشت؟
محور X حداقل مقادیر TTL است. سوابق با منبع TTL بالاتر از این مقدار تحت تأثیر قرار نمی گیرند.
محور Y درصد درخواست‌های یک کلاینت است که قبلاً یک ورودی حافظه پنهان دارد، اما منقضی شده است و درخواست جدیدی می‌کند.
تنها با تنظیم حداقل TTL روی 47 دقیقه، سهم درخواست‌های «اضافی» از 36 درصد به 5 درصد کاهش می‌یابد. با تنظیم حداقل TTL روی 15 دقیقه، تعداد این درخواست ها به 29 درصد کاهش می یابد. حداقل TTL 1 ساعت آنها را به 17 درصد کاهش می دهد. تفاوت معنی دار!
چطور در سمت سرور چیزی را تغییر ندهید، اما به جای آن حداقل TTL را در کش های DNS مشتری (روترها، حل کننده های محلی) تنظیم کنید؟
تعداد درخواست های مورد نیاز از 47٪ به 34٪ با حداقل TTL 5 دقیقه، به 25٪ با حداقل 15 دقیقه و به 13٪ با حداقل 1 ساعت کاهش می یابد. شاید 40 دقیقه بهینه باشد.
تاثیر این تغییر کوچک بسیار زیاد است.
عواقب آن چیست؟
البته، این سرویس می تواند به یک ارائه دهنده ابر جدید، سرور جدید، شبکه جدید منتقل شود و مشتریان را ملزم به استفاده از آخرین رکوردهای DNS کند. و یک TTL نسبتاً کوچک به انجام چنین انتقالی هموار و نامحسوس کمک می کند. اما با انتقال به زیرساخت های جدید، هیچ کس انتظار ندارد که مشتریان ظرف مدت 1 دقیقه، 5 دقیقه یا 15 دقیقه به رکوردهای DNS جدید مهاجرت کنند. تنظیم حداقل TTL به 40 دقیقه به جای 5 دقیقه مانع از دسترسی کاربران به سرویس نمی شود.
با این حال، این به طور قابل توجهی تاخیر را کاهش می دهد و با اجتناب از درخواست های غیر ضروری، حریم خصوصی و قابلیت اطمینان را بهبود می بخشد.
البته RFC ها می گویند که TTL باید به شدت رعایت شود. اما واقعیت این است که سیستم DNS بیش از حد ناکارآمد شده است.
اگر با سرورهای DNS معتبر کار می کنید، لطفاً TTL های خود را بررسی کنید. آیا واقعاً به چنین مقادیر مسخره پایینی نیاز دارید؟
البته دلایل خوبی برای تنظیم TTL های کوچک برای رکوردهای DNS وجود دارد. اما نه برای 75 درصد از ترافیک DNS که تقریباً بدون تغییر باقی مانده است.
و اگر به دلایلی واقعاً نیاز به استفاده از TTLهای کم برای DNS دارید، در عین حال مطمئن شوید که سایت شما کش فعال نباشد. به همین دلایل.
اگر یک کش DNS محلی در حال اجرا دارید، مانند که به شما امکان می دهد حداقل TTL ها را تنظیم کنید، از این تابع استفاده کنید. این خوبه. هیچ اتفاق بدی نخواهد افتاد. حداقل TTL را روی تقریباً 40 دقیقه (2400 ثانیه) و 1 ساعت تنظیم کنید. محدوده کاملا منطقی
منبع: www.habr.com