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 Atom
Chapter 01

Scope 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.

Kemampuan yang dikonfirmasi

Dari halaman produk, kemampuan klien, dan kaliber publik resmi.

Deskripsi desain publik

Jelaskan masalah yang perlu dipecahkan oleh protokol dan batasan sistem yang saat ini terbuka.

Model implementasi referensi

Digunakan untuk menjelaskan kemungkinan implementasi, tidak setara dengan spesifikasi biner yang dipublikasikan.

Chapter 02

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.

Chapter 03

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
Akun dan konfigurasi
Pintu masuk jaringan sistem
DNS dan pembongkaran
Node dan sesi
Transmisi TCP/UDP
Kembali dan bersihkan
Chapter 04

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.

  1. 01

    Login akun dan konfirmasi izin

    Kemampuan yang dikonfirmasi

    Klien 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.

  2. 02

    Pengiriman konfigurasi node dan protokol

    Deskripsi desain publik

    Bidang 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.

  3. 03

    Menetapkan pintu masuk jaringan sistem

    Kemampuan yang dikonfirmasi

    Klien menerima lalu lintas yang perlu diproses melalui mode TUN, proxy sistem, atau ekstensi jaringan platform. Pintu masuk spesifiknya bergantung pada kemampuan sistem operasi.

  4. 04

    Resolusi DNS dan penentuan nama domain

    Kemampuan yang dikonfirmasi

    Kebijakan 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.

  5. 05

    Distribusi lalu lintas yang cerdas dan penilaian perutean

    Kemampuan yang dikonfirmasi

    Menentukan koneksi sebagai koneksi langsung, proxy, atau diblokir berdasarkan aturan, aplikasi, nama domain target, IP, dan status jaringan.

  6. 06

    Pemilihan simpul

    Kemampuan yang dikonfirmasi

    Mode manual menggunakan node yang ditentukan pengguna; mode cerdas dapat memilih kandidat node berdasarkan latensi, ketersediaan, beban, wilayah, dan izin paket.

  7. 07

    Negosiasi kemampuan protokol

    Deskripsi desain publik

    Klien 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.

  8. 08

    Otentikasi dan anti-pemutaran ulang

    Model implementasi referensi

    Node memverifikasi bahwa akun atau sesi tersebut valid dan harus mencegah data autentikasi lama digunakan kembali melalui penuaan, pengacakan, atau mekanisme serupa.

  9. 09

    Pertukaran kunci dan kunci sesi

    Model implementasi referensi

    Protokol 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. 10

    Buat Sesi

    Model implementasi referensi

    Sesi mewakili sesi transmisi antara klien dan node, yang dapat membawa status koneksi, informasi kemampuan, detak jantung, dan satu atau lebih aliran logis.

  11. 11

    Buat koneksi Stream atau proxy independen

    Model implementasi referensi

    Setiap permintaan aplikasi dapat dipetakan ke Aliran logis dalam Sesi, atau koneksi independen dapat dibuat; metode terakhir tergantung pada implementasi publik.

  12. 12

    Enkapsulasi bingkai data

    Model implementasi referensi

    Informasi tujuan, identifikasi aliran, panjang muatan, perintah kontrol, dan data diperlukan untuk membentuk kerangka parsable; halaman ini tidak menciptakan bidang biner yang tidak berdokumen.

  13. 13

    Pemrosesan lalu lintas TCP

    Deskripsi desain publik

    Aliran byte TCP perlu menjaga ketertiban, menangani penutupan setengah dan penutupan abnormal, dan meneruskan tekanan balik sisi aplikasi ke sisi transportasi.

  14. 14

    Pemrosesan lalu lintas UDP dan QUIC

    Deskripsi desain publik

    Datagram 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. 15

    Kontrol aliran dan tekanan balik

    Model implementasi referensi

    Ketika kecepatan konsumsi klien, node, atau layanan target melambat, pertumbuhan buffer harus dibatasi untuk mencegah satu Aliran menjatuhkan seluruh Sesi.

  16. 16

    Subpackaging, Padding dan tampilan lalu lintas

    Model implementasi referensi

    Paketisasi 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. 17

    Penanganan MTU dan ukuran paket

    Deskripsi desain publik

    Tunnel overhead akan mengurangi MTU yang tersedia, dan kegagalan paket yang besar perlu dikurangi melalui penghindaran fragmentasi, penyesuaian MSS, atau mekanisme yang setara.

  18. 18

    Penundaan, kehilangan paket dan penanganan kemacetan

    Model implementasi referensi

    Protokol 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. 19

    Deteksi detak jantung dan kesehatan

    Kemampuan yang dikonfirmasi

    Terus pantau sesi dan status node agar tidak hanya mengandalkan waktu tunggu sistem operasi yang lama untuk mendeteksi koneksi mati.

  20. 20

    Peralihan jaringan dan pemulihan sesi

    Kemampuan yang dikonfirmasi

    Setelah 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. 21

    Kegagalan node dan peralihan otomatis

    Kemampuan yang dikonfirmasi

    Jika 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. 22

    Mengembalikan data, dekapsulasi, dan pembersihan keamanan

    Deskripsi desain publik

    Klien memverifikasi dan mendekapsulasi data yang dikembalikan, dan menghapus status sesi sementara, kunci cache, perutean, dan perubahan DNS setelah koneksi selesai.

Chapter 05

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.

DIRECT

koneksi langsung

Layanan atau target lokal yang secara eksplisit tidak memerlukan proxy menggunakan jaringan lokal.

TUNNEL

agen

Setelah verifikasi izin, koneksi dibuat melalui node SingLink yang dipilih.

BLOCK

blok

Koneksi ditolak ketika aturan keamanan tercapai atau target tanpa izin tercapai.

Chapter 06

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.

Chapter 07

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.

Koneksi aplikasi
Aliran Logis
Sesi Pemindahan
simpul SingLink

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.

Chapter 08

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.

Chapter 09

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.

01

kontrol aliran

Sesuaikan jendela pengiriman sesuai dengan kecepatan konsumsi untuk menghindari pemblokiran seluruh sesi dengan satu aliran.

02

penanganan MTU

Pertimbangkan tambahan overhead terowongan untuk mengurangi risiko fragmentasi dan lubang hitam.

03

pemeriksaan kesehatan

Tentukan koneksi berdasarkan detak jantung, penundaan, kehilangan paket, dan status penerusan sebenarnya.

04

pemulihan jaringan

Setelah jaringan terputus, portal, DNS, perutean, dan sesi dibangun kembali untuk mencegah lalu lintas tersambung langsung secara tidak sengaja.

Chapter 10

Product comparison

SingLink 2.0 dan Beta

indikatorSingLink 2.0SingLink Beta
Penentuan posisikesepakatan formal antar generasiProtokol pratinjau yang mengutamakan kecepatan
Tingkat stabilitas pengujian A/B internal99.5%Hingga sekitar 97%
Fokus kecepatanKeseimbangan kecepatan, stabilitas dan kompatibilitasNilai puncak melebihi 1Gbps dalam kondisi yang sesuai
Izin simpul protokolPro, Maks dan KayaSemua paket
mengubah strategiFokus pada kompatibilitas dan pemulihan jangka panjangDigunakan untuk verifikasi kemampuan dan kinerja baru
Chapter 11

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.

DimensiRuang Lingkup Buku Putih SingLinkRuang lingkup publik VLESSRuang lingkup publik AnyTLS
posisi publikSistem keseluruhan bidang kendali produk dan bidang data transmisiProtokol transport klien dan server yang ringan dan tanpa kewarganegaraanProtokol proxy dan implementasi referensi berbasis TLS
Identitas dan TujuanAkun, izin node, kolaborasi sesi dan peruteanUUID, perintah, port dan alamat targetTLS pasca-otentikasi, lalu buat sesi
Session/StreamPenjelasan model referensi, format persisnya belum diungkapkanDukungan Mux, detailnya ditentukan oleh implementasi dan konfigurasiEkspos bingkai sesi, Streaming multiplexing, dan perintah
penampilan lalu lintasStrategi transmisi yang harus diverifikasi, tidak mengklaim tembus pandang secara mutlakDokumen resmi menjelaskan Aliran opsional dan mekanisme lainnyaPengungkapan subkontrak, rencana padding dan mekanisme pembaruan
KetahananDeteksi kesehatan, pemutusan jaringan, rekonstruksi sesi, dan peralihan nodeBertanggung jawab atas ekologi sinar X dan kombinasi transmisi spesifikProtokol v2 memperlihatkan SYNACK, detak jantung, dan negosiasi server
sistem produkDNS, pembongkaran cerdas, izin paket, dan penjadwalan nodeTidak setara dengan permukaan kontrol produk VPN yang lengkapTidak setara dengan permukaan kontrol produk VPN yang lengkap

Tabel ini tidak mewakili kompatibilitas kode, peringkat kinerja, atau kesimpulan audit keamanan.

Chapter 12

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.

Chapter 13

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.

Chapter 14

References and revision

Data, tautan internal, dan catatan perubahan

Versi 1.0 · 29 Juli 2026:Versi pertama dalam bahasa Cina Sederhana dirilis, yang mengatur siklus hidup koneksi lengkap, status bukti, batasan data Beta, perbandingan data publik VLESS dan AnyTLS, dan menambahkan mekanisme penemuan TechArticle, FAQ, Canonical, Feed, dan peta situs.

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.