Client-Server နှင့် DNS

နားလည်ထားရမယ့် အချက်

Request တစ်ခု application server ဆီ မရောက်ခင် ပိုအခြေခံတဲ့ ပြဿနာတစ်ခု ဖြေရှင်းရပါတယ် — computer တွေက IP address နဲ့ ဆက်သွယ်ကြပေမယ့် လူသားတွေက domain name ကို ရိုက်ထည့်ကြပါတယ်။ DNS (Domain Name System) ဆိုတာ ဒီနှစ်ခုကို ချိတ်ဆက်ပေးတဲ့ lookup တစ်ခုပါ — browser တစ်ခုက example.com ကို ရောက်ချင်ရင် DNS resolver ဆီကို ဒီ name ကို IP address အဖြစ် ပြောင်းပေးဖို့ တောင်းဆိုပြီး၊ ဒီနောက်မှသာ actual server ဆီ network connection ဖွင့်နိုင်ပါတယ်။ ဒီ resolution အဆင့်ဟာ ပုံမှန်အသုံးပြုမှုမှာ မမြင်ရပေမယ့် web interaction တိုင်းရဲ့ ရှေ့ကနေ ဖြစ်ပေါ်နေတာဖြစ်ပြီး အခမဲ့လည်း မဟုတ်ပါဘူး — DNS lookup အပြည့်အစုံတစ်ခုက network distance ရှည်ရင် ပိုပြီး ထင်ရှားတဲ့ delay တစ်ခုကို ထည့်လာနိုင်ပါတယ်။ ဒါကို မြန်စေဖို့ DNS result တွေကို browser ဒါမှမဟုတ် OS ထဲမှာ local ကနေ ၊ intermediate resolver တွေမှာ record ရဲ့ TTL (time to live) သတ်မှတ်ထားတဲ့ ကြာချိန်အထိ cache လုပ်ထားပါတယ်။ TTL တိုတိုဆိုရင် domain ညွှန်ပြတဲ့ address ပြောင်းလဲမှုတွေက မြန်မြန် propagate ဖြစ်ပေမယ့် lookup က မကြာခဏ ဖြစ်ရပါတယ်; TTL ရှည်ရှည်ဆိုရင် ထပ်ခါထပ်ခါ lookup က မြန်ပေမယ့် server address ပြောင်းရင် propagate က နှေးသွားနိုင်ပါတယ်။ ဒီ client-to-server path — resolve, ပြီးမှ connect — ဟာ ဒီ course ရဲ့ lesson တိုင်းက အခြေခံအဖြစ် တည်ဆောက်ထားတဲ့ baseline architecture ဖြစ်ပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Learner တစ်ယောက် Tutorial Platform ရဲ့ domain ကို browser ထဲ ရိုက်ထည့်တိုင်း lesson content ဘယ်ဒါမှ load မဖြစ်ခင် DNS resolution ဖြစ်ပေါ်နေတာဖြစ်ပြီး ဒါဟာ platform engineer တွေ server code ကိုပဲ မဟုတ်ဘဲ TTL setting ကိုပါ အလေးထားရတဲ့ အကြောင်းအရင်းတစ်ခုပါ။ Platform ကို server အသစ်တစ်ခုဆီ ရွှေ့ဖို့ လိုလာရင် (ဥပမာ ယခင် lesson က horizontal-scaling rollout လုပ်ချိန်) DNS TTL ရှည်နေရင် learner အချို့က switch ဖြစ်ပြီး နာရီချီကြာအထိ server အဟောင်းကိုပဲ ဆက်ရောက်နေနိုင်ပြီး TTL တိုနေရင် ပြောင်းလဲမှု မြန်မြန်ဖြန့်ပေမယ့် scale ကြီးလာရင် lookup ပိုများလာလို့ ကုန်ကျစရိတ် ပိုများပါတယ်။ ဒီ path ကို နားလည်ခြင်းက load balancing, caching, replication လို နောက်ပိုင်း lesson တိုင်းရဲ့ အခြေခံ ဖြစ်ပါတယ်။

Web request တိုင်းဟာ DNS resolution နဲ့ စတင်တယ် — connection မဖွင့်ခင် human-readable domain name ကို numeric IP address အဖြစ် ပြောင်းရတယ်။
DNS result တွေကို browser, OS, resolver စတဲ့ layer အများစုမှာ TTL သတ်မှတ်ထားတဲ့ ကြာချိန်အတိုင်း cache လုပ်ထားပြီး propagation speed နဲ့ lookup frequency ကို trade-off လုပ်တယ်။
Client-server communication ဆိုတာ DNS မှတဆင့် domain ကို resolve လုပ်ပြီး resolve လုပ်ရရှိတဲ့ IP ဆီ connection ဖွင့်ခြင်းဖြစ်ပြီး ဒါက system design concept တခြားတွေရဲ့ baseline ဖြစ်တယ်။

အတူတူ စမ်းရေးကြည့်မယ်

text

Browser                DNS Resolver            IP Address           Server
--------                ------------            ----------           ------
  |  "example.com?"          |                       |                  |
  |------------------------->|                       |                  |
  |                          | [check cache: MISS]    |                  |
  |                          |----------------------->|                  |
  |                          | 93.184.216.34, TTL=300s|                  |
  |<-------------------------|                       |                  |
  |  [cache IP for 300s]     |                       |                  |
  |------------------------- connect to 93.184.216.34 ------------------>|
  |                                                                       |
  |  Next request (within 300s): skip DNS lookup entirely, use cached IP |

You should see

Diagram က DNS resolution အဆင့် (cache miss/hit နှင့် TTL) ကို connection ဖွင့်ခြင်းမတိုင်ခင် ဖြစ်ပေါ်ကြောင်း ပြသပါတယ်။

၅ မိနစ် စမ်းကြည့်

terminal မှာ nslookup ဒါမှမဟုတ် dig ကို website တစ်ခုအပေါ် run ကြည့်ပြီး ပြန်လာတဲ့ TTL value ကို ရှာကြည့်ပါ — TTL တိုတိုနဲ့ ရှည်ရှည်က website ပိုင်ရှင်ကို ဘာသက်ရောက်မှုရှိနိုင်လဲ?

သတိလေးတစ်ချက်

Convenience အတွက် DNS TTL ကို ရှည်ရှည် သတ်မှတ်ထားပြီး server migration ဒါမှမဟုတ် outage တစ်ခု ဖြစ်ချိန်မှာ client အများစုက address ဟောင်း ပျက်စီးသွားတဲ့ IP ကို နာရီချီကြာအောင် ဆက်ပို့နေတာ တွေ့ရတတ်ပါတယ်။

DNS resolution ဟာ instant နဲ့ free ဖြစ်တယ်လို့ သတ်မှတ်ထားပြီး latency budget တိုင်းရေတွက်ရသေးတဲ့ request path တစ်ခုအတွက် cache မလုပ်ရသေးတဲ့ lookup က ထင်ရှားတဲ့ latency ထပ်ထည့်နေတာကို လျစ်လျူရှုတတ်ပါတယ်။

Wikipedia — Domain Name System — System Design