HTTP/2 Multiplexing: Cara Kerja dan Rahasia di Balik Koneksi Web yang Lebih Cepat

Pengantar

Kecepatan sebuah website tidak hanya ditentukan oleh spesifikasi server atau koneksi internet. Cara protokol jaringan mengirimkan banyak permintaan dalam satu koneksi juga memiliki pengaruh besar terhadap performa.

Pada era HTTP/1.1, browser sering membutuhkan beberapa koneksi TCP untuk mengambil berbagai resource seperti HTML, CSS, JavaScript, gambar, font, dan file lainnya. Kondisi tersebut dapat menambah overhead dan membuat proses pemuatan halaman menjadi kurang efisien.

HTTP/2 hadir dengan pendekatan yang berbeda. Salah satu fitur terpentingnya adalah multiplexing, yaitu kemampuan untuk menjalankan banyak pertukaran request dan response secara bersamaan melalui satu koneksi.

Menurut spesifikasi resmi IETF, HTTP/2 memungkinkan beberapa pertukaran komunikasi berlangsung secara bersamaan dalam satu koneksi dan setiap pertukaran tersebut dikaitkan dengan stream yang berbeda (dikutip dari: RFC 9113 – HTTP/2).

Teknologi inilah yang membuat HTTP/2 menjadi salah satu perubahan penting dalam evolusi protokol web.

Apa Itu HTTP/2 Multiplexing?

Pengertian Multiplexing

HTTP/2 multiplexing adalah mekanisme yang memungkinkan banyak request dan response berjalan secara bersamaan melalui satu koneksi HTTP/2.

Setiap komunikasi tersebut ditempatkan ke dalam sebuah stream.

Gambaran sederhananya:

HTTP/2 Connection
│
├── Stream 1 → HTML
├── Stream 3 → CSS
├── Stream 5 → JavaScript
├── Stream 7 → Image
├── Stream 9 → Font
└── Stream 11 → API

Semua stream tersebut dapat menggunakan koneksi yang sama.

Dengan demikian, browser tidak perlu membuat satu koneksi TCP terpisah untuk setiap resource.

baca juga : Privileged Identity Management (PIM): Strategi Mengamankan Akses Istimewa dari Ancaman Siber

HTTP/1.1 vs HTTP/2 Multiplexing

Model HTTP/1.1

Pada HTTP/1.1, browser dapat menggunakan beberapa koneksi untuk mengambil resource secara bersamaan.

Contohnya:

Browser
│
├── TCP Connection 1 → HTML
├── TCP Connection 2 → CSS
├── TCP Connection 3 → JavaScript
├── TCP Connection 4 → Image
└── TCP Connection 5 → Font

Setiap koneksi memiliki overhead tersendiri.

Walaupun HTTP/1.1 mendukung persistent connection dan pipelining, implementasi modern browser umumnya menggunakan beberapa koneksi untuk meningkatkan paralelisme.

Model HTTP/2

HTTP/2 mengubah pendekatan tersebut menjadi:

Browser
        │
        ▼
   One TCP Connection
        │
 ┌──────┼──────────────┐
 ▼      ▼              ▼
Stream Stream         Stream
  1      3               5
HTML    CSS         JavaScript

Banyak stream dapat berjalan di dalam satu koneksi.

Inilah inti dari multiplexing.

Apa Itu HTTP/2 Stream?

Stream sebagai Jalur Logis

Stream merupakan urutan frame dua arah yang independen secara logis di dalam koneksi HTTP/2.

Setiap stream memiliki sebuah identifier.

Contohnya:

Stream 1
→ Request HTML
→ Response HTML

Stream 3
→ Request CSS
→ Response CSS

Stream 5
→ Request JavaScript
→ Response JavaScript

Menurut RFC 9113, sebuah koneksi HTTP/2 dapat memiliki banyak stream yang terbuka secara bersamaan dan frame dari stream yang berbeda dapat disisipkan satu sama lain (dikutip dari: RFC 9113 – Section 5, Streams and Multiplexing).

Bagaimana Multiplexing Bekerja?

Request Dipecah Menjadi Frame

HTTP/2 menggunakan format binary framing.

Data tidak dikirim sebagai satu blok HTTP/1.1 yang panjang, tetapi dibagi menjadi beberapa frame.

Contohnya:

HTTP Request
     ↓
┌──────────┐
│ HEADERS  │
└──────────┘
     ↓
┌──────────┐
│   DATA   │
└──────────┘

Frame tersebut kemudian diberi informasi mengenai stream yang terkait.

Frame dari Banyak Stream Dapat Disisipkan

Misalnya terdapat tiga stream:

Stream 1 → HTML
Stream 3 → CSS
Stream 5 → JavaScript

Pengiriman dapat terlihat seperti:

HEADERS Stream 1
DATA    Stream 1

HEADERS Stream 3
DATA    Stream 3

DATA    Stream 1

HEADERS Stream 5
DATA    Stream 5

DATA    Stream 3

Artinya, data dari stream berbeda dapat diinterleave pada koneksi yang sama.

Tidak perlu menunggu seluruh response Stream 1 selesai sebelum Stream 3 atau Stream 5 dapat mengirimkan data.

Mengapa Multiplexing Membuat HTTP/2 Lebih Efisien?

Mengurangi Jumlah Koneksi

Dengan multiplexing, banyak request dapat berbagi satu koneksi.

HTTP/1.1

Client
 ├── Connection 1
 ├── Connection 2
 ├── Connection 3
 └── Connection 4


HTTP/2

Client
      │
      ▼
One Connection
 ├── Stream 1
 ├── Stream 3
 ├── Stream 5
 └── Stream 7

Hal ini mengurangi kebutuhan untuk membuat dan mempertahankan banyak koneksi TCP.

Mengurangi Connection Overhead

Setiap koneksi membutuhkan proses tertentu sebelum data dapat dikirim secara optimal.

Jika menggunakan HTTPS, terdapat pula proses TLS.

Dengan menggunakan satu koneksi untuk banyak stream, overhead tersebut dapat digunakan bersama.

Hasilnya dapat membantu mengurangi latency dan meningkatkan efisiensi penggunaan jaringan.

Hubungan Multiplexing dengan Latency

Mengurangi Waktu Tunggu

Bayangkan sebuah halaman membutuhkan:

• 1 HTML
• 3 CSS
• 5 JavaScript
• 10 gambar
• 2 font

Jika setiap resource harus menunggu koneksi atau jalur komunikasi tertentu, proses pemuatan dapat menjadi lebih lambat.

Dengan HTTP/2:

Single Connection
       │
       ├── HTML
       ├── CSS
       ├── JS
       ├── Image
       └── Font

Resource dapat diproses secara lebih paralel.

MDN menjelaskan bahwa salah satu tujuan utama HTTP/2 adalah mengurangi latency dengan mendukung full request/response multiplexing dan prioritas request (dikutip dari: MDN – HTTP/2).

Multiplexing dan Head-of-Line Blocking

Apa Itu Head-of-Line Blocking?

Head-of-Line (HOL) blocking terjadi ketika data di bagian depan antrean menghambat data lain yang sebenarnya sudah siap diproses.

Pada HTTP/1.1 pipelining, masalah ini dapat terjadi karena response harus mengikuti urutan tertentu.

Contohnya:

Request A → Lambat
Request B → Cepat
Request C → Cepat

A menunggu
↓
B ikut tertahan
↓
C ikut tertahan

HTTP/2 mengatasi masalah tersebut pada level HTTP dengan memungkinkan frame dari stream berbeda disisipkan.

HTTP/2 Tidak Menghilangkan Semua HOL Blocking

Poin ini penting.

HTTP/2 multiplexing mengurangi application-level HOL blocking, tetapi HTTP/2 masih berjalan di atas TCP.

Jika terjadi kehilangan packet TCP, TCP harus melakukan retransmission dan menjaga urutan byte yang diterima.

Akibatnya, kehilangan packet pada satu koneksi TCP masih dapat berdampak terhadap data dari beberapa stream yang menggunakan koneksi tersebut.

Inilah salah satu alasan HTTP/3 menggunakan QUIC di atas UDP untuk menyediakan multiplexing pada transport layer dengan karakteristik yang berbeda.

Peran TCP dalam HTTP/2 Multiplexing

Satu Koneksi TCP

Secara umum, arsitektur HTTP/2 dapat digambarkan:

Application
     │
   HTTP/2
     │
     ▼
    TCP
     │
     ▼
     IP

Multiplexing dilakukan oleh HTTP/2 melalui stream.

Namun seluruh stream tersebut tetap menggunakan koneksi TCP yang sama.

Mengapa Ini Penting?

Karena jika koneksi TCP mengalami gangguan, beberapa stream yang berbagi koneksi tersebut dapat terkena dampaknya.

Contohnya:

TCP Connection
│
├── Stream 1
├── Stream 3
├── Stream 5
└── Stream 7
       ↓
Packet Loss
       ↓
TCP Retransmission
       ↓
Potential Delay

Jadi, multiplexing bukan berarti setiap stream memiliki koneksi jaringan yang benar-benar terpisah.

Stream hanya merupakan jalur logis di dalam satu koneksi.

HTTP/2 Frame dan Multiplexing

HEADERS Frame

Frame HEADERS membawa informasi header HTTP.

Contohnya secara konseptual:

HEADERS
├── :method
├── :path
├── :scheme
└── :authority

Frame ini dapat menjadi bagian awal dari sebuah request atau response.

baca juga : Software Bill of Materials (SBOM): Senjata Penting untuk Mengamankan Rantai Pasok Software

DATA Frame

DATA frame membawa payload.

Contohnya:

Stream 1
├── HEADERS
├── DATA
├── DATA
└── DATA

Data dari stream tersebut dapat diselingi dengan frame milik stream lain.

SETTINGS Frame

SETTINGS digunakan untuk bertukar parameter konfigurasi HTTP/2 antara endpoint.

Salah satu parameter penting berkaitan dengan jumlah stream yang dapat digunakan secara bersamaan.

RST_STREAM

RST_STREAM digunakan untuk menghentikan sebuah stream.

Hal menariknya adalah penghentian satu stream tidak harus berarti seluruh koneksi HTTP/2 dihentikan.

Contohnya:

Connection
├── Stream 1 → Active
├── Stream 3 → RST
├── Stream 5 → Active
└── Stream 7 → Active

Stream tertentu dapat dihentikan sementara stream lainnya tetap berjalan.

Multiplexing dan Flow Control

Mengapa Flow Control Dibutuhkan?

Multiplexing memungkinkan banyak stream mengirim data secara bersamaan.

Namun receiver memiliki kemampuan pemrosesan dan buffer yang terbatas.

Karena itu HTTP/2 menggunakan flow control.

Secara sederhana:

Sender
   ↓
DATA
   ↓
Receiver Buffer
   ↓
WINDOW_UPDATE

Receiver dapat mengontrol seberapa banyak data yang boleh dikirim.

RFC 9113 menjelaskan bahwa flow control digunakan untuk memastikan penggunaan stream multiplexed tetap efisien dengan membatasi data yang dikirim berdasarkan kemampuan receiver untuk menanganinya (dikutip dari: RFC 9113 – Flow Control).

Multiplexing dan Request Prioritization

Tidak semua resource memiliki tingkat kepentingan yang sama.

Contohnya:

HTML
 ↓
Critical CSS
 ↓
JavaScript
 ↓
Image
 ↓
Analytics

HTML dan CSS yang diperlukan untuk menampilkan halaman mungkin lebih penting daripada analytics.

HTTP/2 menyediakan mekanisme yang berkaitan dengan prioritas untuk membantu penggunaan resource yang terbatas secara lebih efektif.

Namun, perlu dipahami bahwa implementasi modern HTTP/2 memiliki perubahan terkait mekanisme prioritas dibandingkan spesifikasi HTTP/2 generasi awal.

Contoh Sederhana HTTP/2 Multiplexing

Bayangkan browser meminta tiga resource:

GET /index.html
GET /style.css
GET /app.js

Pada HTTP/2:

                 TCP Connection
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
    Stream 1       Stream 3       Stream 5
    index.html     style.css      app.js
        │             │             │
        └─────────────┼─────────────┘
                      ▼
                  HTTP/2

Frame dapat dikirim secara bergantian:

HEADERS S1
HEADERS S3
HEADERS S5
DATA S1
DATA S3
DATA S5
DATA S1
DATA S5

Semua tetap melewati koneksi yang sama.

Keuntungan HTTP/2 Multiplexing

1. Lebih Sedikit Koneksi

Banyak request dapat menggunakan satu koneksi.

2. Mengurangi Overhead

Handshake dan pengelolaan koneksi dapat lebih efisien.

3. Mengurangi Latency

Request tidak harus menunggu koneksi terpisah untuk setiap resource.

4. Paralelisme Lebih Baik

Banyak stream dapat aktif secara bersamaan.

5. Pemanfaatan Bandwidth Lebih Efisien

Frame dari berbagai stream dapat berbagi koneksi.

6. Cocok untuk Website Modern

Website modern biasanya membutuhkan banyak resource, sehingga multiplexing memberikan keuntungan yang signifikan.

baca juga : Consistent Hashing: Cara Membagi Data Secara Efisien di Sistem Terdistribusi

Apakah HTTP/2 Multiplexing Selalu Lebih Cepat?

Tidak Selalu

Multiplexing bukan jaminan bahwa setiap website otomatis menjadi lebih cepat.

Performa tetap dipengaruhi oleh:

• Latency jaringan.
• Packet loss.
• Bandwidth.
• Server.
• CDN.
• Ukuran resource.
• TLS.
• Browser.
• Konfigurasi HTTP/2.
• Kemampuan perangkat.

Misalnya, koneksi dengan packet loss tinggi masih dapat mengalami masalah karena HTTP/2 berjalan di atas TCP.

Server Tetap Harus Dioptimalkan

HTTP/2 tidak menggantikan kebutuhan optimasi server.

Beberapa hal yang tetap penting:

HTTP/2
 +
Caching
 +
Compression
 +
CDN
 +
Optimized Images
 +
Efficient Backend

Kombinasi tersebut lebih efektif daripada hanya mengaktifkan HTTP/2 tanpa melakukan optimasi lainnya.

HTTP/2 Multiplexing vs HTTP/1.1

Fitur	HTTP/1.1	HTTP/2
Format	Text-based	Binary framing
Multiplexing	Tidak seperti HTTP/2	Ya
Multiple Streams	Tidak	Ya
Header Compression	Tidak	HPACK
Single Connection	Bisa persistent	Dirancang untuk banyak stream
Parallel Request	Terbatas oleh model koneksi	Lebih efisien
Stream ID	Tidak	Ya
Flow Control	Terbatas pada mekanisme HTTP/1.1	Per-stream & connection

Perbedaan tersebut membuat HTTP/2 lebih cocok untuk pola komunikasi web modern yang membutuhkan banyak request secara bersamaan.

HTTP/2 Multiplexing vs HTTP/3

Persamaan

HTTP/2 dan HTTP/3 sama-sama mendukung multiplexing.

Keduanya memungkinkan banyak stream digunakan untuk komunikasi secara bersamaan.

HTTP/2
HTTP
 ↓
HTTP/2 Streams
 ↓
TCP
 ↓
IP

Sedangkan:

HTTP/3
HTTP
 ↓
HTTP/3 Streams
 ↓
QUIC
 ↓
UDP
 ↓
IP

Perbedaan Utama

Perbedaan penting terdapat pada transport layer.

HTTP/2 menggunakan TCP, sedangkan HTTP/3 menggunakan QUIC.

Akibatnya, HTTP/3 dirancang untuk mengurangi dampak transport-level head-of-line blocking yang masih dapat terjadi ketika HTTP/2 menggunakan satu koneksi TCP.

Dampak Multiplexing terhadap Pengembangan Website

Developer tidak perlu membuat sistem aplikasi khusus hanya untuk menggunakan konsep multiplexing.

HTTP/2 mempertahankan semantik HTTP sehingga metode seperti:

GET
POST
PUT
DELETE
PATCH

tetap digunakan.

Perubahan utama terjadi pada cara data dibingkai dan ditransmisikan di bawah HTTP.

Karena itu, banyak aplikasi web dapat memanfaatkan HTTP/2 tanpa perlu mengubah logika API secara besar-besaran.

Cara Mengetahui Website Menggunakan HTTP/2

Developer dapat memeriksa protokol yang digunakan melalui browser.

Pada Chrome atau browser berbasis Chromium, misalnya:

Developer Tools
      ↓
Network
      ↓
Protocol

Jika resource menggunakan HTTP/2, biasanya akan terlihat indikator seperti:

h2

Pengembang juga dapat menggunakan tools jaringan seperti curl untuk memeriksa dukungan HTTP/2 pada server.

baca juga : Cross-Site Request Forgery (CSRF): Cara Kerja Serangan dan Strategi Efektif untuk Melindungi Web

Kesimpulan

HTTP/2 Multiplexing merupakan salah satu fitur penting yang membuat HTTP/2 lebih efisien dibandingkan pendekatan HTTP/1.1 tradisional.

Dengan multiplexing, banyak request dan response dapat berjalan melalui satu koneksi TCP menggunakan stream yang berbeda. Data dari berbagai stream dapat dipecah menjadi frame dan dikirim secara bergantian melalui koneksi yang sama.

Pendekatan ini membantu mengurangi kebutuhan koneksi tambahan, menekan overhead, meningkatkan paralelisme, dan membantu mengurangi latency pada website yang memiliki banyak resource.

Namun, HTTP/2 multiplexing bukan berarti semua masalah performa jaringan otomatis hilang. Karena HTTP/2 masih menggunakan TCP, packet loss pada koneksi dapat tetap berdampak terhadap beberapa stream sekaligus.

Memahami konsep stream, frame, flow control, prioritization, TCP, dan head-of-line blocking menjadi penting untuk memahami mengapa HTTP/2 bekerja lebih efisien dan bagaimana HTTP/3 kemudian membawa konsep multiplexing tersebut ke lingkungan QUIC.

Dengan kata lain, jika HTTP/1.1 dapat dianalogikan seperti menggunakan beberapa jalur untuk mengirim barang, HTTP/2 mencoba membuat satu jalur yang lebih efisien dengan memungkinkan banyak aliran data berjalan secara bersamaan di dalamnya.