Protokol SingLink 2.0

SingLink 2.0 adalah protokol transport jaringan resmi yang dikembangkan sendiri oleh SingLinkVPN. “2.0” menunjukkan nama dan generasi protokol; ini bukan versi perangkat lunak klien SingLinkVPN.

Protokol SingLink tidak hanya membawa lalu lintas ke node VPN. Protokol ini juga mencakup otorisasi akun dan node, penanganan DNS, perutean pintar, sesi terenkripsi, enkapsulasi TCP dan UDP, pemeriksaan kesehatan koneksi, perubahan jaringan, dan pemulihan dari gangguan.

Saat ini SingLink memiliki protokol produksi SingLink 2.0 dan protokol pratinjau SingLink Beta yang mengutamakan kecepatan. Dalam uji A/B internal, SingLink 2.0 mencapai stabilitas 99.5% dan Beta mencapai hingga sekitar 97%; dalam kondisi jaringan dan perangkat yang sesuai, kecepatan puncak Beta melampaui 1 Gbps.

Perbandingan data inti: SingLink 2.0 produksi mencatat stabilitas 99.5% di lingkungan pengujian yang ditentukan. Beta mencapai hingga sekitar 97%, tetapi melampaui kecepatan puncak 1 Gbps dalam kondisi jaringan dan perangkat yang sesuai. Hasil ini mencerminkan prioritas yang berbeda antara stabilitas dan kecepatan, dan bukan jaminan untuk setiap perangkat atau jaringan.

Bukti dan batasan teknis: Posisi produk yang sudah dikonfirmasi, definisi pengujian internal, dan fungsi publik dapat dikutip langsung. Algoritma enkripsi spesifik, format paket, negosiasi kemampuan, Session, Stream, multiplexing, dan detail pemulihan sesi di bawah ini adalah model pemrosesan acuan, bukan pernyataan tentang spesifikasi yang saat ini diterapkan. Dokumen teknis resmi SingLink dan kode sumber yang dipublikasikan di kemudian hari yang menjadi acuan utama.

Prinsip Pemrosesan Lengkap Protokol SingLink

Sistem secara keseluruhan dapat dibagi menjadi dua jalur:

Control plane

Bertanggung jawab atas:

• masuk ke akun;
• memvalidasi keanggotaan;
• mengambil daftar node;
• menentukan hak akses node;
• mengirimkan konfigurasi protokol;
• memperbarui aturan;
• memilih Beta atau 2.0.

Data plane

Bertanggung jawab atas:

• menerima lalu lintas aplikasi;
• me-resolve DNS;
• membangun koneksi yang aman;
• mengenkapsulasi dan membawa TCP dan UDP;
• menjaga koneksi tetap hidup;
• menangani koneksi yang terputus;
• mengembalikan data ke aplikasi.

Alur yang disederhanakan adalah:

Pengguna masuk ke SingLinkVPN
        ↓
Mengambil node yang diizinkan dan konfigurasi protokol
        ↓
Klien membuat TUN / proxy sistem
        ↓
Menerima lalu lintas aplikasi
        ↓
Mengevaluasi aturan DNS dan perutean
        ↓
Memilih node SingLink 2.0 atau Beta
        ↓
Menegosiasikan kemampuan protokol
        ↓
Memverifikasi hak akses akun dan perangkat
        ↓
Membuat sesi terenkripsi dan kunci sesi
        ↓
Membuat stream logis terpisah untuk setiap koneksi aplikasi
        ↓
Mengenkapsulasi data TCP / UDP
        ↓
Mengirim data ke node SingLink
        ↓
Node mendekapsulasi dan mengakses situs tujuan
        ↓
Mengembalikan data dan mengirimkannya ke aplikasi asal
        ↓
Terus mengukur latensi, packet loss, dan status koneksi
        ↓
Menyambung ulang, memulihkan, atau berganti node setelah gangguan

---

Tahap 1: Masuk, Pengambilan Node, dan Konfigurasi Protokol

Setelah pengguna membuka SingLinkVPN dan masuk, klien sebaiknya tidak langsung menyimpan semua alamat node produksi, kredensial, dan parameter protokol secara permanen di perangkat.

Alur yang lebih tepat adalah:

1. Klien mengirimkan kredensial akun.
2. Sistem akun memverifikasi pengguna.
3. Sistem memastikan paket dan hak akses node.
4. Sistem mengembalikan node yang tersedia untuk pengguna tersebut.
5. Sistem mengembalikan kredensial koneksi berumur pendek.
6. Sistem mengembalikan versi protokol saat ini dan konfigurasi yang diperlukan.
7. Klien memverifikasi integritas konfigurasi.
8. Konfigurasi sensitif disimpan di penyimpanan sistem yang terlindungi.

Lapisan ini terutama menentukan:

• apakah pengguna memiliki keanggotaan yang valid;
• apakah Beta atau 2.0 tersedia;
• apakah akun memiliki hak akses Pro, Max, atau Rich;
• negara dan node mana yang tersedia;
• apakah konfigurasi sudah kedaluwarsa;
• apakah klien harus diperbarui.

Penjelasan sederhana

Ini seperti pemeriksaan sebelum naik kereta cepat:

• siapa Anda;
• kelas tiket apa yang Anda beli;
• kereta mana yang boleh Anda naiki;
• apakah tiketnya masih berlaku.

Aturan keamanan yang disarankan

SingLink sebaiknya tidak terus-menerus mengandalkan satu kata sandi statis yang permanen.

Desain yang lebih tepat memakai:

• token koneksi berumur pendek;
• tantangan (challenge) sekali pakai;
• nonce perangkat;
• batas waktu kedaluwarsa;
• konfigurasi node yang ditandatangani server;
• mekanisme pencabutan.

Dengan begitu, memperoleh satu konfigurasi koneksi tidak akan memberikan akses permanen.

---

Tahap 2: Membangun Titik Masuk Jaringan Sistem

Saat pengguna memilih Hubungkan, SingLinkVPN pertama-tama perlu membuat titik masuk jaringan di sistem operasi.

Caranya berbeda di setiap platform:

Platform	Titik masuk jaringan yang umum
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension atau TUN
Windows	Adaptor virtual TUN dan perutean sistem
Linux	TUN, tabel perutean, dan manajemen DNS

Setelah titik masuk ini dibuat, data yang biasanya dikirim aplikasi langsung ke jaringan akan masuk terlebih dahulu ke klien SingLinkVPN.

Contohnya:

Aplikasi ChatGPT
    ↓
Network stack sistem operasi
    ↓
Antarmuka TUN SingLink
    ↓
Klien SingLinkVPN

Pada tahap ini, klien perlu:

• membuat IP virtual;
• mengonfigurasi tabel perutean;
• mengonfigurasi DNS;
• mengecualikan jaringan area lokal (LAN);
• mencegah koneksi proxy dirutekan kembali ke TUN;
• membuat aturan Kill Switch.

Poin terakhir sangat penting.

Tanpa pengecualian rute, lalu lintas yang dipakai SingLinkVPN untuk mencapai node bisa masuk kembali ke VPN dan menciptakan loop:

Lalu lintas VPN
↓
Masuk kembali ke VPN
↓
Dienkapsulasi lagi
↓
Loop tanpa akhir

Karena itu, klien harus secara eksplisit mengecualikan:

• IP node itu sendiri;
• antarmuka kontrol yang diperlukan;
• gateway lokal;
• layanan yang harus dijangkau sistem secara langsung.

---

Tahap 3: Resolusi DNS dan Evaluasi Domain

Saat pengguna membuka chatgpt.com, perangkat biasanya harus me-resolve domain tersebut menjadi alamat IP terlebih dahulu.

Penanganan DNS yang keliru dapat menyebabkan:

• permintaan DNS berjalan langsung melalui jaringan lokal;
• resolver DNS lokal mengembalikan alamat yang salah;
• aturan kehilangan konteks domain aslinya;
• lalu lintas IPv6 melewati VPN;
• kebocoran DNS meski VPN tampak terhubung.

Klien SingLink dapat memakai alur ini:

Aplikasi mengirim permintaan DNS
        ↓
Klien mencegat DNS
        ↓
Mengevaluasi aturan domain
        ↓
Memilih DNS lokal atau DNS jarak jauh yang terlindungi
        ↓
Memperoleh hasil IPv4 / IPv6
        ↓
Mengaitkan domain dengan IP
        ↓
Memilih langsung, proxy, atau blokir

Domain lokal

Bank lokal, perangkat LAN, atau layanan khusus wilayah dapat memakai DNS lokal dan terhubung langsung.

Domain yang di-proxy

Domain yang harus diakses melalui VPN dapat di-resolve melalui node proxy atau resolver DNS yang terlindungi.

Penjelasan sederhana

DNS ibarat mencari alamat.

Jika pencarian alamat itu masih memakai jalan lokal, situs yang diminta bisa terungkap meski data selanjutnya melewati VPN.

Karena itu, sistem protokol SingLink perlu menetapkan:

• apakah klien mencegat DNS;
• permintaan DNS mana yang langsung;
• permintaan DNS mana yang melalui VPN;
• bagaimana IPv4 dan IPv6 ditangani;
• berapa lama hasil DNS disimpan di cache;
• apakah hasil DNS yang usang dibersihkan setelah perubahan jaringan.

---

Tahap 4: Perutean Pintar dan Keputusan Rute

Setelah DNS dan lalu lintas aplikasi masuk ke klien, sistem harus memutuskan cara menanganinya.

Biasanya ada tiga kemungkinan hasil:

Langsung
Proxy
Blokir

Langsung

Lalu lintas memakai jaringan lokal dan tidak masuk ke tunnel SingLink.

Cocok untuk:

• perangkat LAN;
• situs web lokal;
• aplikasi yang tidak memerlukan proxy;
• daftar izin yang ditentukan pengguna.

Proxy

Lalu lintas masuk ke protokol SingLink dan diteruskan oleh node.

Cocok untuk:

• situs web luar negeri;
• alat AI;
• platform sosial internasional;
• aplikasi yang dipilih pengguna.

Blokir

Koneksi ditolak.

Cocok untuk:

• domain iklan;
• domain pelacak;
• alamat berbahaya;
• daftar blokir yang ditentukan pengguna.

Keputusan ini dapat mempertimbangkan:

• domain;
• alamat IP;
• port;
• aplikasi;
• lokasi geografis;
• jenis protokol;
• aturan pengguna;
• mode global atau mode aturan.

Penjelasan sederhana

Tahap ini mirip pengaturan lalu lintas jalan raya:

• kendaraan lokal memakai jalan biasa;
• kendaraan tujuan luar negeri masuk ke jalan tol terenkripsi;
• kendaraan berbahaya dilarang masuk.

---

Tahap 5: Pemilihan Node dan Protokol

Setelah lalu lintas dikenali sebagai lalu lintas yang di-proxy, klien harus memilih node.

Pemilihan tidak bisa hanya berdasarkan nama negara. Pemilihan juga harus mempertimbangkan:

• paket pengguna;
• apakah node memakai 2.0 atau Beta;
• apakah node sedang online;
• latensi;
• packet loss;
• beban;
• jarak ke node;
• operator lokal;
• lokasi tujuan;
• dukungan UDP;
• kompatibilitas klien.

Pemilihan manual

Pengguna memilih node di Jepang, Amerika Serikat, Singapura, atau lokasi lain.

Pemilihan pintar

Klien memilih node yang sesuai berdasarkan hasil pengujian.

Pemilihan pintar sebaiknya tidak sekadar memilih node dengan latensi terendah.

Contohnya:

Node	Latensi	Packet loss	Beban
A	50 ms	8%	90%
B	70 ms	0%	30%

Meskipun latensi A lebih rendah, packet loss dan bebannya tinggi; B mungkin lebih stabil dalam pemakaian nyata.

Karena itu, pemilihan pintar sebaiknya menggabungkan:

Latensi + packet loss + tingkat keberhasilan koneksi + beban + performa historis

---

Tahap 6: Negosiasi Kemampuan Protokol

Setelah klien mencapai node, klien sebaiknya tidak langsung berasumsi bahwa kedua pihak mendukung fungsi yang sama persis.

Kemampuan perlu dinegosiasikan terlebih dahulu.

Hal yang dinegosiasikan dapat mencakup:

• versi SingLink;
• Beta atau 2.0;
• dukungan TCP;
• dukungan UDP;
• IPv4 / IPv6;
• dukungan session resumption;
• dukungan multiplexing;
• ukuran frame data maksimum;
• strategi Padding;
• interval heartbeat;
• apakah kompresi diaktifkan;
• ukuran MTU;
• dukungan negosiasi ulang.

Contohnya:

Klien:
Saya mendukung SingLink 2.0
Saya mendukung TCP, UDP, dan IPv6
Saya mendukung Session Resume
Frame maksimum: 64 KB

Server:
Pemakaian SingLink 2.0 dikonfirmasi
TCP dan UDP tersedia
Session Resume tersedia
Frame maksimum efektif: 32 KB

Pada akhirnya kedua pihak hanya memakai kemampuan yang didukung bersama.

Mengapa negosiasi diperlukan?

Klien dan node mungkin tidak diperbarui pada hari yang sama.

Jika klien baru mengirim format yang tidak dikenali node lama, koneksi akan gagal.

SingLink 2.0 produksi sebaiknya lebih menekankan daripada Beta pada:

• kompatibilitas mundur;
• fallback versi;
• penurunan fungsi yang aman saat suatu fitur tidak tersedia;
• penolakan eksplisit terhadap versi yang tidak kompatibel.

---

Tahap 7: Verifikasi Identitas

Setelah koneksi dasar terbentuk, node perlu memastikan bahwa pengguna memiliki izin.

Data verifikasi yang disarankan meliputi:

• token berumur pendek;
• ID akun atau otorisasi;
• nonce klien;
• versi protokol;
• ID node;
• kemampuan yang diminta;
• data verifikasi integritas.

Paket autentikasi yang disederhanakan menyatakan:

Siapa saya
Node mana yang saya inginkan
Protokol mana yang saya inginkan
Pengenal acak untuk koneksi ini
Kapan otorisasi saya kedaluwarsa
Apakah data telah diubah

Server perlu memeriksa:

1. apakah token diterbitkan secara resmi;
2. apakah token sudah kedaluwarsa;
3. apakah token sudah dicabut;
4. apakah pengguna memiliki akses ke node;
5. apakah nonce pernah dipakai sebelumnya;
6. apakah permintaan merupakan replay;
7. apakah versi klien ini diizinkan terhubung.

Perlindungan replay

Penyerang bisa merekam data autentikasi yang valid lalu mengirimkannya lagi tanpa perubahan.

Karena itu, data autentikasi memerlukan:

• nonce sekali pakai;
• tantangan dari server;
• masa berlaku yang singkat;
• catatan kredensial yang sudah dipakai;
• pengikatan ke sesi.

Dalam bahasa sederhana:

Tiket yang sudah divalidasi tidak bisa disalin dan dipakai ulang tanpa batas.

---

Tahap 8: Pertukaran Kunci dan Sesi Terenkripsi

Setelah verifikasi identitas berhasil, klien dan node memerlukan kunci sesi khusus untuk koneksi ini.

Logika yang disarankan adalah:

Klien membuat kunci sementara (ephemeral)
        ↓
Server membuat kunci sementara (ephemeral)
        ↓
Keduanya bertukar data publik
        ↓
Masing-masing secara mandiri menghitung rahasia bersama yang sama
        ↓
Beberapa kunci sesi diturunkan dari rahasia bersama tersebut

Kunci terpisah sebaiknya diturunkan untuk:

• enkripsi dari klien ke server;
• enkripsi dari server ke klien;
• integritas data;
• pemulihan sesi;
• perlindungan header.

Semua arah dan tujuan sebaiknya tidak memakai satu kunci yang sama.

Forward secrecy

Desain yang lebih tepat memakai kunci sementara untuk setiap sesi.

Jika kunci jangka panjang server bocor di kemudian hari, kunci itu seharusnya tidak bisa langsung mendekripsi setiap koneksi yang pernah direkam sebelumnya.

Rotasi kunci

Koneksi yang berjalan lama sebaiknya tidak memakai satu set kunci sesi selamanya.

Kunci dapat diturunkan ulang dengan mempertimbangkan:

• volume data yang ditransfer;
• durasi koneksi;
• jumlah frame;
• instruksi dari server.

sebagai dasar untuk menurunkan ulang kunci.

Contohnya:

Setelah sejumlah GB tertentu
atau
setelah jangka waktu tertentu
turunkan kunci baru untuk tiap arah

Nilai pastinya sebaiknya ditentukan melalui pengujian performa dan keamanan rekayasa, bukan dikarang dalam artikel promosi.

---

Tahap 9: Membuat Session

Setelah identitas dan kunci terbentuk, kedua pihak membuat SingLink Session.

Sebuah Session dapat berisi:

• Session ID;
• versi protokol;
• parameter enkripsi;
• ukuran frame maksimum;
• interval heartbeat;
• mode UDP;
• batas Stream;
• batas waktu idle;
• kemampuan pemulihan sesi;
• kebijakan Beta atau 2.0.

Server mengembalikan konfirmasi:

Identitas terverifikasi
Session terbentuk
Memakai SingLink 2.0
TCP tersedia
UDP tersedia
Multiplexing tersedia
Heartbeat aktif

Klien sebaiknya baru mengirim data aplikasi setelah menerima konfirmasi dari server.

---

Tahap 10: Membuat Stream atau Koneksi Proxy Terpisah

Konfirmasi dari tim rekayasa diperlukan untuk memastikan arsitektur mana yang benar-benar dipakai SingLink.

Opsi 1: Satu Session membawa banyak Stream

Pendekatan ini mirip dengan AnyTLS:

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

Setiap Stream memerlukan:

• Stream ID;
• alamat tujuan;
• port tujuan;
• TCP atau UDP;
• status saat ini;
• jendela kirim;
• jendela terima.

Kelebihan:

• lebih sedikit handshake berulang;
• latensi koneksi lebih rendah;
• lebih sedikit koneksi dasar;
• efisien menangani banyak koneksi singkat.

Risiko:

• kegagalan satu Session dapat memengaruhi banyak Stream;
• satu koneksi TCP dasar dapat menyebabkan head-of-line blocking;
• diperlukan kontrol aliran yang lengkap.

Opsi 2: Setiap permintaan aplikasi membuat koneksi terpisah

ChatGPT → koneksi terpisah
YouTube → koneksi terpisah
Telegram → koneksi terpisah

Kelebihan:

• lalu lintas yang berbeda terisolasi;
• kegagalan satu koneksi tidak memengaruhi koneksi lain;
• logikanya lebih sederhana.

Kekurangan:

• lebih banyak handshake;
• overhead koneksi lebih besar;
• kurang efisien untuk banyak koneksi singkat.

Rekomendasi

SingLink dapat memakai mode hibrida:

• melakukan multiplexing koneksi singkat dan lalu lintas web biasa dalam satu Session;
• membuat kanal terpisah untuk unduhan besar dan video;
• menangani UDP berlatensi rendah secara terpisah;
• mencegah satu unduhan berkecepatan tinggi menghabiskan semua Stream.

---

Tahap 11: Enkapsulasi Frame Data

Data aplikasi tidak bisa begitu saja dimasukkan tanpa perubahan ke kanal transport. Data perlu dienkapsulasi menjadi frame protokol.

Secara konsep, sebuah frame SingLink dapat berisi:

Versi
Jenis frame
Session ID
Stream ID
Nomor urut
Flag
Panjang data
Data terenkripsi
Tag integritas

Jenis frame yang mungkin meliputi:

Jenis frame	Fungsi
OPEN	Membuat Stream baru
DATA	Membawa data
ACK	Mengonfirmasi status
FIN	Menutup secara normal
RESET	Menghentikan secara tidak normal
PING	Pemeriksaan kesehatan
PONG	Respons pemeriksaan kesehatan
UDP	Membawa datagram UDP
SETTINGS	Memperbarui parameter sesi
KEY_UPDATE	Merotasi kunci sesi
RESUME	Memulihkan sesi

Ini adalah rekomendasi desain protokol. Ini tidak menyatakan bahwa saat ini nama atau format bit tersebut sudah dipakai oleh SingLink.

---

Tahap 12: Pemrosesan Lalu Lintas TCP

Untuk koneksi TCP seperti situs web, API, dan unduhan file, SingLink perlu mempertahankan:

• urutan data;
• transfer dua arah;
• status penutupan;
• kontrol aliran;
• status galat.

Alur lengkapnya dapat berupa:

Aplikasi membuat koneksi TCP
        ↓
Klien membuat SingLink Stream
        ↓
Mengirim domain dan port tujuan
        ↓
Node terhubung ke situs tujuan
        ↓
Node melaporkan berhasil atau gagal
        ↓
Memulai penerusan dua arah

Penutupan normal

Saat aplikasi mengakhiri koneksi:

1. Klien mengirim FIN.
2. Node berhenti menerima data dari arah tersebut.
3. Node menunggu arah lainnya selesai.
4. Stream ditutup sepenuhnya.
5. Memori dan status koneksi dilepaskan.

Penutupan tidak normal

Jika tujuan menolak koneksi:

1. Node mengembalikan galat.
2. Klien melaporkan kegagalan koneksi ke aplikasi.
3. Stream langsung dibersihkan.
4. Stream lain tidak terpengaruh.

---

Tahap 13: Pemrosesan Lalu Lintas UDP

UDP tidak memiliki koneksi seperti TCP pada umumnya. Setiap datagram perlu mempertahankan:

• asosiasi sumber;
• alamat tujuan;
• port tujuan;
• panjang data;
• batas datagram;
• batas waktu asosiasi.

Contohnya:

UDP Association ID
Alamat tujuan
Port tujuan
Panjang data
UDP Payload

SingLink perlu memilih secara eksplisit di antara pendekatan berikut:

UDP over TCP

Datagram UDP dibawa di dalam TCP atau Session yang andal.

Kelebihan:

• lebih mudah menembus jaringan yang hanya mengizinkan TCP;
• kemungkinan kehilangan data lebih kecil;
• deployment lebih sederhana.

Kekurangan:

• packet loss pada TCP memblokir data UDP berikutnya;
• kurang cocok untuk sebagian game, panggilan suara, dan pemakaian real-time.

UDP native

UDP membawa data secara langsung.

Kelebihan:

• latensi rendah;
• cocok untuk game, panggilan suara, dan QUIC;
• tidak terpengaruh head-of-line blocking TCP.

Kekurangan:

• sebagian jaringan membatasi UDP;
• penanganan NAT dan firewall lebih rumit.

Transport bergaya QUIC

Transport ini berbasis UDP, tetapi menyediakan di lapisan protokol:

• enkripsi;
• transmisi ulang;
• banyak Stream;
• kontrol kemacetan;
• migrasi jaringan.

Kemampuan teknisnya lebih lengkap, tetapi lebih sulit diimplementasikan.

Arah yang masuk akal bagi SingLink adalah:

Secara otomatis memilih UDP native, enkapsulasi yang andal, atau mode kompatibel lainnya sesuai jenis jaringan dan lalu lintas.

Apakah hal ini sudah diimplementasikan masih perlu dikonfirmasi.

---

Tahap 14: Kontrol Aliran dan Backpressure

Misalkan YouTube sedang mengunduh dengan cepat, sementara ChatGPT hanya mentransfer sedikit teks.

Tanpa kontrol aliran, Stream video dapat memenuhi kanal dan menyebabkan:

• respons ChatGPT melambat;
• DNS tertunda;
• aplikasi macet;
• pemakaian memori terus meningkat.

Karena itu, diperlukan dua tingkat kontrol aliran:

Tingkat Session

Membatasi berapa banyak data yang belum dikonfirmasi yang dapat dibawa oleh seluruh Session.

Tingkat Stream

Membatasi seberapa besar jendela transport yang dapat ditempati setiap Stream.

Dalam bahasa sederhana:

Satu truk besar tidak boleh menguasai semua lajur jalan tol. Setiap Stream perlu mendapat jatah sumber daya transport yang adil.

Protokol 2.0 produksi dapat memakai penjadwalan yang lebih konservatif daripada Beta agar upaya mengejar kecepatan puncak tidak mengganggu koneksi lain.

---

Tahap 15: Segmentasi, Padding, dan Tampilan Lalu Lintas

Setelah data dienkripsi, pengamat mungkin masih dapat melihat:

• panjang paket;
• interval pengiriman;
• durasi koneksi;
• rasio unggah/unduh;
• perilaku penyambungan ulang.

Karena itu, protokol dapat mengubah tampilan lalu lintas, misalnya dengan:

• memecah data besar menjadi beberapa frame;
• menggabungkan data kecil;
• menambahkan Padding yang bervariasi;
• menyesuaikan kelompok pengiriman;
• menghindari satu panjang handshake yang tetap;
• memperbarui strategi Padding secara berkala.

Namun, harus jelas bahwa:

Padding tidak dapat menggantikan enkripsi dan tidak dapat menjamin lalu lintas akan selalu tidak dapat dikenali.

Padding yang berlebihan juga menyebabkan:

• lalu lintas bertambah;
• latensi lebih tinggi;
• pemakaian CPU lebih besar;
• kuota Paket Gratis terbuang.

Karena itu, profil 2.0 dapat menyesuaikan diri:

• memakai overhead rendah di jaringan biasa;
• meningkatkan pemrosesan tampilan di lingkungan jaringan khusus;
• mengurangi Padding yang tidak perlu saat unduhan berkecepatan tinggi;
• menerapkan padding yang sesuai pada data kontrol berukuran kecil.

Sebaliknya, Beta dapat mengurangi overhead tambahan untuk meningkatkan kecepatan puncak.

---

Tahap 16: Penanganan MTU dan Ukuran Paket

Menambahkan header protokol dan data terenkripsi ke lalu lintas TUN akan memperbesar ukuran paket.

Melebihi MTU jaringan dapat menyebabkan:

• fragmentasi IP;
• paket terbuang;
• situs web gagal dibuka;
• kecepatan tidak stabil;
• VPN terhubung tetapi tidak ada data yang lewat.

SingLink perlu:

1. menentukan MTU TUN;
2. mengurangi ukuran header protokol;
3. mengurangi overhead enkripsi;
4. menyesuaikan untuk IPv4 dan IPv6;
5. memecah data bila diperlukan;
6. menghindari fragmentasi IP yang tidak perlu.

Inilah sebabnya satu ukuran paket yang tetap tidak cocok untuk setiap jaringan.

SingLink 2.0 produksi seharusnya memiliki kompatibilitas MTU lintas platform yang lebih lengkap. Jika Beta memakai frame besar yang lebih agresif, Beta mungkin lebih cepat di sebagian jaringan, tetapi kurang stabil di jaringan yang tidak biasa.

---

Tahap 17: Penanganan Latensi, Packet Loss, dan Kemacetan

Klien perlu terus mengamati:

• latensi RTT;
• jitter;
• packet loss;
• kecepatan kirim;
• kecepatan terima;
• data yang belum dikonfirmasi;
• respons node.

Klien tidak bisa mengandalkan satu Ping saja.

Contohnya:

Normal: 60 ms
Naik sementara: 120 ms
Naik terus-menerus: 500 ms
Tidak ada respons: timeout

Situasi yang berbeda memerlukan penanganan yang berbeda:

Situasi	Penanganan
Latensi sementara	Tetap menunggu; jangan langsung menyambung ulang
Packet loss ringan	Sesuaikan jendela atau laju pengiriman
Latensi tinggi terus-menerus	Kurangi konkurensi atau pertimbangkan node lain
Tidak ada data tetapi heartbeat berhasil	Pertahankan Session
Heartbeat dan data sama-sama gagal	Anggap koneksi terputus
Node gagal total	Sambung ulang atau ganti node

Menyambung ulang setelah satu paket hilang justru akan membuat protokol kurang stabil.

---

Tahap 18: Heartbeat dan Pemeriksaan Kesehatan

Bahkan ketika tidak ada data aplikasi dalam waktu lama, sistem perlu tahu apakah kanal masih hidup.

Sistem dapat memakai:

PING
↓
PONG

Heartbeat tidak boleh terlalu sering.

Frekuensi yang berlebihan:

• memboroskan baterai;
• memakan kuota data;
• menambah beban server;
• menciptakan karakteristik waktu yang tetap.

Frekuensi yang terlalu jarang:

• memperlambat deteksi node yang gagal;
• membuat aplikasi menunggu lebih lama;
• memperlambat pemulihan setelah perubahan jaringan.

Karena itu, frekuensi heartbeat dapat menyesuaikan dengan kondisi:

• saat ada lalu lintas normal, jangan tambahkan heartbeat;
• setelah periode idle, mulai heartbeat berfrekuensi rendah;
• setelah perubahan jaringan, tingkatkan pemeriksaan untuk sementara;
• setelah kegagalan berulang, tandai koneksi sebagai terputus.

---

Tahap 19: Perubahan Jaringan dan Pemulihan Sesi

Saat ponsel berpindah dari Wi-Fi ke 5G, koneksi semula biasanya menjadi tidak valid.

Penanganan yang lengkap seharusnya:

Mendeteksi perubahan jaringan
        ↓
Berhenti mengirim data baru melalui kanal yang gagal
        ↓
Memperoleh IP lokal dan rute baru
        ↓
Menyambung ulang ke node semula
        ↓
Mengirim kredensial pemulihan sesi
        ↓
Server memvalidasi Session lama
        ↓
Memulihkan Stream logis yang dapat dipulihkan
        ↓
Memberi tahu aplikasi untuk membangun ulang koneksi TCP yang tidak dapat dipulihkan

Batasan penting:

Tidak setiap koneksi TCP aplikasi dapat dipulihkan tanpa jeda.

Protokol dapat memulihkan:

• status Session;
• otorisasi node;
• parameter protokol;
• sebagian Stream yang statusnya masih valid.

Namun, jika koneksi TCP milik situs tujuan sendiri sudah berakhir, aplikasi mungkin tetap perlu menyambung ulang.

Karena itu, hal ini tidak boleh dipromosikan sebagai:

Setiap aplikasi akan selalu mengalami perubahan jaringan tanpa gangguan sama sekali.

Pernyataan yang lebih akurat adalah:

SingLink 2.0 mempersingkat waktu penyambungan ulang, memulihkan status protokol dan perutean, serta berupaya meminimalkan dampaknya pada aplikasi.

---

Tahap 20: Kegagalan Node dan Peralihan Otomatis

Gangguan node dapat dibagi menjadi:

Kegagalan ringan

• latensi meningkat;
• packet loss sesekali;
• tidak ada respons untuk sementara;
• sebagian tujuan tidak dapat dijangkau.

Penanganan:

• tunggu sebentar;
• kurangi tekanan transport;
• ukur kembali;
• sambung ulang ke node yang sama.

Kegagalan berat

• node tidak dapat dijangkau;
• antarmuka autentikasi tidak tersedia;
• timeout terus-menerus;
• node dihentikan dari layanan.

Penanganan:

1. Berhenti memakai node semula.
2. Aktifkan Kill Switch.
3. Pilih node alternatif dari daftar yang tersedia.
4. Bangun Session aman yang baru.
5. Pulihkan DNS dan rute.
6. Beri tahu aplikasi untuk membangun ulang koneksi yang diperlukan.

SingLink 2.0 produksi dapat beralih secara lebih konservatif agar jitter sesaat tidak menyebabkan perpindahan node berulang kali.

Beta dapat menyambung ulang atau memilih node berkecepatan tinggi secara lebih agresif, tetapi hal ini dapat menghasilkan variasi yang lebih besar.

---

Tahap 21: Pengembalian Data dan Dekapsulasi

Respons dari situs tujuan mengikuti alur ini:

Situs tujuan mengembalikan data
        ↓
Node SingLink menerimanya
        ↓
Mencari Session dan Stream yang cocok
        ↓
Mengenkapsulasi sebagai frame data SingLink
        ↓
Mengenkripsi dan mengirim ke klien
        ↓
Klien memverifikasi integritas
        ↓
Mendekripsi
        ↓
Memisahkan berdasarkan Stream ID
        ↓
Menulis ke TUN atau proxy sistem
        ↓
Mengembalikan ke aplikasi asal

Klien perlu memeriksa:

• apakah data telah diubah;
• apakah nomor urutnya benar;
• apakah frame tersebut duplikat;
• apakah Stream masih ada;
• apakah panjang data masih dalam batas;
• apakah jendela terima terlampaui.

Data yang tidak valid tidak boleh langsung diteruskan ke aplikasi.

---

Tahap 22: Pemutusan Normal dan Pembersihan yang Aman

Saat pengguna memilih Putuskan, klien seharusnya:

1. berhenti menerima lalu lintas baru yang di-proxy;
2. menutup Stream yang aktif secara normal;
3. mengirim penghentian Session ke node;
4. menghapus kunci sesi;
5. mencabut atau membuang token berumur pendek;
6. menutup TUN;
7. memulihkan rute sistem;
8. memulihkan DNS;
9. menghapus aturan Kill Switch;
10. menghapus konfigurasi sementara yang tidak diperlukan.

Jika klien crash, sistem operasi atau peluncuran berikutnya juga memerlukan jalur perbaikan agar tidak meninggalkan:

• proxy sistem yang tidak valid;
• DNS yang salah;
• rute yang tersisa;
• tidak ada akses internet;
• Kill Switch yang terkunci permanen.

---

Perbedaan Strategi Terperinci antara SingLink Beta dan 2.0

Berikut ini menggambarkan posisi teknis produk; parameter pastinya masih memerlukan konfirmasi dari tim rekayasa.

Area pemrosesan	SingLink Beta	SingLink 2.0
Arah utama	Kecepatan puncak	Kecepatan, stabilitas, kompatibilitas
Parameter koneksi	Lebih agresif	Adaptif dan lebih konservatif
Konkurensi	Dapat memakai konkurensi lebih tinggi	Mencegah satu aliran memenuhi kanal
Jendela transport	Condong ke throughput	Disesuaikan dinamis terhadap latensi dan packet loss
Peralihan node	Lebih cepat mencoba node berkecepatan tinggi	Memastikan kegagalan sebelum beralih
Multiplexing	Condong ke efisiensi pemakaian ulang	Menyeimbangkan pemakaian ulang dan isolasi kegagalan
Padding	Mengutamakan overhead lebih rendah	Menyesuaikan dengan lingkungan
Perubahan jaringan	Pemulihan dasar	Pemulihan dan kompatibilitas yang lebih lengkap
Pengujian regresi platform	Cakupan pratinjau	Pengujian produksi penuh
Stabilitas internal	Sekitar 97%	99.5%
Kecepatan	Di atas 1 Gbps dalam kondisi yang sesuai	Tetap cepat tanpa hanya mengejar angka puncak

---

Prinsip Pemrosesan Lengkap dalam Satu Paragraf

SingLink pertama-tama membuat klien mengambil alih lalu lintas perangkat dan menyelesaikan pemrosesan DNS, perutean pintar, serta pemilihan node. Selanjutnya SingLink memverifikasi hak akses akun dan node, menegosiasikan kemampuan protokol dengan node, dan membangun kunci enkripsi sementara. Setelah koneksi terbentuk, lalu lintas TCP dan UDP setiap aplikasi dienkapsulasi sebagai koneksi proxy terpisah atau Stream logis, lalu dibawa melalui kanal yang terlindungi ke node, yang kemudian mengakses situs tujuan. Selama transfer, sistem terus mengelola jendela aliran, integritas data, latensi, packet loss, heartbeat, dan status node. Saat jaringan berubah atau node gagal, sistem membangun ulang Session, memulihkan rute, atau beralih ke node yang tersedia.

Perbedaan mendasar antara Beta dan 2.0 adalah:

SingLink Beta mengejar kecepatan puncak secara lebih agresif. SingLink 2.0 menambahkan kompatibilitas, pemeriksaan kesehatan, klasifikasi gangguan, pemulihan sesi, dan penanganan lintas platform yang lebih lengkap sambil tetap mempertahankan transfer berkecepatan tinggi, sehingga mencapai stabilitas yang lebih tinggi.

---

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu SingLink 2.0?

SingLink 2.0 adalah protokol transport jaringan resmi yang dikembangkan oleh SingLinkVPN. Protokol ini menangani verifikasi identitas, sesi terenkripsi, enkapsulasi lalu lintas, transport TCP dan UDP, pemeriksaan kesehatan, dan pemulihan dari gangguan.

Apakah SingLink 2.0 adalah versi perangkat lunak?

Bukan. SingLink 2.0 adalah nama resmi protokolnya. Versi klien Windows, macOS, Android, dan iOS memakai sistem penomoran versi yang terpisah.

Apa perbedaan antara SingLink Beta dan 2.0?

SingLink Beta adalah protokol pratinjau yang mengutamakan kecepatan, dengan kecepatan puncak yang bisa melampaui 1 Gbps dalam kondisi yang sesuai. SingLink 2.0 adalah protokol produksi yang menekankan kecepatan, stabilitas, kompatibilitas lintas platform, dan pemulihan saat koneksi terputus.

Berapa tingkat stabilitas SingLink 2.0?

Dalam uji A/B internal SingLinkVPN pada kondisi yang ditentukan, SingLink 2.0 mencapai stabilitas 99.5% dan Beta mencapai hingga sekitar 97%.

Bagaimana SingLink memproses lalu lintas jaringan?

Klien SingLink pertama-tama mengambil alih lalu lintas sistem serta melakukan penanganan DNS dan perutean pintar. Klien lalu memverifikasi hak akses akun dan node, membangun Session terenkripsi, mengenkapsulasi data TCP atau UDP, dan mengirimkannya ke node.

Bagaimana SingLink menangani koneksi yang terputus?

SingLink terus memeriksa latensi, packet loss, heartbeat, dan status node. Setelah terjadi gangguan, sistem dapat membangun ulang Session, memulihkan rute, atau beralih ke node yang tersedia.

Apa bedanya SingLink dengan VLESS?

VLESS terutama mendefinisikan identitas, perintah, dan penerusan ke tujuan. SingLink memadukan identitas, perutean, hak akses node, kebijakan transport, pemeriksaan kesehatan, dan pemulihan gangguan ke dalam sistem protokol yang lebih luas.

Apa bedanya SingLink dengan AnyTLS?

AnyTLS terutama membawa satu Session dan banyak Stream melalui koneksi TLS. SingLink memiliki peran produk yang lebih luas, yang juga mencakup perutean pintar, hak akses keanggotaan, penjadwalan node, dan pemulihan koneksi. Implementasi Session dan Stream yang sebenarnya tetap mengacu pada dokumentasi teknis resmi.

Siapa yang bisa memakai SingLink 2.0?

Node protokol SingLink 2.0 produksi saat ini terutama tersedia untuk pengguna Pro, Max, dan Rich. Protokol Beta terbuka untuk semua anggota. Tampilan klien terbaru menjadi acuan untuk akses yang sebenarnya.

Apakah SingLink 2.0 sepenuhnya open source?

Kode sumber protokol inti belum sepenuhnya publik, tetapi dokumen teknis, metode pengujian, format data, alat validasi, dan mekanisme pengungkapan kerentanan merupakan bagian dari rencana open source yang berkelanjutan.

---

Sumber dan Bacaan Lanjutan

Posisi produk dan pernyataan cakupan publik dalam artikel ini juga merujuk pada pusat teknologi resmi SingLinkVPN, repositori riset publik SingLinkLabs, dan metodologi benchmark performa-nya.

Bacaan terkait meliputi panduan lengkap Paket Gratis SingLinkVPN, rencana open source SingLinkVPN, dan laporan audit keamanan SingLinkVPN 2026.

Catatan teknis: Angka 99.5%, sekitar 97%, dan di atas 1 Gbps masing-masing merupakan hasil stabilitas uji A/B internal dan hasil throughput puncak dalam kondisi yang ditentukan. Angka-angka ini tidak berarti setiap wilayah, perangkat, operator, jaringan, atau periode waktu akan menghasilkan hasil yang sama. Algoritma enkripsi spesifik, format paket, mekanisme Session, dan mekanisme Stream tetap mengacu pada dokumen teknis resmi SingLink dan kode sumber yang dipublikasikan di kemudian hari.