Gesaan dan skop
Halaman kolaboratif menerima peristiwa frekuensi tinggi dan menghantar suntingan ke pelayan. Nilaikan sama ada WebSocketStream sesuai, terangkan cara tekanan balik Streams, penutupan dan pembatalan menghalang pengumpulan mesej, dan reka bentuk sandaran (fallback) untuk pelayar yang tidak disokong.
WebSocketStream ialah Web API eksperimen yang bukan standard. Ia mendedahkan sambungan sebagai objek ReadableStream dan WritableStream, membolehkan tekanan balik Streams mengawal pembacaan dan penulisan. MDN secara jelas mengesyorkan agar memeriksa keserasian pelayar sebelum penggunaan produksi. Temu duga ini adalah mengenai reka bentuk protokol strim dan pertimbangan risiko.
Perkara yang diuji oleh penemu duga
Merangkumi kitaran hayat ReadableStream dan WritableStream, cara tekanan balik menghalang barisan gilir tanpa batas, kunci reader dan writer, perbezaan antara abort dan close, susunan mesej dan keidempotensian (idempotency), denyutan jantung (heartbeats) dan penyambungan semula, penggunaan Worker, pengesanan keupayaan, dan sandaran (fallback).
Jawapan 30 saat
"Saya terlebih dahulu mengesahkan bahawa WebSocketStream bukanlah keupayaan yang dipiawaikan secara meluas dan hanya mendayakannya selepas pengesanan ciri. Saya menguruskan readable dan writable secara bebas, membiarkan tekanan balik merambat dan bukannya menimbal tatasusunan tanpa batas, serta menjadikan penutupan, pembatalan, dan ralat rangkaian sebagai keadaan yang boleh diperhatikan. AbortSignal membawa jangka hayat komponen ke dalam kerja tak segerak. Produksi mengekalkan penyesuai WebSocket klasik dengan protokol mesej yang sama, barisan gilir terhad, backoff sambungan semula, dan penindasan pendua."
Penyelesaian langkah demi langkah
Langkah 1: Sahkan keupayaan dan sempadan
Semak sama ada masa jalan (runtime) mendedahkan WebSocketStream sebelum mendayakannya. Ia bersifat eksperimen dan bukan standard, jadi sokongan dalam satu binaan Chrome tidak membayangkan sokongan dalam setiap pelayar, WebView, atau persekitaran perusahaan. Pemeriksaan keupayaan yang gagal akan memilih pelaksanaan yang stabil secara terus.
Langkah 2: Buka sambungan dan strim
Bina WebSocketStream dan tunggu janji opened untuk mendapatkan maklumat readable, writable, protokol, dan sambungan (extension). Gunakan bahagian readable melalui reader dan tulis melalui writer; laporkan penutupan sambungan melalui janji closed.
const socket = new WebSocketStream(url);
const { readable, writable } = await socket.opened;
const reader = readable.getReader();
const writer = writable.getWriter();Langkah 3: Gunakan tekanan balik (backpressure)
Jangan tolak setiap peristiwa ke dalam tatasusunan biasa. Biarkan highWaterMark TransformStream atau WritableStream hiliran menghadkan barisan gilir, tunggu writer.ready sebelum menghantar, dan panggil read mengikut kadar pengguna. Tekanan balik mengawal strim klien; pelayan masih memerlukan had kadar pada peringkat protokol.
Langkah 4: Tentukan susunan mesej
Berikan nombor jujukan, versi dokumen, dan kunci idempotensi pada suntingan. Selepas menyambung semula, jangan anggap mesej terakhir dalam strim lama telah dikekalkan. Minta jurang atau snapshot berversi daripada pelayan sebelum menggunakan peristiwa baharu, dan pastikan kedua-dua lapisan pemaparan dan pengangkutan mengenali pendua.
Langkah 5: Kendalikan pembatalan dan penutupan
Apabila pengguna meninggalkan atau menukar dokumen, hentikan pembacaan dan penulisan, kemudian tutup atau batalkan strim yang berkaitan. AbortSignal menghubungkan jangka hayat komponen kepada kerja tak segerak. Penutupan normal, pembatalan aktif, ralat protokol, dan kehilangan rangkaian hendaklah menjadi keadaan yang berbeza supaya logik penyambungan semula hanya digunakan untuk kegagalan rangkaian sebenar.
Langkah 6: Lindungi memori dan UI
Asingkan penghuraian (parsing), pengesahan, dan pemaparan; alihkan penyahkodan atau pemprosesan kelompok kepada Worker apabila diperlukan. Tetapkan saiz mesej maksimum, kiraan peristiwa belum selesai, dan masa kelompok. Di atas ambang, jeda langganan, gabungkan atau gugurkan peristiwa perantaraan yang boleh dibina semula, atau minta snapshot pelayan dan bukannya mengumpul tanpa had.
Langkah 7: Reka bentuk penyambungan semula dan pemulihan
Gunakan backoff eksponen dengan jitter dan sertakan versi dokumen terakhir yang disahkan. Selepas pelayan mengembalikan peristiwa yang hilang atau snapshot, sambung semula strim langsung. ID idempotensi yang dijana oleh klien menghalang penulisan yang terputus daripada diserahkan dua kali.
Langkah 8: Laksanakan sandaran dan kebolehpemerhatian (observability)
Gunakan WebSocket klasik sebagai sandaran lalai dengan sampul mesej dan mesin keadaan yang sama. Rekodkan hasil keupayaan, kependaman opened dan closed, kedalaman barisan gilir, masa menunggu tekanan balik, kiraan sambungan semula, peristiwa yang digugurkan, dan kadar pemulihan snapshot. Pecahkan mengikut pelayar, jenis rangkaian, dan versi halaman sebelum memperluaskan eksperimen.
Pertukaran (trade-offs) dan sempadan
WebSocketStream atau WebSocket
WebSocketStream menyediakan tekanan balik strim dan isyarat kitaran hayat berasaskan Promise, tetapi sokongan dan penyeragamannya adalah terhad. WebSocket klasik tersedia secara meluas namun memerlukan aplikasi menghadkan kerja onmessage dan barisan gilir penghantaran. Satu abstraksi protokol boleh menyokong kedua-dua pengangkutan.
Gugurkan peristiwa atau minta snapshot
Peristiwa yang boleh dibina semula seperti pergerakan kursor boleh digabungkan atau digugurkan apabila barisan gilir penuh. Suntingan dokumen tidak boleh digugurkan secara senyap; jeda penggunaan dan minta snapshot berversi. Pilihan bergantung pada komutativiti, susunan, dan sokongan main semula pelayan.
Utas utama atau Worker
Mesej kecil dan kadar pemaparan yang rendah sesuai untuk utas utama. Penyahkodan binari kadar tinggi, pemampatan, dan penggabungan kelompok boleh dipindahkan ke Worker. Worker tidak membuang had jumlah memori, jadi barisan gilir pengangkutan dan pembatalan masih memerlukan had yang jelas.
Latih tubi kegagalan dan evolusi
Pelayar tidak menyokong API
Matikan cabang keupayaan dan sahkan bahawa WebSocket klasik menyambung, menggunakan mesej yang sama, dan melaporkan metrik keserasian.
Pengguna menjadi perlahan
Perlahankan pemaparan secara buatan dan sahkan bahawa masa menunggu tekanan balik meningkat, barisan gilir kekal terhad, dan laluan pemulihan snapshot dicetuskan pada ambang dan bukannya ranap.
Sambungan terputus semasa menulis
Putuskan sambungan serta-merta selepas menghantar suntingan. Sahkan bahawa ID idempotensi, versi terakhir yang disahkan, dan backoff penyambungan semula memulihkan keadaan tanpa menggunakan suntingan dua kali.
Kesilapan lazim dan tindakan susulan
Kesilapan 1: Menganggap Streams menyelesaikan pendikit (throttling) pelayan
Tindakan susulan: Apakah yang dikawal oleh tekanan balik? Ia mengawal pengeluaran dan penggunaan di dalam strim klien; ia tidak menggantikan kuota pelayan, had sambungan, atau pengelompokan perniagaan.
Kesilapan 2: Menganggap close, cancel, dan abort sebagai serupa
Tindakan susulan: Apakah yang berlaku semasa komponen dinyahlekap (unmount)? Rekodkan penutupan normal, pembatalan bacaan, dan pembatalan tak segerak secara berasingan supaya logik penyambungan semula menyasarkan kerosakan rangkaian sebenar.
Kesilapan 3: Menghantar hanya WebSocketStream
Tindakan susulan: Bagaimana dengan WebView atau pelayar lama? Pemeriksaan keupayaan yang gagal memilih penyesuai WebSocket klasik, manakala protokol mesej dan mesin keadaan kekal sama.
Tindakan susulan yang lebih mendalam dan contoh jawapan
Mengapakah perlu await writer.ready?
Ia membolehkan penghantar menunggu kapasiti WritableStream di bawah tekanan balik dan bukannya mencipta janji atau tatasusunan tanpa batas. Had kadar pelayan dan had saiz mesej masih diperlukan.
Bilakah klien patut meminta snapshot?
Apabila barisan gilir peristiwa melebihi hadnya, jurang jujukan muncul, atau klien tidak dapat mengesahkan versi yang berterusan, snapshot berversi adalah lebih selamat daripada meneka susunan peristiwa.
Bagaimanakah anda melancarkan API eksperimen?
Kumpulkan mengikut keupayaan, versi pelayar, dan versi halaman, kemudian dayakan peratusan yang kecil. Bandingkan kedalaman barisan gilir, pemulihan putus sambungan, kadar ralat, dan kependaman pemaparan; lumpuhkan bendera dan kembali kepada WebSocket klasik apabila metrik merosot.