DNS-ի ցածր լատենտությունը արագ զննարկման հիմնական գործոն է: Այն նվազագույնի հասցնելու համար կարևոր է ուշադիր ընտրել DNS սերվերները և Բայց առաջին բանը, որ դուք պետք է անեք, անօգուտ հարցումներից ազատվելն է։
Ահա թե ինչու DNS-ը սկզբնապես նախագծվել է որպես քեշավորման բարձր մակարդակ ունեցող արձանագրություն: Գոտիների ադմինիստրատորները սահմանում են առանձին գրառումների համար կյանքի տևողություն (TTL), իսկ լուծիչները օգտագործում են այս տեղեկատվությունը՝ գրառումները հիշողության մեջ պահելիս՝ ավելորդ երթևեկությունից խուսափելու համար:
Քեշավորումը արդյունավե՞տ է։ Մի քանի տարի առաջ իմ փոքրիկ հետազոտությունը ցույց տվեց, որ այն կատարյալ չէ։ Եկեք նայենք ներկայիս իրավիճակին։
Իմ կողմից թարմացված տեղեկատվությունը հավաքելու համար պահպանել պատասխանի TTL արժեքը։ Այն սահմանվում է որպես իր գրառումների նվազագույն TTL՝ յուրաքանչյուր մուտքային հարցման համար։ Սա լավ պատկերացում է տալիս իրական երթևեկության TTL բաշխման մասին, ինչպես նաև հաշվի է առնում առանձին հարցումների ժողովրդականությունը։ Սերվերի թարմացված տարբերակը աշխատեց մի քանի ժամ։
Արդյունքում ստացված տվյալների հավաքածուն բաղկացած է 1 գրառումներից (անուն, qtype, TTL, timestamp): Ահա TTL-ի ընդհանուր բաշխումը (x-առանցքը TTL-ն է վայրկյաններով):
Բացի 86-ի մի փոքր բարձրացումից (հիմնականում SOA գրառումների համար), բավականին ակնհայտ է, որ TTL-ները ցածր միջակայքում են։ Եկեք ավելի մանրամասն նայենք։
Լավ, 1 ժամից ավելի տևողությամբ TTL-ները վիճակագրորեն աննշան են։ Ապա եկեք կենտրոնանանք 0-3600 միջակայքի վրա՝
TTL-ների մեծ մասը 0-ից 15 րոպեի սահմաններում է։
Մեծամասնությունը 0-ից մինչև 5 րոպե է։
Սա շատ լավ չէ։
Կուտակային բաշխումը խնդիրն ավելի ակնհայտ է դարձնում.
DNS պատասխանների կեսն ունի 1 րոպե կամ պակաս TTL, իսկ երեք քառորդը՝ 5 րոպե կամ պակաս։
Բայց սպասեք, իրականում ավելի վատ է։ Սա հեղինակավոր սերվերներից ստացված TTL-ն է։ Սակայն, հաճախորդ-լուծիչները (օրինակ՝ ռաութերները, տեղական քեշերը) TTL-ը ստանում են վերևում գտնվող լուծիչներից, և այն նվազում է ամեն վայրկյան։
Այսպիսով, հաճախորդը կարող է իրականում օգտագործել յուրաքանչյուր գրառում, միջինում, սկզբնական TTL-ի կեսի համար՝ նախքան նոր հարցում ուղարկելը։
Գուցե այս շատ ցածր TTL-ները ազդում են միայն անսովոր հարցումների վրա, և ոչ թե հայտնի կայքերի և API-ների վրա։ Եկեք նայենք.
X առանցքը TTL-ն է, Y առանցքը՝ հարցման ժողովրդականությունը։
Դժբախտաբար, ամենատարածված հարցումները նաև ամենավատ քեշավորվածն են։
Եկեք մեծացնենք։
Դատավճիռ. Այն իսկապես վատ է։ Այն արդեն վատ էր, և ավելի է վատացել։ DNS քեշավորումը դարձել է գործնականում անօգուտ։ Քանի որ ավելի քիչ մարդիկ են օգտագործում իրենց ինտերնետ մատակարարի DNS լուծիչը (լավ պատճառներով), լատենտության աճը դառնում է ավելի նկատելի։
DNS քեշավորումը օգտակար է դարձել միայն այն բովանդակության համար, որը ոչ ոք չի այցելում։
Խնդրում ենք նաև նկատի ունենալ, որ ծրագիրը կարող է մեկնաբանել ցածր TTL-ները։
Ինչու:
Ինչո՞ւ են DNS գրառումները սահմանված այդքան փոքր TTL-ի վրա։
- Հին բեռնվածության հավասարակշռիչները մնում են լռելյայն կարգավորումներով։
- Կան միֆեր, որ DNS բեռի հավասարակշռումը կախված է TTL-ից (սա ճիշտ չէ. Netscape Navigator-ից ի վեր հաճախորդները RR հավաքածուից ընտրում են պատահական IP հասցե և, եթե չեն կարողանում միանալ, փորձում են մեկ այլ հասցե):
- Ադմինիստրատորները ցանկանում են անմիջապես կիրառել փոփոխությունները, ուստի ավելի հեշտ է պլանավորել։
- DNS սերվերի կամ բեռի հավասարակշռիչի ադմինիստրատորը իր խնդիրը համարում է օգտատերերի կողմից պահանջվող կոնֆիգուրացիայի արդյունավետ տեղակայումը, այլ ոչ թե կայքերի և ծառայությունների աշխատանքի արագացումը։
- Ցածր TTL-ը հանգստություն է տալիս։
- Մարդիկ սկզբում ցածր TTL-ներ են սահմանում թեստավորման համար, ապա մոռանում են դրանք փոխել։
Ես չներառեցի «failover»-ը, քանի որ այն գնալով պակաս արդիական է դառնում։ Եթե անհրաժեշտ է օգտատերերին վերահասցեագրել մեկ այլ ցանց՝ սխալի էջ ցուցադրելու համար, երբ ամեն ինչ խափանված է, 1 րոպեից ավելի ուշացումը հավանաբար ընդունելի է։
Բացի այդ, մեկ րոպեանոց TTL-ը նշանակում է, որ եթե հեղինակավոր DNS սերվերները արգելափակվեն ավելի քան 1 րոպե, ոչ ոք չի կարողանա մուտք գործել կախյալ ծառայություններ: Եվ ավելորդությունը չի օգնի, եթե պատճառը կարգավորման սխալն է կամ կոտրումը: Մյուս կողմից, ողջամիտ TTL-ների դեպքում շատ հաճախորդներ կշարունակեն օգտագործել նախորդ կարգավորումը և երբեք չեն նկատի:
Ցածր TTL-ները մեծ մասամբ CDN ծառայությունների և բեռի հավասարակշռիչների մեղքն են, հատկապես, երբ դրանք համատեղում են 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 գրառման ժամկետը լրանում է, պետք է ուղարկվի նոր հարցում։ Երկուսն էլ ունեն 30 վայրկյան տևողությամբ TTL, բայց դրանք նույնը չեն։ Իրական միջին TTL-ը կկազմի 15 վայրկյան։
Բայց սպասեք։ Ավելի վատ է դառնում։ Որոշ լուծիչներ շատ վատ են վարվում այս իրավիճակում՝ երկու կապված ցածր TTL-ների դեպքում։
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME-ում github.map.fastly.net. github.map.fastly.net. 1 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-ները ունեն 60 վայրկյան սկզբնական TTL, բայց դոմեյնների համար։ akamai.net Առավելագույն TTL-ը 20 վայրկյան է, և դրանցից ոչ մեկը փուլային չէ։
Իսկ ի՞նչ կասեք այն դոմեյնների մասին, որոնք անընդհատ հարցումներ են անում 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
Նույն խնդիրն է, ինչ Firefox-ը և TTL-ը, որոնք Level1 լուծիչն օգտագործելիս մեծ մասամբ կպչում են 3 վայրկյանում։
Dropbox-ը՞
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME Մուտք client.dropbox-dns.com. client.dropbox-dns.com. 59 Մուտք A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 Մուտք CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 Մուտք A 162.125.64.3
Ձայնագրության ժամանակ safebrowsing.googleapis.com TTL արժեքը 60 վայրկյան է, ինչպես Facebook-ի դոմեյնների դեպքում։ Եվ կրկին, հաճախորդի տեսանկյունից, այս արժեքները կիսով չափ կրճատվում են։
Ինչպե՞ս կլինի սահմանել նվազագույն TTL:
Օգտագործելով անունը, հարցման տեսակը, TTL-ը և սկզբնապես պահպանված ժամանակային դրոշմանիշը, ես գրեցի սկրիպտ՝ քեշավորման լուծիչի միջոցով 1,5 միլիոն հարցումներ մոդելավորելու համար՝ ժամկետանց քեշի գրառման պատճառով ուղարկված լրացուցիչ հարցումների քանակը գնահատելու համար։
Հարցումների 47,4%-ը կատարվել է առկա գրանցամատյանի ժամկետի ավարտից հետո։ Սա անհիմն բարձր ցուցանիշ է։
Ի՞նչ ազդեցություն կունենա քեշավորման վրա, եթե սահմանվի նվազագույն TTL:
X-առանցքը TTL-ի նվազագույն արժեքներն են։ Այս արժեքից բարձր հում TTL-ներով գրառումները չեն ազդվում։
Y առանցքը այն հաճախորդի հարցումների տոկոսն է, որն արդեն ունի քեշավորված գրառում, բայց դրա ժամկետը լրացել է և կատարում է նոր հարցում։
«Լրացուցիչ» հարցումների բաժինը 47%-ից կրճատվում է մինչև 36%՝ պարզապես նվազագույն TTL-ը 5 րոպե սահմանելով։ Նվազագույն TTL-ը 15 րոպե սահմանելով՝ այս հարցումների քանակը կրճատվում է մինչև 29%։ 1 ժամ նվազագույն TTL-ը կրճատվում է մինչև 17%։ Սա էական տարբերություն է։
Ինչպե՞ս կլինի, եթե սերվերի կողմից ոչինչ չփոխենք, այլ փոխարենը հաճախորդի DNS քեշերում (ռաութերներ, տեղական լուծիչներ) սահմանենք նվազագույն TTL-ներ։
Պահանջվող հարցումների քանակը 47%-ից նվազում է մինչև 34%, երբ TTL-ը սահմանվում է 5 րոպե, մինչև 25%՝ առնվազն 15 րոպեի դեպքում, և մինչև 13%՝ առնվազն 1 ժամի դեպքում։ Հնարավոր է՝ 40 րոպեն լինի օպտիմալը։
Այս նվազագույն փոփոխության ազդեցությունը հսկայական է։
Որո՞նք են դրա հետևանքները:
Անշուշտ, դուք կարող եք ծառայությունը տեղափոխել նոր ամպային մատակարարի, նոր սերվերի, նոր ցանցի և պահանջել, որ հաճախորդները օգտագործեն ամենաթարմ DNS գրառումները: Եվ բավականաչափ փոքր TTL-ը նպաստում է այդ անցմանը սահուն և անխափան: Սակայն, երբ դուք տեղափոխվում եք նոր ենթակառուցվածքի, ոչ ոք չի սպասում, որ հաճախորդները կտեղափոխվեն նոր DNS գրառումների 1 րոպեի, 5 րոպեի կամ 15 րոպեի ընթացքում: Նվազագույն TTL-ը 40 րոպեի փոխարեն 5 րոպե սահմանելը չի խանգարի օգտատերերին մուտք գործել ծառայությանը:
Այնուամենայնիվ, սա զգալիորեն կնվազեցնի լատենտությունը և կբարելավի գաղտնիությունն ու հուսալիությունը՝ խուսափելով ավելորդ հարցումներից։
Անշուշտ, RFC-ները նշում են, որ TTL-ները պետք է խստորեն կիրառվեն։ Սակայն իրականությունն այն է, որ DNS համակարգը չափազանց անարդյունավետ է դարձել։
Եթե աշխատում եք հեղինակավոր DNS սերվերների հետ, խնդրում ենք ստուգել ձեր TTL-ները: Իսկապե՞ս անհրաժեշտ են նման ծիծաղելիորեն ցածր արժեքներ:
Իհարկե, կան լավ պատճառներ DNS գրառումների համար փոքր TTL սահմանելու համար։ Բայց ոչ DNS տրաֆիկի 75%-ի համար, որը գրեթե չի փոխվում։
Եվ եթե ինչ-ինչ պատճառներով իսկապես անհրաժեշտ է օգտագործել ցածր TTL-ներ DNS-ի համար, համոզվեք նաև, որ ձեր կայքում քեշավորումը միացված չէ։ Նույն պատճառներով։
Եթե ունեք տեղական DNS քեշ, օրինակ՝ , որը թույլ է տալիս սահմանել նվազագույն TTL-ը, օգտագործեք այս գործառույթը: Սա նորմալ է: Ոչ մի վատ բան չի պատահի: Սահմանեք նվազագույն TTL-ը 40 րոպեից (2400 վայրկյան) մինչև 1 ժամ միջակայքում: Բավարար միջակայք:
Source: www.habr.com
