Tailscale Lebih Cepat: Multi-Queue, writev, dan Netmap Caching Dijelaskan

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.

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.

Kapan perbaikan ini tersedia

Jadwal yang disebutkan cukup spesifik dan berguna untuk perencanaan.

• Pengurangan memori lewat perubahan buffer untuk Linux dan Android diharapkan hadir pada klien versi 1.104.
• Multi-queue untuk subnet router dan app connector direncanakan pada rilis setelah 1.104.
• Peningkatan throughput untuk Linux dan Android sebagian sudah diterapkan pada musim semi 2026, dan tambahan keuntungan memori serta throughput direncanakan pada rilis setelah 1.104.
• Netmap caching tersedia sebagai feature flag di klien saat ini, dan diharapkan aktif secara bawaan pada 1.104 setelah pengujian lanjutan. Klien seluler menyusul pada rilis setelah 1.104.

Artinya, kalau Anda ingin menguji perbaikan ini sekarang, jalur yang paling cepat adalah mengaktifkan feature flag netmap caching pada klien Linux. Perbaikan lain perlu menunggu rilis berikutnya.

Alat ukur performa masih jadi celah

Bagian terakhir catatan itu jujur dan layak dihargai: Tailscale mengakui bahwa mengukur performa jaringan masih sulit, dan mereka tidak meminta pembaca percaya begitu saja. Mereka menyebut empat celah pada alat ukur yang ada sekarang.

• Pajak distribusi. Sebagian besar alat ukur performa bersifat titik ke titik dan mengharuskan pemasangan sesuatu di setiap endpoint.
• Alur kerja yang kaku. Sangat mudah menjalankan uji yang salah, mendapat keluaran yang menyesatkan, lalu mengejar masalah yang sebenarnya tidak ada.
• Dukungan protokol. Banyak alat belum mendukung protokol yang lebih baru seperti QUIC dan HTTP/3.
• Kesadaran Tailscale. Alat ukur umum tidak tahu apakah sebuah koneksi memakai relay atau langsung, apakah peer relay akan membantu, atau bagaimana jalur koneksi berubah sepanjang waktu.

Keempat celah itu menjelaskan kenapa diagnosis performa sering berakhir dengan tebakan. Untuk konteks perbandingan pada lapisan yang lebih rendah, ada juga catatan mengenai perubahan mekanisme pertukaran kunci TLS yang menunjukkan bahwa perbaikan handshake pun kini diukur dengan metrik yang lebih rinci.

Apa artinya untuk yang menjalankan self-hosting

Bagi yang memakai Tailscale untuk menghubungkan server rumah, NAS, atau perangkat edge, ada beberapa hal praktis yang bisa diambil dari catatan ini.

• Kalau ada subnet router atau exit node yang melayani banyak koneksi berumur pendek, peningkatan multi-queue adalah alasan kuat untuk memutakhirkan klien begitu tersedia.
• Kalau perangkat sering dipakai di jaringan buruk, misalnya laptop yang berpindah antar jaringan atau perangkat di lokasi dengan internet tidak stabil, netmap caching adalah fitur yang paling berdampak dan bisa diuji sekarang lewat feature flag.
• Kalau perangkat memakai kartu SD sebagai penyimpanan utama, pertimbangkan dampak ausnya sebelum mengaktifkan caching.
• Ukur sendiri sebelum dan sesudah memutakhirkan. Tanpa baseline, peningkatan performa hanya jadi klaim pemasok, bukan angka yang bisa dipertanggungjawabkan.

Untuk konteks pendekatan alternatif di dunia jaringan, ada juga catatan menarik soal implementasi ulang AppleTalk modern yang memperlihatkan bagaimana protokol lama dibangun kembali dengan arsitektur asinkron masa kini.

Kesimpulan

Catatan teknis Tailscale ini menjelaskan bahwa sebagian besar biaya performa pada jaringan mesh tidak datang dari kriptografi, melainkan dari hal-hal yang tampak sepele: ukuran buffer yang tidak cocok dengan ukuran paket, antrean yang terlalu panjang, pipeline yang hanya satu lajur, dan proses startup yang selalu menunggu control plane.

Yang bisa dipelajari dari sini berlaku lebih luas dari Tailscale. Sebelum memasang optimasi generik, ukur dulu di mana hambatannya. Pada kasus ini, hambatannya ternyata ada di penyalinan memori dan paralelisme, bukan di algoritma enkripsi. Pola berpikir yang sama berguna untuk sistem apa pun yang memindahkan data dalam jumlah besar.

Sumber

• Kabir Sikand dan Kevin Purdy, "We're making Tailscale faster", Tailscale Blog, 22 September 2026: https://tailscale.com/blog/making-tailscale-faster
• Diskusi publik atas tulisan tersebut di Hacker News, September 2026: https://news.ycombinator.com/item?id=44670000

Catatan: seluruh angka percepatan, jadwal rilis, dan kutipan dalam artikel ini bersumber dari tulisan resmi Tailscale tersebut dan belum diverifikasi lewat pengujian independen.