अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना Chrome विकासकांनी जाहीर केले की समर्थन देणे थांबविण्याचा त्यांचा हेतू आहे यंत्रणा सर्व्हर पुश HTTP / 2 आणि gQUIC प्रोटोकॉल मध्ये, तसेच मानक मंजुरीच्या टप्प्यात असलेल्या एचटीटीपी / 3 प्रोटोकॉलसाठी याची अंमलबजावणी करत नाही. सुरुवातीपासूनच HTTP / 1.1 प्रोटोकॉलमध्ये सर्व्हर पुश तंत्रज्ञान प्रदान केलेले नाही.
कारण निर्मूलन च्या कोडमधील मोठ्या गुंतागुंतपासून मुक्त होण्याची इच्छा आहे, सर्व्हर पुश-आधारित ऑप्टिमायझेशनच्या प्रभावीतेसाठी मागणीची कमतरता आणि केवळ सैद्धांतिक आवश्यकतांच्या संदर्भात.
तंत्रज्ञान सर्व्हर पुश HTTP / 2 मानक मध्ये परिभाषित केले आहे आणि डेटा लोड करणे ऑप्टिमाइझ करण्याचे उद्दीष्ट आहे.
क्रोमियम इंजिनवर आधारित ब्राउझर व्यतिरिक्त, सर्व्हर पुश समर्थन सध्या फायरफॉक्स आणि सफारीमध्ये आणि सर्व्हरच्या बाजूला एनजीन्क्स आणि अपाचे httpd मध्ये लागू केले गेले आहे.
सर्व्हर पुश सह, आपल्या स्पष्ट विनंतीची प्रतीक्षा न करता सर्व्हर क्लायंटला संसाधने पाठवू शकतो. असे गृहित धरले जाते की या मार्गाने सर्व्हर पृष्ठ लोड करण्यास वेगवान करू शकते, जेव्हा क्लायंट विनंती करेल तेव्हा पृष्ठ रेंडर करण्यासाठी आवश्यक असलेल्या सीएसएस फायली, स्क्रिप्ट आणि प्रतिमा आधीपासूनच त्याच्या बाजूला हस्तांतरित केल्या जातील.
क्लायंट विशिष्ट पृष्ठास जोडतो आणि विनंती करतो, ज्यानंतर सर्व्हरने त्याच्या कॉन्फिगरेशनवर किंवा क्लायंटद्वारे पाठविलेल्या दुवा शीर्षलेखातील सामग्रीच्या आधारे, क्लायंटकडून या संसाधनांच्या विनंतीची वाट न पाहता, आधीपासूनच स्थापित एचटीटीपी / 2 कनेक्शनद्वारे विशिष्ट संसाधनांचे हस्तांतरण सुरू होते. .
पुश कॉलद्वारे हस्तांतरित केलेली सामग्री वर्तमान एचटीटीपी / 2 कनेक्शनशी संबंधित विशेष कॅशेमध्ये क्लायंटच्या बाजूला संग्रहित केली जाते.
जेव्हा एखादे पृष्ठ प्रस्तुत करण्याच्या प्रक्रियेत, क्लायंट त्याच्याशी संबंधित संसाधनांसाठी विनंती (सीएसएस, जेएस, प्रतिमा इ.) पोहोचतो, प्रत्येक विनंती प्रत्यक्षात पाठविण्यापूर्वी कॅशे तपासणी केली जाते. जर आधीपासूनच सर्व्हरद्वारे संसाधन हस्तांतरित केले गेले असेल आणि कॅशेमध्ये असेल तर क्लायंट सर्व्हरला बाह्य विनंती न करता स्थानिक संसाधनाद्वारे स्थानिक संसाधनाद्वारे हे संसाधन खाली आणते.
HTTP / 3 एक अर्ध-आरएफसी प्रोटोकॉल आहे जो सर्व्हर पुश देखील परिभाषित करतो.
क्रोम सध्या एचटीटीपी / 2 आणि जीकेयूआयसीवर पुश ट्रान्समिशनच्या हाताळणीचे समर्थन करते आणि हा हेतू दोन्ही प्रोटोकॉलसाठी समर्थन काढून टाकण्याचा आहे. Chrome HTTP / 3 वर पुश करण्यास समर्थन देत नाही आणि समर्थन जोडणे रोडमॅपवर नाही.
अशा कॅशेची देखभाल अंमलबजावणीसाठी मोठ्या प्रमाणात गुंतागुंत करते सर्व्हर पुश क्लायंटच्या बाजूला, परंतु "प्रीलोड" टॅगद्वारे प्री-एम्प्लिव्ह रिसोर्स विनंतीच्या तुलनेत लोड लोड प्रवेग वाढत नाही आणि काही अभ्यासानुसार, विलंब वाढवते.
गूगल आकडेवारीनुसार, सर्व्हर पुश तंत्रज्ञान योग्यरित्या वितरित केले गेले नाही. उदाहरणार्थ, गेल्या 28 दिवसांत, HTTP / 99,95 कनेक्शनपैकी 2% सर्व्हर पुश वापरत नाहीत. जून 2019 मध्ये अभ्यासानुसार असे संकेतक पाळले गेले होते, म्हणजेच सर्व्हर पुश तैनात तैनात काहीच वाढ झाली नाही.
तसेच यावर्षी, सर्व्हर पुशकडून प्राप्त झालेल्या संदेशांपैकी केवळ 40% संदेश ब्राउझरद्वारे वापरले गेले होते आणि दोन वर्षांपूर्वी हा आकडा 63,51 XNUMX१% होता (कच्चे संदेश चुकीचे होते, प्रक्रिया केलेल्या पृष्ठाशी जुळत नाही किंवा आधीपासूनच कॅशेमध्ये होते) .
लोड ऑप्टिमाइझ करण्यासाठी सर्व्हर पुशऐवजी पृष्ठाचे, टॅग वापरण्याचा हेतू आहे , ज्याच्या आधारे ब्राउझर पृष्ठावर त्याच्या वापराची वाट न पाहता संसाधनाची विनंती करू शकतो.
एकीकडे सर्व्हर पुशच्या तुलनेत प्रीलोडिंग अनावश्यक पॅकेट एक्सचेंज (आरटीटी) ठरवते, परंतु दुसरीकडे, ब्राउझरच्या कॅशेमध्ये आधीपासूनच असलेले स्त्रोत पाठविणे प्रतिबंधित करते.
सर्वसाधारणपणे सर्व्हर पुश आणि प्रीलोड वापरताना विलंबातील फरक नगण्य मानले जातात. स्त्रोत लोड ऑप्टिमाइझ करण्याव्यतिरिक्त, सर्व्हर पुश यंत्रणा देखील सर्व्हरवरून क्लायंटकडे डेटा प्रसारित करण्यासाठी वापरली जाऊ शकते, परंतु वेबट्रान्सपोर्ट प्रोटोकॉल (क्वाइक वर आधारित) या हेतूसाठी अधिक योग्य आहे, ज्याचे मानकीकरण मसुद्याच्या टप्प्यात आहे .
स्त्रोत:https://groups.google.com