Tailscale menerbitkan catatan teknis pada 22 September 2026 yang merinci serangkaian perbaikan performa di sisi data plane. Isinya bukan pengumuman fitur baru yang bisa langsung dipakai semua orang, melainkan penjelasan tentang apa yang mereka temukan saat membedah jalur paket di klien mereka, dan apa yang mereka ubah. Bagi siapa pun yang menjalankan VPN mesh untuk menghubungkan server, subnet router, atau perangkat edge, catatan ini menjelaskan dari mana sebagian besar biaya performa sebenarnya berasal.
TL;DR
- Tailscale merilis catatan teknis pada 22 September 2026 yang merinci perbaikan performa data plane, mulai dari pengelolaan buffer, multi-queue, writev, hingga netmap caching.
- Perubahan buffer pada Linux dan Android yang membiarkan paket kecil tetap di tempatnya menghasilkan percepatan sekitar 5 persen di banyak konfigurasi jaringan.
- Sistem multi-queue untuk subnet router, app connector, dan exit node memungkinkan paket diproses paralel di beberapa inti CPU dengan kapasitas agregat lebih tinggi dan jeda lebih rendah.
- Netmap caching menyimpan salinan network map di disk sehingga perangkat bisa mulai berkomunikasi satu sampai dua orde besaran lebih cepat pada jaringan dengan keterjangkauan control plane buruk.
- Pengurangan memori lewat perubahan buffer diharapkan hadir pada klien versi 1.104, sementara netmap caching sudah bisa diuji lewat feature flag pada klien saat ini.
Konteksnya penting. Tailscale sudah lama dikenal karena kemampuan menembus NAT, sehingga perangkat bisa saling terhubung di berbagai kondisi jaringan. Tapi NAT traversal bukan satu-satunya hal yang menentukan. Setelah koneksi terbentuk, data plane harus sanggup memindahkan paket dengan efisien. Di situlah pekerjaan mereka berlanjut, dari peningkatan throughput TCP di perangkat Linux, terobosan di implementasi wireguard-go untuk melewati 10 Gb/s di bare metal, sampai pemanfaatan segmentation offload untuk aplikasi berbasis UDP.
Masalah pertama: paket kecil yang dipaksa masuk buffer besar
Temuan pertama mereka terasa sepele sampai angkanya muncul. Sebagian besar paket jaringan berukuran kecil, sekitar 1 KiB. Namun untuk memanfaatkan alat throughput paling efisien di Linux seperti Generic Receive Offload, klien harus siap menerima 64 KiB trafik sekaligus. Perumpamaan yang dipakai Tailscale cukup jelas: bayangkan pelabuhan, kapal, dan truk yang semuanya dirancang untuk satu ukuran kontainer, tidak peduli seberapa penuh kontainer itu.
Masalahnya, implementasi wireguard-go yang menjadi dasar kriptografi dan jaringan Tailscale hanya menyediakan satu ukuran buffer 64 KiB untuk membongkar paket. Akibatnya paket berukuran 1 KiB disalin ke buffer 64 KiB miliknya sendiri, setiap kali. Untuk beban kerja dengan banyak paket kecil, ini pemborosan memori dan waktu salin yang terjadi terus-menerus.
Perbaikannya sederhana secara konsep: pada Linux dan Android, Tailscale sekarang membiarkan paket tetap di tempatnya. Klien mengidentifikasi di mana setiap paket mulai dan berakhir di dalam satu pembacaan besar, alih-alih menyalinnya ke lokasi baru. Paket kecil tetap kecil di memori, banyak paket berbagi satu alokasi, dan waktu yang dihabiskan untuk menyalin berkurang. Perubahan ini sendiri menghasilkan percepatan sekitar 5 persen di banyak konfigurasi jaringan.
Secara terpisah, mereka memperpendek antrean paket, yaitu baris tunggu paket di antara tahap-tahap pipeline. Antrean itu ada untuk menyerap lonjakan trafik, tapi pengujian menunjukkan sebagian besar kedalamannya tidak terpakai, sementara antrean yang lebih pendek berarti waktu tunggu lebih singkat dan memori lebih hemat. Memori yang terbebaskan itu kemudian dialokasikan ke node yang paling sibuk: subnet router dan app connector.
Multi-queue untuk subnet router, app connector, dan exit node
Sebelum perubahan ini, subnet router, app connector, dan exit node memproses paket dari banyak aliran independen dalam satu pipeline berurutan dengan satu thread. Artinya satu lajur dipakai bersama oleh banyak koneksi, karena aplikasi penerima tidak boleh melihat paketnya datang tidak berurutan.
Setelah jejak memori berhasil ditekan, mereka punya kapasitas untuk menerapkan sistem multi-queue: beberapa lajur alih-alih satu, dan jumlahnya diskalakan ke sumber daya mesin, bukan ke jumlah peer. Setiap aliran paket mendapat satu lajur dan tetap di sana, sementara lajur-lajur itu berjalan paralel sehingga pekerjaan bisa tersebar ke beberapa inti CPU.
Hasilnya adalah kapasitas agregat yang lebih tinggi dan jeda yang lebih rendah antara penerimaan dan penerusan paket. Perangkat keras yang sudah ada jadi terpakai lebih efisien. App connector dan exit node, yang biasanya melayani banyak pengguna dengan koneksi berumur pendek, mendapat peningkatan paling terasa. Alex Valiushko, anggota staf teknis Tailscale, menggambarkan hasilnya sebagai pemrosesan data yang lebih cepat sejak paket dibaca dari jaringan sampai dikirim ke sistem operasi.
writev: menggambarkan data tanpa memindahkannya
Perbaikan berikutnya memanfaatkan kemampuan writev di Linux. Alih-alih menyalin dan menggabungkan beberapa potongan data paket sebelum menyerahkannya ke kernel, klien Tailscale bisa menyerahkan beberapa potongan sekaligus dalam satu operasi. Huruf v pada writev berarti vector: klien cukup mendeskripsikan potongan data yang perlu dipindahkan, tanpa benar-benar memindahkannya lebih dulu.
Konsekuensinya adalah lebih sedikit salinan data paket di memori, lebih sedikit operasi tulis, dan throughput yang lebih tinggi. Perlu dicatat, keuntungan ini untuk sementara hanya tersedia di Linux dan, bila berlaku, Android.
Netmap caching untuk startup yang lebih cepat
Bagian ini menyentuh masalah yang berbeda: bukan throughput, melainkan waktu yang dibutuhkan perangkat untuk mulai bisa berkomunikasi. Saat sebuah mesin terhubung ke Tailscale, ia biasanya menghubungi control plane lebih dulu, sekitar 100 milidetik pada jaringan yang normal. Mesin melakukan autentikasi lalu menerima network map yang menjelaskan perangkat mana saja yang bisa dijangkau dan bagaimana caranya.
Pada koneksi bagus, proses ini terasa instan. Masalahnya muncul pada jaringan buruk, misalnya Wi-Fi pesawat atau jaringan hotel yang memfilter ketat. Waktu untuk mencapai control plane bisa panjang, dan kadang tidak tercapai sama sekali. Efeknya, perangkat tidak bisa menjangkau perangkat lain, dan sering tidak jelas di mana masalahnya. Bahkan pada kondisi ideal, 100 milidetik bisa terlalu lama untuk beban kerja yang sensitif terhadap latensi.
Netmap caching menyelesaikan ini dengan menyimpan salinan network map di disk setiap perangkat. Saat perangkat menyala, ia bisa memakai salinan cache untuk membangun koneksi dengan perangkat lain di tailnet, sampai akhirnya berhasil menghubungi control plane untuk memperbarui informasi. Koneksi tetap dinegosiasikan langsung antar perangkat, dan Tailscale tetap tidak melihat isi trafiknya.
Menurut Claus Lensbøl, anggota staf teknis Tailscale, kondisi jaringan buruk adalah ruang di mana netmap caching memberi manfaat paling besar: perangkat bisa mulai bekerja lebih dulu sambil menunggu control plane tercapai. Untuk tailnet dengan keterjangkauan control plane yang buruk, Tailscale melaporkan startup dengan cache hangat mengirim data melalui data plane satu sampai dua orde besaran lebih cepat dibanding startup dingin.
Ada batasannya, dan Tailscale menyebutkannya terbuka. Caching hanya bekerja kalau perangkat pernah terhubung ke tailnet setidaknya sekali untuk mengambil network map. Perangkat juga butuh ruang disk yang persisten untuk menyimpan cache. Pada tailnet yang sangat besar, memperbarui cache bisa menghasilkan banyak trafik disk. Perangkat dengan penyimpanan lambat atau rentan aus seperti kartu SD mungkin lebih baik tidak mengaktifkannya.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬