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