UDP tidak selalu lebih cepat: memilih transport OpenVPN

Setiap panduan mengatakan UDP mengalahkan TCP untuk OpenVPN, dan saran itu adalah default, bukan pengukuran. Transport mengubah cara paket dikirimkan dan apa yang terjadi ketika jalur menjatuhkannya, bukan cara terowongan dienkripsi. Di balik captive portal atau proxy yang hanya mengizinkan port 443, opsi yang lebih lambat adalah satu-satunya yang bisa terhubung. Uraian berikut memisahkan apa yang dilakukan protokol dari apa yang diizinkan jaringan akses Anda.

Apa yang sebenarnya diubah transport

TCP mengirimkan aliran byte yang andal dan berurutan serta mengirim ulang semua yang hilang, sebagaimana ditetapkan RFC 9293. UDP menyerahkan datagram ke jaringan, dan OpenVPN menjalankan lapisan keandalannya sendiri di atas soket itu. Enkapsulasi TCP di dalam TCP menumpuk dua putaran pemulihan, sehingga satu segmen yang hilang dapat menahan aliran dalam sampai pengiriman ulang luar tiba. Interaksi itulah argumen sebenarnya untuk UDP, dan muncul sebagai latensi, bukan sebagai throughput.

Efeknya bertambah seiring kehilangan paket dan waktu pulang-pergi. Pada jalur lokal yang bersih kedua transport terasa sama, karena itu uji di laboratorium jarang mereproduksi keluhan. Pada tautan seluler yang padat perbedaannya terlihat di sesi interaktif jauh sebelum transfer besar menyadari apa pun.

Tidak ada yang menyentuh kerahasiaan atau integritas. Jabat tangan TLS dan cipher kanal data sama untuk kedua transport, jadi beralih tidak dapat menyelamatkan rangkaian cipher yang lemah.

Di mana TCP mendapatkan tempatnya

Jaringan akses adalah alasan biasa memilih TCP. Hotel, bandara, atau jaringan tamu mungkin mengizinkan 443 keluar dan membuang semua yang lain, dan pendengar TCP pada port itu adalah satu-satunya profil yang berfungsi. Itu keterjangkauan, bukan kinerja, dan itu alasan yang cukup baik dengan sendirinya.

TCP juga membantu ketika jalur stabil tetapi perangkat tengah bermusuhan. Beberapa jaringan mengatur ulang aliran UDP berumur panjang sambil menoleransi sesi TCP yang mirip lalu lintas web biasa. Apakah kemiripan itu berhasil adalah sifat jaringan tertentu, dan tidak ada panduan yang bisa menjanjikannya untuk semua. Uji di dalam jaringan yang gagal sebelum menyalahkan protokol.

Login yang ditolak bukan masalah transport. Menonaktifkan verifikasi sertifikat untuk memaksa koneksi lewat adalah perubahan lain dengan hasil yang jauh lebih buruk.

Menyiapkan profil TCP adalah kompromi praktis. Sebagian besar klien menyimpan keduanya dan memungkinkan Anda beralih ketika jaringan menolak jalur UDP, yang tidak memakan biaya sampai Anda membutuhkannya. Yang tidak boleh Anda lakukan adalah mengirim dua profil yang menunjuk ke titik akhir berbeda, karena perbandingan Anda lalu mengukur servernya.

Periksa pendengar mana yang sebenarnya Anda miliki

Sebelum membandingkan kinerja, pastikan kedua ujung sepakat soal transport dan port. Mengubah proto udp menjadi proto tcp di berkas klien tidak membuat pendengar server. Server harus dikonfigurasi untuk protokol itu, dan profilnya harus cocok.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep mencetak apa yang diperintahkan ke server untuk digunakan, sedangkan dua daftar soket menunjukkan ke apa ia terikat. Pendengar UDP hanya muncul di daftar pertama dan pendengar TCP hanya di daftar kedua, jadi baris yang hilang adalah cara tercepat menemukan profil yang tidak pernah diterapkan. Bandingkan juga portnya, karena profil TCP pada 1194 berperilaku berbeda dari yang di 443 di sebagian besar jaringan akses. Mulai ulang layanan setelah perubahan dan baca baris log yang melaporkan pengikatan.

Konfirmasi di sisi klien murah: jalankan koneksi dengan --verb 4 dan baca baris transport di log. Jika klien menyebut UDP sementara server mendengarkan TCP, jabat tangan tidak pernah dimulai dan tidak ada penyetelan yang membantu.

Bandingkan beban kerja, bukan label transport

Perbandingan yang adil menjaga semuanya tetap konstan kecuali transport. Perangkat yang sama, jaringan akses yang sama, host tujuan yang sama, aplikasi yang sama, dan idealnya server yang sama. Jika kedua profil menunjuk ke host berbeda, Anda juga mengukur host tersebut.

Catat tiga hasil untuk setiap eksekusi: apakah terowongan terbentuk, apakah bertahan, dan apakah tugas selesai. Permintaan kecil yang berhasil sementara transfer besar macet menunjukkan ukuran paket dan MTU, bukan transport. Koneksi ulang berulang menunjukkan jalur atau waktu tunggu perangkat tengah.

Pertahankan profil yang berfungsi dalam kondisi yang benar-benar Anda temui, dan simpan yang lain. Pilihan itu milik jaringan, bukan orang, karena itu jawaban default tunggal selalu salah di suatu tempat.