क्रोम 124 वेबसॉकेटस्ट्रीम और रीडेबलस्ट्रीम असिंक्रोन-इटरेशन लॉन्च करता है
क्या हुआ
- क्रोम 124 (स्थिर) दो प्लेटफार्म-स्तरीय स्ट्रीमिंग सुधार जोड़ता है: वेबसॉकेटस्ट्रीम एपीआई (WHATWG स्ट्रीम को वेबसॉकेट्स के साथ एकीकृत करना) और रीडेबलस्ट्रीम के लिए असिंक्रोन-इटरेशन समर्थन। दोनों स्थिर चैनल में आए हैं और क्लाइंट कोड के लिए वेब पर स्ट्रीमिंग I/O को आसान और अधिक मजबूत बनाने के लिए डिज़ाइन किए गए हैं। (developer.chrome.com)
पूर्ण-स्टैक टीमों के लिए यह क्यों महत्वपूर्ण है (व्यावहारिक प्रभाव)
- रीडेबलस्ट्रीम + फॉर-ऑवेट-ऑफ: आप अब एक Response.body या अन्य रीडेबलस्ट्रीम को सीधे असिंक्रोन-इटरेटर प्रोटोकॉल (फॉर अवेट...ऑफ) के साथ उपभोग कर सकते हैं। इससे बहुत सारा getReader()/read() बायलरप्लेट हटा दिया जाता है, क्रमिक पार्सिंग (NDJSON, लाइन-सीमित JSON, स्ट्रीमिंग पार्सर्स) को सरल बनाता है, आकस्मिक बफरिंग को कम करता है, और स्ट्रीमिंग कोड को बहुत स्पष्ट और कम त्रुटि-प्रवण बनाता है।
- वेबसॉकेटस्ट्रीम → बैकप्रेशर और स्ट्रीम्स एकीकरण: वेबसॉकेटस्ट्रीम एक रीडेबलस्ट्रीम और राइटेबलस्ट्रीम जोड़ी को एक सॉकेट के लिए खोले जाने पर उजागर करता है, ताकि क्लाइंट कोड TransformStream, पाइपिंग, और मूल बैकप्रेशर सेमांटिक्स का उपयोग कर सके, न कि ऐड-हॉक बफरिंग। वास्तविक समय के ऐप्स के लिए, यह संदेश कतारबद्धता को कम करता है, क्लाइंट-साइड मेमोरी विस्फोटों को रोकने में मदद करता है, और क्लाइंट स्ट्रीमिंग कोड को स्ट्रीम्स एपीआई के साथ संरेखित करता है जो fetch, file, और media प्रवाह में उपयोग होता है।
- सर्वर-साइड स्ट्रीमिंग के साथ समेकन: सरल क्लाइंट-स्ट्रीम मुहावरे के साथ, अधिक ऐप्स से स्ट्रीमिंग प्रतिक्रियाओं (RSC/SSR टुकड़े, प्रगतिशील JSON) और स्ट्रीमिंग अपलोड को अपनाने की उम्मीद करें। पूर्ण-स्टैक टीमों को दोनों सिरों का अभ्यास करना चाहिए: क्लाइंट फीचर-डिटेक्शन/फॉलबैक और बैकप्रेशर या परिवर्तनीय उपभोग दरों के तहत सर्वर व्यवहार।
छोटे, ठोस उदाहरण
- रीडेबलस्ट्रीम असिंक्रोन-इटरेशन (क्लाइंट):
const res = await fetch('/streaming-endpoint');
for await (const chunk of res.body) {
// chunk एक Uint8Array है; यहां क्रमिक बाइट्स/फ्रेम्स को प्रोसेस करें
}
- वेबसॉकेटस्ट्रीम (क्लाइंट रूपरेखा):
const ws = new WebSocketStream('wss://example.com/ws');
const { readable, writable } = await ws.opened;
// readable एक रीडेबलस्ट्रीम है जिसे आप फॉर-ऑवेट-ऑफ कर सकते हैं
// writable एक राइटेबलस्ट्रीम है जिसमें आप write() या pipeTo() कर सकते हैं
टीमों को अगला क्या करना चाहिए (संक्षिप्त चेकलिस्ट)
- फीचर-डिटेक्ट करें और प्रगतिशील रूप से सुधारें: रीडेबलस्ट्रीम[Symbol.asyncIterator] / वेबसॉकेटस्ट्रीम का पता लगाएं और अनुपस्थित होने पर getReader()/वेबसॉकेट संदेश हैंडलर्स पर वापस जाएं।
- CI में स्ट्रीमिंग परीक्षण जोड़ें: ऐसे परीक्षण जोड़ें जो बड़े स्ट्रीम किए गए उत्तरों और लंबे समय तक चलने वाले वेबसॉकेट सत्रों का उपभोग करें ताकि लोड के तहत मेमोरी या क्रमबद्धता के मुद्दों को पकड़ सकें।
- क्लाइंट पार्सिंग कोड को अपडेट करें: जहां संभव हो, मैन्युअल रीडर लूप को फॉर-ऑवेट-ऑफ के साथ बदलें - इससे बग कम होते हैं और पठनीयता में सुधार होता है।
- वेबसॉकेटस्ट्रीम के लिए ग्रेसफुल डिग्रेडेशन की योजना बनाएं: क्रोमियम के अलावा अन्य ब्राउज़र अभी तक वेबसॉकेटस्ट्रीम प्रदान नहीं कर सकते हैं; एक फॉलबैक रैपर लागू करें जो एक साधारण वेबसॉकेट (बफरिंग + मैन्युअल बैकप्रेशर अनुमानों) पर समान असिंक्रोन/स्ट्रीमिंग अनुबंध को उजागर करता है।
- सर्वर व्यवहार का मूल्यांकन करें: जब एक क्लाइंट बैकप्रेशर-जानकारी वाले लेखन करता है या स्ट्रीम को क्रमिक रूप से उपभोग करता है, तो सुनिश्चित करें कि आपका सर्वर (और प्रॉक्सी) प्रवाह को सही तरीके से संभालता है; अपने वास्तविक-विश्व वेबसॉकेट सर्वर लाइब्रेरी (ws, uWebSockets, Fastify websockets, आदि) के साथ परीक्षण करें ताकि निहित बफरिंग और प्रदर्शन प्रभावों को समझ सकें।
संगतता और चेतावनियाँ
- वेबसॉकेटस्ट्रीम अभी भी नया है और कई दस्तावेजों में प्रयोगात्मक के रूप में चिह्नित है; आज क्रॉस-ब्राउज़र समर्थन सीमित है। रीडेबलस्ट्रीम असिंक्रोन-इटरेशन का व्यापक अपनाना है लेकिन अभी भी पुराने इंजनों के लिए फीचर डिटेक्शन की आवश्यकता है।
- यह न मानें कि एप्लिकेशन-स्तरीय बैकप्रेशर जादुई रूप से सर्वर लोड पैटर्न को ठीक करता है - अंत-से-अंत परीक्षण और दर सीमाओं को तदनुसार डिज़ाइन करें।
सारांश क्रोम 124 का वेबसॉकेटस्ट्रीम और रीडेबलस्ट्रीम असिंक्रोन-इटरेशन छोटे एपीआई परिवर्तन हैं जिनसे स्ट्रीमिंग वर्कलोड के लिए डेवलपर की कार्यक्षमता और विश्वसनीयता में बड़े लाभ मिलते हैं। पूर्ण-स्टैक टीमों को फीचर-डिटेक्टिंग, स्ट्रीमिंग परीक्षण जोड़ने और फॉर-ऑवेट-ऑफ और स्ट्रीम-आधारित वेबसॉकेट कोड को प्रगतिशील रूप से अपनाने की शुरुआत करनी चाहिए, जबकि गैर-समर्थित ब्राउज़रों के लिए मजबूत फॉलबैक प्रदान करें। (developer.chrome.com)
स्रोत: क्रोम 124 रिलीज नोट्स (developer.chrome.com)। (developer.chrome.com)
स्रोत
आगे पढ़ें
Chrome 143 में FedCM में परिवर्तन: संरचित ID दावे, कड़े क्लाइंट मेटाडेटा, और ब्रेकिंग API अपडेट
31 जनवरी 2026Chrome 143 (12 जनवरी, 2026 को प्रकाशित) FedCM पहचान प्रवाह में परिवर्तन करता है: ID दावा टोकन संरचित JSON हो सकते हैं, क्लाइंट_मेटाडेटा सत्यापन लागू किया गया है, और कई API फ़ील्ड स्थानांतरित/नामांकित किए गए हैं — Chrome 145 से पहले माइग्रेशन आवश्यक है।
Undici CVE-2026-22036: अनबाउंड डिकंप्रेशन चेन संसाधन समाप्ति की अनुमति देती है — पैच जारी किए गए
30 जनवरी 202614 जनवरी, 2026 को undici (Node.js HTTP क्लाइंट) के लिए एक सुरक्षा सलाह में एक अनबाउंड डिकंप्रेशन-चेन भेद्यता का वर्णन किया गया है जो उच्च CPU और मेमोरी उपयोग की ओर ले जा सकती है। फुल-स्टैक टीमों को प्रभावित undici संस्करणों को खोजने और अपग्रेड करने और हल्के रनटाइम सुरक्षा जोड़ने की आवश्यकता है।
React Router / Remix CSRF सुरक्षा दोष सर्वर क्रियाओं में (CVE-2026-22030)
29 जनवरी 2026React Router और @remix-run/server-runtime ने सर्वर-साइड क्रिया हैंडलरों और अस्थिर React सर्वर क्रियाओं को प्रभावित करने वाले मध्यम-गंभीर CSRF मुद्दे को पैच किया - जो पूर्ण-स्टैक टीमों को अब जांचना और पैच करना चाहिए।