Төмөн DNS кечигүү ылдам интернет серептөө үчүн ачкычы болуп саналат. Аны азайтуу үчүн, кылдаттык менен DNS серверлерин тандоо маанилүү жана . Бирок биринчи кадам пайдасыз суроолордон арылуу.
Ошондуктан DNS алгач кэштелуучу протокол катары иштелип чыккан. Аймактын администраторлору жеке жазуулар үчүн жашоо убактысын (TTL) белгилешет жана чечүүчүлөр бул маалыматты керексиз трафикти болтурбоо үчүн жазууларды эстутумда сактоодо колдонушат.
Кэштөө натыйжалуубу? Бир нече жыл мурун, менин кичинекей изилдөөм ал идеалдуу эмес экенин көрсөттү. Иштин азыркы абалына көз чаптыралы.
Маалыматты чогултуу үчүн мен түзмөгүн түздүм жооп үчүн TTL маанисин сактоо үчүн. Ал ар бир келген суроо-талап үчүн анын жазууларынын минималдуу TTL катары аныкталат. Бул реалдуу трафиктин TTL бөлүштүрүлүшүнө жакшы сереп салып берет, ошондой эле жеке суроо-талаптардын популярдуулугун эске алат. Сервердин жаңыланган версиясы бир нече саат бою иштеди.
Жыйынтыгында маалымат топтому 1 583 579 жазуудан турат (аты, qtype, TTL, убакыт белгиси). Бул жерде жалпы TTL бөлүштүрүү (X огу секундада TTL болуп саналат):
86 (көбүнчө SOA жазуулары үчүн) кичинекей соккусунан тышкары, TTLлер төмөнкү диапазондо экени айкын. Келгиле, кененирээк карап көрөлү:
Макул, 1 сааттан ашкан TTLлер статистикалык мааниге ээ эмес. Анда 0−3600 диапазонуна көңүл буралы:
Көпчүлүк TTLлер 0дөн 15 мүнөткө чейин:
Басымдуу көпчүлүгү 0дөн 5 мүнөткө чейин:
Бул абдан жакшы эмес.
Кумулятивдүү бөлүштүрүү көйгөйдү ого бетер айкын кылат:
DNS жоопторунун жарымында TTL 1 мүнөт же андан аз, ал эми төрттөн үч бөлүгүндө 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 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 сыяктуу эле көйгөй 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 IN 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 IN A 162.125.64.3
Жазууда safebrowsing.googleapis.com TTL мааниси Facebook домендери сыяктуу 60 секунд. Жана дагы, кардардын көз карашы боюнча, бул баалуулуктар эки эсеге кыскарган.
Минималдуу 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 мүнөт оптималдуу болуп саналат.
Бул кичинекей өзгөрүүнүн таасири абдан чоң.
Мунун кесепети кандай?
Албетте, кызмат кардарлардан акыркы DNS жазууларын колдонууну талап кылган жаңы булут провайдерине, жаңы серверге, жаңы тармакка жылдырылышы мүмкүн. Ал эми бир кыйла кичинекей TTL мындай өтүүнү жылмакай жана байкалбаган кылууга жардам берет. Бирок жаңы инфраструктурага өтүү менен эч ким кардарлардын жаңы DNS жазууларына 1 мүнөт, 5 мүнөт же 15 мүнөт ичинде өтүшүн күтпөйт. Минималдуу TTL 40 мүнөттүн ордуна 5 мүнөткө коюу колдонуучулардын кызматка кирүүсүнө тоскоол болбойт.
Бирок, бул күтүү убактысын кыйла азайтат жана ашыкча суроо-талаптардан качуу менен купуялуулукту жана ишенимдүүлүктү жакшыртат.
Албетте, РФКлар TTL катуу сакталышы керек деп айтышат. Бирок чындык DNS системасы өтө натыйжасыз болуп калды.
Эгерде сиз авторитеттүү DNS серверлери менен иштеп жатсаңыз, TTLлериңизди текшериңиз. Сизге чындап эле ушундай күлкүлүү төмөн баалуулуктар керекпи?
Албетте, DNS жазуулары үчүн кичинекей TTL коюуга жакшы себептер бар. Бирок дээрлик өзгөрүүсүз калган DNS трафиктин 75% үчүн эмес.
Жана кандайдыр бир себептерден улам сиз DNS үчүн чындап эле төмөн TTLлерди колдонушуңуз керек болсо, ошол эле учурда сиздин сайтыңызда кэш иштетилген эмес экенин текшериңиз. Ошол эле себептерден улам.
Эгер сизде жергиликтүү DNS кэш бар болсо, мисалы минималдуу TTLs коюуга мүмкүндүк берет, бул функцияны колдонуңуз. Бул Жакшы. Эч кандай жаман нерсе болбойт. Минималдуу TTLди болжол менен 40 мүнөткө (2400 секунд) жана 1 саатка коюңуз. Абдан акылга сыярлык диапазон.
Source: www.habr.com