Vonesa e ulët DNS është çelësi për shfletimin e shpejtë të internetit. Për ta minimizuar atë, është e rëndësishme të zgjidhni me kujdes serverët DNS dhe . Por hapi i parë është të heqësh qafe pyetjet e padobishme.
Kjo është arsyeja pse DNS fillimisht u projektua si një protokoll shumë i fshehtë. Administratorët e zonës caktojnë një kohë për të jetuar (TTL) për hyrjet individuale dhe zgjidhësit e përdorin këtë informacion kur ruajnë hyrjet në memorie për të shmangur trafikun e panevojshëm.
A është memoria efektive? Disa vite më parë, hulumtimi im i vogël tregoi se nuk ishte perfekt. Le të hedhim një vështrim në gjendjen aktuale të punëve.
Për të mbledhur informacion, unë arnova për të ruajtur vlerën TTL për përgjigjen. Përcaktohet si TTL minimale e të dhënave të tij për çdo kërkesë hyrëse. Kjo jep një pasqyrë të mirë të shpërndarjes TTL të trafikut real, dhe gjithashtu merr parasysh popullaritetin e kërkesave individuale. Versioni i arnuar i serverit funksionoi për disa orë.
Seti i të dhënave që rezulton përbëhet nga 1 regjistrime (emri, lloji, TTL, vula kohore). Këtu është shpërndarja e përgjithshme TTL (boshti X është TTL në sekonda):
Përveç një përplasjeje të vogël në 86 (kryesisht për regjistrimet SOA), është mjaft e qartë se TTL-të janë në intervalin e ulët. Le të hedhim një vështrim më të afërt:
Në rregull, TTL-të më të mëdha se 1 orë nuk janë statistikisht domethënëse. Pastaj le të përqendrohemi në diapazonin 0−3600:
Shumica e TTL-ve janë nga 0 deri në 15 minuta:
Shumica dërrmuese janë nga 0 deri në 5 minuta:
Nuk është shumë mirë.
Shpërndarja kumulative e bën problemin edhe më të dukshëm:
Gjysma e përgjigjeve DNS kanë një TTL prej 1 minutë ose më pak, dhe tre të katërtat kanë një TTL prej 5 minutash ose më pak.
Por prisni, në fakt është më keq. Në fund të fundit, ky është TTL nga serverët autoritativ. Sidoqoftë, zgjidhësit e klientëve (p.sh. ruterat, cache lokale) marrin një TTL nga zgjidhësit në rrjedhën e sipërme dhe ai zvogëlohet çdo sekondë.
Kështu që klienti mund të përdorë çdo hyrje, mesatarisht, për gjysmën e TTL origjinale përpara se të dërgojë një kërkesë të re.
Ndoshta këto TTL shumë të ulëta zbatohen vetëm për kërkesa të pazakonta dhe jo për faqet e internetit dhe API-të e njohura? Le t'i hedhim një sy:
Boshti X është TTL, boshti Y është popullariteti i pyetjeve.
Për fat të keq, pyetjet më të njohura janë gjithashtu më të këqijat për të ruajtur memorien.
Le të zmadhojmë:
Verdikti: është vërtet keq. Ishte tashmë keq më parë, por u bë edhe më keq. DNS caching është bërë praktikisht i padobishëm. Ndërsa më pak njerëz përdorin zgjidhësin DNS të ISP-së së tyre (për arsye të mira), rritja e vonesës bëhet më e dukshme.
DNS caching është bërë i dobishëm vetëm për përmbajtjen që askush nuk e viziton.
Ju lutemi vini re gjithashtu se softueri mund interpretojnë TTL të ulëta.
Pse kaq?
Pse të dhënat DNS vendosen në një TTL kaq të ulët?
- Balancuesit e ngarkesës së vjetër kanë mbetur me cilësimet e paracaktuara.
- Ka mite që balancimi i ngarkesës DNS varet nga TTL (kjo nuk është e vërtetë - që nga ditët e Netscape Navigator, klientët kanë zgjedhur një adresë IP të rastësishme nga një grup RR dhe kanë provuar në mënyrë transparente një tjetër nëse nuk mund të lidhen)
- Administratorët duan të aplikojnë ndryshimet menjëherë, kështu që është më e lehtë të planifikosh.
- Administratori i një serveri DNS ose balancuesi i ngarkesës e sheh detyrën e tij si vendosjen efikase të konfigurimit që kërkojnë përdoruesit dhe jo përshpejtimin e faqeve dhe shërbimeve.
- TTL-të e ulëta ju japin paqe mendore.
- Njerëzit fillimisht vendosin TTL të ulëta për testim dhe më pas harrojnë t'i ndryshojnë ato.
Nuk e përfshiva "failover" në listë sepse po bëhet gjithnjë e më pak e rëndësishme. Nëse ju duhet të ridrejtoni përdoruesit në një rrjet tjetër vetëm për të shfaqur një faqe gabimi kur absolutisht gjithçka tjetër është e prishur, një vonesë prej më shumë se 1 minutë është ndoshta e pranueshme.
Për më tepër, një TTL një minutëshe do të thotë që nëse serverët autoritativ DNS bllokohen për më shumë se 1 minutë, askush tjetër nuk do të jetë në gjendje të hyjë në shërbimet e varura. Dhe teprica nuk do të ndihmojë nëse shkaku është një gabim konfigurimi ose një hak. Nga ana tjetër, me TTL të arsyeshme, shumë klientë do të vazhdojnë të përdorin konfigurimin e mëparshëm dhe kurrë nuk do të vërejnë asgjë.
Shërbimet CDN dhe balancuesit e ngarkesës janë kryesisht fajtorë për TTL të ulëta, veçanërisht kur kombinojnë CNAME me TTL të ulëta dhe regjistrime me TTL po aq të ulëta (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ë CNAME ose ndonjë nga të dhënat A skadon, një kërkesë e re duhet të dërgohet. Të dy kanë një TTL 30 sekonda, por nuk është njësoj. Mesatarja aktuale TTL do të jetë 15 sekonda.
Por prit! Është edhe më keq. Disa zgjidhës sillen shumë keq në këtë situatë me dy TTL të ulëta të lidhura:
$ stërvitje raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 NË CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Zgjidhësi Level3 ndoshta funksionon në BIND. Nëse vazhdoni ta dërgoni këtë kërkesë, një TTL prej 1 do të kthehet gjithmonë. Në thelb, raw.githubusercontent.com nuk ruhet kurrë.
Këtu është një shembull tjetër i një situate të tillë me një domen 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 rekorde CNAME. Aj. Njëri ka një TTL të mirë, por është plotësisht i padobishëm. CNAME-të e tjerë kanë një TTL fillestar prej 60 sekondash, por për domenet akamai.net TTL maksimale është 20 sekonda dhe asnjëra prej tyre nuk është në fazë.
Po në lidhje me domenet që anketojnë 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
I njëjti problem si Firefox dhe TTL do të ngecen në 1 sekondë shumicën e kohës kur përdorni zgjidhjen Level3.
Dropbox?
$ stërvitje client.dropbox.com @8.8.8.8 client.dropbox.com. 7 NË CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ stërvitje klient.dropbox.com @4.2.2.2 client.dropbox.com. 1 NË CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Në regjistrim safebrowsing.googleapis.com Vlera TTL është 60 sekonda, si domenet e Facebook. Dhe, përsëri, nga këndvështrimi i klientit, këto vlera janë përgjysmuar.
Po për vendosjen e një TTL minimale?
Duke përdorur emrin, llojin e kërkesës, TTL-në dhe vulën kohore të ruajtur fillimisht, shkrova një skript për të simuluar 1,5 milionë kërkesa që kalojnë përmes një zgjidhësi të memories për të vlerësuar vëllimin e kërkesave shtesë të dërguara për shkak të një hyrjeje të skaduar në cache.
47,4% e kërkesave janë bërë pasi një regjistrim ekzistues kishte skaduar. Kjo është në mënyrë të paarsyeshme e lartë.
Cili do të jetë ndikimi në caching nëse vendoset minimumi TTL?
Boshti X është vlera minimale TTL. Regjistrimet me TTL burimore mbi këtë vlerë nuk preken.
Boshti Y është përqindja e kërkesave nga një klient që tashmë ka një hyrje të memories, por që ka skaduar dhe po bën një kërkesë të re.
Pjesa e kërkesave “ekstra” zvogëlohet nga 47% në 36% thjesht duke vendosur TTL minimale në 5 minuta. Duke vendosur TTL minimale në 15 minuta, numri i këtyre kërkesave zbret në 29%. Një TTL minimale prej 1 ore i zvogëlon ato në 17%. Dallim domethënës!
Po sikur të mos ndryshoni asgjë në anën e serverit, por në vend të kësaj të vendosni TTL-në minimale në memoriet e klientit DNS (ruterat, zgjidhësit lokalë)?
Numri i kërkesave të kërkuara bie nga 47% në 34% me një minimum TTL prej 5 minutash, në 25% me një minimum prej 15 minutash dhe në 13% me një minimum prej 1 orë. Ndoshta 40 minuta është optimale.
Ndikimi i këtij ndryshimi të vogël është i madh.
Cilat janë pasojat?
Sigurisht, shërbimi mund të zhvendoset në një ofrues të ri cloud, server të ri, rrjet të ri, duke kërkuar që klientët të përdorin të dhënat më të fundit DNS. Dhe një TTL mjaft e vogël ndihmon për të bërë një tranzicion të tillë pa probleme dhe në mënyrë të padukshme. Por me kalimin në infrastrukturën e re, askush nuk pret që klientët të migrojnë në të dhënat e reja DNS brenda 1 minutë, 5 minuta ose 15 minuta. Vendosja e minimumit të TTL në 40 minuta në vend të 5 minutave nuk do t'i pengojë përdoruesit të hyjnë në shërbim.
Megjithatë, kjo do të reduktojë ndjeshëm vonesën dhe do të përmirësojë privatësinë dhe besueshmërinë duke shmangur kërkesat e panevojshme.
Sigurisht, RFC-të thonë se TTL duhet të ndiqet rreptësisht. Por realiteti është se sistemi DNS është bërë shumë joefikas.
Nëse jeni duke punuar me serverë autoritativë DNS, ju lutemi kontrolloni TTL-të tuaja. A keni vërtet nevojë për vlera kaq qesharake të ulëta?
Sigurisht, ka arsye të mira për të vendosur TTL të vogla për regjistrimet DNS. Por jo për 75% të trafikut DNS që mbetet praktikisht i pandryshuar.
Dhe nëse për ndonjë arsye ju duhet vërtet të përdorni TTL të ulëta për DNS, në të njëjtën kohë sigurohuni që faqja juaj të mos ketë të aktivizuar caching. Për të njëjtat arsye.
Nëse keni një memorie lokale DNS që funksionon, si p.sh që ju lejon të vendosni TTL minimale, përdorni këtë funksion. Kjo është mirë. Asgjë e keqe nuk do të ndodhë. Vendosni TTL minimale në afërsisht 40 minuta (2400 sekonda) dhe 1 orë. Gama mjaft e arsyeshme.
Burimi: www.habr.com