Нізкая затрымка DNS - ключавы фактар для хуткай працы ў інтэрнэце. Каб яе мінімізаваць, важна старанна падабраць DNS-серверы і . Але перш за ўсё варта пазбавіцца ад бескарысных запытаў.
Менавіта таму DNS першапачаткова ствараўся як моцна які кэшуецца пратакол. Адміністратары зон усталёўваюць час жыцця (TTL) для асобных запісаў, а рэзаверы выкарыстоўваюць гэтую інфармацыю пры захоўванні запісаў у памяці, каб пазбегнуць непатрэбнага трафіку.
Ці эфектыўна кэшаванне? Пару гадоў таму маё невялікае даследаванне паказала, што яно не ідэальна. Зірнем на цяперашні стан спраў.
Для збору інфармацыі я прапатчыў для захавання значэння TTL для адказу. Яно вызначаецца як мінімальнае TTL яго запісаў, для кожнага ўваходнага запыту. Гэта дае добры агляд размеркавання TTL рэальнага трафіку, а таксама улічвае папулярнасць асобных запытаў. Прапатчаная версія сервера працавала некалькі гадзін.
Выніковы набор дадзеных складаецца з 1 запісаў (name, qtype, TTL, timestamp). Вось агульнае размеркаванне TTL (вось X - гэта TTL у секундах):
Калі не лічыць малаважнага бугра на 86 (у асноўным, для запісаў SOA), даволі відавочна, што TTL знаходзяцца ў нізкім дыяпазоне. Паглядзім бліжэй:
Добра, TTL больш за 1 гадзіну статыстычна не значныя. Тады засяродзімся на дыяпазоне 0-3600:
Большасць TTL ад 0 да 15 хвілін:
Пераважная большасць ад 0 да 5 хвілін:
Гэта ня вельмі добра.
Назапашвальнае размеркаванне робіць праблему яшчэ больш відавочнай:
У палове DNS-адказаў TTL складае 1 хвіліну ці менш, а ў трох чвэрцяў – 5 хвілін ці менш.
Але пачакайце, насамрэч усё яшчэ горш. Бо гэта TTL ад аўтарытатыўных сэрвераў. Аднак кліенцкія рэзаверы (напрыклад, маршрутызатары, лакальныя кэшы) атрымліваюць TTL ад вышэйстаячых рэзавераў, і ён памяншаецца кожную секунду.
Такім чынам, кліент фактычна можа выкарыстоўваць кожны запіс, у сярэднім, на працягу паловы зыходнага TTL, пасля чаго адправіць новы запыт.
Можа, гэтыя вельмі нізкія TTL датычацца толькі незвычайных запытаў, а не папулярных вэб-сайтаў і API? Давайце паглядзім:
Вось X – гэта TTL, вось Y – папулярнасць запытаў.
Нажаль, самыя папулярныя запыты таксама і горш за ўсё кэшуюцца.
Наблізім:
Вердыкт: усё сапраўды дрэнна. Ужо і раней было кепска, а стала яшчэ горш. Кэшаванне DNS стала практычна бескарысным. Паколькі ўсё менш людзей выкарыстоўваюць DNS-рэзалвер свайго правайдэра (па ўважлівых прычынах), павелічэнне затрымкі становіцца больш прыкметнай.
Кэшаванне DNS стала карысным толькі для кантэнту, які ніхто не наведвае.
Таксама звярніце ўвагу, што праграмнае забеспячэнне можа інтэрпрэтаваць нізкія TTL.
Чаму так?
Чаму для запісаў DNS усталёўваецца такі малы TTL?
- Састарэлыя балансавальнікі нагрузкі засталіся з наладамі па змаўчанні.
- Ходзяць міфы, што балансаванне нагрузкі па DNS залежыць ад TTL (гэта не так – з часоў Netscape Navigator кліенты выбіраюць выпадковы IP-адрас з набору RR і празрыста спрабуюць іншы, калі не могуць падлучыцца)
- Адміністратары жадаюць ужыць змены неадкладна, таму так прасцей планаваць.
- Адміністратар DNS-сервера ці балансавальніка нагрузкі бачыць сваёй задачай эфектыўна разгортваць канфігурацыю, якую запытваюць карыстачы, а не паскараць працу сайтаў і сэрвісаў.
- Нізкія TTL даюць душэўны спакой.
- Людзі першапачаткова ставяць нізкія TTL для тэсціравання і забываюць потым іх змяніць.
Я не ўключыў у спіс "адпрацоўку адмовы", паколькі гэта ўсё менш актуальна. Калі трэба перанакіраваць карыстальнікаў у іншую сетку толькі для адлюстравання старонкі з памылкай, калі абсалютна ўсё астатняе зламалася, напэўна, дапушчальная затрымка больш за 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 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN 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 першапачатковы 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 секундзе пры выкарыстанні рэзалвера 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
У запісы safebrowsing.googleapis.com значэнне TTL 60 секунд, як і ў даменаў Facebook. І, зноў жа, з пункту гледжання кліента, гэтыя значэнні памяншаюцца ўдвая.
Як наконт усталёўкі мінімальнага TTL?
Выкарыстоўваючы імя, тып запыту, TTL і першапачаткова захаваную часовую пазнаку, я напісаў скрыпт для імітацыі 1,5 мільёна запытаў, якія праходзяць праз які кэшуе рэзавер, каб ацаніць аб'ём лішніх запытаў, адпраўленых з-за пратэрмінаванага запісу кэша.
47,4% запытаў былі зроблены пасля заканчэння тэрміну дзеяння існуючага запісу. Гэта неапраўдана высока.
Які будзе ўплыў на кэшаванне, калі ўсталяваны мінімальны TTL?
Вось X - гэта мінімальныя значэння TTL. Запісы з зыходнымі TTL вышэй гэтага значэння не закрануты.
Вось Y - працэнт запытаў ад кліента, у якога ўжо ёсць кэшаваны запіс, але яе тэрмін дзеяння скончыўся і ён робіць новы запыт.
Доля "лішніх" запытаў зніжаецца з 47% да 36% простай устаноўкай мінімальнага TTL у 5 хвілін. Пры ўстаноўцы мінімальнага TTL у 15 хвілін колькасць гэтых запытаў зніжаецца да 29%. Мінімальны TTL у 1 гадзіну зніжае іх да 17%. Істотная розніца!
Як наконт таго, каб нічога не мяняць на баку сервера, а замест гэтага ўсталяваць мінімальныя TTL у кліенцкіх DNS-кэшах (маршрутызатары, лакальныя рэзаверы)?
Колькасць патрабаваных запытаў зніжаецца з 47% да 34% пры ўстаноўцы мінімальнага TTL у 5 хвілін, да 25% з мінімумам у 15 хвілін і да 13% з мінімумам у 1 гадзіну. Магчыма, аптымальнае значэнне 40 хвілін.
Уплыў гэтай мінімальнай змены велізарны.
Якія наступствы?
Вядома, сэрвіс можна перавесці на новага хмарнага правайдэра, новы сервер, новую сетку, патрабуючы ад кліентаў выкарыстоўваць апошнія запісы DNS. І досыць малы TTL дапамагае плыўна і неўзаметку ажыццявіць такі пераход. Але з пераходам на новую інфраструктуру ніхто не чакае, што кліенты пяройдуць на новыя запісы DNS на працягу 1 хвіліны, 5 хвілін ці 15 хвілін. Устаноўка мінімальнага тэрміну жыцця ў 40 хвілін замест 5 хвілін не перашкодзіць карыстальнікам атрымаць доступ да сэрвісу.
Аднак гэта дазволіць значна скараціць затрымку і павысіць канфідэнцыйнасць і надзейнасць, пазбягаючы непатрэбных запытаў.
Вядома, RFC кажуць, што трэба строга выконваць TTL. Але рэальнасць такая, што сістэма DNS стала занадта неэфектыўнай.
Калі вы працуеце з аўтарытатыўнымі DNS-серверамі, калі ласка, праверце свае TTL. Вам сапраўды патрэбныя такія смяхотна нізкія значэнні?
Вядома, ёсць важкія прычыны ўстаноўкі малых TTL для DNS-запісаў. Але не для 75% трафіку DNS, які практычна не мяняецца.
І калі па нейкіх прычынах вам сапраўды трэба выкарыстоўваць нізкія TTL для DNS, заадно пераканайцеся, што на вашым сайце не ўключана кэшаванне. Па тых жа прычынах.
Калі ў вас працуе лакальны DNS-кэш, такі як , Які дазваляе ўсталёўваць мінімальныя TTL, выкарыстоўвайце гэтую функцыю. Гэта нармальна. Нічога дрэннага не здарыцца. Усталюйце мінімальны TTL прыкладна паміж 40 хвілінамі (2400 секунд) і 1 гадзінай. Цалкам разумны дыяпазон.
Крыніца: habr.com