नेविगेशन में क्या होता है
यह उस 4 भाग वाली ब्लॉग सीरीज़ का दूसरा हिस्सा है, जिसमें Chrome की अंदरूनी चीज़ों पर काम किया गया है. पिछली पोस्ट में हमने देखा कि अलग-अलग प्रोसेस और थ्रेड, ब्राउज़र के अलग-अलग हिस्सों को कैसे मैनेज करते हैं. इस पोस्ट में हमने इस बारे में गहराई से बताया है कि किसी वेबसाइट को दिखाने के लिए, हर प्रोसेस और थ्रेड कैसे आपस में संपर्क करते हैं.
चलिए, वेब ब्राउज़िंग के सामान्य इस्तेमाल के उदाहरण पर नज़र डालते हैं: आप ब्राउज़र में कोई यूआरएल टाइप करते हैं, फिर ब्राउज़र इंटरनेट से डेटा फ़ेच करता है और कोई पेज दिखाता है. इस पोस्ट में, हम इस बात पर फ़ोकस करेंगे कि जब कोई उपयोगकर्ता किसी साइट के लिए अनुरोध करता है और ब्राउज़र किसी पेज को रेंडर करने की तैयारी करता है, तो इसे नेविगेशन भी कहा जाता है.
यह एक ब्राउज़र प्रोसेस से शुरू होता है
जैसा कि हमने पहले हिस्से: सीपीयू, जीपीयू, मेमोरी, और मल्टी-प्रोसेस आर्किटेक्चर के बारे में बताया है, टैब के बाहर की सारी चीज़ें ब्राउज़र प्रोसेस से मैनेज की जाती हैं. ब्राउज़र प्रोसेस में यूज़र इंटरफ़ेस (यूआई) थ्रेड जैसे थ्रेड होते हैं, जो ब्राउज़र के बटन और इनपुट फ़ील्ड खींचते हैं. इसके अलावा, वह नेटवर्क थ्रेड जो इंटरनेट से डेटा पाने के लिए नेटवर्क स्टैक से जुड़ी होती है, स्टोरेज थ्रेड होती है जो फ़ाइलों के ऐक्सेस को कंट्रोल करती है वगैरह. पता बार में कोई यूआरएल टाइप करने पर, आपके इनपुट को ब्राउज़र प्रोसेस के यूज़र इंटरफ़ेस (यूआई) थ्रेड से मैनेज किया जाता है.
एक आसान नेविगेशन
पहला चरण: इनपुट मैनेज करना
जब कोई उपयोगकर्ता पता बार में टाइप करना शुरू करता है, तो यूज़र इंटरफ़ेस (यूआई) थ्रेड सबसे पहले पूछता है कि "यह खोज क्वेरी है या यूआरएल?". Chrome में, पता बार एक खोज इनपुट फ़ील्ड भी होता है, इसलिए यूज़र इंटरफ़ेस (यूआई) थ्रेड को पार्स करने और यह तय करने की ज़रूरत होती है कि आपको किसी सर्च इंजन पर भेजना है या उस साइट पर भेजना है जिसका आपने अनुरोध किया है.
दूसरा चरण: नेविगेशन शुरू करना
जब कोई उपयोगकर्ता Enter दबाता है, तो यूज़र इंटरफ़ेस (यूआई) थ्रेड, साइट का कॉन्टेंट पाने के लिए नेटवर्क कॉल शुरू करता है. लोडिंग स्पिनर, टैब के कोने में दिखाया जाता है और नेटवर्क थ्रेड, डीएनएस लुकअप और अनुरोध के लिए TLS कनेक्शन जैसे सही प्रोटोकॉल से होकर गुज़रता है.
इस समय, नेटवर्क थ्रेड को HTTP 301 जैसा कोई सर्वर रीडायरेक्ट हेडर मिल सकता है. ऐसी स्थिति में, नेटवर्क थ्रेड उस यूज़र इंटरफ़ेस (यूआई) थ्रेड के साथ जानकारी देती है जिसे सर्वर रीडायरेक्ट का अनुरोध कर रहा है. इसके बाद, दूसरा यूआरएल अनुरोध भेजा जाएगा.
तीसरा चरण: जवाब पढ़ें
रिस्पॉन्स का मुख्य हिस्सा (पेलोड) आने के बाद, ज़रूरत होने पर नेटवर्क थ्रेड, स्ट्रीम की शुरुआती कुछ बाइट की जांच करता है. रिस्पॉन्स के कॉन्टेंट-टाइप हेडर में यह बताया जाना चाहिए कि वह किस तरह का डेटा है. लेकिन यह गायब या गलत हो सकता है, इसलिए MIME टाइप स्निफ़िंग का काम यहां किया जाता है. यह सोर्स कोड में टिप्पणी के मुताबिक, "गलत कारोबार" है. टिप्पणी को पढ़कर यह देखा जा सकता है कि अलग-अलग ब्राउज़र, कॉन्टेंट-टाइप/पेलोड पेयर को कैसे इस्तेमाल करते हैं.
अगर रिस्पॉन्स एक एचटीएमएल फ़ाइल है, तो अगला चरण रेंडरर प्रोसेस में डेटा भेजना होगा. हालांकि, अगर यह zip फ़ाइल या कोई अन्य फ़ाइल है, तो इसका मतलब है कि यह डाउनलोड करने का अनुरोध है. इसलिए, उन्हें डेटा को डाउनलोड मैनेजर को भेजना होगा.
यहां SafeBrowsing की जांच की जाती है. अगर डोमेन और रिस्पॉन्स डेटा, जानी-पहचानी नुकसान पहुंचाने वाली साइट से मेल खाता है, तो नेटवर्क थ्रेड चेतावनी पेज दिखाने के लिए अलर्ट करता है. इसके अलावा, Cरॉस Cरिजिन Cमोड Cलॉकिंग (C) जांच की जाती है, ताकि यह पक्का किया जा सके कि क्रॉस-साइट का संवेदनशील डेटा, रेंडर करने की प्रोसेस में शामिल नहीं हो पाता.
चौथा चरण: रेंडर करने की प्रोसेस ढूंढना
सभी जांच पूरी हो जाने के बाद और नेटवर्क थ्रेड को यह भरोसा हो जाता है कि ब्राउज़र को उस साइट पर जाना चाहिए जिसके लिए अनुरोध किया गया था. इसके बाद, नेटवर्क थ्रेड, यूज़र इंटरफ़ेस (यूआई) थ्रेड को बताती है कि डेटा तैयार है. इसके बाद, यूज़र इंटरफ़ेस (यूआई) थ्रेड, वेब पेज की रेंडरिंग जारी रखने के लिए, रेंडरर प्रोसेस ढूंढता है.
नेटवर्क अनुरोध को जवाब मिलने में कई सौ मिलीसेकंड लग सकते हैं. इसलिए, इस प्रोसेस को तेज़ी से बढ़ाने के लिए एक ऑप्टिमाइज़ेशन लागू किया जाता है. जब यूज़र इंटरफ़ेस (यूआई) थ्रेड, दूसरे चरण में नेटवर्क थ्रेड को यूआरएल का अनुरोध भेज रहा हो, तो उसे पहले से पता होता है कि वे किस साइट पर नेविगेट कर रहे हैं. यूज़र इंटरफ़ेस (यूआई) थ्रेड, नेटवर्क अनुरोध के साथ-साथ रेंडरर प्रोसेस को अपने-आप ढूंढने या शुरू करने की कोशिश करता है. इस तरह, अगर सब कुछ उम्मीद के मुताबिक होता है, तो नेटवर्क थ्रेड को डेटा मिलने पर रेंडरर प्रोसेस पहले से ही स्टैंडबाय स्थिति में होती है. अगर नेविगेशन क्रॉस-साइट रीडायरेक्ट करता है, तो हो सकता है कि इस स्टैंडबाय प्रोसेस का इस्तेमाल न किया जाए. इस स्थिति में, किसी दूसरी प्रोसेस की ज़रूरत पड़ सकती है.
पांचवां चरण: नेविगेशन शुरू करना
अब डेटा और रेंडरर प्रक्रिया तैयार होने के बाद, नेविगेशन के लिए ब्राउज़र प्रोसेस से रेंडरर प्रोसेस में एक IPC भेजा जाता है. यह डेटा स्ट्रीम को भी पास करता है, ताकि रेंडरर प्रोसेस को एचटीएमएल डेटा मिलता रहे. ब्राउज़र प्रोसेस को यह पुष्टि सुनाई देने के बाद कि रेंडर प्रोसेस में पेमेंट हो चुका है, नेविगेशन पूरा हो जाता है और दस्तावेज़ लोड होने का चरण शुरू हो जाता है.
यहां, पता बार अपडेट किया जाता है और सुरक्षा संकेतक और साइट सेटिंग का यूज़र इंटरफ़ेस (यूआई), नए पेज की साइट की जानकारी दिखाता है. टैब के लिए सत्र इतिहास अपडेट किया जाएगा, ताकि बैक-फ़ॉरवर्ड बटन उस साइट पर चले जाएं जिस पर अभी-अभी नेविगेट किया गया था. किसी टैब या विंडो को बंद करने पर, टैब/सेशन को पहले जैसा करने के लिए, सेशन का इतिहास डिस्क पर सेव किया जाता है.
अतिरिक्त चरण: शुरुआती लोड पूरा हुआ
नेविगेशन की प्रोसेस पूरी हो जाने के बाद, रेंडर करने की प्रोसेस में रिसॉर्स लोड होते हैं और पेज रेंडर होता है. इस चरण में क्या होगा, इस बारे में हम अगली पोस्ट में विस्तार से बताएंगे. रेंडरर
की प्रक्रिया "पूरी" होने पर, ब्राउज़र प्रोसेस को IPC वापस भेजता है. ऐसा तब होता है, जब पेज के सभी फ़्रेम पर
onload इवेंट ट्रिगर हो जाएं और उनका एक्ज़ीक्यूशन पूरा हो जाए. यहां पर यूज़र इंटरफ़ेस (यूआई) थ्रेड, टैब पर लोडिंग स्पिनर को बंद कर देता है.
मेरा मतलब "पूरा" है, क्योंकि क्लाइंट साइड JavaScript अब भी अतिरिक्त रिसॉर्स लोड कर सकता है और इसके बाद नए व्यू रेंडर कर सकता है.
किसी दूसरी साइट पर जाना
आसान नेविगेशन पूरा हो गया! लेकिन, अगर कोई उपयोगकर्ता पता बार में
फिर से कोई दूसरा यूआरएल डाल देता है, तो क्या होता है? वैसे, अलग-अलग साइट पर नेविगेट करने के लिए ब्राउज़र प्रोसेस एक ही तरीके से होती है.
हालाँकि, ऐसा करने से पहले, पहले से रेंडर की गई साइट से पता करना ज़रूरी है कि क्या वह beforeunload इवेंट से जुड़ी कोई परवाह करता है.
पेज से बाहर नेविगेट करने या टैब बंद करने पर, beforeunload "इस साइट को छोड़ें?" चेतावनी बना सकता है.
आपके JavaScript कोड के साथ टैब में मौजूद हर चीज़, रेंडर करने वाली प्रोसेस से मैनेज की जाती है. इसलिए, नया नेविगेशन अनुरोध आने पर, ब्राउज़र प्रोसेस को रेंडर करने की मौजूदा प्रोसेस की जांच करनी होगी.
अगर नेविगेशन रेंडरर प्रोसेस से शुरू किया गया था (जैसे कि उपयोगकर्ता ने किसी लिंक पर क्लिक किया या क्लाइंट-साइड JavaScript ने window.location = "https://newsite.com" चलाया), तो रेंडरर प्रोसेस
सबसे पहले beforeunload हैंडलर की जांच करती है. फिर, यह उसी प्रोसेस से होकर गुज़रता है जो ब्राउज़र प्रोसेस
की नेविगेशन शुरू करने की प्रक्रिया से होती है. अंतर सिर्फ़ यह है कि नेविगेशन अनुरोध को रेंडरर प्रोसेस से ब्राउज़र प्रोसेस पर बंद कर दिया जाता है.
जब नया नेविगेशन, मौजूदा पेज पर रेंडर की गई साइट के बजाय किसी दूसरी साइट पर किया जाता है, तो नए नेविगेशन को मैनेज करने के लिए, रेंडर करने की एक अलग प्रोसेस इस्तेमाल की जाती है. वहीं, unload जैसे इवेंट को हैंडल करने के लिए, मौजूदा रेंडर प्रोसेस को रखा जाता है. ज़्यादा जानकारी के लिए, पेज लाइफ़साइकल एपीआई की खास जानकारी देखें. साथ ही, यह भी देखें कि Page Lifecycle API की मदद से इवेंट को कैसे जोड़ा जा सकता है.
सर्विस वर्कर के मामले में
इस नेविगेशन प्रक्रिया में हाल ही में एक बदलाव हुआ है सर्विस वर्कर. सर्विस वर्कर, आपके ऐप्लिकेशन कोड में नेटवर्क प्रॉक्सी लिखने का एक तरीका है. इससे वेब डेवलपर को इस बात पर ज़्यादा कंट्रोल मिलता है कि स्थानीय तौर पर क्या कैश मेमोरी में सेव करनी है और नेटवर्क से नया डेटा कब पाना है. अगर सर्विस वर्कर को कैश मेमोरी से पेज लोड करने के लिए सेट किया गया है, तो नेटवर्क से डेटा के लिए अनुरोध करने की ज़रूरत नहीं होती.
यह याद रखना ज़रूरी है कि सर्विस वर्कर एक JavaScript कोड है, जो रेंडर करने वाले प्रोसेस में चलता है. हालांकि, नेविगेशन का अनुरोध मिलने पर, ब्राउज़र प्रोसेस को कैसे पता चलता है कि साइट में कोई सर्विस वर्कर है?
जब कोई सर्विस वर्कर रजिस्टर किया जाता है, तब सर्विस वर्कर का स्कोप रेफ़रंस के तौर पर रखा जाता है. सर्विस वर्कर के लाइफ़साइकल लेख में, स्कोप के बारे में ज़्यादा पढ़ा जा सकता है. नेविगेशन होने पर, नेटवर्क थ्रेड, रजिस्टर किए गए सर्विस वर्कर के दायरे से डोमेन की जांच करता है. अगर किसी सर्विस वर्कर को उस यूआरएल के लिए रजिस्टर किया गया है, तो सर्विस वर्कर कोड को एक्ज़ीक्यूट करने के लिए, यूज़र इंटरफ़ेस (यूआई) थ्रेड रेंडर प्रोसेस ढूंढता है. सर्विस वर्कर, कैश मेमोरी से डेटा लोड कर सकता है, जिससे नेटवर्क से डेटा के लिए अनुरोध करने की ज़रूरत नहीं पड़ती या वह नेटवर्क से नए संसाधनों का अनुरोध कर सकता है.
नेविगेशन प्रीलोड
आपको ब्राउज़र प्रोसेस और रेंडरर प्रोसेस के बीच इस राउंड ट्रिप के दौरान देरी हो सकती है. अगर सर्विस वर्कर, नेटवर्क से डेटा का अनुरोध करने का फ़ैसला लेता है, तो ऐसा हो सकता है. नेविगेशन प्रीलोड एक ऐसा तरीका है, जिसकी मदद से सर्विस वर्कर स्टार्टअप के साथ-साथ संसाधनों को लोड करके इस प्रोसेस को तेज़ किया जा सकता है. यह इन अनुरोधों को हेडर से मार्क करता है, जिससे सर्वर को इन अनुरोधों के लिए अलग-अलग कॉन्टेंट भेजने का फ़ैसला लेने में मदद मिलती है; उदाहरण के लिए, पूरे दस्तावेज़ के बजाय सिर्फ़ अपडेट किया गया डेटा.
रैप-अप
इस पोस्ट में, हमने पता लगाया कि नेविगेशन के दौरान क्या होता है और रिस्पॉन्स हेडर और क्लाइंट-साइड JavaScript जैसे आपके वेब ऐप्लिकेशन कोड, ब्राउज़र के साथ कैसे इंटरैक्ट करते हैं. नेटवर्क से डेटा पाने के लिए ब्राउज़र किन चरणों को अपनाता है, यह समझना आसान हो जाता है कि नेविगेशन जैसे एपीआई पहले से लोड किए जाने की वजह क्या थी. अगले पोस्ट में, हम जानेंगे कि ब्राउज़र पेजों को रेंडर करने के लिए हमारे एचटीएमएल/सीएसएस/JavaScript का मूल्यांकन कैसे करता है.
क्या आपको यह पोस्ट पसंद आई? अगर आगे की पोस्ट के बारे में आपका कोई सवाल है या सुझाव है, तो हमें नीचे दिए गए टिप्पणी वाले सेक्शन में या Twitter पर @kosamari से जवाब देने में खुशी होगी.