Konteks dan pertanyaan
Sebuah layanan mengaktifkan TLS 1.3 0-RTT untuk mengurangi latensi first-byte pada koneksi yang dilanjutkan (resumed). Beberapa permintaan tiba sebelum jabat tangan (handshake) selesai, dan early data dapat di-replay pada koneksi lain. Jelaskan kapan API harus mengembalikan 425 Too Early, bagaimana klien mencoba kembali, dan bagaimana gateway serta setiap replika layanan tetap konsisten.
Ini cocok untuk wawancara backend, jaringan, infrastruktur, dan keamanan. Ujiannya bukan menghafal kode status. Ini tentang memetakan risiko replay tingkat transport ke efek samping aktual suatu sumber daya, kemudian menentukan batasan antara 425, penundaan (deferral), menonaktifkan early data, kunci idempoten, dan bukti audit.
Apa yang diuji oleh pewawancara
Jawaban yang kuat menyatakan bahwa 425 berarti server tidak akan mengambil risiko memproses permintaan yang mungkin di-replay. Ini bukan kesalahan kelebihan beban (overload) umum, autentikasi, atau validasi bisnis. Jawaban tersebut membedakan metode aman dari sumber daya dengan efek samping, menjelaskan mengapa hanya origin yang tahu apakah suatu sumber daya mentolerir early data, dan mencakup header Early-Data, percobaan ulang klien, penerusan gateway, serta konsistensi replika. Ini juga membahas badai percobaan ulang (retry storm), state bersama, dan efek yang tidak dapat dibatalkan (irreversible).
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah permintaan benar-benar tiba dalam early data, atau membawa
Early-Data: 1tepercaya? - Apakah operasi mengubah state, menagih biaya, mengirim pesanan, mengirim pesan, atau memicu efek samping eksternal?
- Bisakah klien mencoba kembali dengan aman setelah handshake, dengan kunci idempoten dan penyimpanan deduplikasi?
- Apakah gateway memahami 425 dan Early-Data, dan apakah semua replika origin berbagi satu kebijakan?
- Bagaimana resumption, beban, batas waktu (timeout), dan anggaran percobaan ulang memengaruhi keamanan dan ketersediaan?
Jawaban 30 detik
"425 adalah penolakan keamanan untuk permintaan early-data yang mungkin di-replay, bukan rate limiting umum. Origin memilih berdasarkan risiko sumber daya: permintaan bebas efek samping atau yang terbukti idempoten dapat dilanjutkan atau ditunda, sementara penagihan, penulisan, dan tindakan yang tidak dapat dibatalkan harus menunggu handshake dan dapat menerima 425. Klien yang menerima 425 hanya mencoba kembali setelah handshake; gateway mempertahankan sinyal, setiap replika menerapkan kebijakan yang sama, serta kunci idempoten ditambah deduplikasi sisi server melindungi permintaan berulang."
Jawaban langkah demi langkah
Langkah 1: Identifikasi early data dan model replay
TLS 1.3 0-RTT memungkinkan klien mengirim data aplikasi sebelum handshake selesai. Handshake yang selesai hanya memberi tahu Anda tentang data pada koneksi tersebut; itu tidak membuktikan koneksi lain tidak menerima byte yang sama. Oleh karena itu, layanan tidak dapat menyimpulkan keunikan dari koneksi yang berhasil.
Langkah 2: Klasifikasikan efek samping sumber daya
Origin mengetahui konsekuensi replay untuk suatu sumber daya. Operasi baca, kueri, dan operasi tanpa perubahan state sering kali berisiko lebih rendah, tetapi verifikasi bahwa jalur penagihan dan audit tidak memiliki operasi tulis tersembunyi. Membuat pesanan, menagih kartu, menerbitkan kredit, mengubah izin, dan mengirim pesan dapat dieksekusi dua kali; tolak atau tunda hingga handshake selesai.
Langkah 3: Pilih penundaan, penolakan, atau penonaktifan 0-RTT
RFC 8470 menjelaskan penolakan early data pada tingkat TLS, menunggu handshake sebelum memproses, atau mengembalikan 425 sehingga klien mencoba kembali nanti. Semuanya mengurangi risiko replay; pilihan bergantung pada kebijakan sumber daya, anggaran memori, perilaku klien, dan beban. Jangan gunakan 425 sebagai pengganti setiap kegagalan handshake.
Langkah 4: Keluarkan 425 dengan benar
Ketika sebuah permintaan tiba dalam early data atau membawa Early-Data: 1 dan tidak dapat diproses dengan aman, origin mengembalikan 425. Kode ini tidak dapat di-cache secara default, dan payload-nya bukan merupakan representasi dari sumber daya yang diidentifikasi. Jangan mengeluarkan 425 ketika klien tidak dapat mencoba kembali atau ketika permintaan tersebut bukan early data, karena pemulihan mungkin menjadi mustahil.
Langkah 5: Tentukan batasan percobaan ulang klien
Klien yang menggunakan early data diharapkan mencoba kembali setelah menerima 425, tetapi percobaan ulang tersebut tidak boleh menggunakan early data lagi. Pertahankan semantik permintaan, batasi percobaan, terapkan backoff, dan patuhi pembatalan serta batas waktu. Jika permintaan itu sendiri tidak dapat dicoba kembali dengan aman, laporkan kegagalan ke pemanggil alih-alih me-replay tanpa batas.
Langkah 6: Teruskan sinyal melalui gateway
Gateway biasanya tidak dapat mengetahui apakah sumber daya tertentu menerima early data. Saat meneruskan permintaan yang mungkin telah di-replay, gateway harus mempertahankan atau menambahkan Early-Data: 1; jangan menghapus sinyal tersebut. Jika origin tidak mendukung mekanisme ini, tunggu handshake atau tolak. Gateway dapat mencoba kembali atas nama klien hanya jika keamanannya diketahui secara eksplisit.
Langkah 7: Jaga konsistensi replika
Setiap replika origin, node edge, dan worker asinkron memerlukan kebijakan early-data yang sama. Jika satu replika menunda sementara yang lain menagih secara instan, penyerang atau perbedaan jalur dapat menciptakan efek duplikat. Bagikan versi kebijakan, kunci idempoten, catatan deduplikasi, dan field yang dapat diobservasi di seluruh replika.
Langkah 8: Uji perilaku percobaan ulang dan kelebihan beban
Uji handshake lengkap, replay ke replika lain, permintaan yang tiba sebagian sebelum handshake, penerusan gateway, timeout klien, dan beban berlebih pada server. Catat rasio early-data, rasio 425, percobaan ulang, kunci duplikat, efek duplikat, dan pertumbuhan antrean. Di bawah beban tinggi, respons 425 atau 503 yang berulang dapat memperkuat percobaan ulang, jadi tetapkan anggaran dan pastikan mampu menonaktifkan 0-RTT secara global.
Pertukaran (trade-offs) dan batasan
0-RTT mengurangi waktu tunggu first-byte pada koneksi yang dilanjutkan, tetapi memerlukan analisis replay, kebijakan yang konsisten, dan deduplikasi. Nama metode saja tidak cukup: metode yang secara nominal aman masih dapat menulis ke status penagihan, audit, atau cache. Kebijakan tingkat sumber daya lebih dapat diandalkan.
Kunci idempoten mengurangi efek duplikat tetapi tidak membuat setiap permintaan cocok untuk early data. State deduplikasi membutuhkan periode retensi yang berguna, visibilitas lintas replika, dan perilaku yang terdefinisi untuk tabrakan kunci, kedaluwarsa percobaan ulang, dan kegagalan penyimpanan. Untuk tindakan yang tidak dapat dibatalkan, menunggu handshake sering kali lebih jelas daripada mengandalkan kompensasi yang rumit.
Rencana peluncuran dan bukti
Daftarkan kebijakan early-data untuk setiap sumber daya: izinkan, tunda, atau 425. Tambahkan kunci idempoten dan deduplikasi untuk penulisan, minta gateway menyebarkan Early-Data, dan catat status koneksi, versi kebijakan, serta korelasi percobaan ulang di origin. Jalankan latihan replay lintas replika dan verifikasi bahwa pesanan, penagihan, dan pesan tidak terduplikasi.
Setelah peluncuran, amati metrik 425, percobaan ulang, dan efek samping berdasarkan sumber daya dan versi klien. Jika klien melanggar aturan percobaan ulang, perbaiki klien atau nonaktifkan 0-RTT di edge alih-alih melemahkan perlindungan origin. RFC 8470 memerlukan penanganan gateway dan origin yang konsisten, sehingga pemeriksaan rilis harus mencakup setiap jalur ingress.
Kesalahan umum dan tindak lanjut
Memperlakukan 425 sebagai rate limiting atau kelebihan beban
425 menargetkan permintaan early-data yang mungkin di-replay. Konkurensi tinggi, dependensi yang tidak tersedia, dan pelanggaran kuota memiliki semantik dan perilaku backoff yang berbeda.
Mengembalikan 425 untuk setiap POST
Metode hanyalah sebuah petunjuk. Putuskan berdasarkan toleransi replay sumber daya serta idempoten dan deduplikasi yang andal. Penulisan yang terbukti idempoten dapat ditunda atau ditangani oleh kebijakan khusus sumber daya.
Mencoba kembali 425 dengan 0-RTT lagi
RFC 8470 mewajibkan percobaan ulang setelah 425 menghindari early data. Jika tidak, klien mengubah perlindungan server menjadi peluang replay lainnya.
Menghapus header Early-Data di gateway
Menghapus sinyal membuat origin percaya bahwa permintaan tersebut tidak melintasi early data. Pertahankan atau tambahkan header, verifikasi dukungan origin untuk 425, dan tunggu handshake jika ragu.
Bagaimana Anda membuktikan tidak ada penagihan ganda?
Jalankan latihan replay dengan kunci idempoten lintas replika, fingerprint permintaan, dan state machine penagihan, lalu verifikasi satu hasil bisnis akhir per operasi. Uji juga kegagalan penyimpanan deduplikasi, percobaan ulang klien setelah timeout, dan pengiriman hilir (downstream) duplikat; kode status HTTP saja bukan merupakan bukti.