फ़्रंटएंड इंटरव्यू: आप Compression Dictionary Transport को सुरक्षित रूप से कैनरी (canary) कैसे करेंगे?

प्रश्न और संदर्भ

एक दस्तावेज़ीकरण साइट हर रिलीज़ पर समान HTML, CSS और JavaScript उत्पन्न करती है। टीम चाहती है कि दोहराए जाने वाले बाइट्स को कम करने के लिए बाद के रिस्पॉन्स पहले के रिस्पॉन्स को Brotli या Zstandard डिक्शनरी के रूप में पुन: उपयोग करें, लेकिन ब्राउज़र समर्थन एक समान नहीं है और कुछ रिस्पॉन्स में निजी उपयोगकर्ता डेटा होता है। Compression Dictionary Transport का उपयोग करके एक कैनरी, कैश और सुरक्षा योजना डिज़ाइन करें।

RFC 9842 एक ऐसे फ़्लो को परिभाषित करता है जिसमें एक रिस्पॉन्स Use-As-Dictionary के साथ एक डिक्शनरी का विज्ञापन करता है, क्लाइंट Available-Dictionary के साथ एक उपलब्ध डिक्शनरी की पेशकश करता है, और दोनों पक्ष एक डिक्शनरी कंटेंट एन्कोडिंग पर बातचीत (negotiate) करते हैं। विनिर्देश के लिए HTTPS सुरक्षित संदर्भों की आवश्यकता होती है; MDN वर्तमान में इस क्षमता को Limited availability के रूप में लेबल करता है, इसलिए यह प्रत्येक ब्राउज़र के लिए एक अनिवार्य पथ नहीं हो सकता है।

इंटरव्यूअर क्या परीक्षण कर रहा है

क्या आप डिक्शनरी पंजीकरण, मिलान, हैश वार्ता, एन्कोडिंग चयन और सामान्य-कम्प्रेशन फ़ॉलबैक की व्याख्या कर सकते हैं?
क्या आप फ़्रेशनेस, कैश कीज़, रिलीज़ वर्ज़न, CDNs और नोड्स के बीच निरंतरता (consistency) को संभाल सकते हैं?
क्या आप साझा डिक्शनरी से सामग्री-अनुमान (content-inference) या कम्प्रेशन साइड-चैनल जोखिम को पहचान सकते हैं?
क्या आप ब्राउज़र क्षमता, HTTPS और रिस्पॉन्स पठनीयता के इर्द-गिर्द प्रोग्रेसिव एन्हांसमेंट डिज़ाइन कर सकते हैं?
क्या आप त्रुटियों या गोपनीयता जोखिम को बढ़ाए बिना बाइट बचत साबित कर सकते हैं?

पहले स्पष्ट करने योग्य सवाल

क्या लक्षित ब्राउज़र, WebViews, प्रॉक्सी और CDN प्रासंगिक डिक्शनरी एन्कोडिंग का समर्थन करते हैं? क्या रोलआउट केवल Chromium-only हो सकता है?
कौन से रिस्पॉन्स सार्वजनिक, समान-मूल (same-origin), और दोहराव वाले हैं, और किनमें उपयोगकर्ता, टेनेंट, या प्राधिकरण डेटा शामिल है?
डिक्शनरी कौन बनाता है, हस्ताक्षरित करता है, समाप्त करता है और रोलबैक करता है, और क्या रिलीज़ वर्ज़न संसाधन हैश से बंधे हैं?
क्या कैश भाषा, टेनेंट, प्राधिकरण स्थिति और कंटेंट एन्कोडिंग द्वारा अलग किए गए हैं?
क्या साइट पहले से ही Brotli, Zstandard, ETag, Early Hints, या service-worker कैशिंग का उपयोग करती है?

30-सेकंड का उत्तर

"मैं ब्राउज़र क्षमता और संवेदनशीलता के आधार पर सार्वजनिक, समान-मूल, अत्यधिक दोहराव वाले संसाधनों का चयन करूँगा। HTTPS पर, सर्वर Use-As-Dictionary के साथ एक वर्ज़न वाली डिक्शनरी का विज्ञापन करता है; Available-Dictionary के बाद, यह dcb, dcz, या सामान्य Brotli/gzip चुनता है। डिक्शनरी और सामग्री वर्ज़न, हैश और कैश वेरिएंट अलग रहते हैं, और संवेदनशील रिस्पॉन्स डिक्शनरी साझा नहीं करते हैं। मैं Chromium और एक छोटे संसाधन सेट के साथ कैनरी करूँगा, बाइट्स, डिकोड त्रुटियों, कैश हिट्स और गोपनीयता चेतावनियों को मापूँगा, और जब भी समर्थन या सत्यापन विफल हो, तो सामान्य एन्कोडिंग पर फ़ॉलबैक करूँगा।"

चरण-दर-चरण गहन विश्लेषण

सही संसाधनों का चयन करें। स्थिर, सार्वजनिक, समान-मूल, वर्ज़न-स्थिर संसाधनों से शुरुआत करें। व्यक्तिगत HTML, खाता डेटा, क्रॉस-टेनेंट रिस्पॉन्स और रहस्यों (secrets) को बाहर रखें। अतिरिक्त जटिलता को स्वीकार करने से पहले दोहराव और डिक्शनरी लाभ को मापें।

नेगोशिएशन फ़्लो बनाएं। एक रिस्पॉन्स मैच, प्रकार, पहचानकर्ता और फ़्रेशनेस घोषित करने के लिए Use-As-Dictionary का उपयोग करता है। मैच वाला क्लाइंट एक Available-Dictionary हैश भेजता है और Accept-Encoding में डिक्शनरी एन्कोडिंग का विज्ञापन करता है। सर्वर dcb या dcz केवल तभी लौटाता है जब दोनों पक्ष इसका समर्थन करते हैं और डिक्शनरी ताज़ा होती है; अन्यथा यह सामान्य एन्कोडिंग का उपयोग करता है।

http

HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"

HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary

निरंतरता सीमा तय करें। डिक्शनरी ID, संसाधन वर्ज़न और सामग्री हैश एक रिलीज़ आर्टिफ़ैक्ट में होते हैं। प्रत्येक CDN नोड को समान डिक्शनरी प्राप्त होनी चाहिए; आधे नोड्स को पुरानी डिक्शनरी नहीं लौटानी चाहिए जबकि बाकी नई एन्कोडिंग का उपयोग करते हैं। Vary और कैश कीज़ को उन अनुरोध हेडर को कवर करना चाहिए जो निरूपण (representation) को बदलते हैं, जिससे डिक्शनरी रिस्पॉन्स को असमर्थित क्लाइंट तक पहुंचने से रोका जा सके।

फ़्रेशनेस और रोलबैक को संभालें। जब कोई डिक्शनरी समाप्त हो जाती है, रद्द कर दी जाती है, या सामग्री वर्ज़न से मेल नहीं खाती है, तो उसका विज्ञापन करना बंद करें और सामान्य कम्प्रेशन पर फ़ॉलबैक करें। एक निश्चित रिटायरमेंट समय के साथ नियंत्रित ओवरलैप विंडो के लिए पुरानी डिक्शनरी रखें। रोलबैक को विज्ञापन हटाना चाहिए, CDN वेरिएंट को पर्ज करना चाहिए और Brotli/gzip को पुनर्स्थापित करना चाहिए; इसे क्लाइंट द्वारा कैश साफ़ करने पर निर्भर नहीं होना चाहिए।

गोपनीयता जोखिम को अलग करें। डिक्शनरी सामग्री को समान-मूल सार्वजनिक संसाधनों की तरह सुरक्षित रखें। यदि कोई हमलावर इनपुट के हिस्से को नियंत्रित करता है और कंप्रेस किए गए आकारों का निरीक्षण कर सकता है, तो दोहराए गए सबस्ट्रिंग डिक्शनरी या रिस्पॉन्स सामग्री को प्रकट कर सकते हैं। रहस्यों को हमलावर द्वारा नियंत्रित टेक्स्ट के समान कम्प्रेशन संदर्भ से बाहर रखें, और आवश्यकता पड़ने पर डिक्शनरी कम्प्रेशन को अक्षम करें। HTTPS ट्रांसपोर्ट की सुरक्षा करता है लेकिन कम्प्रेशन साइड चैनलों को नहीं हटाता है।

प्रोग्रेसिव एन्हांसमेंट का उपयोग करें। क्षमता या वार्ता विफलता Brotli, gzip, या एक असम्पीडित (uncompressed) रिस्पॉन्स के साथ जारी रहती है। एक छोटे स्थिर-संसाधन और ब्राउज़र कोहोर्ट के साथ शुरुआत करें। Content-Encoding वितरण, स्थानांतरित बाइट्स, TTFB, डिकोड त्रुटियों, कैश हिट्स और फ़ॉलबैक दर की तुलना करें; यदि लाभ अस्थिर हैं तो सुविधा वापस लें।

मॉडल उत्तर

मैं पहले रोलआउट को उच्च दोहराव वाले सार्वजनिक, समान-मूल, वर्ज़न वाले स्थिर संसाधनों तक सीमित करूँगा, जिसमें व्यक्तिगत HTML, टेनेंट डेटा और रहस्यों को शामिल नहीं किया जाएगा। HTTPS पर, सर्वर Use-As-Dictionary के माध्यम से एक ID, मैच स्कोप और समाप्ति के साथ एक डिक्शनरी का विज्ञापन करता है। क्लाइंट द्वारा Available-Dictionary भेजने और Accept-Encoding पर बातचीत करने के बाद ही सर्वर dcb या dcz लौटाएगा; असमर्थित क्लाइंट, बासी (stale) डिक्शनरी और हैश बेमेल सामान्य Brotli/gzip का उपयोग करते हैं।

रिलीज़ आर्टिफ़ैक्ट में डिक्शनरी, संसाधन हैश और CDN कैश वेरिएंट शामिल होंगे ताकि प्रत्येक नोड सुसंगत रहे। Vary एन्कोडिंग और डिक्शनरी अनुरोध हेडर को अलग करता है। मैं कभी भी हमलावर द्वारा नियंत्रित इनपुट और रहस्यों को एक ही कम्प्रेशन संदर्भ में नहीं रखूँगा; HTTPS आकार-आधारित साइड चैनलों को समाप्त नहीं करता है। कैनरी Chromium और एक छोटे स्थिर सेट के साथ शुरू होता है, जो बचाए गए बाइट्स, कैश हिट्स, डिकोड त्रुटियों, फ़ॉलबैक और गोपनीयता अलर्ट को मापता है। एक रोलबैक डिक्शनरी विज्ञापन को हटा देता है और सामान्य एन्कोडिंग को पुनर्स्थापित करता है।

सामान्य गलतियाँ

लक्षण: प्रत्येक रिस्पॉन्स के लिए साझा डिक्शनरी सक्षम करना → यह क्यों विफल होता है: व्यक्तिगत या संवेदनशील डेटा एक अनुमान लगाने योग्य कम्प्रेशन संदर्भ में प्रवेश करता है → समाधान: केवल सार्वजनिक स्थिर संसाधनों का उपयोग करें और संवेदनशील रिस्पॉन्स के लिए सामान्य कम्प्रेशन का उपयोग करें।
लक्षण: केवल Accept-Encoding की जाँच करना और डिक्शनरी हैश और फ़्रेशनेस को अनदेखा करना → यह क्यों विफल होता है: क्लाइंट गलत डिक्शनरी का उपयोग कर सकता है या डिकोड करने में विफल हो सकता है → समाधान: ID, हैश, वर्ज़न और समाप्ति को बाइंड करें।
लक्षण: CDN पर केवल URL द्वारा कैश करना → यह क्यों विफल होता है: एक डिक्शनरी रिस्पॉन्स एक असमर्थित क्लाइंट तक पहुँच सकता है → समाधान: Vary और कैश कीज़ के साथ एन्कोडिंग, डिक्शनरी हेडर और संसाधन वर्ज़न को अलग करें।
लक्षण: HTTPS को पूर्ण सुरक्षा गारंटी मानना → यह क्यों विफल होता है: कम्प्रेशन साइड चैनल अभी भी दोहराए गए सबस्ट्रिंग को प्रकट कर सकते हैं → समाधान: हमलावर-नियंत्रित इनपुट को रहस्यों से अलग करें और आवश्यकता पड़ने पर डिक्शनरी कम्प्रेशन को अक्षम करें।

अनुवर्ती प्रश्न और उत्तर

क्या होता है जब कोई ब्राउज़र इसका समर्थन नहीं करता है?

सर्वर केवल सफल डिक्शनरी वार्ता के बाद ही dcb या dcz लौटाता है। अन्य अनुरोध Brotli, gzip, या बिना किसी कम्प्रेशन के जारी रहते हैं; फ़ॉलबैक की निगरानी करें और पेज तक पहुँचने के लिए कभी भी अपग्रेड की आवश्यकता न रखें।

एक डिक्शनरी को कितने समय तक सक्रिय रहना चाहिए?

रिलीज़ की आवृत्ति, दोहराव लाभ और निरसन गति से लाइफ़टाइम निर्धारित करें, और रिलीज़ नीति में इस विकल्प को एनकोड करें। स्थिर-वर्ज़न परिवर्तनों के दौरान एक छोटे ओवरलैप का उपयोग करें, फिर पुरानी डिक्शनरी को अनिश्चित काल तक रखने के बजाय उसे रिटायर करें और CDN वेरिएंट को पर्ज करें।

आप डिकोडिंग और कैश शुद्धता का परीक्षण कैसे करते हैं?

समर्थन करने वाले और समर्थन न करने वाले ब्राउज़र, HTTP/1.1, HTTP/2, विभिन्न CDN नोड्स, और कोल्ड और वार्म कैश का परीक्षण करें। केवल कम्प्रेशन अनुपात ही नहीं, बल्कि Vary, सामग्री हैश, डिकोड किए गए बाइट्स, 304 रिस्पॉन्स, ऑरिजिन फ़ेच और सामान्य-एन्कोडिंग फ़ॉलबैक को सत्यापित करें।

कौन से संकेत आपको इसे तुरंत अक्षम करने के लिए प्रेरित करते हैं?

क्रॉस-यूज़र सामग्री मिश्रण, डिक्शनरी हैश बेमेल, डिकोड त्रुटियां, कैश पॉइज़निंग, असामान्य कंप्रेस किए गए आकार, या गोपनीयता-स्कैन अलर्ट मिलने पर Use-As-Dictionary को तुरंत हटा देना चाहिए। सामान्य एन्कोडिंग को पुनर्स्थापित करें और घटना के मेट्रिक्स को सुरक्षित रखें।

संदर्भ

Compression Dictionary Transport (RFC 9842)
MDN Compression Dictionary Transport
डेवलपर्स के लिए Chrome: कम्प्रेशन डिक्शनरी के साथ Google खोज में सुधार
Chromium Compression Dictionary Transport दस्तावेज़ीकरण

इंटरव्यू चेकलिस्ट

सार्वजनिक स्थिर-संसाधन चयन और वार्ता हेडर से शुरुआत करें। फिर डिक्शनरी वर्ज़न, कैश कीज़, HTTPS, साइड चैनल, प्रोग्रेसिव एन्हांसमेंट और रोलबैक को कवर करें। बाइट, कैश और त्रुटि मेट्रिक्स के साथ लाभ को मान्य करें।

एक वाक्य में मुख्य सीख

साझा डिक्शनरी केवल तभी दोहराए गए बाइट्स को कम करती हैं जब संसाधन अलगाव, वर्ज़न हैश, ब्राउज़र फ़ॉलबैक और गोपनीयता सुरक्षा उपाय सभी मौजूद हों।