Reāllaika transkripcija, kad ugunsmūris bloķē WebSockets

Reāllaika transkripcijai korporatīvajā tīklā ir konkrēts, prātam neaptverams veids, kā izgāzties. Jūsu Wi-Fi ir kārtībā. HTTPS darbojas — jūs varat ielādēt jebkuru vietni. Bet reāllaika transkripcija vienkārši... nesākas, un nekas jums nepasaka, kāpēc.

Vaininieks ir korporatīvo proxy klase, kas atļauj parasto HTTPS trafiku, bet bloķē WebSocket jauninājumu — rokasspiedienu, kas pārvērš HTTPS savienojumu par pastāvīgu, divvirzienu kanālu, kāds reāllaika transkripcijai ir nepieciešams. Proxy skatījumā WebSocket izskatās kā nekontrolēts tunelis ārpus tīkla, tāpēc tas to nogalina. Jūsu skatījumā transkripcija ir klusi salauzta.

GeekBye v2.0.8 pievienoja automātisku rezerves variantu tieši šim gadījumam — un tā izveide atklāja kļūdu, kas būtu padarījusi visu funkciju bezjēdzīgu.

Kāpēc rezerves variants, nevis tikai atkārtots mēģinājums

Mēs jau apstrādājam nestabilus tīklus. Ja jūsu savienojums pārtrūkst sesijas vidū, GeekBye atkārtoti savienojas ar atkāpi un buferē jūsu audio, tāpēc nekas nezūd — tā ir atsevišķa funkcija, aprakstīta rakstā kāpēc jūsu AI piezīmju rīks apstājas sliktā Wi-Fi.

Bet bloķēts WebSocket nav nestabils savienojums. Atkārtots mēģinājums ar to pašu WebSocket pret proxy, kas atsakās no WebSockets, izgāžas vienādi katru reizi, mūžīgi. Vienīgais risinājums ir cits transports — tāds, kas izskatās pēc parastā HTTPS, ko proxy jau atļauj.

Tāpēc v2.0.8 pārslēdzas uz tīri HTTPS transportu pa to pašu autentificēto galapunktu:

• Lejup (transkripti, kas nāk atpakaļ pie jums): server-sent events — ilgdzīvojoša HTTPS atbilde, ko proxy redz kā parastu straumētu lejupielādi.
• Augšup (jūsu audio, kas iziet ārā): sadalīti POST pieprasījumi, katrs nes audio gabalu ar secības numuru, lai serveris varētu tos salikt kārtībā pat tad, ja tīkls tos pārkārto.

Nekāda pastāvīga soketa, nekā, kas izskatās pēc tuneļa — tikai HTTPS pieprasījumi un atbildes. Ja proxy ļauj jums lietot vietni, tas ļauj arī šo.

Kļūda, kas būtu piegādājusi mirušu funkciju

Lūk daļa, kuras dēļ ir vērts lasīt. Rezerves variantam ir jāiedarbojas, kad WebSocket savienojums izsmeļ savus mēģinājumus ar bloķēta transporta parakstu — katrs mēģinājums izgāžas jauninājumā, nav autentifikācijas vai kvotas problēmas, vismaz viens proxy formas noraidījums. Proxy, kas bloķē WebSocket, uz jauninājumu parasti atbild ar HTTP 403 Forbidden vai 407.

Problēma: mūsu savienojuma kodam jau bija noteikums, ka 403 nozīmē fatālu autentifikācijas kļūdu — apstāties, parādīt to lietotājam, neatkārtot. Kas ir pareizi gandrīz visur. Bet tas nozīmēja, ka 403 no bloķējošā proxy — tieši tas signāls, kam vajadzēja iedarbināt rezerves variantu — tā vietā tika izmests kā fatāla kļūda pirms rezerves varianta loģika vispār varēja nostrādāt. Tikai neapstrādāts savienojuma pārrāvums (1006 aizvēršanās) izkrita cauri līdz rezerves variantam. Tātad funkcija būtu strādājusi retajā gadījumā un klusi izgāzusies pie sava īstā galvenā mērķa: korporatīvā proxy.

Mēs to noķērām, nostiprinot laidienu, nevis ražošanā. Labojums: 403/407 uz WebSocket jauninājuma posma tagad tiek uzskatīts par atgūstamu, lai savienojuma cikls varētu izsmelties līdz rezerves variantam — kamēr īsta autentifikācijas kļūme (kas pienāk citādi, pēc tam, kad jauninājums ir izdevies) joprojām izgāžas ātri, tieši tāpat kā agrāk. Regresijas tests tagad nostiprina atšķirību: bloķēta proxy 403 ir jāpārslēdzas uz rezerves variantu; īsts autentifikācijas 403 nedrīkst.

Pārējā nostiprināšana sekoja tai pašai paranoiskajai līnijai: noildze katram augšupejošajam POST, lai proxy, kas pieņem pieprasījumu, bet nekad neatbild, nevarētu iestrēdzināt audio straumi, un garantija, ka īstu pierakstīšanās problēmu nekad nevar klusi maskēt rezerves varianta mehānisms.

Mēs to pārbaudījām pret īstu naidīgu proxy

Funkciju, kuras viss mērķis ir izdzīvot naidīgos tīklos, nevar pārbaudīt tikai ar vienībtestiem — vienībtestiem nav proxy. Pirms tās iespējošanas mēs izlaidām īsto lietotni caur lokālu reverso proxy, kas konfigurēts darīt tieši to, ko dara korporatīvie proxy: pārsūtīt HTTPS, noraidīt WebSocket jauninājumus ar 403.

Pēdas žurnālos ir kvīts: četri bloķēti WebSocket mēģinājumi, atpazīts izsīkuma paraksts, automātiska pārslēgšanās uz HTTPS transportu, un tad vesela 96 sekundes gara transkripcijas sesija pa tīru HTTPS — 66 transkripta segmenti, nulle zudumu. Pārslēgšanās darbojas, jo mēs vērojām, kā tā pārslēdzas.

Trīs pārnesamas mācības

1. "Tas darbojas nestabilā Wi-Fi" un "tas darbojas aiz naidīga proxy" ir atšķirīgas garantijas. Vienai vajag atkārtotu savienošanos; otrai vajag citu transportu. To sajaukšana atstāj veselu korporatīvo lietotāju grupu klusi salauztu.
2. Jūsu kļūdu klasifikācija var paslēpt jūsu pašu funkciju no tās pašas. Noteikums, kas ir pareizs 99% gadījumu (403 = fatāla autentifikācija), bija tieši nepareizs tam 1%, kura dēļ šī funkcija pastāvēja. Kad pievienojat rezerves variantu, pārbaudiet, vai iedarbināšanas nosacījums vispār var sasniegt rezerves variantu.
3. Testējiet pretinieku, nevis tikai laimīgo ceļu. Vienīgais godīgais tests "izdzīvo WebSocket bloķējošu proxy" ir WebSocket bloķējošs proxy. Mēs tādu uzbūvējām.

GeekBye v2.0.8 piegādāja HTTPS rezerves variantu ar karogu ierobežotu un pārbaudītu. Par uzticamības darbu, kas atrodas tam blakus, lasiet kāpēc jūsu AI piezīmju rīks apstājas sliktā Wi-Fi, un par kaimiņu laidieniem šajā sērijā — kāpēc jūsu AI piezīmju rīks pārtrauc ierakstīšanu sapulces vidū (v2.0.9) un kāpēc AI transkripcija pārprot tehniskos terminus (v2.0.11).