ပရောက်စီပေါက်တစ်ခုက HTTP နှင့် SOCKS နှစ်မျိုးလုံးကို မည်သို့လက်ခံနိုင်သည်

ရောစပ်ထားသော ပရောက်စီနားထောင်သူသည် TCP ပေါက်တစ်ခုတည်းတွင် HTTP နှင့် SOCKS ကို လက်ခံနိုင်သည်၊ အကြောင်းမှာ ဆာဗာသည် ပထမဆုံး ပရိုတိုကောက်ဘိုက်များကို စစ်ဆေးသောကြောင့်ဖြစ်သည်။ ပေါက်နံပါတ်သည် ထိုဖော်ထုတ်မှုကို မလုပ်ဆောင်ပါ။

HTTP ပရောက်စီတောင်းခံမှုသည် GET သို့မဟုတ် CONNECT ကဲ့သို့သော HTTP နည်းလမ်းဖြင့် စတင်သည်။ SOCKS နှုတ်ခွန်းဆက်ခြင်းသည် ဒွိစုံပရိုတိုကောက်အကွက်များဖြင့် စတင်သည်။ ဤထည့်သွင်းမှုများအတွက် ဒီဇိုင်းဆွဲထားသော ဆော့ဖ်ဝဲသည် ချိတ်ဆက်မှုကို သင့်လျော်သော ကိုင်တွယ်သူထံ ပေးပို့နိုင်သည်။

ဤအရာသည် ရှင်းလင်းသော အကောင်အထည်ဖော်မှုအင်္ဂါရပ်ဖြစ်သည်။ သာမန် Squid HTTP နားထောင်သူသည် ၎င်း၏ပေါက်ကို 1080 သို့ ပြောင်းလိုက်ခြင်းကြောင့် ရောစပ်မဖြစ်သွားပါ၊ SOCKS သီးသန့် နားထောင်သူသည်လည်း ဘရောက်ဇာဆက်တင်မှ HTTP ကို မသင်ယူပါ။

TLS သည် နောက်ထပ်နယ်နိမိတ်တစ်ခုကို ပေါင်းထည့်သည်၊ ကုဒ်ဝှက်ထားသော ပရောက်စီချိတ်ဆက်မှုသည် မြင်နိုင်သော HTTP နည်းလမ်းဖြင့် မဟုတ်ဘဲ TLS ဖြင့် စတင်သည်။ တူညီသော အဆုံးမှတ်တွင် ၎င်းကို ပံ့ပိုးရန် ထပ်လောင်း ရည်ရွယ်ချက်ရှိရှိ ကိုင်တွယ်မှု လိုအပ်သည်၊ ရိုးရှင်းသော HTTP နှင့် SOCKS ကို အသိအမှတ်ပြုခြင်းသည် ထိုစွမ်းရည်ကို သက်သေမပြပါ။

အဆုံးမှတ်အတွက် မှတ်တမ်းတင်ထားသော ကလိုင်းပရိုတိုကောကို အသုံးပြုပါ။ နှစ်ခုလုံး အလုပ်လုပ်ပါက ၎င်းသည် ထိုဆာဗာ၏ ရောစပ်နားထောင်သူနှင့် ပတ်သက်သော သက်သေဖြစ်သည်၊ ကလိုင်းတိုင်းတွင် ပရိုတိုကောကို မသတ်မှတ်ဘဲ ထားရန် အကြောင်းမဟုတ်ပါ။

Glider ၏ ရောစပ်နားထောင်သူသည် ခိုင်မာသော ဥပမာတစ်ခု ပေးသည်၊ ၎င်းသည် ဘိုက်တစ်ခုကို မသုံးစွဲဘဲ ကြည့်ရှုကာ 0x05 ကို ၎င်း၏ SOCKS5 ကိုင်တွယ်သူထံ ပေးပို့ပြီး မဟုတ်ပါက ၎င်း၏ HTTP ခွဲခြမ်းစိတ်ဖြာသူကို ခေါ်သည်။ ထိုခွဲခြမ်းစိတ်ဖြာသူသည် ဝင်လာသောတောင်းခံမှုကို အလေးအနက် အတည်ပြုနေဆဲဖြစ်သည်၊ ပေးပို့သည့်ရွေးချယ်မှုသည် ထင်ရာစိုင်းသွင်းအားစုကို တရားဝင် HTTP မဖြစ်စေပါ။

TCP နားထောင်သူကို မျှဝေခြင်းသည် SOCKS5 UDP ဆက်စပ်မှုကို ၎င်းကိုယ်တိုင် မပေးပါ။ Glider သည် ၎င်း၏ UDP နားထောင်သူကို သီးခြား စတင်သည်။ TCP ပရိုတိုကောက်ရွေးချယ်မှုနှင့် နောက်ပိုင်း ဒေတာဂရမ် ထပ်ဆင့်ပို့ခြင်းသည် သီးခြားစွမ်းရည်များဖြစ်သည်။