DNS-i madal latentsusaeg on kiire Interneti-sirvimise võti. Selle minimeerimiseks on oluline hoolikalt valida DNS-serverid ja . Kuid esimene samm on kasututest päringutest vabanemine.
Seetõttu loodi DNS algselt väga vahemällu salvestatava protokollina. Tsooni administraatorid määravad üksikute kirjete jaoks eluaja (TTL) ja lahendajad kasutavad seda teavet kirjete mällu salvestamisel, et vältida tarbetut liiklust.
Kas vahemällu salvestamine on tõhus? Paar aastat tagasi näitas mu väike uurimus, et see pole täiuslik. Heidame pilgu asjade hetkeseisule.
Teabe kogumiseks parandasin vastuse TTL väärtuse salvestamiseks. See on määratletud kui selle kirjete minimaalne TTL iga sissetuleva päringu jaoks. See annab hea ülevaate reaalse liikluse TTL jaotusest ning võtab arvesse ka üksikute päringute populaarsust. Serveri paigatud versioon töötas mitu tundi.
Saadud andmekogum koosneb 1 583 579 kirjest (nimi, qtype, TTL, ajatempel). Siin on üldine TTL-jaotus (X-telg on TTL sekundites):
Kui jätta kõrvale väike tõrge 86 juures (peamiselt SOA-kirjete puhul), on üsna selge, et TTL-id on madalas vahemikus. Vaatame lähemalt:
Olgu, üle 1 tunni kestvad TTL-id ei ole statistiliselt olulised. Seejärel keskendume vahemikule 0–3600:
Enamik TTL-e on 0 kuni 15 minutit:
Valdav enamus on 0 kuni 5 minutit:
See ei ole väga hea.
Kumulatiivne jaotus muudab probleemi veelgi ilmsemaks:
Poolte DNS-i vastuste TTL on 1 minut või vähem ja kolmel neljandikul on TTL kuni 5 minutit.
Aga oota, see on tegelikult hullem. Lõppude lõpuks on see autoriteetsete serverite TTL. Klientide lahendajad (nt ruuterid, kohalikud vahemälud) saavad aga ülesvoolu lahendajatelt TTL-i ja see väheneb iga sekundiga.
Seega saab klient enne uue päringu saatmist kasutada iga kirjet keskmiselt poole algsest TTL-ist.
Võib-olla kehtivad need väga madalad TTL-id ainult ebatavaliste taotluste, mitte populaarsete veebisaitide ja API-de puhul? Vaatame:
X-telg on TTL, Y-telg on päringu populaarsus.
Kahjuks on kõige populaarsemad päringud ka kõige halvemini vahemällu salvestatavad.
Suumime sisse:
Kohtuotsus: see on tõesti halb. See oli juba varem halb, aga läks veelgi hullemaks. DNS-i vahemälu on muutunud praktiliselt kasutuks. Kuna vähem inimesi kasutab oma Interneti-teenuse pakkuja DNS-i lahendajat (mõjuvatel põhjustel), muutub latentsusaja suurenemine märgatavamaks.
DNS-i vahemällu salvestamine on muutunud kasulikuks ainult sisu puhul, mida keegi ei külasta.
Pange tähele ka seda, et tarkvara võib tõlgendada madalaid TTL-e.
Miks nii?
Miks on DNS-kirjetele seatud nii madal TTL?
- Pärandkoormuse tasakaalustajad jäeti vaikeseadetega.
- On müüte, et DNS-i koormuse tasakaalustamine sõltub TTL-ist (see pole tõsi - Netscape Navigatori aegadest peale on kliendid valinud RR-ide hulgast juhusliku IP-aadressi ja proovinud läbipaistvalt teist, kui nad ei saa ühendust luua)
- Administraatorid soovivad muudatusi kohe rakendada, nii on lihtsam planeerida.
- DNS-serveri või koormuse tasakaalustaja administraator näeb oma ülesandena kasutajate soovitud konfiguratsiooni tõhusat juurutamist, mitte saitide ja teenuste kiirendamist.
- Madalad TTL-id annavad teile meelerahu.
- Inimesed määravad alguses testimiseks madalad TTL-id ja unustavad seejärel neid muuta.
Ma ei lisanud loendisse "tõrkeid ülekandmist", sest see muutub üha vähem asjakohaseks. Kui teil on vaja kasutajad teise võrku ümber suunata, et kuvada vealeht, kui absoluutselt kõik muu on katki, on üle 1-minutiline viivitus tõenäoliselt vastuvõetav.
Lisaks tähendab üheminutiline TTL, et kui autoriteetsed DNS-serverid blokeeritakse rohkem kui 1 minutiks, ei pääse keegi teine sõltuvatele teenustele juurde. Ja koondamine ei aita, kui põhjuseks on seadistusviga või häkkimine. Teisest küljest kasutavad paljud kliendid mõistlike TTL-ide korral varasemat konfiguratsiooni ega märka kunagi midagi.
CDN-i teenused ja koormuse tasakaalustajad on suures osas süüdi madalates TTL-ides, eriti kui need ühendavad CNAME-id madalate TTL-idega ja kirjed, millel on sama madal (kuid sõltumatu) TTL-id:
$ 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
Kui CNAME või mõni A-kirje aegub, tuleb saata uus päring. Mõlemal on 30-sekundiline TTL, kuid see pole sama. Tegelik keskmine TTL on 15 sekundit.
Aga oota! See on veel hullem. Mõned lahendajad käituvad sellises olukorras väga halvasti kahe seotud madala TTL-iga:
$ puurida raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Tõenäoliselt töötab Level3 lahendaja BIND-is. Kui jätkate selle päringu saatmist, tagastatakse alati TTL 1. Põhimõtteliselt raw.githubusercontent.com pole kunagi vahemällu salvestatud.
Siin on veel üks näide sellisest olukorrast väga populaarse domeeniga:
$ 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
Vähemalt kolm CNAME-kirjet. Jah. Ühel on korralik TTL, aga see on täiesti kasutu. Teiste CNAME-ide esialgne TTL on 60 sekundit, kuid domeenide jaoks akamai.net maksimaalne TTL on 20 sekundit ja ükski neist pole faasis.
Aga domeenid, mis küsivad pidevalt Apple'i seadmeid?
$ 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
Sama probleem nagu Firefoxil ja TTL-il jääb 1. taseme lahendaja kasutamisel enamasti 3 sekundi juurde.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN 162.125.67.3 $ puur client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Salvestusel safebrowsing.googleapis.com TTL väärtus on 60 sekundit, nagu Facebooki domeenid. Ja jällegi, kliendi seisukohast on need väärtused poole väiksemad.
Kuidas oleks minimaalse TTL-i määramisega?
Kasutades nime, päringu tüüpi, TTL-i ja algselt salvestatud ajatemplit, kirjutasin skripti, et simuleerida 1,5 miljonit vahemällu salvestamise lahendajat läbivat päringut, et hinnata aegunud vahemälukirje tõttu saadetud lisapäringute mahtu.
47,4% taotlustest tehti pärast olemasoleva rekordi aegumist. See on põhjendamatult kõrge.
Millist mõju avaldab vahemällu salvestamisele, kui määratakse minimaalne TTL?
X-telg on minimaalsed TTL väärtused. See ei mõjuta kirjeid, mille allika TTL-id on sellest väärtusest kõrgemad.
Y-telg on taotluste protsent kliendilt, kellel on juba vahemällu salvestatud kirje, kuid see on aegunud ja esitab uue päringu.
Lisapäringute osakaalu vähendatakse 47%-lt 36%-le, kui seadistate minimaalseks TTL-iks 5 minutit. Kui määrate minimaalseks TTL-iks 15 minutit, väheneb nende päringute arv 29% -ni. Minimaalne TTL 1 tund vähendab neid 17%-ni. Märkimisväärne erinevus!
Kuidas oleks, kui ei muudaks midagi serveri poolel, vaid määraks selle asemel minimaalse TTL-i kliendi DNS-i vahemäludes (ruuterid, kohalikud lahendajad)?
Nõutavate taotluste arv väheneb 47%-lt 34%-le minimaalse TTL-iga 5 minutiga, 25%-le minimaalselt 15 minutiga ja 13%-le minimaalse 1 tunniga. Võib-olla 40 minutit on optimaalne.
Selle väikese muudatuse mõju on tohutu.
Millised on tagajärjed?
Loomulikult saab teenust teisaldada uude pilveteenuse pakkujasse, uude serverisse, uude võrku, nõudes klientidelt uusimate DNS-kirjete kasutamist. Ja üsna väike TTL aitab sellist üleminekut sujuvalt ja märkamatult teha. Kuid uuele infrastruktuurile üleminekul ei eelda keegi, et kliendid migreeruvad uutele DNS-kirjetele 1 minuti, 5 minuti või 15 minuti jooksul. Minimaalse TTL-i määramine 40 minuti asemel 5 minutiks ei takista kasutajatel teenusele juurdepääsu.
See aga vähendab oluliselt latentsust ning parandab privaatsust ja usaldusväärsust, vältides tarbetuid päringuid.
Muidugi ütlevad RFC-d, et TTL-i tuleb rangelt järgida. Kuid reaalsus on see, et DNS-süsteem on muutunud liiga ebaefektiivseks.
Kui töötate autoriteetsete DNS-serveritega, kontrollige oma TTL-e. Kas tõesti vajate nii naeruväärselt madalaid väärtusi?
Loomulikult on DNS-kirjete jaoks väikeste TTL-ide seadmiseks head põhjused. Kuid mitte 75% DNS-liiklusest, mis jääb praktiliselt muutumatuks.
Ja kui teil on mingil põhjusel tõesti vaja DNS-i jaoks kasutada madalaid TTL-e, veenduge samal ajal, et teie saidil pole vahemällu lubatud. Samadel põhjustel.
Kui teil töötab kohalik DNS-i vahemälu, nt mis võimaldab teil määrata minimaalsed TTL-id, kasutage seda funktsiooni. See sobib. Midagi hullu ei juhtu. Määrake minimaalseks TTL-iks ligikaudu 40 minutit (2400 sekundit) ja 1 tund. Üsna mõistlik vahemik.
Allikas: www.habr.com