आधुनिक ब्राउज़रों में पाइपलाइनिंग अक्षम क्यों है?

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

HTTP मानक के अनुसार, सभी सर्वर पाइपलाइन अनुरोधों को संभालना चाहिए, इसलिए समस्या सर्वर पर समर्थन की कमी नहीं होनी चाहिए।

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

यह सर्वर पर पाइपलाइनिंग समर्थन बंद करने का एक कारण होगा (मानक का उल्लंघन), लेकिन मुझे इसे ग्राहकों पर बंद करने का कोई कारण नहीं मिल रहा है।

हालांकि यह एंड्रॉइड ब्राउज़र और क्रोम मोबाइल पर डिफ़ॉल्ट रूप से चालू है।

क्रोम, फ़ायरफ़ॉक्स, आईई, ओपेरा और सफारी अपने डेस्कटॉप (और कभी-कभी मोबाइल) संस्करण में पाइपलाइन HTTP अनुरोधों का उपयोग क्यों नहीं कर रहे हैं? इसे बंद करने के पीछे उनकी तर्क क्या है?

स्रोत

2015-05-27 Filip Haglund

मैं के रूप में विषय से हटकर है क्योंकि यह एक व्यावहारिक समस्या को हल करने की कोशिश कर नहीं है इस सवाल के बंद करने के लिए मतदान कर रहा हूँ । यह ** [प्रोग्रामर स्टैकएक्सचेंज] (http://programmers.stackexchange.com/help/on-topic) के लिए बेहतर अनुकूल हो सकता है। – Quentin

संभावित डुप्लिकेट [HTTP पाइपलाइनिंग का उपयोग करने के नुकसान क्या हैं?] (Http://stackoverflow.com/questions/14810890/what-are-the-disadvantages-of-using-http-pipelining) – Joe

I ' मैं इसे वोट दे रहा हूँ। ** मैं जवाब जानना चाहता हूं! ** – ieXcept

पाइपलाइनिंग निम्नलिखित कारणों के लिए अक्षम किया गया है:

फ़ायरफ़ॉक्स:

बड़ा मुद्दा स्पष्ट रूप से लाइन अवरुद्ध और प्रदर्शन और मजबूती पर इसके प्रभाव के सिर किया गया है। नाइव पाइपलाइन बस प्रदर्शन को और खराब बनाते हैं।

क्रोम:

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

सामान्य में:

छोटी गाड़ी प्रॉक्सी अभी भी आम और अजीब और अनियमित व्यवहार कि वेब डेवलपर्स पूर्वानुमान और आसानी से विश्लेषण नहीं कर सकते करने के लिए इन नेतृत्व कर रहे हैं।

पाइपलाइनिंग सही ढंग से लागू करने के लिए जटिल है: संसाधन का आकार स्थानांतरित किया जा रहा, प्रभावी RTT कि उपयोग किया जाएगा, साथ ही प्रभावी बैंडविड्थ, पाइप लाइन द्वारा प्रदान की सुधार पर सीधा घटना है। इन्हें जानने के बिना, महत्वपूर्ण संदेशों को महत्वहीन लोगों के पीछे देरी हो सकती है। पेज लेआउट के दौरान भी महत्वपूर्ण की धारणा विकसित होती है! इसलिए HTTP पाइपलाइनिंग ज्यादातर मामलों में केवल मामूली सुधार लाती है।

पाइपलाइनिंग HOL problem के अधीन है।

HTTP/1.x के साथ
, ब्राउज़र सीमित है लाभ उठाने के लिए ऊपर प्राथमिकता डेटा की क्षमता:

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

HTTP/2 इन अक्षमताओं को हल करता है: अनुरोध क्यूइंग और हेड-ऑफ-लाइन अवरोध समाप्त हो गया है क्योंकि ब्राउजर उन सभी अनुरोधों को प्रेषित कर सकता है जब वे खोजे जाते हैं, और ब्राउजर स्ट्रीम निर्भरताओं और वजन के माध्यम से अपनी स्ट्रीम प्राथमिकता वरीयता को संवाद कर सकता है, सर्वर को प्रतिक्रिया वितरण को और अनुकूलित करने की इजाजत देता है।

एक प्रॉक्सी के रूप में अच्छी तरह से इस्तेमाल किया जा सकता:

तुम कुछ मैं KDE3 में Konqueror तेजी लाने के लिए किया था की कोशिश कर सकते हैं। मैं असंतुष्ट था कि कॉन्करर के पास HTTP पाइपलाइनिंग नहीं थी, इसलिए कुछ खोज के बाद, मैंने पोलिपो को स्थानीय HTTP/HTTPS/FTP प्रॉक्सी के रूप में स्थापित किया और इसका उपयोग करने के लिए कॉन्करर सेट किया (पोर्ट 8123 पर स्थानीयहोस्ट अगर मुझे सही याद है)। HTTP पाइपलाइनिंग के अलावा, पोलिपो ने भी बेहतर कैशिंग प्रदान की, और चूंकि यह प्रॉक्सी थी, इसलिए मैं प्रत्येक ब्राउज़र को इसका उपयोग करने के लिए सेट कर सकता था और कैशिंग को ब्राउज़र के बीच साझा किया जाएगा। (इसका यह भी अर्थ है कि प्रत्येक ब्राउज़र के स्वतंत्र कैशिंग को अक्षम करना एक अच्छा विचार है।)

संदर्भ

स्रोत

2016-11-19 01:33:43

अब मैं जानना चाहता हूं कि क्यों मोबाइल ब्राउज़र पाइपलाइनिंग सक्षम करते हैं! वे एक ही प्रॉक्सी, मध्यम बक्से का उपयोग करते हैं और एक ही होल समस्या होनी चाहिए (लेकिन इससे भी बदतर, क्योंकि यह उच्च विलंबता कनेक्शन का उपयोग करता है)। HTTP/2 निश्चित रूप से भविष्य का समाधान है, लेकिन तब तक। –

क्या कोई मोबाइल ब्राउज़र है जो इस भेद को दस्तावेज करता है?मैंने देखा है लेकिन ओपेरा मिनी के अलावा कोई भी नहीं मिला है, जो अपनी प्रॉक्सी का उपयोग करता है, और कोई भी जो पीसीपीलाइनिंग या HTTP अनुरूपता के संबंध में डेस्कटॉप बनाम डेस्कटॉप अंतर नहीं करता है। –

महान जवाब! एफडब्ल्यूआईडब्ल्यू, https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c65 मोबाइल बनाम डेस्कटॉप मतभेदों पर संक्षेप में छूता है। –

आधुनिक ब्राउज़रों में पाइपलाइनिंग अक्षम क्यों है?

उत्तर

संबंधित मुद्दे