Gesaan dan konteks
Sebuah perkhidmatan mendayakan TLS 1.3 0-RTT untuk mengurangkan kependaman bait pertama pada sambungan yang disambung semula (resumed). Sesetengah permintaan tiba sebelum jabat tangan (handshake) selesai, dan data awal (early data) boleh di-replay pada sambungan lain. Terangkan bilakah API patut mengembalikan 425 Too Early, bagaimana klien mencuba semula, dan bagaimana get laluan serta setiap replika perkhidmatan kekal konsisten.
Ini sesuai untuk temu duga bahagian belakang (backend), rangkaian, infrastruktur, dan keselamatan. Ujian ini bukan tentang menghafal kod status. Ia tentang memetakan risiko replay pada peringkat pengangkutan kepada kesan sampingan sebenar sesuatu sumber, kemudian mentakrifkan sempadan antara 425, penangguhan (deferral), melumpuhkan early data, kunci keidempoteman, dan bukti audit.
Perkara yang diuji oleh penemu duga
Jawapan yang mantap menyatakan bahawa 425 bermakna pelayan tidak akan mengambil risiko memproses permintaan yang mungkin di-replay. Ia bukan ralat beban lampau (overload) umum, pengesahan identiti, atau pengesahan perniagaan. Jawapan tersebut membezakan kaedah selamat daripada sumber yang memberi kesan sampingan, menerangkan mengapa hanya origin yang tahu sama ada sesuatu sumber bertolak ansur dengan early data, dan merangkumi pengepala Early-Data, percubaan semula klien, pemajuan get laluan, serta konsistensi replika. Ia juga menangani ribut percubaan semula (retry storms), keadaan kongsi (shared state), dan kesan yang tidak dapat dipulihkan (irreversible).
Soalan untuk dijelaskan terlebih dahulu
- Adakah permintaan itu benar-benar tiba dalam early data, atau adakah ia membawa
Early-Data: 1yang dipercayai? - Adakah operasi itu mengubah keadaan, mengenakan caj wang, menghantar pesanan, menghantar mesej, atau mencetuskan kesan sampingan luaran?
- Bolehkah klien mencuba semula dengan selamat selepas handshake, dengan kunci keidempoteman dan stor penyahduplikasian?
- Adakah get laluan memahami 425 dan Early-Data, dan adakah semua replika origin berkongsi satu dasar yang sama?
- Bagaimanakah penyambungan semula, beban, had masa tamat (timeouts), dan belanjawan percubaan semula menjejaskan keselamatan serta ketersediaan?
Jawapan 30 saat
"425 ialah penolakan keselamatan untuk permintaan early-data yang mungkin di-replay, bukan pengehadan kadar (rate limiting) umum. Origin memilih mengikut risiko sumber: permintaan tanpa kesan sampingan atau yang terbukti idempoten boleh diteruskan atau ditangguhkan, manakala pengecasan, operasi tulis, dan tindakan yang tidak boleh dipulihkan harus menunggu handshake dan mungkin menerima 425. Klien yang menerima 425 mencuba semula hanya selepas handshake; get laluan mengekalkan isyarat, setiap replika menggunakan dasar yang sama, dan kunci keidempoteman serta penyahduplikasian bahagian pelayan melindungi permintaan berulang."
Jawapan langkah demi langkah
Langkah 1: Kenal pasti early data dan model replay
TLS 1.3 0-RTT membolehkan klien menghantar data aplikasi sebelum handshake selesai. Handshake yang selesai hanya memberitahu anda tentang data pada sambungan tersebut; ia tidak membuktikan sambungan lain tidak menerima bait yang sama. Oleh itu, perkhidmatan tidak boleh membuat kesimpulan keunikan daripada sambungan yang berjaya.
Langkah 2: Kelaskan kesan sampingan sumber
Origin mengetahui akibat replay bagi sesuatu sumber. Operasi baca, pertanyaan (queries), dan operasi tanpa perubahan keadaan selalunya berisiko lebih rendah, tetapi sahkan bahawa laluan pengebilan dan audit tidak mempunyai operasi tulis tersembunyi. Membuat pesanan, mengenakan caj kad, mengeluarkan kredit, menukar kebenaran, dan menghantar mesej boleh dilaksanakan dua kali; tolak atau tangguhkan sehingga handshake selesai.
Langkah 3: Pilih penangguhan, penolakan, atau melumpuhkan 0-RTT
RFC 8470 menerangkan penolakan early data pada TLS, menunggu handshake sebelum memproses, atau mengembalikan 425 supaya klien mencuba semula kemudian. Kesemuanya mengurangkan risiko replay; pilihan bergantung pada dasar sumber, belanjawan memori, tingkah laku klien, dan beban. Jangan gunakan 425 sebagai pengganti bagi setiap kegagalan handshake.
Langkah 4: Keluarkan 425 dengan betul
Apabila permintaan tiba dalam early data atau membawa Early-Data: 1 dan tidak dapat diproses dengan selamat, origin mengembalikan 425. Ia tidak boleh dicache secara lalai, dan muatan (payload) miliknya bukan perwakilan bagi sumber yang dikenal pasti. Jangan keluarkan 425 apabila klien tidak dapat mencuba semula atau apabila permintaan tersebut bukan early data, kerana pemulihan mungkin mustahil.
Langkah 5: Takrifkan sempadan percubaan semula klien
Klien yang menggunakan early data dijangka mencuba semula selepas 425, tetapi percubaan semula tersebut tidak boleh menggunakan early data lagi. Kekalkan semantik permintaan, hadkan percubaan, gunakan backoff, dan hormati pembatalan serta batas masa. Jika permintaan itu sendiri tidak boleh dicuba semula dengan selamat, laporkan kegagalan kepada pemanggil dan bukannya melakukan replay tanpa henti.
Langkah 6: Majukan isyarat melalui get laluan
Get laluan biasanya tidak dapat mengetahui sama ada sumber tertentu menerima early data. Semasa memajukan permintaan yang mungkin telah di-replay, ia mesti mengekalkan atau menambah Early-Data: 1; ia tidak boleh membuang isyarat tersebut. Jika origin tidak menyokong mekanisme ini, tunggu handshake atau tolak. Get laluan boleh mencuba semula bagi pihak klien hanya apabila keselamatan diketahui secara eksplisit.
Langkah 7: Pastikan replika kekal konsisten
Setiap replika origin, nod pinggir (edge), dan pekerja tak segerak (asynchronous worker) memerlukan dasar early-data yang sama. Jika satu replika menangguhkan manakala yang lain mengenakan caj serta-merta, penyerang atau perbezaan laluan boleh menghasilkan kesan duplikasi. Kongsi versi dasar, kunci keidempoteman, rekod penyahduplikasian, dan medan yang boleh diperhatikan merentasi replika.
Langkah 8: Uji tingkah laku percubaan semula dan beban lampau
Uji handshake yang lengkap, replay ke replika lain, permintaan yang tiba sebahagiannya sebelum handshake, pemajuan get laluan, had masa tamat klien, dan beban lampau pelayan. Catatkan kadar early-data, kadar 425, percubaan semula, kunci duplikasi, kesan duplikasi, dan pertumbuhan baris gilir. Di bawah beban yang tinggi, respons 425 atau 503 yang berulang boleh menguatkan percubaan semula, jadi tetapkan belanjawan dan pastikan anda boleh melumpuhkan 0-RTT secara global.
Pertukaran (trade-offs) dan sempadan
0-RTT mengurangkan penantian bait pertama pada sambungan yang disambung semula, tetapi memerlukan analisis replay, dasar yang konsisten, dan penyahduplikasian. Nama kaedah sahaja tidak mencukupi: kaedah yang secara nominalnya selamat masih boleh menulis keadaan pengebilan, audit, atau cache. Dasar pada peringkat sumber adalah lebih boleh dipercayai.
Kunci keidempoteman mengurangkan kesan duplikasi tetapi tidak menjadikan setiap permintaan sesuai untuk early data. Keadaan penyahduplikasian memerlukan tempoh pengekalan yang berguna, keterlihatan merentasi replika, dan tingkah laku yang ditakrifkan untuk pertembungan kunci, tamat tempoh percubaan semula, dan kegagalan storan. Bagi tindakan yang tidak boleh dipulihkan, menunggu handshake selalunya lebih jelas daripada bergantung pada pampasan (compensation) yang kompleks.
Pelan pelancaran dan bukti
Daftarkan dasar early-data bagi setiap sumber: benarkan, tangguhkan, atau 425. Tambahkan kunci keidempoteman dan penyahduplikasian untuk penulisan, minta get laluan menyebarkan Early-Data, dan log keadaan sambungan, versi dasar, serta korelasi percubaan semula pada origin. Jalankan latihan replay merentasi replika dan sahkan bahawa pesanan, caj, dan mesej tidak berduplikasi.
Selepas pelancaran, perhatikan metrik 425, percubaan semula, dan kesan sampingan mengikut sumber dan versi klien. Jika klien melanggar peraturan percubaan semula, betulkan klien atau lumpuhkan 0-RTT pada pinggir dan bukannya melemahkan perlindungan origin. RFC 8470 memerlukan pengendalian get laluan dan origin yang konsisten, jadi semakan pelepasan mesti meliputi setiap laluan masuk (ingress).
Kesilapan lazim dan tindakan susulan
Menganggap 425 sebagai pengehadan kadar atau beban lampau
425 disasarkan untuk permintaan early-data yang mungkin di-replay. Keberkesanan serentak yang tinggi, kebergantungan yang tidak tersedia, dan pelanggaran kuota mempunyai semantik serta tingkah laku backoff yang berbeza.
Mengembalikan 425 untuk setiap POST
Kaedah hanyalah petunjuk. Buat keputusan berdasarkan toleransi replay sumber serta keidempoteman dan penyahduplikasian yang boleh dipercayai. Penulisan yang terbukti idempoten boleh ditangguhkan atau dikendalikan oleh dasar khusus sumber.
Mencuba semula 425 dengan 0-RTT sekali lagi
RFC 8470 memerlukan percubaan semula selepas 425 mengelakkan early data. Jika tidak, klien menukar perlindungan pelayan menjadi satu lagi peluang untuk replay.
Membuang pengepala Early-Data pada get laluan
Membuang isyarat menyebabkan origin mempercayai bahawa permintaan tidak melalui early data. Kekalkan atau tambah pengepala, sahkan sokongan origin untuk 425, dan tunggu handshake jika tidak pasti.
Bagaimanakah anda membuktikan tiada caj berganda berlaku?
Jalankan latihan replay dengan kunci keidempoteman merentasi replika, cap jari permintaan (fingerprint), dan mesin keadaan caj, kemudian sahkan satu hasil perniagaan akhir bagi setiap operasi. Uji juga kegagalan stor penyahduplikasian, percubaan semula klien selepas tamat masa, dan penghantaran hiliran (downstream) yang bertindih; kod status HTTP sahaja bukan bukti.