Episode ini membahas karakteristik kinerja PPTP: pengaruh overhead enkapsulasi, biaya enkripsi MPPE berbasis RC4, pengukuran throughput dengan iperf3, pengukuran latency dan packet loss, serta perbandingan dengan OpenVPN dan WireGuard.

Ketika orang bertanya mengapa PPTP terasa lebih cepat, jawabannya sering disalahpahami. Episode 17 membahas kinerja PPTP secara teknis: apa yang membuatnya cepat, apa yang sebenarnya ia korbankan, dan bagaimana mengukurnya dengan benar.
Benchmark bukan sekadar angka — ia adalah dasar keputusan. Memahami pengukuran throughput, latency, dan packet loss membuat kalian bisa menilai apakah PPTP layak dipertahankan untuk beban kerja tertentu, atau justru jadi alasan tambahan untuk migrasi.
Dari sisi enkapsulasi, PPTP cukup ramping. Overhead PPP, GRE, dan header IP berkisar 50-80 byte — lebih kecil daripada L2TP/IPsec yang membungkus dua lapis enkapsulasi. Inilah salah satu alasan PPTP terasa responsif.
Enkripsi MPPE berbasis RC4 juga ringan secara komputasi dibandingkan cipher modern. Pada CPU kecil, RC4 lebih cepat daripada AES dengan hardware acceleration yang tidak tersedia. Tapi kecepatan ini membeli keamanan yang jauh di bawah standar.
Ada biaya yang tidak langsung terlihat di angka kecepatan. Tidak adanya integrity check membuat MPPE ringan, tapi juga menghilangkan verifikasi integritas. GRE yang stateless berarti tidak ada deteksi kongesti — semua tanggung jawab ada di TCP.
Performa PPTP menurun drastis pada kondisi tertentu: jaringan dengan packet loss tinggi (karena GRE stateless tidak memulihkan paket), jalur dengan MTU kecil yang tidak di-clamp, dan banyak sesi sekaligus di server dengan satu CPU. Pada kasus-kasus ini, PPTP tidak lagi terasa cepat.
Penting juga memperhitungkan CPU: RC4 memakai sedikit siklus, tapi enkripsi tetap berjalan di ruang pengguna pppd. Pada server yang juga menjalankan banyak layanan lain, bottleneck sering muncul di sisi enkripsi, bukan di jaringan.
Alat standar untuk mengukur throughput adalah iperf3. Jalankan server di sisi server PPTP, lalu klien di sisi tunnel:
iperf3 -siperf3 -c 192.168.1.10iperf3 -c 192.168.1.10 mengirimkan traffic melalui interface ppp0 dan melaporkan throughput. Bandingkan hasilnya dengan pengukuran langsung tanpa tunnel untuk mengetahui berapa besar overhead yang hilang.
Perhatikan bahwa hasil iperf3 berbeda tergantung arah. Untuk gambaran utuh, ukur keduanya: upload dan download. Kalian juga bisa memakai mode -R di client untuk membalik arah secara otomatis.
iperf3 -c 192.168.1.10 -Riperf3 -c 192.168.1.10 -R menjalankan pengujian terbalik sehingga hasil download juga terukur. Catat kedua angka untuk memahami asimetri jaringan.
Output iperf3 menampilkan throughput per interval dan rata-rata keseluruhan. Perhatikan baris SUM pada laporan interval untuk melihat gabungan transfer. Bandingkan tiga angka: tanpa tunnel, lewat tunnel tanpa MPPE, dan lewat tunnel dengan MPPE.
Selisih antara angka pertama dan terakhir adalah biaya sesungguhnya yang harus dipertanggungjawabkan PPTP. Jika selisihnya kecil, overhead enkripsi bukan masalah besar; jika besar, pertimbangkan apakah hardware server masih memadai untuk kebutuhan.
Latency diukur dengan ping melalui interface tunnel:
ping -c 20 -i 0.2 192.168.1.10ping -c 20 -i 0.2 192.168.1.10 mengirim 20 paket setiap 200 milidetik. Perhatikan nilai rata-rata dan jitter. Tunnel PPTP menambah latensi karena lapisan enkapsulasi, tapi biasanya dalam kisaran milidetik pada jaringan yang sehat.
Perhatikan baris packet loss di output ping. GRE yang stateless berarti paket yang hilang di tunnel tidak dipulihkan pada lapisan ini — TCP akan mengatasinya lewat retransmission, tapi UDP real-time akan terasa dampaknya.
Selain rata-rata latency, perhatikan jitter — variasi antar pengukuran. Jitter yang tinggi mengindikasikan antrian atau buffering di jalur, dan sangat berpengaruh pada aplikasi real-time seperti VoIP dan video conference.
Tunnel PPTP di atas koneksi yang sudah tinggi jitter-nya akan memperburuk keadaan karena setiap paket ditambah overhead lapisan. Untuk beban kerja real-time, VPN dengan kontrol modern dan dukungan hardware offload biasanya menunjukkan angka yang lebih stabil.
Saat membandingkan PPTP dengan OpenVPN atau WireGuard, ingat dua hal. Pertama, PPTP bisa lebih cepat dalam throughput mentah pada perangkat keras tua, tapi itu karena keamanan yang jauh lebih lemah. Kedua, WireGuard dan OpenVPN dengan AES-NI di perangkat keras modern bisa mengejar bahkan melampaui PPTP sambil tetap aman.
Benchmark yang sehat mengukur lebih dari sekadar throughput: ia mengukur keamanan per byte yang ditransfer. Di metrik itu, PPTP kalah telak.
Selain itu, ukur konsistensi: jalankan benchmark beberapa kali dan perhatikan variasi antar percobaan. Angka yang melonjak-lonjak menandakan kondisi jaringan yang tidak stabil, dan membuat satu angka tunggal tidak bisa dipercaya sebagai dasar keputusan.
Catat juga kondisi lingkungan saat benchmark — waktu, beban server, dan versi firmware — supaya hasilnya bisa direproduksi. Benchmark yang tidak bisa direproduksi nilainya hampir sama dengan tebakan.
Episode 17 memisahkan mitos dari fakta soal kinerja PPTP: overhead yang kecil, enkripsi yang ringan tapi rapuh, serta cara mengukur throughput, latency, dan packet loss dengan iperf3 dan ping.
Inti yang harus dibawa pulang:
iperf3 -c mengukur throughput; gunakan -R untuk arah sebaliknya.Di episode 18 selanjutnya kita akan membahas integrasi sistem legacy — konfigurasi PPTP di Windows Server melalui RRAS, peran NPS untuk autentikasi, dukungan PPTP di perangkat Cisco dan Juniper, serta isu interoperabilitas antar vendor.