Skip to content
GitHub

The Handshake - Connection ကို စတင်ခြင်း

WebSocket ချိတ်ဆက်မှု တစ်ခုကို စတင် ထူထောင်တာဟာ စိတ်ဝင်စားစရာ ကောင်းပါတယ်။ သူက ပုံမှန် HTTP Request တစ်ခုနဲ့ပဲ အရင် စတင်ပြီး၊ အဲ့ဒီ ချိတ်ဆက်ထားတဲ့ လမ်းကြောင်းကိုပဲ WebSocket Protocol ဆိုတဲ့ ပိုပြီး အဆင့်မြင့်တဲ့၊ နှစ်ဖက်သွား ပြောဆိုနိုင်တဲ့ နည်းလမ်း အသစ်တစ်ခုဆီကို “အဆင့်မြှင့်တင်” (Upgrade) လိုက်တာမျိုး ဖြစ်ပါတယ်။

ဘယ်လို အဆင့်မြှင့်တင် (Upgrade) လဲ?

Section titled “ဘယ်လို အဆင့်မြှင့်တင် (Upgrade) လဲ?”

ဒီလို Upgrade လုပ်တဲ့ လုပ်ငန်းစဉ်ကို အဆင့် ၃ ဆင့်နဲ့ ရှင်းပြထားပါတယ်။ ဒါကို WebSocket Handshake လို့လည်း ခေါ်ပါတယ်။

၁။ Client ကနေ HTTP Request ပို့ပြီး Upgrade လုပ်ဖို့ တောင်းဆိုခြင်း

Section titled “၁။ Client ကနေ HTTP Request ပို့ပြီး Upgrade လုပ်ဖို့ တောင်းဆိုခြင်း”

ကိုယ့် Browser (Client) ကနေ Website Server ဆီကို ပုံမှန်အားဖြင့် Website စာမျက်နှာ ဒါမှမဟုတ် အချက်အလက် တစ်ခုခု တောင်းဆိုတဲ့ HTTP GET Request တစ်ခု အရင် ပို့လိုက်ပါတယ်။

ဒါပေမဲ့ ဒီတစ်ခါမှာတော့ ပုံမှန် Request မဟုတ်ဘဲ WebSocket Connection လုပ်ချင်ကြောင်း Server ကို အချက်ပြဖို့ Upgrade: websocket နဲ့ Connection: Upgrade ဆိုတဲ့ သီးခြား ထပ်ဆောင်း အချက်အလက်တွေ (Headers) ကို ထည့်ပေးလိုက်ပါတယ်။ ဒါ့အပြင် လုံခြုံရေးအတွက် ကျပန်း ထုတ်ထားတဲ့ လျှို့ဝှက်ကုဒ်တစ်ခု (Sec-WebSocket-Key) နဲ့ ဘယ် WebSocket Version ကို သုံးချင်ကြောင်းကိုလည်း ထည့်ပို့ပါတယ်။

(ဒါဟာ ပုံမှန် ဖုန်းခေါ်လိုက်ပြီး စကားမပြောသေးခင် ‘ဒီဖုန်းခေါ်ဆိုမှုကို နှစ်ဖက်စလုံး တစ်ပြိုင်နက် စိတ်ကြိုက် ပြောလို့ရတဲ့ အထူးလိုင်း အဖြစ် ပြောင်းရအောင်လား’ လို့ Server ကို မေးလိုက်တာနဲ့ တူပါတယ်)

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://client.example.com

၂။ Server က Upgrade လုပ်ရန် သဘောတူကြောင်း ပြန်ကြားခြင်း (101 Switching Protocols)

Section titled “၂။ Server က Upgrade လုပ်ရန် သဘောတူကြောင်း ပြန်ကြားခြင်း (101 Switching Protocols)”

Server က Client ပို့လိုက်တဲ့ Upgrade တောင်းဆိုမှုကို လက်ခံရရှိပြီး၊ WebSocket Connection လုပ်ဖို့ အဆင်သင့် ဖြစ်တယ်၊ သဘောတူတယ် ဆိုရင် HTTP Status Code အသစ်ဖြစ်တဲ့ 101 Switching Protocols ဆိုတဲ့ သီးခြား နံပါတ်နဲ့ ပြန်ဖြေပါတယ်။

ဒါဟာ ‘မင်း Protocol ပြောင်းချင်တာကို ငါ နားလည်ပြီ၊ ပြောင်းဖို့လည်း သဘောတူတယ်’ လို့ Server က ပြန်ပြောလိုက်တာပါ။ Server ရဲ့ Response မှာ Client ပို့လိုက်တဲ့ Upgrade နဲ့ Connection Headers တွေကို ပြန်ထည့်ပေးပြီး၊ Client ရဲ့ လျှို့ဝှက်ကုဒ် (Sec-WebSocket-Key) ကနေ တွက်ချက်ထားတဲ့ Sec-WebSocket-Accept ဆိုတဲ့ တန်ဖိုးတစ်ခုကိုပါ ပြန်ထည့်ပေးလိုက်ပါတယ်။

(ဒီ Sec-WebSocket-Accept တန်ဖိုးက Server ဟာ WebSocket Handshake လုပ်နည်းကို မှန်မှန်ကန်ကန် နားလည်ပြီး တကယ်လည်း လုပ်ဆောင်နိုင်ကြောင်း Client ဘက်ကို အတည်ပြုပြတဲ့ လျှို့ဝှက်ကုဒ် ပြန်ပြောပြတာမျိုးပါ)

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
http upgrade handshake

၃။ WebSocket Connection အောင်မြင်စွာ ထူထောင်ပြီးခြင်း

Section titled “၃။ WebSocket Connection အောင်မြင်စွာ ထူထောင်ပြီးခြင်း”

Client (Browser) က Server ရဲ့ 101 Switching Protocols Response နဲ့ Server ပြန်ပို့လိုက်တဲ့ Sec-WebSocket-Accept တန်ဖိုး မှန်ကန်မှု ရှိ/မရှိကို စစ်ဆေးပြီးတာနဲ့၊ အစက စတင်ခဲ့တဲ့ HTTP Connection ဟာ HTTP Connection အဖြစ်ကနေ လုံးဝ ပြောင်းလဲသွားပြီး WebSocket Connection အဖြစ် အောင်မြင်စွာ ထူထောင်ပြီး ဖြစ်သွားပါပြီ

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

ဒီလို Handshake လုပ်ငန်းစဉ် ပြီးသွားတာနဲ့၊ WebSocket Connection ဟာ အောက်ခံ TCP Connection တစ်ခုပေါ်မှာ ဆက်လက် တည်ရှိနေပြီး၊ HTTP ရဲ့ Request/Response Model ရဲ့ ကန့်သတ်ချက်တွေ မရှိတော့ဘဲ Data တွေကို နှစ်ဖက်စလုံး အချိန်မရွေး လွတ်လပ် လျင်မြန်စွာ ပို့နိုင်၊ ယူနိုင်တော့မှာ ဖြစ်ပါတယ် ခင်ဗျာ။