Tiesioginė transkripcija, kai ugniasienė blokuoja WebSocket

Yra vienas konkretus, iki įsiūčio varantis būdas, kaip transkripcija realiu laiku sugenda įmonės tinkle. Jūsų Wi-Fi tvarkingas. HTTPS veikia — galite atsidaryti bet kurią svetainę. Bet tiesioginė transkripcija tiesiog... nepasileidžia, ir niekas jums nepasako kodėl.

Kaltininkas — įmonių proxy klasė, kuri praleidžia įprastą HTTPS srautą, bet blokuoja upgrade į WebSocket — rankos paspaudimą, kuris HTTPS ryšį paverčia nuolatiniu, dvipusiu kanalu, kurio reikia transkripcijai realiu laiku. Proxy akimis WebSocket atrodo kaip nestebimas tunelis iš tinklo į išorę, tad jį užmuša. Jums transkripcija tyliai sugedusi.

GeekBye v2.0.8 pridėjo automatinį fallback būtent šiam atvejui — o jo kūrimas iškėlė klaidą, dėl kurios visa funkcija nebūtų dariusi nieko.

Kodėl fallback, o ne tik kartojimas

Nestabilius tinklus jau tvarkome. Jei jūsų ryšys nutrūksta vidury sesijos, GeekBye prisijungia iš naujo su backoff ir buferizuoja jūsų garsą, kad niekas nedingtų — tai atskira funkcija, aprašyta kodėl jūsų AI užrašinė sustoja prastame Wi-Fi.

Bet užblokuotas WebSocket nėra nestabilus ryšys. To paties WebSocket kartojimas prieš proxy, kuris WebSocket atmeta, sugenda vienodai kaskart, amžinai. Vienintelis pataisymas — kitas transportas, kuris atrodo kaip paprastas HTTPS, kurį proxy jau leidžia.

Tad v2.0.8 persijungia į gryną HTTPS transportą per tą patį autentifikuotą endpoint:

• Žemyn (transkriptai, grįžtantys pas jus): server-sent events — ilgai gyvuojantis HTTPS atsakas, kurį proxy mato kaip įprastą srautinį atsisiuntimą.
• Aukštyn (jūsų garsas, keliaujantis į išorę): sugrupuotos POST užklausos, kiekviena neša garso gabalą su eilės numeriu, kad serveris galėtų juos surinkti tvarka, net jei tinklas juos sukeis vietomis.

Jokio nuolatinio soketo, nieko, kas atrodytų kaip tunelis — tik HTTPS užklausos ir atsakymai. Jei proxy leidžia jums naudotis svetaine, leidžia ir tai.

Klaida, kuri būtų išleidusi negyvą funkciją

Štai dalis, verta perskaityti. Fallback turi suveikti, kai WebSocket ryšys išsemia savo bandymus su užblokuoto transporto signatūra — kiekvienas bandymas žlunga ties upgrade, jokių auth ar limito problemų, bent vienas proxy formos atmetimas. Proxy, blokuojantis WebSocket, į upgrade paprastai atsako HTTP 403 Forbidden arba 407.

Problema: mūsų ryšio kode jau buvo taisyklė, kad 403 reiškia fatalią autentifikacijos klaidą — sustok, parodyk ją naudotojui, nekartok. Kas beveik visur teisinga. Bet tai reiškė, kad 403 iš blokuojančio proxy — būtent tas signalas, kuris turėjo paleisti fallback — vietoj to buvo metamas kaip fatali klaida dar prieš tai, kai fallback logika apskritai galėjo pasileisti. Tik grynas ryšio nutrūkimas (uždarymas 1006) prakrisdavo toliau į fallback. Tad funkcija būtų veikusi retam atvejui ir tyliai žlugusi savo tikrajam pagrindiniam taikiniui: įmonės proxy.

Pagavome tai grūdindami leidimą, o ne produkcijoje. Pataisa: 403/407 ties WebSocket upgrade atkarpa dabar traktuojamas kaip atkuriamas, kad ryšio ciklas galėtų išsisemti į fallback — tuo tarpu tikra autentifikacijos nesėkmė (kuri ateina kitaip, po sėkmingo upgrade) vis dar žlunga greitai, lygiai kaip anksčiau. Regresijos testas dabar prisega šį skirtumą: 403 iš užblokuoto proxy turi pereiti į fallback; tikras auth 403 — ne.

Likusi grūdinimo dalis ėjo ta pačia paranojiška linija: laiko limitas kiekvienam išeinančiam POST, kad proxy, kuris užklausą priima, bet niekada neatsako, negalėtų užstrigdyti garso srauto, ir garantija, kad tikra prisijungimo problema niekada negali būti tyliai užmaskuota fallback mechanizmo.

Išbandėme tai prieš tikrą priešišką proxy

Funkcijos, kurios visa paskirtis — išgyventi priešiškuose tinkluose, neįmanoma patikrinti vien vienetiniais testais — vienetiniai testai neturi proxy. Prieš įjungdami ją, praleidome tikrą programą per vietinį reverse proxy, sukonfigūruotą daryti būtent tai, ką daro įmonių proxy: praleisti HTTPS, atmesti WebSocket upgrade su 403.

Pėdsakas žurnaluose — tai kvitas: keturi užblokuoti WebSocket bandymai, atpažinta išsėmimo signatūra, automatinis persijungimas į HTTPS transportą, o paskui sveika 96 sekundžių transkripcijos sesija per gryną HTTPS — 66 transkripto segmentai, nulis praradimų. Failover veikia, nes matėme, kaip jis persijungia.

Trys perkeliamos pamokos

1. „Veikia prastame Wi-Fi" ir „veikia už priešiško proxy" — tai skirtingos garantijos. Vienai reikia pakartotinio prisijungimo; kitai reikia kito transporto. Jų maišymas palieka visą įmonių naudotojų populiaciją tyliai sugedusią.
2. Jūsų klaidų klasifikacija gali paslėpti jūsų pačių funkciją nuo jos pačios. Taisyklė, teisinga 99% atvejų (403 = fatalus auth), buvo lygiai neteisinga tam 1%, kuriam ši funkcija ir egzistavo. Kai pridedate fallback, patikrinkite, ar suveikimo sąlyga apskritai gali pasiekti fallback.
3. Testuokite priešininką, o ne tik laimingą kelią. Vienintelis sąžiningas testas „išgyvena WebSocket blokuojantį proxy" yra WebSocket blokuojantis proxy. Mes jį pastatėme.

GeekBye v2.0.8 išleido HTTPS fallback su vėliavėle ir patikrintą. Apie greta esantį patikimumo darbą skaitykite kodėl jūsų AI užrašinė sustoja prastame Wi-Fi, o apie gretimus šios serijos leidimus — kodėl jūsų AI užrašinė nustoja įrašinėti vidury susitikimo (v2.0.9) ir kodėl AI transkripcija iškraipo techninius terminus (v2.0.11).