Kam DNS kechikishi Internetni tez ko'rish uchun kalit hisoblanadi. Uni minimallashtirish uchun DNS serverlarini diqqat bilan tanlash va . Lekin birinchi qadam keraksiz so'rovlardan xalos bo'lishdir.
Shuning uchun DNS dastlab yuqori darajada keshlanadigan protokol sifatida ishlab chiqilgan. Hudud ma'murlari alohida yozuvlar uchun yashash vaqtini (TTL) belgilaydilar va hal qiluvchilar keraksiz trafikni oldini olish uchun yozuvlarni xotirada saqlashda ushbu ma'lumotlardan foydalanadilar.
Keshlash samaralimi? Bir necha yil oldin, mening kichik tadqiqotlarim bu mukammal emasligini ko'rsatdi. Keling, ishlarning hozirgi holatini ko'rib chiqaylik.
Ma'lumot to'plash uchun men tuzatdim javob uchun TTL qiymatini saqlash uchun. U har bir kiruvchi so'rov uchun yozuvlarining minimal TTL sifatida aniqlanadi. Bu real trafikning TTL taqsimoti haqida yaxshi ma'lumot beradi, shuningdek, individual so'rovlarning mashhurligini hisobga oladi. Serverning yamalgan versiyasi bir necha soat ishladi.
Olingan ma'lumotlar to'plami 1 583 579 ta yozuvdan iborat (nom, qtype, TTL, vaqt tamg'asi). Mana umumiy TTL taqsimoti (X o'qi soniyalarda TTL):
86 da (asosan SOA yozuvlari uchun) kichik zarbadan tashqari, TTLlar past diapazonda ekanligi aniq. Keling, batafsil ko'rib chiqaylik:
Yaxshi, 1 soatdan ortiq TTLlar statistik ahamiyatga ega emas. Keyin 0−3600 oralig'iga e'tibor qaratamiz:
Ko'pgina TTLlar 0 dan 15 minutgacha:
Ko'pchilik 0 dan 5 daqiqagacha:
Bu unchalik yaxshi emas.
Kümülatif taqsimot muammoni yanada aniqroq qiladi:
DNS javoblarining yarmida 1 daqiqa yoki undan kam TTL, to'rtdan uch qismida esa 5 daqiqa yoki undan kam TTL mavjud.
Ammo kuting, bu haqiqatan ham yomonroq. Axir, bu nufuzli serverlardan TTL. Shu bilan birga, mijoz hal qiluvchilar (masalan, marshrutizatorlar, mahalliy keshlar) yuqori oqim rezolyutsiyalaridan TTL oladi va u har soniyada kamayadi.
Shunday qilib, mijoz yangi so'rov yuborishdan oldin har bir yozuvni o'rtacha TTLning yarmi uchun ishlatishi mumkin.
Ehtimol, bu juda past TTLlar mashhur veb-saytlar va API-larga emas, balki g'ayrioddiy so'rovlarga tegishlidir? Keling, ko'rib chiqaylik:
X o'qi - TTL, Y o'qi - so'rovlarning mashhurligi.
Afsuski, eng mashhur so'rovlar ham keshlash uchun eng yomoni.
Keling, kattalashtiramiz:
Hukm: bu juda yomon. Bu allaqachon yomon edi, lekin bundan ham yomonlashdi. DNS keshlash deyarli foydasiz bo'lib qoldi. Kamroq odam o'z ISP DNS-resolveridan foydalanar ekan (uzrli sabablarga ko'ra), kechikishning oshishi sezilarli bo'ladi.
DNS keshlash faqat hech kim tashrif buyurmaydigan kontent uchun foydali bo'ldi.
Shuni ham yodda tutingki, dasturiy ta'minot past TTLlarni talqin qilish.
Nega bunday?
Nima uchun DNS yozuvlari shunchalik past TTLga o'rnatiladi?
- Eski yuk balanslagichlari standart sozlamalar bilan qoldirildi.
- DNS yuk balansi TTL ga bog'liq degan afsonalar mavjud (bu to'g'ri emas - Netscape Navigator davridan beri mijozlar RR to'plamidan tasodifiy IP-manzilni tanlaganlar va agar ulana olmasalar, boshqasini shaffof tarzda sinab ko'rishgan)
- Administratorlar o'zgarishlarni darhol qo'llashni xohlashadi, shuning uchun rejalashtirish osonroq.
- DNS-server yoki yuk balansi ma'muri o'z vazifasini foydalanuvchilar so'ragan konfiguratsiyani samarali joylashtirish va saytlar va xizmatlarni tezlashtirmaslik deb biladi.
- Kam TTLlar sizga xotirjamlik beradi.
- Odamlar dastlab sinov uchun past TTLlarni o'rnatadilar va keyin ularni o'zgartirishni unutadilar.
Men ro‘yxatga “muvaffaqiyatsizlik”ni kiritmadim, chunki u tobora ahamiyatsiz bo‘lib bormoqda. Agar siz foydalanuvchilarni boshqa tarmoqqa yo'naltirishingiz kerak bo'lsa, faqat hamma narsa buzilganida xato sahifasini ko'rsatish uchun 1 daqiqadan ko'proq kechikish mumkin.
Bundan tashqari, bir daqiqalik TTL, agar vakolatli DNS serverlari 1 daqiqadan ko'proq vaqt davomida bloklangan bo'lsa, boshqa hech kim qaram xizmatlardan foydalana olmasligini anglatadi. Va agar sabab konfiguratsiya xatosi yoki buzg'unchilik bo'lsa, ortiqcha ish yordam bermaydi. Boshqa tomondan, oqilona TTLlar bilan ko'plab mijozlar avvalgi konfiguratsiyadan foydalanishda davom etadilar va hech qachon hech narsani sezmaydilar.
CDN xizmatlari va yuk balanslagichlari past TTLlar uchun asosan aybdor, ayniqsa ular CNAME-larni past TTL va yozuvlarni teng darajada past (lekin mustaqil) TTL bilan birlashtirganda:
$ 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 yoki A yozuvlarining amal qilish muddati tugagach, yangi so'rov yuborilishi kerak. Ikkalasida ham 30 soniyalik TTL bor, lekin u bir xil emas. Haqiqiy o'rtacha TTL 15 soniya bo'ladi.
Lekin kuting! Bundan ham battar. Ba'zi hal qiluvchilar bu vaziyatda ikkita past TTL bilan juda yomon harakat qilishadi:
$ matkap raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME IN github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3 resolver ehtimol BIND da ishlaydi. Agar siz ushbu so‘rovni yuborishda davom etsangiz, har doim 1 TTL qaytariladi. Asosan, raw.githubusercontent.com hech qachon keshda saqlanmaydi.
Juda mashhur domen bilan bunday vaziyatning yana bir misoli:
$ 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
Kamida uchta CNAME yozuvi. Ay. Birida yaxshi TTL bor, lekin u mutlaqo foydasiz. Boshqa CNAME'larda boshlang'ich TTL 60 soniyadan iborat, ammo domenlar uchun akamai.net maksimal TTL 20 soniya va ularning hech biri fazada emas.
Doimiy ravishda Apple qurilmalarini so'roq qiladigan domenlar haqida nima deyish mumkin?
$ 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
Firefox va TTL bilan bir xil muammo Level1-ni hal qiluvchidan foydalanganda ko'pincha 3 soniyada qolib ketadi.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com da. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 CNAME client.dropbox-dns.com da. client.dropbox-dns.com. 1 IN A 162.125.64.3
Yozib olishda safebrowsing.googleapis.com TTL qiymati Facebook domenlari kabi 60 soniya. Va yana, mijoz nuqtai nazaridan, bu qiymatlar ikki baravar kamayadi.
Minimal TTLni o'rnatish haqida nima deyish mumkin?
Ism, so'rov turi, TTL va dastlab saqlangan vaqt tamg'asidan foydalanib, men keshlash moslamasi orqali o'tadigan 1,5 million so'rovni taqlid qilish uchun skriptni yozdim va muddati o'tgan kesh yozuvi tufayli yuborilgan keraksiz so'rovlar hajmini taxmin qildim.
So'rovlarning 47,4 foizi mavjud yozuv muddati tugaganidan keyin qilingan. Bu asossiz darajada yuqori.
Minimal TTL o'rnatilgan bo'lsa, keshlash qanday ta'sir qiladi?
X o'qi - minimal TTL qiymatlari. Manba TTLlari bu qiymatdan yuqori boʻlgan yozuvlarga taʼsir qilmaydi.
Y o'qi - bu allaqachon keshlangan yozuvga ega bo'lgan, ammo muddati tugagan va yangi so'rov yuborayotgan mijoz so'rovlarining foizi.
"Qo'shimcha" so'rovlar ulushi oddiygina minimal TTLni 47 daqiqaga belgilash orqali 36% dan 5% gacha kamayadi. Minimal TTLni 15 daqiqaga o'rnatish orqali ushbu so'rovlar soni 29% gacha kamayadi. 1 soatlik minimal TTL ularni 17% gacha kamaytiradi. Muhim farq!
Server tomonida hech narsani o'zgartirmaslik, balki mijozning DNS keshlarida (marshrutizatorlar, mahalliy hal qiluvchilar) minimal TTL ni o'rnatish haqida nima deyish mumkin?
Talab qilinadigan so'rovlar soni kamida 47 daqiqa TTL bilan 34% dan 5% gacha, kamida 25 daqiqa bilan 15% gacha va kamida 13 soat bilan 1% gacha kamayadi. Ehtimol, 40 daqiqa optimaldir.
Ushbu kichik o'zgarishning ta'siri juda katta.
Buning oqibatlari qanday?
Albatta, xizmat yangi bulutli provayderga, yangi serverga, yangi tarmoqqa o'tkazilishi mumkin, bu esa mijozlardan so'nggi DNS yozuvlaridan foydalanishni talab qiladi. Va juda kichik TTL bunday o'tishni muammosiz va sezilmas tarzda amalga oshirishga yordam beradi. Ammo yangi infratuzilmaga o'tish bilan hech kim mijozlarning yangi DNS yozuvlariga 1 daqiqa, 5 daqiqa yoki 15 daqiqa ichida o'tishini kutmaydi. Minimal TTLni 40 daqiqa o‘rniga 5 daqiqaga belgilash foydalanuvchilarning xizmatga kirishiga to‘sqinlik qilmaydi.
Biroq, bu kechikishni sezilarli darajada kamaytiradi va keraksiz so'rovlardan qochib, maxfiylik va ishonchlilikni yaxshilaydi.
Albatta, RFClar TTLga qat'iy rioya qilish kerakligini aytadilar. Ammo haqiqat shundaki, DNS tizimi juda samarasiz bo'lib qoldi.
Agar siz nufuzli DNS serverlari bilan ishlayotgan bo'lsangiz, iltimos, TTLlaringizni tekshiring. Sizga haqiqatan ham shunday kulgili past qiymatlar kerakmi?
Albatta, DNS yozuvlari uchun kichik TTLlarni o'rnatish uchun yaxshi sabablar bor. Ammo deyarli o'zgarmagan DNS-trafikning 75% uchun emas.
Va agar biron sababga ko'ra siz haqiqatan ham DNS uchun past TTLlardan foydalanishingiz kerak bo'lsa, shu bilan birga saytingizda keshlash yoqilmaganligiga ishonch hosil qiling. Xuddi shu sabablarga ko'ra.
Agar sizda mahalliy DNS kesh ishlayotgan bo'lsa, masalan minimal TTLlarni o'rnatish imkonini beradi, bu funksiyadan foydalaning. Bu odatiy. Hech qanday yomon narsa bo'lmaydi. Minimal TTLni taxminan 40 daqiqa (2400 soniya) va 1 soatga o'rnating. Juda oqilona diapazon.
Manba: www.habr.com