Reaalajas transkriptsioon, kui tulemüür blokeerib WebSockets

Reaalajas transkriptsioonil on ettevõtte võrgus üks konkreetne, hulluksajav viis ebaõnnestuda. Sinu Wi-Fi on korras. HTTPS töötab — sa saad avada ükskõik millise veebisaidi. Aga reaalajas transkriptsioon lihtsalt... ei käivitu, ja miski ei ütle sulle, miks.

Süüdlane on ettevõtte proxyde klass, mis lubab tavalist HTTPS-liiklust, kuid blokeerib WebSocketi täienduse — käepigistuse, mis muudab HTTPS-ühenduse püsivaks, kahesuunaliseks kanaliks, mida reaalajas transkriptsioon vajab. Proxy silmis näeb WebSocket välja nagu jälgimata tunnel võrgust välja, nii et see tapab selle. Sinu jaoks on transkriptsioon vaikselt katki.

GeekBye v2.0.8 lisas automaatse varulahenduse just selleks — ja selle ehitamine tõi välja vea, mis oleks pannud kogu funktsiooni mitte midagi tegema.

Miks varutransport, mitte lihtsalt uus katse

Me juba käsitleme ebakindlaid võrke. Kui su ühendus katkeb keset seanssi, taasühendub GeekBye taganemisega ja puhverdab su heli, nii et midagi ei kao — see on eraldi funktsioon, mida kirjeldab miks su AI-märkmik peatub halva Wi-Fi korral.

Aga blokeeritud WebSocket ei ole ebakindel ühendus. Sama WebSocketi uuesti proovimine proxy vastu, mis WebSocketitest keeldub, ebaõnnestub iga kord ühtmoodi, igavesti. Ainus lahendus on teistsugune transport — selline, mis näeb välja nagu tavaline HTTPS, mida proxy juba lubab.

Nii et v2.0.8 lülitub puhtale HTTPS-transpordile sama autenditud lõpp-punkti kaudu:

• Alla (transkriptid, mis tulevad sulle tagasi): server-sent events — pikaealine HTTPS-vastus, mille proxy näeb tavalise voogedastatud allalaadimisena.
• Üles (su heli, mis läheb välja): kimpudena POST-päringud, igaüks kannab heli tükki järjekorranumbriga, nii et server saab need õiges järjekorras kokku panna isegi siis, kui võrk need ümber järjestab.

Ei mingit püsivat soklit, mitte midagi, mis näeks välja nagu tunnel — ainult HTTPS-päringud ja -vastused. Kui proxy lubab sul veebisaiti kasutada, lubab see ka seda.

Viga, mis oleks väljastanud surnud funktsiooni

Siin on osa, mille pärast tasub lugeda. Varutransport peaks käivituma, kui WebSocketi ühendus ammendab oma katsed blokeeritud transpordi allkirjaga — iga katse ebaõnnestub täiendusel, ei mingit autentimis- ega kvoodiprobleemi, vähemalt üks proxy-kujuline tagasilükkamine. WebSocketti blokeeriv proxy vastab täiendusele tavaliselt HTTP 403 Forbidden või 407.

Probleem: meie ühenduskoodil oli juba reegel, et 403 tähendab fataalset autentimisviga — peatu, näita seda kasutajale, ära proovi uuesti. Mis on peaaegu igal pool õige. Aga see tähendas, et 403 blokeerivalt proxylt — täpselt see signaal, mis oleks pidanud varutranspordi käivitama — visati hoopis fataalse veana enne, kui varutranspordi loogika üldse jooksma sai. Ainult toores ühenduskatkestus (1006 sulgemine) kukkus läbi varutranspordini. Nii et funktsioon oleks töötanud harval juhul ja vaikselt ebaõnnestunud oma tegeliku peamise sihtmärgi puhul: ettevõtte proxy.

Me püüdsime selle kinni väljalaset karastades, mitte tootmises. Parandus: 403/407 WebSocketi täienduse jalal käsitletakse nüüd taastatavana, nii et ühendustsükkel saab ammenduda varutransporti — samas kui tõeline autentimistõrge (mis saabub teisiti, pärast seda, kui täiendus on õnnestunud) ebaõnnestub endiselt kiiresti, täpselt nagu varem. Regressioonitest fikseerib nüüd erinevuse: blokeeritud proxy 403 peab lülituma varutranspordile; tõeline autentimise 403 ei tohi.

Ülejäänud karastamine järgnes samale paranoilisele joonele: ajalõpp igal ülesvoolu POST-il, et proxy, mis päringu vastu võtab, kuid ei vasta kunagi, ei saaks helivoogu kinni panna, ja garantii, et tõelist sisselogimisprobleemi ei saa kunagi vaikselt maskeerida varutranspordi masinavärk.

Me testisime seda päris vaenuliku proxy vastu

Funktsiooni, mille kogu eesmärk on ellu jääda vaenulikes võrkudes, ei saa valideerida ainult ühiktestidega — ühiktestidel pole proxysid. Enne selle lubamist ajasime päris rakenduse läbi lokaalse pöördproxy, mis oli seadistatud tegema täpselt seda, mida ettevõtte proxyd teevad: edastama HTTPS-i, lükkama WebSocketi täiendused tagasi 403-ga.

Jälg logides on kviitung: neli blokeeritud WebSocketi katset, ammendumise allkiri tuvastatud, automaatne üleminek HTTPS-transpordile, ja siis terve 96-sekundine transkriptsiooniseanss puhta HTTPS-i kaudu — 66 transkriptsioonisegmenti, null kadu. Tõrkesiire töötab, sest me nägime, kuidas see tõrkesiirdas.

Kolm ülekantavat õppetundi

1. "See töötab ebakindla Wi-Fi korral" ja "see töötab vaenuliku proxy taga" on erinevad garantiid. Üks vajab taasühendumist; teine vajab teistsugust transporti. Nende segiajamine jätab terve hulga ettevõtte kasutajaid vaikselt katki.
2. Sinu veaklassifikatsioon võib peita su enda funktsiooni tema enda eest. Reegel, mis on 99% ajast õige (403 = fataalne autentimine), oli täpselt vale selle 1% jaoks, mille jaoks see funktsioon eksisteeris. Kui lisad varutranspordi, kontrolli, kas käivitustingimus saab varutranspordini üldse jõuda.
3. Testi vastast, mitte ainult õnnelikku rada. Ainus aus test "jääb ellu WebSocketti blokeeriva proxy vastu" on WebSocketti blokeeriv proxy. Me ehitasime ühe.

GeekBye v2.0.8 saatis välja HTTPS-varutranspordi lipuga piiratud ja valideeritud. Töökindluse töö kohta, mis selle kõrval seisab, vaata miks su AI-märkmik peatub halva Wi-Fi korral, ja selle sarja naaberväljalasete kohta miks su AI-märkmik lõpetab salvestamise keset koosolekut (v2.0.9) ja miks AI-transkriptsioon kuuleb tehnilisi termineid valesti (v2.0.11).