HTTP Version များ၏ သမိုင်းအကျဉ်း (အသေးစိတ်)
ဘယ်လို တိုးတက် ပြောင်းလဲလာတာလဲ?
Section titled “ဘယ်လို တိုးတက် ပြောင်းလဲလာတာလဲ?”HTTP ဟာ နှစ်ပေါင်းများစွာ ကြာလာတာနဲ့အမျှ ပိုကောင်းလာအောင်၊ ပိုမြန်လာအောင် Version တွေ ပြောင်းပြီး အဆင့်ဆင့် တိုးတက်လာခဲ့ပါတယ်။ ဒါပေမဲ့ သူ့ရဲ့ အခြေခံ အလုပ်လုပ်ပုံဖြစ်တဲ့ “ကိုယ်က တောင်းဆိုမှ Server က ပြန်ပို့ပေးတဲ့” (Request/Response Model) ကတော့ အများစု မပြောင်းလဲခဲ့ပါဘူး။ တိုးတက်လာတဲ့ Version တွေမှာ ဘာအသစ်တွေ ပါလာလဲ ဆိုတာ ကြည့်ရအောင် ခင်ဗျာ။
HTTP/1.0 (၁၉၉၆)
Section titled “HTTP/1.0 (၁၉၉၆)”ဒါက အစောပိုင်းကာလပါ။ တောင်းဆိုတာတွေ၊ ပြန်ပို့တာတွေမှာ ထပ်ဆောင်း အချက်အလက်တွေ (Headers) ထည့်တာ၊ အမျိုးအစား မတူတဲ့ အချက်အလက်တွေ (ရုပ်ပုံ၊ စာသား စသည်ဖြင့်) ပို့လို့ရတာ၊ အချက်အလက် ပို့နည်း အမျိုးမျိုး (ဥပမာ - GET, POST) နဲ့ အခြေအနေပြ နံပါတ်တွေ (ဥပမာ - 200 ဆို အိုကေ၊ 404 ဆို ရှာမတွေ့) စတာတွေ ပါလာပါတယ်။ ဒီတုန်းကတော့ Request တစ်ခုလုပ်ပြီး Response ပြန်ရတာနဲ့ ချိတ်ဆက်မှုက ပုံမှန်အားဖြင့် ချက်ချင်း ပြတ်သွားပါတယ်။ (တစ်ခုမေး၊ အဖြေရ၊ ဖုန်းချသလိုမျိုးပါ)။
HTTP/1.1 (၁၉၉၇)
Section titled “HTTP/1.1 (၁၉၉၇)”တော်တော်လေး တိုးတက်လာပါတယ်။ အရေးအကြီးဆုံးကတော့ ချိတ်ဆက်မှုကို ချက်ချင်း မဖြတ်ဘဲ ခဏဖွင့်ထားတာ (Persistent Connections / Keep-Alive) ကြောင့် နောက်ထပ် တောင်းဆိုစရာ ရှိရင် အသစ် ပြန်ချိတ်စရာ မလိုတော့လို့ ပိုမြန်လာပါတယ်။ တခြား ပိုကောင်းတဲ့ စနစ်တွေလည်း ပါဝင်လာပြီး နှစ်ပေါင်းများစွာ Website တွေအတွက် အသုံးအများဆုံး Version ဖြစ်ခဲ့ပါတယ်။ (ဖုန်းကြိုး မချသေးဘဲ နောက်မေးခွန်းတစ်ခု ဆက်မေးလို့ ရလာတာမျိုးပါ)။
HTTP/2 (၂၀၁၅)
Section titled “HTTP/2 (၂၀၁၅)”ပိုပြီး မြန်အောင်၊ ပိုပြီး အလုပ်များများ လုပ်နိုင်အောင် လုပ်ဖို့ အဓိက ရည်ရွယ်ပါတယ်။ အချက်အလက်တွေကို တစ်ခုချင်းစီ စောင့်ပို့နေစရာ မလိုဘဲ ချိတ်ဆက်မှု တစ်ခုတည်း ပေါ်ကနေ မတူညီတဲ့ အချက်အလက် အများကြီးကို တစ်ပြိုင်နက် ပို့လို့ရတာ (Multiplexing)၊ ထပ်ဆောင်း အချက်အလက် (Headers) တွေကို ချုံ့ပြီးပို့တာ စတာတွေ ပါလာပါတယ်။ (လမ်းကြောင်း တစ်ခုတည်းကနေ ကုန်ပစ္စည်း အမျိုးမျိုးကို တစ်ပြိုင်တည်း ပို့လို့ရတာမျိုးပါ)။
HTTP/3 (၂၀၂၂)
Section titled “HTTP/3 (၂၀၂၂)”အသစ်ဆုံး Version ပါ။ အချက်အလက် ပို့ဆောင်တဲ့ အောက်ခံနည်းလမ်းကို TCP ရဲ့နေရာမှာ ပိုပြီး မြန်ဆန်တဲ့ QUIC ဆိုတဲ့ နည်းလမ်းသစ် (UDP ပေါ်မှာ တည်ဆောက်ထားပြီး လိုအပ်တဲ့ ယုံကြည်စိတ်ချမှုတွေ ထပ်ထည့်ထားပါတယ်) ကို အသုံးပြုပါတယ်။ ဒါကြောင့် ချိတ်ဆက်မှု စလုပ်တာ ပိုမြန်ပြီး Network မကောင်းတဲ့ အခါမျိုးမှာတောင် အချက်အလက် အများကြီးကို တစ်ပြိုင်နက် ပို့တာ ပိုကောင်းလာပါတယ်။
Real-Time အတွက် HTTP ရဲ့ အားနည်းချက် (ပိုရှင်းအောင် ထပ်ပြောခြင်း)
Section titled “Real-Time အတွက် HTTP ရဲ့ အားနည်းချက် (ပိုရှင်းအောင် ထပ်ပြောခြင်း)”ဒီလို Version တွေ တစ်ဆင့်ပြီးတစ်ဆင့် တိုးတက်လာပြီး မြန်လာပေမဲ့ Real-time (ချက်ချင်း အပြောင်းအလဲ ရှိတာ) အတွက် အဓိက အားနည်းချက်ကတော့ အတူတူပဲ ရှိနေတုန်းပါပဲ။
အဲ့ဒါကတော့ HTTP ရဲ့ “ကိုယ်က တောင်းဆိုမှ Server က ပြန်ပို့ပေးတဲ့” (Request/Response) ပုံစံကြောင့် Server ဘက်မှာ အချက်အလက် အသစ် (ဥပမာ - Chat Message အသစ်၊ ဒါမှမဟုတ် Live Sport Score အပြောင်းအလဲ) ရတာနဲ့ Client (Browser) ဘက်ကို ကိုယ်တိုင် စတင်ပြီး (Push) ပို့ဖို့ မလွယ်ကူတာပါပဲ။
WebSocket ဘာကြောင့် လိုအပ်လာသလဲ?
Section titled “WebSocket ဘာကြောင့် လိုအပ်လာသလဲ?”Live Chat တို့၊ စတော့ရှယ်ယာ ဈေးနှုန်းတို့လို အချိန်နဲ့ တပြေးညီ (Real-time) Update ပြရတဲ့ Application တွေမှာဆိုရင် Server မှာ Data အသစ် ဖြစ်ပေါ်လာတာနဲ့ Client ဆီ ချက်ချင်း ပို့ပေးဖို့ လိုအပ်ပါတယ်။
ဒါပေမဲ့ HTTP ရဲ့ မူလ ဒီဇိုင်းအရ Server ကနေ Client ဆီကို Client ဘက်က တောင်းဆိုမှု မရှိဘဲ စတင်ပြီး အချက်အလက် (Update) ပို့ဖို့က တော်တော်လေး ခက်ခဲပါတယ်။ Client ဘက်က ‘အသစ် လာပြီလား’ လို့ အမြဲတမ်း ပြန်ပြန်ပြီး လာမေး (Request လုပ်) နေမှသာ Server က ပြန်ဖြေ (Response လုပ်) ပေးနိုင်တာဖြစ်လို့ ချက်ချင်း Update လုပ်ဖို့အတွက် ဒီနည်းလမ်းက အဆင်မပြေပါဘူး။
ဒါကြောင့် Server ကနေလည်း Client ဆီကို လိုအပ်ရင် လိုအပ်သလို အချိန်မရွေး၊ တောင်းဆိုမှု မရှိဘဲ ချက်ချင်း အချက်အလက် (Update) တွေ တွန်းပို့ (Push) ပေးနိုင်တဲ့ နည်းလမ်းသစ်တစ်ခု Real-time Application တွေအတွက် မဖြစ်မနေ လိုအပ်လာတာ ဖြစ်ပါတယ်။ အဲ့ဒါကတော့ ကျွန်တော်တို့ လေ့လာမယ့် WebSocket နည်းပညာပဲ ဖြစ်ပါတယ် ခင်ဗျာ။