Reaaliaikainen transkriptio, kun palomuuri estää WebSocketit

Reaaliaikaisella transkriptiolla on yksi tietty, raivostuttava tapa epäonnistua yritysverkossa. Wi-Fisi on kunnossa. HTTPS toimii — voit ladata minkä tahansa sivuston. Mutta reaaliaikainen transkriptio ei vain... käynnisty, eikä mikään kerro sinulle miksi.

Syyllinen on yritysproxyjen luokka, joka sallii tavallisen HTTPS-liikenteen mutta estää WebSocket-päivityksen — kättelyn, joka muuttaa HTTPS-yhteyden pysyväksi, kaksisuuntaiseksi kanavaksi, jota reaaliaikainen transkriptio tarvitsee. Proxyn silmissä WebSocket näyttää valvomattomalta tunnelilta ulos verkosta, joten se tappaa sen. Sinun silmissäsi transkriptio on hiljaa rikki.

GeekBye v2.0.8 lisäsi automaattisen varasiirron juuri tähän — ja sen rakentaminen paljasti bugin, joka olisi saanut koko ominaisuuden tekemään tyhjää.

Miksi varasiirto, ei pelkkä uudelleenyritys

Käsittelemme jo epävakaat verkot. Jos yhteytesi katkeaa kesken istunnon, GeekBye yhdistää uudelleen peräytymisellä ja puskuroi äänesi, joten mitään ei menetetä — se on erillinen ominaisuus, joka käsitellään artikkelissa miksi AI-muistiinpanotyökalusi pysähtyy huonossa Wi-Fissä.

Mutta estetty WebSocket ei ole epävakaa yhteys. Saman WebSocketin uudelleenyrittäminen proxya vastaan, joka kieltäytyy WebSocketeista, epäonnistuu samalla tavalla joka kerta, ikuisesti. Ainoa korjaus on eri siirto — sellainen, joka näyttää tavalliselta HTTPS:ltä, jonka proxy jo sallii.

Joten v2.0.8 vaihtaa puhtaaseen HTTPS-siirtoon saman todennetun päätepisteen kautta:

• Alas (transkriptit takaisin sinulle): server-sent events — pitkäikäinen HTTPS-vastaus, jonka proxy näkee tavallisena striimattuna latauksena.
• Ylös (äänesi ulos): niputetut POST-pyynnöt, joista kukin kantaa ääniosaa järjestysnumerolla, jotta palvelin voi koota ne oikeaan järjestykseen, vaikka verkko järjestäisi ne uudelleen.

Ei pysyvää soketia, ei mitään, joka näyttää tunnelilta — vain HTTPS-pyyntöjä ja -vastauksia. Jos proxy sallii sinun käyttää verkkosivustoa, se sallii tämän.

Bugi, joka olisi julkaissut kuolleen ominaisuuden

Tässä on osa, jonka takia kannattaa lukea. Varasiirron on tarkoitus käynnistyä, kun WebSocket-yhteys kuluttaa loppuun yrityksensä estetyn siirron allekirjoituksella — jokainen yritys epäonnistuu päivityksessä, ei todennus- tai kiintiöongelmaa, vähintään yksi proxyn muotoinen hylkäys. WebSocketin estävä proxy vastaa päivitykseen tyypillisesti HTTP 403 Forbidden- tai 407-koodilla.

Ongelma: yhteyskoodissamme oli jo sääntö, että 403 tarkoittaa kohtalokasta todennusvirhettä — pysähdy, näytä se käyttäjälle, älä yritä uudelleen. Mikä on lähes kaikkialla oikein. Mutta se tarkoitti, että estävän proxyn 403 — juuri se signaali, jonka olisi pitänyt käynnistää varasiirto — heitettiin sen sijaan kohtalokkaana virheenä ennen kuin varasiirron logiikka ehti koskaan ajaa. Vain raaka yhteyden katkeaminen (1006-sulkeutuminen) putosi läpi varasiirtoon. Joten ominaisuus olisi toiminut harvinaisessa tapauksessa ja epäonnistunut hiljaa sen todellisen ensisijaisen kohteen kohdalla: yritysproxyn.

Nappasimme tämän julkaisua kovettaessamme, emme tuotannossa. Korjaus: 403/407 WebSocketin päivitysjalassa käsitellään nyt palautettavana, jotta yhteyssilmukka voi kuluttaa itsensä loppuun varasiirtoon — kun taas aito todennusvika (joka saapuu eri tavalla, sen jälkeen kun päivitys on onnistunut) epäonnistuu edelleen nopeasti, aivan kuten ennenkin. Regressiotesti kiinnittää nyt eron: estetyn proxyn 403:n täytyy vaihtaa varasiirtoon; aidon todennuksen 403:n ei saa.

Loppu kovettamisesta seurasi samaa paranoidista linjaa: aikakatkaisu jokaisessa ylävirran POSTissa, jottei proxy, joka hyväksyy pyynnön mutta ei koskaan vastaa, voi jumittaa äänivirtaa, ja takuu siitä, ettei aitoa kirjautumisongelmaa voi koskaan hiljaa peittää varasiirtokoneisto.

Testasimme sitä aitoa vihamielistä proxya vastaan

Ominaisuutta, jonka koko tarkoitus on selviytyä vihamielisistä verkoista, ei voi validoida pelkillä yksikkötesteillä — yksikkötesteillä ei ole proxyja. Ennen sen käyttöönottoa ajoimme aidon sovelluksen paikallisen käänteisproxyn läpi, joka oli konfiguroitu tekemään juuri sitä, mitä yritysproxyt tekevät: välittämään HTTPS:n, hylkäämään WebSocket-päivitykset 403:lla.

Jälki lokeissa on kuitti: neljä estettyä WebSocket-yritystä, tunnistettu loppumisen allekirjoitus, automaattinen vaihto HTTPS-siirtoon, ja sitten terve 96-sekuntinen transkriptioistunto puhtaan HTTPS:n yli — 66 transkriptiosegmenttiä, nolla pudotusta. Vikasietoinen vaihto toimii, koska katsoimme sen vaihtuvan.

Kolme siirrettävää oppituntia

1. "Se toimii epävakaassa Wi-Fissä" ja "se toimii vihamielisen proxyn takana" ovat eri takuita. Toinen tarvitsee uudelleenyhteyden; toinen tarvitsee eri siirron. Niiden sekoittaminen jättää kokonaisen joukon yrityskäyttäjiä hiljaa rikki.
2. Virheluokittelusi voi piilottaa oman ominaisuutesi siltä itseltään. Sääntö, joka on 99 % ajasta oikein (403 = kohtalokas todennus), oli juuri väärin sen 1 %:n kohdalla, jonka takia tämä ominaisuus oli olemassa. Kun lisäät varasiirron, tarkista, voiko käynnistysehto edes tavoittaa varasiirron.
3. Testaa vastustajaa, ei pelkkää onnellista polkua. Ainoa rehellinen testi "selviää WebSocketin estävästä proxysta" on WebSocketin estävä proxy. Rakensimme sellaisen.

GeekBye v2.0.8 julkaisi HTTPS-varasiirron lippurajattuna ja validoituna. Sen vieressä olevasta luotettavuustyöstä katso miksi AI-muistiinpanotyökalusi pysähtyy huonossa Wi-Fissä, ja tämän sarjan naapurijulkaisuista miksi AI-muistiinpanotyökalusi lopettaa tallennuksen kesken kokouksen (v2.0.9) ja miksi AI-transkriptio kuulee tekniset termit väärin (v2.0.11).