जब webservers एक पृष्ठ भेजते हैं, तो वे सभी आवश्यक CSS, JS और छवियों को बिना पूछे क्यों नहीं भेजते हैं?

Question

जब एक वेब पेज में एक एकल सीएसएस फ़ाइल और एक छवि होती है, तो ब्राउज़र और सर्वर इस पारंपरिक समय लेने वाले मार्ग के साथ समय क्यों बर्बाद करते हैं:

1. ब्राउज़र वेबपेज के लिए प्रारंभिक GET अनुरोध भेजता है और सर्वर की प्रतिक्रिया का इंतजार करता है।
2. ब्राउज़र css फ़ाइल के लिए एक और GET अनुरोध भेजता है और सर्वर की प्रतिक्रिया का इंतजार करता है।
3. ब्राउज़र छवि फ़ाइल के लिए एक और GET अनुरोध भेजता है और सर्वर की प्रतिक्रिया का इंतजार करता है।

जब इसके बजाय वे इस छोटे, प्रत्यक्ष, समय की बचत मार्ग का उपयोग कर सकते हैं?

1. ब्राउज़र एक वेब पेज के लिए एक GET अनुरोध भेजता है।
2. वेब सर्वर के साथ प्रतिक्रिया करता है ( index.html उसके बाद style.css और image.jpg )

Comments

कोई भी अनुरोध तब तक नहीं किया जा सकता है जब तक कि वेब पेज निश्चित रूप से न आ जाए। उसके बाद, HTML पढ़ने के लिए अनुरोध किए जाते हैं। लेकिन इसका मतलब यह नहीं है कि एक समय में केवल एक अनुरोध किया जाता है। वास्तव में, कई अनुरोध किए जाते हैं लेकिन कभी-कभी अनुरोधों के बीच निर्भरताएं होती हैं और कुछ को पृष्ठ को ठीक से चित्रित करने से पहले हल करना पड़ता है। ब्राउज़र्स कभी-कभी एक अनुरोध के रूप में विराम देते हैं, अन्य प्रतिक्रियाओं को संभालने से पहले संतुष्ट होने के लिए यह प्रकट करते हैं कि प्रत्येक अनुरोध को एक बार में ही संभाल लिया जाता है। वास्तविकता ब्राउज़र की तरफ अधिक है क्योंकि वे संसाधन गहन होते हैं।

— क्लोसेट्नोक

मुझे आश्चर्य है कि किसी ने कैशिंग का उल्लेख नहीं किया। अगर मेरे पास पहले से ही वह फाइल है, तो मुझे इसकी जरूरत नहीं है।

— कोरी ओगबर्न

यह सूची सैकड़ों चीजें लंबी हो सकती है। हालाँकि वास्तव में फाइलें भेजने से कम, यह अभी भी एक इष्टतम समाधान से बहुत दूर है।

— कोरी ओगबर्न

वास्तव में, मैंने कभी ऐसे वेब पेज का दौरा नहीं किया है जिसमें 100 से अधिक अनूठे संसाधन हों ..

— अहमद

@AhmedElsoobky: ब्राउज़र को यह पता नहीं होता है कि किन संसाधनों को कैश्ड-रिसोर्स हेडर के रूप में भेजा जा सकता है, बिना पहले पेज को फिर से प्राप्त किए बिना। यह एक गोपनीयता और सुरक्षा दुःस्वप्न भी होगा यदि कोई पृष्ठ पुनर्प्राप्त करता है सर्वर से कहता है कि मेरे पास एक और पृष्ठ कैश है, जो संभवतः मूल पृष्ठ (एक बहु-किरायेदारों की वेबसाइट) की तुलना में एक अलग संगठन द्वारा नियंत्रित किया जाता है।

— रयान

Answer 1

संक्षिप्त उत्तर है "क्योंकि HTTP इसके लिए डिज़ाइन नहीं किया गया था"।

टिम बर्नर्स-ली ने एक कुशल और एक्स्टेंसिबल नेटवर्क प्रोटोकॉल डिजाइन नहीं किया। उनका एक डिजाइन लक्ष्य सादगी था। (कॉलेज में मेरी नेटवर्किंग क्लास के प्रोफेसर ने कहा कि उन्हें पेशेवरों को नौकरी छोड़नी चाहिए थी।) जो समस्या आप रेखांकित करते हैं वह HTTP प्रोटोकॉल की कई समस्याओं में से एक है। अपने मूल रूप में:

• कोई प्रोटोकॉल संस्करण नहीं था, केवल एक संसाधन के लिए एक अनुरोध था
• कोई हेडर नहीं थे
• प्रत्येक अनुरोध को एक नए टीसीपी कनेक्शन की आवश्यकता थी
• कोई कंप्रेशन नहीं था

इन समस्याओं में से कई को संबोधित करने के लिए प्रोटोकॉल को बाद में संशोधित किया गया था:

• अनुरोध संस्करण किए गए थे, अब अनुरोध दिखते हैं GET /foo.html HTTP/1.1
• अनुरोध और प्रतिक्रिया दोनों के साथ मेटा जानकारी के लिए हेडर जोड़े गए थे
• कनेक्शनों को पुन: उपयोग करने की अनुमति दी गई थी Connection: keep-alive
• समय से पहले दस्तावेज़ का आकार ज्ञात नहीं होने पर भी कनेक्शन का पुन: उपयोग करने की अनुमति देने के लिए चुटकीली प्रतिक्रियाएं पेश की गईं।
• Gzip संपीड़न जोड़ा गया था

इस बिंदु पर HTTP को लिया गया है जहाँ तक पीछे की संगतता को तोड़े बिना हो सकता है।

आप यह सुझाव देने वाले पहले व्यक्ति नहीं हैं कि एक पृष्ठ और उसके सभी संसाधनों को ग्राहक को धकेल दिया जाना चाहिए। वास्तव में, Google ने एक प्रोटोकॉल डिज़ाइन किया है जो तथाकथित SPDY कर सकता है ।

आज क्रोम और फ़ायरफ़ॉक्स दोनों HTTP के बजाय SPDY का उपयोग उन सर्वरों के लिए कर सकते हैं जो इसका समर्थन करते हैं। SPDY वेबसाइट से, HTTP की तुलना में इसकी मुख्य विशेषताएं हैं:

• SPDY क्लाइंट और सर्वर को अनुरोध और प्रतिक्रिया हेडर को संपीड़ित करने की अनुमति देता है, जो बैंडविड्थ उपयोग पर कटौती करता है जब समान हेडर (जैसे कुकीज़) को कई अनुरोधों के लिए भेजा जाता है।
• SPDY एक ही कनेक्शन पर कई गुणा, एक साथ बहुस्तरीय अनुरोधों की अनुमति देता है, क्लाइंट और सर्वर के बीच दौर यात्राओं पर बचत करता है, और कम प्राथमिकता वाले संसाधनों को उच्च प्राथमिकता वाले अनुरोधों को अवरुद्ध करने से रोकता है।
• SPDY सर्वर को क्लाइंट के लिए सक्रिय रूप से संसाधनों को धक्का देने की अनुमति देता है, जो यह जानता है कि क्लाइंट को उनके अनुरोध के लिए प्रतीक्षा किए बिना क्लाइंट की आवश्यकता होगी (उदाहरण के लिए जावास्क्रिप्ट और सीएसएस फाइलें), बिना सर्वर के अप्रयुक्त बैंडविड्थ का कुशल उपयोग करने की अनुमति देता है।

यदि आप अपनी वेबसाइट को SPDY के साथ ब्राउज़ करने वाले ब्राउज़र की सेवा देना चाहते हैं, तो आप ऐसा कर सकते हैं। उदाहरण के लिए अपाचे में mod_spdy है ।

SPDY HTTP पुश 2 के लिए सर्वर पुश तकनीक के साथ आधार बन गया है ।

Comments

डांग अच्छा और सूचित जवाब! वेब ब्राउज़र प्रकृति द्वारा धारावाहिक हैं और अनुरोध तेजी से किए जा सकते हैं। लॉग फ़ाइल पर एक नज़र दिखाएगा कि HTML के पार्स होने के बाद संसाधनों के लिए अनुरोध जल्दी से किए जाते हैं। यह है जो यह है। एक बुरा सिस्टम नहीं है, बस कोड / संसाधन कुशल नहीं है जैसा कि यह हो सकता है।

— क्लोसेट्नोक

सिर्फ रिकॉर्ड के लिए, SPDY पवित्र कब्र नहीं है। यह कुछ चीजों को अच्छी तरह से करता है, लेकिन अन्य समस्याओं का परिचय देता है। यहाँ एक लेख है जिसमें कुछ बिंदुओं पर फिर से SPDY बोलने की बात है।

— जोस्ट

मैं अत्यधिक अनुशंसा करता हूं कि जो कोई भी इसमें रुचि रखता है वह @Jost की कड़ी में आलोचनाएं पढ़ें। यह आपको यह पता लगाने में शामिल जटिलता का संकेत देता है कि कैसे एक बहुत ही सामान्य रूप से लागू की गई चीज़ को न केवल बेहतर तरीके से बेहतर किया जाए , बल्कि इतना बेहतर हो कि हर कोई इसका उपयोग करना शुरू कर दे । एक सुधार के बारे में सोचना आसान है जो उपयोग के मामलों के अपेक्षाकृत बड़े सबसेट के लिए कुछ बेहतर बनाता है। चीजों को इस तरह से बेहतर बनाना कि हर कोई आपके नए प्रोटोकॉल का उपयोग करना शुरू कर दे क्योंकि यह इतना बेहतर है कि यह बदलने की लागत के लायक है यह पूरी तरह से एक और मामला है, और ऐसा करना आसान नहीं है।

— एमएसउथ

उन्हें पेशेवरों को नौकरी छोड़ देनी चाहिए : अगर उन्होंने ऐसा किया होता, तो उन्हें एक मानक के साथ आने में छह साल लग जाते, जो दिन निकलने पर अप्रचलित हो जाता, और जल्द ही एक दर्जन प्रतिस्पर्धी मानक सामने आ जाते। इसके अलावा, क्या पेशेवरों को किसी से अनुमति की आवश्यकता थी? उन्होंने खुद ऐसा क्यों नहीं किया?

— शांतनु तिवारी

फ्रैंक होने के लिए कोई योग्य पेशेवर नहीं हैं। कोई नहीं जानता कि कैसे एक विश्व व्यापी वेब का निर्माण किया जाए, क्योंकि किसी ने कभी निर्माण नहीं किया था। हाइपरमीडिया की अवधारणा टिम द्वारा आविष्कार नहीं की गई थी, उन्हें सर्न में "जानकारी खोने" की समस्या को हल करने के लिए "सूचना प्रबंधन" के लिए प्रस्ताव लिखने से पहले विभिन्न स्थानीय क्षेत्र के हाइपरमीडिया सिस्टम के साथ अनुभव था।

— रेयान

Answer 2

आपका वेब ब्राउज़र अतिरिक्त संसाधनों के बारे में नहीं जानता है जब तक कि वह सर्वर से वेब पेज (HTML) डाउनलोड नहीं करता है, जिसमें उन संसाधनों के लिंक शामिल हैं।

आप सोच रहे होंगे कि, वेब पेज के लिए प्रारंभिक अनुरोध के दौरान सर्वर केवल अपने स्वयं के HTML को पार्स क्यों नहीं करता है और सभी अतिरिक्त संसाधनों को वेब ब्राउज़र को भेजता है? ऐसा इसलिए है क्योंकि संसाधनों को कई सर्वरों में फैलाया जा सकता है, और वेब ब्राउज़र को उन सभी संसाधनों की आवश्यकता नहीं हो सकती है क्योंकि यह पहले से ही उनमें से कुछ कैश है, या उनका समर्थन नहीं कर सकता है।

वेब ब्राउजर संसाधनों का एक कैश रखता है, इसलिए उसे होस्ट करने वाले सर्वरों से समान संसाधनों को डाउनलोड नहीं करना पड़ता है। जब एक ही jQuery लाइब्रेरी का उपयोग करने वाली वेबसाइट पर विभिन्न पृष्ठों को नेविगेट करते हैं, तो आप हर बार, केवल पहली बार उस लाइब्रेरी को डाउनलोड नहीं करना चाहते हैं।

इसलिए जब वेब ब्राउज़र को सर्वर से एक वेब पेज मिलता है, तो यह जांचता है कि यह जो जुड़े हुए संसाधन हैं वह पहले से ही कैश में नहीं हैं, फिर उन संसाधनों के लिए अतिरिक्त HTTP अनुरोध करता है। बहुत सरल, बहुत लचीला और एक्स्टेंसिबल।

एक वेब ब्राउज़र आमतौर पर समानांतर में दो HTTP अनुरोध कर सकता है। यह AJAX के विपरीत नहीं है - वे दोनों वेब पृष्ठों को लोड करने के लिए अतुल्यकालिक तरीके हैं - अतुल्यकालिक फ़ाइल लोडिंग और अतुल्यकालिक सामग्री लोडिंग। रखने के साथ , हम एक कनेक्शन का उपयोग करके कई अनुरोध कर सकते हैं, और पाइपलाइनिंग के साथ हम प्रतिक्रियाओं का इंतजार किए बिना कई अनुरोध कर सकते हैं। ये दोनों तकनीक बहुत तेज हैं क्योंकि ज्यादातर ओवरहेड आमतौर पर टीसीपी कनेक्शन खोलने / बंद करने से आता है:

वेब इतिहास का एक सा ...

वेब पेजों की शुरुआत सादे पाठ ईमेल के रूप में हुई, जिसमें कंप्यूटर सिस्टम को इस विचार के इर्द-गिर्द रखा गया, जिससे कुछ हद तक सभी संचार मंच मुक्त हो गए; वेब सर्वर उस समय भी मालिकाना थे। बाद में, अतिरिक्त MIME प्रकारों, जैसे कि चित्र, शैली, स्क्रिप्ट आदि के रूप में "ईमेल युक्ति" में और अधिक परतें जोड़ी गईं, आखिरकार, MIME मल्टी-पर्पज इंटरनेट मेल एक्सटेंशन के लिए खड़ा है । जल्दी या बाद में हमारे पास अनिवार्य रूप से मल्टीमीडिया ईमेल संचार, मानकीकृत वेब सर्वर और वेब पेज थे।

HTTP के लिए आवश्यक है कि डेटा को ईमेल-जैसे संदेशों के संदर्भ में प्रेषित किया जाए, हालाँकि डेटा अक्सर ईमेल नहीं होता है।

जैसे-जैसे तकनीक विकसित होती है, उसे डेवलपर्स को मौजूदा सॉफ्टवेयर को तोड़ने के बिना नई सुविधाओं को उत्तरोत्तर शामिल करने की अनुमति देने की आवश्यकता होती है। उदाहरण के लिए, जब एक नया MIME प्रकार कल्पना में जोड़ा जाता है - मान लें कि JPEG - इसे लागू करने के लिए वेब सर्वर और वेब ब्राउज़र के लिए कुछ समय लगेगा। आप केवल अचानक ही JPEG को कल्पना में शामिल नहीं करते हैं और इसे सभी वेब ब्राउज़र को भेजना शुरू करते हैं, आप वेब ब्राउज़र को उन संसाधनों का अनुरोध करने की अनुमति देते हैं, जो इसका समर्थन करता है, जो सभी को खुश रखता है और तकनीक आगे बढ़ती है। क्या स्क्रीन रीडर को वेब पेज पर सभी जेपीईजी की जरूरत है? शायद ऩही। यदि आपकी डिवाइस जावास्क्रिप्ट का समर्थन नहीं करती है, तो क्या आपको जावास्क्रिप्ट फ़ाइलों का एक गुच्छा डाउनलोड करने के लिए मजबूर किया जाना चाहिए? शायद ऩही। क्या Googlebot को आपकी साइट को ठीक से अनुक्रमित करने के लिए आपकी सभी जावास्क्रिप्ट फ़ाइलों को डाउनलोड करने की आवश्यकता है? नहीं।

स्रोत: मैंने Node.js. की तरह एक इवेंट-आधारित वेब सर्वर विकसित किया है इसे रैपिड सर्वर कहा जाता है ।

संदर्भ:

• HTTP लगातार कनेक्शन (जीवित रहें)
• HTTP पाइपलाइनिंग
• HTTP / 1.1 कनेक्शन (RFC 2616)

आगे की पढाई:

• क्या SPDY http कनेक्शन को जीवित रखने की तुलना में किसी भी मल्टीप्लेक्सिंग से अलग है
• क्यों HTTP / 2.0 दिलचस्प नहीं लगता है

Comments

ठीक है, वास्तव में, हम उन सभी साइड-प्रॉब्लम्स (जैसे: कैश, कंटेंट-टाइप हेडर..एटीसी) का ध्यान रख सकते हैं, इन समस्याओं को हल करने के लिए वर्कअराउंड हैं । और जैसा कि मैंने ऊपर पोस्ट में टिप्पणियों में सुझाव दिया था, हम इस हेडर> कैश्ड-रिसोर्स: इमेज.जेपीजी जैसे कुछ का उपयोग कर सकते हैं; style.css; कैशिंग समस्या को हल करने के लिए .. (यदि आपके पास समय है, तो आप उपरोक्त टिप्पणियों पर एक नज़र डाल सकते हैं ..)

— अहमद

हाँ, यह विचार मेरे दिमाग को पार कर गया था, लेकिन यह बस HTTP के लिए बहुत अधिक है और यह इस तथ्य को हल नहीं करता है कि संसाधनों को कई सर्वरों में फैलाया जा सकता है। इसके अलावा, मुझे नहीं लगता कि आपकी प्रस्तावित समय-बचत विधि वास्तव में समय बचाएगी क्योंकि डेटा को स्ट्रीम के रूप में भेजा जा रहा है, चाहे आप इसे कैसे भी देखें, और साथ ही साथ-साथ, 100 एक साथ HTTP अनुरोध अनिवार्य रूप से 1 अनुरोध बन जाते हैं। आपके द्वारा प्रस्तावित तकनीक और क्षमता पहले से मौजूद है। देखें en.wikipedia.org/wiki/HTTP_persistent_connection

— पैरी

@perry: https://बड़ी सार्वजनिक रूप से वितरित फ़ाइलों को भेजने के लिए एक विकल्प के बारे में आप क्या सोचेंगे, जिन्हें प्रमाणित करने की आवश्यकता है, लेकिन गोपनीय नहीं रखा गया है: URL में एक वैध उत्तर के शीर्ष लेख के कुछ हिस्सों का हैश शामिल है, जो बदले में हो सकता है या तो एक हस्ताक्षर या डेटा पेलोड का हैश शामिल है, और क्या ब्राउज़र हेडर के खिलाफ प्राप्त डेटा को मान्य करता है? इस तरह के डिजाइन से न केवल कुछ एसएसएल हैंडशेक चरणों को बचाया जा सकेगा, बल्कि यह महत्वपूर्ण रूप से कैशिंग प्रॉक्सी को अनुमति देगा। SSL लिंक के माध्यम से URL प्राप्त करें, और डेटा कहीं से भी फीड किया जा सकता है।

— सुपरकैट

Answer 3

क्योंकि वे नहीं जानते कि वे संसाधन क्या हैं। उन वेब पेजों की आवश्यकता है जो HTML में कोडित हैं। एक पार्सर के बाद ही निर्धारित होता है कि उपयोगकर्ता-एजेंट द्वारा उन परिसंपत्तियों का अनुरोध क्या किया जा सकता है।

इसके अतिरिक्त, एक बार उन परिसंपत्तियों को ज्ञात होने के बाद, उन्हें व्यक्तिगत रूप से परोसा जाना चाहिए ताकि उचित हेडर (यानी सामग्री-प्रकार) को परोसा जा सके, इसलिए उपयोगकर्ता-एजेंट जानता है कि इसे कैसे संभालना है।

Comments

खासकर यदि आप आवश्यकता की तरह कुछ का उपयोग करते हैं। ब्राउज़र केवल इसके लिए पूछता है कि उसे क्या चाहिए। सब कुछ एक ही बार में लोड करने की कल्पना करें ...

— अरन मुल्होलैंड

यह सही उत्तर है, और एक यह है कि अधिकांश टिप्पणीकार गायब हैं - सर्वर को सक्रिय रूप से संसाधनों को भेजने के लिए, यह जानने की जरूरत है कि वे क्या हैं, जिसका अर्थ है कि सर्वर को HTML को पार्स करना होगा।

लेकिन सवाल यह है कि वेब सर्वर संसाधनों को क्यों नहीं भेजता है, न कि क्लाइंट उसी समय उनके लिए क्यों नहीं पूछ सकता है। ऐसी दुनिया की कल्पना करना बहुत आसान है जहां सर्वरों में संबंधित संपत्ति का एक पैकेज होता है जो सभी को एक साथ भेजा जाता है जो पैकेज बनाने के लिए HTML को पार्स करने पर भरोसा नहीं करता है।

— डेविड मिस्टर

@DavidMeister क्योंकि सर्वर को हमेशा नहीं पता होता है कि क्लाइंट क्या चाहता है - सर्च इंजन के लिए वेबक्रेलर सीएसएस / जेएस के बारे में परवाह नहीं कर सकता है, और दस्तावेज़ में कई अन्य संसाधन हैं जो इससे परे जुड़े हुए हैं - संपूर्ण भेजने की कोई आवश्यकता नहीं है RSS एक वेब ब्राउज़र को पैकेज में फीड करता है (अधिकांश सामग्री संभवतः HTML में पहले से ही है), जबकि एक फीड रीडर सिर्फ <head>आरएसएस को खोजने के लिए वैकल्पिक लिंक की तलाश करने वाले तत्व को पार्स कर सकता है - क्लाइंट क्लाइंट की एक सूची भेज सकता है इसमें क्या दिलचस्पी है, लेकिन फिर यह जानने की जरूरत है कि क्या उपलब्ध है और हम शुरुआत में वापस आ गए हैं

— झाफ - बेन ड्यूगिड

@ Zhaph-BenDuguid मैं एक वैकल्पिक दुनिया के बारे में बात कर रहा हूं, इस बात पर प्रकाश डालने के लिए कि इसका जवाब उतना ही है जितना कि प्रोटोकॉल किसी और चीज के रूप में काम करता है। इसके अतिरिक्त, किसी सर्वर के लिए यह अनावश्यक होने पर भी एक बार में सभी डेटा भेजने के लिए तेज़ हो सकता है। आप अनिवार्य रूप से बैंडविड्थ उपयोग के खिलाफ विलंबता के मुद्दों को बंद कर रहे हैं।

— डेविड मीस्टर

Answer 4

क्योंकि, आपके उदाहरण में, वेब सर्वर हमेशा सीएसएस और छवियां भेजेगा भले ही ग्राहक के पास पहले से ही हो, इस प्रकार बैंडविड्थ को बहुत बर्बाद कर रहा है (और इस प्रकार विलंब को कम करके कनेक्शन को धीमा करने के बजाय तेजी से बना रहा है, जो संभवतः आपका इरादा था)। ध्यान दें कि सीएसएस, जावास्क्रिप्ट और छवि फ़ाइलों को आमतौर पर वास्तव में उस कारण के लिए बहुत लंबे समय के साथ भेजा जाता है (जैसे कि जब आपको उन्हें बदलने की आवश्यकता होती है, तो आप नई प्रतिलिपि को बाध्य करने के लिए फ़ाइल का नाम बदल देते हैं जो फिर से लंबे समय तक कैश हो जाएगा)।

अब, आप " ओके " कहकर बैंडविड्थ की बर्बादी के आसपास काम करने की कोशिश कर सकते हैं , लेकिन क्लाइंट संकेत दे सकता है कि इसमें पहले से ही कुछ संसाधन हैं, इसलिए सर्वर इसे फिर से नहीं भेजेगा । कुछ इस तरह:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

और फिर केवल उन फ़ाइलों को प्राप्त करें जो बदल नहीं गए हैं एक टीसीपी कनेक्शन पर भेजा गया है (लगातार कनेक्शन पर HTTP पाइपलाइनिंग का उपयोग करके)। और अंदाज लगाइये क्या? यह यह है कि यह पहले से ही कैसे काम करता है (आप इफ-मॉडिफाइड-चूंकि-इफ-नो -नो-मैच के बजाय) का उपयोग कर सकते हैं ।

---

लेकिन अगर आप वास्तव में बहुत सारे बैंडविड्थ को बर्बाद करके (अपने मूल अनुरोध के अनुसार) विलंबता को कम करना चाहते हैं, तो आप अपनी वेबसाइट डिजाइन करते समय मानक HTTP / 1.1 का उपयोग करके आज ऐसा कर सकते हैं। अधिकांश लोग ऐसा नहीं करते हैं, क्योंकि उन्हें नहीं लगता कि यह इसके लायक है।

ऐसा करने के लिए, आपको सीएसएस या जावास्क्रिप्ट को अलग फ़ाइल में रखने की आवश्यकता नहीं है, आप उन्हें मुख्य HTML फ़ाइल में उपयोग करके <style>और <script>टैग कर सकते हैं (आपको शायद इसे मैन्युअल रूप से करने की भी आवश्यकता नहीं है, आपका टेम्पलेट इंजन शायद इसे स्वचालित रूप से कर सकता है) । आप इस तरह से डेटा URI का उपयोग करके HTML फ़ाइल में चित्र भी शामिल कर सकते हैं :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

बेशक, बेस 64 एन्कोडिंग बैंडविड्थ के उपयोग को थोड़ा बढ़ा देता है, लेकिन अगर आप व्यर्थ बैंडविड्थ की परवाह नहीं करते हैं, तो यह एक मुद्दा नहीं होना चाहिए।

अब, अगर आप वास्तव में परवाह करते हैं, तो आप दोनों दुनिया के सर्वश्रेष्ठ को पाने के लिए आपको वेब स्क्रिप्ट भी स्मार्ट बना सकते हैं: पहले अनुरोध पर (उपयोगकर्ता के पास कुकी नहीं है), सब कुछ भेजें (सीएसएस, जावास्क्रिप्ट, चित्र) केवल एक ही HTML में एम्बेडेड फ़ाइल के रूप में ऊपर वर्णित है, फ़ाइलों की बाहरी प्रतियों के लिए एक लिंक rel = "prefetch" टैग जोड़ें और एक कुकी जोड़ें। यदि उपयोगकर्ता के पास पहले से ही कुकी है (उदाहरण के लिए वह पहले का दौरा कर चुका है), तो उसे बस एक सामान्य HTML के साथ भेजें <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">आदि।

इसलिए पहली बार ब्राउजर में सिर्फ एक ही HTML फाइल के लिए अनुरोध करना होगा और सब कुछ प्राप्त करना और दिखाना होगा। तब यह (जब निष्क्रिय) बाहरी सीएसएस, जेएस, छवियों को प्रीलोड करेगा। अगली बार जब उपयोगकर्ता आएगा, तो ब्राउज़र अनुरोध करेगा और केवल परिवर्तित संसाधन (शायद सिर्फ नया HTML) प्राप्त करेगा।

अतिरिक्त सीएसएस + जेएस + छवियों का डेटा केवल दो बार भेजा जाएगा, भले ही आपने वेबसाइट पर सैकड़ों बार क्लिक किया हो। आपके प्रस्तावित समाधान के अनुसार सैकड़ों बार से बेहतर है। और यह कभी नहीं (पहली बार नहीं, न ही अगली बार) एक से अधिक विलंबता-बढ़ती दौर-यात्रा का उपयोग करेगा।

अब, अगर यह बहुत अधिक काम की तरह लगता है, और आप SPDY जैसे किसी अन्य प्रोटोकॉल के साथ नहीं जाना चाहते हैं , तो Apache के लिए mod_pagespeed जैसे मॉड्यूल पहले से ही हैं , जो स्वचालित रूप से आपके लिए कुछ काम कर सकते हैं (कई CSS / JS फ़ाइलों को मर्ज करना) एक में, छोटे-छोटे सीएसएस को ऑटो-इनलाइन करना और उन्हें छोटा करना, छोटे प्लेसहोल्डर इनलाइन इमेज बनाते हैं, जबकि आपको अपने वेबपेज की सिंगल लाइन को संशोधित करने की आवश्यकता के बिना ओरिजनल को लोड करने, आलसी लोडिंग इमेज आदि की प्रतीक्षा करते हुए।

Comments

मुझे लगता है यह है सही जवाब।

— el.pescado

Answer 5

HTTP2 SPDY पर आधारित है और जैसा आप सुझाते हैं वैसा ही करते हैं:

उच्च स्तर पर, HTTP / 2:

• पाठ के बजाय द्विआधारी है
• आदेश और अवरुद्ध करने के बजाय पूरी तरह से बहुसंकेतन है
• इसलिए समानता के लिए एक कनेक्शन का उपयोग कर सकते हैं
• ओवरहेड को कम करने के लिए हेडर संपीड़न का उपयोग करता है
• सर्वर को क्लाइंट कैश में "पुश" प्रतिक्रियाओं को लगातार करने की अनुमति देता है

अधिक HTTP 2 Faq पर उपलब्ध है

Answer 6

क्योंकि यह नहीं मानता कि ये चीजें वास्तव में आवश्यक हैं ।

प्रोटोकॉल किसी विशेष प्रकार की फ़ाइल या उपयोगकर्ता-एजेंट के लिए किसी विशेष हैंडलिंग को परिभाषित नहीं करता है। यह एक HTML फ़ाइल और PNG छवि के बीच का अंतर नहीं जानता है। आप जो पूछ रहे हैं उसे करने के लिए, वेब सर्वर को फ़ाइल प्रकार की पहचान करनी होगी, यह पता लगाने के लिए पार्स करना होगा कि यह किस अन्य फाइल का संदर्भ दे रहा है, और फिर निर्धारित करें कि अन्य फ़ाइलों की वास्तव में क्या जरूरत है, यह देखते हुए कि आप क्या करना चाहते हैं। फ़ाइल । इसके साथ तीन बड़ी समस्याएं हैं।

पहली समस्या यह है कि सर्वर छोर पर फ़ाइल प्रकारों की पहचान करने के लिए कोई मानक, मजबूत तरीका नहीं है । HTTP सामग्री-प्रकार के तंत्र के माध्यम से प्रबंधन करता है, लेकिन यह सर्वर की मदद नहीं करता है, जिसे इस सामग्री को अपने आप ही पता लगाना पड़ता है (आंशिक रूप से ताकि यह जानता हो कि सामग्री-प्रकार में क्या डाला जाए)। फ़ाइलनाम एक्सटेंशन को व्यापक रूप से समर्थित किया जाता है, लेकिन दुर्भावनापूर्ण उद्देश्यों के लिए कभी-कभी नाजुक और आसानी से मूर्ख बनाया जाता है। फ़ाइल सिस्टम मेटाडेटा कम नाजुक है, लेकिन अधिकांश सिस्टम इसे बहुत अच्छी तरह से समर्थन नहीं करते हैं, इसलिए सर्वर भी परेशान नहीं करते हैं। fileयदि आप इसे महंगा बनाने के लिए तैयार हैं, तो सामग्री सूँघना (कुछ ब्राउज़र और यूनिक्स कमांड करने की कोशिश करना) मजबूत हो सकता है, लेकिन सर्वर साइड पर व्यावहारिक रूप से सूँघना बहुत महंगा है, और सस्ता सूँघना पर्याप्त मजबूत नहीं है।

दूसरी समस्या यह है कि किसी फ़ाइल को पार्स करना महंगा, कम्प्यूटेशनल रूप से बोलना है । यह पहले से कुछ हद तक जुड़ा हुआ है, इसमें आपको अलग-अलग संभावित तरीकों के एक समूह में फ़ाइल को पार्स करने की आवश्यकता होगी यदि आप सामग्री को ज़ोर से सूँघना चाहते थे, लेकिन यह भी लागू होता है क्योंकि आपने फ़ाइल प्रकार की पहचान की है, क्योंकि आपको ज़रूरत है यह पता लगाने के लिए कि संदर्भ क्या हैं। यह इतना बुरा नहीं है जब आप केवल एक बार में कुछ फाइलें कर रहे हों, जैसे कि ब्राउज़र करता है, लेकिन एक वेब सर्वर को एक बार में सैकड़ों या हजारों अनुरोधों को संभालना पड़ता है। यह जोड़ता है, और अगर यह बहुत दूर चला जाता है, तो यह वास्तव में कई अनुरोधों से अधिक चीजों को धीमा कर सकता है। यदि आपने कभी Slashdot या इसी तरह की साइटों से लिंक का दौरा किया है, तो केवल यह पता लगाने के लिए कि सर्वर उच्च उपयोग के कारण तेजी से धीमा है, आपने इस सिद्धांत को कार्रवाई में देखा है।

तीसरी समस्या यह है कि सर्वर के पास यह जानने का कोई तरीका नहीं है कि आप फ़ाइल के साथ क्या करना चाहते हैं । एक ब्राउज़र को HTML में संदर्भित फ़ाइलों की आवश्यकता हो सकती है, लेकिन यह उस सटीक संदर्भ पर निर्भर नहीं हो सकता है जिसमें फ़ाइल निष्पादित की जा रही है। यह पर्याप्त जटिल होगा, लेकिन वेब पर केवल ब्राउज़रों की तुलना में अधिक है: मकड़ियों, फ़ीड एग्रीगेटर्स और पेज-स्क्रैपिंग मैशअप के बीच, कई प्रकार के उपयोगकर्ता-एजेंट हैं जिन्हें HTML में संदर्भित फ़ाइलों की कोई आवश्यकता नहीं है : वे केवल HTML के बारे में परवाह है। इन अन्य फाइलों को ऐसे यूजर-एजेंट्स को भेजना केवल बैंडविड्थ की बर्बादी होगी।

लब्बोलुआब यह है कि सर्वर पर इन निर्भरताओं का पता लगाना इसके लायक होने की तुलना में अधिक परेशानी है । इसलिए इसके बजाय, वे ग्राहक को यह पता लगाने देते हैं कि उसे क्या चाहिए।

Comments

यदि हम एक नया प्रोटोकॉल विकसित करने जा रहे हैं या पहले से मौजूद एक को ठीक करने के लिए, हम इन सभी समस्याओं का एक ही तरह से ध्यान रख सकते हैं! और वेब सर्वर केवल एक समय के लिए फ़ाइलों को पार्स करेगा और फिर यह परिभाषित नियमों के आधार पर उन्हें वर्गीकृत कर सकता है ताकि यह प्राथमिकता दे सके कि कौन सी फाइलें पहले भेजें..सीटीसी और वेब सर्वर को यह जानने की जरूरत नहीं है कि मैं क्या करने का इरादा रखता हूं उन फाइलों के साथ, यह सिर्फ यह जानना है कि क्या भेजना है, कब करना है और किन नियमों के आधार पर है .. (वेब ​​बॉट्स और स्पाइडर एक समस्या नहीं हैं, उनके साथ व्यवहार अलग होगा-उनके पास अद्वितीय उपयोगकर्ता-एजेंट हेडर हैं- ..)

— अहमद

@AhmedElsobky: क्या आप नेटवर्क प्रोटोकॉल की तुलना में एक विशिष्ट कार्यान्वयन की तरह लगता है के बारे में बात कर रहे हैं। लेकिन यह वास्तव में यह जानना है कि आप फ़ाइलों के साथ क्या करना चाहते हैं, इससे पहले कि यह निर्धारित कर सके कि क्या भेजना है: अन्यथा यह अनिवार्य रूप से उन फ़ाइलों को भेजेगा जो कई उपयोगकर्ता नहीं चाहते हैं। आप उपयोगकर्ता-एजेंट स्ट्रिंग्स पर भरोसा नहीं कर सकते, इसलिए आप यह निर्धारित करने के लिए उनका उपयोग नहीं कर सकते कि उपयोगकर्ता का इरादा क्या है।

— स्पूनिएस्ट