වේගවත් අන්තර්ජාල ගවේෂණය සඳහා අඩු DNS ප්‍රමාදය ප්‍රධාන වේ. එය අවම කිරීම සඳහා, DNS සේවාදායකයන් ප්රවේශමෙන් තෝරා ගැනීම වැදගත් වේ . නමුත් පළමු පියවර වන්නේ නිෂ්ඵල විමසුම් ඉවත් කිරීමයි.
DNS මුලින් නිර්මාණය කර ඇත්තේ ඉතා හැඹිලිගත හැකි ප්‍රොටෝකෝලයක් ලෙසය. කලාප පරිපාලකයින් තනි ඇතුළත් කිරීම් සඳහා ජීවත් වීමට (TTL) වේලාවක් නියම කරන අතර, අනවශ්‍ය තදබදය මඟහරවා ගැනීම සඳහා මතකයේ ඇතුළත් කිරීම් ගබඩා කිරීමේදී විසඳන්නන් මෙම තොරතුරු භාවිතා කරයි.
හැඹිලිගත කිරීම ඵලදායීද? වසර කිහිපයකට පෙර, මගේ කුඩා පර්යේෂණ පෙන්නුම් කළේ එය පරිපූර්ණ නොවන බවයි. වත්මන් තත්ත්වය දෙස බලමු.
තොරතුරු රැස් කිරීමට මම පැච් කළා ප්‍රතිචාරය සඳහා TTL අගය සුරැකීමට. එය එක් එක් එන ඉල්ලීම සඳහා එහි වාර්තා වල අවම TTL ලෙස අර්ථ දක්වා ඇත. මෙය සැබෑ ගමනාගමනයේ TTL බෙදා හැරීම පිළිබඳ හොඳ දළ විශ්ලේෂණයක් ලබා දෙන අතර, තනි ඉල්ලීම්වල ජනප්‍රියතාවය ද සැලකිල්ලට ගනී. සේවාදායකයේ පැච් කළ අනුවාදය පැය කිහිපයක් වැඩ කළේය.
ප්‍රතිඵලයක් ලෙස ලැබෙන දත්ත කට්ටලය වාර්තා 1කින් සමන්විත වේ (නම, qtype, TTL, timestamp). මෙන්න සමස්ත TTL ව්‍යාප්තිය (X-අක්ෂය තත්පර වලින් TTL වේ):
86 (බොහෝ විට SOA වාර්තා සඳහා) හි සුළු bump එකක් හැරුණු විට, TTLs අඩු පරාසයක පවතින බව ඉතා පැහැදිලිය. අපි සමීපව බලමු:
හරි, පැය 1කට වඩා වැඩි TTL සංඛ්‍යානමය වශයෙන් වැදගත් නොවේ. ඉන්පසු අපි 0−3600 පරාසය කෙරෙහි අවධානය යොමු කරමු:
බොහෝ TTLs විනාඩි 0 සිට 15 දක්වා වේ:
අතිමහත් බහුතරය විනාඩි 0 සිට 5 දක්වා වේ:
එය ඉතා හොඳ නැත.
සමුච්චිත ව්‍යාප්තිය ගැටලුව වඩාත් පැහැදිලි කරයි:
DNS ප්‍රතිචාරවලින් අඩකට මිනිත්තු 1ක් හෝ ඊට අඩු TTL එකක් ඇති අතර හතරෙන් තුනකට මිනිත්තු 5ක් හෝ ඊට අඩු TTL එකක් ඇත.
නමුත් ඉන්න, එය ඇත්තෙන්ම නරකයි. සියල්ලට පසු, මෙය බලයලත් සේවාදායකයන්ගෙන් TTL වේ. කෙසේ වෙතත්, සේවාදායක නිරාකරණය කරන්නන් (උදා: රවුටර, දේශීය හැඹිලි) උඩු ප්‍රවාහ විසදුම් වලින් TTL ලබා ගන්නා අතර එය සෑම තත්පරයකම අඩු වේ.
එබැවින් සේවාලාභියාට නව ඉල්ලීමක් යැවීමට පෙර එක් එක් ප්‍රවේශය සාමාන්‍යයෙන් මුල් TTL වලින් අඩක් භාවිතා කළ හැක.
සමහර විට මෙම ඉතා අඩු TTLs අදාළ වන්නේ අසාමාන්‍ය ඉල්ලීම්වලට මිස ජනප්‍රිය වෙබ් අඩවි සහ API සඳහා නොවේද? අපි බලමු:
X අක්ෂය TTL වේ, Y අක්ෂය විමසුම් ජනප්රියත්වය වේ.
අවාසනාවකට, වඩාත් ජනප්‍රිය විමසුම් ද හැඹිලියට නරකම වේ.
අපි විශාලනය කරමු:
තීන්දුව: එය ඇත්තෙන්ම නරකයි. එය දැනටමත් නරක විය, නමුත් එය වඩාත් නරක අතට හැරී ඇත. DNS හැඹිලි කිරීම ප්‍රායෝගිකව නිෂ්ඵල වී ඇත. අඩු පිරිසක් ඔවුන්ගේ ISP හි DNS විසඳුම භාවිතා කරන බැවින් (හොඳ හේතු නිසා), ප්‍රමාදයේ වැඩි වීම වඩාත් කැපී පෙනේ.
DNS හැඹිලිය ප්‍රයෝජනවත් වී ඇත්තේ කිසිවෙකු නොපැමිණෙන අන්තර්ගතය සඳහා පමණි.
මෘදුකාංග විය හැකි බව ද කරුණාවෙන් සලකන්න අඩු TTL අර්ථකථනය කරන්න.
ඇයි එසේ
DNS වාර්තා මෙතරම් අඩු TTL එකකට සකසා ඇත්තේ ඇයි?
- ලෙගසි ලෝඩ් බැලන්සර් පෙරනිමි සැකසුම් සමඟ ඉතිරි විය.
- DNS පැටවුම් තුලනය TTL මත රඳා පවතින බවට මිථ්‍යාවන් ඇත (මෙය සත්‍ය නොවේ - Netscape Navigator කාලයේ සිට, සේවාදායකයින් RRs කට්ටලයකින් අහඹු IP ලිපිනයක් තෝරාගෙන ඇති අතර ඔවුන්ට සම්බන්ධ වීමට නොහැකි නම් විනිවිද පෙනෙන ලෙස වෙනත් එකක් උත්සාහ කර ඇත)
- පරිපාලකයින්ට වහාම වෙනස්කම් යෙදීමට අවශ්‍ය වේ, එබැවින් එය සැලසුම් කිරීම පහසුය.
- DNS සේවාදායකයක හෝ load balancer එකක පරිපාලක ඔහුගේ කාර්යය දකින්නේ පරිශීලකයන් ඉල්ලා සිටින වින්‍යාසය කාර්යක්ෂමව යෙදවීම සහ අඩවි සහ සේවා වේගවත් කිරීම නොවේ.
- අඩු TTL ඔබට මනසේ සාමය ලබා දෙයි.
- මිනිසුන් මුලදී පරීක්ෂණ සඳහා අඩු TTL සකසා පසුව ඒවා වෙනස් කිරීමට අමතක කරයි.
මම "අසාර්ථක" ලැයිස්තුවට ඇතුළත් නොකළේ එය අඩුවෙන් අදාළ වන බැවිනි. ඔබට පරිශීලකයන් වෙනත් ජාලයකට හරවා යැවීමට අවශ්‍ය නම්, අනෙක් සියල්ල මුළුමනින්ම කැඩී ගිය විට දෝෂ පිටුවක් පෙන්වීමට, මිනිත්තු 1කට වඩා ප්‍රමාදයක් පිළිගත හැකිය.
මීට අමතරව, එක් මිනිත්තුවක TTL යනු බලයලත් DNS සේවාදායකයන් විනාඩි 1 කට වඩා අවහිර කර ඇත්නම්, වෙනත් කිසිවෙකුට යැපෙන සේවාවන් වෙත ප්‍රවේශ වීමට නොහැකි වනු ඇත. හේතුව වින්‍යාස දෝෂයක් හෝ හැක් කිරීමක් නම් අතිරික්තය උදව් නොවනු ඇත. අනෙක් අතට, සාධාරණ TTL සමඟින්, බොහෝ සේවාදායකයින් පෙර වින්‍යාසය දිගටම භාවිතා කරන අතර කිසි විටෙකත් කිසිවක් නොදකිනු ඇත.
CDN සේවා සහ load balancers බොහෝ දුරට අඩු TTL සඳහා දොස් පැවරිය යුතුය, විශේෂයෙන් ඔවුන් CNAMEs අඩු TTLs සමඟ සහ වාර්තා සමානව අඩු (නමුත් ස්වාධීන) 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 මත ධාවනය වේ. ඔබ මෙම ඉල්ලීම දිගටම එවන්නේ නම්, සෑම විටම 1ක TTL එකක් ආපසු ලබා දෙනු ඇත. අත්‍යවශ්‍යයෙන්ම, 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
Level1 නිරාකරණය භාවිතා කරන විට Firefox සහ TTL වැනි එකම ගැටළුව තත්පර 3 කින් ඇණහිටිනු ඇත.
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 කි. තවද, නැවතත්, සේවාදායකයාගේ දෘෂ්ටි කෝණයෙන්, මෙම අගයන් අඩකින් අඩු වේ.
අවම TTL එකක් සකසන්නේ කෙසේද?
නම, ඉල්ලීම් වර්ගය, TTL, සහ මුලින් ගබඩා කර ඇති වේලා මුද්‍රාව භාවිතා කරමින්, කල් ඉකුත් වූ හැඹිලි ඇතුළත් කිරීමක් හේතුවෙන් එවන ලද අනවශ්‍ය ඉල්ලීම් ප්‍රමාණය තක්සේරු කිරීම සඳහා හැඹිලි විසදුමක් හරහා යන ඉල්ලීම් මිලියන 1,5 අනුකරණය කිරීමට මම ස්ක්‍රිප්ට් එකක් ලිව්වෙමි.
පවතින වාර්තාවක් කල් ඉකුත් වූ පසු ඉල්ලීම්වලින් 47,4%ක් ඉදිරිපත් කර ඇත. මෙය අසාධාරණ ලෙස ඉහළ ය.
අවම TTL සකසා ඇත්නම් හැඹිලිගත කිරීමට ඇති බලපෑම කුමක්ද?
X අක්ෂය යනු අවම TTL අගයන් වේ. මෙම අගයට වඩා මූලාශ්‍ර TTL සහිත වාර්තාවලට බලපෑමක් නැත.
Y අක්ෂය යනු දැනටමත් හැඹිලිගත ප්‍රවේශයක් ඇති සේවාදායකයෙකුගෙන් ඉල්ලීම් ප්‍රතිශතයකි, නමුත් එය කල් ඉකුත් වී ඇති අතර නව ඉල්ලීමක් කරයි.
"අමතර" ඉල්ලීම් වල කොටස 47% සිට 36% දක්වා අඩු කරනු ලබන්නේ අවම TTL විනාඩි 5ක් ලෙස සැකසීමෙනි. අවම TTL මිනිත්තු 15 ලෙස සැකසීමෙන්, මෙම ඉල්ලීම් ගණන 29% දක්වා පහත වැටේ. අවම වශයෙන් පැය 1 ක TTL ඒවා 17% දක්වා අඩු කරයි. සැලකිය යුතු වෙනසක්!
සේවාදායක පැත්තේ කිසිවක් වෙනස් නොකර, ඒ වෙනුවට සේවාදායක DNS හැඹිලි (රවුටර, දේශීය විසඳුම්) තුළ අවම TTL සැකසීම ගැන කුමක් කිව හැකිද?
අවශ්‍ය ඉල්ලීම් සංඛ්‍යාව අවම වශයෙන් මිනිත්තු 47ක TTL සමඟ 34% සිට 5% දක්වාද, අවම වශයෙන් මිනිත්තු 25කින් 15% දක්වාද, අවම වශයෙන් පැය 13කින් 1% දක්වාද පහත වැටේ. සමහර විට විනාඩි 40 ප්රශස්ත වේ.
මෙම කුඩා වෙනසෙහි බලපෑම අතිමහත්ය.
එහි විපාක මොනවාද?
ඇත්ත වශයෙන්ම, සේවාව නව වලාකුළු සපයන්නෙකු, නව සේවාදායකයක්, නව ජාලයක් වෙත ගෙන යා හැකි අතර, සේවාදායකයින්ට නවතම DNS වාර්තා භාවිතා කිරීමට අවශ්‍ය වේ. තරමක් කුඩා TTL එවැනි සංක්‍රාන්තියක් සුමටව හා නොපෙනෙන ලෙස සිදු කිරීමට උපකාරී වේ. නමුත් නව යටිතල පහසුකම් වෙත සංක්‍රමණය වීමත් සමඟ, සේවාදායකයින් මිනිත්තු 1, මිනිත්තු 5 හෝ මිනිත්තු 15 තුළ නව DNS වාර්තා වෙත සංක්‍රමණය වනු ඇතැයි කිසිවෙකු අපේක්ෂා නොකරයි. අවම TTL මිනිත්තු 40ක් වෙනුවට විනාඩි 5ක් ලෙස සැකසීම පරිශීලකයින්ට සේවාව වෙත ප්‍රවේශ වීම වලක්වන්නේ නැත.
කෙසේ වෙතත්, මෙය ප්‍රමාදය සැලකිය යුතු ලෙස අඩු කරන අතර අනවශ්‍ය ඉල්ලීම් මඟහරවා ගැනීමෙන් පුද්ගලිකත්වය සහ විශ්වසනීයත්වය වැඩි දියුණු කරයි.
ඇත්ත වශයෙන්ම, RFCs පවසන්නේ TTL දැඩි ලෙස අනුගමනය කළ යුතු බවයි. නමුත් යථාර්ථය නම් DNS පද්ධතිය ඉතා අකාර්යක්ෂම වී ඇති බවයි.
ඔබ බලයලත් DNS සේවාදායකයන් සමඟ වැඩ කරන්නේ නම්, කරුණාකර ඔබේ TTL පරීක්ෂා කරන්න. ඔබට ඇත්තටම එවැනි හාස්‍යජනක ලෙස පහත් අගයන් අවශ්‍යද?
ඇත්ත වශයෙන්ම, DNS වාර්තා සඳහා කුඩා TTL සැකසීමට හොඳ හේතු තිබේ. නමුත් පාහේ නොවෙනස්ව පවතින 75% DNS ගමනාගමනය සඳහා නොවේ.
යම් හේතුවක් නිසා ඔබට DNS සඳහා අඩු TTL භාවිතා කිරීමට අවශ්‍ය නම්, ඒ සමඟම ඔබේ වෙබ් අඩවිය හැඹිලි සක්‍රීය කර නොමැති බවට වග බලා ගන්න. එකම හේතු නිසා.
ඔබට දේශීය DNS හැඹිලියක් ක්‍රියාත්මක වන්නේ නම්, වැනි ඔබට අවම TTL සැකසීමට ඉඩ සලසයි, මෙම කාර්යය භාවිතා කරන්න. මේක හොඳයි. නරක කිසිවක් සිදු නොවනු ඇත. අවම TTL ආසන්න වශයෙන් විනාඩි 40 (තත්පර 2400) සහ පැය 1 ට සකසන්න. තරමක් සාධාරණ පරාසයක්.
මූලාශ්රය: www.habr.com