जब फ़ायरवॉल WebSocket को ब्लॉक कर दे, तब लाइव ट्रांसक्रिप्शन का क्या होता है

कॉर्पोरेट नेटवर्क पर रियल-टाइम ट्रांसक्रिप्शन के फेल होने का एक खास, झल्ला देने वाला तरीका है। आपका Wi-Fi ठीक है। HTTPS चल रहा है — कोई भी वेबसाइट खुल जाती है। पर लाइव ट्रांसक्रिप्शन बस… शुरू ही नहीं होती, और कुछ भी नहीं बताता कि क्यों।

गुनहगार एक ऐसी किस्म का कॉर्पोरेट proxy है जो सामान्य HTTPS ट्रैफिक को तो जाने देता है पर WebSocket upgrade को ब्लॉक कर देता है — वह handshake जो एक HTTPS कनेक्शन को उस स्थायी, दोतरफा चैनल में बदलता है जिसकी रियल-टाइम ट्रांसक्रिप्शन को जरूरत होती है। proxy की नज़र में एक WebSocket नेटवर्क से बाहर जाती एक बिना-निगरानी वाली सुरंग जैसा दिखता है, तो वह उसे मार देता है। आपकी नज़र में, ट्रांसक्रिप्शन बस खामोशी से टूटी हुई है।

GeekBye v2.0.8 ने ठीक इसी के लिए एक अपने-आप चलने वाला fallback जोड़ा — और इसे बनाते हुए एक ऐसा बग निकला जो पूरे फीचर से कुछ भी न करवाता।

सिर्फ रीट्राई क्यों नहीं, fallback क्यों

डगमगाते नेटवर्क को हम पहले से संभालते हैं। अगर आपका कनेक्शन सेशन के बीच में गिर जाए, तो GeekBye backoff के साथ दोबारा जुड़ता है और आपके ऑडियो को बफर कर लेता है ताकि कुछ न खोए — वह एक अलग फीचर है, जिसे आपका AI notetaker खराब Wi-Fi पर क्यों रुक जाता है में बताया गया है।

पर एक ब्लॉक किया गया WebSocket डगमगाता कनेक्शन नहीं है। WebSocket को ठुकराने वाले proxy के खिलाफ उसी WebSocket को रीट्राई करना हर बार, हमेशा के लिए, उसी तरह फेल होता है। एकमात्र इलाज है एक अलग ट्रांसपोर्ट — एक ऐसा जो उसी सादे HTTPS जैसा दिखे जिसे proxy पहले से जाने देता है।

तो v2.0.8 उसी authenticated endpoint पर एक प्योर-HTTPS ट्रांसपोर्ट पर fall back करता है:

• डाउनस्ट्रीम (ट्रांसक्रिप्ट जो आपके पास वापस आते हैं): server-sent events — एक लंबा चलने वाला HTTPS रिस्पॉन्स जिसे proxy एक सामान्य स्ट्रीम्ड डाउनलोड की तरह देखता है।
• अपस्ट्रीम (आपका ऑडियो जो बाहर जाता है): बैच्ड POST रिक्वेस्ट, हर एक एक sequence number के साथ ऑडियो का एक चंक ढोता है ताकि नेटवर्क क्रम बदल भी दे तो सर्वर उन्हें सही क्रम में दोबारा जोड़ सके।

कोई स्थायी socket नहीं, सुरंग जैसा दिखने वाला कुछ नहीं — बस HTTPS रिक्वेस्ट और रिस्पॉन्स। अगर कोई proxy आपको एक वेबसाइट इस्तेमाल करने देता है, तो वह इसे भी होने देता है।

वह बग जो एक मरा हुआ फीचर शिप कर देता

यही वह हिस्सा है जो पढ़ने लायक है। fallback को तब ट्रिगर होना चाहिए जब WebSocket कनेक्शन एक ट्रांसपोर्ट-ब्लॉक सिग्नेचर के साथ अपनी कोशिशें खत्म कर दे — हर कोशिश upgrade पर फेल, कोई auth या quota समस्या नहीं, कम-से-कम एक proxy-आकार का इनकार। WebSocket को ब्लॉक करने वाला proxy आमतौर पर upgrade का जवाब एक HTTP 403 Forbidden या 407 से देता है।

समस्या: हमारे कनेक्शन कोड में पहले से एक नियम था कि एक 403 का मतलब है fatal authentication error — रुको, इसे यूज़र को दिखाओ, रीट्राई मत करो। जो लगभग हर जगह सही है। पर इसका मतलब था कि ब्लॉक करने वाले proxy से आया 403 — ठीक वही सिग्नल जिसे fallback ट्रिगर करना चाहिए था — के बजाय, fallback लॉजिक के चलने का मौका मिलने से पहले ही एक fatal error के रूप में फेंका जा रहा था। सिर्फ एक कच्चा कनेक्शन-ड्रॉप (एक 1006 क्लोज) ही fallback तक गिरकर पहुंचता था। तो फीचर उस दुर्लभ मामले के लिए काम करता, और अपने असली मुख्य लक्ष्य — कॉर्पोरेट proxy — के लिए खामोशी से फेल हो जाता।

हमने इसे रिलीज़ को मजबूत करते हुए पकड़ा, प्रोडक्शन में नहीं। फिक्स: WebSocket upgrade चरण पर एक 403/407 अब recoverable माना जाता है ताकि कनेक्शन लूप खत्म होकर fallback में गिर सके — जबकि एक असली authentication फेल्योर (जो अलग तरह से, upgrade सफल होने के बाद आता है) पहले की तरह ही तेज़ी से फेल होता है। एक regression test अब इस फर्क को कील ठोककर पक्का करता है: एक ब्लॉक-proxy 403 को fall back करना ही होगा; एक असली auth 403 को नहीं।

बाकी की मजबूती भी उसी शक्की लाइन पर चली: हर अपस्ट्रीम POST पर एक timeout ताकि कोई proxy जो रिक्वेस्ट स्वीकार तो करे पर कभी जवाब न दे, ऑडियो स्ट्रीम को अटका न सके, और एक गारंटी कि एक असली sign-in समस्या कभी fallback मशीनरी के हाथों खामोशी से ढंकी न जा सके।

हमने इसे एक असली दुश्मन proxy के खिलाफ टेस्ट किया

एक ऐसा फीचर जिसके होने का पूरा मकसद ही दुश्मन नेटवर्कों में टिके रहना है, उसे अकेले यूनिट टेस्ट से वैलिडेट नहीं किया जा सकता — यूनिट टेस्ट में proxy होते ही नहीं। इसे चालू करने से पहले, हमने असली ऐप को एक लोकल रिवर्स proxy से गुज़ारा जिसे ठीक वही करने के लिए कॉन्फिगर किया गया था जो कॉर्पोरेट proxy करते हैं: HTTPS को आगे भेजो, WebSocket upgrade को एक 403 से ठुकरा दो।

लॉग में बना निशान ही रसीद है: चार ब्लॉक की गई WebSocket कोशिशें, पहचानी गई खत्म-होने वाली सिग्नेचर, HTTPS ट्रांसपोर्ट पर अपने-आप स्विच, और फिर प्योर HTTPS पर एक सेहतमंद 96-second ट्रांसक्रिप्शन सेशन — 66 ट्रांसक्रिप्ट सेगमेंट, शून्य ड्रॉप। failover इसलिए काम करता है क्योंकि हमने इसे fail over होते देखा।

तीन आगे ले जाने लायक सबक

1. "यह डगमगाते Wi-Fi पर चलता है" और "यह एक दुश्मन proxy के पीछे चलता है" अलग-अलग गारंटियां हैं। एक को reconnection चाहिए; दूसरे को एक अलग ट्रांसपोर्ट। दोनों को एक कर देना कॉर्पोरेट यूज़र्स की एक पूरी आबादी को खामोशी से टूटा छोड़ देता है।
2. आपका error वर्गीकरण आपके अपने फीचर को उसी से छिपा सकता है। एक नियम जो 99% वक्त सही है (403 = fatal auth) उस 1% के लिए ठीक-ठीक गलत था जिसके लिए यह फीचर था। जब आप एक fallback जोड़ें, तो जांचें कि क्या ट्रिगर की शर्त fallback तक पहुंच भी सकती है।
3. दुश्मन को टेस्ट करो, सिर्फ आसान रास्ते को नहीं। "एक WebSocket-ब्लॉक करने वाले proxy में टिकता है" का इकलौता ईमानदार टेस्ट एक WebSocket-ब्लॉक करने वाला proxy ही है। हमने एक बनाया।

GeekBye v2.0.8 ने HTTPS fallback को flag-गेटेड और वैलिडेटेड रूप में शिप किया। इसके साथ-साथ चलने वाले रिलायबिलिटी काम के लिए देखें आपका AI notetaker खराब Wi-Fi पर क्यों रुक जाता है, और इस सीरीज़ की पड़ोसी रिलीज़ों के लिए देखें आपका AI notetaker मीटिंग के बीच में रिकॉर्डिंग क्यों बंद कर देता है (v2.0.9) और AI ट्रांसक्रिप्शन तकनीकी शब्दों को गलत क्यों सुनता है (v2.0.11)।