आम तौर पर, डेटा को स्टोर करके कैश मेमोरी से परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इससे, उसी डेटा के लिए आने वाले अनुरोधों को तेज़ी से पूरा किया जा सकता है. उदाहरण के लिए, नेटवर्क से कैश मेमोरी में सेव किया गया संसाधन, सर्वर से रीडायरेक्ट होने से बचा सकता है. कैश मेमोरी में सेव किए गए कैलकुलेशन के नतीजे से, उसी कैलकुलेशन को दोबारा करने में लगने वाला समय बच सकता है.
Chrome में, कैश मेकेनिज्म का इस्तेमाल अलग-अलग तरीकों से किया जाता है. एचटीटीपी कैश इसका एक उदाहरण है.
फ़िलहाल, Chrome का एचटीटीपी कैश मेमोरी कैसे काम करता है
Chrome के 85 वर्शन से, नेटवर्क से फ़ेच किए गए संसाधनों को कैश मेमोरी में सेव किया जाता है. इसके लिए, संसाधनों के यूआरएल को कैश मेमोरी में सेव करने के लिए कुंजी के तौर पर इस्तेमाल किया जाता है. (कैश मेमोरी कुंजी का इस्तेमाल, कैश मेमोरी में सेव किए गए संसाधन की पहचान करने के लिए किया जाता है.)
इस उदाहरण में बताया गया है कि एक इमेज को कैश मेमोरी में कैसे सेव किया जाता है और तीन अलग-अलग संदर्भों में कैसे इस्तेमाल किया जाता है:
https://x.example/doge.png }
कोई उपयोगकर्ता किसी ऐसे पेज (https://a.example) पर जाता है जो किसी इमेज (https://x.example/doge.png) का अनुरोध करता है. इमेज का अनुरोध नेटवर्क से किया जाता है और https://x.example/doge.png को पासकोड के तौर पर इस्तेमाल करके कैश मेमोरी में सेव किया जाता है.
https://x.example/doge.png }
वही उपयोगकर्ता किसी दूसरे पेज (https://b.example) पर जाता है, जो उसी इमेज (https://x.example/doge.png) का अनुरोध करता है. ब्राउज़र, अपने एचटीटीपी कैश मेमोरी में यह देखने के लिए जांच करता है कि क्या उसके पास पहले से ही यह संसाधन कैश मेमोरी में सेव है. इसके लिए, वह इमेज के यूआरएल को पासकोड के तौर पर इस्तेमाल करता है. ब्राउज़र को अपने कैश मेमोरी में मैच मिलता है, इसलिए वह संसाधन के कैश मेमोरी में सेव किए गए वर्शन का इस्तेमाल करता है.
https://x.example/doge.png }
भले ही, इमेज को iframe से लोड किया गया हो. अगर उपयोगकर्ता, iframe (https://d.example) वाली किसी दूसरी वेबसाइट (https://c.example) पर जाता है और iframe उसी इमेज (https://x.example/doge.png) का अनुरोध करता है, तो ब्राउज़र अब भी अपनी कैश मेमोरी से इमेज लोड कर सकता है. ऐसा इसलिए होता है, क्योंकि सभी पेजों पर कैश मेमोरी का पासकोड एक ही होता है.
परफ़ॉर्मेंस के लिहाज़ से, यह तरीका लंबे समय से अच्छा काम कर रहा है. हालांकि, एचटीटीपी अनुरोधों का जवाब देने में वेबसाइट को लगने वाला समय बता सकता है कि ब्राउज़र ने पहले भी उसी संसाधन को ऐक्सेस किया है. इससे ब्राउज़र को सुरक्षा और निजता से जुड़े हमलों का सामना करना पड़ सकता है. जैसे:
- यह पता लगाना कि उपयोगकर्ता ने किसी खास साइट पर विज़िट किया है या नहीं: कोई अटैक करने वाला व्यक्ति, उपयोगकर्ता के ब्राउज़िंग इतिहास का पता लगा सकता है. इसके लिए, वह यह देखता है कि कैश मेमोरी में कोई ऐसा रिसॉर्स है या नहीं जो किसी खास साइट या साइटों के ग्रुप के लिए खास हो.
- क्रॉस-साइट सर्च अटैक: अगर कोई व्यक्ति यह पता लगाना चाहता है कि उपयोगकर्ता के खोज नतीजों में कोई स्ट्रिंग मौजूद है या नहीं, तो वह यह देख सकता है कि किसी वेबसाइट के इस्तेमाल की गई 'कोई खोज नतीजा नहीं' इमेज, ब्राउज़र के कैश मेमोरी में मौजूद है या नहीं.
- कई साइटों के डेटा को ट्रैक करना: कैश मेमोरी का इस्तेमाल, कई साइटों के डेटा को ट्रैक करने के तरीके के तौर पर, कुकी जैसे आइडेंटिफ़ायर को सेव करने के लिए किया जा सकता है.
इन खतरों को कम करने के लिए, Chrome 86 से Chrome अपने एचटीटीपी कैश को अलग-अलग हिस्सों में बांट देगा.
कैश मेमोरी को अलग-अलग हिस्सों में बांटने से, Chrome के एचटीटीपी कैश पर क्या असर पड़ेगा?
कैश मेमोरी को अलग-अलग हिस्सों में बांटने की सुविधा की मदद से, कैश मेमोरी में सेव किए गए रिसॉर्स को रिसॉर्स यूआरएल के साथ-साथ, नए "नेटवर्क आइसोलेशन पासकोड" का इस्तेमाल करके पासकोड दिया जाएगा. नेटवर्क आइसोलेशन पासकोड, टॉप-लेवल साइट और मौजूदा फ़्रेम साइट से बना होता है.
कैश मेमोरी को अलग-अलग कॉन्टेक्स्ट में बांटने का तरीका जानने के लिए, पिछले उदाहरण को फिर से देखें:
https://a.example, https://a.example, https://x.example/doge.png }
कोई उपयोगकर्ता किसी ऐसे पेज (https://a.example) पर जाता है जिस पर किसी इमेज (https://x.example/doge.png) का अनुरोध किया जाता है. इस मामले में, नेटवर्क से इमेज का अनुरोध किया जाता है और उसे https://a.example (टॉप-लेवल साइट), https://a.example (मौजूदा फ़्रेम साइट), और https://x.example/doge.png (संसाधन यूआरएल) को कुंजी के तौर पर इस्तेमाल करके कैश मेमोरी में सेव किया जाता है. (ध्यान दें कि जब रिसॉर्स का अनुरोध टॉप-लेवल फ़्रेम से किया जाता है, तो नेटवर्क आइसोलेशन पासकोड में टॉप-लेवल साइट और मौजूदा फ़्रेम साइट एक ही होती है.)
https://b.example, https://b.example, https://x.example/doge.png }
वही उपयोगकर्ता किसी दूसरे पेज (https://b.example) पर जाता है, जो उसी इमेज (https://x.example/doge.png) का अनुरोध करता है. हालांकि, पिछले उदाहरण में वही इमेज लोड की गई थी, लेकिन कुंजी मेल न खाने की वजह से इसे कैश मेमोरी में सेव नहीं किया जाएगा.
इमेज का अनुरोध नेटवर्क से किया जाता है और उसे https://b.example,
https://b.example, और https://x.example/doge.png को पासकोड के तौर पर इस्तेमाल करके कैश मेमोरी में सेव किया जाता है.
https://a.example, https://a.example, https://x.example/doge.png }
अब उपयोगकर्ता https://a.example पर वापस आता है, लेकिन इस बार इमेज (https://x.example/doge.png) को iframe में एम्बेड किया गया है. इस मामले में,
कुंजी एक ट्यूपल है, जिसमें https://a.example, https://a.example, और https://x.example/doge.png शामिल हैं और कैश मेमोरी में हिट होता है. ध्यान दें कि जब टॉप-लेवल साइट और iframe एक ही साइट हों, तो टॉप-लेवल फ़्रेम में कैश मेमोरी में सेव किए गए रिसॉर्स का इस्तेमाल किया जा सकता है.
https://a.example, https://c.example, https://x.example/doge.png }
उपयोगकर्ता https://a.example पर वापस आ गया है, लेकिन इस बार इमेज को https://c.example के iframe में होस्ट किया गया है.
इस मामले में, इमेज को नेटवर्क से डाउनलोड किया जाता है, क्योंकि कैश मेमोरी में ऐसा कोई संसाधन नहीं है जो https://a.example,
https://c.example, और https://x.example/doge.png से मिलता-जुलता हो.
https://a.example, https://c.example, https://x.example/doge.png }
अगर डोमेन में सबडोमेन या पोर्ट नंबर शामिल है, तो क्या होगा? उपयोगकर्ता https://subdomain.a.example पर जाता है, जो एक iframe (https://c.example:8080) एम्बेड करता है. यह iframe, इमेज का अनुरोध करता है.
कुंजी, "scheme://eTLD+1" के आधार पर बनाई जाती है. इसलिए, सबडोमेन और पोर्ट नंबर को अनदेखा किया जाता है. इसलिए, कैश मेमोरी हिट होती है.
https://a.example, https://c.example, https://x.example/doge.png }
अगर iframe को कई बार नेस्ट किया जाता है, तो क्या होगा? उपयोगकर्ता https://a.example पर जाता है, जो एक iframe (https://b.example) को एम्बेड करता है. यह iframe, एक और iframe (https://c.example) को एम्बेड करता है, जो आखिर में इमेज का अनुरोध करता है.
कुंजी को टॉप-फ़्रेम (https://a.example) और संसाधन (https://c.example) को लोड करने वाले तुरंत फ़्रेम से लिया जाता है. इसलिए, कैश मेमोरी में हिट होता है.
अक्सर पूछे जाने वाले सवाल
क्या यह सुविधा मेरे Chrome पर पहले से चालू है? मैं कैसे देखूं?
यह सुविधा 2020 के आखिर तक रोल आउट की जाएगी. यह देखने के लिए कि आपके Chrome इंस्टेंस में यह सुविधा पहले से उपलब्ध है या नहीं:
chrome://net-export/खोलें और डिस्क पर लॉगिंग शुरू करें दबाएं.- अपने कंप्यूटर पर लॉग फ़ाइल सेव करने की जगह तय करें.
- Chrome पर एक मिनट तक वेब ब्राउज़ करें.
chrome://net-export/पर वापस जाएं और लॉगिंग बंद करें दबाएं.https://netlog-viewer.appspot.com/#importपर जाएं.- फ़ाइल चुनें दबाएं और सेव की गई लॉग फ़ाइल को पास करें.
आपको लॉग फ़ाइल का आउटपुट दिखेगा.
उसी पेज पर, SplitCacheByNetworkIsolationKey ढूंढें. अगर इसके बाद Experiment_[****] दिखता है, तो इसका मतलब है कि आपके Chrome पर एचटीटीपी कैश मेमोरी का बंटवारा करने की सुविधा चालू है. अगर इसके बाद Control_[****] या Default_[****] दिखता है, तो इसका मतलब है कि यह सुविधा चालू नहीं है.
मैं अपने Chrome पर एचटीटीपी कैश मेमोरी के बंटवारे की जांच कैसे करूं?
अपने Chrome पर एचटीटीपी कैश मेमोरी के बंटवारे की जांच करने के लिए, आपको कमांड लाइन फ़्लैग: --enable-features=SplitCacheByNetworkIsolationKey के साथ Chrome को लॉन्च करना होगा. अपने प्लैटफ़ॉर्म पर, कमांड-लाइन फ़्लैग की मदद से Chrome को लॉन्च करने का तरीका जानने के लिए, फ़्लैग के साथ Chromium चलाना पर दिए गए निर्देशों का पालन करें.
वेब डेवलपर के तौर पर, क्या मुझे इस बदलाव के हिसाब से कोई कार्रवाई करनी चाहिए?
यह कोई बड़ा बदलाव नहीं है. हालांकि, इससे कुछ वेब सेवाओं की परफ़ॉर्मेंस पर असर पड़ सकता है.
उदाहरण के लिए, जिन साइटों पर कई साइटों (जैसे, फ़ॉन्ट और लोकप्रिय स्क्रिप्ट) पर कैश मेमोरी में सेव किए जा सकने वाले ज़्यादा संसाधनों को दिखाया जाता है उनके ट्रैफ़िक में बढ़ोतरी हो सकती है. साथ ही, ऐसी सेवाओं का इस्तेमाल करने वाले लोग, उन पर ज़्यादा भरोसा कर सकते हैं.
(निजता बनाए रखने के लिए, शेयर की गई लाइब्रेरी को चालू करने का एक प्रस्ताव है. इसे वेब पर शेयर की गई लाइब्रेरी (प्रज़ेंटेशन वीडियो) कहा जाता है. हालांकि, इस पर अब भी विचार किया जा रहा है.)
उपयोगकर्ताओं के व्यवहार में हुए इस बदलाव का क्या असर पड़ेगा?
कैश मेमोरी में कॉन्टेंट न मिलने की दर में करीब 3.6% की बढ़ोतरी होती है. FCP (First Contentful Paint) में हुए बदलाव मामूली (~0.3%) होते हैं. साथ ही, नेटवर्क से लोड किए गए बाइट के कुल हिस्से में करीब 4% की बढ़ोतरी होती है. एचटीटीपी कैश मेमोरी को अलग-अलग हिस्सों में बांटने के बारे में जानकारी में, परफ़ॉर्मेंस पर पड़ने वाले असर के बारे में ज़्यादा जानें.
क्या यह स्टैंडर्ड है? क्या अन्य ब्राउज़र अलग तरह से काम करते हैं?
"एचटीटीपी कैश मेमोरी का बंटवारा", फ़ेच स्पेसिफ़िकेशन में स्टैंडर्ड किया गया है. हालांकि, ब्राउज़र अलग-अलग तरीके से काम करते हैं:
- Chrome: टॉप-लेवल स्कीम://eTLD+1 और फ़्रेम स्कीम://eTLD+1 का इस्तेमाल करता है
- Safari: टॉप-लेवल eTLD+1 का इस्तेमाल करता है
- Firefox: top-level scheme://eTLD+1 के साथ लागू करने की योजना बनाई जा रही है. साथ ही, Chrome की तरह दूसरी कुंजी शामिल करने पर विचार किया जा रहा है
वर्कर्स से फ़ेच करने का क्या तरीका है?
डिवाइस के लिए खास तौर पर बनाए गए वर्कर्स, उसी कुंजी का इस्तेमाल करते हैं जो उनके मौजूदा फ़्रेम में इस्तेमाल की जा रही है. सेवा वर्कर और शेयर किए गए वर्कर ज़्यादा जटिल होते हैं, क्योंकि इन्हें कई टॉप-लेवल साइटों के बीच शेयर किया जा सकता है. फ़िलहाल, इस समस्या को हल करने के लिए चर्चा की जा रही है.