โปรโตคอล SingLink 2.0

SingLink 2.0 คือโปรโตคอลการส่งข้อมูลผ่านเครือข่ายอย่างเป็นทางการที่ SingLinkVPN พัฒนาขึ้นเอง “2.0” หมายถึงชื่อและยุคของโปรโตคอล ไม่ใช่หมายเลขเวอร์ชันซอฟต์แวร์ของไคลเอนต์ SingLinkVPN

โปรโตคอล SingLink ไม่ได้มีหน้าที่เพียงส่งทราฟฟิกไปยังโหนด VPN เท่านั้น แต่ยังครอบคลุมการตรวจสอบสิทธิ์บัญชีและโหนด การจัดการ DNS การแบ่งเส้นทางอัจฉริยะ เซสชันเข้ารหัส การห่อหุ้ม TCP และ UDP การตรวจสุขภาพการเชื่อมต่อ การสลับเครือข่าย และการกู้คืนจากความผิดปกติ

ปัจจุบัน SingLink แบ่งเป็นโปรโตคอล SingLink 2.0 รุ่นทางการ และโปรโตคอลพรีวิว SingLink Beta ที่ให้ความสำคัญกับความเร็ว จากการทดสอบ A/B ภายใน SingLink 2.0 มีอัตราความเสถียร 99.5% ส่วน Beta สูงสุดประมาณ 97% และภายใต้เครือข่ายกับอุปกรณ์ที่เหมาะสม Beta สามารถทำความเร็วสูงสุดได้มากกว่า 1 Gbps

การเปรียบเทียบข้อมูลหลัก: SingLink 2.0 รุ่นทางการบันทึกอัตราความเสถียร 99.5%ในสภาพแวดล้อมทดสอบที่กำหนด ส่วน Beta สูงสุดประมาณ97% แต่ภายใต้เครือข่ายและอุปกรณ์ที่เหมาะสม ความเร็วสูงสุดอาจมากกว่า1 Gbps ผลลัพธ์เหล่านี้สะท้อนแนวทางด้านความเสถียรและความเร็วตามลำดับ ไม่ควรถือเป็นค่ารับประกันสำหรับทุกอุปกรณ์และทุกเครือข่ายโดยตรง

หลักฐานและขอบเขตทางเทคนิค: สามารถอ้างอิงตำแหน่งผลิตภัณฑ์ เกณฑ์การทดสอบภายใน และฟังก์ชันที่เผยแพร่ซึ่งยืนยันแล้วได้โดยตรง เนื้อหาในบทความนี้เกี่ยวกับอัลกอริทึมการเข้ารหัส รูปแบบแพ็กเก็ต การเจรจาความสามารถ Session, Stream, multiplexing และการกู้คืนเซสชัน เป็นแบบจำลองอ้างอิงสำหรับการประมวลผล ไม่อาจถือเป็นข้อกำหนดที่ใช้งานจริงในปัจจุบัน โปรดอ้างอิงเอกสารทางเทคนิคและซอร์สโค้ดที่ SingLink จะเผยแพร่อย่างเป็นทางการในภายหลัง

หลักการประมวลผลทั้งหมดของโปรโตคอล SingLink

ระบบทั้งหมดแบ่งได้เป็นสองส่วน:

Control plane

รับผิดชอบ:

• เข้าสู่ระบบบัญชี

• ตรวจสอบสมาชิก

• รับข้อมูลโหนด

• ตรวจสอบสิทธิ์ของโหนด

• ส่งการกำหนดค่าโปรโตคอล

• อัปเดตกฎ

• เลือก Beta หรือ 2.0

Data plane

รับผิดชอบ:

• รับทราฟฟิกจากแอปพลิเคชัน

• แก้ชื่อ DNS

• สร้างการเชื่อมต่อที่ปลอดภัย

• ห่อหุ้มและส่ง TCP, UDP

• รักษาการเชื่อมต่อ

• จัดการการตัดการเชื่อมต่อ

• ส่งข้อมูลกลับไปยังแอปพลิเคชัน

ลำดับการทำงานอย่างย่อ:

ผู้ใช้เข้าสู่ระบบ SingLinkVPN
        ↓
รับโหนดที่ได้รับอนุญาตและการกำหนดค่าโปรโตคอล
        ↓
ไคลเอนต์สร้าง TUN／พร็อกซีระบบ
        ↓
รับทราฟฟิกของแอปพลิเคชัน
        ↓
ตัดสินตาม DNS และกฎแบ่งเส้นทาง
        ↓
เลือกโหนด SingLink 2.0 หรือ Beta
        ↓
เจรจาความสามารถของโปรโตคอล
        ↓
ตรวจสอบสิทธิ์บัญชีและอุปกรณ์
        ↓
สร้างเซสชันเข้ารหัสและกุญแจเซสชัน
        ↓
สร้างสตรีมตรรกะแยกสำหรับการเชื่อมต่อของแต่ละแอป
        ↓
ห่อหุ้มข้อมูล TCP／UDP
        ↓
ส่งไปยังโหนด SingLink
        ↓
โหนดแกะการห่อหุ้มและเข้าถึงเว็บไซต์ปลายทาง
        ↓
ส่งข้อมูลกลับและแจกจ่ายให้แอปเดิม
        ↓
ตรวจสอบเวลาแฝง การสูญหายของแพ็กเก็ต และสถานะการเชื่อมต่ออย่างต่อเนื่อง
        ↓
เมื่อผิดปกติ ให้เชื่อมต่อใหม่ กู้คืน หรือสลับโหนด

ขั้นตอนที่หนึ่ง: เข้าสู่ระบบ รับโหนด และรับการกำหนดค่าโปรโตคอล

หลังผู้ใช้เปิด SingLinkVPN และเข้าสู่ระบบ ไคลเอนต์ไม่ควรบันทึกที่อยู่โหนดจริงทั้งหมด ข้อมูลรับรอง และพารามิเตอร์โปรโตคอลไว้ในเครื่องอย่างถาวรทันที

กระบวนการที่เหมาะสมกว่าคือ:

1. ไคลเอนต์ส่งข้อมูลรับรองสำหรับเข้าสู่บัญชี

2. ระบบบัญชีตรวจสอบผู้ใช้

3. ระบบยืนยันแพ็กเกจและสิทธิ์การใช้โหนด

4. ส่งคืนรายการโหนดที่ผู้ใช้ใช้ได้

5. ส่งคืนข้อมูลรับรองการเชื่อมต่อที่มีอายุสั้น

6. ส่งคืนเวอร์ชันโปรโตคอลปัจจุบันและการกำหนดค่าที่จำเป็น

7. ไคลเอนต์ตรวจสอบความครบถ้วนของการกำหนดค่า

8. บันทึกการกำหนดค่าที่ละเอียดอ่อนไว้ในพื้นที่จัดเก็บที่ปลอดภัยของระบบ

ชั้นนี้ใช้พิจารณาหลัก ๆ ว่า:

• ผู้ใช้เป็นสมาชิกที่ใช้งานได้หรือไม่

• ใช้ Beta หรือ 2.0 ได้หรือไม่

• มีสิทธิ์ Pro, Max หรือ Rich หรือไม่

• ใช้ประเทศและโหนดใดได้บ้าง

• การกำหนดค่าหมดอายุแล้วหรือไม่

• ต้องอัปเดตเวอร์ชันไคลเอนต์หรือไม่

อธิบายแบบเข้าใจง่าย

เหมือนก่อนขึ้นรถไฟความเร็วสูง ระบบจะตรวจสอบก่อนว่า:

• คุณคือใคร

• ซื้อตั๋วระดับใด

• ขึ้นรถขบวนใดได้

• ตั๋วยังใช้ได้อยู่หรือไม่

กฎความปลอดภัยที่แนะนำ

SingLink ไม่ควรพึ่งพารหัสผ่านแบบคงที่ซึ่งไม่เปลี่ยนแปลงตลอดไปในระยะยาว

วิธีที่เหมาะสมกว่าคือใช้:

• Token การเชื่อมต่ออายุสั้น

• Challenge แบบใช้ครั้งเดียว

• Nonce สุ่มของอุปกรณ์

• การจำกัดอายุการใช้งาน

• การกำหนดค่าโหนดที่มีลายเซ็นของเซิร์ฟเวอร์

• กลไกเพิกถอน

ดังนั้น แม้มีผู้ได้รับการกำหนดค่าของการเชื่อมต่อครั้งหนึ่ง ก็ไม่ได้หมายความว่าจะนำไปใช้ได้ตลอดไป

ขั้นตอนที่สอง: สร้างทางเข้าเครือข่ายของระบบ

เมื่อผู้ใช้กดเชื่อมต่อ SingLinkVPN ต้องสร้างทางเข้าเครือข่ายในระบบปฏิบัติการก่อน

แต่ละแพลตฟอร์มมีวิธีจัดการต่างกัน:

หลังสร้างแล้ว ข้อมูลที่เดิมส่งจากแอปไปยังเครือข่ายโดยตรงจะเข้าสู่ไคลเอนต์ SingLinkVPN ก่อน

ตัวอย่าง:

ChatGPT App
    ↓
สแตกเครือข่ายของระบบปฏิบัติการ
    ↓
อินเทอร์เฟซ SingLink TUN
    ↓
ไคลเอนต์ SingLinkVPN

ในขั้นตอนนี้ไคลเอนต์ต้อง:

• สร้าง IP เสมือน

• ตั้งค่าตารางเส้นทาง

• ตั้งค่า DNS

• ยกเว้นเครือข่ายท้องถิ่น

• ป้องกันไม่ให้การเชื่อมต่อพร็อกซีถูกส่งกลับเข้า TUN อีกครั้ง

ข้อสุดท้ายสำคัญมาก

หากไม่มี “การยกเว้นเส้นทาง” ทราฟฟิกที่ SingLinkVPN ใช้เชื่อมต่อโหนดอาจย้อนกลับเข้า VPN อีกครั้งจนเกิดวงจร:

ทราฟฟิก VPN
↓
เข้า VPN อีกครั้ง
↓
ห่อหุ้มอีกครั้ง
↓
วนซ้ำไม่สิ้นสุด

ดังนั้นไคลเอนต์ต้องยกเว้นอย่างชัดเจน:

• IP ของโหนดเอง

• อินเทอร์เฟซควบคุมที่จำเป็น

• เกตเวย์ท้องถิ่น

• บริการที่ระบบจำเป็นต้องเข้าถึงโดยตรง

ขั้นตอนที่สาม: การแก้ชื่อ DNS และการตัดสินโดเมน

เมื่อผู้ใช้เปิด chatgpt.com โดยทั่วไปอุปกรณ์ต้องแปลงชื่อโดเมนเป็นที่อยู่ IP ก่อน

หากจัดการ DNS ไม่ถูกต้อง อาจเกิด:

• คำขอ DNS วิ่งผ่านเครือข่ายท้องถิ่นโดยตรง

• DNS ท้องถิ่นส่งคืนที่อยู่ผิด

• กฎไม่สามารถจำแนกโดเมน

• IPv6 เลี่ยง VPN

• เชื่อมต่อ VPN แล้วแต่ DNS ยังรั่วไหล

ไคลเอนต์ SingLink สามารถดำเนินการตามลำดับต่อไปนี้:

แอปส่งคำขอ DNS
        ↓
ไคลเอนต์ดักจับ DNS
        ↓
ตรวจสอบกฎของโดเมน
        ↓
เลือก DNS ท้องถิ่นหรือ DNS ระยะไกลที่ปลอดภัย
        ↓
รับผลลัพธ์ IPv4／IPv6
        ↓
เชื่อมโยงโดเมนกับ IP
        ↓
ตัดสินใจเชื่อมต่อตรง ใช้พร็อกซี หรือบล็อก

โดเมนท้องถิ่น

เช่น ธนาคารท้องถิ่น อุปกรณ์ในเครือข่ายท้องถิ่น หรือบริการเฉพาะภูมิภาค สามารถใช้ DNS ท้องถิ่นและเชื่อมต่อโดยตรง

โดเมนที่ใช้พร็อกซี

โดเมนที่ต้องเข้าผ่าน VPN สามารถแก้ชื่อผ่านโหนดพร็อกซีหรือ DNS ที่ได้รับการปกป้อง

อธิบายแบบเข้าใจง่าย

DNS เปรียบเสมือนการค้นหาสมุดที่อยู่

หากขั้นตอนค้นหาสมุดที่อยู่ยังวิ่งบนเส้นทางท้องถิ่น แม้ข้อมูลหลังจากนั้นจะผ่าน VPN ก็อาจเปิดเผยว่า “กำลังค้นหาเว็บไซต์ใด”

ดังนั้น ระบบโปรโตคอล SingLink ควรกำหนดอย่างชัดเจนว่า:

• ไคลเอนต์ดักจับ DNS หรือไม่

• คำขอ DNS ใดเชื่อมต่อตรง

• คำขอ DNS ใดผ่าน VPN

• จัดการ IPv4 และ IPv6 อย่างไร

• เก็บแคช DNS นานเท่าใด

• หลังสลับเครือข่ายจะล้างผล DNS เก่าหรือไม่

ขั้นตอนที่สี่: การแบ่งทราฟฟิกอัจฉริยะและการตัดสินเส้นทาง

หลัง DNS และทราฟฟิกแอปเข้าสู่ไคลเอนต์ ระบบต้องตัดสินว่าจะจัดการทราฟฟิกอย่างไร

โดยทั่วไปมีสามผลลัพธ์:

เชื่อมต่อตรง
พร็อกซี
บล็อก

เชื่อมต่อตรง

ทราฟฟิกใช้เครือข่ายท้องถิ่นโดยตรงและไม่เข้าสู่ช่องทาง SingLink

เหมาะสำหรับ:

• อุปกรณ์ในเครือข่ายท้องถิ่น

• เว็บไซต์ท้องถิ่น

• แอปที่ไม่ต้องใช้พร็อกซี

• รายการอนุญาตที่ผู้ใช้กำหนดเอง

พร็อกซี

ทราฟฟิกเข้าสู่โปรโตคอล SingLink และส่งต่อโดยโหนด

เหมาะสำหรับ:

• เว็บไซต์ต่างประเทศ

• เครื่องมือ AI

• แพลตฟอร์มสังคมออนไลน์ระหว่างประเทศ

• App ที่ผู้ใช้ระบุ

บล็อก

ปฏิเสธการเชื่อมต่อ

เหมาะสำหรับ:

• โดเมนโฆษณา

• โดเมนติดตาม

• ที่อยู่อันตราย

• รายการบล็อกที่ผู้ใช้ตั้งค่า

เกณฑ์การตัดสินอาจประกอบด้วย:

• โดเมน

• ที่อยู่ IP

• พอร์ต

• แอปพลิเคชัน

• ตำแหน่งทางภูมิศาสตร์

• ประเภทโปรโตคอล

• กฎของผู้ใช้

• โหมดทั่วโลกหรือโหมดตามกฎ

อธิบายแบบเข้าใจง่าย

ขั้นตอนนี้เหมือนการแบ่งช่องทางจราจร:

• รถท้องถิ่นใช้ถนนทั่วไป

• รถไปต่างประเทศเข้าสู่ทางด่วนเข้ารหัส

• รถอันตรายถูกห้ามผ่านโดยตรง

ขั้นตอนที่ห้า: การเลือกโหนดและโปรโตคอล

หลังยืนยันว่าทราฟฟิกต้องใช้พร็อกซี ไคลเอนต์ต้องเลือกโหนด

การเลือกโหนดไม่ควรพิจารณาเพียงชื่อประเทศเท่านั้น แต่ยังต้องคำนึงถึง:

• แพ็กเกจของผู้ใช้

• โหนดเป็น 2.0 หรือ Beta

• โหนดออนไลน์อยู่หรือไม่

• ค่าหน่วง

• การสูญหายของแพ็กเก็ต

• ภาระของโหนด

• ระยะห่างจากโหนด

• ผู้ให้บริการเครือข่ายในพื้นที่

• ตำแหน่งของเว็บไซต์ปลายทาง

• โหนดรองรับ UDP หรือไม่

• ไคลเอนต์เข้ากันได้หรือไม่

การเลือกด้วยตนเอง

ผู้ใช้เลือกโหนดในญี่ปุ่น สหรัฐอเมริกา สิงคโปร์ หรือประเทศอื่นด้วยตนเอง

การเลือกอัจฉริยะ

ไคลเอนต์เลือกโหนดที่เหมาะสมตามผลการทดสอบ

การเลือกอัจฉริยะไม่ควรเลือกเพียงโหนดที่มีค่าหน่วงต่ำที่สุด

ตัวอย่าง:

แม้ A จะมีค่าหน่วงต่ำกว่า แต่มีการสูญหายของแพ็กเก็ตและภาระสูงมาก ในการใช้งานจริง B อาจเสถียรกว่า

ดังนั้น การเลือกอัจฉริยะควรพิจารณาปัจจัยต่อไปนี้ร่วมกัน:

ค่าหน่วง + การสูญหายของแพ็กเก็ต + อัตราความสำเร็จในการเชื่อมต่อ + ภาระ + ประสิทธิภาพที่ผ่านมา

ขั้นตอนที่ 6: การเจรจาความสามารถของโปรโตคอล

หลังจากไคลเอนต์เชื่อมต่อกับโหนดแล้ว ไม่ควรสันนิษฐานทันทีว่าทั้งสองฝ่ายรองรับฟังก์ชันเหมือนกันทั้งหมด

ต้องดำเนินการเจรจาความสามารถก่อน

เนื้อหาที่ใช้เจรจาอาจประกอบด้วย:

• เวอร์ชัน SingLink

• Beta หรือ 2.0

• การรองรับ TCP

• การรองรับ UDP

• IPv4 / IPv6

• รองรับการกู้คืนเซสชันหรือไม่

• รองรับมัลติเพล็กซ์หรือไม่

• เฟรมข้อมูลขนาดสูงสุด

• กลยุทธ์ Padding

• ช่วงเวลาการส่ง heartbeat

• เปิดใช้การบีบอัดหรือไม่

• ขนาด MTU

• ความสามารถในการเจรจาใหม่

ตัวอย่าง:

ไคลเอนต์:
ฉันรองรับ SingLink 2.0
รองรับ TCP, UDP และ IPv6
รองรับ Session Resume
เฟรมสูงสุด 64KB

เซิร์ฟเวอร์:
ยืนยันการใช้ SingLink 2.0
ใช้งาน TCP และ UDP ได้
ใช้งาน Session Resume ได้
เฟรมสูงสุดจริง 32KB

ท้ายที่สุด ทั้งสองฝ่ายจะใช้ความสามารถที่รองรับร่วมกัน

เหตุใดจึงต้องเจรจา?

เพราะไคลเอนต์และโหนดอาจไม่ได้อัปเดตในวันเดียวกัน

หากไคลเอนต์ใหม่ส่งรูปแบบที่โหนดเก่าไม่รู้จักโดยตรง การเชื่อมต่อจะล้มเหลว

เวอร์ชัน 2.0 ที่เป็นทางการควรให้ความสำคัญมากกว่า Beta ในด้าน:

• ความเข้ากันได้ย้อนหลัง

• การย้อนกลับไปใช้เวอร์ชันก่อนหน้า

• การลดระดับอย่างปลอดภัยเมื่อไม่รองรับฟังก์ชัน

• การปฏิเสธเวอร์ชันที่เข้ากันไม่ได้อย่างชัดเจน

ขั้นตอนที่ 7: การยืนยันตัวตน

หลังจากเชื่อมต่อพื้นฐานเสร็จแล้ว โหนดต้องยืนยันว่าผู้ใช้มีสิทธิ์ใช้งานหรือไม่

ข้อมูลยืนยันที่แนะนำประกอบด้วย:

• Token ระยะสั้น

• บัญชีหรือ ID การอนุญาต

• ค่าสุ่มของไคลเอนต์

• เวอร์ชันโปรโตคอล

• ID โหนด

• ความสามารถที่ร้องขอ

• ข้อมูลตรวจสอบความสมบูรณ์

แพ็กเก็ตยืนยันแบบเข้าใจง่ายสามารถอธิบายได้ว่า:

ฉันคือใคร
ฉันต้องการใช้โหนดใด
ฉันต้องการใช้โปรโตคอลอะไร
หมายเลขสุ่มของการเชื่อมต่อครั้งนี้
การอนุญาตของฉันหมดอายุเมื่อใด
ข้อมูลถูกแก้ไขโดยผู้อื่นหรือไม่

ฝั่งเซิร์ฟเวอร์ต้องตรวจสอบ:

1. Token ออกโดยระบบทางการหรือไม่

2. Token หมดอายุหรือไม่

3. Token ถูกเพิกถอนแล้วหรือไม่

4. ผู้ใช้มีสิทธิ์เข้าถึงโหนดหรือไม่

5. ค่าสุ่มเคยถูกใช้แล้วหรือไม่

6. คำขอถูกนำกลับมาเล่นซ้ำหรือไม่

7. เวอร์ชันไคลเอนต์ได้รับอนุญาตให้เชื่อมต่อหรือไม่

การป้องกันการโจมตีแบบ Replay

ผู้โจมตีอาจบันทึกข้อมูลยืนยันที่ถูกต้องหนึ่งครั้ง แล้วส่งข้อมูลเดิมซ้ำอีก

ดังนั้น ข้อมูลยืนยันต้องมี:

• Nonce แบบใช้ครั้งเดียว

• Challenge จากเซิร์ฟเวอร์

• ระยะเวลาที่ใช้ได้สั้น

• บันทึกข้อมูลรับรองที่ใช้แล้ว

• การผูกกับเซสชัน

อธิบายอย่างง่าย:

ตั๋วใบเดิมที่ตรวจแล้วไม่ควรถูกคัดลอกไปใช้ได้ไม่จำกัดครั้ง

ขั้นตอนที่ 8: การแลกเปลี่ยนกุญแจและเซสชันเข้ารหัส

หลังจากยืนยันตัวตนผ่านแล้ว ไคลเอนต์และโหนดต้องสร้างกุญแจเซสชันเฉพาะสำหรับการเชื่อมต่อครั้งนี้

ตรรกะที่แนะนำคือ:

ไคลเอนต์สร้างกุญแจชั่วคราว
        ↓
เซิร์ฟเวอร์สร้างกุญแจชั่วคราว
        ↓
ทั้งสองฝ่ายแลกเปลี่ยนข้อมูลสาธารณะ
        ↓
แต่ละฝ่ายคำนวณกุญแจที่ใช้ร่วมกันซึ่งมีค่าเดียวกันภายในเครื่อง
        ↓
สร้างกุญแจเซสชันหลายชุดจากกุญแจที่ใช้ร่วมกัน

ควรแยกสร้าง:

• กุญแจเข้ารหัสจากไคลเอนต์ไปยังเซิร์ฟเวอร์

• กุญแจเข้ารหัสจากเซิร์ฟเวอร์ไปยังไคลเอนต์

• กุญแจตรวจสอบความสมบูรณ์ของข้อมูล

• กุญแจสำหรับกู้คืนเซสชัน

• กุญแจป้องกัน Header

ไม่ควรใช้กุญแจดอกเดียวกันร่วมกันในทุกทิศทางและทุกวัตถุประสงค์

Forward Secrecy

แนวทางที่เหมาะสมกว่าคือใช้กุญแจชั่วคราวสำหรับแต่ละเซสชัน

ด้วยวิธีนี้ แม้กุญแจระยะยาวของเซิร์ฟเวอร์ชุดหนึ่งจะรั่วไหลในภายหลัง ก็ไม่ควรทำให้สามารถถอดรหัสทราฟฟิกทั้งหมดที่บันทึกไว้ก่อนหน้านี้ได้โดยตรง

การหมุนเวียนกุญแจ

การเชื่อมต่อระยะยาวไม่ควรใช้กุญแจเซสชันชุดเดิมตลอดไป

สามารถสร้างกุญแจใหม่ตาม:

• ปริมาณข้อมูลที่ส่ง

• ระยะเวลาการเชื่อมต่อ

• จำนวนเฟรม

• คำสั่งจากเซิร์ฟเวอร์

เมื่อถึงเงื่อนไขข้อใดข้อหนึ่ง การเชื่อมต่อจะเปลี่ยนไปใช้กุญแจที่สร้างขึ้นใหม่

ตัวอย่าง:

ทุกครั้งที่ส่งข้อมูลครบหลาย GB
หรือ
เมื่อผ่านไประยะเวลาหนึ่ง
ให้สร้างกุญแจตามทิศทางขึ้นใหม่

ค่าเกณฑ์ที่แน่นอนกำหนดผ่านการทดสอบประสิทธิภาพและความปลอดภัย

ขั้นตอนที่ 9: การสร้าง Session

หลังจากจัดการตัวตนและกุญแจเสร็จแล้ว ทั้งสองฝ่ายจะสร้าง SingLink Session

Session อาจประกอบด้วย:

• Session ID

• เวอร์ชันโปรโตคอล

• พารามิเตอร์การเข้ารหัส

• ขนาดเฟรมสูงสุด

• ช่วงเวลาการส่ง heartbeat

• โหมด UDP

• จำนวน Stream สูงสุด

• ระยะหมดเวลาเมื่อไม่มีการใช้งาน

• ความสามารถในการกู้คืนเซสชัน

• กลยุทธ์ Beta หรือ 2.0

เซิร์ฟเวอร์ส่งการยืนยันกลับ:

ยืนยันตัวตนสำเร็จ
สร้างเซสชันสำเร็จ
ใช้ SingLink 2.0
ใช้งาน TCP ได้
ใช้งาน UDP ได้
ใช้งานมัลติเพล็กซ์ได้
เปิดใช้ heartbeat แล้ว

ไคลเอนต์ควรเริ่มส่งข้อมูลแอปพลิเคชันอย่างเป็นทางการหลังจากได้รับการยืนยันจากเซิร์ฟเวอร์เท่านั้น

ขั้นตอนที่ 10: การสร้าง Stream หรือการเชื่อมต่อพร็อกซีแยก

ในขั้นตอนนี้มีสถาปัตยกรรมที่นิยมใช้อยู่สองแบบ:

ทางเลือกที่ 1: หนึ่ง Session รองรับหลาย Stream

แนวคิดคล้าย AnyTLS:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: เบราว์เซอร์

แต่ละ Stream ต้องมี:

• Stream ID

• ที่อยู่ปลายทาง

• พอร์ตปลายทาง

• TCP หรือ UDP

• สถานะปัจจุบัน

• หน้าต่างการส่ง

• หน้าต่างการรับ

ข้อดี:

• ลดการ handshake ซ้ำ

• ลดค่าหน่วงในการเชื่อมต่อ

• ลดจำนวนการเชื่อมต่อชั้นล่าง

• เหมาะกับการเชื่อมต่อระยะสั้นจำนวนมาก

ความเสี่ยง:

• หาก Session หนึ่งมีปัญหา อาจส่งผลต่อหลาย Stream

• ชั้น TCP เดียวอาจเกิด head-of-line blocking

• ต้องมีการควบคุมการไหลที่สมบูรณ์

ทางเลือกที่ 2: สร้างการเชื่อมต่อแยกสำหรับแต่ละคำขอของแอปพลิเคชัน

ChatGPT → การเชื่อมต่อแยก
YouTube → การเชื่อมต่อแยก
Telegram → การเชื่อมต่อแยก

ข้อดี:

• ทราฟฟิกแต่ละประเภทแยกจากกัน

• การเชื่อมต่อหนึ่งล้มเหลวไม่กระทบการเชื่อมต่ออื่น

• ตรรกะเรียบง่ายกว่า

ข้อเสีย:

• มีการ handshake มากกว่า

• ค่าใช้จ่ายในการเชื่อมต่อสูงกว่า

• มีประสิทธิภาพต่ำกว่าเมื่อมีการเชื่อมต่อระยะสั้นจำนวนมาก

ข้อเสนอแนะ

SingLink สามารถใช้โหมดผสม:

• ใช้มัลติเพล็กซ์ของ Session สำหรับการเชื่อมต่อระยะสั้นและหน้าเว็บทั่วไป

• สร้างช่องทางแยกสำหรับการดาวน์โหลดข้อมูลจำนวนมากและวิดีโอ

• ประมวลผล UDP ที่ต้องการค่าหน่วงต่ำแยกต่างหาก

• ป้องกันไม่ให้การดาวน์โหลดความเร็วสูงรายการเดียวใช้ความจุของ Stream ทั้งหมด

ขั้นตอนที่สิบเอ็ด: การห่อหุ้มเฟรมข้อมูล

ไม่สามารถโยนข้อมูลแอปพลิเคชันเข้าสู่ช่องทางรับส่งโดยตรงในรูปเดิมได้ แต่ต้องห่อหุ้มเป็นเฟรมของโปรโตคอล

ในเชิงแนวคิด เฟรม SingLink อาจประกอบด้วย:

เวอร์ชัน
ประเภทเฟรม
Session ID
Stream ID
หมายเลขลำดับ
Flags
ความยาวข้อมูล
ข้อมูลที่เข้ารหัส
เครื่องหมายความครบถ้วนสมบูรณ์

ประเภทเฟรมต่าง ๆ อาจประกอบด้วย:

นี่เป็นเพียงข้อเสนอแนะในระดับการออกแบบโปรโตคอล ไม่ได้หมายความว่า SingLink ในปัจจุบันใช้ชื่อหรือรูปแบบบิตเหล่านี้แล้ว

ขั้นตอนที่สิบสอง: การจัดการทราฟฟิก TCP

สำหรับการเชื่อมต่อ TCP เช่น หน้าเว็บ API และการดาวน์โหลดไฟล์ SingLink จำเป็นต้องรักษา:

• ลำดับข้อมูล;

• การรับส่งสองทิศทาง;

• สถานะการปิด;

• การควบคุมการไหล;

• สถานะข้อผิดพลาด

กระบวนการทั้งหมดอาจเป็นดังนี้:

แอปพลิเคชันสร้างการเชื่อมต่อ TCP
        ↓
ไคลเอนต์สร้าง SingLink Stream
        ↓
ส่งชื่อโดเมนและพอร์ตปลายทาง
        ↓
โหนดเชื่อมต่อเว็บไซต์ปลายทาง
        ↓
โหนดรายงานว่าสำเร็จหรือล้มเหลว
        ↓
เริ่มส่งต่อแบบสองทิศทาง

การปิดตามปกติ

เมื่อแอปพลิเคชันยุติการเชื่อมต่อ:

1. ไคลเอนต์ส่ง FIN;

2. โหนดหยุดรับข้อมูลในทิศทางนั้น;

3. รอให้อีกทิศทางหนึ่งเสร็จสิ้น;

4. ปิด Stream อย่างสมบูรณ์;

5. คืนหน่วยความจำและสถานะการเชื่อมต่อ

การปิดอย่างผิดปกติ

เช่น เมื่อเว็บไซต์ปลายทางปฏิเสธการเชื่อมต่อ:

1. โหนดส่งข้อผิดพลาดกลับ;

2. ไคลเอนต์แจ้งแอปพลิเคชันว่าการเชื่อมต่อล้มเหลว;

3. ล้าง Stream ทันที;

4. ไม่กระทบ Stream อื่น

ขั้นตอนที่สิบสาม: การจัดการทราฟฟิก UDP

UDP ไม่มีแนวคิดการเชื่อมต่อแบบ TCP ดั้งเดิม แต่ละแพ็กเก็ตจึงต้องเก็บรักษา:

• ความสัมพันธ์กับต้นทาง;

• ที่อยู่ปลายทาง;

• พอร์ตปลายทาง;

• ความยาวข้อมูล;

• ขอบเขตแพ็กเก็ต;

• การหมดเวลาของเซสชัน

ตัวอย่าง:

UDP Association ID
ที่อยู่ปลายทาง
พอร์ตปลายทาง
ความยาวข้อมูล
UDP Payload

SingLink จำเป็นต้องเลือกให้ชัดเจน:

UDP-over-TCP

นำแพ็กเก็ต UDP ใส่ใน TCP หรือ Session ที่เชื่อถือได้เพื่อรับส่ง

ข้อดี:

• ผ่านเครือข่ายที่อนุญาตเฉพาะ TCP ได้ง่าย;

• ข้อมูลสูญหายได้ยาก;

• ติดตั้งใช้งานง่าย

ข้อเสีย:

• เมื่อ TCP ทำแพ็กเก็ตสูญหาย ข้อมูล UDP ที่ตามมาจะถูกบล็อก;

• ไม่เหมาะกับเกม เสียง และสถานการณ์แบบเรียลไทม์บางประเภท

UDP แบบเนทีฟ

ใช้ UDP เป็นตัวนำส่งโดยตรง

ข้อดี:

• เวลาแฝงต่ำ;

• เหมาะกับเกม เสียง และ QUIC;

• ไม่ได้รับผลจากการบล็อกหัวแถวของ TCP

ข้อเสีย:

• บางเครือข่ายจำกัด UDP;

• การจัดการ NAT และไฟร์วอลล์ซับซ้อนกว่า

การรับส่งแบบ QUIC

ทำงานบน UDP แต่ให้ความสามารถต่อไปนี้ในระดับโปรโตคอล:

• การเข้ารหัส;

• การส่งซ้ำ;

• หลาย Stream;

• การควบคุมความแออัด;

• การย้ายเครือข่าย

มีความสามารถทางเทคนิคครบถ้วนกว่า แต่มีความซับซ้อนในการพัฒนาสูงกว่า

ทิศทางที่สมเหตุสมผลกว่าสำหรับ SingLink คือ:

ตัดสินใจโดยอัตโนมัติตามเครือข่ายและประเภททราฟฟิกว่า UDP ควรใช้การรับส่งแบบเนทีฟ การห่อหุ้มที่เชื่อถือได้ หรือโหมดที่เข้ากันได้อื่น

ขั้นตอนที่สิบสี่: การควบคุมการไหลและแรงดันย้อนกลับ

สมมติว่า YouTube ดาวน์โหลดเร็วมาก ขณะที่ ChatGPT รับส่งข้อความเพียงเล็กน้อย

หากไม่มีการควบคุมการไหล Stream วิดีโออาจใช้ช่องทางทั้งหมดจนเต็ม ส่งผลให้:

• การตอบกลับของ ChatGPT ช้าลง;

• DNS ล่าช้า;

• แอปพลิเคชันอื่นค้าง;

• การใช้หน่วยความจำเพิ่มขึ้นอย่างต่อเนื่อง

ดังนั้นจึงต้องมีการควบคุมการไหลสองระดับ:

ระดับ Session

จำกัดปริมาณข้อมูลที่ยังไม่ได้รับการยืนยันซึ่งทั้ง Session สามารถรับส่งพร้อมกันได้

ระดับ Stream

จำกัดขนาดหน้าต่างการรับส่งที่แต่ละ Stream สามารถครอบครองได้

กล่าวอย่างง่ายคือ:

ทางด่วนเส้นหนึ่งไม่ควรปล่อยให้รถบรรทุกขนาดใหญ่คันเดียวกินพื้นที่ทุกช่องทาง แต่ละ Stream ต้องได้รับการจัดสรรทรัพยากรของเส้นทางอย่างเหมาะสม

โปรโตคอล 2.0 รุ่นทางการสามารถใช้การจัดตารางทราฟฟิกที่ระมัดระวังกว่า Beta เพื่อไม่ให้การไล่ตามความเร็วสูงสุดกระทบการเชื่อมต่ออื่น

ขั้นตอนที่สิบห้า: การแบ่งแพ็กเก็ต Padding และรูปลักษณ์ทราฟฟิก

หลังเข้ารหัสข้อมูลแล้ว บุคคลภายนอกยังอาจมองเห็น:

• ความยาวแพ็กเก็ต;

• ช่วงเวลาการส่ง;

• ระยะเวลาการเชื่อมต่อ;

• สัดส่วนขาขึ้นและขาลง;

• พฤติกรรมการเชื่อมต่อใหม่

ดังนั้นโปรโตคอลจึงสามารถปรับแต่งรูปลักษณ์ทราฟฟิก เช่น:

• แบ่งข้อมูลขนาดใหญ่ออกเป็นหลายเฟรม;

• รวมข้อมูลขนาดเล็ก;

• เพิ่ม Padding ที่เปลี่ยนแปลงได้;

• ปรับชุดการส่ง;

• หลีกเลี่ยงไม่ให้แฮนด์เชคทั้งหมดมีความยาวคงที่;

• อัปเดตกลยุทธ์ Padding เป็นระยะ

แต่ต้องระบุให้ชัดเจนว่า:

Padding ไม่สามารถทดแทนการเข้ารหัส และไม่อาจรับประกันได้ว่าทราฟฟิกจะไม่มีวันถูกระบุได้

การใช้ Padding มากเกินไปยังทำให้:

• ใช้ทราฟฟิกมากขึ้น;

• เวลาแฝงสูงขึ้น;

• ใช้ CPU มากขึ้น;

• สิ้นเปลืองโควตาฟรี

ดังนั้น 2.0 จึงสามารถใช้กลยุทธ์แบบปรับตัว:

• เมื่อเครือข่ายปกติ ให้ใช้โอเวอร์เฮดต่ำ;

• เพิ่มการปรับรูปลักษณ์ในสภาพแวดล้อมเครือข่ายพิเศษ;

• ลด Padding ที่ไม่จำเป็นเมื่อดาวน์โหลดความเร็วสูง;

• เติมข้อมูลควบคุมขนาดเล็กอย่างเหมาะสม

ส่วน Beta อาจเน้นลดโอเวอร์เฮดเพิ่มเติมมากกว่า เพื่อเพิ่มความเร็วสูงสุด

ขั้นตอนที่สิบหก: การจัดการ MTU และขนาดแพ็กเก็ต

เมื่อเพิ่มส่วนหัวของโปรโตคอลและข้อมูลเข้ารหัสลงในทราฟฟิก TUN แล้ว แพ็กเก็ตจะมีขนาดใหญ่ขึ้น

หากเกิน MTU ของเครือข่าย อาจเกิด:

• การแบ่งส่วน IP;

• แพ็กเก็ตถูกทิ้ง;

• บางเว็บไซต์เปิดไม่ได้;

• ความเร็วขึ้นลงไม่สม่ำเสมอ;

• VPN เชื่อมต่อแล้วแต่รับส่งข้อมูลไม่ได้

SingLink จำเป็นต้อง:

1. กำหนด TUN MTU;

2. หักขนาดส่วนหัวโปรโตคอล;

3. หักโอเวอร์เฮดจากการเข้ารหัส;

4. ปรับตาม IPv4 และ IPv6;

5. แบ่งข้อมูลเมื่อจำเป็น;

6. หลีกเลี่ยงการแบ่งส่วน IP ที่ไม่จำเป็น

นี่คือเหตุผลที่ขนาดแพ็กเก็ตคงที่ชุดเดียวอาจไม่เหมาะกับทุกเครือข่าย

2.0 รุ่นทางการควรมีการจัดการความเข้ากันได้ของ MTU ข้ามแพลตฟอร์มที่สมบูรณ์กว่า ส่วน Beta หากใช้กลยุทธ์เฟรมขนาดใหญ่ที่เข้มข้นกว่า อาจทำความเร็วสูงได้ในบางเครือข่าย แต่มีเสถียรภาพต่ำกว่าในเครือข่ายพิเศษ

ขั้นตอนที่สิบเจ็ด: การจัดการเวลาแฝง แพ็กเก็ตสูญหาย และความแออัด

ไคลเอนต์จำเป็นต้องเฝ้าสังเกตอย่างต่อเนื่อง:

• เวลาแฝง RTT;

• ความผันผวนของเวลาแฝง;

• แพ็กเก็ตสูญหาย;

• ความเร็วการส่ง;

• ความเร็วการรับ;

• ข้อมูลที่ยังไม่ได้รับการยืนยัน;

• การตอบสนองของโหนด

ไม่ควรพึ่งพา Ping เพียงครั้งเดียว

ตัวอย่าง:

ปกติ: 60ms
เพิ่มขึ้นชั่วคราว: 120ms
เพิ่มขึ้นต่อเนื่อง: 500ms
ไม่ตอบสนองโดยสิ้นเชิง: หมดเวลา

แต่ละสถานการณ์ต้องจัดการต่างกัน:

หากเชื่อมต่อใหม่ทุกครั้งที่พบแพ็กเก็ตสูญหายเพียงครั้งเดียว กลับจะทำให้โปรโตคอลไม่เสถียรยิ่งขึ้น

ขั้นตอนที่สิบแปด: Heartbeat และการตรวจสอบความพร้อมใช้งาน

เมื่อไม่มีข้อมูลแอปพลิเคชันเป็นเวลานาน ระบบยังจำเป็นต้องทราบว่าช่องทางยังทำงานอยู่หรือไม่

สามารถใช้:

PING
↓
PONG

แต่ heartbeat ต้องไม่ถี่เกินไป

หากถี่เกินไปจะ:

• สิ้นเปลืองพลังงาน;

• ใช้ทราฟฟิก;

• เพิ่มภาระเซิร์ฟเวอร์;

• ก่อให้เกิดลักษณะเฉพาะด้านเวลาที่คงที่

หากห่างเกินไปจะ:

• ใช้เวลานานกว่าจะพบว่าโหนดล้มเหลว;

• แอปพลิเคชันรอนานเกินไป;

• กู้คืนจากการเปลี่ยนเครือข่ายได้ช้า

ดังนั้น heartbeat จึงปรับตามสถานะได้:

• เมื่อมีทราฟฟิกปกติ ไม่ส่ง heartbeat เพิ่ม;

• เริ่ม heartbeat ความถี่ต่ำหลังว่างช่วงหนึ่ง;

• เพิ่มความถี่การตรวจสอบชั่วคราวเมื่อเพิ่งเปลี่ยนเครือข่าย;

• ตัดสินว่าการเชื่อมต่อขาดหายหลังล้มเหลวหลายครั้ง

ขั้นตอนที่สิบเก้า: การเปลี่ยนเครือข่ายและการกู้คืนเซสชัน

เมื่อโทรศัพท์เปลี่ยนจาก Wi-Fi เป็น 5G การเชื่อมต่อเดิมมักจะใช้การไม่ได้

การจัดการที่สมบูรณ์ควรเป็น:

ตรวจพบว่าเครือข่ายเปลี่ยน
        ↓
หยุดส่งข้อมูลใหม่ไปยังช่องทางที่ใช้การไม่ได้ชั่วคราว
        ↓
รับ IP ภายในและเส้นทางใหม่
        ↓
เชื่อมต่อโหนดเดิมอีกครั้ง
        ↓
ส่งข้อมูลรับรองสำหรับกู้คืนเซสชัน
        ↓
เซิร์ฟเวอร์ตรวจสอบ Session เดิม
        ↓
กู้คืนโฟลว์เชิงตรรกะที่กู้คืนได้
        ↓
แจ้งแอปพลิเคชันให้สร้างการเชื่อมต่อ TCP ที่กู้คืนไม่ได้ขึ้นใหม่

สิ่งที่ต้องระวัง:

ไม่ใช่ทุกการเชื่อมต่อ TCP ของแอปพลิเคชันจะกู้คืนได้อย่างไร้รอยต่อ

โปรโตคอลสามารถกู้คืน:

• เซสชัน;

• การอนุญาตของโหนด;

• พารามิเตอร์โปรโตคอล;

• Stream บางส่วนที่ยังมีสถานะ

แต่หากการเชื่อมต่อ TCP ของเว็บไซต์ปลายทางเองขาดไปแล้ว แอปพลิเคชันอาจยังต้องเชื่อมต่อใหม่

ดังนั้นเราจึงไม่กล่าวอ้างว่า:

เมื่อเปลี่ยนเครือข่าย ทุกแอปพลิเคชันจะไม่รู้สึกถึงผลกระทบใด ๆ เสมอไป

ถ้อยคำที่แม่นยำกว่าคือ:

SingLink 2.0 จะลดเวลาเชื่อมต่อใหม่ กู้คืนสถานะโปรโตคอลและเส้นทาง พร้อมลดผลกระทบต่อแอปพลิเคชันให้มากที่สุด

ขั้นตอนที่ยี่สิบ: โหนดล้มเหลวและการสลับอัตโนมัติ

ความผิดปกติของโหนดแบ่งได้เป็น:

ความขัดข้องแบบไม่รุนแรง

• เวลาแฝงสูงขึ้น;

• แพ็กเก็ตสูญหายเป็นครั้งคราว;

• ไม่ตอบสนองชั่วคราว;

• ปลายทางบางแห่งใช้งานไม่ได้

วิธีจัดการ:

• รอชั่วคราว;

• ลดแรงกดดันในการรับส่ง;

• วัดผลใหม่;

• ลองเชื่อมต่อโหนดเดิมใหม่

ความขัดข้องรุนแรง

• ไม่สามารถเชื่อมต่อโหนดได้โดยสิ้นเชิง;

• อินเทอร์เฟซยืนยันตัวตนใช้งานไม่ได้;

• หมดเวลาอย่างต่อเนื่อง;

• โหนดถูกนำออกจากระบบ

วิธีจัดการ:

1. หยุดใช้โหนดเดิม;

2. เลือกโหนดทดแทนจากรายการที่ใช้ได้;

3. สร้างเซสชันปลอดภัยใหม่;

4. กู้คืน DNS และเส้นทาง;

5. แจ้งแอปพลิเคชันให้สร้างการเชื่อมต่อที่จำเป็นใหม่

2.0 รุ่นทางการสามารถใช้กลยุทธ์สลับที่ระมัดระวังกว่า เพื่อหลีกเลี่ยงการกระโดดเปลี่ยนโหนดบ่อยครั้งเพราะความผันผวนชั่วคราว

ส่วน Beta สามารถใช้กลยุทธ์เชื่อมต่อใหม่หรือเลือกโหนดความเร็วสูงที่เข้มข้นกว่า แต่อาจทำให้เกิดความผันผวนสูงขึ้น

ขั้นตอนที่ยี่สิบเอ็ด: ข้อมูลขากลับและการแกะห่อ

กระบวนการส่งข้อมูลกลับจากเว็บไซต์ปลายทางคือ:

เว็บไซต์ปลายทางส่งข้อมูลกลับ
        ↓
โหนด SingLink รับข้อมูล
        ↓
ค้นหา Session และ Stream ที่ตรงกัน
        ↓
ห่อหุ้มเป็นเฟรมข้อมูล SingLink
        ↓
เข้ารหัสและส่งให้ไคลเอนต์
        ↓
ไคลเอนต์ตรวจสอบความครบถ้วนสมบูรณ์
        ↓
ถอดรหัส
        ↓
แยกโฟลว์ตาม Stream ID
        ↓
เขียนลง TUN หรือพร็อกซีระบบ
        ↓
ส่งคืนให้แอปพลิเคชันเดิม

ไคลเอนต์จำเป็นต้องตรวจสอบ:

• ข้อมูลถูกแก้ไขหรือไม่;

• หมายเลขลำดับถูกต้องหรือไม่;

• เป็นเฟรมซ้ำหรือไม่;

• Stream ยังมีอยู่หรือไม่;

• ความยาวเป็นไปตามข้อจำกัดหรือไม่;

• เกินหน้าต่างรับหรือไม่

ห้ามส่งข้อมูลที่ผิดพลาดให้แอปพลิเคชันโดยตรง

ขั้นตอนที่ยี่สิบสอง: การตัดการเชื่อมต่อตามปกติและการล้างข้อมูลอย่างปลอดภัย

หลังผู้ใช้คลิกตัดการเชื่อมต่อ ไคลเอนต์ควร:

1. หยุดรับทราฟฟิกพร็อกซีใหม่;

2. ปิด Stream ที่ทำงานอยู่ตามปกติ;

3. ส่งคำสั่งสิ้นสุดเซสชันไปยังโหนด;

4. ล้างคีย์ของเซสชัน;

5. เพิกถอนหรือทิ้ง Token ระยะสั้น;

6. ปิด TUN;

7. กู้คืนเส้นทางระบบ;

8. กู้คืน DNS;

9. ล้างการกำหนดค่าชั่วคราวที่ไม่จำเป็น

หากไคลเอนต์ขัดข้องโดยตรง ระบบปฏิบัติการหรือการเปิดใช้งานครั้งถัดไปก็ต้องซ่อมแซมด้วย เพื่อหลีกเลี่ยงการทิ้ง:

• พร็อกซีระบบที่ใช้การไม่ได้;

• DNS ที่ผิดพลาด;

• เส้นทางตกค้าง;

• ไม่สามารถใช้อินเทอร์เน็ต

ความแตกต่างด้านกลยุทธ์รายละเอียดระหว่าง SingLink Beta กับ 2.0

ตารางด้านล่างสรุปการวางตำแหน่งทางเทคนิคของ SingLink Beta และ SingLink 2.0

สรุปหลักการทำงานทั้งหมดในประโยคเดียว

SingLink เริ่มจากให้ไคลเอนต์ควบคุมทราฟฟิกของอุปกรณ์ ดำเนินการ DNS การแยกเส้นทางอัจฉริยะ และการเลือกโหนด จากนั้นตรวจสอบบัญชีและสิทธิ์ของโหนด เจรจาความสามารถของโปรโตคอลกับโหนด และสร้างคีย์เข้ารหัสชั่วคราว เมื่อสร้างการเชื่อมต่อแล้ว ทราฟฟิก TCP และ UDP ของแต่ละแอปพลิเคชันจะถูกห่อหุ้มเป็นการเชื่อมต่อพร็อกซีหรือ Stream เชิงตรรกะที่แยกจากกัน ส่งผ่านช่องทางที่ได้รับการปกป้องไปยังโหนด แล้วให้โหนดเข้าถึงเว็บไซต์ปลายทาง ระหว่างการรับส่ง ระบบจะจัดการหน้าต่างทราฟฟิก ความครบถ้วนสมบูรณ์ของข้อมูล เวลาแฝง แพ็กเก็ตสูญหาย heartbeat และสถานะโหนดอย่างต่อเนื่อง เมื่อพบการเปลี่ยนเครือข่ายหรือโหนดล้มเหลว ระบบจะสร้างเซสชันใหม่ กู้คืนเส้นทาง หรือสลับไปยังโหนดที่ใช้ได้

ส่วนความแตกต่างสำคัญระหว่าง Beta กับ 2.0 คือ:

SingLink Beta มุ่งไล่ตามความเร็วสูงสุดอย่างเข้มข้นกว่า ส่วน SingLink 2.0 เพิ่มความเข้ากันได้ การตรวจสอบความพร้อมใช้งาน การวินิจฉัยความผิดปกติ การกู้คืนเซสชัน และการจัดการข้ามแพลตฟอร์มที่สมบูรณ์ยิ่งขึ้นนอกเหนือจากการรับส่งความเร็วสูง จึงมีอัตราเสถียรภาพสูงกว่า

คำถามที่พบบ่อย

SingLink 2.0 คืออะไร?

SingLink 2.0 คือโปรโตคอลรับส่งข้อมูลเครือข่ายรุ่นทางการที่ SingLink VPN พัฒนาขึ้นเอง รับผิดชอบการยืนยันตัวตน เซสชันเข้ารหัส การห่อหุ้มทราฟฟิก การรับส่ง TCP และ UDP การตรวจสอบความพร้อมใช้งาน และการกู้คืนจากความผิดปกติ

SingLink 2.0 เป็นเวอร์ชันซอฟต์แวร์หรือไม่?

ไม่ใช่ SingLink 2.0 คือชื่ออย่างเป็นทางการของโปรโตคอล ซึ่งเป็นระบบเวอร์ชันคนละชุดกับเวอร์ชันไคลเอนต์ Windows, macOS, Android และ iOS

SingLink Beta กับ 2.0 ต่างกันอย่างไร?

Beta เป็นโปรโตคอลรุ่นตัวอย่างที่ให้ความสำคัญกับความเร็ว โดยในสภาวะที่เหมาะสมอาจมีความเร็วสูงสุดมากกว่า 1 Gbps ส่วน 2.0 เป็นโปรโตคอลรุ่นทางการที่ให้ความสำคัญกับความเร็ว เสถียรภาพ ความเข้ากันได้ข้ามแพลตฟอร์ม และการกู้คืนเมื่อการเชื่อมต่อขาด

อัตราเสถียรภาพของ SingLink 2.0 คือเท่าใด?

ในการทดสอบ A/B ภายในสภาพแวดล้อมทดสอบที่ SingLink VPN กำหนด SingLink 2.0 มีอัตราเสถียรภาพ 99.5% ขณะที่ Beta สูงสุดประมาณ 97%

SingLink จัดการทราฟฟิกเครือข่ายอย่างไร?

ไคลเอนต์จะควบคุมทราฟฟิกระบบก่อน ดำเนินการ DNS และการแยกเส้นทางอัจฉริยะ จากนั้นตรวจสอบบัญชีและสิทธิ์ของโหนด สร้างเซสชันเข้ารหัส ห่อหุ้มข้อมูล TCP หรือ UDP แล้วส่งไปยังโหนด

SingLink จัดการเมื่อการเชื่อมต่อขาดอย่างไร?

ระบบจะตรวจสอบเวลาแฝง แพ็กเก็ตสูญหาย heartbeat และสถานะโหนดอย่างต่อเนื่อง เมื่อเกิดความผิดปกติ สามารถสร้างเซสชันใหม่ กู้คืนเส้นทาง หรือสลับไปยังโหนดที่ใช้ได้

SingLink ต่างจาก VLESS อย่างไร?

แกนหลักของ VLESS เน้นการยืนยันตัวตน คำสั่ง และการส่งต่อไปยังปลายทาง ส่วน SingLink รวมการยืนยันตัวตน เส้นทาง สิทธิ์ของโหนด กลยุทธ์การรับส่ง การตรวจสอบความพร้อมใช้งาน และการกู้คืนจากความผิดปกติไว้เป็นระบบโปรโตคอล

SingLink ต่างจาก AnyTLS อย่างไร?

AnyTLS ใช้การเชื่อมต่อ TLS เป็นหลักในการนำส่ง Session และ Stream หลายรายการ ส่วน SingLink มีขอบเขตกว้างกว่า โดยยังครอบคลุมการกำหนดเส้นทางอัจฉริยะ สิทธิ์สมาชิก การจัดตารางโหนด และการกู้คืนการเชื่อมต่อ การพัฒนา Session และ Stream ที่เจาะจงยังต้องยึดเอกสารทางเทคนิคฉบับทางการเป็นหลัก

ผู้ใช้ใดสามารถใช้ SingLink 2.0 ได้บ้าง?

โหนดโปรโตคอล SingLink 2.0 รุ่นทางการเปิดให้สมาชิก Pro, Max และ Rich ส่วนโปรโตคอล Beta ใช้ได้กับทุกแผน รวมถึงแผนฟรี สิทธิ์จริงให้ยึดตามที่แสดงในไคลเอนต์เวอร์ชันล่าสุด

SingLink 2.0 เปิดซอร์สอย่างสมบูรณ์แล้วหรือยัง?

ขณะนี้ยังไม่ได้เปิดเผยซอร์สโค้ดหลักของโปรโตคอลทั้งหมด แต่เอกสารทางเทคนิค วิธีทดสอบ รูปแบบข้อมูล เครื่องมือตรวจสอบ และกลไกเปิดเผยช่องโหว่ ได้รวมอยู่ในแผนโอเพนซอร์สอย่างต่อเนื่องแล้ว

ข้อมูลที่เกี่ยวข้องและอ่านเพิ่มเติม

การวางตำแหน่งผลิตภัณฑ์และขอบเขตการเปิดเผยในบทความนี้อ้างอิงพร้อมกันจากศูนย์เทคนิคทางการของ SingLink VPN, คลังงานวิจัยสาธารณะของ SingLinkLabs และวิธีทดสอบประสิทธิภาพของคลังดังกล่าว

เนื้อหาอื่นที่เกี่ยวข้องสามารถอ่านได้ที่คู่มือฉบับสมบูรณ์สำหรับแผนฟรีของ SingLink VPN, แผนโอเพนซอร์สของ SingLink VPN และรายงานการตรวจสอบความปลอดภัย SingLink VPN ปี 2026。

คำอธิบายทางเทคนิค: ตัวเลข 99.5%, 97% และมากกว่า 1 Gbps ในบทความนี้ เป็นผลการทดสอบ A/B ภายในและการทดสอบความเร็วสูงสุดในสภาพแวดล้อมที่กำหนดตามลำดับ ไม่ได้หมายความว่าทุกภูมิภาค อุปกรณ์ ผู้ให้บริการเครือข่าย และช่วงเวลาจะได้ผลลัพธ์เดียวกัน เนื้อหาที่เกี่ยวข้องกับอัลกอริทึมเข้ารหัส รูปแบบแพ็กเก็ต และกลไก Session กับ Stream ที่เจาะจง ควรยึดเอกสารทางเทคนิคฉบับทางการและซอร์สโค้ดสาธารณะของ SingLink ที่จะเผยแพร่ในภายหลังเป็นหลัก