DNS-ийн хоцрогдол бага байх нь интернетийг хурдан үзэх гол түлхүүр юм. Үүнийг багасгахын тулд DNS серверүүдийг анхааралтай сонгох нь чухал юм . Гэхдээ эхний алхам бол хэрэггүй асуултуудаас салах явдал юм.
Ийм учраас DNS нь анхандаа кэш хийх өндөр протокол хэлбэрээр бүтээгдсэн. Бүсийн администраторууд хувь хүний оруулгуудад амьдрах хугацааг (TTL) тогтоодог бөгөөд шийдвэрлэгч нар шаардлагагүй урсгалаас зайлсхийхийн тулд бичилтүүдийг санах ойд хадгалахдаа энэ мэдээллийг ашигладаг.
Кэш нь үр дүнтэй юу? Хэдэн жилийн өмнө миний бяцхан судалгаагаар энэ нь төгс биш гэдгийг харуулсан. Өнөөгийн нөхцөл байдлыг харцгаая.
Мэдээлэл цуглуулахын тулд би засвар хийсэн хариултын TTL утгыг хадгалах. Энэ нь ирж буй хүсэлт бүрийн хамгийн бага TTL гэж тодорхойлогддог. Энэ нь бодит траффикийн TTL хуваарилалтын талаар сайн тоймыг өгөхөөс гадна хувь хүний хүсэлтийн түгээмэл байдлыг харгалзан үздэг. Серверийн засварласан хувилбар хэдэн цагийн турш ажилласан.
Үүссэн өгөгдлийн багц нь 1 бичлэгээс (нэр, qtype, TTL, цагийн тэмдэг) бүрдэнэ. Нийт TTL тархалтыг энд харуулав (X тэнхлэг нь секундэд TTL байна):
86 (ихэвчлэн SOA бүртгэлд зориулагдсан) бага зэрэг овойлтыг эс тооцвол TTL нь бага хязгаарт байгаа нь тодорхой байна. Илүү дэлгэрэнгүй харцгаая:
За, 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-ийг тогтоож, дараа нь өөрчлөхөө мартдаг.
"Filover"-ыг жагсаалтад оруулаагүй, учир нь энэ нь улам бүр багасаж байна. Хэрэв та бусад бүх зүйл эвдэрсэн үед алдааны хуудсыг харуулахын тулд хэрэглэгчдийг өөр сүлжээнд дахин чиглүүлэх шаардлагатай бол 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 эсвэл аль нэг А бичлэгийн хугацаа дуусах бүрд шинэ хүсэлт илгээх ёстой. Аль аль нь 30 секундын TTL-тэй боловч энэ нь ижил биш юм. Бодит дундаж TTL нь 15 секунд байх болно.
Гэхдээ хүлээ! Энэ нь бүр ч дор юм. Зарим шийдүүлэгчид энэ нөхцөл байдалд маш муу ажилладаг бөгөөд хоёр холбоотой бага TTL-тэй:
$ өрөмдөх raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME ДАХЬ 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-тэй боловч энэ нь огт ашиггүй юм. Бусад 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 ДАХЬ 162.125.67.3 $ өрмийн 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 тэнхлэг нь кэш хийсэн оруулгатай хэдий ч хугацаа нь дууссан, шинэ хүсэлт гаргаж байгаа үйлчлүүлэгчийн хүсэлтийн хувь юм.
Хамгийн бага TTL-ийг 47 минут болгосноор "нэмэлт" хүсэлтийн эзлэх хувь 36% -иас 5% хүртэл буурдаг. Хамгийн бага TTL-ийг 15 минут болгосноор эдгээр хүсэлтийн тоо 29% хүртэл буурдаг. Хамгийн багадаа 1 цагийн TTL нь тэдгээрийг 17% хүртэл бууруулдаг. Чухал ялгаа!
Серверийн тал дээр юу ч өөрчлөхгүй, харин үйлчлүүлэгчийн DNS кэш (чиглүүлэгч, локал шийдүүлэгч) дэх хамгийн бага TTL-ийг тохируулбал ямар вэ?
Шаардлагатай хүсэлтийн тоо 47%-иас 34%-иас доошгүй TTL 5 минут, 25%-иар 15 минут, 13%-иас доошгүй 1 цаг хүртэл буурна. Магадгүй 40 минут хамгийн тохиромжтой.
Энэ жижиг өөрчлөлтийн нөлөө асар их байна.
Үр дагавар нь юу вэ?
Мэдээжийн хэрэг, үйлчилгээг шинэ үүл үйлчилгээ үзүүлэгч, шинэ сервер, шинэ сүлжээ рүү шилжүүлж, үйлчлүүлэгчдээс хамгийн сүүлийн үеийн DNS бичлэгүүдийг ашиглахыг шаардаж болно. Нилээд жижиг TTL нь ийм шилжилтийг жигд, үл үзэгдэх байдлаар хийхэд тусалдаг. Гэхдээ шинэ дэд бүтцэд шилжсэнээр үйлчлүүлэгчид 1 минут, 5 минут, 15 минутын дотор шинэ DNS бүртгэл рүү шилжинэ гэж хэн ч хүлээхгүй. Хамгийн бага TTL-ийг 40 минутын оронд 5 минут болгож тохируулах нь хэрэглэгчдийг үйлчилгээнд нэвтрэхэд саад болохгүй.
Гэсэн хэдий ч, энэ нь хоцролтыг мэдэгдэхүйц бууруулж, шаардлагагүй хүсэлтээс зайлсхийх замаар нууцлал, найдвартай байдлыг сайжруулах болно.
Мэдээжийн хэрэг, RFC-үүд TTL-ийг хатуу мөрдөх ёстой гэж хэлдэг. Гэвч бодит байдал дээр DNS систем хэтэрхий үр ашиггүй болсон байна.
Хэрэв та эрх бүхий DNS серверүүдтэй ажиллаж байгаа бол TTL-ээ шалгана уу. Танд үнэхээр ийм инээдтэй бага үнэ цэнэ хэрэгтэй юу?
Мэдээжийн хэрэг, DNS бичлэгүүдэд жижиг TTL тохируулах хангалттай шалтгаан бий. Гэхдээ бараг өөрчлөгдөөгүй DNS траффикийн 75% нь биш.
Хэрэв ямар нэг шалтгааны улмаас та DNS-д бага TTL ашиглах шаардлагатай бол тэр үед таны сайт кэшийг идэвхжүүлээгүй эсэхийг шалгаарай. Үүнтэй ижил шалтгаанаар.
Хэрэв танд орон нутгийн DNS кэш ажиллаж байгаа бол, жишээ нь Энэ нь танд хамгийн бага TTL-ийг тохируулах боломжийг олгодог бөгөөд энэ функцийг ашиглана уу. Энэ зүгээр. Ямар ч муу зүйл тохиолдохгүй. Хамгийн бага TTL-ийг ойролцоогоор 40 минут (2400 секунд) ба 1 цаг болгож тохируулна уу. Нилээд боломжийн хүрээ.
Эх сурвалж: www.habr.com