SingLinkLabs · Protocol Paper 01
Whitepaper Teknis Protokol SingLink
Arsitektur SingLink 2.0, siklus hidup koneksi lengkap dan batasan protokol
SingLink 2.0 adalah protokol transmisi jaringan formal yang dikembangkan secara independen oleh SingLinkVPN, bukan versi perangkat lunak klien. Artikel ini mengambil bidang kendali, bidang data, dan siklus hidup koneksi lengkap sebagai jalur utama untuk menjelaskan kemampuan publik protokol, model implementasi referensi, batasan data pengujian, dan perbedaan protokol eksternal.
- Document
- SLP-WP-01
- Revision
- 1.0
- Published
- 2026-07-29
- Language
- Bahasa Indonesia
Pembuatan protokol dan versi klien dikelola secara independen. Ketersediaan node bergantung pada status real-time klien.
Berlangganan Umpan AtomScope and evidence
Ruang Lingkup, Kesimpulan dan Batasan Bukti
Ini bukan halaman pemasaran, tetapi deskripsi sistem mulai dari akuisisi konfigurasi hingga pembersihan koneksi. Setiap item membedakan antara kemampuan yang dikonfirmasi, deskripsi desain publik, dan model implementasi referensi.
SingLink 2.0 adalah generasi protokol transmisi jaringan resmi yang dikembangkan secara independen oleh SingLinkVPN. "2.0" mewakili nama protokol dan pembuatan protokol, bukan nomor versi perangkat lunak Windows, macOS, Android, iOS, atau klien lainnya.
Batasan produk protokol tidak hanya format byte dari klien ke server, tetapi juga melibatkan izin akun dan node, pemrosesan DNS, pembongkaran cerdas, pemilihan node, deteksi kesehatan sesi, peralihan jaringan, dan pemulihan kegagalan.
Dari halaman produk, kemampuan klien, dan kaliber publik resmi.
Jelaskan masalah yang perlu dipecahkan oleh protokol dan batasan sistem yang saat ini terbuka.
Digunakan untuk menjelaskan kemungkinan implementasi, tidak setara dengan spesifikasi biner yang dipublikasikan.
Versioning
Pembuatan protokol bukanlah versi perangkat lunak
Protocol
SingLink 2.0
Mewakili keseluruhan evolusi generasi protokol transport, negosiasi kemampuan, model sesi, dan kebijakan kompatibilitas.
Client software
Setiap platform memiliki nomornya sendiri
Klien Windows, macOS, Android, iOS, Linux, dan TV dikelola sesuai dengan ritme rilisnya masing-masing dan tidak akan dicampur dengan protokol 2.0.
System architecture
Pemisahan bidang kendali dan bidang data
Bidang kendali bertanggung jawab atas izin, konfigurasi, dan penjadwalan node; bidang data bertanggung jawab atas saluran yang benar-benar membawa lalu lintas pengguna. Memisahkan keduanya membantu membatasi cakupan data sensitif dan mengisolasi kegagalan.
Control plane
permukaan kontrol
- 01 Izin akun dan paket
- 02 Daftar kemampuan node dan protokol
- 03 Konfigurasi, strategi dan pencabutan jangka pendek
- 04 Informasi kesehatan dan penjadwalan node
Data plane
Pesawat data
- 01 Lalu lintas mengambil alih dan meneruskan
- 02 TCP, UDP dan pembawa aliran logis
- 03 Status sesi dan deteksi kesehatan
- 04 Mengembalikan dekapsulasi data
Connection lifecycle
22 tahap pemrosesan
Mulai dari izin akun, pintu masuk jaringan sistem hingga dekapsulasi data kembali dan pembersihan keamanan, proses berikut mempertahankan tautan teknis lengkap dan menandai status bukti untuk setiap langkah.
- 01
Login akun dan konfirmasi izin
Kemampuan yang dikonfirmasiKlien memperoleh paket, node, dan izin protokol yang tersedia dari akun saat ini. Kredensial autentikasi harus berumur pendek, dapat dibatalkan, dan dipisahkan dari status penerusan data berikutnya.
- 02
Pengiriman konfigurasi node dan protokol
Deskripsi desain publikBidang kontrol mengembalikan alamat node, port, protokol yang tersedia, dan kebijakan yang diperlukan, dan tidak boleh secara langsung mengirimkan kunci master jangka panjang atau bidang sensitif yang tidak perlu ke klien.
- 03
Menetapkan pintu masuk jaringan sistem
Kemampuan yang dikonfirmasiKlien menerima lalu lintas yang perlu diproses melalui mode TUN, proxy sistem, atau ekstensi jaringan platform. Pintu masuk spesifiknya bergantung pada kemampuan sistem operasi.
- 04
Resolusi DNS dan penentuan nama domain
Kemampuan yang dikonfirmasiKebijakan yang konsisten harus digunakan untuk permintaan DNS dan koneksi selanjutnya untuk menghindari nama domain melalui proxy saat DNS masih bocor dari jaringan lokal atau menyebabkan pengalihan yang salah.
- 05
Distribusi lalu lintas yang cerdas dan penilaian perutean
Kemampuan yang dikonfirmasiMenentukan koneksi sebagai koneksi langsung, proxy, atau diblokir berdasarkan aturan, aplikasi, nama domain target, IP, dan status jaringan.
- 06
Pemilihan simpul
Kemampuan yang dikonfirmasiMode manual menggunakan node yang ditentukan pengguna; mode cerdas dapat memilih kandidat node berdasarkan latensi, ketersediaan, beban, wilayah, dan izin paket.
- 07
Negosiasi kemampuan protokol
Deskripsi desain publikKlien dan server mengkonfirmasi generasi protokol dan kemampuan yang didukung oleh kedua belah pihak. Klien lama tidak boleh secara diam-diam mengaktifkan perilaku yang tidak kompatibel ketika tidak dapat mengenali kemampuan baru.
- 08
Otentikasi dan anti-pemutaran ulang
Model implementasi referensiNode memverifikasi bahwa akun atau sesi tersebut valid dan harus mencegah data autentikasi lama digunakan kembali melalui penuaan, pengacakan, atau mekanisme serupa.
- 09
Pertukaran kunci dan kunci sesi
Model implementasi referensiProtokol memerlukan penetapan konteks enkripsi terpisah untuk koneksi saat ini. Rangkaian sandi tertentu, bidang jabat tangan, dan periode rotasi harus tunduk pada spesifikasi publik di masa mendatang.
- 10
Buat Sesi
Model implementasi referensiSesi mewakili sesi transmisi antara klien dan node, yang dapat membawa status koneksi, informasi kemampuan, detak jantung, dan satu atau lebih aliran logis.
- 11
Buat koneksi Stream atau proxy independen
Model implementasi referensiSetiap permintaan aplikasi dapat dipetakan ke Aliran logis dalam Sesi, atau koneksi independen dapat dibuat; metode terakhir tergantung pada implementasi publik.
- 12
Enkapsulasi bingkai data
Model implementasi referensiInformasi tujuan, identifikasi aliran, panjang muatan, perintah kontrol, dan data diperlukan untuk membentuk kerangka parsable; halaman ini tidak menciptakan bidang biner yang tidak berdokumen.
- 13
Pemrosesan lalu lintas TCP
Deskripsi desain publikAliran byte TCP perlu menjaga ketertiban, menangani penutupan setengah dan penutupan abnormal, dan meneruskan tekanan balik sisi aplikasi ke sisi transportasi.
- 14
Pemrosesan lalu lintas UDP dan QUIC
Deskripsi desain publikDatagram UDP perlu mempertahankan batasan pesan dan mengatur batas waktu sesi; Layanan tipe UDP seperti QUIC juga perlu menghindari pemblokiran head-of-line yang tidak perlu.
- 15
Kontrol aliran dan tekanan balik
Model implementasi referensiKetika kecepatan konsumsi klien, node, atau layanan target melambat, pertumbuhan buffer harus dibatasi untuk mencegah satu Aliran menjatuhkan seluruh Sesi.
- 16
Subpackaging, Padding dan tampilan lalu lintas
Model implementasi referensiPaketisasi dan padding hanya dapat digunakan sebagai bagian dari strategi transmisi dan tidak dapat digambarkan sebagai stealth mutlak; kondisi pendukung dan overhead memerlukan pengujian dan verifikasi.
- 17
Penanganan MTU dan ukuran paket
Deskripsi desain publikTunnel overhead akan mengurangi MTU yang tersedia, dan kegagalan paket yang besar perlu dikurangi melalui penghindaran fragmentasi, penyesuaian MSS, atau mekanisme yang setara.
- 18
Penundaan, kehilangan paket dan penanganan kemacetan
Model implementasi referensiProtokol harus mengontrol ritme pengiriman dan transmisi ulang berdasarkan umpan balik jaringan, dan membedakan antara kehilangan paket nyata, penundaan antrian, dan jitter jaringan jangka pendek.
- 19
Deteksi detak jantung dan kesehatan
Kemampuan yang dikonfirmasiTerus pantau sesi dan status node agar tidak hanya mengandalkan waktu tunggu sistem operasi yang lama untuk mendeteksi koneksi mati.
- 20
Peralihan jaringan dan pemulihan sesi
Kemampuan yang dikonfirmasiSetelah beralih antara Wi-Fi dan jaringan seluler, klien mengonfirmasi ulang pintu masuk jaringan, DNS, perutean dan sesi transmisi, dan melanjutkan koneksi sesuai dengan kemampuannya.
- 21
Kegagalan node dan peralihan otomatis
Kemampuan yang dikonfirmasiJika terjadi kegagalan ringan, sesi dapat dibangun kembali terlebih dahulu, dan jika terjadi kegagalan keras, node yang tersedia dapat dialihkan. Selama proses peralihan, perutean sistem harus dipulihkan dan lalu lintas harus dihindari dari koneksi langsung yang tidak terduga.
- 22
Mengembalikan data, dekapsulasi, dan pembersihan keamanan
Deskripsi desain publikKlien memverifikasi dan mendekapsulasi data yang dikembalikan, dan menghapus status sesi sementara, kunci cache, perutean, dan perubahan DNS setelah koneksi selesai.
Traffic entry and routing
Pengambilalihan lalu lintas, DNS, dan pembongkaran cerdas
Entri jaringan sistem, resolusi nama domain, dan penilaian perutean harus berbagi konteks yang sama untuk menghindari kebocoran DNS, keluar dari kesalahan, dan koneksi langsung yang tidak terduga.
Sistem desktop dapat menggunakan mode TUN atau proxy sistem; platform seluler dan TV menggunakan kemampuan perluasan jaringannya masing-masing. Platform yang berbeda memiliki API yang berbeda, tetapi tujuan kebijakannya sama: lalu lintas yang memerlukan proxy memasuki terowongan, dan lalu lintas yang tidak memerlukan proxy terhubung langsung sesuai aturan.
Hanya memproksi lalu lintas aplikasi dan mengizinkan DNS untuk terus melewati jaringan lokal dapat mengekspos nama domain atau memperoleh hasil resolusi yang tidak sesuai untuk keluar saat ini. Oleh karena itu, pencocokan nama domain, kueri DNS, cache IP, dan pembuatan koneksi harus menggunakan konteks perutean yang sama.
koneksi langsung
Layanan atau target lokal yang secara eksplisit tidak memerlukan proxy menggunakan jaringan lokal.
agen
Setelah verifikasi izin, koneksi dibuat melalui node SingLink yang dipilih.
blok
Koneksi ditolak ketika aturan keamanan tercapai atau target tanpa izin tercapai.
Authentication
Sesi otentikasi dan terenkripsi
Jawaban konfirmasi izin "Dapatkah akun ini menggunakan node dan protokol ini"; Otentikasi transmisi menjawab "Apakah koneksi saat ini berasal dari klien yang valid". Keduanya harus menggunakan status sesi yang berumur pendek dan dapat dibatalkan serta mencegah informasi autentikasi lama diputar ulang.
Klien dan node juga perlu mengonfirmasi generasi protokol dan kemampuan yang didukung oleh kedua belah pihak. Pihak yang tidak mengenali kemampuan baru harus menurunkan versi atau menolak koneksi dengan aman dan tidak dapat mengaktifkan perilaku yang tidak kompatibel tanpa konfirmasi.
Disclosure boundary
Detail kriptografi yang tidak dipublikasikan
Informasi yang ada tidak cukup untuk mengidentifikasi bidang jabat tangan tertentu, rangkaian sandi, fungsi derivasi kunci, periode rotasi, dan format paket biner. Artikel ini hanya menjelaskan sasaran keamanan dan tidak menulis AES, versi TLS, kurva tertentu, atau panjang bidang tetap sebagai fait accompli.
Session model
Sesi, Aliran, dan Bingkai Data
Gunakan model sesi hierarki untuk menjelaskan hubungan antara koneksi aplikasi, aliran logis, dan konteks transportasi node sambil memperjelas batasan format yang dirahasiakan.
Session
Konteks transportasi antara klien dan node dapat membawa hasil otentikasi, kemampuan, detak jantung, dan kontrol aliran tingkat koneksi.
Stream
Koneksi Aplikasi Logika. Apakah beberapa Streaming berbagi Sesi bergantung pada implementasi publik akhir dan kebijakan platform.
Bingkai data perlu mengekspresikan setidaknya perintah kontrol, aliran logika, batas beban, dan status kesalahan; sebelum format resmi dipublikasikan, halaman ini tidak akan memberikan tabel bidang yang belum diverifikasi.
Transport
TCP, UDP dan QUIC
TCP
aliran byte yang dipesan
Pertahankan urutan byte, tangani kesalahan koneksi setengah tutup, penutupan tidak normal, tekanan balik, dan target, serta cegah koneksi lambat mengisi buffer Sesi.
UDP
batasan datagram
Pertahankan batasan datagram dan pertahankan status target dan batas waktu; jika UDP-over-TCP digunakan, pemblokiran head-of-line dan amplifikasi kehilangan paket perlu dievaluasi.
QUIC
Transportasi yang andal melalui UDP
Cobalah untuk mempertahankan keunggulan kemacetan dan transmisi ulang QUIC untuk menghindari pemulihan berulang yang disebabkan oleh lapisan keandalan tambahan.
Reliability
Kontrol aliran, MTU, detak jantung dan pemulihan
Koneksi yang stabil bukanlah tombol sambungkan kembali otomatis, tetapi mesin status yang terdiri dari buffering, pengemasan paket, deteksi kesehatan, pemulihan rute, dan peralihan node.
kontrol aliran
Sesuaikan jendela pengiriman sesuai dengan kecepatan konsumsi untuk menghindari pemblokiran seluruh sesi dengan satu aliran.
penanganan MTU
Pertimbangkan tambahan overhead terowongan untuk mengurangi risiko fragmentasi dan lubang hitam.
pemeriksaan kesehatan
Tentukan koneksi berdasarkan detak jantung, penundaan, kehilangan paket, dan status penerusan sebenarnya.
pemulihan jaringan
Setelah jaringan terputus, portal, DNS, perutean, dan sesi dibangun kembali untuk mencegah lalu lintas tersambung langsung secara tidak sengaja.
Product comparison
SingLink 2.0 dan Beta
| indikator | SingLink 2.0 | SingLink Beta |
|---|---|---|
| Penentuan posisi | kesepakatan formal antar generasi | Protokol pratinjau yang mengutamakan kecepatan |
| Tingkat stabilitas pengujian A/B internal | 99.5% | Hingga sekitar 97% |
| Fokus kecepatan | Keseimbangan kecepatan, stabilitas dan kompatibilitas | Nilai puncak melebihi 1Gbps dalam kondisi yang sesuai |
| Izin simpul protokol | Pro, Maks dan Kaya | Semua paket |
| mengubah strategi | Fokus pada kompatibilitas dan pemulihan jangka panjang | Digunakan untuk verifikasi kemampuan dan kinerja baru |
External protocols
Perbandingan batas dengan VLESS dan AnyTLS
Dasar perbandingannya adalah dokumen publik resmi dari masing-masing proyek. Di sini kami membandingkan posisi, batasan sistem, dan kemampuan pengungkapan, dan tidak mencampurkan angka pemasaran ke dalam kesimpulan protokol yang mendasarinya.
| Dimensi | Ruang Lingkup Buku Putih SingLink | Ruang lingkup publik VLESS | Ruang lingkup publik AnyTLS |
|---|---|---|---|
| posisi publik | Sistem keseluruhan bidang kendali produk dan bidang data transmisi | Protokol transport klien dan server yang ringan dan tanpa kewarganegaraan | Protokol proxy dan implementasi referensi berbasis TLS |
| Identitas dan Tujuan | Akun, izin node, kolaborasi sesi dan perutean | UUID, perintah, port dan alamat target | TLS pasca-otentikasi, lalu buat sesi |
| Session/Stream | Penjelasan model referensi, format persisnya belum diungkapkan | Dukungan Mux, detailnya ditentukan oleh implementasi dan konfigurasi | Ekspos bingkai sesi, Streaming multiplexing, dan perintah |
| penampilan lalu lintas | Strategi transmisi yang harus diverifikasi, tidak mengklaim tembus pandang secara mutlak | Dokumen resmi menjelaskan Aliran opsional dan mekanisme lainnya | Pengungkapan subkontrak, rencana padding dan mekanisme pembaruan |
| Ketahanan | Deteksi kesehatan, pemutusan jaringan, rekonstruksi sesi, dan peralihan node | Bertanggung jawab atas ekologi sinar X dan kombinasi transmisi spesifik | Protokol v2 memperlihatkan SYNACK, detak jantung, dan negosiasi server |
| sistem produk | DNS, pembongkaran cerdas, izin paket, dan penjadwalan node | Tidak setara dengan permukaan kontrol produk VPN yang lengkap | Tidak setara dengan permukaan kontrol produk VPN yang lengkap |
Tabel ini tidak mewakili kompatibilitas kode, peringkat kinerja, atau kesimpulan audit keamanan.
Platforms and openness
Kompatibilitas lintas platform dan batasan sumber terbuka
Konsistensi platform
SingLinkVPN mencakup perangkat iOS, Android, Windows, macOS, Linux, dan TV. Konsistensi lintas platform tidak berarti bahwa setiap platform menggunakan API sistem yang sama persis, tetapi mempertahankan rangkaian izin, perutean, logika pemilihan node dan protokol yang sama, dan mematuhi batasan perluasan jaringan setiap sistem operasi.
Ruang lingkup publik
Kode sumber protokol inti SingLink 2.0 belum diungkapkan sepenuhnya. Petunjuk yang dipublikasikan mencakup dokumentasi teknis, deskripsi arsitektur, data penelitian, metode pengujian yang dapat direproduksi, format data, alat verifikasi, dan infrastruktur pengungkapan kerentanan yang bertanggung jawab.
Frequently asked questions
Pertanyaan Umum
Q01Apa itu SingLink 2.0?
SingLink 2.0 adalah generasi protokol transmisi jaringan formal yang dikembangkan secara independen oleh SingLinkVPN. Ini digunakan untuk mengatur verifikasi identitas dan otoritas, perutean lalu lintas, sesi transmisi, pemrosesan TCP dan UDP, deteksi kesehatan, dan pemulihan pengecualian.
Q02Apakah SingLink 2.0 merupakan versi perangkat lunak klien?
Tidak. SingLink 2.0 adalah nama protokol dan pembuatan protokol. Windows, macOS, Android, iOS, dan klien lainnya menggunakan sistem versi perangkat lunak independen.
Q03Apa perbedaan antara SingLink Beta dan SingLink 2.0?
Beta adalah protokol pratinjau untuk verifikasi kecepatan dan kemampuan baru; SingLink 2.0 adalah generasi protokol resmi, lebih memperhatikan stabilitas, konsistensi lintas platform, pemulihan koneksi, dan kompatibilitas jangka panjang.
Q04Berapa tingkat stabilitas SingLink 2.0?
Catatan pengujian A/B internal SingLinkVPN di lingkungan pengujian yang ditentukan adalah 99,5%, dengan puncak Beta sekitar 97%. Hal ini bukan merupakan jaminan untuk semua wilayah dan periode waktu, dan hasil sebenarnya akan dipengaruhi oleh operator jaringan, beban node, peralatan, dan metode pengujian.
Q05Bagaimana SingLink menangani lalu lintas jaringan?
Klien pertama-tama membuat pintu masuk jaringan sistem, menyelesaikan DNS dan distribusi cerdas, kemudian memilih node, memverifikasi izin, membuat sesi transmisi, dan merangkum data TCP atau UDP sebelum mengirimkannya ke node.
Q06Bagaimana cara SingLink menangani pemutusan dan peralihan jaringan?
Klien terus memantau sesi dan status node. Ketika pengecualian terjadi, sesi akan dibangun kembali, DNS dan perutean dipulihkan, atau dialihkan ke node lain yang tersedia berdasarkan kemampuan.
Q07Apa perbedaan antara SingLink dan VLESS?
VLESS secara resmi diposisikan sebagai protokol transmisi klien dan server yang ringan dan tanpa kewarganegaraan. Cakupan yang dijelaskan dalam kertas putih SingLink lebih luas dan juga mencakup bidang kendali produk, izin node, perutean cerdas, deteksi kesehatan, dan proses pemulihan; keduanya tidak boleh dibandingkan berdasarkan format bingkai tunggal.
Q08Apa perbedaan antara SingLink dan AnyTLS?
Spesifikasi publik AnyTLS berfokus pada penjelasan autentikasi, Sesi, Penggunaan kembali aliran, Padding, dan detak jantung melalui TLS. Buku putih SingLink juga menjelaskan entri lalu lintas klien, DNS, perutean, izin paket, dan penjadwalan node, sehingga perbandingannya didasarkan pada batasan sistem daripada mengklaim bahwa implementasi yang mendasarinya sama.
Q09Siapa yang dapat menggunakan SingLink 2.0?
Saat ini, node protokol SingLink 2.0 sebagian besar terbuka untuk paket Pro, Max dan Rich; Node protokol SingLink Beta terbuka untuk semua paket. Node aktual yang tersedia dapat ditampilkan secara real-time pada klien.
Q10Apakah SingLink 2.0 sepenuhnya open source?
Saat ini, kode sumber protokol inti belum diungkapkan sepenuhnya. Dokumen teknis, data penelitian, metode pengujian, format data, alat verifikasi, dan mekanisme pengungkapan kerentanan telah disertakan dalam rencana sumber terbuka berkelanjutan. Ruang lingkup pengungkapan bergantung pada gudang SingLinkLabs dan pengumuman resmi.
References and revision
Data, tautan internal, dan catatan perubahan
Informasi protokol eksternal
Next step
Rasakan protokol SingLink 2.0
Node SingLink 2.0 sebagian besar terbuka untuk paket Pro, Max dan Rich. Jumlah node dan ketersediaan protokol dapat ditampilkan secara real-time pada klien.