Vonesa e ulët e DNS është një faktor kyç për funksionimin e shpejtë në internet. Për ta minimizuar atë, është e rëndësishme të zgjidhni me kujdes serverët DNS dhe . Por fillimisht duhet të heqim dorë nga kërkesat e padobishme.
Pikërisht për këtë arsye, DNS është krijuar fillimisht si një protokoll shumë i ruajtur. Administratorët e zonës vendosin kohën e jetës (TTL) për regjistrimet e ndryshme, ndërsa rezolutoret e përdorin këtë informacion kur ruajnë regjistrimet në memorje, për të shmangur trafikun e panevojshëm.
A është efikase ruajtja? Para disa vitesh, një studim i vogël i imi tregoi se nuk është e përsosur. Le të shohim situatën aktuale.
Për të mbledhur informacione, unë kam patchuar për të ruajtur vlerën TTL për përgjigjen. Ajo përcaktohet si TTL më i vogël i regjistrimeve të tij për çdo kërkesë që hyn. Kjo ofron një pamje të mirë të shpërndarjes së TTL të trafikut real, si dhe merr parasysh popullaritetin e kërkesave të veçanta. Versioni i patchuar i serverit punoi për disa orë.
Grupi i të dhënave përmban 1,583,579 regjistra (emri, lloji i pyetjes, TTL, marka kohore). Ky është shpërndarja e përgjithshme e TTL (osi X është TTL në sekonda):
Dukshëm, përveç një ngritjeje të vogël në 86,400 (në përgjithësi, për regjistrat SOA), është e qartë se TTL janë në një gamë të ulët. Le të shqyrtojmë më afër:
Mirë, TTL më shumë se 1 orë nuk janë statistike të rëndësishme. Atëherë, le të përqendrohemi në gamën 0–3600:
Shumica e TTL janë nga 0 deri në 15 minuta:
Pjesa dërrmuese nga 0 deri në 5 minuta:
Kjo nuk është shumë mirë.
Shpërndarja akumuluese e bën problemin edhe më të dukshëm:
Në gjysmën e përgjigjeve DNS, TTL është 1 minutë ose më pak, dhe tre të katërtat kanë 5 minuta ose më pak.
Por prisni, në të vërtetë është ende më keq. Sepse këto janë TTL nga serverat autoritativë. Megjithatë, resolvuesit e klientëve (për shembull, routerat, cache lokale) marrin TTL nga resolvuesit e lartë, dhe ai zvogëlohet çdo sekondë.
Prandaj, klienti në fakt mund të përdorë çdo regjistër, në mesatare, për gjysmën e TTL origjinal, pas së cilës do të dërgojë një kërkesë të re.
Ndoshta këto TTL shumë të ulëta lidhen vetëm me kërkesat e pazakonta, e jo me faqet e njohura të internetit dhe API-të? Le të shohim:
Osa X është TTL, osa Y është popullariteti i kërkesave.
Këtu është një zhgënjim: kërkesat më të njohura ashtu si edhe kanë një memorie të keqe.
Të afrohemi:
Verdikti është: gjithçka në të vërtetë është keq. Ka qenë keq më herët, por tani ka përkeqësuar. Keshimi DNS është bërë praktikisht i pavlerë. Me sa më pak njerëz që përdorin zgjidhësit DNS të ofruesve të tyre (për arsye të besueshme), rritja e vonesës bëhet më e dukshme.
Keshimi DNS është bërë i dobishëm vetëm për përmbajtjen që askush nuk e viziton.
Gjithashtu, vini re se softueri mund TTL të ulët.
Pse kështu?
Pse është vendosur një TTL kaq i ulët për të dhënat DNS?
- Balancuesit e ngarkesës të vjetëruar kanë mbetur me ndërlikime të paracaktuara.
- Ka mite që thonë se balancimi i ngarkesës nëpërmjet DNS varet nga TTL (kjo nuk është e vërtetë - që nga koha e Netscape Navigator, klientët zgjedhin një adresë IP të rastësishme nga grupi RR dhe provojnë një tjetër në mënyrë transparente nëse nuk mund të lidhin)
- Administratoret dëshirojnë të aplikojnë ndryshimet menjëherë, sepse është më e lehtë të planifikosh kështu.
- Administrator i serverit DNS ose i balancuesit të ngarkesës e sheh si detyrë e tij të implementojë në mënyrë efikase konfigurimin që kërkojnë përdoruesit, dhe jo të përshpejtojë funksionimin e faqeve dhe shërbimeve.
- TTL të ulët ofrojnë qetësi mendore.
- Njerëzit fillimisht vendosin TTL të ulët për testim dhe pastaj harrojnë t'i ndryshojnë ato.
Nuk e kam përfshirë "punimin e dëmtimit", për shkak se kjo është duke u bërë gjithnjë e më pak relevante. Nëse është e nevojshme të ridrejtohen përdoruesit në një rrjet tjetër për të shfaqur vetëm një faqe gabimi, kur gjithçka tjetër ka dështuar, ndoshta vonesa më e madhe se 1 minutë është e pranueshme.
Për më tepër, një TTL njëminutësh do të thotë se nëse serverët autoritativë DNS bllokohen për më shumë se 1 minutë, askush tjetër nuk do të ketë qasje në shërbimet e varura. Dhe tepërzia nuk do të ndihmojë, nëse problemi është një gabim konfigurimi apo një thyerje. Nga ana tjetër, me TTL të arsyeshëm, shumë klientë do të vazhdojnë të përdorin konfigurimin e mëparshëm dhe kurrë nuk do të vërejnë ndonjë ndryshim.
TTL të ulët janë në masë të madhe të shkaqet nga shërbimet CDN dhe balancuesit e ngarkesës, veçanërisht kur ato bashkojnë CNAME me TTL të vogla dhe regjistrime me TTL të tilla të vogla (por të pavarura):
$ 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
Sa herë që skadon CNAME ose ndonjëra nga regjistrimet A, duhet të dërgohet një kërkesë e re. Të dy kanë një TTL prej 30 sekondash, por nuk përputhen. TTL real mesatar do të jetë 15 sekonda.
Por prisni! Gjithçka është akoma më keq. Disa rezolvues veprojnë shumë keq në këtë situatë me dy TTL të ulta të lidhura:
$ drill 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
Rezolvuesi Level3, ndoshta funksionon mbi BIND. Nëse vazhdoni të dërgoni këtë kërkesë, do të keni gjithmonë një TTL që kthehet, i cili është 1. Në thelb, raw.githubusercontent.com kurrë nuk cache-het.
Ja një tjetër shembull i tillë me një domain shumë të njohur:
$ 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
Të paktën tre regjistrime CNAME. Njëra ka një TTL të arsyeshëm, por kjo është krejtësisht e panevojshme. Në CNAME-të e tjera TTL fillestar është 60 sekonda, por për domainet akamai.net TTL maksimale është 20 sekonda, dhe asnjëra prej tyre nuk është në fazë.
Çfarë ndodh me domainet që kontrollojnë vazhdimisht pajisjet Apple?
$ 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
Problemi është i njëjtë me Firefox, dhe TTL përgjithësisht mbetet në 1 sekondë kur përdorim rezolverin Level3.
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 A 162.125.67.3 $ drill 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
Për regjistrimin safebrowsing.googleapis.com vlera TTL është 60 sekonda, ashtu si për domainet e Facebook. Dhe, përsëri, nga perspektiva e klientit, këto vlera reduktohen me gjysmën.
Çfarë ndodh nëse vendosim një minimum TTL?
Duke emrin, llojin e kërkesës, TTL dhe markën e kohës të ruajtur fillimisht, unë shkrova një skript për të simuluar 1,5 milion kërkesa që kalojnë përmes një zgjidhësi të ruajtur, për të vlerësuar sasinë e kërkesave të tepërta të dërguara për shkak të skadimit të regjistrimit në cache.
47,4% e kërkesave u bënë pasi skadoi regjistrimi ekzistues. Kjo është jashtëzakonisht e lartë.
Cili do të ishte ndikimi në caching nëse vendoset një TTL minimal?
Osi X përfaqëson vlerat minimale të TTL. Regjistrimet me TTL fillestar mbi këtë vlerë nuk preken.
Osi Y tregon përqindjen e kërkesave nga klienti të cilit i ka kaluar regjistrimi në cache, por ka skaduar dhe ai bën një kërkesë të re.
Shpërndarja e kërkesave "të tepërta" zvogëlohet nga 47% në 36% thjesht duke vendosur një TTL minimal prej 5 minutash. Kur vendoset një TTL minimal prej 15 minutash, numri i këtyre kërkesave zvogëlohet në 29%. Një TTL minimal prej 1 ore i ul ata në 17%. Një ndryshim i rëndësishëm!
Çfarë nëse nuk ndryshojmë asgjë në anën e serverit, por vendosim një TTL minimal në cache-at DNS të klientit (ruterë, zgjidhës lokal)?
Numri i kërkesave të nevojshme ulet nga 47% në 34% me vendosjen e një TTL minimale prej 5 minutash, në 25% me një minimum prej 15 minutash dhe në 13% me një minimum prej 1 ore. Vlera optimale mund të jetë 40 minuta.
Ndikimi i këtij ndryshimi minimal është i madh.
Cilat janë pasojat?
Sigurisht, shërbimi mund të transferohet te një ofrues të ri të shërbimeve në cloud, një server të ri, një rrjet të ri, duke kërkuar nga klientët që të përdorin regjistrat më të fundit DNS. Dhe një TTL i ulët ndihmon për të realizuar një kalim të tillë pa probleme dhe në heshtje. Por me kalimin në infrastrukturë të re, askush nuk pret që klientët të bëjnë kalimin në regjistrat e rinj DNS brenda 1 minute, 5 minutash ose 15 minutash. Vendosja e një kohe minimale jetese prej 40 minutash në vend të 5 minutash nuk do t’i pengojë përdoruesit të kenë qasje në shërbim.
Megjithatë, kjo do të lejojë një reduktim të konsiderueshëm të vonesës dhe do të rrisë privatësinë dhe besueshmërinë, duke shmangur kërkesat e panevojshme.
Sigurisht, RFC thonë se duhet të respektohet rreptësisht TTL. Por realiteti është se sistemi DNS ka bërë shumë të paefektshëm.
Nëse punoni me serverë autoritativë DNS, ju lutemi kontrolloni TTL tuaj. Aju nevojiten vërtet vlera kaq të ulëta?
Sigurisht, ka arsye të forta për të vendosur TTL të ulëta për shenjat DNS. Por jo për 75% të trafikut DNS, i cili pothuajse nuk ndryshon.
Dhe nëse për ndonjë arsye ju nevojitet vërtet të përdorni TTL të ulët për DNS, sigurohuni gjithashtu që në faqen tuaj të mos jetë aktivizuar caching. Për të njëjtat arsye.
Nëse keni një cache lokal DNS, si , i cili lejon vendosjen e TTL minimal, përdorni këtë funksion. është në rregull. Nuk do të ndodhë asgjë e keqe. Vendosni një TTL minimal midis 40 minutash (2400 sekonda) dhe 1 ore. Një gamë shumë të arsyeshme.
Burimi: habr.com
