आम तौर पर, कैश मेमोरी में डेटा सेव होने से परफ़ॉर्मेंस बेहतर हो सकती है, ताकि आने वाले समय में उसी डेटा के लिए किए जाने वाले अनुरोधों को तेज़ी से पूरा किया जा सके. उदाहरण के लिए, नेटवर्क से कैश मेमोरी में सेव किए गए रिसॉर्स, सर्वर के राउंड ट्रिप से बच सकता है. कैश मेमोरी में सेव किए गए कंप्यूटेशनल नतीजे से, इस तरह कैलकुलेशन करने में समय लग सकता है.
Chrome में, कैश मेमोरी का इस्तेमाल कई तरह से किया जाता है. एचटीटीपी कैश मेमोरी का एक उदाहरण है.
फ़िलहाल, Chrome की एचटीटीपी कैश मेमोरी कैसे काम करती है
वर्शन 85 के बाद से, Chrome, नेटवर्क से फ़ेच किए गए संसाधनों को कैश मेमोरी में सेव करता है. इसके लिए, वे रिसॉर्स के यूआरएल को कैश मेमोरी के तौर पर इस्तेमाल करते हैं. (कैश मेमोरी में सेव किए गए संसाधन की पहचान करने के लिए कैश कुंजी का इस्तेमाल किया जाता है.)
यह उदाहरण दिखाता है कि एक इमेज को तीन अलग-अलग कॉन्टेक्स्ट में कैसे कैश और इस्तेमाल किया जाता है:
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 पर जाता है, जो इमेज
(https://c.example:8080) को एम्बेड करता है, जो इमेज का अनुरोध करता है.
कुंजी "scheme://eTLD+1" के आधार पर बनाई जाती है, इसलिए सबडोमेन और पोर्ट नंबर को अनदेखा किया जाता है. इसलिए, कैश मेमोरी हिट होती है.
https://a.example, https://c.example, https://x.example/doge.png }
अगर iframe को कई बार नेस्ट किया गया है, तो क्या होगा? उपयोगकर्ता https://a.example पर जाता है, जो एक iframe (https://b.example) एम्बेड करता है, जो एक और 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 पर एचटीटीपी कैश मेमोरी के पार्टीशन की जांच करने के लिए, आपको Chrome को कमांड लाइन फ़्लैग के साथ लॉन्च करना होगा: --enable-features=SplitCacheByNetworkIsolationKey. अपने प्लैटफ़ॉर्म पर कमांड लाइन फ़्लैग की मदद से Chrome को लॉन्च करने का तरीका जानने के लिए, Chromium के साथ फ़्लैग का इस्तेमाल करें पर दिए गए निर्देश का पालन करें.
वेब डेवलपर के तौर पर, क्या इस बदलाव को ध्यान में रखते हुए मुझे कोई कार्रवाई करनी चाहिए?
इस बदलाव से कोई नुकसान नहीं होगा, लेकिन इससे कुछ वेब सेवाओं पर परफ़ॉर्मेंस पर असर पड़ सकता है.
उदाहरण के लिए, कई साइटों (जैसे कि फ़ॉन्ट और लोकप्रिय स्क्रिप्ट) में, ज़्यादा कैश मेमोरी में सेव किए जा सकने वाले संसाधन दिखाने वाली साइटों के ट्रैफ़िक में बढ़ोतरी दिख सकती है. साथ ही, जो लोग ऐसी सेवाओं का इस्तेमाल करते हैं, वे उन पर ज़्यादा भरोसा कर सकते हैं.
(शेयर की गई लाइब्रेरी को निजता की सुरक्षा के लिए वेब पर शेयर की गई लाइब्रेरी (प्रज़ेंटेशन वीडियो) के नाम से चालू करने का सुझाव दिया गया है. हालांकि, इस पर अब भी विचार किया जा रहा है.)
व्यवहार में इस बदलाव का क्या असर पड़ेगा?
कुल कैश मिस रेट करीब 3.6% बढ़ जाता है, एफ़सीपी (फ़र्स्ट कॉन्टेंटफ़ुल पेंट) में बदलाव कम होते हैं (~0.3%). नेटवर्क से लोड होने वाले बाइट का कुल हिस्सा करीब 4% बढ़ जाता है. एचटीटीपी कैश मेमोरी के लिए पार्टीशन करने का तरीका पढ़कर, आप इसकी परफ़ॉर्मेंस पर पड़ने वाले असर के बारे में ज़्यादा जान सकते हैं.
क्या यह स्टैंडर्ड है? क्या अन्य ब्राउज़र अलग तरह से काम करते हैं?
"एचटीटीपी कैश पार्टीशन" को फ़ेच करने से जुड़ी ज़रूरी शर्तों में स्टैंडर्ड तरीके से तय किया जाता है. हालांकि, ब्राउज़र का काम करने का तरीका अलग होता है:
- Chrome: टॉप-लेवल स्कीम://eTLD+1 और फ़्रेम स्कीम://eTLD+1 का इस्तेमाल करता है
- Safari: टॉप-लेवल eTLD+1 का इस्तेमाल करता है
- Firefox: टॉप-लेवल स्कीम://eTLD+1 के साथ लागू करने की योजना बनाना और Chrome जैसी दूसरी कुंजी शामिल करने पर विचार करना
कर्मचारियों से फ़ेच करने के तरीके के साथ क्या किया जाता है?
खास तौर पर काम करने वाले कर्मचारी उसी कुंजी का इस्तेमाल करते हैं जिसका इस्तेमाल वे अपने मौजूदा फ़्रेम के लिए करते हैं. सर्विस वर्कर और शेयर किए गए वर्कर ज़्यादा पेचीदा होते हैं, क्योंकि ये कई टॉप लेवल साइटों के बीच शेयर किए जा सकते हैं. फ़िलहाल, उनके समाधान पर चर्चा हो रही है.