HTTP 1.1 पाइपलाइनिंग

Question

मुझे जावा में एक HTTP क्लाइंट को कार्यान्वित करना है और मेरी ज़रूरतों के लिए ऐसा लगता है कि ऐसा करने का सबसे प्रभावी तरीका HTTP पाइपलाइन लागू करना है (RFC2616 के अनुसार)।

एक तरफ, मैं पाइपलाइन पोस्ट करना चाहता हूं। (इसके अलावा मैं मल्टीप्लेक्सिंग के बारे में बात नहीं कर रहा हूं। मैं पाइपलाइनिंग के बारे में बात कर रहा हूं यानी किसी भी प्रतिक्रिया प्राप्त करने से पहले एक कनेक्शन पर कई अनुरोध- HTTP अनुरोधों की बैचिंग)

मुझे तीसरी पार्टी लाइब्रेरी नहीं मिल सका जो स्पष्ट रूप से पाइपलाइनिंग का समर्थन करता है। लेकिन मैं उदाहरण का उपयोग कर सकता था Apache HTTPCore ऐसे क्लाइंट को बनाने के लिए, या यदि मुझे इसे बनाना है, तो इसे स्वयं बनाएं।

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

तो, क्या मुझे ऐसे क्लाइंट को लागू करने का प्रयास करना चाहिए या सर्वर के कार्यान्वयन (या प्रॉक्सी) के कारण मुझे बहुत परेशानी होगी। क्या कोई संदर्भ है जो इन पर दिशानिर्देश देता है?

यदि यह एक बुरा विचार है तो दक्षता के लिए वैकल्पिक प्रोग्रामिंग मॉडल क्या होगा? अलग टीसीपी कनेक्शन?

Answer 1

मैं एक pipelined HTTP ग्राहक क्रियान्वित किया है। बुनियादी अवधारणा आसान लगता है लेकिन त्रुटि प्रबंधन बहुत कठिन है।प्रदर्शन लाभ इतना महत्वहीन है कि हमने बहुत समय पहले अवधारणाओं को छोड़ दिया था।

मेरी राय में, यह सामान्य उपयोग-मामले के लिए समझ में नहीं आता है। अनुरोधों के तर्क कनेक्शन होने पर केवल कुछ लाभ होते हैं। उदाहरण के लिए, आपके पास 3-अनुरोध लेनदेन हैं और आप उन्हें सभी को बैच में भेज सकते हैं। लेकिन आम तौर पर यदि आप पाइपलाइन किए जा सकते हैं तो आप उन्हें एक अनुरोध में जोड़ सकते हैं।

के बाद बस कुछ बाधाओं मैं याद कर सकते हैं,

1. टीसीपी के keepalive लगातार कनेक्शन इसकी गारंटी नहीं है कर रहे हैं। यदि आपके पास कनेक्शन में पाइप किए गए 3 अनुरोध हैं, तो सर्वर पहली प्रतिक्रिया के बाद कनेक्शन छोड़ देता है। आपको अगले दो अनुरोधों का पुनः प्रयास करना होगा।

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

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

Answer 2

पोस्ट

8.1.2.2 पाइपलाइनिंग

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

ग्राहक जो लगातार कनेक्शन और पाइप लाइन तुरंत कनेक्शन स्थापना के बाद मान उनके कनेक्शन पुन: प्रयास करना है, तो पहले pipelined प्रयास विफल रहता है तैयार रहना चाहिए। यदि कोई ग्राहक ऐसा पुनः प्रयास करता है, तो कनेक्शन को लगातार जानता है इससे पहले पाइपलाइन नहीं होनी चाहिए। ग्राहकों को अनुरोधों को फिर से भेजने के लिए तैयार होना चाहिए यदि सर्वर कनेक्शन को संबंधित प्रतिक्रियाओं को भेजने से पहले कनेक्शन बंद कर देता है।

ग्राहक नहीं पाइपलाइन अनुरोध चाहिए गैर idempotent तरीकों या गैर idempotent दृश्यों तरीकों (खंड 9.1.2 देखें) की का उपयोग कर। अन्यथा, परिवहन कनेक्शन की समय-समय पर समाप्त होने से कनेक्शन परिणाम अनिश्चित हो सकता है। गैर-बेवकूफ अनुरोध भेजने की इच्छा रखने वाले ग्राहक को पर प्रतीक्षा करना चाहिए जब तक कि को पिछले अनुरोध के लिए प्रतिक्रिया स्थिति प्राप्त न हो जाए।

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Answer 3

पाइपलाइनिंग http सर्वर पर लगभग कोई फर्क नहीं पड़ता; वे आम तौर पर एक कनेक्शन में अनुरोधों को संसाधित करते हैं - एक अनुरोध पढ़ें, एक प्रतिक्रिया लिखें, फिर अगला अनुरोध पढ़ता है ...

लेकिन क्लाइंट मल्टीप्लेक्सिंग द्वारा थ्रूपुट में सुधार करेगा। वेबसाइटों में आमतौर पर एकाधिक सीपीयू के साथ कई मशीनें होती हैं, आप स्वेच्छा से अपने अनुरोध को एक पंक्ति में क्यों सीमित करना चाहते हैं? आज यह क्षैतिज स्केलेबिलिटी (समवर्ती अनुरोध) के बारे में अधिक है। बेशक, इसे बेंचमार्क करना सबसे अच्छा है।