Node.js CONNECT ကိုင်တွယ်သူများသည် head buffer ကို ထိန်းသိမ်းရမည်
HTTP မှ tunnel သို့ ကူးပြောင်းသည့် နယ်စပ်တွင် Node ၏ CONNECT socket နှင့် head buffer ကို ကိုင်တွယ်ပြီး headers ကျော်လွန်၍ ဖတ်ပြီးသော bytes များကို ထိန်းသိမ်းပါ။
Node HTTP server သည် သာမန် proxy တောင်းဆိုမှုကို ၎င်း၏ request callback ဖြင့် ကိုင်တွယ်သည်။ CONNECT သည် အခြားလမ်းကို သွားသည်။ server သည် တောင်းဆိုမှု၊ client socket နှင့် head buffer တို့နှင့်အတူ connect ကို ထုတ်လွှတ်သည်။
ထို ဖြစ်ရပ်သည် HTTP ခွဲခြမ်းစိတ်ဖြာမှုနှင့် tunnel အကြား လွှဲပြောင်းမှု ဖြစ်သည်။ tunnel လုပ်ထားသော အသွားအလာအတွက် ဆက်လက်အသုံးပြုမည့် သာမန် ServerResponse object မရှိပါ။
| အငြင်းအခုံ | ၎င်း သယ်ဆောင်သည့်အရာ |
|---|---|
req | CONNECT တောင်းဆိုမှု၊ ၎င်း၏ ဦးတည်ရာ အာဏာပိုင်နှင့် headers အပါအဝင် |
clientSocket | client သို့ ပြန်သွားသော ချိတ်ဆက်မှု |
head | Node က HTTP headers ကျော်၍ ဖတ်ပြီးသော tunnel ဒေတာ၊ ဗလာဖြစ်နိုင်သည် |
bytes များ မပို့မီ HTTP ဆုံးဖြတ်ချက်ကို အပြီးသတ်ပါ
တောင်းဆိုထားသော host နှင့် port ကို စစ်ဆေးပါ၊ proxy ၏ ဝင်ရောက်ခွင့်နှင့် စစ်မှန်ကြောင်းအတည်ပြု မူဝါဒကို ကျင့်သုံးပါ၊ upstream ချိတ်ဆက်မှုကို တည်ဆောက်ပါ။ CONNECT သည် service.example:443 ကဲ့သို့ အာဏာပိုင်ကို ခွဲခြားသည်။ ကော်လံတိုင်းတွင် မျက်စိကန်းစွာ ခွဲမည့်အစား IPv6 အာဏာပိုင်များကို စဉ်းစားပြီး ထိုပုံစံကို ခွဲခြမ်းပါ။
tunnel ကို လက်ခံပြီးပါက အောင်မြင်သော HTTP တုံ့ပြန်မှုနှင့် ၎င်းကို အဆုံးသတ်သည့် ဗလာလိုင်းကို ပို့ပါ။ ထို့နောက် client socket မှ နောက်ပိုင်း bytes များဖြင့် မဆက်မီ head bytes များကို upstream သို့ ပို့ပါ။ data listener အသစ် ချိတ်ဆက်ခြင်းဖြင့် handler သို့ သီးခြား ပေးအပ်ပြီးသော buffer ကို ပြန်လည်ရယူနိုင်မည် မဟုတ်ပါ။
Node ၏ တရားဝင် tunnel ဥပမာသည် stream ဦးတည်ချက် နှစ်ခုကို မချိတ်ဆက်မီ serverSocket.write(head) ဖြင့် ထို လွှဲပြောင်းမှုကို ပြုလုပ်သည်။ ၎င်း၏ ဥပမာငယ်သည် ကူးပြောင်းမှုကို ပြသသည်။ ဖြန့်ကျက်ထားသော proxy သည် ကန့်သတ်ထားသော ချိတ်ဆက်မှု ကြိုးစားမှုများ၊ ဝင်ရောက်ခွင့် ထိန်းချုပ်မှုများနှင့် သက်တမ်းစက်ဝန်း စီမံခန့်ခွဲမှုလည်း လိုအပ်သည်။
အောင်မြင်ပြီးနောက် bytes များသည် ဝန်ဆောင်မှု ပရိုတိုကောပိုင်
အောင်မြင်သော CONNECT တုံ့ပြန်မှုသည် ချိတ်ဆက်မှုကို byte stream အဖြစ် ပြောင်းလဲသည်။ ပစ်မှတ်သည် HTTPS ဆိုက်ဖြစ်ပါက ၎င်း၏ TLS ဖလှယ်မှုသည် ထို stream အတွင်း သွားလာသည်။ tunnel လုပ်ရုံဖြင့် proxy သည် အစားထိုး ဝဘ်ဆိုက် လက်မှတ် ထုတ်ပေးရန် မလိုအပ်ပါ။
CONNECT ကို လက်မခံမီ HTTP အမှားသည် ငြင်းပယ်ရသည့် အကြောင်းရင်းကို ရှင်းပြနိုင်သည်။ လက်ခံပြီးနောက် stream ထဲသို့ HTTP 500 ရေးခြင်းသည် tunnel ပရိုတိုကောထဲသို့ bytes ထိုးသွင်းမည်။ ယင်းအစား နောက်ပိုင်း မအောင်မြင်မှုများတွင် သင့်လျော်သော ချိတ်ဆက်မှုများကို အဆုံးသတ် သို့မဟုတ် ဖျက်ဆီးပါ။
ဦးတည်ချက် နှစ်ခုလုံးကို backpressure ကို သိနားလည်သော stream ကိုင်တွယ်မှု ဖြင့် ချိတ်ဆက်ပြီး end၊ error နှင့် close ဖြစ်ရပ်များက လုပ်ဖော်ကိုင်ဖက်ကို မည်သို့ အဆုံးသတ်သည်ကို ဆုံးဖြတ်ပါ။ ကနဦး head buffer ကို တူညီသော ပိုင်ဆိုင်မှု မော်ဒယ်၏ အစိတ်အပိုင်းအဖြစ် ထိန်းသိမ်းပါ။ ၎င်းသည် အပလီကေးရှင်း ဒေတာဖြစ်ပြီး လွှင့်ပစ်ရမည့် ပိုလျှံသော HTTP headers မဟုတ်ပါ။