HTTP/1.1, HTTP/2, dan HTTP/3: Bagaimana Web Jadi Makin Cepat

Setiap kali kamu membuka sebuah halaman web, browser dan server diam-diam saling mengobrol. Mereka memakai bahasa bersama bernama HTTP — kependekan dari HyperText Transfer Protocol. Bahasa ini berisi aturan main soal bagaimana sebuah permintaan (“tolong kirimkan halaman ini”) dan jawabannya (“ini halamannya”) berpindah melintasi internet.

Selama bertahun-tahun bahasa itu terus diperbarui, dan tiap pembaruan membuat web sedikit lebih cepat. Di artikel ini kita akan menelusuri tiga versi yang namanya bakal sering kamu dengar: HTTP/1.1, HTTP/2, dan HTTP/3. Kamu tidak perlu jadi insinyur jaringan untuk mengikutinya. Kita pakai bahasa sederhana, gambar yang gampang dibayangkan, dan satu dua perumpamaan sehari-hari. Di akhir nanti, kamu akan paham apa yang berubah, kenapa itu penting, dan kenapa situs favoritmu terasa lebih gesit dibanding sepuluh tahun lalu.

Sebenarnya HTTP itu kerjanya apa?

Bayangkan kamu mendekat ke meja kasir di sebuah toko. Kamu minta satu barang, pelayannya mengambilkannya ke gudang, lalu menyerahkannya ke kamu. Perjalanan bolak-balik itu — pertanyaanmu dan jawabannya — adalah satu pertukaran HTTP. Di dunia web, “kamu” adalah browser (sang klien) dan “pelayan” tadi adalah server.

Inilah bentuk paling sederhana dari obrolan tersebut:

Browser (klien)                  Server
      |                            |
      |  GET /index.html  ----->   |   "permintaan"
      |                            |
      |  <-----  200 OK + halaman  |   "jawaban"
      |                            |

Tapi halaman web modern tidak pernah cuma satu berkas. Ada dokumen HTML, ditambah gambar, font, lembar gaya (CSS), dan skrip (JavaScript). Satu halaman saja gampang butuh puluhan bahkan ratusan pengambilan kecil seperti ini. Nah, cara protokol menangani semua pengambilan itulah yang membedakan ketiga versi — dan di situ pula letak cerita soal kecepatan.

HTTP vs HTTPS

HTTPS sebenarnya HTTP yang diberi lapisan enkripsi di atasnya (lewat TLS), supaya tidak ada pihak di tengah jalan yang bisa membaca atau mengutak-atik lalu lintasnya. Nomor versi yang kita bahas di sini (1.1, 2, 3) berbicara tentang bagaimana permintaan diatur, bukan soal enkripsinya. Sekarang, koneksi yang aman sudah jadi standar di mana-mana.

HTTP/1.1: satu permintaan tiap giliran

HTTP/1.1 jadi tulang punggung web dalam waktu yang sangat lama, dan sebagian besar internet masih memakainya sampai sekarang. Idenya sederhana: buka satu koneksi antara browser dan server, lalu kirim sebuah permintaan dan tunggu jawabannya selesai sebelum mengirim permintaan berikutnya.

Anggap saja seperti satu jalur kasir di supermarket. Pembeli mengantre, dan kasir melayani benar-benar urut. Kalau orang paling depan bawa troli penuh yang lama sekali dipindai, semua yang di belakang cuma bisa menunggu — padahal mungkin mereka cuma beli satu barang.

Masalah menunggu ini ada namanya: head-of-line blocking, alias macet di kepala antrean. “Kepala antrean” adalah permintaan yang sedang ditangani saat ini, dan ia bisa menghambat semua yang mengantre di belakangnya.

HTTP/1.1 di satu koneksi (permintaan ditangani berurutan):

  [ permintaan A ] --> [ jawaban A ]
                       lalu...
  [ permintaan B ] --> [ jawaban B ]
                       lalu...
  [ permintaan C ] --> [ jawaban C ]

Browser menyiasatinya dengan membuka beberapa koneksi sekaligus ke server yang sama — mirip membuka beberapa jalur kasir, bukan cuma satu. Cara itu membantu, tapi tiap koneksi butuh waktu dan sumber daya untuk dibangun, dan ada batas praktis berapa banyak koneksi yang mau dibuka browser. Para pengembang juga menciptakan berbagai akal-akalan (menggabung banyak berkas kecil jadi satu berkas besar, menempel gambar-gambar kecil jadi satu “sprite”) demi mengurangi jumlah permintaan terpisah.

Siasat-siasat itu membuat web tetap jalan, tapi sejatinya cuma tambalan untuk keterbatasan yang lebih dalam. Protokolnya sendiri perlu dibikin lebih pintar.

HTTP/2: banyak obrolan dalam satu koneksi

HTTP/2 menghantam masalah macet-di-kepala-antrean lewat gagasan bernama multiplexing. Alih-alih satu permintaan menghambat permintaan berikutnya, banyak permintaan dan jawaban bisa berjalan bersamaan di satu koneksi yang sama. Tiap permintaan dipecah jadi potongan-potongan kecil (disebut frame) yang membawa label penanda milik permintaan mana, sehingga server dan browser bisa menyelang-nyeling lalu menyusunnya kembali dengan benar.

Kembali ke supermarket: ini seolah satu kasir bisa memindai barang dari beberapa troli sekaligus, berpindah-pindah di antaranya, bukan menyelesaikan satu troli dulu baru menyentuh yang lain.

HTTP/2 di SATU koneksi (diselang-seling):

  permintaan A -.                .- jawaban A
  permintaan B  >--- satu pipa --<  jawaban B
  permintaan C -'                '- jawaban C

  semua jalan barengan, tak ada yang antre

HTTP/2 membawa keuntungan kedua yang juga berarti: kompresi header. Tiap permintaan dan jawaban membawa header — serpihan kecil metadata seperti browser apa yang kamu pakai, jenis konten yang kamu terima, dan cookie. Informasi ini banyak berulang di antara sekian permintaan yang dibuat sebuah halaman. HTTP/2 memampatkannya, jadi data yang sama tidak dikirim ulang secara utuh berkali-kali. Makin sedikit data berulang, makin sedikit yang harus dikirim.

Untung yang datang gratis

Sebagian besar manfaat HTTP/2 muncul otomatis begitu server dan browser pengunjung sama-sama mendukungnya. Biasanya kamu tidak perlu mengubah kode aplikasi sama sekali — protokolnya yang mengatur lalu lintas jadi lebih efisien di balik layar.

Ada satu catatan yang perlu kamu tahu. HTTP/2 menyelesaikan macet-di-kepala-antrean di tingkat HTTP, tapi ia tetap berjalan di atas protokol lapisan bawah bernama TCP. TCP mengirim data benar-benar berurutan, jadi kalau satu paket hilang dan harus dikirim ulang, semua yang di belakangnya ikut menunggu paket itu — bahkan permintaan lain yang tidak ada hubungannya, asal berbagi koneksi yang sama. Macetnya pindah turun satu lapis, bukan benar-benar hilang. Persis masalah inilah yang ingin dibereskan versi berikutnya.

HTTP/3: fondasi baru bersama QUIC

HTTP/3 mempertahankan ide-ide bagus dari HTTP/2 — multiplexing, kompresi header — tapi membangun ulang fondasi di bawahnya. Alih-alih jalan di atas TCP, ia jalan di atas transport yang lebih baru bernama QUIC, yang dibangun di atas UDP.

Inti yang perlu kamu ingat: QUIC paham bahwa satu koneksi membawa beberapa aliran (stream) yang saling independen. Kalau satu aliran kehilangan paket, hanya aliran itu yang menunggu potongan yang hilang — aliran lainnya tetap mengalir. Kemacetan akibat paket hilang yang masih membandel di HTTP/2 pun lenyap.

QUIC juga membuat pembentukan koneksi lebih cepat. Membangun koneksi yang aman biasanya melibatkan jabat tangan (handshake) — beberapa pesan bolak-balik sebelum data sungguhan mulai mengalir. QUIC menyatukan pembentukan koneksi dan pembentukan enkripsi sekaligus, sehingga memangkas perjalanan bolak-balik itu. Di jaringan yang tiap perjalanan bolak-baliknya lambat (misalnya data seluler, atau server yang jauh), memangkas waktu setup ini terasa bedanya.

Pembentukan koneksi, kira-kira begini:

  Cara lama:   halo -> balas halo -> aman? -> ya -> BARU kirim data
  QUIC (HTTP/3): halo + aman sekaligus -> BARU kirim data  (lebih sedikit bolak-balik)

Satu lagi keuntungan praktis: karena QUIC menandai koneksi lewat sebuah ID, bukan lewat alamat jaringanmu yang persis, ia bisa bertahan lebih mulus saat jaringan berpindah. Kalau ponselmu loncat dari Wi-Fi ke data seluler di tengah unduhan, koneksinya punya peluang lebih besar untuk lanjut ketimbang mengulang dari awal.

Lebih baru bukan berarti otomatis di mana-mana

Dukungan HTTP/3 bergantung pada server dan jaringan pengunjung yang mengizinkan lalu lintas QUIC lewat UDP. Sebagian jaringan dan perangkat lama membatasi UDP, dan dalam kasus itu browser tinggal turun ke HTTP/2 atau HTTP/1.1. Penurunan versi ini normal dan sudah bawaan — situsmu tetap jalan, hanya saja memakai versi yang bisa disepakati kedua sisi.

Berdampingan: ketiga versi

Berikut keseluruhan ceritanya dalam satu tabel. Baca dari atas ke bawah untuk melihat bagaimana tiap masalah dibereskan oleh versi setelahnya.

Aspek	HTTP/1.1	HTTP/2	HTTP/3
Permintaan per koneksi	Satu per giliran (urut)	Banyak sekaligus (multiplexing)	Banyak sekaligus (multiplexing)
Head-of-line blocking	Ada, di tingkat permintaan	Berkurang, tapi TCP masih bisa menghambat aliran	Sebagian besar teratasi per aliran
Transport di bawahnya	TCP	TCP	QUIC (di atas UDP)
Penanganan header	Dikirim utuh tiap kali	Dimampatkan	Dimampatkan
Pembentukan koneksi	Beberapa kali bolak-balik	Beberapa kali bolak-balik	Lebih sedikit bolak-balik
Bertahan saat pindah jaringan	Koneksi putus	Koneksi putus	Bisa lanjut lebih mulus
Siasat tambahan yang dibutuhkan	Penggabungan berkas, banyak koneksi	Jauh lebih sedikit	Jauh lebih sedikit

Polanya jelas: tiap versi memindahkan lebih banyak kepintaran ke dalam protokol itu sendiri, jadi pengembang butuh lebih sedikit akal-akalan buatan tangan, dan halaman pun dimuat dengan lebih sedikit menunggu.

Kenapa ini penting untuk halaman sungguhan

Mungkin kamu bertanya, seberapa besar sih bedanya dalam keseharian? Lumayan besar, apalagi di halaman dengan banyak sumber daya atau di koneksi yang lambat.

Lebih sedikit kemacetan. Multiplexing membuat satu gambar yang lambat tidak lagi menahan lembar gaya atau skrip yang dibutuhkan halaman untuk mulai tampil.
Lebih sedikit data terbuang. Kompresi header memangkas beban berulang, yang jumlahnya menumpuk di halaman yang membuat banyak permintaan.
Mulai lebih cepat. Setup QUIC yang lebih singkat memperkecil jeda antara “pengguna mengeklik tautan” dan “byte pertama tiba”, yang paling terasa di koneksi seluler dan jarak jauh.
Lebih sedikit akal-akalan yang harus dirawat. Kebiasaan lama menjejalkan berkas jadi satu demi menghindari biaya per permintaan jadi tidak sepenting dulu, sehingga kode bisa tetap sederhana.

Bagi usaha seperti ACY Partner Indonesia yang menjalankan situs penuh konten, semua peningkatan ini berarti halaman terasa responsif bahkan ketika pengunjung memakai ponsel dengan sinyal seadanya. Kecepatan bukan sekadar pajangan — ia memengaruhi berapa lama orang bertahan dan apakah mereka mau kembali.

Kamu tidak memilih versi secara manual

Saat browser tersambung ke server, keduanya menegosiasikan versi terbaik yang sama-sama didukung, secara otomatis. Sebagai pemilik situs, kamu umumnya cukup mengaktifkan versi yang lebih baru di server (atau hosting/CDN yang melakukannya untukmu), sisanya berjalan di balik layar. Pengunjung tidak pernah memilih versi, begitu juga kode aplikasimu.

Rangkuman

Mari kita rangkai kembali benang merahnya. HTTP adalah bahasa yang dipakai browser dan server untuk bertukar permintaan dan jawaban, dan ia tumbuh dewasa lewat tiga langkah besar:

HTTP/1.1 mengirim satu permintaan per giliran di tiap koneksi, sehingga jawaban yang lambat bisa menghambat semua yang di belakangnya — itulah masalah head-of-line blocking. Pengembang menyiasatinya dengan banyak koneksi dan penggabungan berkas.
HTTP/2 memperkenalkan multiplexing (banyak permintaan berbagi satu koneksi tanpa mengantre) dan kompresi header, sehingga menghapus sebagian besar kemacetan dan data berulang. Tapi ia masih duduk di atas TCP, yang bisa menghambat aliran ketika ada paket hilang.
HTTP/3 pindah ke QUIC di atas UDP, mengisolasi paket hilang ke masing-masing aliran, mempercepat pembentukan koneksi, dan menangani perpindahan jaringan dengan lebih mulus.

Gambaran besarnya: tiap versi mendorong lebih banyak kecerdasan ke dalam protokol itu sendiri, sehingga web jadi lebih cepat tanpa pengembang harus bergulat dengan “pipa-pipa” di belakangnya. Kalau kamu ingin menyelam lebih dalam dari sini, langkah berikutnya yang masuk akal adalah melihat bagaimana satu permintaan HTTP disusun — metode seperti GET dan POST, kode status seperti 200 dan 404, serta header yang membawa semua metadata yang tadi kita sebut. Blok-blok pembangun ini sama di semua versi, dan memahaminya membuat semua hal lain jadi lebih masuk akal.