Élő átirat, amikor a tűzfal blokkolja a WebSocketeket

Van egy sajátos, őrjítő módja annak, ahogyan a valós idejű átirat elbukik egy vállalati hálózaton. A Wi-Fi-d rendben van. A HTTPS működik — bármelyik weboldalt betöltheted. De az élő átirat egyszerűen... nem indul el, és semmi nem árulja el, miért.

A bűnös a vállalati proxyk egy fajtája, amely engedi a hétköznapi HTTPS forgalmat, de blokkolja a WebSocket upgrade-et — azt a handshake-et, amely egy HTTPS kapcsolatot azzá a tartós, kétirányú csatornává alakít, amelyre a valós idejű átiratnak szüksége van. A proxy számára egy WebSocket úgy néz ki, mint egy nem monitorozott alagút kifelé a hálózatból, ezért megöli. Számodra az átirat csendben tönkrement.

A GeekBye v2.0.8 pontosan ehhez adott hozzá egy automatikus fallbacket — és a megépítése előcsalt egy hibát, amely miatt az egész funkció semmit sem csinált volna.

Miért fallback, nem csak egy retry

A megbízhatatlan hálózatokat már kezeljük. Ha a kapcsolatod megszakad egy session közepén, a GeekBye backoff-fal újracsatlakozik, és pufferelli az audiódat, hogy semmi ne vesszen el — ez egy külön funkció, amelyet a miért áll le az AI jegyzetelőd rossz Wi-Fi-n tárgyal.

De egy blokkolt WebSocket nem megbízhatatlan kapcsolat. Ugyanannak a WebSocketnek az újrapróbálása egy olyan proxyval szemben, amely elutasítja a WebSocketeket, minden alkalommal ugyanúgy bukik, örökre. Az egyetlen megoldás egy másik transport — olyan, amely úgy néz ki, mint a sima HTTPS, amit a proxy már engedélyez.

Így a v2.0.8 átvált egy tiszta HTTPS transportra ugyanazon a hitelesített endpointon:

• Lefelé (a hozzád visszaérkező átiratok): server-sent events — egy hosszú életű HTTPS válasz, amelyet a proxy egy hétköznapi streamelt letöltésnek lát.
• Felfelé (a kimenő audiód): kötegelt POST kérések, mindegyik egy audiódarabot hordozva sorszámmal, hogy a szerver sorrendben újra tudja őket összeállítani, még ha a hálózat át is rendezi őket.

Semmi tartós socket, semmi, ami alagútnak látszik — csak HTTPS kérések és válaszok. Ha egy proxy engedi, hogy weboldalt használj, ezt is engedi.

A hiba, amely egy halott funkciót szállított volna

Íme a rész, amiért érdemes olvasni. A fallbacknek akkor kell elindulnia, amikor a WebSocket kapcsolat kimeríti a próbálkozásait egy blokkolt-transport szignatúrával — minden próbálkozás az upgrade-en bukik, semmi auth vagy quota probléma, legalább egy proxy formájú elutasítás. Egy WebSocketet blokkoló proxy tipikusan egy HTTP 403 Forbidden-nel vagy 407-tel válaszol az upgrade-re.

A probléma: a kapcsolatkódunknak már volt egy szabálya, hogy egy 403 végzetes hitelesítési hibát jelent — állj le, jelezd a felhasználónak, ne próbáld újra. Ami majdnem mindenhol helyes. De azt jelentette, hogy a blokkoló proxytól érkező 403 — pontosan az a jel, amelynek el kellett volna indítania a fallbacket — helyette végzetes hibaként dobódott el még mielőtt a fallback logika egyáltalán lefuthatott volna. Csak egy nyers kapcsolatmegszakadás (egy 1006 close) esett át a fallbackre. Így a funkció a ritka esetben működött volna, és csendben elbukott volna a valódi elsődleges célja esetében: a vállalati proxyval.

Ezt a kiadás megkeményítése közben kaptuk el, nem a produkcióban. A javítás: a WebSocket upgrade szakaszán érkező 403/407 mostantól helyreállíthatóként kezelendő, hogy a kapcsolati ciklus a fallbackbe merülhessen ki — miközben egy valódi hitelesítési hiba (amely másképp érkezik, az upgrade sikere után) továbbra is gyorsan bukik, pontosan úgy, mint korábban. Egy regressziós teszt most rögzíti a különbséget: egy blokkoló proxy 403-jának fallbackre kell váltania; egy valódi auth 403-nak nem.

A megkeményítés többi része ugyanazt a paranoiás vonalat követte: timeout minden felfelé irányuló POST-on, hogy egy proxy, amely elfogad egy kérést, de sosem válaszol, ne tudja megakasztani az audio streamet, és egy garancia, hogy egy valódi sign-in problémát a fallback gépezet soha ne tudjon csendben elfedni.

Egy valódi ellenséges proxy ellen teszteltük

Egy funkció, amelynek egész célja az ellenséges hálózatok túlélése, nem validálható pusztán unit tesztekkel — a unit teszteknek nincsenek proxyjaik. Mielőtt engedélyeztük, átfuttattuk a valódi appot egy helyi reverse proxyn, amelyet pontosan arra állítottunk be, amit a vállalati proxyk csinálnak: továbbítja a HTTPS-t, elutasítja a WebSocket upgrade-eket egy 403-mal.

A logokban a nyom a bizonyíték: négy blokkolt WebSocket próbálkozás, a kimerülési szignatúra felismerve, az automatikus átváltás a HTTPS transportra, majd egy egészséges, 96 másodperces átirat-session tiszta HTTPS-en — 66 átiratszegmens, nulla kiesés. A failover azért működik, mert néztük, ahogy failovert csinál.

Három átvihető tanulság

1. A „rossz Wi-Fi-n működik" és a „ellenséges proxy mögött működik" különböző garanciák. Az egyiknek újracsatlakozás kell; a másiknak másik transport. Ezek összemosása a vállalati felhasználók egész populációját csendben tönkretéve hagyja.
2. A hibaosztályozásod elrejtheti a saját funkciódat önmaga elől. Egy szabály, amely az esetek 99%-ában helyes (403 = végzetes auth), pontosan rossz volt arra az 1%-ra, amelynek a kiszolgálására ez a funkció létezett. Amikor fallbacket adsz hozzá, auditáld, hogy a kiváltó feltétel egyáltalán elérheti-e a fallbacket.
3. Az ellenfelet teszteld, ne csak a happy path-t. Az egyetlen őszinte teszt arra, hogy „túléli a WebSocketet blokkoló proxyt", egy WebSocketet blokkoló proxy. Építettünk egyet.

A GeekBye v2.0.8 flag mögött és validálva szállította a HTTPS fallbacket. A megbízhatósági munkához, amely mellett áll, lásd miért áll le az AI jegyzetelőd rossz Wi-Fi-n, a sorozat szomszédos kiadásaihoz pedig miért állítja le az AI-jegyzetelőd a felvételt a meeting kellős közepén (v2.0.9) és miért hallja félre az AI-átirat a szakkifejezéseket (v2.0.11).