Belajar Curl - Modern Protocols: HTTP/2, HTTP/3 & WebSocket
Pada episode ini kita akan menaikkan protokol dari HTTP/1.1 ke HTTP/2 dan HTTP/3 berbasis QUIC, memahami multiplexing dan perilaku fallback, lalu menjelajahi komunikasi dua arah WebSocket dengan client WS di curl.
#Pendahuluan
Selama ini curl berbicara dengan server lewat HTTP/1.1 — protokol yang usianya sudah tiga dekade dan didesain sebelum web menjadi sekompleks sekarang. Di episode 14 ini kalian akan menaikkan gigi: HTTP/2 yang membuat banyak request berbagi satu koneksi, HTTP/3 yang terbang di atas UDP dengan latensi lebih rendah, dan WebSocket yang mengubah curl dari pemanggil satu arah menjadi peserta percakapan dua arah. Tidak ada yang harus dipelajari ulang — sintaks URL dan header tetap sama. Yang berubah adalah cara data mengalir di dalamnya.
#Keterbatasan HTTP/1.1
HTTP/1.1 punya satu kelemahan struktural: satu koneksi TCP melayani satu request dalam satu waktu. Setiap request menunggu responsnya selesai sebelum request berikutnya berangkat — yang disebut head-of-line blocking. Browser mengakali ini dengan membuka banyak koneksi paralel (sampai 6 per host), dan curl menirunya secara default. Tapi itu hanya tempelan: koneksi ekstra berarti handshake ekstra, dan tidak menyelesaikan antrean di dalam satu koneksi.
Bayangkan sebuah restoran dengan satu pelayan per meja yang hanya bisa membawa satu piring dalam satu perjalanan. Solusi HTTP/1.1 adalah menambah pelayan; solusi HTTP/2 adalah mengganti pelayan itu dengan yang bisa membawa satu troli penuh sekaligus.
#HTTP/2: --http2
HTTP/2 memecahkan masalah di atas dengan multiplexing: satu koneksi TCP menampung banyak stream sekaligus, dan setiap stream bisa membawa request-responsnya sendiri secara paralel. Satu paket yang lambat tidak lagi menghambat yang lain dalam aliran yang berbeda.
Sejak curl 8.x, HTTP/2 sudah menjadi default untuk koneksi HTTPS — tidak perlu flag apa pun. Tapi untuk menegaskannya, atau memakai di lingkungan yang konfigurasinya ambigu, gunakan --http2:
curl --http2 https://api.example.com/healthBagaimana kalian tahu request benar-benar memakai HTTP/2? Cek dengan -v — baris yang berawalan * akan menunjukkan hasil negosiasi:
* ALPN: offers h2,http/1.1
* ALPN: server accepted h2
> GET /health HTTP/2
> Host: api.example.comALPN: server accepted h2 dan baris request yang mencantumkan HTTP/2 adalah bukti bahwa negosiasi protokol (yang kalian lihat di episode 12) memilih HTTP/2. Jika server tidak mendukung HTTP/2, curl jatuh ke HTTP/1.1 secara mulus — tidak ada yang gagal, hanya lebih lambat.
Tip
Untuk memaksa protokol demi pengujian, kalian bisa mengunci: curl --http2 https://... memakai HTTP/2 dan menolak downgrade, sedangkan curl --http1.1 https://... memaksa kembali ke HTTP/1.1. Kemampuan membandingkan keduanya berguna saat men-debug perilaku yang bergantung versi protokol.
#HTTP/3 dan QUIC: --http3
HTTP/3 adalah generasi berikutnya yang berjalan di atas QUIC — protokol transport yang dibangun di atas UDP, bukan TCP. Dua keunggulan utamanya:
- Tanpa head-of-line blocking antar stream — di HTTP/2, TCP masih bisa memblokir; satu paket hilang menahan seluruh koneksi. Di HTTP/3, setiap stream mandiri, jadi satu gangguan tidak menahan yang lain.
- Latensi koneksi lebih rendah — QUIC menggabungkan handshake transport dan TLS dalam satu perjalanan, dan mendukung 0-RTT untuk koneksi ulang.
curl --http3 https://example.comcurl --http3-only https://example.comPerhatikan perbedaan perilakunya: --http3 mencoba HTTP/3 lalu jatuh ke HTTP/2 atau HTTP/1.1 jika server tidak mendukungnya — pilihan paling bijak untuk produksi. Sedangkan --http3-only memaksa dan gagal jika server buta HTTP/3 — berguna hanya untuk menguji bahwa server benar-benar mendukungnya.
curl -v --http3 https://example.com 2>&1 | grep -i "QUIC\|HTTP/3"Dukungan HTTP/3 butuh build curl yang menyertakan fitur HTTP3 — periksa dengan curl --version. Server di balik CDN modern (Cloudflare, Fastly, dan sejenisnya) umumnya sudah siap. Jika kalian ingin melihat bedanya dengan mata kepala sendiri, bandingkan timing --http3 melawan --http1.1 dengan -w dari episode 6 — pada koneksi yang sehat, HTTP/3 sering menang tipis di time_connect.
#WebSocket: --ws
Sejauh ini semua protokol bersifat request-response: satu permintaan, satu jawaban, koneksi selesai. WebSocket berbeda — ia membuka koneksi persisten dua arah setelah handshake awal, lalu kedua pihak bisa saling kirim pesan kapan saja tanpa menunggu giliran.
Cara kerjanya: request awal adalah HTTP biasa dengan header Upgrade: websocket. Kalau server setuju, koneksi di-upgrade dan percakapan frame-dimulai — pesan-pesan pendek yang saling bertukar secara real-time.
curl 8.x mendukung WebSocket dengan flag --ws:
curl --ws wss://stream.example.com/liveJalankan perintah itu dan kalian masuk mode interaktif: apa pun yang kalian ketik terkirim sebagai pesan, dan pesan masuk muncul di layar secara real-time sampai koneksi ditutup. Untuk pengujian terotomasi, kalian bisa menyuplai satu pesan lewat stdin — curl mengirimkannya, menampilkan balasan, lalu menutup koneksi:
echo '{"type": "ping"}' | curl --ws wss://stream.example.com/livePerhatikan skema URL-nya: ws:// untuk tanpa enkripsi dan wss:// untuk WebSocket di atas TLS — selalu pilih wss:// kecuali di lab lokal.
Warning
Dukungan WebSocket di curl masih berlabel eksperimental — pastikan curl --version menampilkan fitur websockets sebelum memakainya, dan uji di lingkungan non-produksi. Koneksi WebSocket juga persisten dan bisa berjalan lama, jadi pasang --max-time agar sesi debugging tidak menggantung.
#Kapan Memilih yang Mana
Tiga protokol ini bukan saingan — mereka melengkapi:
- HTTP/2 — default yang tepat untuk hampir semua request API; multiplexing membuat banyak request berbagi koneksi tanpa drama.
- HTTP/3 — nilai tambah terbesar untuk latensi dan koneksi tidak stabil (mobile, jaringan yang rawan paket hilang).
- WebSocket — pilihan untuk kebutuhan push real-time: notifikasi, streaming feed, chat, atau update harga — hal yang mustahil dilakukan dengan request-response biasa.
Aturan praktis yang sederhana: gunakan default (--http2 via ALPN) untuk pekerjaan normal, aktifkan --http3 saat server dan build mendukungnya, dan jangan sentuh --ws kecuali kalian benar-benar butuh dua arah. Memaksa protokol yang tidak diperlukan adalah optimasi prematur — dan memakai yang salah adalah latihan pemborosan.
#Penutup
Episode 14 menaikkan gigi protokol kalian: memahami keterbatasan HTTP/1.1 dan lahirnya HTTP/2 dengan multiplexing (--http2), beralih ke HTTP/3 berbasis QUIC dengan latensi lebih rendah (--http3 dengan fallback otomatis, --http3-only untuk menguji), memverifikasi negosiasi lewat -v, serta membuka percakapan dua arah dengan WebSocket (--ws) untuk pengujian real-time.
Inti yang perlu diingat: protokol modern adalah soal mengurangi waktu menunggu dan memungkinkan apa yang tadinya mustahil. HTTP/2 dan HTTP/3 mengecilkan overhead transfer; WebSocket membuka pintu ke aplikasi real-time. Semuanya tetap curl — URL yang sama, header yang sama, hanya alurnya yang berubah.
Di episode 15 berikutnya kita akan memanfaatkan semua kemampuan ini untuk satu tujuan: kecepatan — transfer paralel, multiplexing, kompresi, dan cara mengukur performa secara nyata. Sampai jumpa!