HTTP/1.0 umumnya membuka koneksi baru per permintaan; HTTP/1.1 memakai koneksi persisten; HTTP/2 menambahkan multiplexing dan kompresi header di atas TCP; HTTP/3 berjalan di atas QUIC berbasis UDP sehingga kehilangan paket pada satu stream tidak menahan stream lain.
Halaman terasa lambat meski server mengirim sedikit data? Bisa jadi waktu habis bukan untuk mengunduh konten, melainkan menunggu koneksi. HTTP telah berkembang dari satu permintaan per koneksi menuju pertukaran data multiplex melalui satu koneksi—tetapi versi terbaru tidak otomatis membuat setiap situs lebih cepat.
HTTP itu apa, dan apa yang dimaksud versinya?
HTTP (Hypertext Transfer Protocol) adalah protokol aplikasi untuk pertukaran request dan response antara klien—misalnya browser—dan server. HTTP bersifat stateless: setiap request dapat dipahami tanpa server harus menganggapnya sebagai bagian dari satu percakapan yang tersimpan; aplikasi dapat menambahkan state melalui cookie atau mekanisme lain.
Versi HTTP terutama berbeda pada format pesan dan cara pesan dibawa melalui koneksi. Semantik dasarnya—seperti metode GET, kode status, header, dan makna resource—dibagi lintas versi. Catatan: “HTTP/1.0”, “HTTP/1.1”, “HTTP/2”, dan “HTTP/3” adalah nama versi; versi standar modern umumnya ditulis tanpa akhiran .0, meskipun “HTTP/2.0” dan “HTTP/3.0” kadang dipakai secara informal.
Perjalanan singkat HTTP/1.0 ke HTTP/3
HTTP/1.0: pesan sederhana, koneksi sering terputus
HTTP/1.0 memopulerkan model request-response berbasis teks: request berisi baris metode/path, header, lalu body opsional; server membalas dengan status, header, dan body. Dalam praktik awal, satu koneksi TCP lazimnya digunakan untuk satu pertukaran lalu ditutup. Browser yang memuat HTML, CSS, JavaScript, dan banyak gambar harus membuka banyak koneksi atau menunggu giliran, sehingga latensi setup koneksi berulang terasa mahal.
HTTP/1.0 berkembang melalui implementasi dan dokumen spesifikasi awal; jangan menganggap semua perilaku historisnya seragam. Koneksi persisten dapat muncul sebagai ekstensi, tetapi belum menjadi perilaku baku yang konsisten seperti di HTTP/1.1.
HTTP/1.1: koneksi persisten dan protokol yang lebih matang
HTTP/1.1, yang distandardisasi pada 1997 dan kini didefinisikan dalam RFC 9112 untuk sintaks pesan, membawa koneksi persisten sebagai default. Beberapa request ke host yang sama bisa memakai koneksi TCP yang sama. Fitur penting lainnya mencakup chunked transfer coding, Host untuk virtual hosting, cache control yang lebih matang, conditional request, dan range request.
Namun, pesan HTTP/1.1 tetap berupa teks dan pada satu koneksi respons harus mengikuti urutan request (pipelining tidak banyak digunakan karena implementasi dan penanganan head-of-line blocking yang rumit). Browser biasanya membuka beberapa koneksi TCP paralel per origin. Itu membantu memuat aset, tetapi menambah handshake, penggunaan socket, dan kompetisi congestion control.
HTTP/2: framing biner dan multiplexing di atas TCP
HTTP/2 (RFC 9113) mempertahankan semantik HTTP, tetapi mengodekan pesan sebagai frame biner. Satu koneksi TCP dapat membawa banyak stream secara bersamaan; frame dari stream berbeda dapat saling berselang-seling. HPACK mengompresi header, dan alur prioritas serta kontrol aliran membantu mengatur pengiriman.
Multiplexing mengurangi kebutuhan membuka banyak koneksi dan mencegah satu response lambat memblokir response lain pada tingkat HTTP stream. Tetapi semua stream HTTP/2 pada koneksi tersebut berbagi satu koneksi TCP. Jika paket TCP hilang, TCP tidak dapat menyerahkan byte sesudah celah itu ke aplikasi sampai paket yang hilang dipulihkan. Inilah transport-level head-of-line blocking yang masih bisa menahan semua stream pada koneksi itu.
Server push pernah menjadi fitur HTTP/2, tetapi dukungan dan kegunaannya terbatas; banyak penerapan modern memilih tidak mengandalkannya. Cache browser, preload hints, dan prioritas resource sering menjadi pendekatan yang lebih dapat diprediksi. HTTP/2 tidak berarti “data selalu lebih kecil” atau “setiap halaman pasti lebih cepat”: hasil kompresi dan performa bergantung pada pola header, server, jaringan, dan aplikasi.
HTTP/3: HTTP di atas QUIC
HTTP/3 (RFC 9114) membawa semantik HTTP melalui QUIC, transport terenkripsi yang menggunakan UDP sebagai dasar (QUIC didefinisikan dalam RFC 9000). QUIC menggabungkan fungsi transport dan TLS 1.3, menyediakan stream independen, kontrol aliran per stream, serta setup koneksi yang dapat lebih singkat. Pada koneksi baru, QUIC biasanya menggabungkan negosiasi kriptografi dan transport; koneksi lanjutan dapat memanfaatkan resumption, dan 0-RTT dapat mengirim data lebih awal dengan risiko replay sehingga hanya aman untuk operasi yang sesuai.
Karena stream QUIC diandalkan secara terpisah, kehilangan paket pada satu stream tidak secara otomatis menahan pengiriman data stream lain yang sudah tersedia. Kehilangan tetap punya biaya: stream yang terdampak harus memulihkan data, congestion control tetap membatasi laju keseluruhan, dan kondisi jaringan yang buruk dapat membuat semua protokol lambat. QUIC juga mendukung migrasi koneksi, misalnya saat alamat jaringan perangkat berubah, jika kondisi dan kebijakan memungkinkan.
UDP tidak selalu lolos jaringan perusahaan atau firewall. Implementasi biasanya dapat beralih ke HTTP/2 atau HTTP/1.1 melalui TCP ketika QUIC diblokir. Karena HTTP/3 mengenkripsi lebih banyak bagian transport, observabilitas jaringan tradisional juga dapat memerlukan alat dan konfigurasi yang sesuai.
Tabel perbandingan HTTP/1.0, HTTP/1.1, HTTP/2, dan HTTP/3
| Aspek | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|---|
| Format pesan | Teks, format sederhana | Teks; framing dan aturan pesan lebih lengkap | Frame biner | Frame HTTP/3 di atas stream QUIC |
| Transport umum | TCP | TCP | TCP | QUIC di atas UDP |
| Penggunaan koneksi | Umumnya satu pertukaran per koneksi dalam penggunaan awal | Persisten secara default; request berurutan pada koneksi | Banyak stream multiplex pada satu koneksi TCP | Banyak stream independen pada koneksi QUIC |
| Kompresi header | Tiada mekanisme modern standar | Tiada kompresi header standar | HPACK | QPACK, dirancang agar sesuai dengan pengiriman stream QUIC |
| Risiko head-of-line | Penungguan koneksi dan request berurutan | Antrean request/response pada koneksi; banyak koneksi dapat membantu dengan biaya tambahan | Kehilangan paket TCP dapat menahan seluruh koneksi | Kehilangan pada satu stream tidak otomatis memblokir stream lain; congestion tetap berbagi kapasitas |
| Enkripsi di browser | HTTP biasa atau HTTPS melalui TLS | HTTP biasa atau HTTPS melalui TLS | Umumnya digunakan melalui TLS di browser, walau spesifikasi tidak menjadikan enkripsi sebagai satu-satunya mode | QUIC selalu mengintegrasikan TLS 1.3 |
| Manfaat khas | Kompatibilitas dengan ekosistem lama | Koneksi persisten, fitur pesan dan cache lebih matang | Multiplexing dan kompresi header | Multiplexing tanpa blocking lintas-stream akibat pemulihan TCP; setup dan migrasi koneksi yang lebih baik dalam kondisi tertentu |
Bagaimana HTTP memengaruhi latency dan web performance?
Latency adalah waktu tunda perjalanan data; bandwidth adalah kapasitas data per satuan waktu. Menambah bandwidth membantu transfer objek besar, tetapi tidak selalu mempercepat halaman yang terdiri dari banyak request kecil. Jika sebuah operasi perlu menunggu bolak-balik ke server, Round-Trip Time (RTT) dan jumlah perjalanan sering lebih menentukan.
Bayangkan RTT 80 ms. Satu pertukaran request-response membutuhkan setidaknya satu perjalanan jaringan, belum termasuk DNS, setup koneksi TCP, TLS, antrean, pemrosesan server, dan pengunduhan body. Membuka koneksi baru dapat menambahkan beberapa RTT sebelum konten aplikasi mulai diterima. Koneksi persisten, multiplexing, cache, dan resumption mengurangi sebagian biaya tersebut.
Waktu tampilan halaman juga dipengaruhi parsing HTML, CSS/JavaScript yang memblokir render, ukuran gambar, CPU perangkat, cache, server response time, CDN, dan dependensi berantai. HTTP/2 atau HTTP/3 tidak memperbaiki JavaScript berat, query database lambat, gambar tak terkompresi, atau layout yang memblokir rendering.
Masalah latency yang sering ditemui
- Handshake dan koneksi berulang: koneksi baru memerlukan setup transport dan, untuk HTTPS, negosiasi TLS. HTTP/1.1 keep-alive mengurangi pembukaan ulang; HTTP/2 berbagi satu koneksi; QUIC dapat merendahkan biaya setup pada koneksi baru/resumed.
- Head-of-line blocking: HTTP/1.1 membatasi pertukaran berurutan dalam koneksi; HTTP/2 menghilangkan antrean antar-response di lapisan HTTP, tetapi kehilangan paket TCP masih dapat menahan byte seluruh koneksi; QUIC mengisolasi pemulihan stream, bukan menghapus semua kemacetan.
- Antrean dependensi: HTML mungkin harus diterima dan diparse sebelum browser tahu file CSS atau JavaScript mana yang dibutuhkan. Petunjuk preload, pengurangan render-blocking, dan pengiriman HTML awal yang cepat membantu.
- Cold cache atau origin jauh: pengguna yang jauh dari server mengalami RTT tinggi. CDN, caching edge, dan lokasi origin yang tepat dapat mengurangi jarak jaringan.
- Konten dan prioritas: mengirim banyak resource sekaligus tidak selalu ideal. Prioritas yang keliru dapat membuat gambar besar mengganggu CSS atau konten utama.
Panduan memilih dan mengoptimalkan versi
Untuk pemilik situs: aktifkan HTTP/2 dan HTTP/3 pada CDN atau server yang mendukungnya, pastikan ALPN dan TLS dikonfigurasi benar, lalu pertahankan fallback HTTP/1.1. Periksa apakah CDN benar-benar menegosiasikan versi yang diharapkan; konfigurasi server saja tidak menjamin jalur browser-ke-edge menggunakannya.
Untuk mengukur: gunakan DevTools Network untuk melihat protokol, waterfall, request blocking, TTFB, dan cache. Ukur TTFB (Time to First Byte), LCP (Largest Contentful Paint), INP, dan CLS menggunakan data lab serta field/RUM bila tersedia. Ulangi pengukuran di jaringan, perangkat, dan kondisi cache berbeda; bandingkan median dan persentil tinggi seperti p75, bukan hanya satu hasil.
Di terminal, curl -I --http2 https://example.com/ dapat menguji negosiasi HTTP/2 jika curl dibangun dengan dukungan tersebut. Versi curl dan opsi HTTP/3 berbeda-beda, jadi periksa curl --version dan dokumentasi build lokal. Untuk melihat negosiasi ALPN TLS, openssl s_client -connect example.com:443 -servername example.com -alpn h2 dapat membantu, tetapi bukan pengganti uji browser end-to-end.
Untuk pengembang: kurangi request yang tidak perlu, cache aset statis dengan kebijakan yang benar, kompres teks, optimalkan gambar dan font, hindari rantai redirect, gunakan preload hanya untuk resource kritis, dan kirim respons backend lebih cepat. Jangan menerapkan domain sharding secara otomatis: pada HTTP/2/3, memecah aset ke banyak host bisa menambah DNS, koneksi, dan handshake.
Jangan menganggap HTTP/3 selalu unggul. Pada jaringan dengan loss, variasi latency, firewall UDP, perangkat lama, atau implementasi yang belum optimal, hasil dapat berbeda. Uji berdasarkan populasi pengguna dan jalur nyata; fallback yang sehat penting.
Ringkasan
HTTP/1.0 membawa model request-response sederhana, HTTP/1.1 menambahkan koneksi persisten dan fitur web penting, HTTP/2 memperkenalkan frame biner serta multiplexing melalui TCP, sedangkan HTTP/3 menjalankan HTTP di atas QUIC untuk stream independen dan setup yang lebih modern. Setiap versi mempertahankan semantik HTTP inti, tetapi mengubah cara pesan dikirim.
Versi protokol dapat mengurangi biaya koneksi dan beberapa bentuk penungguan, namun bukan obat untuk semua masalah performa. Ukur bottleneck terlebih dahulu, optimalkan aplikasi dan aset, lalu validasi HTTP/2 atau HTTP/3 pada kondisi nyata. Kunjungi BelajarCerdas.com untuk panduan teknologi praktis lainnya—pelajari konsepnya, uji dengan alat yang tepat, dan bangun web yang lebih cepat untuk pengguna Anda.