Giao thức SingLink 2.0

SingLink 2.0 là giao thức truyền tải mạng chính thức do SingLinkVPN tự nghiên cứu và phát triển. “2.0” biểu thị tên và thế hệ của giao thức, không phải số phiên bản phần mềm của ứng dụng khách SingLinkVPN.

Giao thức SingLink không chỉ chịu trách nhiệm truyền lưu lượng đến nút VPN mà còn bao gồm xác thực tài khoản và quyền truy cập nút, xử lý DNS, phân luồng thông minh, phiên mã hóa, đóng gói TCP và UDP, kiểm tra tình trạng kết nối, chuyển đổi mạng và khôi phục khi xảy ra sự cố.

SingLink hiện được chia thành giao thức chính thức SingLink 2.0 và giao thức xem trước SingLink Beta ưu tiên tốc độ. Trong thử nghiệm A/B nội bộ, SingLink 2.0 đạt tỷ lệ ổn định 99.5%, còn Beta đạt tối đa khoảng 97%; trong điều kiện mạng và thiết bị phù hợp, tốc độ đỉnh của Beta có thể vượt 1 Gbps.

So sánh dữ liệu cốt lõi: Trong môi trường thử nghiệm được chỉ định, SingLink 2.0 chính thức ghi nhận tỷ lệ ổn định 99.5%; Beta đạt tối đa khoảng 97%, nhưng trong điều kiện mạng và thiết bị phù hợp, tốc độ đỉnh có thể vượt 1 Gbps. Các kết quả này lần lượt phản ánh định hướng về độ ổn định và tốc độ, không nên được xem trực tiếp là giá trị được bảo đảm cho mọi thiết bị và mạng.

Bằng chứng và giới hạn kỹ thuật: Có thể trích dẫn trực tiếp định vị sản phẩm, tiêu chí thử nghiệm nội bộ và các tính năng công khai đã được xác nhận; những nội dung trong bài viết này liên quan đến thuật toán mã hóa cụ thể, định dạng gói tin, thương lượng năng lực, Session, Stream, ghép kênh và khôi phục phiên thuộc mô hình xử lý tham khảo, không thể được xem là đặc tả hiện đã triển khai; cần lấy tài liệu kỹ thuật chính thức và mã nguồn công khai sau này của SingLink làm chuẩn.

Nguyên lý xử lý hoàn chỉnh của giao thức SingLink

Toàn bộ hệ thống có thể được chia thành hai mặt:

Mặt điều khiển

Chịu trách nhiệm:

• Đăng nhập tài khoản;

• Xác thực thành viên;

• Lấy danh sách nút;

• Xác định quyền truy cập nút;

• Phân phối cấu hình giao thức;

• Cập nhật quy tắc;

• Chọn Beta hoặc 2.0.

Mặt dữ liệu

Chịu trách nhiệm:

• Tiếp nhận lưu lượng ứng dụng;

• Phân giải DNS;

• Thiết lập kết nối an toàn;

• Đóng gói và truyền TCP, UDP;

• Duy trì kết nối;

• Xử lý mất kết nối;

• Trả dữ liệu về cho ứng dụng.

Quy trình đơn giản hóa như sau:

Người dùng đăng nhập SingLinkVPN
        ↓
Lấy các nút và cấu hình giao thức đã được cấp quyền
        ↓
Ứng dụng khách thiết lập TUN／proxy hệ thống
        ↓
Tiếp nhận lưu lượng ứng dụng
        ↓
Đánh giá theo DNS và quy tắc phân luồng
        ↓
Chọn nút SingLink 2.0 hoặc Beta
        ↓
Thương lượng năng lực giao thức
        ↓
Xác thực tài khoản và quyền của thiết bị
        ↓
Thiết lập phiên mã hóa và khóa phiên
        ↓
Tạo luồng logic độc lập cho từng kết nối ứng dụng
        ↓
Đóng gói dữ liệu TCP／UDP
        ↓
Truyền đến nút SingLink
        ↓
Nút giải đóng gói và truy cập trang web đích
        ↓
Trả dữ liệu về và phân phối cho ứng dụng ban đầu
        ↓
Liên tục kiểm tra độ trễ, mất gói và trạng thái kết nối
        ↓
Kết nối lại, khôi phục hoặc chuyển nút khi xảy ra sự cố

Giai đoạn một: Đăng nhập, lấy danh sách nút và cấu hình giao thức

Sau khi người dùng mở SingLinkVPN và đăng nhập, ứng dụng khách không nên ngay lập tức lưu vĩnh viễn toàn bộ địa chỉ nút sản xuất, thông tin xác thực và tham số giao thức trên thiết bị.

Quy trình xử lý hợp lý hơn là:

1. Ứng dụng khách gửi thông tin xác thực đăng nhập tài khoản;

2. Hệ thống tài khoản xác thực người dùng;

3. Hệ thống xác nhận gói dịch vụ và quyền truy cập nút;

4. Trả về danh sách nút mà người dùng có thể sử dụng;

5. Trả về thông tin xác thực kết nối có hiệu lực ngắn hạn;

6. Trả về phiên bản giao thức hiện tại và cấu hình cần thiết;

7. Ứng dụng khách xác minh tính toàn vẹn của cấu hình;

8. Lưu cấu hình nhạy cảm trong vùng lưu trữ an toàn của hệ thống.

Lớp này chủ yếu xác định:

• Người dùng có phải là thành viên hợp lệ hay không;

• Có thể sử dụng Beta hay 2.0;

• Có quyền Pro, Max hay Rich hay không;

• Có thể sử dụng những quốc gia và nút nào;

• Cấu hình đã hết hạn hay chưa;

• Phiên bản ứng dụng khách có cần cập nhật hay không.

Cách hiểu đơn giản

Giống như trước khi đi tàu cao tốc, hệ thống sẽ kiểm tra:

• Bạn là ai;

• Bạn đã mua vé hạng nào;

• Bạn có thể đi chuyến tàu nào;

• Vé còn hiệu lực hay không.

Quy tắc bảo mật được đề xuất

SingLink không nên phụ thuộc lâu dài vào một mật khẩu tĩnh không bao giờ thay đổi.

Hợp lý hơn là sử dụng:

• Token kết nối ngắn hạn;

• Challenge dùng một lần;

• Nonce ngẫu nhiên của thiết bị;

• Giới hạn thời hạn hiệu lực;

• Cấu hình nút được máy chủ ký;

• Cơ chế thu hồi.

Theo cách này, ngay cả khi cấu hình của một lần kết nối bị lấy được, điều đó cũng không có nghĩa là có thể sử dụng vĩnh viễn.

Giai đoạn hai: Thiết lập điểm vào mạng của hệ thống

Sau khi người dùng nhấn kết nối, SingLinkVPN cần thiết lập điểm vào mạng trong hệ điều hành trước.

Phương thức xử lý khác nhau tùy theo nền tảng:

Sau khi được thiết lập, dữ liệu vốn được ứng dụng gửi trực tiếp ra mạng sẽ đi vào ứng dụng khách SingLinkVPN trước.

Ví dụ:

ChatGPT App
    ↓
Ngăn xếp mạng của hệ điều hành
    ↓
Giao diện SingLink TUN
    ↓
Ứng dụng khách SingLinkVPN

Ở giai đoạn này, ứng dụng khách cần:

• Thiết lập IP ảo;

• Cấu hình bảng định tuyến;

• Cấu hình DNS;

• Loại trừ mạng LAN cục bộ;

• Ngăn kết nối proxy bị đưa trở lại TUN.

Điểm cuối cùng rất quan trọng.

Nếu không có “loại trừ định tuyến”, lưu lượng SingLinkVPN dùng để kết nối đến nút cũng có thể đi vào VPN lần nữa, tạo thành vòng lặp:

Lưu lượng VPN
↓
Đi vào VPN lần nữa
↓
Được đóng gói lần nữa
↓
Vòng lặp vô hạn

Vì vậy, ứng dụng khách phải loại trừ rõ ràng:

• IP của chính nút;

• Giao diện điều khiển cần thiết;

• Cổng mạng cục bộ;

• Các dịch vụ mà hệ thống cần truy cập trực tiếp.

Giai đoạn ba: Phân giải DNS và xác định tên miền

Khi người dùng mở chatgpt.com, thiết bị thường cần phân giải tên miền thành địa chỉ IP trước.

Nếu DNS được xử lý không đúng, có thể xảy ra:

• Yêu cầu DNS đi thẳng qua mạng cục bộ;

• DNS cục bộ trả về địa chỉ sai;

• Quy tắc không thể xác định tên miền;

• IPv6 bỏ qua VPN;

• Đã kết nối VPN nhưng DNS vẫn bị rò rỉ.

Ứng dụng khách SingLink có thể xử lý theo quy trình sau:

Ứng dụng gửi yêu cầu DNS
        ↓
Ứng dụng khách chặn DNS
        ↓
Đánh giá quy tắc tên miền
        ↓
Chọn DNS cục bộ hoặc DNS bảo mật từ xa
        ↓
Nhận kết quả IPv4／IPv6
        ↓
Liên kết tên miền với IP
        ↓
Quyết định kết nối trực tiếp, dùng proxy hoặc chặn

Tên miền cục bộ

Ví dụ, ngân hàng địa phương, thiết bị trong mạng LAN hoặc dịch vụ ở khu vực cụ thể có thể sử dụng DNS cục bộ và kết nối trực tiếp.

Tên miền dùng proxy

Tên miền cần truy cập qua VPN có thể được phân giải thông qua nút proxy hoặc DNS được bảo vệ.

Cách hiểu đơn giản

DNS giống như tra cứu sổ địa chỉ.

Nếu quá trình tra cứu sổ địa chỉ vẫn đi qua đường cục bộ, thì ngay cả khi dữ liệu sau đó đi qua VPN, thông tin về “trang web đang được tra cứu” vẫn có thể bị lộ.

Vì vậy, hệ thống giao thức SingLink cần xác định rõ:

• DNS có được ứng dụng khách chặn hay không;

• Những yêu cầu DNS nào kết nối trực tiếp;

• Những yêu cầu DNS nào đi qua VPN;

• Xử lý IPv4 và IPv6 như thế nào;

• DNS được lưu vào bộ nhớ đệm trong bao lâu;

• Có xóa kết quả DNS cũ sau khi chuyển đổi mạng hay không.

Giai đoạn bốn: Phân luồng thông minh và xác định định tuyến

Sau khi DNS và lưu lượng ứng dụng đi vào ứng dụng khách, hệ thống cần quyết định cách xử lý lưu lượng.

Thông thường có ba kết quả:

Kết nối trực tiếp
Proxy
Chặn

Kết nối trực tiếp

Lưu lượng sử dụng trực tiếp mạng cục bộ, không đi vào kênh SingLink.

Áp dụng cho:

• Thiết bị trong mạng LAN;

• Trang web cục bộ;

• Ứng dụng không cần proxy;

• Danh sách cho phép do người dùng tùy chỉnh.

Proxy

Lưu lượng đi vào giao thức SingLink và được nút chuyển tiếp.

Áp dụng cho:

• Trang web nước ngoài;

• Công cụ AI;

• Nền tảng mạng xã hội quốc tế;

• App do người dùng chỉ định.

Chặn

Từ chối kết nối.

Áp dụng cho:

• Tên miền quảng cáo;

• Tên miền theo dõi;

• Địa chỉ độc hại;

• Danh sách chặn do người dùng thiết lập.

Căn cứ đánh giá có thể bao gồm:

• Tên miền;

• Địa chỉ IP;

• Cổng;

• Ứng dụng;

• Vị trí địa lý;

• Loại giao thức;

• Quy tắc người dùng;

• Chế độ toàn cục hoặc chế độ quy tắc.

Cách hiểu đơn giản

Bước này tương đương với phân luồng giao thông:

• Xe địa phương đi đường thông thường;

• Xe đi nước ngoài vào đường cao tốc được mã hóa;

• Phương tiện nguy hiểm bị cấm lưu thông trực tiếp.

Giai đoạn năm: Lựa chọn nút và lựa chọn giao thức

Sau khi xác định lưu lượng cần đi qua proxy, client cần chọn node.

Khi chọn node, không thể chỉ nhìn vào tên quốc gia mà còn cần cân nhắc:

• Gói dịch vụ của người dùng;

• Node là 2.0 hay Beta;

• Node có đang online hay không;

• Độ trễ;

• Mất gói;

• Tải;

• Khoảng cách đến node;

• Nhà mạng địa phương;

• Vị trí của website đích;

• Node có hỗ trợ UDP hay không;

• Client có tương thích hay không.

Lựa chọn thủ công

Người dùng tự chọn các node tại Nhật Bản, Hoa Kỳ, Singapore, v.v.

Lựa chọn thông minh

Client chọn node phù hợp dựa trên kết quả kiểm tra.

Tính năng lựa chọn thông minh không nên chỉ chọn node có độ trễ thấp nhất.

Ví dụ:

Mặc dù A có độ trễ thấp hơn, nhưng mức mất gói và tải lại rất cao; trong quá trình sử dụng thực tế, B có thể ổn định hơn.

Vì vậy, tính năng lựa chọn thông minh nên cân nhắc tổng hợp:

Độ trễ＋mất gói＋tỷ lệ kết nối thành công＋tải＋hiệu suất trong quá khứ

Giai đoạn 6: Thương lượng năng lực giao thức

Sau khi client kết nối với node, không nên lập tức giả định rằng hai bên hỗ trợ các tính năng hoàn toàn giống nhau.

Trước tiên cần tiến hành thương lượng năng lực.

Nội dung thương lượng có thể bao gồm:

• Phiên bản SingLink;

• Beta hoặc 2.0;

• Hỗ trợ TCP;

• Hỗ trợ UDP;

• IPv4／IPv6;

• Có hỗ trợ khôi phục phiên hay không;

• Có hỗ trợ ghép kênh hay không;

• Data frame tối đa;

• Chiến lược Padding;

• Khoảng thời gian heartbeat;

• Có bật nén hay không;

• Kích thước MTU;

• Khả năng thương lượng lại.

Ví dụ:

Client:
Tôi hỗ trợ SingLink 2.0
Hỗ trợ TCP, UDP, IPv6
Hỗ trợ Session Resume
Frame tối đa 64KB

Server:
Xác nhận sử dụng SingLink 2.0
TCP, UDP khả dụng
Session Resume khả dụng
Frame tối đa thực tế 32KB

Cuối cùng, hai bên sử dụng các năng lực được cả hai cùng hỗ trợ.

Tại sao cần thương lượng?

Vì client và node có thể không được cập nhật trong cùng một ngày.

Nếu client mới trực tiếp gửi một định dạng mà node cũ không nhận diện được, kết nối sẽ thất bại.

Phiên bản 2.0 chính thức nên chú trọng hơn Beta vào:

• Khả năng tương thích ngược;

• Hạ phiên bản;

• Hạ cấp an toàn khi một tính năng không được hỗ trợ;

• Từ chối rõ ràng các phiên bản không tương thích.

Giai đoạn 7: Xác thực danh tính

Sau khi hoàn tất kết nối cơ bản, node cần xác nhận người dùng có quyền sử dụng hay không.

Dữ liệu xác thực được khuyến nghị bao gồm:

• Token ngắn hạn;

• Tài khoản hoặc ID ủy quyền;

• Số ngẫu nhiên của client;

• Phiên bản giao thức;

• ID node;

• Năng lực được yêu cầu;

• Dữ liệu kiểm tra tính toàn vẹn.

Có thể hiểu một gói xác thực theo cách đơn giản như sau:

Tôi là ai
Tôi muốn sử dụng node nào
Tôi muốn sử dụng giao thức nào
Mã số ngẫu nhiên của kết nối lần này
Khi nào quyền sử dụng của tôi hết hạn
Dữ liệu có bị sửa đổi hay không

Server cần kiểm tra:

1. Token có do nhà cung cấp chính thức phát hành hay không;

2. Token có hết hạn hay không;

3. Token có bị thu hồi hay không;

4. Người dùng có quyền truy cập node hay không;

5. Số ngẫu nhiên đã từng được sử dụng hay chưa;

6. Yêu cầu có bị phát lại hay không;

7. Phiên bản client có được phép kết nối hay không.

Chống phát lại

Kẻ tấn công có thể ghi lại một bộ dữ liệu xác thực hợp lệ rồi gửi lại nguyên trạng.

Vì vậy, dữ liệu xác thực cần bao gồm:

• Nonce dùng một lần;

• Challenge từ server;

• Thời hạn hiệu lực ngắn;

• Bản ghi thông tin xác thực đã sử dụng;

• Liên kết phiên.

Nói một cách đơn giản:

Một tấm vé đã được kiểm tra không thể bị sao chép rồi sử dụng vô hạn.

Giai đoạn 8: Trao đổi khóa và phiên mã hóa

Sau khi xác thực danh tính thành công, client và node cần thiết lập khóa phiên dành riêng cho kết nối lần này.

Logic được khuyến nghị là:

Client tạo khóa tạm thời
        ↓
Server tạo khóa tạm thời
        ↓
Hai bên trao đổi dữ liệu công khai
        ↓
Mỗi bên tự tính toán cùng một khóa dùng chung trên thiết bị cục bộ
        ↓
Dẫn xuất nhiều bộ khóa phiên từ khóa dùng chung

Cần dẫn xuất riêng:

• Khóa mã hóa từ client đến server;

• Khóa mã hóa từ server đến client;

• Khóa đảm bảo tính toàn vẹn dữ liệu;

• Khóa khôi phục phiên;

• Khóa bảo vệ Header.

Không nên dùng chung một khóa cho mọi hướng và mọi mục đích.

Tính bí mật chuyển tiếp

Phương án hợp lý hơn là sử dụng khóa tạm thời cho mỗi phiên.

Nhờ đó, ngay cả khi một khóa server dài hạn nào đó bị rò rỉ về sau, toàn bộ lưu lượng đã được ghi lại trước đây cũng không thể bị giải mã trực tiếp.

Luân chuyển khóa

Kết nối kéo dài không nên sử dụng vĩnh viễn cùng một bộ khóa phiên.

Có thể dẫn xuất lại khóa dựa trên:

• Lượng dữ liệu truyền tải;

• Thời gian kết nối;

• Số lượng frame;

• Yêu cầu của server;

Khi đạt một trong các điều kiện này, kết nối sẽ chuyển sang dùng khóa mới được dẫn xuất.

Ví dụ:

Sau mỗi một số GB dữ liệu được truyền
hoặc
Sau mỗi khoảng thời gian nhất định
Tạo lại khóa theo từng hướng

Ngưỡng cụ thể được xác định thông qua kiểm thử hiệu năng và bảo mật.

Giai đoạn 9: Thiết lập Session

Sau khi hoàn tất danh tính và khóa, hai bên thiết lập SingLink Session.

Session có thể bao gồm:

• Session ID;

• Phiên bản giao thức;

• Tham số mã hóa;

• Kích thước frame tối đa;

• Khoảng thời gian heartbeat;

• Chế độ UDP;

• Giới hạn Stream;

• Thời gian chờ khi không hoạt động;

• Khả năng khôi phục phiên;

• Chiến lược Beta hoặc 2.0.

Server trả về xác nhận:

Xác thực danh tính thành công
Thiết lập phiên thành công
Sử dụng SingLink 2.0
TCP khả dụng
UDP khả dụng
Ghép kênh khả dụng
Heartbeat đã được bật

Chỉ sau khi nhận được xác nhận từ server, client mới nên chính thức gửi dữ liệu ứng dụng.

Giai đoạn 10: Thiết lập Stream hoặc kết nối proxy độc lập

Ở giai đoạn này có hai kiến trúc phổ biến:

Phương án 1: Một Session truyền tải nhiều Stream

Tương tự cách tiếp cận của AnyTLS:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Trình duyệt

Mỗi Stream cần có:

• Stream ID;

• Địa chỉ đích;

• Cổng đích;

• TCP hoặc UDP;

• Trạng thái hiện tại;

• Cửa sổ gửi;

• Cửa sổ nhận.

Ưu điểm:

• Giảm các lần handshake lặp lại;

• Giảm độ trễ kết nối;

• Giảm số lượng kết nối tầng dưới;

• Phù hợp với số lượng lớn kết nối ngắn.

Rủi ro:

• Một Session gặp sự cố có thể ảnh hưởng đến nhiều Stream;

• Một tầng TCP duy nhất có thể xảy ra head-of-line blocking;

• Cần có cơ chế kiểm soát lưu lượng hoàn chỉnh.

Phương án 2: Thiết lập kết nối độc lập cho từng yêu cầu ứng dụng

ChatGPT → Kết nối độc lập
YouTube → Kết nối độc lập
Telegram → Kết nối độc lập

Ưu điểm:

• Các loại lưu lượng khác nhau được cách ly với nhau;

• Một kết nối thất bại không ảnh hưởng đến các kết nối khác;

• Logic đơn giản hơn.

Nhược điểm:

• Nhiều lần bắt tay hơn;

• Chi phí kết nối lớn hơn;

• Hiệu suất thấp hơn khi có nhiều kết nối ngắn.

Khuyến nghị

SingLink có thể áp dụng chế độ kết hợp:

• Các kết nối ngắn và trang web thông thường sử dụng ghép kênh Session;

• Các lượt tải xuống có lưu lượng lớn và video thiết lập kênh độc lập;

• UDP có độ trễ thấp được xử lý độc lập;

• Tránh để một lượt tải xuống tốc độ cao chiếm toàn bộ Stream.

Giai đoạn 11: Đóng gói khung dữ liệu

Dữ liệu ứng dụng không thể được đưa nguyên trạng trực tiếp vào kênh truyền tải mà cần được đóng gói thành các khung giao thức.

Về mặt khái niệm, khung SingLink có thể bao gồm:

Phiên bản
Loại khung
Session ID
Stream ID
Số thứ tự
Flags
Độ dài dữ liệu
Dữ liệu mã hóa
Dấu kiểm tra tính toàn vẹn

Các loại khung khác nhau có thể bao gồm:

Đây chỉ là khuyến nghị ở cấp độ thiết kế giao thức, không có nghĩa là SingLink hiện đang sử dụng các tên gọi hoặc định dạng bit này.

Giai đoạn 12: Xử lý lưu lượng TCP

Đối với kết nối TCP, chẳng hạn như trang web, API và tải xuống tệp, SingLink cần duy trì:

• Thứ tự dữ liệu;

• Truyền hai chiều;

• Trạng thái đóng;

• Kiểm soát lưu lượng;

• Trạng thái lỗi.

Quy trình hoàn chỉnh có thể là:

Ứng dụng thiết lập kết nối TCP
        ↓
Client thiết lập SingLink Stream
        ↓
Gửi tên miền và cổng đích
        ↓
Node kết nối đến trang web đích
        ↓
Node báo thành công hoặc thất bại
        ↓
Bắt đầu chuyển tiếp hai chiều

Đóng bình thường

Khi ứng dụng kết thúc kết nối:

1. Client gửi FIN;

2. Node ngừng nhận dữ liệu theo hướng đó;

3. Chờ hướng còn lại hoàn tất;

4. Đóng hoàn toàn Stream;

5. Giải phóng bộ nhớ và trạng thái kết nối.

Đóng bất thường

Nếu trang web đích từ chối kết nối:

1. Node trả về lỗi;

2. Client báo kết nối thất bại cho ứng dụng;

3. Stream được dọn dẹp ngay lập tức;

4. Không ảnh hưởng đến các Stream khác.

Giai đoạn 13: Xử lý lưu lượng UDP

UDP không có khái niệm kết nối TCP truyền thống, mỗi gói dữ liệu đều cần giữ lại:

• Quan hệ nguồn;

• Địa chỉ đích;

• Cổng đích;

• Độ dài dữ liệu;

• Ranh giới gói dữ liệu;

• Thời gian chờ của phiên.

Ví dụ:

UDP Association ID
Địa chỉ đích
Cổng đích
Độ dài dữ liệu
UDP Payload

SingLink cần lựa chọn rõ ràng:

UDP-over-TCP

Đưa các gói dữ liệu UDP vào TCP hoặc Session đáng tin cậy để truyền tải.

Ưu điểm:

• Dễ đi qua các mạng chỉ cho phép TCP;

• Dữ liệu ít bị thất lạc;

• Triển khai đơn giản.

Nhược điểm:

• Khi TCP mất gói, các dữ liệu UDP tiếp theo sẽ bị chặn;

• Không phù hợp với một số trò chơi, thoại và tình huống thời gian thực.

UDP nguyên bản

Truyền trực tiếp qua UDP.

Ưu điểm:

• Độ trễ thấp;

• Phù hợp với trò chơi, thoại và QUIC;

• Không bị ảnh hưởng bởi hiện tượng head-of-line blocking của TCP.

Nhược điểm:

• Một số mạng hạn chế UDP;

• Việc xử lý NAT và tường lửa phức tạp hơn.

Truyền tải kiểu QUIC

Dựa trên UDP, nhưng cung cấp ở tầng giao thức:

• Mã hóa;

• Truyền lại;

• Nhiều Stream;

• Kiểm soát tắc nghẽn;

• Chuyển đổi mạng.

Năng lực kỹ thuật hoàn chỉnh hơn, nhưng độ phức tạp triển khai cũng cao hơn.

Định hướng hợp lý hơn cho SingLink là:

Tự động quyết định UDP sử dụng truyền tải nguyên bản, đóng gói đáng tin cậy hoặc chế độ tương thích khác dựa trên loại mạng và lưu lượng.

Giai đoạn 14: Kiểm soát lưu lượng và backpressure

Giả sử YouTube tải xuống rất nhanh, trong khi ChatGPT chỉ truyền một lượng nhỏ văn bản.

Nếu không có kiểm soát lưu lượng, Stream video có thể chiếm toàn bộ kênh, dẫn đến:

• Phản hồi của ChatGPT chậm hơn;

• DNS bị trễ;

• Các ứng dụng khác bị treo;

• Mức sử dụng bộ nhớ liên tục tăng.

Vì vậy, cần kiểm soát lưu lượng ở hai cấp:

Cấp Session

Giới hạn lượng dữ liệu chưa được xác nhận mà toàn bộ Session có thể truyền đồng thời.

Cấp Stream

Giới hạn dung lượng cửa sổ truyền tải mà mỗi Stream có thể chiếm dụng.

Nói một cách dễ hiểu:

Không thể để một chiếc xe tải lớn chiếm hết mọi làn đường trên đường cao tốc; mỗi Stream đều cần được phân bổ tài nguyên đường truyền hợp lý.

Giao thức chính thức 2.0 có thể áp dụng cơ chế điều phối lưu lượng thận trọng hơn Beta để tránh ảnh hưởng đến các kết nối khác khi theo đuổi tốc độ cực đại.

Giai đoạn 15: Phân mảnh, Padding và hình thái lưu lượng

Sau khi dữ liệu được mã hóa, từ bên ngoài vẫn có thể quan sát được:

• Độ dài gói dữ liệu;

• Khoảng thời gian gửi;

• Thời lượng kết nối;

• Tỷ lệ tải lên và tải xuống;

• Hành vi kết nối lại.

Vì vậy, giao thức có thể xử lý hình thái lưu lượng, chẳng hạn như:

• Chia dữ liệu lớn thành nhiều khung;

• Gộp dữ liệu nhỏ;

• Thêm Padding có độ dài thay đổi;

• Điều chỉnh lô gửi;

• Tránh để tất cả lần bắt tay có độ dài cố định;

• Cập nhật định kỳ chiến lược Padding.

Nhưng cần làm rõ:

Padding không thể thay thế mã hóa và cũng không thể đảm bảo lưu lượng sẽ vĩnh viễn không thể bị nhận diện.

Padding quá mức còn dẫn đến:

• Nhiều lưu lượng hơn;

• Độ trễ cao hơn;

• Tiêu tốn nhiều CPU hơn;

• Lãng phí hạn mức miễn phí.

Vì vậy, 2.0 có thể sử dụng chiến lược thích ứng:

• Khi mạng bình thường, sử dụng cơ chế có chi phí thấp;

• Tăng cường xử lý hình thái trong môi trường mạng đặc biệt;

• Giảm Padding không cần thiết khi tải xuống tốc độ cao;

• Bổ sung lượng đệm thích hợp cho dữ liệu điều khiển nhỏ.

Trong khi đó, Beta có thể thiên về giảm chi phí bổ sung để nâng cao tốc độ cực đại.

Giai đoạn 16: Xử lý MTU và kích thước gói

Sau khi lưu lượng TUN được bổ sung header giao thức và dữ liệu mã hóa, gói sẽ trở nên lớn hơn.

Nếu vượt quá MTU của mạng, có thể xảy ra:

• Phân mảnh IP;

• Gói bị loại bỏ;

• Một số trang web không thể mở;

• Tốc độ lúc nhanh lúc chậm;

• VPN đã kết nối nhưng không thể truyền dữ liệu.

SingLink cần:

1. Xác định TUN MTU;

2. Trừ phần header giao thức;

3. Trừ chi phí mã hóa;

4. Điều chỉnh theo IPv4, IPv6;

5. Chia nhỏ dữ liệu khi cần;

6. Tránh phân mảnh IP không cần thiết.

Đây cũng là lý do một kích thước gói cố định duy nhất không nhất thiết phù hợp với mọi mạng.

Phiên bản chính thức 2.0 cần có cơ chế xử lý tương thích MTU đa nền tảng hoàn chỉnh hơn; nếu Beta sử dụng chiến lược khung lớn tích cực hơn, nó có thể đạt tốc độ cao trên một số mạng, nhưng độ ổn định sẽ thấp hơn trong các mạng đặc biệt.

Giai đoạn 17: Xử lý độ trễ, mất gói và tắc nghẽn

Client cần liên tục theo dõi:

• Độ trễ RTT;

• Dao động độ trễ;

• Mất gói;

• Tốc độ gửi;

• Tốc độ nhận;

• Dữ liệu chưa được xác nhận;

• Phản hồi của node.

Không thể chỉ dựa vào một lần Ping.

Ví dụ:

Bình thường: 60ms
Tăng tạm thời: 120ms
Tăng kéo dài: 500ms
Hoàn toàn không phản hồi: hết thời gian chờ

Các tình huống khác nhau cần cách xử lý khác nhau:

Nếu cứ gặp một lần mất gói là kết nối lại ngay, giao thức sẽ càng trở nên kém ổn định.

Giai đoạn 18: Heartbeat và kiểm tra tình trạng hoạt động

Khi không có dữ liệu ứng dụng trong thời gian dài, hệ thống vẫn cần biết kênh truyền có còn hoạt động hay không.

Có thể sử dụng:

PING
↓
PONG

Tuy nhiên, heartbeat không được gửi quá thường xuyên.

Nếu quá thường xuyên sẽ:

• Lãng phí pin;

• Tiêu tốn lưu lượng;

• Tăng tải cho máy chủ;

• Tạo ra đặc trưng thời gian cố định.

Nếu quá thưa sẽ:

• Mất nhiều thời gian mới phát hiện node ngừng hoạt động;

• Thời gian chờ của ứng dụng quá dài;

• Khôi phục chậm khi chuyển đổi mạng.

Vì vậy, heartbeat có thể được điều chỉnh theo trạng thái:

• Khi có lưu lượng bình thường, không gửi thêm heartbeat;

• Sau một khoảng thời gian không hoạt động, bắt đầu gửi heartbeat với tần suất thấp;

• Tạm thời tăng tần suất kiểm tra ngay sau khi chuyển đổi mạng;

• Xác định kết nối đã bị gián đoạn sau nhiều lần thất bại.

Giai đoạn 19: Chuyển đổi mạng và khôi phục phiên

Khi điện thoại chuyển từ Wi-Fi sang 5G, kết nối hiện tại thường sẽ mất hiệu lực.

Quy trình xử lý đầy đủ nên là:

Phát hiện mạng thay đổi
        ↓
Tạm dừng gửi dữ liệu mới qua kênh đã mất hiệu lực
        ↓
Lấy IP cục bộ và định tuyến mới
        ↓
Kết nối lại với node ban đầu
        ↓
Gửi thông tin xác thực khôi phục phiên
        ↓
Phía máy chủ xác minh Session cũ
        ↓
Khôi phục các luồng logic có thể khôi phục
        ↓
Thông báo cho ứng dụng thiết lập lại các kết nối TCP không thể khôi phục

Cần lưu ý:

Không phải mọi kết nối TCP của ứng dụng đều có thể được khôi phục liền mạch.

Giao thức có thể khôi phục:

• Phiên;

• Quyền truy cập node;

• Tham số giao thức;

• Một số Stream vẫn còn trạng thái.

Tuy nhiên, nếu kết nối TCP của chính trang web đích đã bị ngắt, ứng dụng vẫn có thể phải kết nối lại.

Vì vậy, chúng tôi không khẳng định rằng:

Khi chuyển đổi mạng, mọi ứng dụng sẽ luôn hoàn toàn không bị ảnh hưởng.

Cách diễn đạt chính xác hơn là:

SingLink 2.0 sẽ rút ngắn thời gian kết nối lại, khôi phục trạng thái giao thức và định tuyến, đồng thời giảm thiểu ảnh hưởng đến ứng dụng.

Giai đoạn 20: Node ngừng hoạt động và tự động chuyển đổi

Sự cố node có thể được chia thành:

Lỗi nhẹ

• Độ trễ tăng;

• Thỉnh thoảng mất gói;

• Tạm thời không phản hồi;

• Một số đích không khả dụng.

Phương thức xử lý:

• Tạm thời chờ;

• Giảm áp lực truyền tải;

• Đo lại;

• Thử kết nối lại với cùng node.

Lỗi nghiêm trọng

• Hoàn toàn không thể kết nối với node;

• Giao diện xác thực không khả dụng;

• Liên tục hết thời gian chờ;

• Node bị ngừng cung cấp.

Phương thức xử lý:

1. Ngừng sử dụng node ban đầu;

2. Chọn node thay thế từ danh sách khả dụng;

3. Thiết lập phiên bảo mật mới;

4. Khôi phục DNS và định tuyến;

5. Thông báo cho ứng dụng thiết lập lại các kết nối cần thiết.

Phiên bản 2.0 chính thức có thể áp dụng chiến lược chuyển đổi thận trọng hơn để tránh chuyển node liên tục do dao động tạm thời.

Trong khi đó, Beta có thể sử dụng chiến lược kết nối lại hoặc lựa chọn node tốc độ cao tích cực hơn, nhưng cũng có thể vì thế mà gây ra biến động lớn hơn.

Giai đoạn 21: Dữ liệu trả về và tháo đóng gói

Quy trình dữ liệu trả về từ trang web đích là:

Trang web đích trả dữ liệu
        ↓
Node SingLink tiếp nhận
        ↓
Tìm Session và Stream tương ứng
        ↓
Đóng gói thành frame dữ liệu SingLink
        ↓
Mã hóa và gửi cho client
        ↓
Client xác minh tính toàn vẹn
        ↓
Giải mã
        ↓
Phân luồng theo Stream ID
        ↓
Ghi vào TUN hoặc proxy hệ thống
        ↓
Trả lại cho ứng dụng ban đầu

Client cần kiểm tra:

• Dữ liệu có bị sửa đổi hay không;

• Số thứ tự có chính xác hay không;

• Có phải là frame trùng lặp hay không;

• Stream có còn tồn tại hay không;

• Độ dài có đáp ứng giới hạn hay không;

• Có vượt quá cửa sổ nhận hay không.

Dữ liệu lỗi không được chuyển thẳng cho ứng dụng.

Giai đoạn 22: Ngắt kết nối bình thường và dọn dẹp an toàn

Sau khi người dùng nhấp ngắt kết nối, client phải:

1. Ngừng tiếp nhận lưu lượng proxy mới;

2. Đóng các Stream đang hoạt động theo đúng quy trình;

3. Gửi yêu cầu kết thúc phiên đến node;

4. Xóa khóa phiên;

5. Thu hồi hoặc loại bỏ Token ngắn hạn;

6. Đóng TUN;

7. Khôi phục định tuyến hệ thống;

8. Khôi phục DNS;

9. Xóa cấu hình tạm thời không cần thiết.

Nếu client bị crash trực tiếp, hệ điều hành hoặc lần khởi động tiếp theo cũng cần tiến hành khắc phục để tránh để lại:

• Proxy hệ thống không hợp lệ;

• DNS sai;

• Định tuyến còn sót lại;

• Không thể truy cập Internet.

Khác biệt về chiến lược chi tiết giữa SingLink Beta và 2.0

Bảng dưới đây tóm tắt định vị kỹ thuật của SingLink Beta và SingLink 2.0.

Tóm tắt toàn bộ nguyên lý xử lý trong một câu

Trước tiên, SingLink để client tiếp quản lưu lượng của thiết bị, hoàn tất DNS, phân luồng thông minh và lựa chọn node; sau đó xác minh tài khoản và quyền truy cập node, thương lượng khả năng giao thức với node và thiết lập khóa mã hóa tạm thời. Sau khi kết nối được thiết lập, lưu lượng TCP và UDP của các ứng dụng khác nhau sẽ được đóng gói thành kết nối proxy độc lập hoặc Stream logic, truyền đến node qua kênh được bảo vệ, rồi node sẽ truy cập trang web đích. Trong quá trình truyền, hệ thống liên tục quản lý cửa sổ lưu lượng, tính toàn vẹn dữ liệu, độ trễ, tình trạng mất gói, heartbeat và trạng thái node; khi chuyển đổi mạng hoặc node ngừng hoạt động, hệ thống sẽ thiết lập lại phiên, khôi phục định tuyến hoặc chuyển sang node khả dụng.

Điểm khác biệt cốt lõi giữa Beta và 2.0 là:

SingLink Beta theo đuổi tốc độ tối đa một cách tích cực hơn; ngoài truyền tải tốc độ cao, SingLink 2.0 còn bổ sung khả năng tương thích, kiểm tra tình trạng hoạt động, xác định bất thường, khôi phục phiên và xử lý đa nền tảng toàn diện hơn, nhờ đó có tỷ lệ ổn định cao hơn.

Câu hỏi thường gặp

SingLink 2.0 là gì?

SingLink 2.0 là giao thức truyền tải mạng chính thức do SingLinkVPN tự nghiên cứu và phát triển, chịu trách nhiệm xác thực danh tính, mã hóa phiên, đóng gói lưu lượng, truyền TCP và UDP, kiểm tra tình trạng hoạt động và khôi phục sau sự cố.

SingLink 2.0 có phải là phiên bản phần mềm không?

Không. SingLink 2.0 là tên chính thức của giao thức, thuộc một hệ thống phiên bản khác với các phiên bản client Windows, macOS, Android và iOS.

SingLink Beta và 2.0 khác nhau như thế nào?

Beta là giao thức thử nghiệm ưu tiên tốc độ, có thể đạt tốc độ tối đa trên 1 Gbps trong điều kiện phù hợp; còn 2.0 là giao thức chính thức, chú trọng tốc độ, tính ổn định, khả năng tương thích đa nền tảng và khôi phục sau khi ngắt kết nối.

Tỷ lệ ổn định của SingLink 2.0 là bao nhiêu?

Trong thử nghiệm A/B nội bộ ở môi trường kiểm thử do SingLinkVPN chỉ định, SingLink 2.0 đạt tỷ lệ ổn định 99.5%, còn Beta đạt tối đa khoảng 97%.

SingLink xử lý lưu lượng mạng như thế nào?

Trước tiên, client tiếp quản lưu lượng hệ thống, hoàn tất DNS và phân luồng thông minh, sau đó xác minh tài khoản và quyền truy cập node, thiết lập phiên mã hóa, đóng gói dữ liệu TCP hoặc UDP rồi truyền đến node.

SingLink xử lý tình trạng ngắt kết nối như thế nào?

Hệ thống liên tục kiểm tra độ trễ, tình trạng mất gói, heartbeat và trạng thái node; khi xuất hiện bất thường, hệ thống có thể thiết lập lại phiên, khôi phục định tuyến hoặc chuyển sang node khả dụng.

SingLink khác VLESS như thế nào?

Cốt lõi của VLESS chủ yếu là danh tính, lệnh và chuyển tiếp đến đích; còn SingLink tích hợp danh tính, định tuyến, quyền truy cập node, chiến lược truyền tải, kiểm tra tình trạng hoạt động và khôi phục sau sự cố thành một hệ thống giao thức.

SingLink khác AnyTLS như thế nào?

AnyTLS chủ yếu sử dụng kết nối TLS để chuyên chở Session và nhiều Stream; còn SingLink có định vị rộng hơn, bao gồm cả định tuyến thông minh, quyền thành viên, điều phối node và khôi phục kết nối. Cách triển khai Session và Stream cụ thể vẫn phải căn cứ vào tài liệu kỹ thuật chính thức.

Những người dùng nào có thể sử dụng SingLink 2.0?

Các node dùng giao thức SingLink 2.0 chính thức được mở cho thành viên Pro, Max và Rich; giao thức Beta có trên mọi gói, kể cả Gói miễn phí. Quyền truy cập thực tế căn cứ vào thông tin hiển thị trên client mới nhất.

SingLink 2.0 đã hoàn toàn mã nguồn mở chưa?

Hiện tại, mã nguồn giao thức cốt lõi vẫn chưa được công khai đầy đủ, nhưng tài liệu kỹ thuật, phương pháp kiểm thử, định dạng dữ liệu, công cụ xác minh và cơ chế công bố lỗ hổng đã được đưa vào kế hoạch mã nguồn mở liên tục.

Tài liệu liên quan và nội dung đọc thêm

Định vị sản phẩm và phạm vi công khai trong bài viết này đồng thời tham khảo Trung tâm kỹ thuật chính thức của SingLinkVPN, kho nghiên cứu công khai của SingLinkLabs và phương pháp kiểm thử hiệu năng của dự án.

Các nội dung liên quan khác gồm hướng dẫn đầy đủ về gói miễn phí của SingLinkVPN, kế hoạch mã nguồn mở của SingLinkVPN và báo cáo kiểm toán bảo mật SingLinkVPN năm 2026.

Lưu ý kỹ thuật: Các số liệu 99.5%, 97% và trên 1 Gbps trong bài viết này lần lượt là kết quả thử nghiệm A/B nội bộ và thử nghiệm tốc độ tối đa trong môi trường được chỉ định, không có nghĩa là mọi khu vực, thiết bị, nhà mạng và thời điểm đều có thể đạt kết quả tương tự. Nội dung liên quan đến thuật toán mã hóa, định dạng gói tin, cơ chế Session và Stream cụ thể phải căn cứ vào tài liệu kỹ thuật chính thức và mã nguồn công khai sau này của SingLink.