Wawancara Jaringan: Bagaimana HTTP/3 Mengatasi Head-of-Line Blocking pada HTTP/2?

Pertanyaan dan Kapan Ini Berlaku

Stream A dan B ditransfer secara bersamaan (concurrently) melalui satu koneksi, dan sebuah paket yang membawa data stream A hilang. Jelaskan mengapa stream B juga dapat terhenti (stall) pada HTTP/2, bagaimana HTTP/3 mengubah hasil tersebut, serta bentuk blocking atau performance coupling apa saja yang masih ada pada HTTP/3.

Dua stream dan satu kehilangan paket (loss) adalah asumsi wawancara, bukan batasan protokol. Alur utama membandingkan HTTP/2 di atas TCP dengan HTTP/3 di atas QUIC. Asumsikan bahwa permintaan-permintaan tersebut bersifat independen, koneksi telah terjalin, dan lebih banyak data tiba setelah loss terjadi. Pertanyaan ini cocok untuk posisi frontend, backend, client, infrastructure, SRE, dan rekayasa perangkat lunak umum.

Tujuannya bukan untuk sekadar menghafal bahwa HTTP/3 menggunakan UDP. Jawaban yang kuat menyebutkan layer yang memaksakan urutan, mengidentifikasi batas pengiriman (delivery boundary) yang terhenti oleh data yang hilang, dan menjelaskan mengapa pengiriman stream yang independen tidak berarti independensi performa secara menyeluruh.

Apa yang Dinilai oleh Pewawancara

Pertama, dapatkah kandidat memisahkan head-of-line blocking pada layer yang berbeda? Pipelining HTTP/1.1 memiliki batasan urutan respons. Frame dan stream HTTP/2 menghilangkan urutan lapisan aplikasi (application-layer ordering) antar pesan HTTP, tetapi setiap stream tetap berbagi satu TCP byte stream yang berurutan.

Kedua, dapatkah kandidat menganalisis dampak dari packet loss? TCP mengirimkan byte ke lapisan atas secara berurutan. Ketika satu rentang byte hilang, HTTP/2 belum dapat menerima byte berikutnya, bahkan jika byte tersebut berisi frame lengkap untuk stream B.

Ketiga, dapatkah kandidat menjelaskan QUIC secara tepat? HTTP/3 memetakan permintaan ke stream QUIC dua arah (bidirectional). QUIC mempertahankan urutan berdasarkan stream ID dan offset, sehingga celah (gap) pada stream A tidak menciptakan satu celah pengiriman data aplikasi di seluruh koneksi.

Keempat, dapatkah kandidat menyebutkan batasan-batasan yang tersisa? Stream A tetap menunggu retransmission. Jika satu paket QUIC yang hilang membawa data dari A dan B, kedua stream akan menunggu data mereka yang hilang. Congestion control bersama, flow control tingkat koneksi dan tingkat stream, dependensi dynamic-table QPACK, serta penjadwalan aplikasi juga dapat menciptakan waktu tunggu atau performance coupling.

Kelima, dapatkah kandidat mengusulkan pengujian yang valid? Jawaban yang kuat menggambarkan lini masa paket dan stream, kemudian menggabungkan loss terkontrol, resource konkuren yang independen, bukti protokol yang dinegosiasikan, waktu penyelesaian per stream, dan qlog alih-alih hanya membandingkan total waktu muat halaman.

Pertanyaan Klarifikasi Sebelum Menjawab

• Mekanisme blocking mana yang sedang kita bandingkan? Urutan respons HTTP/1.1, keterlambatan pengiriman lintas stream HTTP/2 setelah TCP loss, atau antrean kerja server? Pertanyaan ini berfokus pada yang kedua.
• Apakah permintaan-permintaan tersebut independen? Jika hasil bisnis B bergantung pada A, aplikasi harus menunggu meskipun transport dapat mengirimkan B secara independen.
• Stream mana saja yang ada di dalam paket yang hilang? Jika satu paket QUIC membawa frame STREAM untuk A dan B, B tidak dijamin bebas dari dampak.
• Apakah protokol yang dimaksud benar-benar dinegosiasikan? Pengujian HTTP/3 harus membedakan koneksi h3 yang berhasil dari fallback ke HTTP/2.
• Bagaimana loss dan kemacetan (congestion) dikendalikan? Satu kali pengujian acak bersifat bising (noisy). Pertahankan konten dan server tetap sama dan ulangi kondisi latensi, bandwidth, dan loss yang identik.
• Apakah kita menjelaskan kebenaran logika (correctness) atau performa end-to-end? Independensi pengiriman lintas stream adalah properti protokol. Apakah HTTP/3 lebih cepat juga bergantung pada RTT, loss, implementasi, CPU, keterjangkauan UDP, dan beban kerja server.

Kerangka Jawaban 30 Detik

“HTTP/2 membagi pesan HTTP menjadi frame yang dapat disisipkan (interleavable) dan stream yang independen, sehingga menghilangkan head-of-line blocking pada layer aplikasi seperti yang terlihat pada pipelining HTTP/1.1. Frame-frame tersebut tetap berjalan melalui satu TCP byte stream. Jika byte TCP yang membawa stream A hilang, TCP tidak dapat mengirimkan byte berikutnya ke HTTP/2 hingga celah tersebut terisi. Oleh karena itu, stream B terhenti meskipun byte berikutnya adalah milik B.

HTTP/3 menempatkan setiap permintaan pada stream QUIC yang independen. QUIC menyusun ulang data berdasarkan stream ID dan stream offset, sehingga celah pada A hanya menghentikan A, sementara B yang tidak memiliki celah dapat terus berjalan. HTTP/3 tidak menghilangkan semua waktu tunggu: stream dengan data yang hilang tetap menunggu retransmission; satu paket dapat memengaruhi setiap stream yang ada di dalam paket tersebut; koneksi berbagi congestion window; serta flow control, dependensi QPACK, dan penjadwalan aplikasi dapat memperlambat pekerjaan lain. Klaim yang tepat adalah bahwa HTTP/3 menghilangkan head-of-line blocking pengiriman lintas stream yang disebabkan oleh satu aliran byte berurutan pada TCP. Protokol ini tidak membuat packet loss menjadi tanpa dampak sama sekali.”

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Temukan “head” dalam antrean tertentu

Setiap masalah head-of-line memiliki pola yang sama: pekerjaan sebelumnya belum memenuhi syarat pengirimannya, sehingga pekerjaan berikutnya tidak dapat melewatinya meskipun sudah siap. Dalam wawancara, sebutkan objek yang sedang diurutkan.

Pipelining HTTP/1.1 dapat mengirim banyak permintaan tanpa menunggu, tetapi respons harus dikembalikan sesuai urutan permintaan. Respons pertama yang lambat mencegah respons berikutnya dikirimkan lebih dulu. Itu adalah batasan urutan pesan HTTP. HTTP/2 menambahkan binary framing, multiplexing, dan stream independen. Server dapat menyisipkan frame untuk A dan B, sehingga B tidak perlu menunggu seluruh respons HTTP dari A selesai.

HTTP/2 umumnya masih membawa setiap stream melalui satu koneksi TCP. TCP menyediakan satu byte stream yang andal dan berurutan, serta tidak mengetahui byte mana yang merupakan milik stream A atau B pada HTTP/2. Oleh karena itu, HTTP/2 menghilangkan satu batasan urutan namun tetap berada di balik satu batas pengurutan pada layer di bawahnya.

Langkah 2: Analisis blocking lintas stream HTTP/2 dari lini masa kehilangan paket

Asumsikan pengirim menuliskan rentang-rentang berikut ke satu koneksi TCP. Angka-angka ini hanya ada untuk mengilustrasikan skenario wawancara ini:

TCP bytes 0..999       -> HTTP/2 stream A frame, lost
TCP bytes 1000..1499   -> HTTP/2 stream B frame, received
TCP bytes 1500..1999   -> HTTP/2 stream B frame, received

TCP stack penerima dapat menyangga (buffer) dua rentang yang tidak berurutan tersebut dan mengirimkan acknowledgment, tetapi urutan byte bersebelahan (contiguous) yang terlihat oleh aplikasi tetap terhenti sebelum celah pada 0. Parser HTTP/2 tidak dapat melihat frame setelah byte 1000, tidak dapat memastikan bahwa frame tersebut milik B, dan tidak dapat mengirimkan B ke layer atas. Pengiriman baru dilanjutkan setelah byte 0..999 ditransmisikan ulang dan mengisi celah tersebut.

HTTP/2 tidak mewajibkan A untuk selesai terlebih dahulu. Pengiriman berurutan di seluruh koneksi oleh TCP-lah yang menghentikan B. Mengubah prioritas HTTP/2 atau penyisipan frame tidak dapat melewati celah byte TCP yang sudah terjadi.

Langkah 3: HTTP/3 memperkecil batas pengurutan dari koneksi ke stream

HTTP/3 berjalan di atas QUIC. Setiap permintaan dan respons menggunakan stream QUIC dua arah yang diinisiasi oleh klien, dan frame HTTP/3 dikirimkan pada stream yang bersangkutan. Frame STREAM pada QUIC berisi stream ID dan offset relatif terhadap stream. Penerima menyusun ulang setiap stream secara terpisah, bukan merekonstruksi satu byte stream aplikasi yang mencakup semua permintaan terlebih dahulu.

QUIC packet 20 -> stream A, offsets 0..999, lost
QUIC packet 21 -> stream B, offsets 0..499, received and deliverable to B
QUIC packet 22 -> stream B, offsets 500..999, received and deliverable to B

Stream A memiliki celah offset dan dijeda. Stream B memiliki offset yang berurutan dan dapat langsung dikirimkan. QUIC tetap melakukan pemulihan kehilangan paket (loss recovery), tetapi data yang ditransmisikan ulang dimasukkan ke dalam paket QUIC yang baru; protokol ini tidak mewajibkan paket asli kembali pada posisi awalnya.

“Dibangun di atas UDP” hanya menggambarkan substrat datagram QUIC. QUIC sendiri mengimplementasikan retransmission yang andal, pengiriman berurutan di dalam stream, congestion control, flow control, dan keamanan koneksi. Mengatakan “UDP tidak andal, sehingga tidak bisa memblokir” tidak menjelaskan mekanisme keandalan dan tidak sesuai dengan perilaku QUIC.

Langkah 4: Nyatakan secara tepat data mana yang masih diblokir oleh packet loss

HTTP/3 mengisolasi pada tingkat stream, bukan pada tingkat paket fisik. Satu paket QUIC dapat berisi beberapa frame STREAM. Jika paket yang hilang membawa data baru untuk A dan B, kedua stream akan mengalami celah offset masing-masing dan menunggu data terkait ditransmisikan ulang. Stream C yang tidak memiliki data di dalam paket tersebut dapat terus berjalan.

Bahkan ketika paket yang hilang hanya berisi A, A tetap harus menunggu. HTTP/3 memperkecil dampak kerusakan (blast radius) dari kegagalan tersebut; protokol ini tidak dapat membuat data yang hilang tiba-tiba tersedia. Pernyataan “HTTP/3 tidak memiliki head-of-line blocking” terlalu luas. Jawaban yang tepat menyatakan bahwa hilangnya data pada satu stream tidak lagi berubah menjadi penundaan pengiriman untuk semua stream akibat satu aliran byte TCP yang berurutan.

Penutupan koneksi, kegagalan jalur (path failure), dan kunci enkripsi yang tidak tersedia tetap merupakan peristiwa di tingkat seluruh koneksi dan memengaruhi setiap stream. Isolasi packet loss lintas stream tidak menghilangkan kegagalan-kegagalan tersebut.

Langkah 5: Pisahkan independensi pengiriman dari independensi performa

Congestion control pada QUIC biasanya beroperasi per jalur (per path), bukan dengan satu congestion window per stream. Stream-stream pada koneksi yang sama berbagi kuota byte yang sedang transit (bytes in flight). Setelah mendeteksi loss, congestion controller dapat memperkecil window tersebut. B mungkin tetap dapat dikirimkan sementara data berikutnya tiba lebih lambat.

Pisahkan kesimpulan-kesimpulan ini:

QUIC juga memiliki flow control tingkat koneksi dan tingkat stream. Habisnya kredit penerimaan koneksi dapat menghentikan banyak stream, sedangkan habisnya kredit pada satu stream hanya menghentikan stream tersebut. Dalam wawancara, pisahkan flow control, yang melindungi buffering dan konsumsi penerima, dari congestion control, yang mengatur beban di dalam jaringan.

Langkah 6: QPACK dapat menciptakan blocking terkendali melalui dependensi header

HPACK pada HTTP/2 dapat mengandalkan transport yang berurutan dalam satu koneksi. Stream HTTP/3 tidak memiliki urutan total, sehingga QPACK memisahkan pembaruan tabel dinamis (dynamic-table updates) dari stream permintaan. Jika sebuah blok header mereferensikan entri tabel dinamis yang belum dimiliki penerima, proses decoding header pada stream permintaan tersebut akan menunggu hingga Required Insert Count tersedia.

Ini adalah blocking akibat dependensi kompresi, bukan blocking pengiriman lintas stream TCP. HTTP/3 membatasi jumlah stream yang mungkin diblokir dengan SETTINGS_QPACK_BLOCKED_STREAMS. Encoder juga dapat menghindari blocking dengan hanya mereferensikan entri dinamis yang telah diakui (acknowledged), menukar efisiensi kompresi demi mengurangi risiko blocking.

Ini adalah contoh tandingan yang sangat berguna. Setelah transport menyediakan stream yang independen, protokol aplikasi masih dapat menciptakan waktu tunggu dengan menambahkan dependensi lintas stream. Jawaban yang tepat menyebutkan blocking mana yang dihilangkan oleh HTTP/3 dan dependensi eksplisit mana yang masih tersisa.

Langkah 7: Bandingkan alternatif dan kondisi pengoperasiannya

HTTP/2 masih dapat memenuhi target pada jaringan dengan tingkat loss rendah, dengan infrastruktur yang matang, atau di mana jalur UDP tidak andal. Jangan menyimpulkan bahwa HTTP/3 selalu lebih cepat hanya dari nomor versinya. Peluncuran HTTP/3 juga membutuhkan dukungan klien dan edge, keterjangkauan UDP, fallback koneksi, observabilitas, serta pemeriksaan biaya sumber daya (resource cost).

Membuka beberapa koneksi TCP HTTP/2 dapat membatasi dampak satu loss TCP hanya pada permintaan-permintaan di dalam satu koneksi tersebut. Namun, cara ini menambah beban pembuatan koneksi, status TLS, buffering, dan congestion controller yang saling bersaing, sekaligus mengorbankan sebagian keuntungan multiplexing satu koneksi. Ini adalah kompromi rekayasa (engineering tradeoff), bukan pengganti yang setara untuk semantik stream HTTP/3.

“Menambahkan stream ID ke TCP” akan mengubah antarmuka byte stream berurutan yang telah lama disediakan TCP untuk aplikasi, serta membutuhkan kompatibilitas sistem operasi, middlebox, dan deployment. QUIC menerapkan semantik transport termultipleks yang aman dan baru di user space di atas UDP, memungkinkan evolusi yang lebih cepat. QUIC tetap mengimplementasikan keandalan dan congestion control.

Langkah 8: Rancang eksperimen yang membuktikan isolasi lintas stream

Dalam lingkungan pengujian yang resmi, siapkan beberapa resource konkuren yang independen dan cukup besar untuk mencakup beberapa paket. Jaga agar server, konten, RTT, bandwidth, dan model loss tetap konstan. Jalankan HTTP/2 dan HTTP/3 berulang kali lalu catat:

1. Protokol yang dinegosiasikan, tidak termasuk fallback HTTP/3.
2. Kapan loss dan retransmission terjadi serta stream mana saja yang terpengaruh.
3. Waktu byte pertama (first-byte time) dan waktu penyelesaian untuk setiap stream, bukan hanya total waktu halaman.
4. Sinyal congestion-window, flow-control-credit, dan QPACK blocked-stream.
5. Waktu pemrosesan server, tidak termasuk dependensi aplikasi dan antrean (queueing).

Packet capture terenkripsi biasa dapat menunjukkan waktu paket dan petunjuk loss, tetapi mungkin tidak merekonstruksi pemetaan stream HTTP/3 secara langsung. qlog pada klien atau server lebih baik untuk mengorelasikan paket QUIC, frame STREAM, pemulihan, dan status kemacetan. Jika HTTP/3 tidak lebih cepat, periksa terlebih dahulu apakah pengujian tersebut memicu blocking TCP lintas stream pada HTTP/2, apakah UDP dibatasi, apakah biaya CPU atau handshake mendominasi, atau apakah beban kerja server yang menjadi bottleneck.

Contoh Jawaban Berkualitas Tinggi

“Pertama-tama, saya akan memisahkan layer blocking. Pipelining HTTP/1.1 memiliki batasan urutan respons. HTTP/2 memultipleks frame untuk stream A dan B, sehingga menghilangkan masalah pengurutan pesan HTTP tersebut. Namun, stream-stream-nya biasanya berbagi satu koneksi TCP, dan TCP menyediakan satu byte stream yang andal dan berurutan.

Jika byte TCP yang berisi frame A hilang, penerima dapat menyangga byte berikutnya yang berisi frame B, tetapi TCP tidak dapat mengirimkan byte berikutnya tersebut ke HTTP/2 sampai celah terisi. Oleh karena itu, B terhenti karena hilangnya data pada A. Itulah head-of-line blocking TCP lintas stream pada HTTP/2.

HTTP/3 memetakan permintaan ke stream QUIC dua arah yang independen. Frame STREAM pada QUIC berisi stream ID dan offset relatif terhadap stream, sehingga penerima menyusun ulang data per stream. Data A yang hilang membuat A menunggu retransmission, tetapi B dapat terus berjalan kapan pun offset milik B berurutan. UDP hanyalah substrat QUIC; QUIC menyediakan pemulihan yang andal, urutan di dalam stream, flow control, congestion control, dan keamanan.

Batasan-batasan tersebut tetap penting. Jika satu paket QUIC yang hilang membawa data A dan B, kedua stream akan menunggu rentang data mereka yang hilang. Stream juga berbagi congestion window di tingkat jalur, sehingga hilangnya data pada A dapat mengurangi throughput B di masa mendatang. Flow control koneksi, dependensi dynamic-table QPACK, dan penjadwalan server dapat menciptakan waktu tunggu lainnya. Klaim yang akurat adalah bahwa HTTP/3 menghilangkan blocking pengiriman lintas stream yang disebabkan oleh satu urutan byte pada TCP. Protokol ini tidak menghilangkan pemulihan di dalam stream atau setiap bentuk performance coupling.

Untuk memverifikasinya, saya akan memuat resource independen secara bersamaan di bawah kondisi jaringan terkontrol yang sama, membuktikan bahwa h2 atau h3 telah dinegosiasikan, menginjeksikan loss yang dapat diulang, membandingkan waktu penyelesaian per stream, dan menggunakan qlog untuk membedakan celah stream, kemacetan, flow control, dan blocking QPACK. Hal itu memisahkan efek protokol dari antrean server atau derau acak (random noise).”

Kesalahan Umum

• Hanya mengatakan HTTP/3 menggunakan UDP → UDP tidak menyediakan semantik termultipleks yang andal seperti QUIC → Jelaskan bahwa QUIC mengimplementasikan pemulihan, urutan di dalam stream, flow control, congestion control, dan keamanan.
• Mengatakan HTTP/2 tidak melakukan multiplexing → HTTP/2 sudah menghilangkan urutan pesan HTTP → Temukan masalah yang tersisa pada byte stream TCP bersama.
• Mengasumsikan byte B yang diterima selalu dapat di-parse → HTTP/2 membaca byte hanya setelah TCP mengirimkannya secara berurutan → Telusuri celah TCP dan out-of-order buffer.
• Mengatakan HTTP/3 menghilangkan semua head-of-line blocking → Celah di dalam stream, QPACK, dan dependensi aplikasi tetap harus menunggu → Batasi klaim hanya pada blocking pengiriman lintas stream TCP.
• Memberikan setiap stream QUIC congestion window-nya sendiri → Congestion control biasanya beroperasi per jalur → Pisahkan isolasi pengiriman dari keterikatan throughput (throughput coupling).
• Mengabaikan bahwa satu paket dapat membawa beberapa stream → Satu loss dapat menciptakan celah pada beberapa stream → Periksa frame STREAM yang sebenarnya dibawa oleh paket yang hilang.
• Mengklaim bahwa HTTP/3 selalu lebih cepat → Jalur, loss, implementasi, dan beban server menentukan hasil → Gunakan pengujian terkontrol yang berulang dan metrik per stream.
• Hanya melihat total waktu muat halaman → Data agregat tidak dapat membuktikan blocking lintas stream → Korelasikan protokol, loss, penyelesaian stream, dan qlog.

Pertanyaan Lanjutan dan Cara Menjawabnya

Pertanyaan Lanjutan 1: Bagaimana jika paket QUIC yang hilang berisi data dari A dan B?

A dan B masing-masing akan mengalami celah pada stream mereka sendiri dan menunggu data yang bersangkutan ditransmisikan ulang. QUIC mengisolasi stream lain yang datanya tidak hilang; protokol ini tidak dapat menyelamatkan data yang berada di dalam paket yang hilang tersebut. Stream C yang tidak bergantung pada paket tersebut dapat terus berjalan.

Pertanyaan Lanjutan 2: Jika congestion window dibagi bersama, apakah B benar-benar “tidak terpengaruh”?

Jawab dalam dua dimensi. Data B yang berurutan dapat langsung dikirimkan tanpa menunggu retransmission A. Namun, loss tetap dapat memicu congestion control bersama dan membuat data B berikutnya tiba lebih lambat. Yang pertama adalah kebenaran logika pengiriman (delivery correctness); yang kedua adalah performance coupling.

Pertanyaan Lanjutan 3: Apakah QPACK memperkenalkan kembali head-of-line blocking?

Protokol ini dapat menciptakan penundaan decoding header yang terkendali. Stream permintaan akan menunggu ketika blok headernya mereferensikan entri tabel dinamis yang belum tiba. Ini bukan satu celah byte TCP yang merambat ke semua stream. Penerima mendeklarasikan batas blocked-stream, dan encoder dapat menghindari referensi yang belum diakui dengan menerima efisiensi kompresi yang lebih rendah.

Pertanyaan Lanjutan 4: Bisakah beberapa koneksi TCP HTTP/2 menyelesaikan masalah ini?

Cara ini dapat membatasi satu TCP loss hanya pada permintaan-permintaan dalam satu koneksi tersebut. Namun, setiap koneksi membawa biaya inisiasi, TLS, buffering, dan status kemacetan, serta beberapa controller akan bersaing pada jalur yang sama. Keputusan ini bergantung pada penggunaan ulang (reuse), tata letak origin, dan kondisi jaringan; ini bukan alternatif cuma-cuma yang setara dengan stream QUIC.

Pertanyaan Lanjutan 5: Mengapa tidak menambahkan stream ID langsung ke TCP?

Hal itu akan mengubah antarmuka byte stream berurutan tunggal yang telah lama disediakan TCP dan akan menghadapi masalah kompatibilitas pada sistem operasi, middlebox, dan deployment. QUIC mengimplementasikan semantik transport termultipleks yang aman dan baru di user space di atas UDP, sehingga mengurangi kendala evolusi tersebut. Protokol ini tetap menyediakan keandalan dan congestion control; perbedaannya terletak pada unit pengirimannya.

Pertanyaan Lanjutan 6: Pengujian terkontrol tidak menunjukkan peningkatan kecepatan pada HTTP/3. Apakah teorinya salah?

Tidak. Jika pengujian tidak memicu blocking TCP lintas stream pada HTTP/2, isolasi stream tidak akan mendominasi total waktu. Periksa apakah terjadi fallback ke HTTP/2, UDP yang dibatasi, penggunaan ulang koneksi, biaya CPU implementasi, algoritma kemacetan, dan antrean server. Buktikan perilaku protokol dengan bukti pengiriman per stream dan buat klaim performa hanya di bawah kondisi yang dinyatakan dan dapat diulang.