SingLink 2.0 ပရိုတိုကော

SingLink 2.0 သည် SingLinkVPN က ကိုယ်တိုင် ဖန်တီးထားသော တရားဝင် ကွန်ရက် transport ပရိုတိုကော ဖြစ်ပါသည်။ “2.0” သည် ပရိုတိုကော၏ အမည်နှင့် မျိုးဆက်ကို ဖော်ပြခြင်းဖြစ်ပြီး SingLinkVPN client ဆော့ဖ်ဝဲဗားရှင်း မဟုတ်ပါ။

SingLink ပရိုတိုကောသည် traffic ကို VPN နုဒ်သို့ သယ်ဆောင်ရုံထက် ပိုလုပ်ဆောင်ပါသည်။ ၎င်းတွင် အကောင့်နှင့် နုဒ် ခွင့်ပြုချက်၊ DNS ကိုင်တွယ်ခြင်း၊ smart routing၊ encrypt လုပ်ထားသော session များ၊ TCP နှင့် UDP encapsulation၊ ချိတ်ဆက်မှု ကျန်းမာရေးစစ်ဆေးခြင်း၊ ကွန်ရက်ပြောင်းလဲမှုများနှင့် ပုံမှန်မဟုတ်မှုမှ ပြန်လည်ကောင်းမွန်ခြင်းတို့လည်း ပါဝင်ပါသည်။

SingLink တွင် လက်ရှိ production အဆင့် SingLink 2.0 ပရိုတိုကောနှင့် အမြန်နှုန်းကို ဦးစားပေးသော SingLink Beta preview ပရိုတိုကော ရှိပါသည်။ အတွင်းပိုင်း A/B စမ်းသပ်မှုများတွင် SingLink 2.0 သည် တည်ငြိမ်မှု 99.5% ရရှိခဲ့ပြီး Beta သည် အများဆုံး 97% ခန့်အထိ ရရှိခဲ့ပါသည်။ သင့်လျော်သော ကွန်ရက်နှင့် စက်ပစ္စည်း အခြေအနေများတွင် Beta ၏ အမြင့်ဆုံးအမြန်နှုန်းသည် 1 Gbps ကို ကျော်လွန်ခဲ့ပါသည်။

အဓိကဒေတာ နှိုင်းယှဉ်ချက်: Production SingLink 2.0 သည် သတ်မှတ်ထားသော စမ်းသပ်ပတ်ဝန်းကျင်တွင် တည်ငြိမ်မှု 99.5% ကို မှတ်တမ်းတင်ခဲ့ပါသည်။ Beta သည် အများဆုံး 97% ခန့် အထိ ရရှိခဲ့သော်လည်း သင့်လျော်သော ကွန်ရက်နှင့် စက်ပစ္စည်း အခြေအနေများတွင် အမြင့်ဆုံးအမြန်နှုန်း 1 Gbps ကို ကျော်လွန်ခဲ့ပါသည်။ ဤရလဒ်များသည် တည်ငြိမ်မှုနှင့် အမြန်နှုန်း ဦးစားပေးမှု ကွဲပြားခြင်းကို ကိုယ်စားပြုပြီး စက်ပစ္စည်း သို့မဟုတ် ကွန်ရက်တိုင်းအတွက် အာမခံချက် မဟုတ်ပါ။

အထောက်အထားနှင့် နည်းပညာ နယ်နိမိတ်: အတည်ပြုထားသော ထုတ်ကုန်နေရာချထားမှု၊ အတွင်းပိုင်းစမ်းသပ်မှု အဓိပ္ပာယ်ဖွင့်ဆိုချက်များနှင့် အများသိ လုပ်ဆောင်ချက်များကို တိုက်ရိုက် ကိုးကားနိုင်ပါသည်။ အောက်တွင် ဖော်ပြထားသော တိကျသည့် encryption algorithm များ၊ packet ပုံစံ၊ စွမ်းရည်ညှိနှိုင်းမှု၊ Session၊ Stream၊ multiplexing နှင့် session ပြန်လည်ရယူမှု အသေးစိတ်များသည် ကိုးကားရန် လုပ်ဆောင်ပုံ မော်ဒယ်တစ်ခုသာ ဖြစ်ပြီး လက်ရှိ အသုံးပြုနေသော သတ်မှတ်ချက်ကို ဖော်ပြခြင်း မဟုတ်ပါ။ အနာဂတ်တွင် ထုတ်ပြန်မည့် တရားဝင် SingLink နည်းပညာစာတမ်းများနှင့် ထုတ်ပြန်ထားသော source code တို့ကသာ အတည်ဖြစ်ပါသည်။

SingLink ပရိုတိုကော၏ လုပ်ဆောင်ပုံ မူများ အပြည့်အစုံ

စနစ်တစ်ခုလုံးကို လမ်းကြောင်း နှစ်ခု ခွဲခြားနိုင်ပါသည်:

ထိန်းချုပ်ရေး plane (Control plane)

တာဝန်ယူသည်များ:

• အကောင့်သို့ ဝင်ရောက်ခြင်း;
• အသင်းဝင်ဖြစ်မှုကို အတည်ပြုခြင်း;
• နုဒ်များ ရယူခြင်း;
• နုဒ် အသုံးပြုခွင့်များ သတ်မှတ်ခြင်း;
• ပရိုတိုကော configuration ပေးပို့ခြင်း;
• စည်းမျဉ်းများ အပ်ဒိတ်လုပ်ခြင်း;
• Beta သို့မဟုတ် 2.0 ကို ရွေးချယ်ခြင်း။

ဒေတာ plane (Data plane)

တာဝန်ယူသည်များ:

• အက်ပ် traffic ကို လက်ခံခြင်း;
• DNS ကို resolve လုပ်ခြင်း;
• လုံခြုံသော ချိတ်ဆက်မှု တည်ဆောက်ခြင်း;
• TCP နှင့် UDP ကို encapsulate လုပ်၍ သယ်ဆောင်ခြင်း;
• ချိတ်ဆက်မှုကို ဆက်လက်ရှင်သန်အောင် ထိန်းထားခြင်း;
• ချိတ်ဆက်မှု ပြတ်တောက်ခြင်းကို ကိုင်တွယ်ခြင်း;
• ဒေတာကို အက်ပ်ထံ ပြန်ပို့ခြင်း။

ရိုးရှင်းအောင် ပြုလုပ်ထားသော လုပ်ငန်းစဉ်မှာ:

အသုံးပြုသူက SingLinkVPN သို့ ဝင်ရောက်သည်
        ↓
ခွင့်ပြုထားသော နုဒ်များနှင့် ပရိုတိုကော configuration ကို ရယူသည်
        ↓
Client က TUN / system proxy ကို ဖန်တီးသည်
        ↓
အက်ပ် traffic ကို လက်ခံသည်
        ↓
DNS နှင့် routing စည်းမျဉ်းများကို အကဲဖြတ်သည်
        ↓
SingLink 2.0 သို့မဟုတ် Beta နုဒ်ကို ရွေးချယ်သည်
        ↓
ပရိုတိုကော စွမ်းရည်များကို ညှိနှိုင်းသည်
        ↓
အကောင့်နှင့် စက်ပစ္စည်း အသုံးပြုခွင့်ကို အတည်ပြုသည်
        ↓
Encrypted session နှင့် session key များ ဖန်တီးသည်
        ↓
အက်ပ်ချိတ်ဆက်မှုတိုင်းအတွက် သီးခြား logical stream ဖန်တီးသည်
        ↓
TCP / UDP ဒေတာကို encapsulate လုပ်သည်
        ↓
ဒေတာကို SingLink နုဒ်သို့ ပို့သည်
        ↓
နုဒ်က decapsulate လုပ်ပြီး ဦးတည်ရာ ဝဘ်ဆိုက်ကို ဝင်ရောက်သည်
        ↓
ဒေတာကို ပြန်ပို့ပြီး မူလအက်ပ်ထံ ပေးအပ်သည်
        ↓
Latency၊ packet ပျောက်ဆုံးမှုနှင့် ချိတ်ဆက်မှုအခြေအနေကို အဆက်မပြတ် တိုင်းတာသည်
        ↓
ပုံမှန်မဟုတ်မှုနောက် ပြန်ချိတ်ဆက်၊ ပြန်လည်ရယူ သို့မဟုတ် နုဒ်ပြောင်းသည်

---

အဆင့် 1: ဝင်ရောက်ခြင်း၊ နုဒ်ရယူခြင်းနှင့် ပရိုတိုကော configuration

အသုံးပြုသူက SingLinkVPN ကို ဖွင့်ပြီး ဝင်ရောက်ပြီးနောက် client သည် production နုဒ်လိပ်စာ၊ credential နှင့် ပရိုတိုကော parameter အားလုံးကို စက်ပစ္စည်းပေါ်တွင် ချက်ချင်း အမြဲတမ်း သိမ်းဆည်းမထားသင့်ပါ။

ပိုမိုသင့်လျော်သော လုပ်ငန်းစဉ်မှာ:

1. Client က အကောင့် credential များကို တင်သွင်းသည်။
2. အကောင့်စနစ်က အသုံးပြုသူကို အတည်ပြုသည်။
3. စနစ်က အစီအစဉ်နှင့် နုဒ် အသုံးပြုခွင့်များကို အတည်ပြုသည်။
4. ထိုအသုံးပြုသူအတွက် ရရှိနိုင်သော နုဒ်များကို ပြန်ပေးသည်။
5. သက်တမ်းတို ချိတ်ဆက်မှု credential များကို ပြန်ပေးသည်။
6. လက်ရှိ ပရိုတိုကောဗားရှင်းနှင့် လိုအပ်သော configuration ကို ပြန်ပေးသည်။
7. Client က configuration ၏ မပျက်စီးမှုကို အတည်ပြုသည်။
8. အရေးကြီးသော configuration ကို ကာကွယ်ထားသော စနစ်သိုလှောင်ရာတွင် သိမ်းဆည်းသည်။

ဤအလွှာက အဓိကအားဖြင့် ဆုံးဖြတ်သည်များ:

• အသုံးပြုသူတွင် မှန်ကန်သော အသင်းဝင်ဖြစ်မှု ရှိ၊ မရှိ;
• Beta သို့မဟုတ် 2.0 ကို အသုံးပြုနိုင်ခြင်း ရှိ၊ မရှိ;
• အကောင့်တွင် Pro၊ Max သို့မဟုတ် Rich အသုံးပြုခွင့် ရှိ၊ မရှိ;
• မည်သည့် နိုင်ငံများနှင့် နုဒ်များ ရရှိနိုင်သည်;
• Configuration သက်တမ်း ကုန်ဆုံးပြီလား;
• Client ကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သလား။

လူတိုင်းနားလည်နိုင်သော ရှင်းလင်းချက်

၎င်းသည် အမြန်ရထား မစီးမီ စစ်ဆေးခြင်းနှင့် တူပါသည်:

• သင် မည်သူဖြစ်သည်;
• သင် မည်သည့် လက်မှတ်အတန်းကို ဝယ်ထားသည်;
• သင် မည်သည့် ခရီးစဉ်ကို စီးနိုင်သည်;
• လက်မှတ် သက်တမ်းရှိနေဆဲလား။

အကြံပြုထားသော လုံခြုံရေး စည်းမျဉ်းများ

SingLink သည် အမြဲတမ်း static စကားဝှက်တစ်ခုတည်းကို အကန့်အသတ်မရှိ အားမကိုးသင့်ပါ။

ပိုမိုသင့်လျော်သော ဒီဇိုင်းတွင် အသုံးပြုသည်များ:

• သက်တမ်းတို ချိတ်ဆက်မှု token;
• တစ်ကြိမ်သုံး challenge;
• စက်ပစ္စည်း nonce;
• သက်တမ်းကုန်ဆုံးမှု ကန့်သတ်ချက်;
• ဆာဗာက လက်မှတ်ထိုးထားသော နုဒ် configuration;
• ပြန်လည်ရုပ်သိမ်းနိုင်သော ယန္တရား။

ထိုသို့ဆိုလျှင် ချိတ်ဆက်မှု configuration တစ်ခု ရရှိခြင်းဖြင့် အမြဲတမ်း ဝင်ရောက်ခွင့် မရတော့ပါ။

---

အဆင့် 2: စနစ်၏ ကွန်ရက် ဝင်ပေါက်ကို တည်ဆောက်ခြင်း

အသုံးပြုသူက Connect ကို ရွေးချယ်သောအခါ SingLinkVPN သည် operating system ထဲတွင် ကွန်ရက်ဝင်ပေါက်တစ်ခုကို ဦးစွာ ဖန်တီးရန် လိုအပ်ပါသည်။

နည်းလမ်းမှာ ပလက်ဖောင်းအလိုက် ကွဲပြားပါသည်:

ပလက်ဖောင်း	အသုံးများသော ကွန်ရက်ဝင်ပေါက်
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension သို့မဟုတ် TUN
Windows	TUN virtual adapter နှင့် စနစ် routing
Linux	TUN၊ routing table နှင့် DNS စီမံခန့်ခွဲမှု

ဖန်တီးပြီးနောက် အက်ပ်များက ပုံမှန်အားဖြင့် ကွန်ရက်သို့ တိုက်ရိုက်ပို့မည့် ဒေတာများသည် SingLinkVPN client ထဲသို့ ဦးစွာ ဝင်ရောက်ပါသည်။

ဥပမာ:

ChatGPT အက်ပ်
    ↓
Operating system ကွန်ရက် stack
    ↓
SingLink TUN interface
    ↓
SingLinkVPN client

ဤအဆင့်တွင် client လုပ်ဆောင်ရန် လိုအပ်သည်များ:

• Virtual IP ဖန်တီးခြင်း;
• Routing table ကို ပြင်ဆင်သတ်မှတ်ခြင်း;
• DNS ကို ပြင်ဆင်သတ်မှတ်ခြင်း;
• ဒေသတွင်း ကွန်ရက် (LAN) ကို ဖယ်ထုတ်ခြင်း;
• Proxy ချိတ်ဆက်မှုကို TUN ထဲသို့ ပြန်လည် route မလုပ်မိစေရန် တားဆီးခြင်း;
• Kill Switch စည်းမျဉ်းများ ဖန်တီးခြင်း။

နောက်ဆုံးအချက်မှာ အရေးကြီးပါသည်။

Route ဖယ်ထုတ်မှု မရှိပါက SingLinkVPN က ၎င်း၏ နုဒ်သို့ရောက်ရန် အသုံးပြုသော traffic ကိုယ်တိုင် VPN ထဲသို့ ပြန်ဝင်ပြီး loop ဖြစ်စေနိုင်ပါသည်:

VPN traffic
↓
VPN ထဲသို့ ပြန်ဝင်သည်
↓
ထပ်မံ encapsulate လုပ်ခံရသည်
↓
အဆုံးမရှိ loop

ထို့ကြောင့် client သည် အောက်ပါတို့ကို ရှင်းလင်းစွာ ဖယ်ထုတ်ရပါမည်:

• နုဒ်၏ ကိုယ်ပိုင် IP;
• လိုအပ်သော ထိန်းချုပ်ရေး interface များ;
• ဒေသတွင်း gateway;
• စနစ်က တိုက်ရိုက် ရောက်ရှိရမည့် ဝန်ဆောင်မှုများ။

---

အဆင့် 3: DNS resolve လုပ်ခြင်းနှင့် domain အကဲဖြတ်ခြင်း

အသုံးပြုသူက chatgpt.com ကို ဖွင့်သောအခါ စက်ပစ္စည်းသည် ပုံမှန်အားဖြင့် domain ကို IP လိပ်စာသို့ ဦးစွာ resolve လုပ်ရပါသည်။

DNS ကို မှားယွင်းစွာ ကိုင်တွယ်ပါက အောက်ပါတို့ ဖြစ်ပေါ်နိုင်ပါသည်:

• DNS request များသည် ဒေသတွင်းကွန်ရက်ပေါ်တွင် တိုက်ရိုက် သွားလာခြင်း;
• ဒေသတွင်း DNS resolver က မှားယွင်းသော လိပ်စာကို ပြန်ပေးခြင်း;
• စည်းမျဉ်းများသည် မူလ domain အချက်အလက်ကို ဆုံးရှုံးခြင်း;
• IPv6 traffic သည် VPN ကို ကျော်ဖြတ်သွားခြင်း;
• VPN ချိတ်ဆက်ထားသလို ပေါ်နေချိန်တွင်ပင် DNS ယိုစိမ့်ခြင်း။

SingLink client သည် ဤလုပ်ငန်းစဉ်ကို အသုံးပြုနိုင်ပါသည်:

အက်ပ်က DNS request ပို့သည်
        ↓
Client က DNS ကို ကြားဖြတ်ယူသည်
        ↓
Domain စည်းမျဉ်းများကို အကဲဖြတ်သည်
        ↓
ဒေသတွင်း DNS သို့မဟုတ် ကာကွယ်ထားသော အဝေး DNS ကို ရွေးသည်
        ↓
IPv4 / IPv6 ရလဒ်ကို ရယူသည်
        ↓
Domain ကို IP နှင့် ချိတ်ဆက်မှတ်သားသည်
        ↓
Direct၊ proxy သို့မဟုတ် block ကို ရွေးသည်

ဒေသတွင်း domain များ

ဒေသတွင်း ဘဏ်များ၊ LAN စက်ပစ္စည်းများ သို့မဟုတ် ဒေသဆိုင်ရာ ဝန်ဆောင်မှုများသည် ဒေသတွင်း DNS ကို အသုံးပြုပြီး တိုက်ရိုက် ချိတ်ဆက်နိုင်ပါသည်။

Proxy ဖြင့်သွားသော domain များ

VPN မှတစ်ဆင့် ဝင်ရောက်ရမည့် domain များကို proxy နုဒ် သို့မဟုတ် ကာကွယ်ထားသော DNS resolver မှတစ်ဆင့် resolve လုပ်နိုင်ပါသည်။

လူတိုင်းနားလည်နိုင်သော ရှင်းလင်းချက်

DNS သည် လိပ်စာတစ်ခုကို ရှာဖွေခြင်းနှင့် တူပါသည်။

ထိုရှာဖွေမှုသည် ဒေသတွင်းလမ်းကို ဆက်သုံးနေပါက နောက်ဆက်တွဲ ဒေတာများ VPN ကို အသုံးပြုနေသော်လည်း မည်သည့် ဝဘ်ဆိုက်ကို တောင်းဆိုနေသည်ကို ထုတ်ဖော်ပြသနိုင်ပါသည်။

ထို့ကြောင့် SingLink ပရိုတိုကောစနစ်သည် အောက်ပါတို့ကို သတ်မှတ်သင့်ပါသည်:

• Client က DNS ကို ကြားဖြတ်ယူခြင်း ရှိ၊ မရှိ;
• မည်သည့် DNS request များ တိုက်ရိုက်သွားမည်;
• မည်သည့် DNS request များ VPN ကို အသုံးပြုမည်;
• IPv4 နှင့် IPv6 ကို မည်သို့ ကိုင်တွယ်မည်;
• DNS ရလဒ်များကို မည်မျှကြာ cache လုပ်မည်;
• ကွန်ရက်ပြောင်းလဲပြီးနောက် ဟောင်းနေသော DNS ရလဒ်များကို ရှင်းလင်းမည် မရှင်းလင်းမည်။

---

အဆင့် 4: Smart routing နှင့် route ဆုံးဖြတ်ချက်များ

DNS နှင့် အက်ပ် traffic များ client ထဲသို့ ဝင်ရောက်ပြီးနောက် စနစ်က ၎င်းတို့ကို မည်သို့ ကိုင်တွယ်မည်ကို ဆုံးဖြတ်ရပါမည်။

ပုံမှန်အားဖြင့် ရလဒ် သုံးမျိုး ရှိပါသည်:

Direct (တိုက်ရိုက်)
Proxy
Block (ပိတ်ဆို့)

Direct (တိုက်ရိုက်)

Traffic သည် ဒေသတွင်းကွန်ရက်ကို အသုံးပြုပြီး SingLink tunnel ထဲသို့ မဝင်ပါ။

သင့်တော်သည်များ:

• LAN စက်ပစ္စည်းများ;
• ဒေသတွင်း ဝဘ်ဆိုက်များ;
• Proxy မလိုအပ်သော အက်ပ်များ;
• အသုံးပြုသူ သတ်မှတ်ထားသော ခွင့်ပြုစာရင်းများ။

Proxy

Traffic သည် SingLink ပရိုတိုကော ထဲသို့ ဝင်ရောက်ပြီး နုဒ်မှတစ်ဆင့် ဆက်လက်ပို့ဆောင်ပါသည်။

သင့်တော်သည်များ:

• ပြည်ပ ဝဘ်ဆိုက်များ;
• AI ကိရိယာများ;
• နိုင်ငံတကာ လူမှုကွန်ရက် ပလက်ဖောင်းများ;
• အသုံးပြုသူ ရွေးချယ်ထားသော အက်ပ်များ။

Block (ပိတ်ဆို့)

ချိတ်ဆက်မှုကို ငြင်းပယ်ပါသည်။

သင့်တော်သည်များ:

• ကြော်ငြာ domain များ;
• ခြေရာခံ (tracking) domain များ;
• အန္တရာယ်ရှိသော လိပ်စာများ;
• အသုံးပြုသူ သတ်မှတ်ထားသော ပိတ်ဆို့စာရင်းများ။

ဆုံးဖြတ်ချက်တွင် ထည့်သွင်းစဉ်းစားနိုင်သည်များ:

• Domain;
• IP လိပ်စာ;
• Port;
• အက်ပ်;
• ပထဝီဝင် တည်နေရာ;
• ပရိုတိုကော အမျိုးအစား;
• အသုံးပြုသူ စည်းမျဉ်းများ;
• Global သို့မဟုတ် rule မုဒ်။

လူတိုင်းနားလည်နိုင်သော ရှင်းလင်းချက်

ဤအဆင့်သည် ယာဉ်ကြောလမ်းညွှန်ခြင်းနှင့် ဆင်တူပါသည်:

• ဒေသတွင်း ယာဉ်များသည် သာမန်လမ်းများကို သုံးသည်;
• ပြည်ပသွား ယာဉ်များသည် encrypt လုပ်ထားသော အမြန်လမ်းမကြီးထဲ ဝင်သည်;
• အန္တရာယ်ရှိသော ယာဉ်များကို ဝင်ခွင့် ငြင်းပယ်သည်။

---

အဆင့် 5: နုဒ်နှင့် ပရိုတိုကော ရွေးချယ်ခြင်း

Traffic ကို proxy ဖြင့်သွားရမည်ဟု ခွဲခြားသိရှိပြီးသည်နှင့် client က နုဒ်တစ်ခုကို ရွေးချယ်ရပါမည်။

ရွေးချယ်မှုသည် နိုင်ငံအမည်တစ်ခုတည်းကိုသာ အားကိုး၍ မရပါ။ အောက်ပါတို့ကိုလည်း ထည့်သွင်းစဉ်းစားရပါမည်:

• အသုံးပြုသူ၏ အစီအစဉ်;
• နုဒ်က 2.0 သို့မဟုတ် Beta ကို အသုံးပြုသည်;
• နုဒ် အွန်လိုင်းဖြစ်နေသလား;
• Latency;
• Packet ပျောက်ဆုံးမှု;
• ဝန်အား;
• နုဒ်၏ အကွာအဝေး;
• ဒေသတွင်း ကွန်ရက်ဝန်ဆောင်မှုပေးသူ;
• ဦးတည်ရာ တည်နေရာ;
• UDP ပံ့ပိုးမှု;
• Client တွဲသုံးနိုင်မှု။

ကိုယ်တိုင် ရွေးချယ်ခြင်း

အသုံးပြုသူက ဂျပန်၊ အမေရိကန်၊ စင်ကာပူ သို့မဟုတ် အခြားတည်နေရာရှိ နုဒ်တစ်ခုကို ရွေးချယ်ပါသည်။

Smart ရွေးချယ်ခြင်း

Client က စမ်းသပ်ရလဒ်များမှ သင့်လျော်သော နုဒ်ကို ရွေးချယ်ပါသည်။

Smart ရွေးချယ်ခြင်းသည် latency အနိမ့်ဆုံး နုဒ်ကို ရိုးရိုးရှင်းရှင်း မရွေးသင့်ပါ။

ဥပမာ:

နုဒ်	Latency	ပျောက်ဆုံးမှု	ဝန်အား
A	50 ms	8%	90%
B	70 ms	0%	30%

A တွင် latency ပိုနိမ့်သော်လည်း ၎င်း၏ packet ပျောက်ဆုံးမှုနှင့် ဝန်အား မြင့်မားပါသည်။ လက်တွေ့အသုံးပြုရာတွင် B က ပိုတည်ငြိမ်နိုင်ပါသည်။

ထို့ကြောင့် Smart ရွေးချယ်ခြင်းသည် အောက်ပါတို့ကို ပေါင်းစပ်သင့်ပါသည်:

Latency + packet ပျောက်ဆုံးမှု + ချိတ်ဆက်မှု အောင်မြင်နှုန်း + ဝန်အား + ယခင် စွမ်းဆောင်ရည်

---

အဆင့် 6: ပရိုတိုကော စွမ်းရည် ညှိနှိုင်းခြင်း

Client က နုဒ်သို့ ရောက်ရှိပြီးနောက် နှစ်ဖက်စလုံး တူညီသော လုပ်ဆောင်ချက်များကို ပံ့ပိုးသည်ဟု ချက်ချင်း မယူဆသင့်ပါ။

စွမ်းရည်များကို ဦးစွာ ညှိနှိုင်းရန် လိုအပ်ပါသည်။

ညှိနှိုင်းနိုင်သော အချက်များတွင် ပါဝင်နိုင်သည်များ:

• SingLink ဗားရှင်း;
• Beta သို့မဟုတ် 2.0;
• TCP ပံ့ပိုးမှု;
• UDP ပံ့ပိုးမှု;
• IPv4 / IPv6;
• Session ပြန်လည်စတင်ခြင်း ပံ့ပိုးမှု;
• Multiplexing ပံ့ပိုးမှု;
• ဒေတာ frame အရွယ်အစား အများဆုံး;
• Padding မဟာဗျူဟာ;
• Heartbeat ကြားကာလ;
• Compression ဖွင့်ထားခြင်း ရှိ၊ မရှိ;
• MTU အရွယ်အစား;
• ပြန်လည်ညှိနှိုင်းခြင်း ပံ့ပိုးမှု။

ဥပမာ:

Client:
ကျွန်ုပ်သည် SingLink 2.0 ကို ပံ့ပိုးသည်
ကျွန်ုပ်သည် TCP၊ UDP နှင့် IPv6 ကို ပံ့ပိုးသည်
ကျွန်ုပ်သည် Session Resume ကို ပံ့ပိုးသည်
အများဆုံး frame: 64 KB

Server:
SingLink 2.0 ကို အသုံးပြုရန် အတည်ပြုသည်
TCP နှင့် UDP အသုံးပြုနိုင်သည်
Session Resume အသုံးပြုနိုင်သည်
ထိရောက်သော အများဆုံး frame: 32 KB

နောက်ဆုံးတွင် နှစ်ဖက်စလုံးသည် နှစ်ဦးနှစ်ဖက် ပံ့ပိုးသော စွမ်းရည်များကိုသာ အသုံးပြုပါသည်။

ညှိနှိုင်းခြင်း ဘာကြောင့် လိုအပ်သနည်း?

Client များနှင့် နုဒ်များကို တစ်နေ့တည်းတွင် အပ်ဒိတ်လုပ်ချင်မှ လုပ်နိုင်ပါသည်။

Client အသစ်က နုဒ်ဟောင်း မမှတ်သိနိုင်သော ပုံစံကို ပို့ပါက ချိတ်ဆက်မှု မအောင်မြင်ပါ။

Production 2.0 သည် Beta ထက် အောက်ပါတို့ကို ပိုမို အလေးပေးသင့်ပါသည်:

• ယခင်ဗားရှင်းများနှင့် တွဲသုံးနိုင်မှု;
• ဗားရှင်း fallback;
• လုပ်ဆောင်ချက်တစ်ခု မရရှိနိုင်သောအခါ လုံခြုံစွာ အဆင့်လျှော့ချခြင်း;
• တွဲသုံး၍မရသော ဗားရှင်းများကို ရှင်းလင်းစွာ ငြင်းပယ်ခြင်း။

---

အဆင့် 7: ကိုယ်ပိုင်အထောက်အထား စစ်ဆေးခြင်း

အခြေခံချိတ်ဆက်မှု တည်ဆောက်ပြီးနောက် နုဒ်က အသုံးပြုသူသည် ခွင့်ပြုချက်ရှိကြောင်း အတည်ပြုရန် လိုအပ်ပါသည်။

အကြံပြုထားသော အတည်ပြုဒေတာတွင် ပါဝင်သည်များ:

• သက်တမ်းတို token;
• အကောင့် သို့မဟုတ် ခွင့်ပြုချက် ID;
• Client nonce;
• ပရိုတိုကော ဗားရှင်း;
• နုဒ် ID;
• တောင်းဆိုထားသော စွမ်းရည်များ;
• မပျက်စီးမှု အတည်ပြုဒေတာ။

ရိုးရှင်းအောင် ပြုလုပ်ထားသော authentication packet တစ်ခုက ပြောသည်မှာ:

ကျွန်ုပ် မည်သူဖြစ်သည်
ကျွန်ုပ် မည်သည့်နုဒ်ကို လိုချင်သည်
ကျွန်ုပ် မည်သည့်ပရိုတိုကောကို လိုချင်သည်
ဤချိတ်ဆက်မှုအတွက် ကျပန်း identifier
ကျွန်ုပ်၏ ခွင့်ပြုချက် မည်သည့်အချိန် သက်တမ်းကုန်မည်
ဒေတာကို ပြုပြင်ပြောင်းလဲခံရခြင်း ရှိ၊ မရှိ

ဆာဗာက စစ်ဆေးရန် လိုအပ်သည်များ:

1. Token ကို တရားဝင် ထုတ်ပေးခဲ့သလား;
2. Token သက်တမ်း ကုန်ဆုံးပြီလား;
3. Token ကို ရုပ်သိမ်းထားပြီလား;
4. နုဒ် ဝင်ရောက်ခွင့် အသုံးပြုသူတွင် ရှိသလား;
5. Nonce ကို ယခင်က အသုံးပြုခဲ့ဖူးသလား;
6. Request သည် replay ဖြစ်နေသလား;
7. ဤ client ဗားရှင်းကို ချိတ်ဆက်ခွင့်ပြုသလား။

Replay ကာကွယ်ရေး

တိုက်ခိုက်သူတစ်ဦးသည် မှန်ကန်သော authentication ဒေတာကို မှတ်တမ်းတင်ပြီး မပြောင်းလဲဘဲ ထပ်မံ ပို့နိုင်ပါသည်။

ထို့ကြောင့် authentication ဒေတာတွင် လိုအပ်သည်များ:

• တစ်ကြိမ်သုံး nonce;
• ဆာဗာ challenge;
• သက်တမ်းတို ကာလ;
• အသုံးပြုပြီးသော credential မှတ်တမ်း;
• Session နှင့် ချိတ်တွဲခြင်း။

ရိုးရိုးရှင်းရှင်း ပြောရလျှင်:

စစ်ဆေးအတည်ပြုပြီးသား လက်မှတ်ကို ကူးယူ၍ အကန့်အသတ်မရှိ ပြန်သုံး၍ မရပါ။

---

အဆင့် 8: Key ဖလှယ်ခြင်းနှင့် encrypted session

ကိုယ်ပိုင်အထောက်အထား စစ်ဆေးမှု အောင်မြင်ပြီးနောက် client နှင့် နုဒ်သည် ဤချိတ်ဆက်မှုအတွက် သီးသန့် session key များ လိုအပ်ပါသည်။

အကြံပြုထားသော logic မှာ:

Client က ephemeral key တစ်ခု ဖန်တီးသည်
        ↓
Server က ephemeral key တစ်ခု ဖန်တီးသည်
        ↓
နှစ်ဖက်စလုံး public ဒေတာကို ဖလှယ်သည်
        ↓
တစ်ဖက်စီက တူညီသော shared secret ကို သီးခြားစီ တွက်ချက်သည်
        ↓
ထို shared secret မှ session key များစွာကို ထုတ်ယူသည်

အောက်ပါတို့အတွက် သီးခြား key များကို ထုတ်ယူသင့်ပါသည်:

• Client မှ server သို့ encryption;
• Server မှ client သို့ encryption;
• ဒေတာ မပျက်စီးမှု;
• Session ပြန်လည်ရယူခြင်း;
• Header ကာကွယ်ခြင်း။

ဦးတည်ချက်နှင့် ရည်ရွယ်ချက် အားလုံးသည် key တစ်ခုတည်းကို မျှဝေမသုံးသင့်ပါ။

Forward secrecy

ပိုမိုသင့်လျော်သော ဒီဇိုင်းသည် session တိုင်းအတွက် ephemeral key များကို အသုံးပြုပါသည်။

ကာလရှည် ဆာဗာ key တစ်ခု နောက်ပိုင်းတွင် ပေါက်ကြားသွားပါက ယခင်က မှတ်တမ်းတင်ထားသော ချိတ်ဆက်မှုအားလုံးကို တိုက်ရိုက် decrypt လုပ်နိုင်ခြင်း မရှိသင့်ပါ။

Key လှည့်ပြောင်းခြင်း

ကြာရှည်စွာ လည်ပတ်နေသော ချိတ်ဆက်မှုသည် session key တစ်စုတည်းကို အမြဲတမ်း မသုံးသင့်ပါ။

Key များကို အောက်ပါတို့အလိုက်

• လွှဲပြောင်းခဲ့သော ဒေတာပမာဏ;
• ချိတ်ဆက်မှု ကြာချိန်;
• Frame အရေအတွက်;
• ဆာဗာ ညွှန်ကြားချက်။

ပြန်လည်ထုတ်ယူနိုင်ပါသည်။

ဥပမာ:

သတ်မှတ်ထားသော GB ပမာဏ ပြီးနောက်
သို့မဟုတ်
သတ်မှတ်ထားသော ကာလ ပြီးနောက်
ဦးတည်ချက်အလိုက် key အသစ်များကို ထုတ်ယူသည်

တိကျသော တန်ဖိုးများကို အင်ဂျင်နီယာ စွမ်းဆောင်ရည်နှင့် လုံခြုံရေးစမ်းသပ်မှုများဖြင့် သတ်မှတ်သင့်ပြီး ကြော်ငြာဆောင်းပါးတစ်ပုဒ်တွင် တီထွင်ဖော်ပြခြင်း မပြုသင့်ပါ။

---

အဆင့် 9: Session ဖန်တီးခြင်း

ကိုယ်ပိုင်အထောက်အထားနှင့် key များ တည်ဆောက်ပြီးနောက် နှစ်ဖက်စလုံးက SingLink Session တစ်ခုကို ဖန်တီးပါသည်။

Session တစ်ခုတွင် ပါဝင်နိုင်သည်များ:

• Session ID;
• ပရိုတိုကော ဗားရှင်း;
• Encryption parameter များ;
• အများဆုံး frame အရွယ်အစား;
• Heartbeat ကြားကာလ;
• UDP မုဒ်;
• Stream ကန့်သတ်ချက်;
• Idle timeout;
• Session ပြန်လည်ရယူနိုင်စွမ်း;
• Beta သို့မဟုတ် 2.0 မူဝါဒ။

ဆာဗာက အတည်ပြုချက်ကို ပြန်ပို့ပါသည်:

ကိုယ်ပိုင်အထောက်အထား အတည်ပြုပြီး
Session တည်ဆောက်ပြီး
SingLink 2.0 ကို အသုံးပြုနေသည်
TCP အသုံးပြုနိုင်သည်
UDP အသုံးပြုနိုင်သည်
Multiplexing အသုံးပြုနိုင်သည်
Heartbeat ဖွင့်ထားသည်

Client သည် ဆာဗာ၏ အတည်ပြုချက်ကို လက်ခံရရှိပြီးမှသာ အက်ပ်ဒေတာကို ပို့သင့်ပါသည်။

---

အဆင့် 10: Stream သို့မဟုတ် သီးခြား proxy ချိတ်ဆက်မှု ဖန်တီးခြင်း

SingLink က အမှန်တကယ် မည်သည့် ဗိသုကာကို အသုံးပြုသည်ကို သတ်မှတ်ရန် အင်ဂျင်နီယာဆိုင်ရာ အတည်ပြုချက် လိုအပ်ပါသည်။

ရွေးချယ်မှု 1: Session တစ်ခုက Stream များစွာကို သယ်ဆောင်သည်

ဤနည်းသည် AnyTLS ၏ ချဉ်းကပ်ပုံနှင့် ဆင်တူပါသည်:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Browser

Stream တစ်ခုစီတွင် လိုအပ်သည်များ:

• Stream ID;
• ဦးတည်ရာ လိပ်စာ;
• ဦးတည်ရာ port;
• TCP သို့မဟုတ် UDP;
• လက်ရှိ အခြေအနေ;
• ပို့ရေး window;
• လက်ခံရေး window။

အကျိုးကျေးဇူးများ:

• ထပ်ခါထပ်ခါ handshake လုပ်ရမှု နည်းခြင်း;
• ချိတ်ဆက်မှု latency နိမ့်ခြင်း;
• အောက်ခံ ချိတ်ဆက်မှု နည်းခြင်း;
• ချိတ်ဆက်မှုတို အများအပြားကို ထိရောက်စွာ ကိုင်တွယ်နိုင်ခြင်း။

အန္တရာယ်များ:

• Session တစ်ခု ပျက်ပါက Stream များစွာကို ထိခိုက်နိုင်သည်;
• အောက်ခံ TCP ချိတ်ဆက်မှုတစ်ခုက head-of-line blocking ဖြစ်စေနိုင်သည်;
• ပြည့်စုံသော flow control လိုအပ်သည်။

ရွေးချယ်မှု 2: အက်ပ် request တိုင်းက သီးခြား ချိတ်ဆက်မှုတစ်ခု ဖန်တီးသည်

ChatGPT → သီးခြား ချိတ်ဆက်မှု
YouTube → သီးခြား ချိတ်ဆက်မှု
Telegram → သီးခြား ချိတ်ဆက်မှု

အကျိုးကျေးဇူးများ:

• မတူညီသော traffic များကို ခွဲခြားထားသည်;
• ချိတ်ဆက်မှုတစ်ခု ပျက်ခြင်းက အခြားများကို မထိခိုက်;
• Logic ပိုရိုးရှင်းသည်။

အားနည်းချက်များ:

• Handshake ပိုများသည်;
• ချိတ်ဆက်မှု overhead ပိုကြီးသည်;
• ချိတ်ဆက်မှုတို အများအပြားအတွက် ထိရောက်မှု နိမ့်သည်။

အကြံပြုချက်

SingLink သည် ပေါင်းစပ်မုဒ်ကို အသုံးပြုနိုင်ပါသည်:

• ချိတ်ဆက်မှုတိုများနှင့် သာမန် ဝဘ် traffic ကို Session တစ်ခုပေါ်တွင် multiplex လုပ်ခြင်း;
• ဒေါင်းလုဒ်ကြီးများနှင့် ဗီဒီယိုအတွက် သီးခြား channel များ ဖန်တီးခြင်း;
• Latency နိမ့်သော UDP ကို သီးခြား ကိုင်တွယ်ခြင်း;
• အမြန်နှုန်းမြင့် ဒေါင်းလုဒ်တစ်ခုက Stream အားလုံးကို မစားသုံးစေရန် တားဆီးခြင်း။

---

အဆင့် 11: ဒေတာ frame encapsulation

အက်ပ်ဒေတာကို transport channel ထဲသို့ မပြောင်းလဲဘဲ တိုက်ရိုက် ထည့်၍ မရပါ။ ၎င်းကို ပရိုတိုကော frame များအဖြစ် encapsulate လုပ်ရန် လိုအပ်ပါသည်။

သဘောတရားအရ SingLink frame တစ်ခုတွင် ပါဝင်နိုင်သည်များ:

Version
Frame အမျိုးအစား
Session ID
Stream ID
Sequence number
Flags
ဒေတာ အရှည်
Encrypt လုပ်ထားသော ဒေတာ
မပျက်စီးမှု tag

ဖြစ်နိုင်သော frame အမျိုးအစားများ:

Frame အမျိုးအစား	ရည်ရွယ်ချက်
OPEN	Stream အသစ် ဖန်တီးရန်
DATA	ဒေတာ သယ်ဆောင်ရန်
ACK	အခြေအနေ အတည်ပြုရန်
FIN	ပုံမှန်အတိုင်း ပိတ်ရန်
RESET	ပုံမှန်မဟုတ်စွာ ရပ်တန့်ရန်
PING	ကျန်းမာရေး စစ်ဆေးမှု
PONG	ကျန်းမာရေး စစ်ဆေးမှု တုံ့ပြန်ချက်
UDP	UDP datagram သယ်ဆောင်ရန်
SETTINGS	Session parameter များ အပ်ဒိတ်လုပ်ရန်
KEY_UPDATE	Session key များ လှည့်ပြောင်းရန်
RESUME	Session ပြန်လည်ရယူရန်

ဤသည်မှာ ပရိုတိုကော ဒီဇိုင်း အကြံပြုချက်သာ ဖြစ်ပါသည်။ SingLink က ဤအမည်များ သို့မဟုတ် bit ပုံစံများကို လက်ရှိ အသုံးပြုနေသည်ဟု မဖော်ပြပါ။

---

အဆင့် 12: TCP traffic ကိုင်တွယ်ခြင်း

ဝဘ်ဆိုက်များ၊ API များနှင့် ဖိုင်ဒေါင်းလုဒ်များကဲ့သို့ TCP ချိတ်ဆက်မှုများအတွက် SingLink သည် အောက်ပါတို့ကို ထိန်းသိမ်းရန် လိုအပ်ပါသည်:

• ဒေတာ အစီအစဉ်;
• နှစ်ဖက်သွား လွှဲပြောင်းမှု;
• ပိတ်ခြင်း အခြေအနေ;
• Flow control;
• Error အခြေအနေ။

ပြည့်စုံသော လုပ်ငန်းစဉ်မှာ:

အက်ပ်က TCP ချိတ်ဆက်မှု ဖန်တီးသည်
        ↓
Client က SingLink Stream ဖန်တီးသည်
        ↓
ဦးတည်ရာ domain နှင့် port ကို ပို့သည်
        ↓
နုဒ်က ဦးတည်ရာ ဝဘ်ဆိုက်သို့ ချိတ်ဆက်သည်
        ↓
နုဒ်က အောင်မြင်မှု သို့မဟုတ် မအောင်မြင်မှုကို အစီရင်ခံသည်
        ↓
နှစ်ဖက်သွား ဆက်လက်ပို့ဆောင်ခြင်း စတင်သည်

ပုံမှန် ပိတ်ခြင်း

အက်ပ်က ချိတ်ဆက်မှုကို အဆုံးသတ်သောအခါ:

1. Client က FIN ပို့သည်။
2. နုဒ်က ထိုဦးတည်ချက်ရှိ ဒေတာ လက်ခံခြင်းကို ရပ်သည်။
3. အခြားဦးတည်ချက် ပြီးဆုံးရန် စောင့်သည်။
4. Stream လုံးဝ ပိတ်သည်။
5. Memory နှင့် ချိတ်ဆက်မှု အခြေအနေကို လွှတ်ပေးသည်။

ပုံမှန်မဟုတ်သော ပိတ်ခြင်း

ဦးတည်ရာက ချိတ်ဆက်မှုကို ငြင်းပယ်ပါက:

1. နုဒ်က error ပြန်ပေးသည်။
2. Client က ချိတ်ဆက်မှု မအောင်မြင်ကြောင်း အက်ပ်ထံ အစီရင်ခံသည်။
3. Stream ကို ချက်ချင်း ရှင်းလင်းသည်။
4. အခြား Stream များ မထိခိုက်ပါ။

---

အဆင့် 13: UDP traffic ကိုင်တွယ်ခြင်း

UDP တွင် သမားရိုးကျ TCP ချိတ်ဆက်မှု မရှိပါ။ Datagram တစ်ခုစီသည် အောက်ပါတို့ကို ထိန်းသိမ်းရန် လိုအပ်ပါသည်:

• ရင်းမြစ် association;
• ဦးတည်ရာ လိပ်စာ;
• ဦးတည်ရာ port;
• ဒေတာ အရှည်;
• Datagram နယ်နိမိတ်;
• Association timeout။

ဥပမာ:

UDP Association ID
ဦးတည်ရာ လိပ်စာ
ဦးတည်ရာ port
ဒေတာ အရှည်
UDP Payload

SingLink သည် ဤချဉ်းကပ်နည်းများထဲမှ ရှင်းလင်းစွာ ရွေးချယ်ရန် လိုအပ်ပါသည်:

UDP over TCP

UDP datagram များကို TCP သို့မဟုတ် ယုံကြည်စိတ်ချရသော Session ထဲတွင် သယ်ဆောင်ပါသည်။

အကျိုးကျေးဇူးများ:

• TCP ကိုသာ ခွင့်ပြုသော ကွန်ရက်များကို ဖြတ်ကျော်ရ ပိုလွယ်သည်;
• ဒေတာ ပျောက်ဆုံးနိုင်ခြေ နည်းသည်;
• ဖြန့်ကျက်ရ ပိုရိုးရှင်းသည်။

အားနည်းချက်များ:

• TCP packet ပျောက်ဆုံးမှုက နောက်ဆက်တွဲ UDP ဒေတာကို ပိတ်ဆို့သည်;
• ဂိမ်းအချို့၊ အသံနှင့် real-time အသုံးပြုမှုများအတွက် မသင့်တော်ပါ။

မူလ UDP (Native UDP)

UDP က ဒေတာကို တိုက်ရိုက် သယ်ဆောင်ပါသည်။

အကျိုးကျေးဇူးများ:

• Latency နိမ့်သည်;
• ဂိမ်း၊ အသံနှင့် QUIC အတွက် သင့်တော်သည်;
• TCP head-of-line blocking ၏ သက်ရောက်မှု မရှိပါ။

အားနည်းချက်များ:

• ကွန်ရက်အချို့က UDP ကို ကန့်သတ်သည်;
• NAT နှင့် firewall ကိုင်တွယ်မှု ပိုရှုပ်ထွေးသည်။

QUIC ပုံစံ transport

၎င်းသည် UDP ကို အခြေခံသော်လည်း ပရိုတိုကောအလွှာတွင် အောက်ပါတို့ကို ပေးပါသည်:

• Encryption;
• ပြန်လည်ပို့လွှတ်ခြင်း (retransmission);
• Stream များစွာ;
• Congestion control;
• ကွန်ရက် ရွှေ့ပြောင်းမှု။

၎င်းသည် ပိုမိုပြည့်စုံသော နည်းပညာစွမ်းရည်များကို ပေးသော်လည်း အကောင်အထည်ဖော်ရ ပိုခက်ခဲပါသည်။

SingLink အတွက် သင့်လျော်သော ဦးတည်ချက်မှာ:

ကွန်ရက်နှင့် traffic အမျိုးအစားအလိုက် မူလ UDP၊ ယုံကြည်စိတ်ချရသော encapsulation သို့မဟုတ် အခြား တွဲသုံးနိုင်သော မုဒ်ကို အလိုအလျောက် ရွေးချယ်ခြင်း။

ဤအရာကို အကောင်အထည်ဖော်ထားခြင်း ရှိ၊ မရှိ အတည်ပြုရန် လိုအပ်ပါသည်။

---

အဆင့် 14: Flow control နှင့် backpressure

YouTube က မြန်မြန်ဆန်ဆန် ဒေါင်းလုဒ်လုပ်နေချိန်တွင် ChatGPT က စာသားအနည်းငယ်သာ လွှဲပြောင်းနေသည်ဟု ယူဆကြပါစို့။

Flow control မရှိပါက ဗီဒီယို Stream က channel ကို ပြည့်စေပြီး အောက်ပါတို့ ဖြစ်စေနိုင်ပါသည်:

• ChatGPT တုံ့ပြန်မှု နှေးကွေးခြင်း;
• DNS နှောင့်နှေးခြင်း;
• အက်ပ်များ ရပ်တန့်နေခြင်း;
• Memory အသုံးပြုမှု အဆက်မပြတ် တိုးလာခြင်း။

ထို့ကြောင့် flow control အဆင့် နှစ်ဆင့် လိုအပ်ပါသည်:

Session အဆင့်

Session တစ်ခုလုံးက အတည်မပြုရသေးသော ဒေတာ မည်မျှ သယ်ဆောင်နိုင်သည်ကို ကန့်သတ်ပါသည်။

Stream အဆင့်

Stream တစ်ခုစီက transport window ၏ မည်မျှကို နေရာယူနိုင်သည်ကို ကန့်သတ်ပါသည်။

ရိုးရိုးရှင်းရှင်း ပြောရလျှင်:

ကုန်တင်ကားကြီးတစ်စီးက အမြန်လမ်းမကြီး၏ လမ်းကြောင်းအားလုံးကို နေရာယူ၍ မရပါ။ Stream တစ်ခုစီသည် transport အရင်းအမြစ်များကို တရားမျှတစွာ ခွဲဝေရရှိရန် လိုအပ်ပါသည်။

Production 2.0 ပရိုတိုကောသည် အမြင့်ဆုံးအမြန်နှုန်းကို လိုက်စားခြင်းက အခြားချိတ်ဆက်မှုများကို မနှောင့်ယှက်စေရန် Beta ထက် ပိုမို သတိထားသော scheduling ကို အသုံးပြုနိုင်ပါသည်။

---

အဆင့် 15: ခွဲခြမ်းခြင်း၊ padding နှင့် traffic ပုံပန်းသဏ္ဌာန်

ဒေတာကို encrypt လုပ်ပြီးနောက်တွင်ပင် စောင့်ကြည့်သူတစ်ဦးသည် အောက်ပါတို့ကို မြင်နိုင်ဆဲ ဖြစ်ပါသည်:

• Packet အရှည်;
• ပို့လွှတ်သည့် ကြားကာလ;
• ချိတ်ဆက်မှု ကြာချိန်;
• အပ်လုဒ်/ဒေါင်းလုဒ် အချိုး;
• ပြန်လည်ချိတ်ဆက်မှု အပြုအမူ။

ထို့ကြောင့် ပရိုတိုကောသည် traffic ပုံပန်းသဏ္ဌာန်ကို ပြုပြင်နိုင်ပါသည်၊ ဥပမာ:

• ဒေတာကြီးကို frame များစွာအဖြစ် ခွဲခြမ်းခြင်း;
• ဒေတာငယ်များကို ပေါင်းစပ်ခြင်း;
• ပြောင်းလဲနိုင်သော Padding ထည့်ခြင်း;
• ပို့လွှတ်သည့် အစုများကို ချိန်ညှိခြင်း;
• ပုံသေ handshake အရှည်တစ်ခုတည်းကို ရှောင်ခြင်း;
• Padding မဟာဗျူဟာကို အခါအားလျော်စွာ အပ်ဒိတ်လုပ်ခြင်း။

သို့သော် ရှင်းလင်းစွာ သိထားရမည်မှာ:

Padding သည် encryption ကို အစားမထိုးနိုင်သလို traffic ကို အမြဲတမ်း ခွဲခြားမသိနိုင်အောင်လည်း အာမမခံနိုင်ပါ။

Padding အလွန်အကျွံ ထည့်ခြင်းကလည်း အောက်ပါတို့ကို ဖြစ်စေပါသည်:

• Traffic ပိုများခြင်း;
• Latency ပိုမြင့်ခြင်း;
• CPU အသုံးပြုမှု ပိုများခြင်း;
• အခမဲ့အစီအစဉ် ပမာဏကို ဖြုန်းတီးခြင်း။

ထို့ကြောင့် 2.0 profile သည် လိုက်လျောညီထွေ ပြောင်းလဲနိုင်ပါသည်:

• သာမန်ကွန်ရက်များတွင် overhead နည်းနည်းသာ အသုံးပြုခြင်း;
• အထူးကွန်ရက် ပတ်ဝန်းကျင်များတွင် ပုံပန်းသဏ္ဌာန် ကိုင်တွယ်မှုကို တိုးမြှင့်ခြင်း;
• အမြန်နှုန်းမြင့် ဒေါင်းလုဒ်များအတွင်း မလိုအပ်သော Padding ကို လျှော့ချခြင်း;
• ထိန်းချုပ်ရေး ဒေတာငယ်များတွင် သင့်လျော်သော padding ကို အသုံးပြုခြင်း။

Beta မူ အမြင့်ဆုံးအမြန်နှုန်းကို မြှင့်တင်ရန် အပို overhead ကို လျှော့ချနိုင်ပါသည်။

---

အဆင့် 16: MTU နှင့် packet အရွယ်အစား ကိုင်တွယ်ခြင်း

TUN traffic တွင် ပရိုတိုကော header များနှင့် encrypt လုပ်ထားသော ဒေတာကို ထပ်ပေါင်းခြင်းက packet အရွယ်အစားကို တိုးစေပါသည်။

ကွန်ရက် MTU ကို ကျော်လွန်ပါက အောက်ပါတို့ ဖြစ်စေနိုင်ပါသည်:

• IP fragmentation;
• Packet များ ကျဆင်းပျောက်ဆုံးခြင်း;
• ဝဘ်ဆိုက်များ မပွင့်ခြင်း;
• အမြန်နှုန်း မတည်ငြိမ်ခြင်း;
• VPN ချိတ်ဆက်ထားသော်လည်း ဒေတာ မသယ်ဆောင်နိုင်ခြင်း။

SingLink လုပ်ဆောင်ရန် လိုအပ်သည်များ:

1. TUN MTU ကို သတ်မှတ်ခြင်း;
2. ပရိုတိုကော header များကို နုတ်ခြင်း;
3. Encryption overhead ကို နုတ်ခြင်း;
4. IPv4 နှင့် IPv6 အတွက် ချိန်ညှိခြင်း;
5. လိုအပ်သည့်အခါ ဒေတာကို ခွဲခြမ်းခြင်း;
6. မလိုအပ်သော IP fragmentation ကို ရှောင်ကြဉ်ခြင်း။

ပုံသေ packet အရွယ်အစား တစ်ခုတည်းက ကွန်ရက်တိုင်းနှင့် မကိုက်ညီသည့် အကြောင်းရင်းမှာ ဤအချက်ပင် ဖြစ်ပါသည်။

Production 2.0 တွင် ပလက်ဖောင်းစုံ MTU တွဲသုံးနိုင်မှု ပိုမိုပြည့်စုံသင့်ပါသည်။ Beta က ပိုမိုပြင်းထန်သော frame ကြီးများကို အသုံးပြုပါက ကွန်ရက်အချို့တွင် ပိုမြန်နိုင်သော်လည်း ပုံမှန်မဟုတ်သော ကွန်ရက်များတွင် တည်ငြိမ်မှု နည်းနိုင်ပါသည်။

---

အဆင့် 17: Latency၊ packet ပျောက်ဆုံးမှုနှင့် congestion ကိုင်တွယ်ခြင်း

Client သည် အောက်ပါတို့ကို အဆက်မပြတ် စောင့်ကြည့်ရန် လိုအပ်ပါသည်:

• RTT latency;
• Jitter;
• Packet ပျောက်ဆုံးမှု;
• ပို့လွှတ်မှု အမြန်နှုန်း;
• လက်ခံမှု အမြန်နှုန်း;
• အတည်မပြုရသေးသော ဒေတာ;
• နုဒ်၏ တုံ့ပြန်မှု။

Ping တစ်ကြိမ်တည်းကို အားကိုး၍ မရပါ။

ဥပမာ:

ပုံမှန်: 60 ms
ယာယီ တိုးလာခြင်း: 120 ms
ဆက်တိုက် တိုးလာခြင်း: 500 ms
တုံ့ပြန်မှု မရှိ: timeout

အခြေအနေ မတူညီသလို ကိုင်တွယ်ပုံလည်း ကွဲပြားရပါမည်:

အခြေအနေ	ကိုင်တွယ်ပုံ
ယာယီ latency	ဆက်စောင့်ပါ၊ ချက်ချင်း ပြန်မချိတ်ဆက်ပါနှင့်
အနည်းငယ်သော packet ပျောက်ဆုံးမှု	Window သို့မဟုတ် pacing ကို ချိန်ညှိပါ
ဆက်တိုက် မြင့်မားသော latency	Concurrency ကို လျှော့ပါ သို့မဟုတ် အခြားနုဒ်ကို စဉ်းစားပါ
ဒေတာ မရှိသော်လည်း heartbeat အောင်မြင်သည်	Session ကို ဆက်ထားပါ
Heartbeat နှင့် ဒေတာ နှစ်မျိုးလုံး မအောင်မြင်	ချိတ်ဆက်မှု ပြတ်တောက်သည်ဟု မှတ်ယူပါ
နုဒ် လုံးဝ ပျက်ယွင်းခြင်း	ပြန်ချိတ်ဆက်ပါ သို့မဟုတ် နုဒ်ပြောင်းပါ

Packet တစ်ခု ပျောက်ဆုံးတိုင်း ပြန်ချိတ်ဆက်ခြင်းက ပရိုတိုကောကို တည်ငြိမ်မှု လျော့နည်းစေပါလိမ့်မည်။

---

အဆင့် 18: Heartbeat နှင့် ကျန်းမာရေး စစ်ဆေးမှုများ

အက်ပ်ဒေတာ ကြာမြင့်စွာ မရှိသည့်အခါတွင်ပင် channel ရှင်သန်နေဆဲလားဆိုသည်ကို စနစ်က သိရှိရန် လိုအပ်ပါသည်။

၎င်းက အသုံးပြုနိုင်သည်မှာ:

PING
↓
PONG

Heartbeat များကို အလွန်မကြာခဏ ပို့၍ မရပါ။

အကြိမ်ရေ အလွန်များပါက:

• ဘက်ထရီ ဖြုန်းတီးသည်;
• ဒေတာ ကုန်သည်;
• ဆာဗာဝန်အား တိုးစေသည်;
• ပုံသေ အချိန်ကိုက် လက္ခဏာတစ်ခု ဖန်တီးသည်။

အကြိမ်ရေ မလုံလောက်ပါက:

• ပျက်နေသော နုဒ်ကို ရှာဖွေတွေ့ရှိမှု နှောင့်နှေးသည်;
• အက်ပ်များကို ပိုကြာကြာ စောင့်စေသည်;
• ကွန်ရက်ပြောင်းလဲပြီးနောက် ပြန်လည်ကောင်းမွန်မှု နှေးသည်။

ထို့ကြောင့် heartbeat အကြိမ်ရေကို အခြေအနေအလိုက် လိုက်လျောညီထွေ ပြောင်းလဲနိုင်ပါသည်:

• ပုံမှန် traffic ရှိနေချိန်တွင် heartbeat မထပ်ထည့်ပါ;
• Idle ကာလတစ်ခု ကြာပြီးနောက် အကြိမ်ရေနည်း heartbeat များ စတင်ပါ;
• ကွန်ရက်ပြောင်းလဲပြီးနောက် စစ်ဆေးမှုများကို ယာယီ တိုးမြှင့်ပါ;
• ထပ်ခါထပ်ခါ မအောင်မြင်ပြီးနောက် ချိတ်ဆက်မှုကို ပြတ်တောက်သည်ဟု အမှတ်အသားပြုပါ။

---

အဆင့် 19: ကွန်ရက်ပြောင်းလဲမှုများနှင့် session ပြန်လည်ရယူခြင်း

ဖုန်းတစ်လုံးက Wi-Fi မှ 5G သို့ ပြောင်းရွှေ့သောအခါ မူလချိတ်ဆက်မှုသည် ပုံမှန်အားဖြင့် အသုံးမဝင်တော့ပါ။

ပြည့်စုံသော ကိုင်တွယ်ပုံမှာ:

ကွန်ရက်ပြောင်းလဲမှုကို ရှာဖွေတွေ့ရှိသည်
        ↓
ပျက်နေသော channel မှတစ်ဆင့် ဒေတာအသစ် ပို့ခြင်းကို ရပ်သည်
        ↓
ဒေသတွင်း IP နှင့် route အသစ်ကို ရယူသည်
        ↓
မူလနုဒ်သို့ ပြန်ချိတ်ဆက်သည်
        ↓
Session ပြန်လည်ရယူရေး credential ကို တင်သွင်းသည်
        ↓
Server က Session ဟောင်းကို အတည်ပြုသည်
        ↓
ပြန်လည်ရယူနိုင်သော logical Stream များကို ပြန်ရယူသည်
        ↓
ပြန်မရနိုင်သော TCP ချိတ်ဆက်မှုများကို ပြန်တည်ဆောက်ရန် အက်ပ်များကို အကြောင်းကြားသည်

အရေးကြီးသော ကန့်သတ်ချက်တစ်ခု:

အက်ပ် TCP ချိတ်ဆက်မှုတိုင်းကို ချောမွေ့စွာ ပြန်လည်ရယူ၍ မရပါ။

ပရိုတိုကောက ပြန်လည်ရယူနိုင်သည်များ:

• Session အခြေအနေ;
• နုဒ် ခွင့်ပြုချက်;
• ပရိုတိုကော parameter များ;
• အခြေအနေ မှန်ကန်နေဆဲဖြစ်သော Stream အချို့။

သို့သော် ဦးတည်ရာ ဝဘ်ဆိုက်၏ ကိုယ်ပိုင် TCP ချိတ်ဆက်မှု ပြီးဆုံးသွားပါက အက်ပ်က ပြန်ချိတ်ဆက်ရန် လိုအပ်နိုင်ဆဲ ဖြစ်ပါသည်။

ထို့ကြောင့် အောက်ပါအတိုင်း ကြော်ငြာ မပြုသင့်ပါ:

အက်ပ်တိုင်းသည် ကွန်ရက်ပြောင်းလဲမှုကို ပြတ်တောက်မှုလုံးဝမရှိဘဲ အမြဲ ကြုံတွေ့ရမည်။

ပိုမိုတိကျသော ဖော်ပြချက်မှာ:

SingLink 2.0 သည် ပြန်လည်ချိတ်ဆက်ချိန်ကို တိုစေပြီး ပရိုတိုကောနှင့် routing အခြေအနေကို ပြန်လည်ရယူကာ အက်ပ်အပေါ် သက်ရောက်မှုကို အနည်းဆုံးဖြစ်အောင် ကြိုးစားပါသည်။

---

အဆင့် 20: နုဒ် ပျက်ယွင်းမှုနှင့် အလိုအလျောက် ပြောင်းလဲခြင်း

နုဒ်၏ ပုံမှန်မဟုတ်မှုများကို အောက်ပါအတိုင်း ခွဲခြားနိုင်ပါသည်:

ပျော့ပျောင်းသော ပျက်ယွင်းမှု (Soft failure)

• Latency မြင့်တက်လာခြင်း;
• ရံဖန်ရံခါ packet ပျောက်ဆုံးခြင်း;
• ယာယီ တုံ့ပြန်မှု မရှိခြင်း;
• ဦးတည်ရာအချို့ မရရှိနိုင်ခြင်း။

ကိုင်တွယ်ပုံ:

• ခဏ စောင့်ပါ;
• Transport ဖိအားကို လျှော့ချပါ;
• ထပ်မံ တိုင်းတာပါ;
• တူညီသော နုဒ်သို့ ပြန်ချိတ်ဆက်ပါ။

ပြင်းထန်သော ပျက်ယွင်းမှု (Hard failure)

• နုဒ်ကို မရောက်ရှိနိုင်ခြင်း;
• Authentication interface မရရှိနိုင်ခြင်း;
• ဆက်တိုက် timeout ဖြစ်ခြင်း;
• နုဒ်ကို ဝန်ဆောင်မှုမှ ဖယ်ရှားထားခြင်း။

ကိုင်တွယ်ပုံ:

1. မူလနုဒ်ကို အသုံးပြုခြင်း ရပ်ပါ။
2. Kill Switch ကို ဖွင့်ပါ။
3. ရရှိနိုင်သော စာရင်းမှ အစားထိုးနုဒ်ကို ရွေးပါ။
4. လုံခြုံသော Session အသစ် တည်ဆောက်ပါ။
5. DNS နှင့် route များကို ပြန်လည်ထားရှိပါ။
6. လိုအပ်သော ချိတ်ဆက်မှုများကို ပြန်တည်ဆောက်ရန် အက်ပ်များကို အကြောင်းကြားပါ။

Production 2.0 သည် ခဏတာ jitter က နုဒ်များကို ထပ်ခါထပ်ခါ ခုန်ပြောင်းစေခြင်း မဖြစ်စေရန် ပိုမို သတိထား၍ ပြောင်းလဲနိုင်ပါသည်။

Beta သည် ပိုမိုပြင်းထန်စွာ ပြန်ချိတ်ဆက်ခြင်း သို့မဟုတ် အမြန်နှုန်းမြင့် နုဒ်များကို ရွေးချယ်နိုင်သော်လည်း ၎င်းက ကွဲလွဲမှု ပိုကြီးစေနိုင်ပါသည်။

---

အဆင့် 21: ဒေတာ ပြန်ပို့ခြင်းနှင့် decapsulation

ဦးတည်ရာ ဝဘ်ဆိုက်၏ တုံ့ပြန်မှုသည် ဤလုပ်ငန်းစဉ်အတိုင်း သွားပါသည်:

ဦးတည်ရာ ဝဘ်ဆိုက်က ဒေတာ ပြန်ပို့သည်
        ↓
SingLink နုဒ်က လက်ခံရရှိသည်
        ↓
ကိုက်ညီသော Session နှင့် Stream ကို ရှာသည်
        ↓
SingLink ဒေတာ frame အဖြစ် encapsulate လုပ်သည်
        ↓
Encrypt လုပ်ပြီး client သို့ ပို့သည်
        ↓
Client က မပျက်စီးမှုကို အတည်ပြုသည်
        ↓
Decrypt လုပ်သည်
        ↓
Stream ID အလိုက် ခွဲထုတ်သည်
        ↓
TUN သို့မဟုတ် system proxy ထဲ ရေးသွင်းသည်
        ↓
မူလအက်ပ်ထံ ပြန်ပို့သည်

Client က စစ်ဆေးရန် လိုအပ်သည်များ:

• ဒေတာကို ပြုပြင်ပြောင်းလဲခံရခြင်း ရှိ၊ မရှိ;
• Sequence number များ မှန်ကန်ခြင်း ရှိ၊ မရှိ;
• Frame သည် ထပ်နေခြင်း ရှိ၊ မရှိ;
• Stream ရှိနေဆဲလား;
• အရှည်သည် ကန့်သတ်ချက်အတွင်း ရှိ၊ မရှိ;
• လက်ခံရေး window ကို ကျော်လွန်ခဲ့ခြင်း ရှိ၊ မရှိ။

မမှန်ကန်သော ဒေတာကို အက်ပ်ထံ တိုက်ရိုက် မပေးပို့ရပါ။

---

အဆင့် 22: ပုံမှန် ချိတ်ဆက်မှုဖြတ်ခြင်းနှင့် လုံခြုံစွာ ရှင်းလင်းခြင်း

အသုံးပြုသူက Disconnect ကို ရွေးချယ်သောအခါ client က လုပ်ဆောင်သင့်သည်များ:

1. Proxy ဖြင့်သွားမည့် traffic အသစ်များကို လက်ခံခြင်း ရပ်ခြင်း;
2. လက်ရှိ Stream များကို ပုံမှန်အတိုင်း ပိတ်ခြင်း;
3. Session အဆုံးသတ်ကြောင်း နုဒ်ထံ ပို့ခြင်း;
4. Session key များကို ဖျက်ပစ်ခြင်း;
5. သက်တမ်းတို token များကို ရုပ်သိမ်းခြင်း သို့မဟုတ် စွန့်ပစ်ခြင်း;
6. TUN ကို ပိတ်ခြင်း;
7. စနစ် route များကို ပြန်လည်ထားရှိခြင်း;
8. DNS ကို ပြန်လည်ထားရှိခြင်း;
9. Kill Switch စည်းမျဉ်းများကို ဖယ်ရှားခြင်း;
10. မလိုအပ်သော ယာယီ configuration ကို ဖယ်ရှားခြင်း။

Client ပျက်ကျသွားပါက operating system သို့မဟုတ် နောက်တစ်ကြိမ် စတင်ဖွင့်ချိန်တွင် အောက်ပါတို့ ကျန်ရစ်ခြင်းကို ရှောင်ရှားရန် ပြုပြင်ရေးလမ်းကြောင်း လိုအပ်ပါသည်:

• မမှန်ကန်သော system proxy;
• မှားယွင်းသော DNS;
• ကျန်ရစ်နေသော route များ;
• အင်တာနက် ဝင်ရောက်၍ မရခြင်း;
• အမြဲတမ်း သော့ခတ်နေသော Kill Switch။

---

SingLink Beta နှင့် 2.0 အကြား အသေးစိတ် မဟာဗျူဟာ ကွာခြားချက်များ

အောက်ပါတို့သည် ထုတ်ကုန်၏ နည်းပညာနေရာချထားမှုကို ဖော်ပြခြင်းဖြစ်ပြီး တိကျသော parameter များမှာ အင်ဂျင်နီယာဆိုင်ရာ အတည်ပြုချက် လိုအပ်နေဆဲ ဖြစ်ပါသည်။

လုပ်ဆောင်မှု နယ်ပယ်	SingLink Beta	SingLink 2.0
အဓိက ဦးတည်ချက်	အမြင့်ဆုံး အမြန်နှုန်း	အမြန်နှုန်း၊ တည်ငြိမ်မှု၊ တွဲသုံးနိုင်မှု
ချိတ်ဆက်မှု parameter များ	ပိုမိုပြင်းထန်သည်	လိုက်လျောညီထွေရှိပြီး ပိုမို သတိထားသည်
Concurrency	Concurrency ပိုမြင့်မြင့် သုံးနိုင်သည်	Flow တစ်ခုက channel ကို မပြည့်စေရန် တားဆီးသည်
Transport window	Throughput ဘက်သို့ ဦးစားပေးသည်	Latency နှင့် packet ပျောက်ဆုံးမှုအလိုက် ပြောင်းလဲချိန်ညှိသည်
နုဒ် ပြောင်းလဲခြင်း	အမြန်နှုန်းမြင့် နုဒ်များကို စောစော စမ်းသည်	ပျက်ယွင်းကြောင်း အတည်ပြုပြီးမှ ပြောင်းသည်
Multiplexing	ပြန်လည်အသုံးပြုမှု ထိရောက်မှုဘက် ဦးစားပေးသည်	ပြန်လည်အသုံးပြုမှုနှင့် ပျက်ယွင်းမှု ခွဲခြားထားမှုကို ချိန်ခွင်လျှာညှိသည်
Padding	Overhead နည်းခြင်းကို ဦးစားပေးသည်	ပတ်ဝန်းကျင်အလိုက် လိုက်လျောညီထွေ ပြောင်းလဲသည်
ကွန်ရက် ပြောင်းလဲမှု	အခြေခံ ပြန်လည်ကောင်းမွန်မှု	ပိုမိုပြည့်စုံသော ပြန်လည်ကောင်းမွန်မှုနှင့် တွဲသုံးနိုင်မှု
ပလက်ဖောင်း regression စမ်းသပ်မှု	Preview နယ်ပယ်	Production အပြည့်အစုံ စမ်းသပ်မှု
အတွင်းပိုင်း တည်ငြိမ်မှု	97% ခန့်	99.5%
အမြန်နှုန်း	သင့်လျော်သော အခြေအနေများတွင် 1 Gbps အထက်	အမြင့်ဆုံးကိုသာ မလိုက်ဘဲ မြန်ဆန်မှုကို ဆက်ထိန်းထားသည်

---

လုပ်ဆောင်ပုံ မူ အပြည့်အစုံကို စာပိုဒ်တစ်ပိုဒ်တည်းဖြင့်

SingLink သည် ပထမဦးစွာ client က စက်ပစ္စည်း traffic ကို ထိန်းချုပ်ပြီး DNS ကိုင်တွယ်မှု၊ smart routing နှင့် နုဒ်ရွေးချယ်မှုကို ပြီးဆုံးစေပါသည်။ ထို့နောက် အကောင့်နှင့် နုဒ် အသုံးပြုခွင့်ကို အတည်ပြုပြီး နုဒ်နှင့် ပရိုတိုကော စွမ်းရည်များကို ညှိနှိုင်းကာ ယာယီ encryption key များကို တည်ဆောက်ပါသည်။ ချိတ်ဆက်မှု ဖန်တီးပြီးနောက် အက်ပ်တစ်ခုစီ၏ TCP နှင့် UDP traffic ကို သီးခြား proxy ချိတ်ဆက်မှု သို့မဟုတ် logical Stream အဖြစ် encapsulate လုပ်ပြီး ကာကွယ်ထားသော channel မှတစ်ဆင့် နုဒ်ထံ သယ်ဆောင်ကာ နုဒ်က ဦးတည်ရာ ဝဘ်ဆိုက်ကို ဝင်ရောက်ပါသည်။ လွှဲပြောင်းနေစဉ်အတွင်း စနစ်သည် flow window များ၊ ဒေတာ မပျက်စီးမှု၊ latency၊ packet ပျောက်ဆုံးမှု၊ heartbeat များနှင့် နုဒ်အခြေအနေကို အဆက်မပြတ် စီမံပါသည်။ ကွန်ရက်ပြောင်းလဲခြင်း သို့မဟုတ် နုဒ်ပျက်ယွင်းခြင်း ဖြစ်ပါက Session ကို ပြန်တည်ဆောက်ခြင်း၊ route များကို ပြန်လည်ထားရှိခြင်း သို့မဟုတ် ရရှိနိုင်သော နုဒ်သို့ ပြောင်းလဲခြင်း ပြုလုပ်ပါသည်။

Beta နှင့် 2.0 အကြား အနှစ်သာရ ကွာခြားချက်မှာ:

SingLink Beta သည် အမြင့်ဆုံးအမြန်နှုန်းကို ပိုမိုပြင်းထန်စွာ လိုက်စားပါသည်။ SingLink 2.0 သည် အမြန်နှုန်းမြင့် လွှဲပြောင်းမှုကို ထိန်းထားရင်း ပိုမိုပြည့်စုံသော တွဲသုံးနိုင်မှု၊ ကျန်းမာရေးစစ်ဆေးမှုများ၊ ပုံမှန်မဟုတ်မှု အမျိုးအစားခွဲခြားခြင်း၊ session ပြန်လည်ရယူခြင်းနှင့် ပလက်ဖောင်းစုံ ကိုင်တွယ်မှုကို ထပ်ပေါင်းထားသောကြောင့် တည်ငြိမ်မှု ပိုမြင့်ပါသည်။

---

မေးလေ့ရှိသော မေးခွန်းများ (FAQ)

SingLink 2.0 ဆိုတာ ဘာလဲ?

SingLink 2.0 သည် SingLinkVPN က ဖန်တီးထားသော တရားဝင် ကွန်ရက် transport ပရိုတိုကော ဖြစ်ပါသည်။ ၎င်းသည် ကိုယ်ပိုင်အထောက်အထား စစ်ဆေးခြင်း၊ encrypted session များ၊ traffic encapsulation၊ TCP နှင့် UDP transport၊ ကျန်းမာရေးစစ်ဆေးမှုများနှင့် ပုံမှန်မဟုတ်မှုမှ ပြန်လည်ကောင်းမွန်ခြင်းတို့ကို ကိုင်တွယ်ပါသည်။

SingLink 2.0 သည် ဆော့ဖ်ဝဲဗားရှင်းတစ်ခုလား?

မဟုတ်ပါ။ SingLink 2.0 သည် ပရိုတိုကော၏ တရားဝင်အမည် ဖြစ်ပါသည်။ Windows၊ macOS၊ Android နှင့် iOS client ဗားရှင်းများသည် သီးခြား ဗားရှင်းနံပါတ်စနစ်ကို အသုံးပြုပါသည်။

SingLink Beta နှင့် 2.0 အကြား ကွာခြားချက်မှာ ဘာလဲ?

SingLink Beta သည် အမြန်နှုန်းကို ဦးစားပေးသော preview ပရိုတိုကော ဖြစ်ပြီး သင့်လျော်သော အခြေအနေများတွင် ၎င်း၏ အမြင့်ဆုံးအမြန်နှုန်းသည် 1 Gbps ကို ကျော်လွန်နိုင်ပါသည်။ 2.0 သည် production ပရိုတိုကော ဖြစ်ပြီး အမြန်နှုန်း၊ တည်ငြိမ်မှု၊ ပလက်ဖောင်းစုံ တွဲသုံးနိုင်မှုနှင့် ချိတ်ဆက်မှုပြတ်တောက်ရာမှ ပြန်လည်ကောင်းမွန်ခြင်းကို အလေးပေးပါသည်။

SingLink 2.0 ၏ တည်ငြိမ်မှုနှုန်းမှာ မည်မျှလဲ?

သတ်မှတ်ထားသော အခြေအနေများအောက်ရှိ SingLinkVPN ၏ အတွင်းပိုင်း A/B စမ်းသပ်မှုတွင် SingLink 2.0 သည် တည်ငြိမ်မှု 99.5% ရရှိခဲ့ပြီး Beta သည် အများဆုံး 97% ခန့်အထိ ရရှိခဲ့ပါသည်။

SingLink သည် ကွန်ရက် traffic ကို မည်သို့ ကိုင်တွယ်သနည်း?

SingLink client သည် ပထမဦးစွာ စနစ် traffic ကို ထိန်းချုပ်ပြီး DNS ကိုင်တွယ်မှုနှင့် smart routing ကို လုပ်ဆောင်ပါသည်။ ထို့နောက် အကောင့်နှင့် နုဒ် အသုံးပြုခွင့်ကို အတည်ပြုပြီး encrypted Session ကို တည်ဆောက်ကာ TCP သို့မဟုတ် UDP ဒေတာကို encapsulate လုပ်၍ နုဒ်ထံ ပို့ပါသည်။

SingLink သည် ချိတ်ဆက်မှု ပြတ်တောက်ခြင်းကို မည်သို့ ကိုင်တွယ်သနည်း?

SingLink စနစ်သည် latency၊ packet ပျောက်ဆုံးမှု၊ heartbeat များနှင့် နုဒ်အခြေအနေကို အဆက်မပြတ် စစ်ဆေးပါသည်။ ပုံမှန်မဟုတ်မှု ဖြစ်ပြီးနောက် Session ကို ပြန်တည်ဆောက်ခြင်း၊ route များကို ပြန်လည်ထားရှိခြင်း သို့မဟုတ် ရရှိနိုင်သော နုဒ်သို့ ပြောင်းလဲခြင်း ပြုလုပ်နိုင်ပါသည်။

SingLink သည် VLESS နှင့် မည်သို့ ကွာခြားသနည်း?

VLESS သည် အဓိကအားဖြင့် ကိုယ်ပိုင်အထောက်အထား၊ command များနှင့် ဦးတည်ရာ ပို့ဆောင်ခြင်းကို သတ်မှတ်ပါသည်။ SingLink သည် ကိုယ်ပိုင်အထောက်အထား၊ routing၊ နုဒ် အသုံးပြုခွင့်၊ transport မူဝါဒ၊ ကျန်းမာရေးစစ်ဆေးမှုများနှင့် ပုံမှန်မဟုတ်မှုမှ ပြန်လည်ကောင်းမွန်ခြင်းတို့ကို ပိုမိုကျယ်ပြန့်သော ပရိုတိုကောစနစ်တစ်ခုထဲသို့ ပေါင်းစည်းထားပါသည်။

SingLink သည် AnyTLS နှင့် မည်သို့ ကွာခြားသနည်း?

AnyTLS သည် အဓိကအားဖြင့် TLS ချိတ်ဆက်မှုတစ်ခုပေါ်တွင် Session တစ်ခုနှင့် Stream များစွာကို သယ်ဆောင်ပါသည်။ SingLink တွင် smart routing၊ အသင်းဝင် အသုံးပြုခွင့်၊ နုဒ် scheduling နှင့် ချိတ်ဆက်မှု ပြန်လည်ကောင်းမွန်ခြင်းတို့ပါ ပါဝင်သော ပိုမိုကျယ်ပြန့်သည့် ထုတ်ကုန်အခန်းကဏ္ဍ ရှိပါသည်။ အမှန်တကယ် Session နှင့် Stream အကောင်အထည်ဖော်မှုမှာ တရားဝင် နည်းပညာစာတမ်းများအပေါ် မူတည်နေဆဲ ဖြစ်ပါသည်။

SingLink 2.0 ကို မည်သူ အသုံးပြုနိုင်သနည်း?

Production SingLink 2.0 ပရိုတိုကော နုဒ်များကို လက်ရှိတွင် အဓိကအားဖြင့် Pro၊ Max နှင့် Rich အစီအစဉ် အသုံးပြုသူများ အသုံးပြုနိုင်ပါသည်။ Beta ပရိုတိုကောကို အသင်းဝင်အားလုံးအတွက် ဖွင့်ထားပါသည်။ အမှန်တကယ် အသုံးပြုခွင့်အတွက် နောက်ဆုံးထွက် client တွင် ပြသချက်ကသာ အတည်ဖြစ်ပါသည်။

SingLink 2.0 သည် လုံးဝ open source ဖြစ်သလား?

Core ပရိုတိုကော source ကို အပြည့်အဝ မထုတ်ပြန်ရသေးသော်လည်း နည်းပညာစာတမ်းများ၊ စမ်းသပ်နည်းများ၊ ဒေတာပုံစံများ၊ စစ်ဆေးရေးကိရိယာများနှင့် အားနည်းချက် ထုတ်ဖော်ရေး ယန္တရားတို့သည် ဆက်လက်လုပ်ဆောင်နေသော open-source အစီအစဉ်၏ အစိတ်အပိုင်း ဖြစ်ပါသည်။

---

ရင်းမြစ်များနှင့် ထပ်မံဖတ်ရှုရန်

ဤဆောင်းပါး၏ ထုတ်ကုန်နေရာချထားမှုနှင့် အများသိနယ်ပယ် ဖော်ပြချက်များသည် SingLinkVPN တရားဝင် နည်းပညာစင်တာ၊ SingLinkLabs အများသိ သုတေသန repository နှင့် ၎င်း၏ စွမ်းဆောင်ရည် benchmark နည်းစနစ် တို့ကိုလည်း ကိုးကားထားပါသည်။

ဆက်စပ်ဖတ်ရှုရန်များတွင် SingLinkVPN အခမဲ့အစီအစဉ် လမ်းညွှန်အပြည့်အစုံ၊ SingLinkVPN open-source အစီအစဉ် နှင့် 2026 SingLinkVPN လုံခြုံရေး စစ်ဆေးမှု အစီရင်ခံစာ တို့ ပါဝင်ပါသည်။

နည်းပညာ မှတ်ချက်: 99.5%၊ 97% ခန့်နှင့် 1 Gbps အထက် ကိန်းဂဏန်းများသည် သတ်မှတ်ထားသော အခြေအနေများအောက်ရှိ အတွင်းပိုင်း A/B တည်ငြိမ်မှုရလဒ်များနှင့် အမြင့်ဆုံး throughput ရလဒ်များ အသီးသီး ဖြစ်ပါသည်။ ၎င်းတို့သည် ဒေသ၊ စက်ပစ္စည်း၊ ကွန်ရက်ဝန်ဆောင်မှုပေးသူ၊ ကွန်ရက် သို့မဟုတ် အချိန်ကာလတိုင်းတွင် တူညီသောရလဒ် ထွက်မည်ဟု မဆိုလိုပါ။ တိကျသော encryption algorithm များ၊ packet ပုံစံများ၊ Session ယန္တရားနှင့် Stream ယန္တရားများမှာ အနာဂတ် တရားဝင် SingLink နည်းပညာစာတမ်းများနှင့် ထုတ်ပြန်ထားသော source code တို့အပေါ် မူတည်နေဆဲ ဖြစ်ပါသည်။