HTTP နှင့် Real-Time

HTTP ရဲ့ ပြဿနာကို ကျော်လွှားဖို့ ကြိုးစားခြင်း

WebSocket မပေါ်ခင်တုန်းက Developer တွေဟာ Website တွေကို Real-time လိုမျိုး ချက်ချင်း အပြောင်းအလဲ ပြသနိုင်အောင် HTTP ရဲ့ “ကိုယ်က တောင်းဆိုမှ Server က ပြန်ပို့ပေးတဲ့ စနစ်” (Request/Response) ကိုပဲ အသုံးပြုပြီး နည်းလမ်း အမျိုးမျိုးနဲ့ ကြိုးစားခဲ့ကြပါတယ်။ ဒါပေမဲ့ ဒီနည်းလမ်းတွေဟာ အကောင်းဆုံးနဲ့ အထိရောက်ဆုံး ဖြေရှင်းနည်းတွေတော့ မဟုတ်ခဲ့ပါဘူး။

Server ကနေ Client ဆီကို အချက်အလက် အသစ်ရတာနဲ့ ချက်ချင်း ပို့ပေးဖို့ အားနည်းနေတဲ့ HTTP ရဲ့ ပြဿနာကို ဘယ်လို ကျော်လွှားဖို့ ကြိုးစားခဲ့ကြလဲ ဆိုတာကို အောက်မှာ လေ့လာကြည့်ရအောင် ခင်ဗျာ။

၁။ Polling (အချိန်မှန် လိုက်မေးခြင်း)

ဒီနည်းလမ်းမှာ Client ဘက် (ကိုယ့် Browser) ကနေ Server ဆီကို အချိန်မှန်မှန်လေးတွေ သတ်မှတ်ပြီး (ဥပမာ - ၅ စက္ကန့် ဒါမှမဟုတ် ၁၀ စက္ကန့် တစ်ကြိမ်) ‘အချက်အလက် အသစ် ဘာများ ရှိလဲ’ လို့ HTTP Request တွေ ပို့ပြီး ဆက်တိုက် လိုက်မေးနေတာပါ။ (ဒါဟာ ကိုယ်က သူငယ်ချင်း တစ်ယောက်ဆီကို ‘သတင်းထူး ဘာရှိလဲ’ လို့ အချိန်တိုင်း ဖုန်းခေါ်ပြီး လိုက်မေးနေတာနဲ့ တူပါတယ်)။

• Polling ၏ အားနည်းချက်များ: အချက်အလက် အသစ် ဘာမှ မရှိရင်တောင် Client က Request တွေ ဆက်တိုက် ပို့နေရတဲ့အတွက် မလိုအပ်တဲ့ အင်တာနက် အသွားအလာ (Network Traffic) တွေ အရမ်း များစေပါတယ်။ Server ကိုလည်း မလိုအပ်ဘဲ အလုပ်တွေ ပိုစေပါတယ် (Server Load များတယ်)။ နောက်ပြီး အချက်အလက် အသစ် ရောက်တာနဲ့ ချက်ချင်း မသိရဘဲ ကိုယ့်ဘက်က နောက်တစ်ကြိမ် လိုက်မေးတဲ့ အချိန်ကျမှ သိရတတ်တဲ့အတွက် အချက်အလက် ရောက်ရှိမှု နှောင့်နှေးတာ (Latency) လည်း မြင့်မားပါတယ်။

၂။ Long Polling (စောင့်ပြီးမှ ဖြေခြင်း / Comet)

ဒီနည်းလမ်းက Polling ထက်တော့ နည်းနည်း ပိုကောင်းပါတယ်။ Client က Server ဆီကို Update အသစ်အတွက် Request ပို့လိုက်ပြီး၊ Server က အဲ့ဒီ Update အသစ်တစ်ခုခု တကယ် ရလာတဲ့အထိ (ဒါမှမဟုတ် ကြိုသတ်မှတ်ထားတဲ့ အချိန်တစ်ခု (Timeout) ကုန်သွားတဲ့အထိ) Connection ကို မပိတ်ဘဲ ဆက်ဖွင့်ထားပေးပါတယ်။ Update ရတာနဲ့ အဲ့ဒီ ဖွင့်ထားတဲ့ ချိတ်ဆက်မှုကနေ Response ပြန်ပို့ပြီးမှသာ Connection ကို ပိတ်လိုက်ပါတယ်။ Client ကလည်း Response ရတာနဲ့ နောက်ထပ် Update အသစ်ကို ထပ်စောင့်ဖို့ Connection အသစ်တစ်ခုကို ချက်ချင်း ပြန်ဖွင့်ပြီး ထပ်စောင့်ပါတယ်။ (သူငယ်ချင်းဆီ ဖုန်းခေါ်ပြီး ‘သတင်းထူးရရင် ဖုန်းမချဘဲ ကိုင်ထားနော်၊ ရတာနဲ့ ပြောပြီး လိုင်းချလိုက်၊ ငါလည်း မင်းပြောတာ ပြီးတာနဲ့ ချက်ချင်း ပြန်ခေါ်ပြီး နောက်ထပ် သတင်းထူးကို ထပ်စောင့်နေမယ်’ လို့ ပြောထားတာနဲ့ တူပါတယ်)။

• Long Polling ၏ အားနည်းချက်များ: Polling လိုမျိုး အမြဲတမ်း လိုက်မေးနေစရာ မလိုတော့ပေမဲ့၊ Connection အသစ်တွေ ခဏခဏ ထူထောင်လိုက်၊ ဖြတ်တောက်လိုက် လုပ်နေရတဲ့အတွက် အလုပ်ရှုပ်ပြီး မလိုအပ်တဲ့ အားထုတ်မှုတွေ (Connection Overhead) ရှိနေတုန်းပါပဲ။ Server ဘက်မှာလည်း Connection အများကြီးကို တစ်ပြိုင်နက် ဖွင့်ထားပြီး ကိုင်တွယ်ရတာ ပိုမို ရှုပ်ထွေးနိုင်ပါတယ်။ အရေးအကြီးဆုံးကတော့ ဒါဟာ တကယ်ကြီး နှစ်ဖက် ပြိုင်တူ စိတ်ကြိုက် ပြောဆိုလို့ရတဲ့ (Bi-directional) Communication မဟုတ်သေးပါဘူး။ Server က Update အသစ်ရရင်တောင် Client က စောင့်နေတဲ့ Request ကို တုံ့ပြန်တဲ့ အနေနဲ့ပဲ ပို့လို့ရတာ ဖြစ်ပါတယ်။ Server ကနေ Client ဆီကို တောင်းဆိုမှု မရှိဘဲ စပြီး အချက်အလက် တွန်းပို့ (Push) လုပ်တာမျိုး မဟုတ်သေးပါဘူး။

ပိုကောင်းသော နည်းလမ်း

ဒီနည်းလမ်းတွေဟာ HTTP ရဲ့ မူလ ပုံစံအရ Server ကနေ Client ဆီကို အချက်အလက် အသစ် ချက်ချင်း တွန်းပို့လို့ မရတဲ့ အားနည်းချက်ကို ကျော်လွှားဖို့ (Workarounds အဖြစ်) ကြိုးစားခဲ့တဲ့ နည်းလမ်းတွေပါ။

ဒီနည်းလမ်းတွေရဲ့ အားနည်းချက်တွေကြောင့်၊ Server ကနေ Client ဆီကို Client ဘက်က တောင်းဆိုမှု မရှိဘဲနဲ့ အချက်အလက် အသစ်ရတာနဲ့ ချက်ချင်း တိုက်ရိုက် ပို့နိုင်တဲ့ ပိုကောင်းပြီး ပိုမို ထိရောက်တဲ့ နည်းလမ်းတစ်ခု Real-time Application တွေအတွက် မဖြစ်မနေ လိုအပ်နေပြီ ဆိုတာ ပိုပြီး ပေါ်လွင်လာပါတယ်။ အဲ့ဒီ လိုအပ်ချက်ကို ဖြည့်ဆည်းပေးဖို့ပဲ WebSocket ဆိုတာ ပေါ်ပေါက်လာတာ ဖြစ်ပါတယ် ခင်ဗျာ။