Evolusi HTTP: dari 1.1 ke HTTP/2 dan HTTP/3

Jalan satu lajur vs jalan tol

Bayangkan jalan desa satu lajur: mobil harus antre satu per satu, kalau satu mogok semua berhenti. Itulah HTTP/1.1: satu koneksi hanya bisa menangani satu request dalam satu waktu (atau beberapa dengan trik yang boros). HTTP/2 seperti jalan tol multilajur: banyak request melaju bersamaan dalam satu koneksi. HTTP/3 membangun ulang fondasinya agar tahan terhadap kemacetan jaringan modern.

Kenapa evolusi ini perlu

Website modern memuat puluhan sampai ratusan file: HTML, CSS, JS, gambar, font. Dengan HTTP/1.1, browser harus membuka banyak koneksi paralel (biasanya 6 per domain) dan setiap request membawa header lengkap yang berulang-ulang. Hasilnya lambat, apalagi di jaringan HP yang tidak stabil. Setiap generasi baru HTTP dirancang untuk satu tujuan: memuat web lebih cepat dengan koneksi lebih sedikit.

Contoh 1: multiplexing di HTTP/2

Di HTTP/1.1, meminta 3 file berarti antre:

GET /style.css ... (tunggu selesai)
GET /app.js    ... (tunggu selesai)
GET /logo.png  ... (tunggu selesai)

Di HTTP/2, ketiganya dikirim bersamaan dalam satu koneksi lewat stream yang diberi nomor. Response bisa datang tidak berurutan dan dirakit kembali oleh browser. Satu koneksi cukup untuk seluruh halaman. Bonus: header dikompresi dengan HPACK, jadi request berulang jauh lebih ramping.

Contoh 2: QUIC di HTTP/3

HTTP/2 masih berjalan di atas TCP. Masalahnya, kalau satu paket TCP hilang, SEMUA stream harus menunggu (head-of-line blocking di level TCP). HTTP/3 mengganti TCP dengan QUIC (berbasis UDP): setiap stream independen, paket hilang di satu stream tidak menghambat stream lain. Perpindahan jaringan (misalnya WiFi ke data seluler) juga tidak memutus koneksi karena QUIC memakai connection ID, bukan alamat IP.

Melihat versinya di DevTools: tab Network, klik kanan header kolom, aktifkan Protocol. Kamu akan melihat h1, h2, atau h3.

Kesalahan umum

Salah: mengira harus setting manual untuk pakai HTTP/2. Tidak. Ini urusan server dan browser yang bernegosiasi otomatis. Yang benar: sebagai developer, pastikan hosting/CDN-mu mendukung HTTP/2 atau HTTP/3.

Salah: tetap melakukan trik optimasi era HTTP/1.1. Spriting gambar dan menggabung semua JS jadi satu file dulu penting untuk mengurangi request; di HTTP/2 manfaatnya kecil. Yang benar: fokus ke ukuran total dan caching, bukan jumlah request semata.

Salah: mengira HTTP/3 selalu lebih cepat. Di jaringan kabel yang stabil, bedanya tipis. Keunggulan HTTP/3 terasa di jaringan tidak stabil (mobile). Yang benar: biarkan server memilih versi terbaik otomatis.

Catatan teknis: gRPC (dibahas di modul tersendiri) dibangun di atas HTTP/2 dan memanfaatkan multiplexing serta kompresi header-nya. Memahami evolusi ini membantumu mengerti kenapa teknologi modern memilih fondasi tertentu.