Төмен DNS кідірісі интернетті жылдам шолудың кілті болып табылады. Оны азайту үшін DNS серверлерін мұқият таңдау маңызды және . Бірақ бірінші қадам - пайдасыз сұраулардан арылу.
Сондықтан DNS бастапқыда жоғары кэштелген протокол ретінде жасалған. Аймақ әкімшілері жеке жазбалар үшін өмір сүру уақытын (TTL) орнатады және шешушілер қажетсіз трафикті болдырмау үшін жазбаларды жадта сақтау кезінде осы ақпаратты пайдаланады.
Кэштеу тиімді ме? Бірнеше жыл бұрын менің шағын зерттеулерім оның мінсіз емес екенін көрсетті. Қазіргі жағдайға көз жүгіртейік.
Ақпаратты жинау үшін мен патч жасадым жауап үшін TTL мәнін сақтау үшін. Ол әрбір кіріс сұрау үшін жазбаларының ең аз TTL ретінде анықталады. Бұл нақты трафиктің TTL таралуына жақсы шолу жасайды, сонымен қатар жеке сұраулардың танымалдылығын ескереді. Сервердің патчталған нұсқасы бірнеше сағат бойы жұмыс істеді.
Алынған деректер жинағы 1 583 579 жазбадан тұрады (аты, qтипі, TTL, уақыт белгісі). Мұнда жалпы TTL үлестірімі берілген (X осі секундтарда TTL):
86-дегі шамалы соққыдан басқа (негізінен SOA жазбалары үшін), TTLs төмен диапазонда екені анық. Толығырақ қарастырайық:
Жарайды, 1 сағаттан асатын TTL статистикалық маңызды емес. Содан кейін 0−3600 диапазонына назар аударайық:
Көптеген TTL 0-ден 15 минутқа дейін:
Басым көпшілігі 0-ден 5 минутқа дейін:
Бұл өте жақсы емес.
Жиынтық бөлу мәселені одан да айқын етеді:
DNS жауаптарының жартысында 1 минут немесе одан аз TTL, ал төрттен үшінде 5 минут немесе одан аз TTL болады.
Бірақ күте тұрыңыз, бұл шынымен де нашар. Өйткені, бұл беделді серверлерден алынған TTL. Дегенмен, клиенттік шешушілер (мысалы, маршрутизаторлар, жергілікті кэштер) жоғары ағындық шешушілерден TTL алады және ол секунд сайын азаяды.
Осылайша, клиент жаңа сұрау жібермес бұрын әрбір жазбаны орташа есеппен бастапқы TTL жартысы үшін пайдалана алады.
Мүмкін бұл өте төмен TTL мәндері танымал веб-сайттар мен API емес, әдеттен тыс сұрауларға ғана қатысты болуы мүмкін бе? Қарап көрейік:
X осі - TTL, Y осі - сұраныстардың танымалдығы.
Өкінішке орай, ең танымал сұраулар да кэштеуге ең нашар.
Үлкейтейік:
Үкім: бұл өте жаман. Бұрын нашар болды, бірақ одан да нашарлады. DNS кэштеу іс жүзінде пайдасыз болды. Аз адамдар өздерінің ISP DNS шешушісін пайдаланатындықтан (жақсы себептермен), кідірістің артуы байқалады.
DNS кэштеу тек ешкім кірмейтін мазмұн үшін пайдалы болды.
Сондай-ақ бағдарламалық қамтамасыз ету мүмкін екенін ескеріңіз төмен TTL мәндерін түсіндіру.
Неге бұлай?
Неліктен DNS жазбалары соншалықты төмен TTL мәніне орнатылған?
- Бұрынғы жүктеме теңгергіштері әдепкі параметрлермен қалды.
- DNS жүктемесін теңестіру TTL-ге байланысты деген мифтер бар (бұл дұрыс емес - Netscape Navigator күндерінен бері клиенттер RR жиынтығынан кездейсоқ IP мекенжайын таңдады және қосыла алмаса, басқасын ашық түрде қолданып көрді)
- Әкімшілер өзгертулерді дереу қолданғысы келеді, сондықтан жоспарлау оңайырақ.
- DNS серверінің немесе жүктеме балансының әкімшісі өз міндетін сайттар мен қызметтерді жылдамдатпай, пайдаланушылар сұрайтын конфигурацияны тиімді қолдану деп санайды.
- Төмен TTL сізге жан тыныштығын береді.
- Адамдар тестілеу үшін бастапқыда төмен TTL мәндерін орнатады, содан кейін оларды өзгертуді ұмытады.
Тізімге «ауыспалы» дегенді қоспадым, себебі ол азырақ өзекті болып келеді. Қалғанының бәрі бұзылған кезде қате бетін көрсету үшін пайдаланушыларды басқа желіге қайта бағыттау қажет болса, 1 минуттан астам кідіріс қолайлы болуы мүмкін.
Оған қоса, бір минуттық TTL беделді DNS серверлері 1 минуттан астам уақытқа бұғатталған болса, басқа ешкім тәуелді қызметтерге қол жеткізе алмайтынын білдіреді. Егер себеп конфигурация қатесі немесе бұзу болса, артықшылық көмектеспейді. Екінші жағынан, ақылға қонымды TTL арқылы көптеген клиенттер бұрынғы конфигурацияны пайдалануды жалғастырады және ешқашан ештеңе байқамайды.
CDN қызметтері мен жүктемені теңестірушілер төмен TTL үшін негізінен кінәлі, әсіресе олар 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 IN github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
3-деңгей шешушісі 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 бар, бірақ ол мүлдем пайдасыз. Басқа CNAMEs бастапқы TTL 60 секундқа ие, бірақ домендер үшін 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 сияқты мәселе 1-деңгейді шешу құралын пайдаланған кезде көп жағдайда 3 секундта тұрып қалады.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com IN. 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 IN. client.dropbox-dns.com. 1 IN A 162.125.64.3
Жазбада safebrowsing.googleapis.com TTL мәні - Facebook домендері сияқты 60 секунд. Және тағы да, клиенттің көзқарасы бойынша, бұл құндылықтар екі есе азаяды.
Ең төменгі TTL орнату туралы не айтасыз?
Атты, сұрау түрін, TTL және бастапқы сақталған уақыт белгісін пайдаланып, мерзімі өтіп кеткен кэш жазбасына байланысты жіберілген қажетсіз сұраулардың көлемін бағалау үшін кэштеу құралы арқылы өтетін 1,5 миллион сұрауды имитациялау үшін сценарий жаздым.
Сұраныстардың 47,4%-ы бұрыннан бар жазбаның мерзімі өткеннен кейін жасалған. Бұл негізсіз жоғары.
Ең аз TTL орнатылған болса, кэштеуге қандай әсер етеді?
X осі ең аз TTL мәндері болып табылады. Бұл мәннен жоғары бастапқы TTL бар жазбаларға әсер етпейді.
Y осі - кэштелген жазбасы бұрыннан бар, бірақ оның мерзімі өтіп кеткен және жаңа сұрау жасап жатқан клиенттің сұрауларының пайызы.
Ең аз TTL 47 минутқа орнату арқылы «қосымша» сұраулардың үлесі 36%-дан 5%-ға дейін төмендейді. Ең аз TTL 15 минутқа орнату арқылы бұл сұраулардың саны 29%-ға дейін төмендейді. Ең аз 1 сағаттық TTL оларды 17%-ға дейін азайтады. Айтарлықтай айырмашылық!
Сервер жағында ештеңені өзгертпей, оның орнына клиенттің DNS кэштерінде (маршрутизаторлар, жергілікті шешушілер) ең аз TTL мәнін орнату туралы не айтасыз?
Қажетті сұраулар саны ең аз TTL 47 минутпен 34%-дан 5%-ға, ең азы 25 минутпен 15%-ға және кемінде 13 сағатпен 1%-ға дейін төмендейді. Мүмкін 40 минут оңтайлы.
Бұл шағын өзгерістің әсері орасан зор.
Мұның салдары қандай?
Әрине, қызметті клиенттерден соңғы DNS жазбаларын пайдалануды талап ететін жаңа бұлттық провайдерге, жаңа серверге, жаңа желіге ауыстыруға болады. Ал жеткілікті кішкентай TTL мұндай ауысуды тегіс және сезілмейтін жасауға көмектеседі. Бірақ жаңа инфрақұрылымға көшумен ешкім клиенттердің жаңа DNS жазбаларына 1 минут, 5 минут немесе 15 минут ішінде көшуін күтпейді. Ең аз TTL мәнін 40 минуттың орнына 5 минутқа орнату пайдаланушылардың қызметке кіруіне кедергі болмайды.
Дегенмен, бұл қажетсіз сұрауларды болдырмай, кідірісті айтарлықтай азайтады және құпиялылық пен сенімділікті жақсартады.
Әрине, RFCs TTL қатаң сақталуы керек дейді. Бірақ шындық DNS жүйесі тым тиімсіз болып қалды.
Егер сіз беделді DNS серверлерімен жұмыс істеп жатсаңыз, TTL мекенжайларын тексеріңіз. Сізге шынымен осындай күлкілі төмен құндылықтар керек пе?
Әрине, DNS жазбалары үшін шағын TTL орнатудың жақсы себептері бар. Бірақ іс жүзінде өзгеріссіз қалатын DNS трафикінің 75% үшін емес.
Егер қандай да бір себептермен DNS үшін шынымен төмен TTL пайдалану қажет болса, сонымен бірге сайтыңызда кэштеу қосылмағанына көз жеткізіңіз. Дәл осындай себептермен.
Егер сізде жергілікті DNS кэш жұмыс істеп тұрса, мысалы ең аз TTL мәндерін орнатуға мүмкіндік береді, осы функцияны пайдаланыңыз. Бұл жақсы. Жаман ештеңе болмайды. Ең аз TTL мәнін шамамен 40 минутқа (2400 секунд) және 1 сағатқа орнатыңыз. Өте орынды диапазон.
Ақпарат көзі: www.habr.com