Transkripsi Langsung Apabila Tembok Api Menyekat WebSocket

Ada satu cara yang khusus dan memeningkan bagi transkripsi masa nyata untuk gagal pada rangkaian korporat. Wi-Fi anda elok. HTTPS berfungsi — anda boleh memuatkan mana-mana laman web. Tetapi transkripsi langsung cuma... tidak bermula, dan tiada apa-apa memberitahu anda sebabnya.

Punca masalahnya ialah sejenis proxy korporat yang membenarkan trafik HTTPS biasa tetapi menyekat naik taraf WebSocket — jabat tangan yang menukar sambungan HTTPS menjadi saluran dua hala yang kekal, yang diperlukan oleh transkripsi masa nyata. Bagi proxy, sebuah WebSocket kelihatan seperti terowong tak terpantau keluar dari rangkaian, jadi ia mematikannya. Bagi anda, transkripsi rosak secara senyap.

GeekBye v2.0.8 menambah sandaran automatik untuk tepat perkara ini — dan membinanya mendedahkan satu pepijat yang akan menjadikan seluruh ciri ini tidak berbuat apa-apa.

Mengapa sandaran, bukan sekadar cuba semula

Kami sudah mengendalikan rangkaian yang tak menentu. Jika sambungan anda terputus di tengah sesi, GeekBye menyambung semula dengan backoff dan menimbal audio anda supaya tiada apa yang hilang — itu ciri berasingan yang dibincangkan dalam mengapa AI notetaker anda berhenti apabila Wi-Fi teruk.

Tetapi WebSocket yang disekat bukanlah sambungan yang tak menentu. Mencuba semula WebSocket yang sama terhadap proxy yang menolak WebSocket gagal dengan cara yang sama setiap kali, selama-lamanya. Satu-satunya penyelesaian ialah pengangkutan yang berbeza — yang kelihatan seperti HTTPS biasa yang sudah dibenarkan oleh proxy.

Maka v2.0.8 berundur kepada pengangkutan HTTPS-tulen melalui endpoint disahtaraf yang sama:

• Ke arah bawah (transkrip yang kembali kepada anda): server-sent events — respons HTTPS berhayat panjang yang dilihat proxy sebagai muat turun strim biasa.
• Ke arah atas (audio anda yang keluar): permintaan POST berkelompok, setiap satu membawa satu ketulan audio dengan nombor jujukan supaya pelayan boleh mencantumkannya semula mengikut tertib walaupun rangkaian menyusun semulanya.

Tiada soket kekal, tiada apa yang kelihatan seperti terowong — hanya permintaan dan respons HTTPS. Jika sebuah proxy membenarkan anda menggunakan laman web, ia membenarkan yang ini.

Pepijat yang hampir mengeluarkan ciri yang mati

Inilah bahagian yang berbaloi dibaca. Sandaran sepatutnya tercetus apabila sambungan WebSocket menghabiskan percubaannya dengan tandatangan pengangkutan-disekat — setiap percubaan gagal pada naik taraf, tiada masalah auth atau kuota, sekurang-kurangnya satu penolakan berbentuk proxy. Proxy yang menyekat sebuah WebSocket biasanya menjawab naik taraf dengan HTTP 403 Forbidden atau 407.

Masalahnya: kod sambungan kami sudah pun mempunyai peraturan bahawa 403 bermaksud ralat pengesahan maut — berhenti, tunjukkan kepada pengguna, jangan cuba semula. Yang mana betul hampir di mana-mana. Tetapi ia bermakna 403 daripada proxy penyekat — tepat isyarat yang sepatutnya mencetuskan sandaran — sebaliknya dilontar sebagai ralat maut sebelum logik sandaran sempat berjalan langsung. Hanya putus sambungan mentah (penutupan 1006) yang lolos sampai ke sandaran. Jadi ciri ini akan berfungsi untuk kes yang jarang berlaku dan gagal secara senyap untuk sasaran utama sebenarnya: proxy korporat.

Kami menangkapnya semasa mengeraskan keluaran, bukan dalam produksi. Pembetulannya: 403/407 pada kaki naik taraf WebSocket kini dilayan sebagai boleh pulih supaya gelung sambungan boleh habis sehingga ke sandaran — manakala kegagalan pengesahan yang tulen (yang tiba secara berbeza, selepas naik taraf berjaya) masih gagal dengan pantas, tepat seperti sebelumnya. Satu ujian regresi kini menetapkan perbezaannya: 403 proxy tersekat mesti jatuh ke sandaran; 403 auth sebenar tidak boleh.

Selebihnya pengerasan mengikut garis paranoid yang sama: satu tamat masa pada setiap POST ke arah atas supaya proxy yang menerima permintaan tetapi tak pernah menjawab tidak boleh menyekat aliran audio, dan satu jaminan bahawa masalah log masuk yang tulen tak akan pernah ditutup secara senyap oleh jentera sandaran.

Kami mengujinya terhadap proxy yang benar-benar bermusuhan

Sebuah ciri yang seluruh tujuannya ialah bertahan pada rangkaian bermusuhan tidak boleh disahkan dengan ujian unit sahaja — ujian unit tiada proxy. Sebelum mengaktifkannya, kami menjalankan aplikasi sebenar melalui reverse proxy tempatan yang dikonfigurasi untuk melakukan tepat apa yang dilakukan proxy korporat: memajukan HTTPS, menolak naik taraf WebSocket dengan 403.

Kesan dalam log itulah resitnya: empat percubaan WebSocket yang disekat, tandatangan kehabisan yang dikenali, peralihan automatik kepada pengangkutan HTTPS, dan kemudian sesi transkripsi yang sihat selama 96 saat melalui HTTPS tulen — 66 segmen transkrip, sifar kehilangan. Peralihan gagal itu berfungsi kerana kami menyaksikannya beralih.

Tiga pengajaran yang boleh dibawa

1. "Ia berfungsi pada Wi-Fi tak menentu" dan "ia berfungsi di belakang proxy bermusuhan" ialah jaminan yang berbeza. Satu memerlukan penyambungan semula; yang lain memerlukan pengangkutan yang berbeza. Menyamakan kedua-duanya membiarkan seluruh populasi pengguna korporat rosak secara senyap.
2. Pengelasan ralat anda boleh menyembunyikan ciri anda sendiri daripada dirinya. Peraturan yang betul 99% masa (403 = auth maut) adalah tepat salah untuk 1% yang menjadi sebab kewujudan ciri ini. Apabila anda menambah sandaran, audit sama ada keadaan pencetus itu boleh mencapai sandaran langsung.
3. Uji si musuh, bukan hanya laluan yang gembira. Satu-satunya ujian yang jujur bagi "bertahan terhadap proxy penyekat WebSocket" ialah proxy penyekat WebSocket. Kami membina satu.

GeekBye v2.0.8 mengeluarkan sandaran HTTPS yang dilindungi flag dan disahkan. Untuk kerja kebolehpercayaan yang mengiringinya, lihat mengapa AI notetaker anda berhenti apabila Wi-Fi teruk, dan untuk keluaran jiran dalam siri ini, mengapa AI notetaker anda berhenti merakam di pertengahan mesyuarat (v2.0.9) dan mengapa transkripsi AI tersalah dengar istilah teknikal (v2.0.11).