Gesaan dan konteks
Soalan ini menguji sama ada anda boleh menukar pengoptimuman kependaman pada peringkat pengangkutan kepada sempadan keselamatan perniagaan yang jelas. TLS 1.3 early data boleh dihantar sebelum sambungan diwujudkan sepenuhnya, dan RFC 8470 secara jelas menyatakan risiko replay. Oleh itu, keselamatan permintaan tidak boleh diputuskan hanya daripada nama kaedah HTTP. Rangkumi kelas permintaan, peralihan keadaan, keidempotenan, cache dan proksi, percubaan semula klien, pemantauan dan sandaran (fallback).
Perkara yang dinilai oleh penemu duga
- Sama ada anda membezakan bacaan berulang yang tidak berbahaya daripada kesan sampingan yang berulang.
- Sama ada anda mengehadkan early data kepada set selamat yang jelas dan memberikan laluan penolakan yang boleh dijelaskan untuk permintaan yang tidak pasti.
- Sama ada 425, kunci keidempotenan, penyahduplikasian (deduplication) dan backoff percubaan semula berfungsi bersama.
- Sama ada anda boleh menerangkan rantaian proksi, log, metrik, rollback dan kawalan peluncuran secara berperingkat.
Soalan penjelasan untuk ditanya terlebih dahulu
Sahkan permintaan yang manakah boleh membawa early data, di mana TLS ditamatkan, dan sama ada proksi atau percubaan semula mesej berlaku selepas lapisan pinggir (edge). Operasi manakah yang mengubah baki, inventori, pesanan, kebenaran atau pemberitahuan? Adakah perniagaan sudah mempunyai kunci keidempotenan, jadual keadaan permintaan dan kekangan unik (unique constraints)? Adakah klien, SDK dan get laluan memahami 425? Siapa yang mencuba semula, berapa kali, dan dengan backoff eksponen serta jitter yang bagaimana? Jika storan penyahduplikasian tidak tersedia, patutkah perkhidmatan menolak, berundur ke jabat tangan penuh (full handshake), atau meneruskan trafik baca sahaja?
Kerangka jawapan 30 saat
Secara lalai, saya akan mengecualikan permintaan yang mempunyai kesan sampingan atau yang keidempotenannya tidak dapat dibuktikan daripada early data. Lapisan pinggir mengesan early data dan menghantar isyarat yang dilindungi kepada aplikasi; bacaan selamat boleh diteruskan, manakala pesanan, caj dan perubahan kebenaran mengembalikan 425 atau memerlukan jabat tangan penuh. Bagi operasi tulis yang benar-benar memerlukan kependaman rendah, klien membekalkan kunci keidempotenan dan pelayan menggunakan kekangan unik serta keadaan hasil jangka pendek untuk mengekalkan status “processing” dan “completed”. Klien hanya mencuba semula respons yang boleh dicuba semula secara eksplisit, dengan backoff eksponen terikat dan jitter. Lancarkan secara beransur-ansur dan pantau pelaksanaan pendua, 425, volum percubaan semula dan anomali perniagaan.
Analisis mendalam langkah demi langkah
1. Tentukan sempadan kepercayaan untuk early data
Kesan early data pada lapisan penamatan TLS dan salurkannya melalui isyarat dalaman yang dilindungi; klien awam tidak boleh memalsukan penanda “permintaan selamat”. Tentukan sama ada proksi, cache dan panggilan perkhidmatan ke perkhidmatan boleh menyalin atau menangguhkan permintaan. Anggap isyarat yang hilang atau laluan yang tidak pasti sebagai berisiko tinggi secara lalai.
2. Kelaskan mengikut kesan sampingan perniagaan
Bacaan tanpa keadaan (stateless reads) yang hasil berulangnya tidak mengubah sumber adalah lebih mudah untuk diterima. Membuat pesanan, mengenakan caj, mengurangkan inventori, menukar kebenaran, menghantar mesej dan memanggil sistem luaran adalah sensitif terhadap replay. Malah PUT atau DELETE mesti disemak terhadap pelaksanaan sebenar; POST tidak semestinya bukan idempoten secara automatik. Model keadaan perniagaan dan kekangan unik menentukan jaminan tersebut.
3. Reka bentuk 425 dan sandaran jabat tangan penuh
Kembalikan 425 Too Early untuk laluan yang tidak membenarkan early data dan dokumentasikan cara klien melengkapkan jabat tangan penuh sebelum menghantar semula. Get laluan tidak boleh mencuba semula 425 tanpa henti. Catatkan sama ada permintaan asal mungkin telah sampai ke aplikasi supaya lapisan pinggir dan klien tidak kedua-duanya mencuba semula dan menggandakan beban. Apabila keupayaan klien tidak diketahui, kegagalan eksplisit adalah lebih selamat daripada pelaksanaan senyap.
4. Gunakan kunci keidempotenan dan mesin keadaan
Ikat kunci keidempotenan pada penyewa (tenant), jenis operasi dan ringkasan (digest) parameter permintaan. Kekalkan keadaan pemprosesan, kejayaan dan kegagalan di sebalik kekangan unik. Satu permintaan serentak memiliki kunci tersebut; yang lain membaca keadaan atau menunggu untuk masa yang terhad, manakala ketidakpadanan parameter akan ditolak. Tetapkan tempoh pengekalan supaya hasil lama tidak melebihi tetingkap percubaan semula perniagaan. Komit pangkalan data dan kesan sampingan luaran masih memerlukan peti keluar (outbox), pengundian status atau reka bentuk pampasan.
5. Kekang percubaan semula dan tingkah laku proksi
Klien hanya mencuba semula apabila respons boleh dicuba semula dan operasi memenuhi peraturan keidempotenan, menggunakan backoff eksponen terpotong, jitter dan had jumlah percubaan. Get laluan, SDK dan pengguna giliran tidak boleh mengumpul percubaan semula tanpa had; bezakan antara 425, kegagalan sambungan, pengehadan kadar (rate limiting) dan penolakan perniagaan. Untuk operasi tulis bernilai tinggi, biarkan klien menanyakan status kunci keidempotenan dan bukannya menghantar semula kesan sampingan yang asal.
6. Pantau, lancarkan dan buat sandaran
Mulakan dengan laluan baca dan set penyewa yang kecil, dengan mengekalkan suis mengikut laluan, klien dan rantau. Jejaki volum early-data, kadar 425, konflik kunci pendua, caj pendua atau anomali inventori, amplifikasi percubaan semula, kependaman jabat tangan penuh dan ralat storan penyahduplikasian. Jika ambang batas dilangkaui, hentikan peluncuran, nyahdayakan early data, atau paksakan jabat tangan penuh, dan simpan sampel audit untuk menentukan sama ada permintaan benar-benar telah dilaksanakan.
Contoh jawapan berkualiti tinggi
Saya akan menganggap early data sebagai input yang berpotensi untuk di-replay, bukan sebagai permintaan HTTPS biasa. Lapisan pinggir mengesan dan melindungi isyarat tersebut; bacaan diteruskan hanya apabila risikonya boleh diterima, manakala pesanan, caj, inventori, kebenaran dan pemberitahuan luaran mengembalikan 425 dan memerlukan jabat tangan penuh. Bagi operasi tulis yang memerlukan kependaman rendah, klien mesti menghantar kunci keidempotenan yang terikat pada penyewa, operasi dan digest parameter. Pelayan mengekalkan keadaan pemprosesan, kejayaan dan kegagalan di sebalik kekangan unik serta menolak konflik parameter. Tentukan syarat percubaan semula secara berasingan untuk 425, kegagalan sambungan dan pengehadan kadar; klien menggunakan backoff eksponen terikat dan jitter, manakala get laluan mengelakkan percubaan semula automatik tanpa henti. Lancarkan secara berperingkat dan pantau 425, kunci pendua, pelaksanaan perniagaan pendua, amplifikasi percubaan semula, kependaman sandaran dan kegagalan penyahduplikasian. Nyahdayakan early data atau paksakan jabat tangan penuh sekiranya berlaku anomali, kemudian selaraskan rekod audit.
Kesilapan biasa
- Menganggap penyulitan TLS bermaksud early data tidak boleh di-replay.
- Mengelaskan hanya berdasarkan nama kaedah dan bukannya kesan sampingan perniagaan yang sebenar.
- Membiarkan kedua-dua get laluan dan klien mencuba semula 425 tanpa had.
- Mengabaikan pengikatan penyewa dan parameter daripada kunci keidempotenan.
- Hanya menyimpan kejayaan dalam cache dan mengabaikan keadaan pemprosesan atau semantik kegagalan yang boleh dicuba semula.
- Mengukur pengurangan kependaman tanpa mengambil kira caj pendua, anomali inventori atau amplifikasi percubaan semula.
- Mengabaikan pelumpuhan pada peringkat laluan, sandaran jabat tangan penuh dan penyelarasan audit.
Soalan susulan dan jawapan
Apakah perbezaan antara 425 dan 429?
425 bermaksud permintaan tiba terlalu awal di bawah syarat early-data semasa dan harus dihantar semula selepas jabat tangan penuh. 429 bermaksud permintaan telah mencapai had kadar atau kuota. Syarat percubaan semula, pembayang masa tunggu dan makna pemantauannya adalah berbeza, jadi kedua-duanya tidak boleh berkongsi cabang percubaan semula automatik yang sama.
Bagaimana jika klien tidak menyokong 425?
Untuk laluan tulis yang kritikal, tolak early data di get laluan atau paksakan jabat tangan penuh dan bukannya bergantung pada tafsiran klien. Sediakan tingkah laku keserasian dalam SDK yang dinaik taraf. Laluan baca sahaja boleh diteruskan, tetapi rekodkan keupayaan klien dan sempadan risiko.
Patutkah transaksi caj diteruskan jika storan keidempotenan terputus?
Jangan laksanakan kesan sampingan berisiko tinggi apabila penyahduplikasian tidak dapat dibuktikan. Kembalikan ralat yang boleh dicuba semula, berundur kepada jabat tangan penuh dan semak semula, atau tukar permintaan kepada keadaan belum selesai yang boleh ditanya. Buat pilihan berdasarkan had kerugian dan laluan pemulihan.
Bolehkah permintaan early-data dilaksanakan selepas perkhidmatan mengembalikan 425?
Wujud keadaan perlumbaan (race condition) di mana permintaan telah sampai ke aplikasi, jadi aplikasi mesti menyemak semula isyarat early-data dan keadaan keidempotenan sebelum melaksanakan kesan sampingan. Status 425 tidak membatalkan operasi yang telah dimulakan. Komit kesan sampingan melalui mesin keadaan dan kekangan unik, kemudian gunakan rekod audit untuk mengesahkan pelaksanaan.