Wawancara Backend: Bagaimana Anda Merancang Penjadwalan Prioritas HTTP?

Konteks dan penerapan

Sebuah halaman meminta HTML, CSS kritis, font, gambar, dan data latar belakang secara bersamaan. Bandwidth seluler terbatas. Tim ingin sumber daya kritis selesai lebih awal dengan HTTP Priority, namun khawatir tentang penimpaan (override) oleh proksi, starvation, cache hit yang melewati penjadwalan aplikasi, dan transmisi ulang akibat kehilangan paket yang mengubah urutan. Rancang penjadwalan server dan proksi di seluruh HTTP/1.1, HTTP/2, dan HTTP/3, termasuk validasinya.

RFC 9218 mendefinisikan header Priority yang independen dari versi dan frame reprioritisasi untuk HTTP/2 dan HTTP/3. Spesifikasi ini mengomunikasikan preferensi, bukan SLA pengiriman. Jawaban yang kuat memisahkan sinyal, penjadwal (scheduler), cache, dan transport, serta menyatakan apa yang dapat ditolak atau ditulis ulang oleh setiap lapisan.

Hal yang diuji oleh pewawancara

• Mengetahui bahwa urgency berkisar antara 0 hingga 7, dengan nilai lebih kecil berarti lebih mendesak dan nilai permintaan default adalah 3.
• Menjelaskan bagaimana incremental mengubah konkurensi dan waktu penyelesaian untuk sumber daya dengan urgency yang sama.
• Membedakan pengurutan permintaan HTTP/1.1 dari penjadwalan termultipleks pada HTTP/2 dan HTTP/3.
• Memperlakukan Priority sebagai petunjuk (hint) alih-alih SLA dan menangani deklarasi klien yang salah atau berbahaya.
• Mempertimbangkan cache hit, reprioritisasi proksi, transmisi ulang QUIC, keadilan, dan kompetisi antar-koneksi.
• Merancang peluncuran bertahap (rollout) yang dapat dibatalkan (reversible) dengan metrik pengalaman pengguna dan keadilan.

Klarifikasi yang perlu ditanyakan terlebih dahulu

1. Apakah tujuannya adalah LCP yang lebih rendah, latensi ekor (tail latency) yang lebih rendah untuk satu API, atau throughput latar belakang yang lebih tinggi? Masing-masing mengubah kebijakan dan metrik.
2. Apakah sumber daya berada pada satu koneksi, node CDN, dan kunci cache yang sama? Prioritas koneksi tunggal tidak dapat dibandingkan secara langsung lintas koneksi.
3. Sumber daya mana yang dapat diproses secara bertahap (inkremental)? CSS lengkap, font, dan objek terkompresi yang tidak dapat dikonsumsi per bagian tidak boleh dipecah hanya karena urgency-nya tinggi.
4. Apakah proksi meneruskan header permintaan dan respons serta PRIORITY_UPDATE? Apakah setiap hop menggunakan HTTP/2 atau HTTP/3?
5. Apakah ada batasan tenant, pengguna, atau keamanan yang mencegah permintaan bernilai rendah mengklaim prioritas tertinggi?

Jawaban 30 detik

Saya akan mendefinisikan target sebagai waktu penyelesaian yang terlihat oleh pengguna dan mengklasifikasikan sumber daya dengan nilai default. Header Priority dari klien adalah masukan; server menghitung ulang menggunakan tipe sumber daya, status cache, koneksi, dan keadilan. Urgency dari 0 hingga 7 memberikan urutan relatif, sedangkan incremental digunakan untuk respons yang dapat dikonsumsi saat byte tiba. HTTP/1.1 mengandalkan urutan permintaan koneksi; HTTP/2 dan HTTP/3 menggunakan penjadwal dan, jika didukung, frame reprioritisasi. Cache hit, transmisi ulang, dan bandwidth antar-koneksi memerlukan penanganan terpisah. Dalam canary, saya akan melacak LCP, penyelesaian sumber daya kritis, tail latensi latar belakang, starvation, dan bandwidth, serta menonaktifkan penulisan ulang jika batas pengaman (guardrails) gagal.

Pembahasan mendalam langkah demi langkah

1. Mengubah tujuan produk menjadi tujuan penjadwalan

HTML, CSS pemblokir perenderan (render-blocking), dan font kritis harus selesai lebih awal. Gambar besar dapat memiliki urgency lebih rendah; analitik dan prefetch tidak boleh bersaing dengan jalur kritis. API latar belakang tetap memerlukan batas tunggu maksimum. Berikan setiap kelas batas tunggu dan pembagian bandwidth daripada hanya mengatakan bahwa permintaan kritis berjalan lebih dulu.

2. Menjelaskan dua parameter Priority

u adalah urgensi: 0 adalah yang tertinggi dan 7 terendah, dengan nilai permintaan default adalah 3. i menyatakan bahwa respons dapat diproses secara bertahap. Dengan i, server dapat membagi bandwidth di antara sumber daya dengan urgency yang sama sehingga semuanya dimulai lebih cepat, meskipun masing-masing dapat selesai lebih lambat. Tanpa parameter ini, pengiriman berurutan biasanya lebih baik untuk objek yang tidak dapat dikonsumsi sebagian.

GET /style.css HTTP/1.1
Host: example.test
Priority: u=1

GET /hero.jpg HTTP/1.1
Host: example.test
Priority: u=4, i

Respons server juga dapat mengirimkan petunjuk prioritas ke perantara downstream. Mengabaikan header respons berarti server tidak mengubah prioritas klien. Parameter yang tidak dikenal harus diabaikan; nilai klien bukan merupakan kredensial otorisasi atau penagihan.

3. Memilih batasan berdasarkan versi protokol

HTTP/1.1 tidak memiliki prioritas termultipleks bawaan; perilaku server terutama mengikuti urutan koneksi, konkurensi koneksi, dan antrean. HTTP/2 dan HTTP/3 berbagi bandwidth pada satu koneksi termultipleks, sehingga penjadwal dapat memilih segmen data berikutnya menggunakan urgency dan incremental. Keduanya dapat mengubah preferensi permintaan yang ada dengan mekanisme PRIORITY_UPDATE, namun implementasi tidak menjanjikan eksekusi langsung atau ketat.

4. Menangani cache dan proksi

Cache hit dapat dikembalikan tanpa mencapai penjadwalan aplikasi asal (origin). Pertahankan efek prioritas pada tahap transmisi dan pengisian cache; header Priority normal tidak boleh mengubah otorisasi objek atau diam-diam menjadi kunci cache. Proksi dapat menggabungkan koneksi klien, menggunakan koneksi backend yang berbeda, atau menulis ulang prioritas respons. Catat nilai asli, nilai akhir, dan alasannya di setiap batas. Perilaku cache tetap diatur oleh bidang seperti Cache-Control dan Vary.

5. Menangani transmisi ulang dan keadilan

QUIC dan TCP mentransmisikan ulang data yang hilang. Objek baru dengan urgency tinggi tidak boleh secara otomatis mengalahkan transmisi ulang ber-urgency rendah, karena transmisi ulang dapat membuka blokir respons yang sedang berlangsung. RFC 9218 menyerahkan kompromi ini pada kebijakan transport dan aplikasi. Lintas koneksi, u=0 pada satu koneksi tidak dapat menjamin bandwidth global tertinggi. Tambahkan kuota per koneksi, penuaan (aging), dan anggaran pengiriman berturut-turut maksimum sehingga pekerjaan latar belakang tidak mengalami starvation selamanya.

6. Mencegah penyalahgunaan prioritas dan kesalahan propagasi

Klien dapat melabeli setiap permintaan dengan u=0, sehingga server harus memperbaikinya menggunakan daftar izin sumber daya, identitas terautentikasi, fase halaman, dan riwayat. Batasi urgency maksimum, terapkan kuota tenant, gunakan nilai default untuk sumber daya yang tidak dikenal, dan catat penimpaan. Lintas proksi, pertahankan makna daripada menyalin string secara membabi buta. Hop yang tidak memahami sinyal harus mengabaikannya dengan aman tanpa mengubah kebenaran respons.

7. Canary, fallback, dan penerimaan

Mulai dengan halaman tetap dan node CDN berisiko rendah, mengaktifkan penulisan ulang server untuk sebagian kecil koneksi. Bandingkan jaringan, perangkat, status cache, dan kumpulan sumber daya yang sama. Ukur LCP, penyelesaian CSS kritis, waktu pemblokiran font, p95 dan p99 latar belakang, time to first byte, unduhan duplikat, utilisasi koneksi, dan waktu tunggu maksimum prioritas rendah. Peningkatan harus ditimbang terhadap kesalahan, biaya bandwidth, dan keadilan lintas tenant. Segera pulihkan prioritas default jika perilaku penjadwal tidak normal.

Contoh jawaban berkualitas tinggi

Saya akan menentukan penyelesaian first-paint dan target permintaan latar belakang, kemudian mengklasifikasikan HTML, CSS render-blocking, font, media inkremental, dan data latar belakang. Header Priority dari klien hanyalah petunjuk. Saya akan mengoreksinya menggunakan daftar izin sumber daya, fase halaman, status cache, dan kuota tenant: gunakan urgency 3 sebagai default, turunkan nilainya untuk sumber daya kritis, naikkan untuk pekerjaan latar belakang, dan gunakan incremental hanya jika konsumen dapat memproses data parsial.

HTTP/1.1 sebagian besar bergantung pada urutan koneksi dan antrean. HTTP/2 dan HTTP/3 menggunakan penjadwal termultipleks dan frame reprioritisasi opsional. Cache hit tidak boleh mengubah otorisasi atau kunci cache, dan proksi harus mencatat prioritas asli serta akhir. Transmisi ulang tidak boleh secara otomatis kalah dari data baru, jadi saya akan menambahkan kuota koneksi, aging, dan batas pengiriman berturut-turut. Rilis canary membandingkan LCP, penyelesaian kritis, tail latar belakang, bandwidth, dan waktu tunggu prioritas rendah; batas pengaman yang memburuk akan menonaktifkan penulisan ulang server.

Kesalahan umum

• Memperlakukan Priority: u=0 sebagai SLA penyelesaian → kongesti, status cache, dan transmisi ulang tetap berpengaruh → gunakan sebagai masukan penjadwal dengan target yang terukur.
• Memperlakukan incremental sebagai "selesai lebih cepat" → berbagi bandwidth dapat menunda penyelesaian masing-masing objek → gunakan hanya jika konsumsi parsial memiliki nilai.
• Membiarkan prioritas klien mengubah kunci cache atau otorisasi → fragmentasi cache atau kesalahan hak akses akan terjadi → jaga kontrak cache dan izin tetap independen.
• Hanya menganalisis satu koneksi HTTP/2 → persaingan lintas koneksi dapat membalikkan hasil → bagi validasi berdasarkan koneksi, node, jaringan, dan tenant.
• Membiarkan transmisi ulang prioritas tinggi selalu mengalahkan data lain → respons baru atau stream latar belakang dapat mengalami starvation → sertakan kebijakan transmisi ulang, kuota, dan aging.
• Hanya melihat LCP → tail latar belakang dan biaya bandwidth dapat memburuk → tetapkan batas pengaman pengguna, keandalan, keadilan, dan biaya secara bersamaan.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika setiap klien mengirim u=0?

Perlakukan sebagai petunjuk yang tidak tepercaya. Hitung ulang menggunakan tipe sumber daya, fase halaman, identitas terautentikasi, dan kuota tenant; kembalikan permintaan yang tidak normal atau tidak dikenal ke default dan catat mengapa permintaan tersebut ditimpa.

Apakah incremental selalu meningkatkan pengalaman pengguna?

Tidak. Parameter ini membagi bandwidth di antara respons dengan urgency yang sama, membuat beberapa respons mulai lebih awal sementara masing-masing dapat selesai lebih lambat. Gunakan jika konsumen dapat memproses byte parsial dan manfaat waktu mulai tersebut penting.

Apakah Priority diperlukan untuk cache hit?

Hit biasanya melewati antrean aplikasi asal, tetapi proksi mungkin masih menjadwalkan transmisi pada suatu koneksi. Priority tidak boleh masuk ke otorisasi atau mengubah kunci cache secara sembarangan; amati tahap hit, pengisian (fill), dan pengiriman secara terpisah.

Haruskah transmisi ulang atau data baru ber-urgency tinggi didahulukan setelah terjadi kehilangan paket?

Tidak ada jawaban tunggal untuk semua konteks. Transmisi ulang dapat membuka blokir respons yang sedang berlangsung, sementara data baru mungkin lebih penting bagi pengguna. Gabungkan dependensi stream, kemampuan inkremental, status kongesti, dan tujuan pengalaman yang terukur.

Bisakah HTTP/1.1 menerapkan prioritas yang sama?

HTTP/1.1 tidak memiliki pohon prioritas termultipleks seperti HTTP/2. Antrean server, konkurensi koneksi, dan pengurutan sumber daya dapat mendekati kebijakan tersebut, tetapi ini tetap merupakan strategi implementasi yang harus diuji terhadap head-of-line blocking dan persaingan koneksi.

Bagaimana Anda membuktikan bahwa pekerjaan berprioritas rendah tidak mengalami starvation?

Catat waktu antrean dan waktu pengiriman pertama untuk setiap permintaan, lalu hitung waktu tunggu maksimum dan p99 berdasarkan sumber daya, koneksi, dan tenant. Di bawah beban urgency tinggi yang berkelanjutan, verifikasi bahwa aging, kuota, atau batas waktu tetap memungkinkan pekerjaan berprioritas rendah menerima layanan.