वेब सर्वर और रिवर्स प्रॉक्सी
nginx: वेब सर्वर जो इवेंट लूप्स द्वारा स्केल करता है
nginx संरचनात्मक कारण से किसी भी अन्य सर्वर की तुलना में वेब के अधिक ट्रैफ़िक को संभालता है: यह C10K को थ्रेड-प्रति-कनेक्शन के बजाय एक इवेंट-संचालित, एसिंक्रोनस मॉडल के साथ हल करता है। व्यवहार में यह एक साथ दो भूमिकाएँ निभाता है, एक हल्का स्थैतिक फ़ाइल सर्वर और उद्योग का डिफ़ॉल्ट रिवर्स प्रॉक्सी, और अधिकांश वास्तविक तैनाती दूसरी होती है। इसके चारों ओर परिचालन अनुशासन (कॉन्फ़िगरेशन परीक्षण, लॉग देखना, टीएलएस स्वचालन) यह तय करता है कि वह शक्ति शांत है या नाजुक है।
मुख्य बिंदु
- इवेंट-लूप आर्किटेक्चर संपूर्ण तर्क है: कम संख्या में कार्यकर्ता प्रक्रियाएं सस्ते संदर्भ स्विच के साथ हजारों कनेक्शनों को संभालती हैं, यही कारण है कि nginx थ्रेड-प्रति-अनुरोध डिज़ाइन की तरह प्रति कनेक्शन मेमोरी को जलाए बिना कई धीमे क्लाइंट (स्थैतिक संपत्ति, डाउनस्ट्रीम मोबाइल उपयोगकर्ता) को प्रॉक्सी करने में उत्कृष्टता प्राप्त करता है।
- एक बाइनरी में दो भूमिकाएँ: सर्वर ब्लॉक स्थिर सामग्री प्रदान करते हैं और पुनर्लेखन लागू करते हैं; प्रॉक्सी_पास ब्लॉक टीएलएस को समाप्त करते हैं और अपस्ट्रीम सेवाओं को आगे बढ़ाते हैं, स्वास्थ्य-आसन्न व्यवहार (मैक्स_फेल्स, टाइमआउट, बफरिंग) के साथ जो मॉड्यूल के बजाय कॉन्फ़िगरेशन सतह हैं, अपाचे सोच से एकल सबसे बड़ी आदत बदलाव।
- कॉन्फ़िगरेशन अनुशासन उबाऊ और अनिवार्य है: प्रत्येक संपादन के बाद nginx -t, प्रति साइट एक फ़ाइल शामिल होती है इसलिए रिवर्ट सर्जिकल होते हैं, और लाइव-चेंज कार्रवाई के रूप में पुनः लोड (पुनः आरंभ नहीं) करते हैं; एक कॉन्फिगरेशन को प्रकाशित करना जो सिंटैक्स परीक्षण में विफल रहता है, एक प्रकार का आउटेज है जिसमें एक दोपहर का समय लगता है लेकिन इसे पूरी तरह से रोका जा सकता है।
- टीएलएस प्रथम श्रेणी का स्तर है: आधुनिक प्रोटोकॉल विकल्प, सत्र बहाली सेटिंग्स और ओसीएसपी स्टेपलिंग, acme.sh या सर्टिफिकेट स्वचालित जारी करने के साथ; गलत तरीके से कॉन्फ़िगर किया गया नवीनीकरण हुक जो 60 दिनों तक चुपचाप विफल रहता है, वह क्लासिक nginx आउटेज है, इसलिए समाप्ति देखने के बजाय प्रमाणपत्र आयु पर सतर्क रहें।
- ईमानदार सीमाएं: अपाचे की तरह कोई गतिशील मॉड्यूल पारिस्थितिकी तंत्र नहीं है (स्थैतिक संकलन-समय मॉड्यूल, इसलिए तृतीय-पक्ष सुविधाओं को पुनर्निर्माण या डिस्ट्रो पैकेज की आवश्यकता होती है), और रिवर्स-प्रॉक्सी सतह जानबूझकर दुबला है क्योंकि जटिलता के लिए nginx का उत्तर अक्सर 'दूसरे उपकरण को सामने रखना' होता है (मोडसिक्योरिटी-क्लास परतों में nginx प्लस WAF में दर सीमित करना)।
- प्रदर्शन कार्य कार्गो पंथ के बजाय वास्तविकता से शुरू होता है: वर्कर_प्रोसेस = ऑटो, वर्कर_कनेक्शन मेमोरी और लोड लिफ़ाफ़े के आकार का, प्रॉक्सी_बफ़रिंग समझा जाता है (बफ़रिंग चालू डिफ़ॉल्ट है और अधिकांश एपीआई के लिए भी सही है), टेक्स्ट प्रकारों पर जीज़िप/ब्रॉटली, और डैशबोर्ड थ्रेशोल्ड रिंग से पहले 499/504 स्पाइक्स के लिए लॉग की समीक्षा की जाती है।
क्षेत्रीय टिप्पणी
nginx कॉन्फिगरेशन जो एक क्लाइंट को सबसे अधिक सिखाता था वह एक फ़ाइल थी: HSTS के साथ एक रिवर्स प्रॉक्सी, ईमानदार कैशिंग हेडर, और प्रति सेवा सर्वर ब्लॉक, सभी 200 लाइनों के तहत। उनके पिछले स्टैक में डुप्लीकेट इन्क्लूड की 4,000 लाइनें थीं और एक रीलोड था जो हर तिमाही में कुछ न कुछ तोड़ता था। कॉन्फिग बागवानी को इंजीनियरिंग के रूप में गिना जाता है।
अक्सर पूछे जाने वाले प्रश्न
nginx बनाम Apache: nginx कब स्पष्ट रूप से सही है?
उच्च-संगामिति रिवर्स प्रॉक्सीइंग, स्थैतिक-भारी ट्रैफ़िक, और बड़े पैमाने पर टीएलएस समाप्ति, इवेंट लूप बिल्कुल वहीं भुगतान करता है। प्रति-निर्देशिका कॉन्फ़िगरेशन के साथ .htaccess-संचालित साझा होस्टिंग के लिए, अपाचे आरामदायक रहता है (हमारा nginx-बनाम-अपाचे लेख ईमानदारी से व्यापार को कवर करता है)।
पुनः लोड बनाम पुनरारंभ नियम क्या है?
पुनः लोड करें (सुंदर, पुराने कर्मचारी मौजूदा कनेक्शन की सेवा समाप्त कर देते हैं जबकि नया कॉन्फिगरेशन कार्यभार संभाल लेता है) दैनिक क्रिया है; पुनरारंभ इंजन संस्करण परिवर्तन और पुनः लोड द्वारा पकड़ में न आने वाली किसी भी चीज़ के लिए है; और न ही पहले चल रहे nginx -t को प्रतिस्थापित करता है।
कुछ साइटें Apache को nginx के पीछे क्यों रखती हैं?
क्लासिक हाइब्रिड स्टैक: nginx TLS को समाप्त करता है, तेजी से स्टैटिक्स प्रदान करता है, और अपाचे के लिए डायनामिक अनुरोधों को प्रॉक्सी करता है जहां .htaccess और mod_php-क्लास टूलिंग पारंपरिक व्यवहार की अपेक्षा करते हैं; लागत लगातार निगरानी और कॉन्फ़िगर करने के लिए एक और गतिशील हिस्सा है।
किन पहली तीन ट्यूनिंग गलतियों से बचना चाहिए?
लोड परीक्षण के बिना ब्लॉग पोस्ट से वर्कर/बफ़र नॉब्स को कॉपी-पेस्ट करना, प्रॉक्सी_बफ़रिंग को धीमा सुनने के बाद उसे बंद कर देना (बफ़रिंग आमतौर पर तेज़ डिफ़ॉल्ट है), और पुनः लोड करने से पहले कॉन्फ़िगरेशन परीक्षण को छोड़ देना; उपरोक्त अनुशासन से इन तीनों को रोका जा सकता है।
वेब सर्वर और रिवर्स प्रॉक्सी में Kinetikatech कैसे सहायता करता है
हम इसे सैकड़ों बार संभाल चुके हैं: प्रोग्राम जो कनेक्शन स्वीकार करते हैं और तय करते हैं कि अनुरोध कैसे प्रवाहित होंगे: nginx, Apache, LiteSpeed, Caddy, और ट्रैफ़िक, साथ ही कॉन्फ़िगरेशन आदतें जो उन्हें तेज़, कैश्ड और हटाने में कठिन बनाती हैं। वेबसाइट गति अनुकूलन और सर्वर प्रबंधन के साथ आपको पूरा चक्र मिलता है — हम आकलन करते हैं, लागू करते हैं, चौबीसों घंटे निगरानी रखते हैं, और महत्वपूर्ण समय में 30 मिनट में जवाब देते हैं।