Topik wawancara representatif

Wawancara backend: Bagaimana cara meluncurkan HTTP 103 melalui CDN dan proxy?

BackendSedang
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Origin sudah dapat memancarkan HTTP 103. Bagaimana Anda akan memvalidasi terminator TLS, reverse proxy, CDN, dan peramban, merancang fallback dan observabilitas, serta memperluas lalu lintas dengan aman?

Petunjuk dan konteks

Origin dapat memancarkan 103 dengan Link sebelum respons akhir, tetapi lalu lintas produksi masih melintasi terminator TLS, load balancer, reverse proxy, dan CDN. Rancang matriks kompatibilitas end-to-end, sakelar canary, fallback transparan, dan rencana observabilitas yang membuktikan respons 1xx mencapai peramban yang didukung.

Hal yang diuji oleh pewawancara

Jawaban yang kuat membedakan respons sementara dari respons akhir, memilih sumber daya berkeyakinan tinggi, membahas HTTP/2, HTTP/3, proxy, dan CDN, serta menyediakan fallback transparan saat 103 diabaikan. Mereka juga mencakup petunjuk yang salah, risiko cache dan lintas-asal (cross-origin), serta pengukuran manfaat nyata bagi pengguna.

Pertanyaan untuk diklarifikasi

  • Seberapa awal dan seberapa yakin server dapat mengetahui kumpulan sumber daya tersebut?
  • Apakah klien, terminator TLS, reverse proxy, dan CDN mempertahankan respons 1xx?
  • Apakah sumber daya diberi versi, dan apakah preconnect lintas-asal diperlukan?
  • Apakah targetnya adalah LCP, jeda pasca-TTFB, atau penemuan CSS dan font yang lebih awal?
  • Bagaimana kesalahan, cache hit, dan klien tanpa 103 diamati dan ditangani?

Jawaban 30 detik

Sebelum respons akhir, saya akan mengirimkan 103 dengan sekumpulan kecil petunjuk Link berkeyakinan tinggi, lalu mengirimkan respons akhir yang normal. Sumber daya menggunakan URL berversi dan koneksi lintas-asal dibatasi pada domain tepercaya. Mengabaikan 103 harus tetap membuat halaman benar karena HTML akhir masih mereferensikan sumber daya. Saya akan membandingkan jalur yang didukung dan tidak didukung menggunakan trace dan RUM untuk LCP, waktu penemuan, duplikasi bita, dan kesalahan sebelum memperluas cakupan.

Jawaban mendalam langkah demi langkah

Langkah 1: Pahami waktu (timing)

103 adalah respons sementara yang bersifat informasional dan harus diikuti oleh respons akhir. Ini dapat membawa petunjuk seperti Link: </app.css>; rel=preload; as=style saat server sedang bekerja. Apakah klien menindaklanjutinya bergantung pada tumpukan protokol, peramban, dan kebijakan; kebenaran bisnis tidak boleh bergantung padanya.

Langkah 2: Pilih sumber daya

Hanya berikan petunjuk untuk sumber daya yang hampir pasti, berukuran wajar, dan stabil: CSS kritis, font, atau preconnect. Hindari gambar dengan probabilitas rendah, skrip yang dipersonalisasi, dan aset yang bergantung pada izin yang membuang-buang bandwidth atau melakukan prefetch hal yang salah.

http
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

Langkah 3: Verifikasi perantara dan fallback

Uji jalur load balancer, terminasi TLS, CDN, dan peramban yang sebenarnya untuk meneruskan atau mengonsumsi 103. Klien yang mengabaikannya harus tetap menerima referensi biasa dalam respons akhir; jangan pernah membuat halaman bergantung pada pesan sementara.

Langkah 4: Batasi efek cache dan keamanan

Petunjuk harus cocok dengan konteks permintaan saat ini. Gunakan URL dengan hash konten dan Cache-Control yang benar; jangan pernah membuat nilai Link sembarangan dari input pengguna. preconnect lintas-asal mengungkapkan niat koneksi dan menghabiskan sumber daya, jadi izinkan hanya asal yang tepercaya dan parameter yang diperlukan.

Langkah 5: Hindari preload yang salah

Jika autentikasi, eksperimen, atau geografi mengubah kumpulan sumber daya, tunggu hingga keyakinan lebih tinggi atau hilangkan petunjuk tersebut. Jika respons akhir tidak lagi mereferensikan sumber daya yang diisyaratkan, peramban mungkin telah membuang-buang unduhan; ukur biaya tersebut.

Langkah 6: Amati dan lakukan rollback

Catat apakah 103 dikirim, status akhir, waktu penemuan, cache hit, duplikasi bita, dan perbedaan berdasarkan proxy. Kendalikan peluncuran berdasarkan rute atau lalu lintas dengan feature flag. Nonaktifkan petunjuk jika bandwidth, kesalahan, atau metrik pengguna memburuk; HTML akhir tetap tidak berubah.

Trade-off dan batasan

103 versus tautan preload

103 memindahkan petunjuk lebih awal, sementara link HTML biasa tetap menjadi referensi otoritatif akhir. Keduanya harus selaras untuk menghindari pengunduhan ganda atau konflik prioritas. Petunjuk tidak menggantikan CSP, integritas, atau kebijakan izin.

Versi protokol dan perantara

RFC 8297 mendefinisikan semantiknya, tetapi rantai proxy dapat membuang respons 1xx. Ukur kombinasi nyata HTTP/2, HTTP/3, CDN, dan klien serta pertahankan baseline tanpa 103.

Rencana peluncuran dan bukti

Rilis bertahap

Mulai dengan CSS statis pada satu rute, verifikasi respons akhir dan referensinya, lalu perluas ke font atau preconnect yang aman. Pertahankan tombol pemutus (kill switch) dan bandingkan kunjungan pertama, kunjungan dari cache, dan jaringan lambat secara terpisah.

Metrik dan penerimaan

Lacak LCP, waktu penemuan sumber daya, duplikasi bita, rasio cache hit, 4xx/5xx, dan bandwidth. Rekonsiliasikan alat peramban, log edge, dan RUM; log pengiriman server saja tidak dapat membuktikan perilaku klien.

Kesalahan umum dan tindak lanjut

Kesalahan: memperlakukan 103 sebagai keberhasilan akhir

Status bisnis, caching, dan kesalahan menggunakan respons akhir; kehilangan 103 tidak boleh menggagalkan permintaan.

Kesalahan: memberi petunjuk untuk setiap sumber daya

Aset berkeyakinan rendah membuang-buang bandwidth dan koneksi. Lebih baik pilih kumpulan kritis yang kecil dan stabil.

Kesalahan: hanya menguji jalur lokal langsung

CDN produksi, proxy, dan terminasi TLS dapat mengubah perilaku 1xx; uji secara end-to-end.

Tindak lanjut: bagaimana jika 103 tidak didukung?

Andalkan referensi HTML akhir biasa dan caching yang ada. Kebenaran fungsional tetap terjaga; hanya potensi peningkatan kinerja yang hilang.

Tindak lanjut: bagaimana Anda membuktikan bahwa ini layak dipertahankan?

Jalankan eksperimen terpisah (split experiment) untuk LCP, penemuan, duplikasi bita, kesalahan, dan bandwidth, yang disegmentasikan berdasarkan kondisi cache dan jaringan.

Sumber publik

Pertanyaan terkait