HTTP ရဲ့ သမိုင်းနှင့် ကန့်သတ်ချက်များ
HTTP ဆိုတာ ဘာလဲ?
Section titled “HTTP ဆိုတာ ဘာလဲ?”အချက်အလက်တွေ ယုံကြည်စိတ်ချစွာ ပို့နိုင်ဖို့ TCP က ဘယ်လို အခြေခံချိတ်ဆက်မှု လုပ်ပေးလဲဆိုတာ သိသွားပြီဆိုတော့၊ အဲဒီ TCP ချိတ်ဆက်မှုပေါ်ကနေ အလုပ်လုပ်တဲ့ HTTP Protocol အကြောင်းကို ဆက်ကြည့်ရအောင်။ WebSocket မပေါ်ခင်တုန်းက Website တွေ အချက်အလက် အပြန်အလှန်ပို့ဖို့အတွက် HTTP (Hypertext Transfer Protocol) ကိုပဲ အဓိကထား သုံးခဲ့ကြပါတယ်။ HTTP က Website တွေရဲ့ လည်ပတ်မှုအတွက် အင်မတန် အရေးကြီးပေမယ့်၊ အချိန်နဲ့တပြေးညီ ချက်ချင်းအပြောင်းအလဲရှိတဲ့ (Real-time) ဆက်သွယ်မှုတွေ (ဥပမာ - Live Chat, Online Game) အတွက်ကျတော့ အားနည်းချက် တချို့ ရှိခဲ့ပါတယ်။
HTTP ရဲ့ အဓိက လုပ်ငန်းပုံ (Request/Response Model)
Section titled “HTTP ရဲ့ အဓိက လုပ်ငန်းပုံ (Request/Response Model)”HTTP ဘယ်လို အလုပ်လုပ်လဲဆိုတဲ့ အခြေခံကတော့ “တောင်းဆိုခြင်း/တုံ့ပြန်ခြင်း” (Request/Response) ပုံစံပဲ ဖြစ်ပါတယ်။ ဒါက ဘာကိုပြောလဲဆိုတော့…
- ကိုယ့်ဘက်က တောင်းဆိုခြင်း (Client Request): ကိုယ့် Browser (Client) ကနေ Website Server ဆီကို ‘ဒီ Website ရဲ့ စာမျက်နှာကို ပြပါ’ လိုမျိုး၊ ဒါမှမဟုတ် ‘ဒီပုံလေးကို လိုချင်တယ်’ လိုမျိုး အချက်အလက်တစ်ခုခုကို “တောင်းဆိုခြင်း (Request)” လုပ်ပါတယ်။ (ဒါဟာ ကိုယ်က Server ကို မေးခွန်းတစ်ခု မေးလိုက်တာနဲ့တူပါတယ်)
- Server ဘက်က ပြန်ပို့ပေးခြင်း (Server Response): Server က Client ရဲ့ တောင်းဆိုမှုကို လက်ခံရရှိတာနဲ့ တောင်းဆိုထားတဲ့ အချက်အလက်ကို ရှာပြီး “တုံ့ပြန်ခြင်း (Response)” အနေနဲ့ ပြန်ပို့ပေးပါတယ်။ (Server က ကိုယ်မေးတဲ့ မေးခွန်းကို ပြန်ဖြေပေးတာပါ)
ဆက်သွယ်မှုပုံစံ
Section titled “ဆက်သွယ်မှုပုံစံ”ပုံမှန်အားဖြင့်ဆိုရင် Server က တောင်းဆိုထားတာကို ပြန်ပို့ပြီးတာနဲ့ (Response ပြီးတာနဲ့) အဲဒီ ချိတ်ဆက်မှုက ချက်ချင်း ပြတ်တောက်သွားတတ်ပါတယ်။ နောက်ပိုင်း နည်းပညာတွေ တိုးတက်လာတော့ (HTTP/1.1 မှာ Persistent Connection / Keep-Alive ဆိုပြီး) ချိတ်ဆက်မှုကို ချက်ချင်း မဖြတ်ဘဲ ခဏလေး ဖွင့်ထားပေးတာမျိုး လုပ်လို့ရလာပေမယ့်၊ အလုပ်လုပ်ပုံ အခြေခံကတော့ ကိုယ်က တောင်းဆို (Request) မှ Server က ပြန်ပို့ (Response) ပေးတဲ့ ပုံစံအတိုင်းပဲ ရှိနေတုန်းပါပဲ။ (ဖုန်းကြိုးဖွင့်ထားပေမယ့် ကိုယ်က စကားမပြောရင် ဟိုဘက်ကလည်း ဘာမှ မပြောသလိုမျိုးပါ)
Static Content များအတွက် သင့်တော်ခြင်း
Section titled “Static Content များအတွက် သင့်တော်ခြင်း”ဒီလို “ကိုယ်က တောင်းဆိုမှ Server က ပြန်ပို့ပေးတဲ့” ပုံစံဟာ မပြောင်းလဲတဲ့ Website စာမျက်နှာတွေ (Static Content) ကို ကြည့်တာ ဒါမှမဟုတ် ကိုယ်ဖြည့်ထားတဲ့ Form Data တွေ Server ဆီ ပို့တာမျိုးတွေအတွက် လုံလောက်ပြီး အဆင်ပြေပါတယ်။
Real-time ဆက်သွယ်မှုအတွက် အားနည်းချက်များ
Section titled “Real-time ဆက်သွယ်မှုအတွက် အားနည်းချက်များ”ဒါပေမယ့် Server ဘက်မှာ အချက်အလက်အသစ်တွေ (ဥပမာ - Chat Message အသစ်တစ်ခု ဝင်လာတာ၊ စတော့ဈေးနှုန်း ရုတ်တရက် ပြောင်းသွားတာ) ရတာနဲ့ Browser ကို ချက်ချင်း၊ ချက်ချင်းပို့ပေးဖို့ လိုအပ်တဲ့ Real-time အခြေအနေတွေ (ဥပမာ - Chat Application တွေ၊ တိုက်ရိုက် ဂိမ်းဆော့တာတွေ၊ Live Update ပြနေတဲ့ ကိန်းဂဏန်းတွေ) အတွက်ကျတော့ ဒီနည်းလမ်းက အားနည်းချက် အကြီးကြီး ရှိလာပါတယ်။ ဘာလို့လဲဆိုတော့ Server မှာ ဘယ်လောက် အချက်အလက်အသစ်တွေ ရှိနေပါစေ၊ Browser ဘက်ကနေ ‘အသစ်လာပြီလား’ လို့ ပြန်ပြန်ပြီး လာတောင်းဆို (Request လုပ်) တာကိုပဲ စောင့်နေရမှာ ဖြစ်ပါတယ်။
Server-to-Client Data Pushing
Section titled “Server-to-Client Data Pushing”Server က အလိုအလျောက် အချက်အလက်ကို Browser ဆီ တွန်းပို့လို့ မရပါဘူး။ (Browser က အမြဲတမ်း လိုက်မေးနေရသလို ဖြစ်နေမှာပါ)
ဒီလိုမျိုး Server ကနေ Client (Browser) ဆီကို အချက်အလက်အသစ်ရတာနဲ့ ချက်ချင်း တွန်းပို့ပေးနိုင်တဲ့ နည်းလမ်းတစ်ခု HTTP မှာ အခြေခံအားဖြင့် မပါဝင်ပါဘူး။ ဒါကြောင့် Real-time ဆက်သွယ်မှုတွေအတွက် ပိုမိုကောင်းမွန်တဲ့၊ Server ကနေလည်း Client ဆီကို လိုအပ်ရင် လိုအပ်သလို ချက်ချင်းပို့ပေးနိုင်တဲ့ နည်းလမ်းသစ်တစ်ခု လိုအပ်လာတာ ဖြစ်ပါတယ်။ အဲဒါကတော့ နောက်မှ လေ့လာမယ့် WebSocket ပဲ ဖြစ်ပါတယ်။