HTTP/2 Adalah: Cara Kerja, Kelebihan, dan Cara Ceknya

Membuka satu halaman website terlihat seperti satu perbuatan tunggal. Kenyataannya browser sedang mengambil puluhan berkas terpisah: dokumen HTML, berkas CSS, beberapa berkas JavaScript, font, dan gambar. Setiap berkas adalah satu permintaan tersendiri ke server.

Aturan yang mengatur percakapan itu bernama HTTP (HyperText Transfer Protocol). Versi yang dipakai hampir seluruh internet selama dua dekade, HTTP/1.1, punya satu batasan mendasar: dalam satu koneksi, permintaan harus diladeni bergiliran. Permintaan kedua menunggu permintaan pertama selesai. Ketika sebuah halaman membutuhkan delapan puluh berkas, giliran itu terasa.

HTTP/2 adalah jawaban resmi atas keterbatasan tersebut. Inti cara kerja HTTP/2 sederhana: alih-alih mengantre, browser dan server dibuat mampu menukar banyak berkas sekaligus di dalam satu koneksi yang sama.

HTTP/2 Adalah Versi Kedua Protokol Web

HTTP/2 adalah versi kedua protokol HTTP yang dirancang agar browser dan server dapat bertukar banyak berkas secara bersamaan melalui satu koneksi. Namanya kerap disingkat h2, dan sesekali ditulis "HTTP 2.0" — penulisan lama yang tidak dipakai spesifikasinya.

Sejarah HTTP/2 berakar pada SPDY, protokol eksperimental buatan Google yang membuktikan pengiriman paralel dalam satu koneksi memang mempercepat pemuatan halaman. Gagasan itu dibakukan IETF menjadi RFC 7540 pada Mei 2015.

Dokumen itu kini sudah tidak berlaku. Sejak Juni 2022, HTTP/2 dibakukan ulang lewat RFC 9113, yang menggantikan RFC 7540 sekaligus mencabut beberapa bagiannya. Rujukan yang sah untuk HTTP/2 hari ini adalah RFC 9113.

Soal pemakaiannya, W3Techs mencatat pada September 2026 bahwa 34,6% website memakai HTTP/2 dan 40,3% memakai HTTP/3. Kedua angka itu tumpang tindih karena satu situs bisa melayani keduanya, jadi tidak boleh dijumlahkan.

Kemacetan HTTP/1.1 yang Melatarbelakangi Kelahirannya

Satu koneksi HTTP/1.1 hanya sanggup menangani satu permintaan pada satu waktu. Respons harus dikirim utuh sebelum permintaan berikutnya boleh berjalan, sehingga berkas yang berat menahan seluruh antrean di belakangnya.

Browser menyiasatinya dengan membuka beberapa koneksi sekaligus. Menurut MDN, jumlah lazimnya kini enam koneksi paralel per domain, naik dari dua sampai tiga di masa awal. Enam berkas sekaligus lebih baik daripada satu, tetapi jauh dari cukup untuk halaman modern.

Karena batas itu, muncul sejumlah siasat yang dulu dianggap praktik terbaik:

1. Domain sharding: berkas disebar ke beberapa subdomain (img1, img2) supaya browser membuka lebih banyak koneksi.
2. Penggabungan berkas: puluhan berkas CSS dan JavaScript disatukan agar jumlah permintaan berkurang.
3. Sprite gambar: banyak ikon kecil ditempel jadi satu gambar, lalu dipotong kembali lewat CSS.

Ketiganya lahir bukan karena elegan, melainkan karena protokolnya sempit. MDN sendiri kini menandai domain sharding sebagai teknik usang dan menyarankan pindah ke HTTP/2, bahkan menyebutnya justru merugikan performa.

HTTP/1.1 memakai enam koneksi yang tiap lajurnya antre empat permintaan; HTTP/2 satu koneksi dan selesai lebih awal.

Empat Perubahan Inti di Balik HTTP/2

HTTP/2 tidak menambal HTTP/1.1, melainkan mengganti cara pesan dibungkus di kabel. Empat perubahan berikut yang menopang seluruh kelebihan HTTP/2.

1. Format biner menggantikan teks. HTTP/1.1 mengirim header sebagai teks yang bisa dibaca manusia. HTTP/2 memecah semuanya menjadi frame (potongan data berukuran tetap dengan penanda jenis). Mesin memprosesnya lebih cepat dan lebih sedikit salah tafsir, meski lalu lintasnya tidak bisa lagi dibaca lewat telnet biasa.
2. Multiplexing dalam satu koneksi. Setiap permintaan berjalan di stream sendiri, dan puluhan stream hidup bersamaan di satu koneksi. Frame dari stream berbeda boleh berselang-seling di kabel lalu disusun kembali di ujung penerima. Inilah yang menghapus antrean HTTP/1.1 dan membuat domain sharding tidak lagi relevan.
3. Kompresi header dengan HPACK. Setiap permintaan membawa header yang isinya nyaris sama: User-Agent, Accept, cookie, dan seterusnya. Pada halaman dengan delapan puluh permintaan, teks yang sama dikirim delapan puluh kali. HPACK, dibakukan di RFC 7541, menyimpan header yang pernah dikirim di sebuah tabel lalu cukup mengirim nomor rujukannya.
4. Kontrol aliran per stream. Penerima dapat memberi tahu pengirim seberapa banyak data yang sanggup ia tampung, per stream maupun untuk seluruh koneksi. Satu unduhan besar karenanya tidak menenggelamkan permintaan kecil yang berjalan di sebelahnya.

Anatomi HTTP/2: satu koneksi TCP memuat Stream 1, 3, dan 5 berisi frame HEADERS dan DATA, plus tabel indeks HPACK.

RFC 7540 sebenarnya juga mendefinisikan skema prioritas berbasis pohon ketergantungan antar-stream. Skema itu dicabut di RFC 9113. Alasannya, penandaan prioritas versi lama tidak berhasil karena terlalu rumit dan diterapkan berbeda-beda oleh tiap klien dan server. Penggantinya jauh lebih sederhana, berupa header tersendiri.

Yang Justru Tidak Ikut Berubah

HTTP/2 mengubah cara pesan dibungkus, bukan isi pesannya.

Method GET dan POST tetap sama. Status 200, 301, dan 404 tetap sama. Nama header, cookie, aturan caching, dan bentuk URL tetap sama persis. Permintaan HTTP/1.1 dan HTTP/2 yang setara membawa informasi identik; yang berbeda hanya pengemasannya di kabel.

Konsekuensi praktisnya melegakan. Kode aplikasi Anda tidak perlu disentuh, aturan redirect di .htaccess tetap berjalan, dan klien REST API yang Anda tulis tidak perlu diubah satu baris pun. Mengaktifkan HTTP/2 adalah pekerjaan di sisi server, bukan proyek migrasi aplikasi.

Karena semantiknya tidak berubah, mengaktifkan HTTP/2 tidak memperbaiki masalah yang berakar di tempat lain. Query database yang lambat, gambar yang tidak dikompresi, dan kode yang berat tetap lambat di protokol mana pun.

Server Push: Fitur Andalan yang Sudah Dicabut

Server Push adalah fitur yang membolehkan server mengirim berkas yang belum diminta. Misalnya menyodorkan berkas CSS bersamaan dengan HTML, dengan harapan browser tidak perlu meminta terpisah.

Fitur ini sudah berhenti dipakai. Google mematikannya secara bawaan sejak Chrome 106 pada 2022, dan browser berbasis Chromium lain mengikuti. Alasannya dipaparkan terbuka: hanya 1,25% situs HTTP/2 yang memakainya, dan ketika analisis diulang angkanya turun ke 0,7%. Pengukuran Chrome maupun Akamai tidak menemukan keuntungan performa yang jelas, dan sering menemukan penurunan. Penyebabnya, server kerap mengirim berkas yang sudah ada di cache browser sehingga bandwidth terbuang.

Penggantinya ada dua, dan keduanya lebih aman:

1. 103 Early Hints: server mengirim petunjuk lebih dulu tentang berkas yang mungkin dibutuhkan, lalu browser yang memutuskan mengambilnya atau tidak.
2. rel=preload: halaman menandai sendiri berkas kritis agar browser mengambilnya lebih awal.

RFC 9113 masih mendefinisikan Server Push, tetapi tanpa browser yang memakainya fitur itu tidak lagi berguna dipasang. Usaha yang sama lebih berhasil bila dialihkan ke kompresi gambar dan caching.

HTTP/1.1, HTTP/2, dan HTTP/3 Hidup Berdampingan

Ketiga versi ini tidak saling menggantikan seperti versi aplikasi. Ketiganya aktif bersamaan, dan browser memilih yang tertinggi yang didukung server. Pemilihannya terjadi di dalam handshake TLS lewat ALPN (Application-Layer Protocol Negotiation), sebuah perundingan singkat sebelum data pertama dikirim.

Ringkasan perbedaan HTTP/1.1, HTTP/2, dan HTTP/3 ada di tabel berikut.

Soal enkripsi perlu ditegaskan. Spesifikasinya mengizinkan mode tanpa enkripsi bernama h2c, tetapi tidak ada browser arus utama yang menerapkannya. RFC 9113 bahkan mencabut mekanisme upgrade ke h2c karena tidak pernah tersebar luas. Praktisnya, HTTP/2 di browser berarti HTTPS, dan itu berarti Anda membutuhkan sertifikat SSL yang aktif lebih dulu.

Kapan HTTP/2 Tidak Membantu, dan Kapan Justru Merugikan

Keunggulan HTTP/2 nyata, tetapi bersyarat. Empat hal berikut adalah kekurangan HTTP/2 yang perlu Anda pertimbangkan sebelum mengejarnya.

Antrean tidak hilang, hanya pindah lapisan. HTTP/2 menghapus antrean di tingkat permintaan, tetapi semuanya masih berjalan di atas satu koneksi TCP. Ketika satu paket TCP hilang, seluruh stream di koneksi itu berhenti menunggu paket tersebut dikirim ulang — meskipun data yang mereka butuhkan sudah tiba. Gejala ini disebut head-of-line blocking, dan di HTTP/2 ia berpindah dari lapisan HTTP ke lapisan TCP.

Satu paket hilang menahan seluruh stream di HTTP/2, sedangkan di HTTP/3 hanya stream yang terdampak yang berhenti.

Di jaringan yang buruk, HTTP/1.1 bisa menang. Satu koneksi TCP berarti satu jendela kongesti. Ketika paket hilang, jendela itu dipangkas dan seluruh halaman melambat sekaligus. HTTP/1.1 dengan enam koneksi lebih tahan karena kegagalan satu koneksi tidak menyeret lima lainnya. Penelitian Goel dan rekan (2017) pada jaringan seluler ber-packet loss menemukan HTTP/2 unggul untuk halaman berisi objek kecil, tetapi memburuk untuk objek besar. Mengingat mayoritas pengunjung di Indonesia datang dari perangkat seluler, catatan ini bukan hal teoretis.

Situs kecil nyaris tidak merasakan bedanya. Halaman dengan sepuluh berkas tidak pernah benar-benar mengantre di HTTP/1.1. Google bahkan menyatakan Googlebot tetap merayapi situs berlalu lintas sangat rendah lewat HTTP/1.1 karena tidak ada penghematan berarti.

Penggabungan berkas belum sepenuhnya usang. Anjuran menghentikan penggabungan CSS dan JavaScript begitu HTTP/2 aktif terlalu jauh. Kompresi bekerja lebih baik pada satu berkas besar dibanding banyak berkas kecil, dan setiap berkas tetap membawa biaya pemrosesan tersendiri di browser. Yang layak ditinggalkan adalah domain sharding dan sprite gambar.

Rapid Reset: Ketika Fitur Inti HTTP/2 Dijadikan Senjata

Pada Agustus 2023, multiplexing yang menjadi keunggulan HTTP/2 dipakai untuk serangan DDoS terbesar yang pernah tercatat. Kerentanannya terdaftar sebagai CVE-2023-44487 dan dikenal dengan nama HTTP/2 Rapid Reset.

Cara kerjanya memanfaatkan aturan yang wajar. Server membatasi jumlah stream yang boleh terbuka bersamaan, dan hanya stream terbuka atau setengah tertutup yang dihitung terhadap batas itu. Penyerang membuka stream lalu langsung membatalkannya dengan frame RST_STREAM, sehingga slot bebas seketika untuk stream baru. Server sudah lebih dulu mulai memproses permintaan tersebut, sementara penyerang tidak perlu menunggu apa pun.

Rapid Reset HTTP/2: stream dibuka, server memproses, lalu dibatalkan RST_STREAM berulang; puncak 201 juta request/detik.

Skalanya mengejutkan. Cloudflare mencatat puncak 201 juta permintaan per detik dari botnet yang hanya berisi sekitar 20.000 mesin. Google mencatat puncak 398 juta permintaan per detik — dalam dua menit, serangan itu menghasilkan lebih banyak permintaan daripada seluruh tampilan artikel Wikipedia sepanjang September 2023. Sebagai pembanding, rekor tahun sebelumnya berada di 46 juta permintaan per detik.

Bagi pemilik website biasa, tindak lanjutnya sederhana dan tidak berarti HTTP/2 harus dihindari. Pastikan software web server Anda diperbarui, karena Nginx, Apache, dan hampir semua implementasi lain sudah merilis tambalannya sejak Oktober 2023. Bila situs Anda berada di belakang CDN Cloudflare atau layanan sejenis, mitigasinya sudah berjalan di sisi mereka.

Cara Memeriksa Website Anda Sudah HTTP/2 atau Belum

Ada tiga cara yang bisa Anda lakukan sendiri dalam hitungan detik. Yang paling ringkas memakai curl, meminta HTTP/2 lalu mencetak versi yang benar-benar dipakai:

curl -sS --http2 -o /dev/null \
  -w 'HTTP/%{http_version}\n' \
  https://www.indowebsite.co.id/

Keluarannya satu baris. Pada pengujian 3 September 2026, alamat di atas menjawab:

HTTP/2

Sebagai pembanding, dengan perintah yang sama https://nginx.org/ — situs resmi Nginx sendiri — masih menjawab HTTP/1.1. Perlu diperhatikan bahwa penanda %{http_version} mengembalikan 2, bukan 2.0.

Cara kedua memeriksa hasil perundingan ALPN. Server yang menyanggupi HTTP/2 menyebut h2 di dalam handshake:

echo | openssl s_client -alpn h2 \
  -connect www.google.com:443 \
  -servername www.google.com 2>/dev/null \
  | grep -i ALPN

Balasannya berupa ALPN protocol: h2. Bila tidak mendukung HTTP/2, baris itu tidak muncul atau menyebut http/1.1.

Cara ketiga tidak membutuhkan terminal. Buka Developer Tools di browser, masuk ke tab Network, klik kanan pada baris judul tabel, lalu aktifkan kolom Protocol. Kolom itu menampilkan h2, h3, atau http/1.1 untuk setiap berkas yang dimuat. Berkas dari domain pihak ketiga bisa memakai versi berbeda dari domain Anda sendiri.

Cara Mengaktifkan HTTP/2 di Server Anda

Langkahnya bergantung pada software yang Anda pakai. Prasyaratnya sama untuk semua: HTTPS harus sudah aktif lebih dulu.

Langkah #1: Nginx

Sejak versi 1.25.1 yang dirilis 13 Juni 2023, Nginx memakai direktif tersendiri dan nilai bawaannya nonaktif. Tambahkan satu baris di dalam blok server:

server {
    listen 443 ssl;
    http2 on;
    server_name contoh.com;
}

Cara lama menuliskannya sebagai parameter listen 443 ssl http2; masih berjalan, tetapi sudah ditandai deprecated di rilis yang sama. Konfigurasi Nginx yang masih memakai bentuk lama sebaiknya diperbarui selagi belum dicabut.

Langkah #2: Apache

Apache menyediakan mod_http2 sejak versi 2.4.17. Aktifkan modulnya, lalu daftarkan protokol yang ingin dilayani:

Protocols h2 http/1.1

Menuliskan h2 lebih dulu berarti HTTP/2 diprioritaskan bila klien menyanggupinya. Kalau Anda ingin melayani mode tanpa enkripsi, daftarnya menjadi Protocols h2 h2c http/1.1. Seperti dijelaskan sebelumnya, tidak ada browser yang memakai h2c.

Langkah #3: LiteSpeed, OpenLiteSpeed, dan Cloudflare

LiteSpeed dan OpenLiteSpeed menyalakan HTTP/2 secara bawaan pada koneksi HTTPS, sehingga umumnya tidak ada yang perlu diubah. Cloudflare pun demikian: dokumentasinya menyatakan HTTP/2 aktif bawaan di seluruh paket termasuk paket gratis, dengan syarat sertifikatnya sudah aktif di jaringan tepi mereka. Menaruh situs di belakang Cloudflare karenanya jalan tercepat mendapatkan HTTP/2 tanpa menyentuh konfigurasi server.

Langkah #4: Kalau Anda Berada di Shared Hosting

Pada layanan web hosting bersama, konfigurasi web server dipegang penyedia dan tidak bisa diubah dari cPanel. Yang bisa Anda lakukan ada tiga. Pastikan sertifikatnya sudah terpasang dan situs diakses lewat HTTPS, jalankan perintah curl di atas, lalu tanyakan ke penyedia bila hasilnya masih HTTP/1.1.

HTTP/2 dan SEO: Apa yang Benar-Benar Dikatakan Google

HTTP/2 tidak menaikkan peringkat di Google, dan pernyataan itu datang dari Google sendiri.

Google mengumumkan pada 17 September 2020 bahwa Googlebot mulai merayapi sebagian situs lewat HTTP/2 pada pertengahan November 2020. Alasannya efisiensi perayapan, bukan penilaian kualitas. Dalam pengumuman yang sama Google menyatakan tidak ada kerugian bila situs tetap memakai HTTP/1.1. Perayapan berjalan sama saja, baik dari sisi kualitas maupun kuantitas.

Beberapa hal lain dari pengumuman itu layak Anda ketahui:

1. Anda tidak bisa memintanya. Googlebot sendiri yang memutuskan situs mana yang dirayapi lewat HTTP/2, berdasarkan ada tidaknya penghematan nyata bagi kedua pihak.
2. Googlebot menolak h2c. Situs wajib memakai HTTPS dan mendukung HTTP/2 agar memenuhi syarat, persis seperti browser modern.
3. Ada jalan keluar, dan ada pemberitahuan. Situs yang menolak perayapan lewat HTTP/2 dapat menjawab dengan status 421. Sebaliknya, pemilik situs di Search Console menerima pemberitahuan saat situsnya memenuhi syarat, dan jejaknya terlihat di log akses server.

Hubungan HTTP/2 dengan SEO karenanya tidak langsung. Yang berpengaruh adalah kecepatan halaman yang dirasakan pengunjung, dan HTTP/2 hanya satu dari sekian faktor yang memengaruhinya.

Pertanyaan yang Sering Muncul Seputar HTTP/2

Apakah HTTP/2 wajib memakai HTTPS?

Menurut spesifikasinya tidak, karena tersedia mode tanpa enkripsi bernama h2c. Namun tidak ada browser arus utama yang menerapkan mode itu, dan Googlebot pun menolaknya. Secara praktis jawabannya wajib.

Berapa peningkatan kecepatan yang bisa diharapkan dari HTTP/2?

Tidak ada angka tunggal yang jujur. Peningkatan terbesar terjadi pada halaman dengan banyak berkas kecil dan koneksi berlatensi tinggi. Pada halaman ringan berisi sepuluh berkas, selisihnya bisa saja tidak terukur.

Sudah ada HTTP/3, apakah HTTP/2 masih perlu?

Masih. HTTP/3 berjalan di atas QUIC yang memakai UDP, dan sebagian jaringan perusahaan memblokir UDP. Ketika itu terjadi, browser turun ke HTTP/2. Keduanya sebaiknya aktif bersamaan, bukan dipilih salah satu.

Apa arti pesan error yang menyebut HTTP/2?

Pesan seperti stream was not closed cleanly menandakan koneksi terputus di tengah pengiriman stream. Penyebab umumnya masalah jaringan, batas waktu di server, atau perantara seperti proxy yang menangani HTTP/2 dengan tidak sempurna. Menonaktifkan HTTP/2 sementara adalah cara cepat memastikan penyebabnya memang di lapisan itu.

Apakah mengaktifkan HTTP/2 bisa merusak website saya?

Risikonya kecil karena semantik HTTP tidak berubah. Yang perlu diperhatikan adalah perantara lama seperti load balancer atau proxy yang belum mendukungnya. Uji di lingkungan staging bila situs Anda melewati banyak lapisan perantara.

Kesimpulan

HTTP/2 adalah versi kedua protokol web yang menghapus antrean permintaan dengan mengalirkan banyak stream sekaligus di dalam satu koneksi, ditopang format biner dan kompresi header HPACK. Ia mengubah pengemasan pesan, bukan artinya, sehingga aplikasi Anda tidak perlu disentuh. Dua hal membedakan keadaannya hari ini dari saat protokol ini diperkenalkan: Server Push sudah dicabut browser sejak 2022, dan rujukan spesifikasinya kini RFC 9113, bukan RFC 7540.

Mengaktifkannya layak dilakukan untuk situs yang memuat banyak berkas dan melayani pengunjung dari jarak jauh. Pada praktiknya cukup memastikan HTTPS aktif lalu menyalakan satu direktif di web server. Untuk situs kecil berisi sepuluh berkas, keuntungannya tipis dan sebaiknya Anda mendahulukan kompresi gambar serta caching. Mulailah dengan menjalankan satu perintah curl di atas — sangat mungkin server Anda sudah melayaninya tanpa Anda sadari.

Semoga artikel ini membantu.