आम तौर पर, डेटा को कैश मेमोरी में सेव करके, परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. इससे उस डेटा के लिए आने वाले समय में किए जाने वाले अनुरोध तेज़ी से पूरे किए जाते हैं. उदाहरण के लिए, नेटवर्क से कैश मेमोरी में सेव किया गया रिसॉर्स, सर्वर पर राउंड ट्रिप से बच सकता है. कैश मेमोरी में सेव किए गए कंप्यूटेशनल नतीजे, इसी तरह का कैलकुलेशन करने में लगने वाले समय को कम कर सकते हैं.
Chrome में कैश मेमोरी को कई तरीकों से इस्तेमाल किया जाता है और एचटीटीपी कैश इसका एक उदाहरण है.
फ़िलहाल, Chrome का एचटीटीपी कैश मेमोरी कैसे काम करता है
वर्शन 85 के बाद से, Chrome, नेटवर्क से फ़ेच किए गए रिसॉर्स के यूआरएल को कैश कुंजी के तौर पर इस्तेमाल करके, उन्हें कैश मेमोरी में सेव करता है. (कैश मेमोरी में सेव किए गए संसाधन की पहचान करने के लिए, कैश कुंजी का इस्तेमाल किया जाता है.)
इस उदाहरण में दिखाया गया है कि किसी इमेज को कैश मेमोरी में कैसे सेव किया जाता है और उसे तीन अलग-अलग कॉन्टेक्स्ट में कैसे इस्तेमाल किया जाता है:
उपयोगकर्ता किसी ऐसे पेज (https://a.example
) पर जाता है जो इमेज (https://x.example/doge.png
) का अनुरोध करता है. इमेज को नेटवर्क से अनुरोध किया जाता है और कुंजी के तौर पर https://x.example/doge.png
का इस्तेमाल करके, इसे कैश मेमोरी में सेव किया जाता है.
वही उपयोगकर्ता किसी दूसरे पेज (https://b.example
) पर जाता है, जो उसी इमेज (https://x.example/doge.png
) का अनुरोध करता है.
ब्राउज़र अपने एचटीटीपी कैश की जांच करके पता लगाता है कि क्या पेज में पहले से इस रिसॉर्स को कैश मेमोरी में सेव किया गया है या नहीं. इसके लिए, इमेज यूआरएल को कुंजी के तौर पर इस्तेमाल किया जाता है. ब्राउज़र को इसकी कैश मेमोरी में कोई मिलान मिलता है, इसलिए वह संसाधन के कैश किए गए वर्शन का इस्तेमाल करता है.
इस बात से फ़र्क़ नहीं पड़ता कि इमेज को किसी iframe के अंदर से लोड किया गया है या नहीं. अगर उपयोगकर्ता, iframe (https://d.example
) वाली किसी दूसरी वेबसाइट (https://c.example
) पर जाता है और iframe उसी इमेज (https://x.example/doge.png
) के लिए अनुरोध करता है, तो ब्राउज़र अब भी कैश मेमोरी से इमेज लोड कर सकता है, क्योंकि कैश कुंजी सभी पेजों पर एक जैसी होती है.
परफ़ॉर्मेंस के नज़रिए से, यह तरीका लंबे समय से काम कर रहा है. हालांकि, किसी वेबसाइट को एचटीटीपी अनुरोधों का जवाब देने में लगने वाले समय से यह पता चलता है कि ब्राउज़र ने पहले इसी संसाधन को ऐक्सेस किया था. इससे ब्राउज़र को सुरक्षा और निजता से जुड़े हमलों के लिए खुल जाता है, जैसे कि:
- यह पता लगाना कि उपयोगकर्ता किसी खास साइट पर गया है या नहीं: कोई विरोधी उपयोगकर्ता के ब्राउज़िंग इतिहास का पता लगा सकता है. इसके लिए, वह यह जांच कर सकता है कि कैश में कोई ऐसा संसाधन तो नहीं है जो किसी खास साइट या साइटों के समानता रखने वाले लोगों के लिए बनाया गया हो.
- क्रॉस-साइट सर्च अटैक: विज्ञापन देने वाला यह पता लगा सकता है कि उपयोगकर्ता के खोज नतीजों में कोई आर्बिट्रेरी स्ट्रिंग मौजूद है या नहीं. इसके लिए, वह यह जांच कर सकता है कि किसी वेबसाइट के लिए इस्तेमाल की गई 'कोई खोज नतीजा नहीं' वाली इमेज, ब्राउज़र की कैश मेमोरी में है या नहीं.
- क्रॉस-साइट ट्रैकिंग: कैश मेमोरी का इस्तेमाल, कुकी जैसे आइडेंटिफ़ायर को क्रॉस-साइट ट्रैकिंग तकनीक के तौर पर स्टोर करने के लिए किया जा सकता है.
इन जोखिमों को कम करने के लिए, Chrome 86 की शुरुआत में, अपने एचटीटीपी कैश मेमोरी को अलग-अलग हिस्सों में बांट देगा.
कैश मेमोरी के बंटवारे से Chrome के एचटीटीपी कैश पर कैसे असर पड़ेगा?
कैश मेमोरी को बांटने की सुविधा की मदद से, कैश मेमोरी में सेव किए गए रिसॉर्स को, रिसॉर्स यूआरएल के साथ-साथ एक नई "नेटवर्क आइसोलेशन कुंजी" का इस्तेमाल करके भी कुंजी के तौर पर जोड़ा जाएगा. नेटवर्क आइसोलेशन कुंजी, टॉप लेवल साइट और मौजूदा फ़्रेम वाली साइट को मिलाकर बनाई जाती है.
पिछले उदाहरण पर एक बार फिर नज़र डालें और देखें कि कैश पार्टीशन अलग-अलग कॉन्टेक्स्ट में कैसे काम करते हैं:
कोई व्यक्ति किसी ऐसे पेज (https://a.example
) पर जाता है जो इमेज (https://x.example/doge.png
) के लिए अनुरोध करता है. इस मामले में, नेटवर्क से इमेज का अनुरोध किया जाता है और उसे कैश मेमोरी में सेव किया जाता है. इसके लिए, https://a.example
(टॉप लेवल साइट), https://a.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://x.example/doge.png
) को iframe में एम्बेड किया गया है. इस मामले में, कुंजी एक टपल है जिसमें https://a.example
, https://a.example
, और https://x.example/doge.png
शामिल होते हैं और एक कैश हिट होता है. (ध्यान दें कि अगर टॉप-लेवल साइट और iframe एक ही साइट हैं, तो टॉप-लेवल फ़्रेम की मदद से कैश मेमोरी में सेव किए गए रिसॉर्स का इस्तेमाल किया जा सकता है.
उपयोगकर्ता https://a.example
पर वापस आ गया है, लेकिन इस समय इमेज को https://c.example
के iframe में होस्ट किया गया है.
इस मामले में, इमेज को नेटवर्क से डाउनलोड किया जाता है, क्योंकि कैश मेमोरी में ऐसा कोई संसाधन नहीं है जो https://a.example
, https://c.example
, और https://x.example/doge.png
की कुंजी से मेल खाता हो.
अगर डोमेन में सबडोमेन या पोर्ट नंबर है, तो क्या होगा? उपयोगकर्ता
https://subdomain.a.example
पर जाता है, जो इमेज का अनुरोध करने के लिए, iframe
(https://c.example:8080
) एम्बेड करता है.
कुंजी को "scheme://eTLD+1" के आधार पर बनाया जाता है, इसलिए सबडोमेन और पोर्ट नंबर को नज़रअंदाज़ किया जाता है. इसलिए, कैश हिट होता है.
अगर 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 जैसी दूसरी कुंजी शामिल करने पर विचार करना
वर्कर को फ़ेच करने की सुविधा का इस्तेमाल कैसे किया जाता है?
खास तौर पर काम करने वाले वर्कर, उसी कुंजी का इस्तेमाल करते हैं जो उनके मौजूदा फ़्रेम के लिए होती है. सर्विस वर्कर और शेयर किए गए वर्कर बहुत जटिल होते हैं, क्योंकि इन्हें कई टॉप-लेवल की साइटों के बीच शेयर किया जा सकता है. फ़िलहाल, उनके समाधान पर चर्चा चल रही है.