Prompt dan skop
Anda memiliki API pembayaran, penukaran kata laluan, atau penciptaan pesanan. Bahagian edge membolehkan TLS 1.3 0-RTT, dan get laluan boleh memajukan permintaan yang membawa Early-Data: 1. Terangkan bila perlu mengembalikan 425, bila perlu meneruskan, dan bagaimana klien mencuba semula selepas jabat tangan (handshake) selesai. Ini sesuai untuk temu duga backend, platform, dan infrastruktur API.
RFC 8470 mentakrifkan 425 sebagai penolakan pelayan untuk mengambil risiko memproses permintaan yang mungkin dimainkan semula; ia bukan kod percubaan semula generik "pelayan sibuk". Andaikan get laluan boleh mengekalkan isyarat Early-Data dan perkhidmatan boleh membezakan operasi baca sahaja daripada kesan sampingan.
Perkara yang diuji oleh penemu duga
- Sama ada anda memisahkan faedah kependaman 0-RTT daripada risiko main semula (replay risk) dan bukannya menganggap setiap 4xx sebagai input klien biasa.
- Sama ada anda boleh menjejaki tanggungjawab klien, get laluan, dan aplikasi untuk menunggu, mencuba semula, dan keidempotensian.
- Sama ada anda boleh menukar syarat RFC, ketidakbolehan simpanan cache, dan pemasaan percubaan semula menjadi dasar API yang boleh diuji.
Jawapan yang lemah sekadar menghafal "425 bermaksud Too Early." Jawapan yang kukuh membuat keputusan daripada kesan sampingan, isyarat Early-Data, kunci keidempotensian, dan tetingkap percubaan semula yang terhad, kemudian menerangkan bagaimana konfigurasi yang salah boleh mengenakan caj dua kali kepada pelanggan.
Soalan penjelasan untuk ditanya terlebih dahulu
- Adakah permintaan membawa
Early-Data: 1, atau bolehkah edge membuktikan ia tiba dalam early data? RFC 8470 menasihatkan agar tidak mereka-reka respons 425 tanpa isyarat tersebut. - Adakah operasi tersebut mencipta kesan sampingan luaran? Bacaan pesanan boleh diteruskan; caj, penukaran kata laluan, atau pengeluaran kupon harus menunggu jabat tangan atau menggunakan rekod keidempotensian yang ketat.
- Adakah get laluan akan mencuba semula secara automatik? Jika ya, sahkan bahawa ia mencuba semula selepas jabat tangan dan get laluan serta SDK tidak akan melakukan percubaan semula secara berasingan.
- Adakah klien menyokong kunci keidempotensian dan had percubaan semula? Tanpa ciri tersebut, melumpuhkan 0-RTT bagi operasi itu adalah lebih selamat daripada menganggap 425 sebagai kebenaran untuk mencuba semula selama-lamanya.
Jawapan 30 saat
"Saya terlebih dahulu mengesahkan bahawa permintaan datang melalui TLS early data dengan Early-Data: 1, kemudian mengelaskan kesan sampingannya. Kerja baca sahaja boleh diteruskan; pembayaran dan penukaran kata laluan sama ada menunggu di get laluan atau menerima 425. Klien mencuba semula hanya selepas jabat tangan selesai, dan perkhidmatan menggunakan kunci keidempotensian serta kekangan keunikan untuk mengelakkan pelaksanaan pendua. Get laluan mengekalkan isyarat, memiliki satu dasar percubaan semula, dan kami memantau kadar 425, kejayaan percubaan semula, serta kesan sampingan pendua. Jika rantaian tidak dapat membuktikan syarat-syarat ini, saya melumpuhkan 0-RTT untuk titik akhir tulis."
Penyelesaian langkah demi langkah
1. Kenal pasti isyarat risiko
RFC 8470 memerlukan perantara mengekalkan maksud Early-Data apabila memajukan early data. Perkhidmatan hanya perlu mempertimbangkan 425 apabila permintaan itu berpotensi untuk dimainkan semula. Mengembalikan 425 tanpa bukti menukar kegagalan rangkaian biasa kepada penolakan keselamatan yang mengelirukan.
2. Kelaskan mengikut kesan sampingan
Kelaskan titik akhir sebagai baca sahaja, boleh diulang dengan selamat, atau tidak selamat untuk diulang. GET /orders/123 biasanya adalah baca sahaja; mengeluarkan kupon sekali guna, mengenakan caj pada kad, atau menukar kata laluan adalah tidak selamat untuk diulang. Kelas yang tidak selamat harus menunggu jabat tangan yang lengkap atau menyimpan kunci keidempotensian sebelum sebarang kesan sampingan.
3. Tetapkan satu pemilik percubaan semula
Selepas 425, klien menunggu jabat tangan TLS dan menghantar permintaan semula; percubaan semula tidak boleh menggunakan early data. Get laluan boleh memiliki percubaan semula itu, tetapi kontrak mesti menyatakan sedemikian, jika tidak kedua-dua get laluan dan SDK boleh mencuba semula. Tetapkan undur eksponen (exponential backoff), kiraan percubaan maksimum, dan sebab yang jelas untuk setiap percubaan semula.
4. Jadikan keidempotensian sebagai pertahanan kedua
Wajibkan kunci keidempotensian untuk operasi tulis. Perkhidmatan menyimpan rekod unik berpandukan penyewa, titik akhir, dan kunci, dengan sekurang-kurangnya status pemprosesan, kejayaan, dan kegagalan boleh cuba semula. Pendua akan mengembalikan hasil asal atau respons eksplisit bahawa proses sedang berjalan. Keidempotensian tidak menggantikan 425: pelaksanaan pertama masih boleh dimainkan semula selepas komit pangkalan data dan sebelum respons sampai kepada klien.
5. Pastikan get laluan dan tika konsisten
Setiap tika mesti menggunakan dasar Early-Data yang sama. Jika get laluan tidak pasti bahawa huluan memahami isyarat tersebut, ia menunggu jabat tangan atau menolak permintaan awal; ia tidak boleh memajukan operasi tulis secara senyap kepada perkhidmatan HTTP sahaja. Log ID permintaan, keadaan Early-Data, sebab 425, dan cincangan kunci keidempotensian, jangan sekali-kali kandungan pembayaran.
6. Uji laluan kegagalan
Uji permintaan dengan dan tanpa Early-Data: 1, percubaan semula pertama selepas jabat tangan, percubaan semula get laluan, tamat masa klien diikuti dengan penyerahan semula, dan dua tika yang bersaing pada satu kunci keidempotensian. Pastikan bahawa kesan sampingan yang tidak selamat berlaku sekali sahaja dan 425 tidak disimpan dalam cache.
Alternatif yang lebih mudah adalah melumpuhkan 0-RTT sepenuhnya. Ia mempunyai sempadan keselamatan yang jelas tetapi menambah kependaman jabat tangan. Bagi sebilangan kecil titik akhir yang penjimatan kependamannya tidak ketara, melumpuhkannya adalah lebih selamat daripada mengekalkan dasar rentas lapisan.
Contoh jawapan berkualiti tinggi
"Saya tidak akan menggunakan 425 sebagai ralat pendikit (throttling) am. Saya terlebih dahulu menyemak Early-Data: 1, kemudian bertanya sama ada operasi tersebut mempunyai kesan sampingan. Bacaan pesanan boleh diteruskan; titik akhir pembayaran dan penukaran kata laluan menunggu di get laluan atau mengembalikan 425. Klien mencuba semula tepat selepas jabat tangan, dengan dasar SDK yang terhad. Perkhidmatan juga memerlukan kunci keidempotensian, menguatkuasakan kekangan keunikan penyewa serta kunci, dan menyimpan status pemprosesan serta hasil akhir supaya respons yang hilang tidak menyebabkan caj kedua. Get laluan dan tika berkongsi satu dasar, dan kami memantau kadar 425, kejayaan percubaan semula, serta pelaksanaan pendua. Jika Early-Data tidak dapat disebarkan, saya melumpuhkan 0-RTT untuk operasi tulis dan bukannya meneka."
Kesilapan lazim
- Menggunakan 425 sebagai pengganti 429 → Pencetus dan tindakan klien berbeza → Gunakan 425 hanya apabila risiko main semula early-data wujud.
- Mengembalikan 425 untuk setiap permintaan → Operasi baca disekat dan klien mungkin mencuba semula selama-lamanya → Kelaskan kesan sampingan dan hadkan percubaan semula.
- Mencuba semula dalam 0-RTT sekali lagi → Tetingkap main semula kekal terbuka → Wajibkan jabat tangan yang lengkap sebelum menghantar semula.
- Meletakkan keidempotensian hanya dalam aplikasi → Get laluan atau tika lain mungkin melaksanakannya terlebih dahulu → Terapkan satu dasar merentasi edge, perkhidmatan, dan ketekalan.
- Merekodkan keseluruhan badan pembayaran dalam log → Penyahpepijatan mendedahkan data sensitif → Log pengecam, sebab, dan cincangan kunci yang disunting.
Soalan susulan dan respons
Bagaimana jika get laluan membuang pengepala Early-Data?
Anggap ia sebagai jurang keupayaan: get laluan mesti menunggu jabat tangan atau menolak permintaan awal. Aplikasi tidak boleh membuat inferens 0-RTT daripada permintaan biasa; betulkan penyebaran isyarat sebelum mendayakan operasi tulis.
Bagaimana jika klien mengalami tamat masa dan menghantar semula sebelum melihat 425?
Gunakan kunci keidempotensian yang sama supaya permintaan kedua membaca keadaan sedang diproses atau hasil akhir permintaan pertama. Untuk operasi tulis berbahaya tanpa kunci, kembalikan ralat yang boleh didiagnosis dan gunakan aliran kerja manual atau pampasan; jangan meneka sama ada caj telah berlaku.
Bagaimana jika percubaan semula kerap berjaya tetapi memburukkan SLO kependaman?
Bandingkan kadar 425, kependaman kejayaan pertama p95, kesan sampingan pendua, dan kejayaan perniagaan mengikut titik akhir dan ejen pengguna. Jika faedah operasi tulis tidak berbaloi dengan kependaman tersebut, kekalkan 0-RTT hanya untuk operasi baca yang selamat atau lumpuhkannya bagi kelas titik akhir tersebut.