2017-01-13 18 views
12

मेरे पास एक node.js सर्वर nginx प्रॉक्सी के पीछे चल रहा है। node.js पोर्ट 3000 पर HTTP 1.1 (कोई SSL) सर्वर नहीं चला रहा है। दोनों एक ही सर्वर पर चल रहे हैं।HTTP2 nginx प्रॉक्सी के पीछे node.js के साथ

मैंने हाल ही में एसएसएल (एच 2) के साथ HTTP2 का उपयोग करने के लिए nginx सेट अप किया है। ऐसा लगता है कि HTTP2 वास्तव में सक्षम है और काम कर रहा है।

हालांकि, मैं जानना चाहता हूं कि प्रॉक्सी कनेक्शन (nginx < -> node.js) HTTP 1.1 का उपयोग कर प्रदर्शन को प्रभावित करता है। यही है, क्या मैं गति के संदर्भ में HTTP2 लाभ खो रहा हूं क्योंकि मेरा आंतरिक कनेक्शन HTTP 1.1 है?

उत्तर

15

सामान्य रूप से, HTTP/2 का सबसे बड़ा तत्काल लाभ ब्राउज़र कनेक्शन के लिए multiplexing द्वारा प्रदान की गई गति वृद्धि है जो अक्सर कम विलंबता से बाधित होती है। ये कई कनेक्शनों की आवश्यकता (और महंगी) को भी कम करता है जो HTTP/1.1 में समान प्रदर्शन लाभ प्राप्त करने के लिए चारों ओर एक काम है।

आंतरिक कनेक्शन के लिए (उदाहरण के लिए वेबसर्वर के बीच रिवर्स प्रॉक्सी और बैक एंड ऐप सर्वर के रूप में कार्य करना) विलंबता आम तौर पर बहुत कम है, इसलिए बहुत कम, HTTP/2 के गति लाभ नगण्य हैं। इसके अतिरिक्त प्रत्येक ऐप सर्वर आमतौर पर पहले से ही एक अलग कनेक्शन होगा, इसलिए यहां कोई लाभ नहीं है।

तो आपको किनारे पर HTTP/2 का समर्थन करने से आपके प्रदर्शन लाभ के अधिकतर मिलेगा। यह एक काफी आम सेट अप है - जिस तरह से एचटीटीपीएस को हमेशा विपरीत तरीके से रिवर्स प्रॉक्सी/लोड बैलेंसर पर समाप्त किया जाता है।

हालांकि HTTP/2 को सभी तरह से समर्थन करने के संभावित लाभ हैं। उदाहरण के लिए यह एप्लिकेशन से सर्वर धक्का देता है। HTTP/2 और हेडर संपीड़न की बाइनरी प्रकृति के कारण उस अंतिम हॉप के लिए कम पैकेट आकार से भी संभावित लाभ। हालांकि, विलंबता की तरह, बैंडविड्थ आमतौर पर आंतरिक कनेक्शन के लिए एक मुद्दा से कम है, इसलिए इसका महत्व तर्कसंगत है। अंत में कुछ तर्क देते हैं कि एक रिवर्स प्रॉक्सी एक HTTP/2 कनेक्शन से HTTP/2 कनेक्शन से कनेक्ट करने के लिए HTTP/1.1 कनेक्शन से कनेक्ट करने के लिए कम काम करता है, क्योंकि एक प्रोटोकॉल को दूसरे में परिवर्तित करने की आवश्यकता नहीं है, हालांकि मुझे संदेह है कि यह भी है ध्यान देने योग्य क्योंकि वे अलग कनेक्शन हैं (जब तक कि यह प्रॉक्सी के माध्यम से बस एक टीसीपी पास के रूप में कार्य नहीं कर रहा हो)। तो, मेरे लिए, HTTP/2 को समाप्त करने के अंत का मुख्य कारण सर्वर पुश को समाप्त करने की अनुमति देना है। अधिक जानकारी के लिए See sbordet's answer to this question (and the discussion below it)

अभी के लिए, जबकि सर्वर अभी भी समर्थन जोड़ रहे हैं और सर्वर पुश उपयोग कम है (और अभी भी सर्वोत्तम अभ्यास को परिभाषित करने के लिए प्रयोग किया जा रहा है), मैं केवल अंत बिंदु पर HTTP/2 रखने की अनुशंसा करता हूं।Nginx लिखने के समय भी नहीं है, प्रॉक्सीपास कनेक्शन (हालांकि अपाचे करता है) के लिए HTTP/2 का समर्थन करता है, और no plans to add this है, और वे एक दिलचस्प बिंदु बनाते हैं कि एक HTTP/2 कनेक्शन धीमा (जोर मेरा) पेश कर सकता है या नहीं। :

क्या निकट भविष्य के लिए HTTP/2 प्रॉक्सी समर्थन योजना बनाई गई है?

संक्षिप्त उत्तर:

नहीं, कोई योजना नहीं है।

लांग जवाब:

लगभग कोई मतलब नहीं है यह, के रूप में मुख्य HTTP/2 लाभ है कि यह एक एकल कनेक्शन के भीतर बहुसंकेतन कई अनुरोध की अनुमति देता है, इस प्रकार [लगभग] उस अधिकतम संख्या तक को हटाने है लागू करने के लिए के साथ-साथ अनुरोध - और से अपने स्वयं के बैकएंड से बात करते समय ऐसी कोई सीमा नहीं है। इसके अलावा, HTTP/2 का उपयोग करते समय चीजें भी बदतर हो सकती हैं, क्योंकि एकाधिक टीसीपी कनेक्शन के बजाय का उपयोग किया जा रहा है।

दूसरी ओर, HTTP/2 प्रोटोकॉल को कार्यान्वित करना और अपस्ट्रीम मॉड्यूल में एक कनेक्शन के भीतर मल्टीप्लेक्सिंग का अनुरोध को अपस्ट्रीम मॉड्यूल में बड़े बदलाव की आवश्यकता होगी।

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

अंत में, यह भी ध्यान दिया जाना चाहिए कि, जबकि ब्राउज़रों HTTP/2 (h2) के लिए HTTPS की आवश्यकता होती है, ज्यादातर सर्वर HTTP (H2C) पर इस अंतिम हॉप नहीं है और इसलिए समर्थन कर सके है। तो अगर अंत में नोड भाग पर मौजूद नहीं है तो अंत में एन्क्रिप्शन समाप्त होने की आवश्यकता नहीं होगी (जैसा कि यह अक्सर नहीं होता है)। हालांकि, इस कनेक्शन के लिए बैकएंड सर्वर भी HTTPS पर बैठता है, इस पर निर्भर करता है कि शायद कुछ ऐसा माना जाना चाहिए।

+1

व्यापक उत्तर के लिए धन्यवाद। प्रोटोकॉल के बीच "अनुवाद" पर और मेरी सेटअप में मल्टीप्लेक्सिंग की समग्र प्रभावशीलता पर आपकी टिप्पणियां अधिकतर चीजें थीं जिन्हें मैं ढूंढ रहा था। – Shade

+0

हाय, क्या आप इस विचार को साझा करना चाहते हैं कि आप रिवर्स प्रॉक्सी सेवा और बैकएंड सेवा का उपयोग कर सर्वर पुश को कैसे कार्यान्वित करते हैं? मैंने 'spdy' या मूल' http2' के साथ नोडजेज़ की कोशिश की, दोनों को एसएसएल को काम करने की आवश्यकता होती है (और ऐसा लगता है कि http2 का उपयोग करने के लिए यह महत्वपूर्ण आवश्यकता है चाहे कोई भी lib या प्लेटफॉर्म हो)। खैर, मुझे बैकएंड सेवा के साथ रिवर्स प्रॉक्सी सेवा को गठबंधन करने का विचार नहीं मिला क्योंकि जहां तक ​​मैं देख सकता हूं, हम हमेशा रिवर्स प्रॉक्सी सेवा में एसएसएल का उपयोग करते हैं, हालांकि, बैकएंड सेवा का कहना है कि उन्हें अब भी इसकी आवश्यकता है। और मैं इस बात से सहमत नहीं हो सकता कि यह अंतहीन एन्क्रिप्शन समाप्त करने के लिए बर्बाद है। – cyl19910101

+1

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

3

एनजीआईएनएक्स क्लाइंट के रूप में HTTP/2 का समर्थन नहीं करता है। चूंकि वे एक ही सर्वर पर चल रहे हैं और कोई विलंबता या सीमित बैंडविड्थ नहीं है, मुझे नहीं लगता कि यह किसी भी तरह से अलग हो जाएगा। मैं सुनिश्चित करता हूं कि आप nginx और node.js. के बीच रख-रखाव का उपयोग कर रहे हैं।

https://www.nginx.com/blog/tuning-nginx/#keepalive

2

आप सामान्य रूप में प्रदर्शन को खोने नहीं कर रहे हैं, क्योंकि nginx अनुरोध बहुसंकेतन अपने नोड बैकएंड के लिए एकाधिक अनुरोध बनाने के द्वारा ब्राउज़र के HTTP/2 करता है मेल खाता है। (HTTP/2 के प्रमुख प्रदर्शन सुधारों में से एक ब्राउज़र को एक ही कनेक्शन पर एकाधिक एक साथ अनुरोध करने की अनुमति दे रहा है, जबकि HTTP 1.1 में प्रति कनेक्शन केवल एक साथ अनुरोध संभव है। और ब्राउज़र भी कनेक्शन की संख्या को सीमित करते हैं।)

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