Protokol SingLink 2.0

SingLink 2.0 ialah protokol pengangkutan rangkaian rasmi yang dibangunkan sendiri oleh SingLinkVPN. “2.0” merujuk kepada nama dan generasi protokol; ia bukan versi perisian klien SingLinkVPN.

Protokol SingLink bukan sekadar membawa trafik ke nod VPN. Ia juga merangkumi kebenaran akaun dan nod, pengendalian DNS, penghalaan pintar, sesi tersulit, pengkapsulan TCP dan UDP, semakan kesihatan sambungan, perubahan rangkaian dan pemulihan pengecualian.

SingLink kini mempunyai protokol pengeluaran SingLink 2.0 dan protokol pratonton SingLink Beta yang mengutamakan kelajuan. Dalam ujian A/B dalaman, SingLink 2.0 mencapai kestabilan 99.5% dan Beta mencapai sehingga kira-kira 97%; dalam keadaan rangkaian dan peranti yang sesuai, kelajuan puncak Beta melebihi 1 Gbps.

Perbandingan data teras: SingLink 2.0 pengeluaran mencatat kestabilan 99.5% dalam persekitaran ujian yang ditetapkan. Beta mencapai sehingga kira-kira 97%, tetapi melebihi kelajuan puncak 1 Gbps dalam keadaan rangkaian dan peranti yang sesuai. Keputusan ini mewakili keutamaan kestabilan dan kelajuan yang berbeza dan bukan jaminan untuk setiap peranti atau rangkaian.

Bukti dan sempadan teknikal: Kedudukan produk yang telah disahkan, definisi ujian dalaman dan fungsi awam boleh dipetik secara langsung. Butiran algoritma penyulitan, format paket, rundingan keupayaan, Session, Stream, pemultipleksan dan pemulihan sesi di bawah ialah model pemprosesan rujukan, bukan kenyataan tentang spesifikasi yang sedang digunakan. Dokumen teknikal rasmi SingLink dan kod sumber yang diterbitkan pada masa hadapan akan diutamakan.

Prinsip Pemprosesan Lengkap Protokol SingLink

Sistem lengkap boleh dibahagikan kepada dua laluan:

Satah kawalan

Bertanggungjawab untuk:

• log masuk ke akaun;
• mengesahkan keahlian;
• mendapatkan nod;
• menentukan hak akses nod;
• menghantar konfigurasi protokol;
• mengemas kini peraturan;
• memilih Beta atau 2.0.

Satah data

Bertanggungjawab untuk:

• menerima trafik aplikasi;
• menyelesaikan DNS;
• mewujudkan sambungan selamat;
• mengkapsulkan dan membawa TCP serta UDP;
• mengekalkan sambungan;
• mengendalikan pemutusan sambungan;
• mengembalikan data kepada aplikasi.

Aliran ringkasnya ialah:

Pengguna log masuk ke SingLinkVPN
        ↓
Dapatkan nod yang dibenarkan dan konfigurasi protokol
        ↓
Klien mencipta TUN / proksi sistem
        ↓
Terima trafik aplikasi
        ↓
Nilai peraturan DNS dan penghalaan
        ↓
Pilih nod SingLink 2.0 atau Beta
        ↓
Rundingkan keupayaan protokol
        ↓
Sahkan hak akaun dan peranti
        ↓
Cipta sesi tersulit dan kunci sesi
        ↓
Cipta strim logik tersendiri untuk setiap sambungan aplikasi
        ↓
Kapsulkan data TCP / UDP
        ↓
Hantar data ke nod SingLink
        ↓
Nod menyahkapsul dan mengakses laman web destinasi
        ↓
Kembalikan data dan serahkan kepada aplikasi asal
        ↓
Ukur kependaman, kehilangan paket dan keadaan sambungan secara berterusan
        ↓
Sambung semula, pulihkan atau tukar nod selepas pengecualian

---

Peringkat 1: Log Masuk, Pengambilan Nod dan Konfigurasi Protokol

Selepas pengguna membuka SingLinkVPN dan log masuk, klien tidak sepatutnya serta-merta menyimpan setiap alamat nod pengeluaran, bukti kelayakan dan parameter protokol secara kekal pada peranti.

Aliran yang lebih sesuai ialah:

1. Klien menghantar bukti kelayakan akaun.
2. Sistem akaun mengesahkan pengguna.
3. Sistem mengesahkan pelan dan hak akses nod.
4. Ia mengembalikan nod yang tersedia untuk pengguna tersebut.
5. Ia mengembalikan bukti kelayakan sambungan jangka pendek.
6. Ia mengembalikan versi protokol semasa dan konfigurasi yang diperlukan.
7. Klien mengesahkan integriti konfigurasi.
8. Konfigurasi sensitif disimpan dalam storan sistem yang dilindungi.

Lapisan ini terutamanya menentukan:

• sama ada pengguna mempunyai keahlian yang sah;
• sama ada Beta atau 2.0 tersedia;
• sama ada akaun mempunyai hak Pro, Max atau Rich;
• negara dan nod yang tersedia;
• sama ada konfigurasi telah tamat tempoh;
• sama ada klien perlu dikemas kini.

Penjelasan mudah

Ia seperti pemeriksaan sebelum menaiki kereta api laju:

• siapa anda;
• kelas tiket yang anda beli;
• perkhidmatan yang boleh anda naiki;
• sama ada tiket masih sah.

Peraturan keselamatan yang disyorkan

SingLink tidak sepatutnya bergantung selama-lamanya pada satu kata laluan statik yang kekal.

Reka bentuk yang lebih sesuai menggunakan:

• token sambungan jangka pendek;
• cabaran sekali guna;
• nonce peranti;
• had tempoh tamat;
• konfigurasi nod yang ditandatangani pelayan;
• mekanisme pembatalan.

Dengan itu, memperoleh satu konfigurasi sambungan tidak akan memberikan akses kekal.

---

Peringkat 2: Mewujudkan Titik Masuk Rangkaian Sistem

Apabila pengguna memilih Sambung, SingLinkVPN terlebih dahulu perlu mencipta titik masuk rangkaian dalam sistem pengendalian.

Kaedahnya berbeza mengikut platform:

Platform	Titik masuk rangkaian yang lazim
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension atau TUN
Windows	Penyesuai maya TUN dan penghalaan sistem
Linux	TUN, jadual penghalaan dan pengurusan DNS

Selepas ia dicipta, data yang biasanya dihantar terus oleh aplikasi ke rangkaian akan terlebih dahulu memasuki klien SingLinkVPN.

Contohnya:

Aplikasi ChatGPT
    ↓
Timbunan rangkaian sistem pengendalian
    ↓
Antara muka TUN SingLink
    ↓
Klien SingLinkVPN

Pada peringkat ini, klien perlu:

• mencipta IP maya;
• mengkonfigurasi jadual penghalaan;
• mengkonfigurasi DNS;
• mengecualikan rangkaian kawasan setempat (LAN);
• menghalang sambungan proksi daripada dihalakan semula ke dalam TUN;
• mencipta peraturan Kill Switch.

Perkara terakhir ini penting.

Tanpa pengecualian laluan, trafik yang digunakan oleh SingLinkVPN untuk mencapai nodnya sendiri boleh memasuki semula VPN dan mewujudkan gelung:

Trafik VPN
↓
Memasuki semula VPN
↓
Dikapsulkan sekali lagi
↓
Gelung tanpa henti

Oleh itu, klien mesti secara jelas mengecualikan:

• IP nod itu sendiri;
• antara muka kawalan yang diperlukan;
• get laluan setempat;
• perkhidmatan yang mesti dicapai terus oleh sistem.

---

Peringkat 3: Resolusi DNS dan Penilaian Domain

Apabila pengguna membuka chatgpt.com, peranti biasanya perlu terlebih dahulu menyelesaikan domain tersebut kepada alamat IP.

Pengendalian DNS yang salah boleh menyebabkan:

• permintaan DNS bergerak terus melalui rangkaian setempat;
• penyelesai DNS setempat mengembalikan alamat yang salah;
• peraturan kehilangan konteks domain asal;
• trafik IPv6 memintas VPN;
• kebocoran DNS walaupun VPN kelihatan bersambung.

Klien SingLink boleh menggunakan aliran ini:

Aplikasi menghantar permintaan DNS
        ↓
Klien memintas DNS
        ↓
Nilai peraturan domain
        ↓
Pilih DNS setempat atau DNS jauh yang dilindungi
        ↓
Dapatkan keputusan IPv4 / IPv6
        ↓
Kaitkan domain dengan IP
        ↓
Pilih terus, proksi atau sekat

Domain setempat

Bank tempatan, peranti LAN atau perkhidmatan khusus wilayah boleh menggunakan DNS setempat dan bersambung secara terus.

Domain yang diproksi

Domain yang mesti diakses melalui VPN boleh diselesaikan melalui nod proksi atau penyelesai DNS yang dilindungi.

Penjelasan mudah

DNS seumpama mencari alamat.

Jika carian itu masih menggunakan jalan tempatan, ia mungkin mendedahkan laman web yang diminta walaupun data seterusnya menggunakan VPN.

Oleh itu, sistem protokol SingLink patut mentakrifkan:

• sama ada klien memintas DNS;
• permintaan DNS mana yang pergi secara terus;
• permintaan DNS mana yang menggunakan VPN;
• cara IPv4 dan IPv6 dikendalikan;
• berapa lama keputusan DNS dicache;
• sama ada keputusan DNS yang lapuk dikosongkan selepas perubahan rangkaian.

---

Peringkat 4: Penghalaan Pintar dan Keputusan Laluan

Selepas DNS dan trafik aplikasi memasuki klien, sistem mesti memutuskan cara mengendalikannya.

Biasanya terdapat tiga hasil:

Terus
Proksi
Sekat

Terus

Trafik menggunakan rangkaian setempat dan tidak memasuki terowong SingLink.

Sesuai untuk:

• peranti LAN;
• laman web tempatan;
• aplikasi yang tidak memerlukan proksi;
• senarai benar yang ditetapkan pengguna.

Proksi

Trafik memasuki protokol SingLink dan dimajukan oleh nod.

Sesuai untuk:

• laman web luar negara;
• alat AI;
• platform sosial antarabangsa;
• aplikasi yang dipilih pengguna.

Sekat

Sambungan ditolak.

Sesuai untuk:

• domain pengiklanan;
• domain penjejakan;
• alamat berniat jahat;
• senarai sekat yang ditetapkan pengguna.

Keputusan boleh mengambil kira:

• domain;
• alamat IP;
• port;
• aplikasi;
• lokasi geografi;
• jenis protokol;
• peraturan pengguna;
• mod global atau mod peraturan.

Penjelasan mudah

Peringkat ini menyerupai pengaturan lalu lintas:

• kenderaan tempatan menggunakan jalan biasa;
• kenderaan ke luar negara memasuki lebuh raya tersulit;
• kenderaan berbahaya tidak dibenarkan masuk.

---

Peringkat 5: Pemilihan Nod dan Protokol

Sebaik sahaja trafik dikenal pasti untuk diproksi, klien mesti memilih nod.

Pemilihan tidak boleh bergantung pada nama negara sahaja. Ia juga mesti mengambil kira:

• pelan pengguna;
• sama ada nod menggunakan 2.0 atau Beta;
• sama ada nod berada dalam talian;
• kependaman;
• kehilangan paket;
• beban;
• jarak nod;
• pembawa rangkaian setempat;
• lokasi destinasi;
• sokongan UDP;
• keserasian klien.

Pemilihan manual

Pengguna memilih nod di Jepun, Amerika Syarikat, Singapura atau lokasi lain.

Pemilihan pintar

Klien memilih nod yang sesuai berdasarkan keputusan ujian.

Pemilihan pintar tidak sepatutnya hanya memilih nod dengan kependaman paling rendah.

Contohnya:

Nod	Kependaman	Kehilangan paket	Beban
A	50 ms	8%	90%
B	70 ms	0%	30%

Walaupun kependaman A lebih rendah, kehilangan paket dan bebannya tinggi; B mungkin lebih stabil dalam penggunaan sebenar.

Oleh itu, pemilihan pintar patut menggabungkan:

Kependaman + kehilangan paket + kadar kejayaan sambungan + beban + prestasi sejarah

---

Peringkat 6: Rundingan Keupayaan Protokol

Selepas klien mencapai nod, ia tidak sepatutnya serta-merta menganggap kedua-dua pihak menyokong fungsi yang sama.

Keupayaan perlu dirundingkan terlebih dahulu.

Perkara yang dirundingkan mungkin termasuk:

• versi SingLink;
• Beta atau 2.0;
• sokongan TCP;
• sokongan UDP;
• IPv4 / IPv6;
• sokongan penyambungan semula sesi;
• sokongan pemultipleksan;
• saiz maksimum bingkai data;
• strategi Padding;
• selang denyutan (heartbeat);
• sama ada pemampatan diaktifkan;
• saiz MTU;
• sokongan rundingan semula.

Contohnya:

Klien:
Saya menyokong SingLink 2.0
Saya menyokong TCP, UDP dan IPv6
Saya menyokong Session Resume
Bingkai maksimum: 64 KB

Pelayan:
Penggunaan SingLink 2.0 disahkan
TCP dan UDP tersedia
Session Resume tersedia
Bingkai maksimum berkesan: 32 KB

Kedua-dua pihak akhirnya hanya menggunakan keupayaan yang disokong bersama.

Mengapakah rundingan diperlukan?

Klien dan nod mungkin tidak dikemas kini pada hari yang sama.

Jika klien baharu menghantar format yang tidak dapat dikenali oleh nod lama, sambungan akan gagal.

Versi pengeluaran 2.0 patut memberi lebih penekanan berbanding Beta pada:

• keserasian ke belakang;
• pengunduran versi;
• penurunan fungsi secara selamat apabila sesuatu ciri tidak tersedia;
• penolakan jelas terhadap versi yang tidak serasi.

---

Peringkat 7: Pengesahan Identiti

Selepas sambungan asas diwujudkan, nod perlu mengesahkan bahawa pengguna dibenarkan.

Data pengesahan yang disyorkan termasuk:

• token jangka pendek;
• ID akaun atau kebenaran;
• nonce klien;
• versi protokol;
• ID nod;
• keupayaan yang diminta;
• data pengesahan integriti.

Paket pengesahan yang dipermudahkan menyatakan:

Siapa saya
Nod mana yang saya mahu
Protokol mana yang saya mahu
Pengecam rawak untuk sambungan ini
Bila kebenaran saya tamat
Sama ada data telah diubah suai

Pelayan perlu menyemak:

1. sama ada token dikeluarkan secara rasmi;
2. sama ada token telah tamat tempoh;
3. sama ada token telah dibatalkan;
4. sama ada pengguna mempunyai akses ke nod;
5. sama ada nonce pernah digunakan sebelum ini;
6. sama ada permintaan itu ialah main semula (replay);
7. sama ada versi klien ini dibenarkan bersambung.

Perlindungan main semula

Penyerang boleh merakam data pengesahan yang sah dan menghantarnya semula tanpa sebarang perubahan.

Oleh itu, data pengesahan memerlukan:

• nonce sekali guna;
• cabaran pelayan;
• tempoh sah yang singkat;
• rekod bukti kelayakan yang telah digunakan;
• pengikatan sesi.

Dalam bahasa mudah:

Tiket yang telah disahkan tidak boleh disalin dan digunakan semula tanpa had.

---

Peringkat 8: Pertukaran Kunci dan Sesi Tersulit

Selepas pengesahan identiti berjaya, klien dan nod memerlukan kunci sesi yang dikhaskan untuk sambungan ini.

Logik yang disyorkan ialah:

Klien mencipta kunci sementara
        ↓
Pelayan mencipta kunci sementara
        ↓
Kedua-duanya bertukar data awam
        ↓
Masing-masing mengira rahsia kongsi yang sama secara bebas
        ↓
Beberapa kunci sesi diterbitkan daripada rahsia kongsi tersebut

Kunci berasingan patut diterbitkan untuk:

• penyulitan dari klien ke pelayan;
• penyulitan dari pelayan ke klien;
• integriti data;
• pemulihan sesi;
• perlindungan pengepala.

Semua arah dan tujuan tidak sepatutnya berkongsi satu kunci.

Kerahsiaan ke hadapan (forward secrecy)

Reka bentuk yang lebih sesuai menggunakan kunci sementara untuk setiap sesi.

Jika kunci jangka panjang pelayan bocor kemudian, ia tidak sepatutnya dapat menyahsulit secara langsung setiap sambungan yang pernah dirakam sebelum ini.

Putaran kunci

Sambungan yang berjalan lama tidak sepatutnya menggunakan satu set kunci sesi selama-lamanya.

Kunci boleh diterbitkan semula berdasarkan:

• jumlah data yang dipindahkan;
• tempoh sambungan;
• bilangan bingkai;
• arahan pelayan.

untuk menerbitkan semula kunci.

Contohnya:

Selepas sejumlah GB yang ditetapkan
atau
selepas tempoh yang ditetapkan
terbitkan kunci arah yang baharu

Nilai tepat patut ditentukan melalui ujian prestasi dan keselamatan kejuruteraan, bukan direka-reka dalam artikel promosi.

---

Peringkat 9: Mencipta Sesi

Selepas identiti dan kunci diwujudkan, kedua-dua pihak mencipta SingLink Session.

Session mungkin mengandungi:

• Session ID;
• versi protokol;
• parameter penyulitan;
• saiz bingkai maksimum;
• selang denyutan;
• mod UDP;
• had Stream;
• tamat masa melahu;
• keupayaan pemulihan sesi;
• dasar Beta atau 2.0.

Pelayan mengembalikan pengesahan:

Identiti disahkan
Session diwujudkan
Menggunakan SingLink 2.0
TCP tersedia
UDP tersedia
Pemultipleksan tersedia
Denyutan diaktifkan

Klien patut menghantar data aplikasi hanya selepas menerima pengesahan pelayan.

---

Peringkat 10: Mencipta Stream atau Sambungan Proksi Tersendiri

Pengesahan kejuruteraan diperlukan untuk menentukan seni bina yang sebenarnya digunakan oleh SingLink.

Pilihan 1: Satu Session membawa berbilang Stream

Ini menyerupai pendekatan AnyTLS:

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

Setiap Stream memerlukan:

• Stream ID;
• alamat destinasi;
• port destinasi;
• TCP atau UDP;
• keadaan semasa;
• tetingkap hantar;
• tetingkap terima.

Kebaikan:

• kurang jabat tangan berulang;
• kependaman sambungan lebih rendah;
• kurang sambungan asas;
• pengendalian cekap bagi banyak sambungan pendek.

Risiko:

• kegagalan satu Session boleh menjejaskan berbilang Stream;
• satu sambungan TCP asas boleh menyebabkan sekatan kepala barisan;
• kawalan aliran yang lengkap diperlukan.

Pilihan 2: Setiap permintaan aplikasi mencipta sambungan tersendiri

ChatGPT → sambungan tersendiri
YouTube → sambungan tersendiri
Telegram → sambungan tersendiri

Kebaikan:

• trafik yang berbeza diasingkan;
• kegagalan satu sambungan tidak menjejaskan yang lain;
• logik yang lebih ringkas.

Keburukan:

• lebih banyak jabat tangan;
• overhed sambungan yang lebih besar;
• kecekapan lebih rendah untuk banyak sambungan pendek.

Cadangan

SingLink boleh menggunakan mod hibrid:

• multipleks sambungan pendek dan trafik web biasa melalui satu Session;
• cipta saluran tersendiri untuk muat turun besar dan video;
• kendalikan UDP kependaman rendah secara berasingan;
• halang satu muat turun berkelajuan tinggi daripada menggunakan semua Stream.

---

Peringkat 11: Pengkapsulan Bingkai Data

Data aplikasi tidak boleh dimasukkan begitu sahaja ke dalam saluran pengangkutan. Ia perlu dikapsulkan sebagai bingkai protokol.

Bingkai SingLink secara konsep mungkin mengandungi:

Versi
Jenis bingkai
Session ID
Stream ID
Nombor jujukan
Bendera
Panjang data
Data tersulit
Tag integriti

Jenis bingkai yang mungkin termasuk:

Jenis bingkai	Tujuan
OPEN	Mencipta Stream baharu
DATA	Membawa data
ACK	Mengesahkan keadaan
FIN	Menutup secara normal
RESET	Menamatkan secara tidak normal
PING	Semakan kesihatan
PONG	Respons semakan kesihatan
UDP	Membawa datagram UDP
SETTINGS	Mengemas kini parameter sesi
KEY_UPDATE	Memutar kunci sesi
RESUME	Memulihkan sesi

Ini ialah cadangan reka bentuk protokol. Ia tidak menyatakan bahawa SingLink kini menggunakan nama atau format bit ini.

---

Peringkat 12: Pemprosesan Trafik TCP

Bagi sambungan TCP seperti laman web, API dan muat turun fail, SingLink perlu mengekalkan:

• susunan data;
• pemindahan dua hala;
• keadaan penutupan;
• kawalan aliran;
• keadaan ralat.

Aliran lengkap boleh jadi seperti berikut:

Aplikasi mencipta sambungan TCP
        ↓
Klien mencipta SingLink Stream
        ↓
Hantar domain dan port destinasi
        ↓
Nod bersambung ke laman web destinasi
        ↓
Nod melaporkan kejayaan atau kegagalan
        ↓
Mulakan pemajuan dua hala

Penutupan normal

Apabila aplikasi menamatkan sambungan:

1. Klien menghantar FIN.
2. Nod berhenti menerima data dari arah tersebut.
3. Ia menunggu arah yang satu lagi selesai.
4. Stream ditutup sepenuhnya.
5. Memori dan keadaan sambungan dilepaskan.

Penutupan tidak normal

Jika destinasi menolak sambungan:

1. Nod mengembalikan ralat.
2. Klien melaporkan kegagalan sambungan kepada aplikasi.
3. Stream dibersihkan serta-merta.
4. Stream lain tidak terjejas.

---

Peringkat 13: Pemprosesan Trafik UDP

UDP tidak mempunyai sambungan TCP konvensional. Setiap datagram perlu mengekalkan:

• perkaitan sumber;
• alamat destinasi;
• port destinasi;
• panjang data;
• sempadan datagram;
• tamat masa perkaitan.

Contohnya:

UDP Association ID
Alamat destinasi
Port destinasi
Panjang data
UDP Payload

SingLink perlu memilih secara jelas antara pendekatan berikut:

UDP melalui TCP

Datagram UDP dibawa di dalam TCP atau Session yang boleh dipercayai.

Kebaikan:

• lebih mudah melalui rangkaian yang hanya membenarkan TCP;
• kurang kemungkinan kehilangan data;
• penggunaan yang lebih ringkas.

Keburukan:

• kehilangan paket TCP menyekat data UDP seterusnya;
• tidak sesuai untuk sesetengah permainan, suara dan kegunaan masa nyata.

UDP asli

UDP membawa data secara terus.

Kebaikan:

• kependaman rendah;
• sesuai untuk permainan, suara dan QUIC;
• tidak terjejas oleh sekatan kepala barisan TCP.

Keburukan:

• sesetengah rangkaian menyekat UDP;
• pengendalian NAT dan tembok api lebih rumit.

Pengangkutan gaya QUIC

Ia berasaskan UDP tetapi menyediakan di lapisan protokol:

• penyulitan;
• penghantaran semula;
• berbilang Stream;
• kawalan kesesakan;
• migrasi rangkaian.

Ia menawarkan keupayaan teknikal yang lebih lengkap tetapi lebih sukar dilaksanakan.

Hala tuju yang munasabah untuk SingLink ialah:

Memilih secara automatik UDP asli, pengkapsulan yang boleh dipercayai atau mod serasi lain mengikut rangkaian dan jenis trafik.

Sama ada ini telah dilaksanakan perlu disahkan.

---

Peringkat 14: Kawalan Aliran dan Tekanan Balik

Andaikan YouTube sedang memuat turun dengan pantas manakala ChatGPT hanya memindahkan sedikit teks.

Tanpa kawalan aliran, Stream video boleh memenuhi saluran dan menyebabkan:

• respons ChatGPT menjadi lebih perlahan;
• kelewatan DNS;
• aplikasi tergendala;
• penggunaan memori yang terus meningkat.

Oleh itu, dua tahap kawalan aliran diperlukan:

Tahap Session

Mengehadkan jumlah data yang belum diakui yang boleh dibawa oleh keseluruhan Session.

Tahap Stream

Mengehadkan bahagian tetingkap pengangkutan yang boleh digunakan oleh setiap Stream.

Dalam bahasa mudah:

Satu lori besar tidak boleh menggunakan semua lorong lebuh raya. Setiap Stream memerlukan peruntukan sumber pengangkutan yang adil.

Protokol pengeluaran 2.0 boleh menggunakan penjadualan yang lebih konservatif berbanding Beta supaya usaha mengejar kelajuan puncak tidak mengganggu sambungan lain.

---

Peringkat 15: Segmentasi, Padding dan Rupa Trafik

Selepas data disulitkan, pemerhati mungkin masih dapat melihat:

• panjang paket;
• selang penghantaran;
• tempoh sambungan;
• nisbah muat naik/muat turun;
• tingkah laku penyambungan semula.

Oleh itu, protokol boleh mengubah rupa trafik, contohnya dengan:

• memecahkan data besar kepada beberapa bingkai;
• menggabungkan data kecil;
• menambah Padding berubah-ubah;
• melaraskan kelompok penghantaran;
• mengelakkan satu panjang jabat tangan yang tetap;
• mengemas kini strategi Padding secara berkala.

Namun perlu jelas bahawa:

Padding tidak boleh menggantikan penyulitan dan tidak dapat menjamin trafik sentiasa tidak dapat dikenal pasti.

Padding yang berlebihan juga menyebabkan:

• lebih banyak trafik;
• kependaman lebih tinggi;
• penggunaan CPU lebih tinggi;
• pembaziran kuota Pelan Percuma.

Oleh itu, profil 2.0 boleh menyesuaikan diri:

• menggunakan overhed rendah pada rangkaian biasa;
• meningkatkan pemprosesan rupa trafik dalam persekitaran rangkaian khas;
• mengurangkan Padding yang tidak perlu semasa muat turun berkelajuan tinggi;
• menggunakan padding yang sesuai pada data kawalan yang kecil.

Beta pula mungkin mengurangkan overhed tambahan untuk meningkatkan kelajuan puncak.

---

Peringkat 16: Pengendalian MTU dan Saiz Paket

Menambah pengepala protokol dan data tersulit pada trafik TUN akan meningkatkan saiz paket.

Melebihi MTU rangkaian boleh menyebabkan:

• fragmentasi IP;
• paket tercicir;
• laman web gagal dibuka;
• kelajuan tidak stabil;
• VPN bersambung tetapi tidak membawa sebarang data.

SingLink perlu:

1. menentukan MTU TUN;
2. menolak pengepala protokol;
3. menolak overhed penyulitan;
4. melaraskan untuk IPv4 dan IPv6;
5. memecahkan data apabila perlu;
6. mengelakkan fragmentasi IP yang tidak perlu.

Inilah sebabnya satu saiz paket tetap tidak sesuai untuk setiap rangkaian.

Versi pengeluaran 2.0 patut mempunyai keserasian MTU merentas platform yang lebih lengkap. Jika Beta menggunakan bingkai besar yang lebih agresif, ia mungkin lebih pantas pada sesetengah rangkaian tetapi kurang stabil pada rangkaian yang luar biasa.

---

Peringkat 17: Pengendalian Kependaman, Kehilangan Paket dan Kesesakan

Klien perlu memerhati secara berterusan:

• kependaman RTT;
• ketaran (jitter);
• kehilangan paket;
• kelajuan penghantaran;
• kelajuan penerimaan;
• data yang belum diakui;
• respons nod.

Ia tidak boleh bergantung pada satu Ping sahaja.

Contohnya:

Normal: 60 ms
Peningkatan sementara: 120 ms
Peningkatan berterusan: 500 ms
Tiada respons: tamat masa

Situasi berbeza memerlukan pengendalian yang berbeza:

Situasi	Pengendalian
Kependaman sementara	Terus menunggu; jangan sambung semula dengan serta-merta
Kehilangan paket kecil	Laraskan tetingkap atau rentak penghantaran
Kependaman tinggi berterusan	Kurangkan keserentakan atau pertimbangkan nod lain
Tiada data tetapi denyutan berjaya	Kekalkan Session
Denyutan dan data kedua-duanya gagal	Anggap sambungan telah terputus
Kegagalan nod sepenuhnya	Sambung semula atau tukar nod

Menyambung semula selepas satu paket hilang akan menjadikan protokol kurang stabil.

---

Peringkat 18: Denyutan dan Semakan Kesihatan

Walaupun tiada data aplikasi untuk tempoh yang lama, sistem perlu tahu sama ada saluran masih hidup.

Ia boleh menggunakan:

PING
↓
PONG

Denyutan tidak boleh terlalu kerap.

Frekuensi yang berlebihan:

• membazirkan bateri;
• menggunakan data;
• meningkatkan beban pelayan;
• mewujudkan ciri pemasaan yang tetap.

Frekuensi yang tidak mencukupi:

• melambatkan pengesanan nod yang gagal;
• membuat aplikasi menunggu lebih lama;
• melambatkan pemulihan selepas perubahan rangkaian.

Oleh itu, frekuensi denyutan boleh menyesuaikan diri mengikut keadaan:

• apabila terdapat trafik biasa, jangan tambah denyutan;
• selepas tempoh melahu, mulakan denyutan berfrekuensi rendah;
• selepas perubahan rangkaian, tingkatkan semakan buat sementara;
• selepas kegagalan berulang, tandakan sambungan sebagai terputus.

---

Peringkat 19: Perubahan Rangkaian dan Pemulihan Sesi

Apabila telefon bertukar daripada Wi-Fi ke 5G, sambungan asal biasanya menjadi tidak sah.

Pengendalian yang lengkap sepatutnya:

Kesan perubahan rangkaian
        ↓
Berhenti menghantar data baharu melalui saluran yang gagal
        ↓
Dapatkan IP setempat dan laluan baharu
        ↓
Sambung semula ke nod asal
        ↓
Hantar bukti kelayakan pemulihan sesi
        ↓
Pelayan mengesahkan Session lama
        ↓
Pulihkan Stream logik yang boleh dipulihkan
        ↓
Maklumkan aplikasi untuk membina semula sambungan TCP yang tidak dapat dipulihkan

Satu batasan penting:

Bukan setiap sambungan TCP aplikasi boleh dipulihkan dengan lancar.

Protokol boleh memulihkan:

• keadaan Session;
• kebenaran nod;
• parameter protokol;
• sesetengah Stream yang keadaannya masih sah.

Tetapi jika sambungan TCP laman web destinasi itu sendiri telah tamat, aplikasi mungkin masih perlu menyambung semula.

Oleh itu, ia tidak patut dipromosikan sebagai:

Setiap aplikasi akan sentiasa melalui perubahan rangkaian tanpa sebarang gangguan.

Kenyataan yang lebih tepat ialah:

SingLink 2.0 memendekkan masa penyambungan semula, memulihkan keadaan protokol dan penghalaan, dan berusaha meminimumkan kesan kepada aplikasi.

---

Peringkat 20: Kegagalan Nod dan Penukaran Automatik

Pengecualian nod boleh dibahagikan kepada:

Kegagalan ringan

• kependaman meningkat;
• kehilangan paket sekali-sekala;
• tiada respons buat sementara;
• sesetengah destinasi tidak tersedia.

Pengendalian:

• tunggu sebentar;
• kurangkan tekanan pengangkutan;
• ukur semula;
• sambung semula ke nod yang sama.

Kegagalan keras

• nod tidak dapat dicapai;
• antara muka pengesahan tidak tersedia;
• tamat masa berterusan;
• nod ditarik balik daripada perkhidmatan.

Pengendalian:

1. Berhenti menggunakan nod asal.
2. Aktifkan Kill Switch.
3. Pilih alternatif daripada senarai yang tersedia.
4. Wujudkan Session selamat yang baharu.
5. Pulihkan DNS dan laluan.
6. Maklumkan aplikasi untuk membina semula sambungan yang perlu.

Versi pengeluaran 2.0 boleh bertukar nod secara lebih konservatif supaya ketaran singkat tidak menyebabkan lompatan nod yang berulang.

Beta boleh menyambung semula atau memilih nod berkelajuan tinggi dengan lebih agresif, tetapi ini mungkin menghasilkan variasi yang lebih besar.

---

Peringkat 21: Mengembalikan Data dan Penyahkapsulan

Respons laman web destinasi mengikut aliran ini:

Laman web destinasi mengembalikan data
        ↓
Nod SingLink menerimanya
        ↓
Cari Session dan Stream yang sepadan
        ↓
Kapsulkan sebagai bingkai data SingLink
        ↓
Sulitkan dan hantar ke klien
        ↓
Klien mengesahkan integriti
        ↓
Nyahsulit
        ↓
Nyahmultipleks mengikut Stream ID
        ↓
Tulis ke TUN atau proksi sistem
        ↓
Kembalikan kepada aplikasi asal

Klien perlu menyemak:

• sama ada data telah diubah suai;
• sama ada nombor jujukan betul;
• sama ada bingkai itu pendua;
• sama ada Stream masih wujud;
• sama ada panjang berada dalam had;
• sama ada tetingkap terima telah dilampaui.

Data yang tidak sah tidak boleh diserahkan terus kepada aplikasi.

---

Peringkat 22: Pemutusan Normal dan Pembersihan Selamat

Apabila pengguna memilih Putuskan Sambungan, klien patut:

1. berhenti menerima trafik proksi baharu;
2. menutup Stream aktif secara normal;
3. menghantar penamatan Session kepada nod;
4. memadam kunci sesi;
5. membatalkan atau membuang token jangka pendek;
6. menutup TUN;
7. memulihkan laluan sistem;
8. memulihkan DNS;
9. membuang peraturan Kill Switch;
10. membuang konfigurasi sementara yang tidak diperlukan.

Jika klien ranap, sistem pengendalian atau pelancaran seterusnya juga memerlukan laluan pembaikan untuk mengelak daripada meninggalkan:

• proksi sistem yang tidak sah;
• DNS yang salah;
• laluan yang tertinggal;
• tiada akses internet;
• Kill Switch yang terkunci secara kekal.

---

Perbezaan Strategi Terperinci antara SingLink Beta dan 2.0

Yang berikut menyatakan kedudukan teknikal produk; parameter tepat masih memerlukan pengesahan kejuruteraan.

Bidang pemprosesan	SingLink Beta	SingLink 2.0
Hala tuju utama	Kelajuan puncak	Kelajuan, kestabilan, keserasian
Parameter sambungan	Lebih agresif	Adaptif dan lebih konservatif
Keserentakan	Mungkin menggunakan keserentakan lebih tinggi	Menghalang satu aliran memenuhi saluran
Tetingkap pengangkutan	Cenderung kepada daya pemprosesan	Dilaraskan secara dinamik mengikut kependaman dan kehilangan paket
Penukaran nod	Mencuba nod berkelajuan tinggi lebih awal	Mengesahkan kegagalan sebelum bertukar
Pemultipleksan	Cenderung kepada kecekapan penggunaan semula	Mengimbangi penggunaan semula dan pengasingan kegagalan
Padding	Mengutamakan overhed lebih rendah	Menyesuaikan diri dengan persekitaran
Perubahan rangkaian	Pemulihan asas	Pemulihan dan keserasian yang lebih lengkap
Ujian regresi platform	Skop pratonton	Ujian pengeluaran penuh
Kestabilan dalaman	Kira-kira 97%	99.5%
Kelajuan	Melebihi 1 Gbps dalam keadaan yang sesuai	Kekal pantas tanpa hanya mengejar kelajuan puncak

---

Prinsip Pemprosesan Lengkap dalam Satu Perenggan

SingLink terlebih dahulu membiarkan klien mengambil alih trafik peranti dan melengkapkan pemprosesan DNS, penghalaan pintar dan pemilihan nod. Kemudian ia mengesahkan hak akaun dan nod, merundingkan keupayaan protokol dengan nod, dan mewujudkan kunci penyulitan sementara. Selepas sambungan dicipta, trafik TCP dan UDP setiap aplikasi dikapsulkan sebagai sambungan proksi tersendiri atau Stream logik dan dibawa melalui saluran yang dilindungi ke nod, yang kemudiannya mengakses laman web destinasi. Semasa pemindahan, sistem terus mengurus tetingkap aliran, integriti data, kependaman, kehilangan paket, denyutan dan keadaan nod. Apabila rangkaian berubah atau nod gagal, ia mewujudkan semula Session, memulihkan laluan atau bertukar ke nod yang tersedia.

Perbezaan asas antara Beta dan 2.0 ialah:

SingLink Beta mengejar kelajuan puncak dengan lebih agresif. SingLink 2.0 menambah keserasian, semakan kesihatan, klasifikasi pengecualian, pemulihan sesi dan pengendalian merentas platform yang lebih lengkap sambil mengekalkan pemindahan berkelajuan tinggi, dan oleh itu mencapai kestabilan yang lebih tinggi.

---

Soalan Lazim (FAQ)

Apakah SingLink 2.0?

SingLink 2.0 ialah protokol pengangkutan rangkaian rasmi yang dibangunkan oleh SingLinkVPN. Ia mengendalikan pengesahan identiti, sesi tersulit, pengkapsulan trafik, pengangkutan TCP dan UDP, semakan kesihatan dan pemulihan pengecualian.

Adakah SingLink 2.0 sebuah versi perisian?

Tidak. SingLink 2.0 ialah nama rasmi protokol tersebut. Versi klien Windows, macOS, Android dan iOS menggunakan sistem versi yang berasingan.

Apakah perbezaan antara SingLink Beta dan 2.0?

SingLink Beta ialah protokol pratonton yang mengutamakan kelajuan dengan kelajuan puncak yang boleh melebihi 1 Gbps dalam keadaan yang sesuai. 2.0 ialah protokol pengeluaran yang menekankan kelajuan, kestabilan, keserasian merentas platform dan pemulihan selepas sambungan terputus.

Berapakah kadar kestabilan SingLink 2.0?

Dalam ujian A/B dalaman SingLinkVPN di bawah keadaan yang ditetapkan, SingLink 2.0 mencapai kestabilan 99.5% dan Beta mencapai sehingga kira-kira 97%.

Bagaimanakah SingLink memproses trafik rangkaian?

Klien SingLink terlebih dahulu mengambil alih trafik sistem dan melaksanakan pengendalian DNS serta penghalaan pintar. Kemudian ia mengesahkan hak akaun dan nod, mewujudkan Session tersulit, mengkapsulkan data TCP atau UDP, dan menghantarnya ke nod.

Bagaimanakah SingLink mengendalikan sambungan yang terputus?

Sistem SingLink menyemak kependaman, kehilangan paket, denyutan dan keadaan nod secara berterusan. Selepas berlaku pengecualian, ia boleh mewujudkan semula Session, memulihkan laluan atau bertukar ke nod yang tersedia.

Apakah perbezaan SingLink dengan VLESS?

VLESS terutamanya mentakrifkan identiti, arahan dan pemajuan destinasi. SingLink pula menyepadukan identiti, penghalaan, hak akses nod, dasar pengangkutan, semakan kesihatan dan pemulihan pengecualian ke dalam sistem protokol yang lebih luas.

Apakah perbezaan SingLink dengan AnyTLS?

AnyTLS terutamanya membawa satu Session dan berbilang Stream melalui sambungan TLS. SingLink mempunyai peranan produk yang lebih luas yang turut merangkumi penghalaan pintar, hak keahlian, penjadualan nod dan pemulihan sambungan. Pelaksanaan sebenar Session dan Stream masih tertakluk kepada dokumentasi teknikal rasmi.

Siapakah yang boleh menggunakan SingLink 2.0?

Nod protokol pengeluaran SingLink 2.0 kini terutamanya tersedia untuk pengguna Pro, Max dan Rich. Protokol Beta dibuka kepada semua ahli. Paparan klien terkini adalah rujukan muktamad untuk akses sebenar.

Adakah SingLink 2.0 sumber terbuka sepenuhnya?

Kod sumber protokol teras SingLink belum dibuka sepenuhnya kepada umum, tetapi dokumen teknikal, kaedah ujian, format data, alat pengesahan dan mekanisme pendedahan kelemahan merupakan sebahagian daripada pelan sumber terbuka yang berterusan.

---

Sumber dan Bacaan Lanjut

Kedudukan produk dan kenyataan skop awam dalam artikel ini juga merujuk kepada pusat teknologi rasmi SingLinkVPN, repositori penyelidikan awam SingLinkLabs dan metodologi penanda aras prestasinya.

Bacaan berkaitan termasuk panduan lengkap Pelan Percuma SingLinkVPN, pelan sumber terbuka SingLinkVPN dan laporan audit keselamatan SingLinkVPN 2026.

Nota teknikal: Angka 99.5%, kira-kira 97% dan melebihi 1 Gbps masing-masing ialah keputusan kestabilan A/B dalaman dan keputusan daya pemprosesan puncak di bawah keadaan yang ditetapkan. Ia tidak bermaksud setiap wilayah, peranti, pembawa, rangkaian atau tempoh masa akan menghasilkan keputusan yang sama. Algoritma penyulitan, format paket, mekanik Session dan mekanik Stream yang khusus masih tertakluk kepada dokumen teknikal rasmi SingLink dan kod sumber yang diterbitkan pada masa hadapan.