👘 🛣️ 👩🏽‍🔧 FastCGI का उपयोग करके C / C ++ वेब एप्लिकेशन

शुभ दोपहर
इस लेख में, मैं FastCGI प्रोटोकॉल और इसके साथ काम करने के तरीके के बारे में बात करना चाहूंगा। इस तथ्य के बावजूद कि प्रोटोकॉल स्वयं और इसके कार्यान्वयन 1996 में वापस दिखाई दिए, इस प्रोटोकॉल के लिए बस कोई विस्तृत मैनुअल नहीं हैं - डेवलपर्स ने अपने स्वयं के पुस्तकालय का संदर्भ नहीं लिखा है। लेकिन दो साल पहले, जब मैंने इस प्रोटोकॉल का उपयोग करना शुरू किया था, तो "मैं इस पुस्तकालय का उपयोग कैसे करना है, यह समझ नहीं पाया" जैसे वाक्यांश अक्सर पाए जाते थे। यह कमी है कि मैं सही करना चाहता हूं - एक बहु-थ्रेडेड प्रोग्राम में इस प्रोटोकॉल के उपयोग पर एक विस्तृत मार्गदर्शिका लिखना और विभिन्न मापदंडों को चुनने के लिए सिफारिशें जो हर कोई उपयोग कर सकता है।

अच्छी खबर यह है कि जिस तरह से डेटा को FastCGI और CGI में एन्कोड किया गया है, केवल वही है, जिस तरह से वे प्रेषित परिवर्तन हैं: यदि CGI प्रोग्राम मानक I / O इंटरफ़ेस का उपयोग करता है, तो FastCGI प्रोग्राम सॉकेट्स का उपयोग करता है। दूसरे शब्दों में, आपको बस FastCGI के साथ काम करने के लिए पुस्तकालय के कई कार्यों से निपटने की आवश्यकता है, और फिर सीजीआई कार्यक्रमों को लिखने के अनुभव का लाभ उठाएं, सौभाग्य से, उनके कई उदाहरण हैं।

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

FastCGI क्या है?

आप FastCGI के बारे में विकिपीडिया पर पढ़ सकते हैं। संक्षेप में, यह एक CGI प्रोग्राम है जो लूप में चल रहा है। यदि प्रत्येक नए अनुरोध के लिए नियमित CGI प्रोग्राम को पुनरारंभ किया जाता है, तो FastCGI प्रोग्राम अनुरोधों की एक कतार का उपयोग करता है जो क्रमिक रूप से संसाधित होते हैं। अब कल्पना करें: 300-500 एक साथ अनुरोध आपके 4-8-कोर सर्वर पर आए। इन्हीं 300-500 बार निष्पादित करने के लिए एक नियमित सीजीआई कार्यक्रम शुरू किया जाएगा। जाहिर है, बहुत सारी प्रक्रियाएं हैं - आपका सर्वर शारीरिक रूप से उन सभी को एक साथ काम नहीं कर सकता है। तो, आप प्रोसेसर समय के उनके क्वांटम के लिए इंतजार कर प्रक्रियाओं की एक कतार मिल जाएगा। आमतौर पर, अनुसूचक प्रोसेसर को समान रूप से वितरित करेगा (जैसा कि इस मामले में, सभी प्रक्रियाओं की प्राथमिकताएं समान हैं), जिसका अर्थ है कि आपके पास अनुरोधों के लिए 300-500 "लगभग तैयार" प्रतिक्रियाएं होंगी। किसी भी तरह बहुत आशावादी नहीं लगता है, है ना? एक FastCGI कार्यक्रम में, इन सभी समस्याओं को एक सरल अनुरोध कतार द्वारा हल किया जाता है (अर्थात, अनुरोध मल्टीप्लेक्सिंग लागू किया जाता है)।

जब पहले से ही PHP, Ruby, Python, Perl, इत्यादि हों, तो मुझे FastCGI की आवश्यकता क्यों है?

शायद मुख्य कारण यह है कि संकलित कार्यक्रम की व्याख्या की तुलना में तेजी से चलेगा। PHP के लिए, उदाहरण के लिए, APC, eAccelerator, XCache सहित त्वरक की एक पूरी पंक्ति है, जो कोड व्याख्या समय को कम करते हैं। लेकिन C / C ++ के लिए, यह सब आवश्यक नहीं है।
दूसरी बात जो आपको ध्यान में रखनी चाहिए वह यह है कि डायनामिक टाइपिंग और कचरा संग्रहकर्ता बहुत सारे संसाधन जुटा लेते हैं। कभी-कभी बहुत। उदाहरण के लिए, PHP में पूर्णांक सरणियाँ डेटा की समान मात्रा के लिए C / C ++ की तुलना में लगभग 18 गुना अधिक मेमोरी (विभिन्न PHP संकलन विकल्पों के आधार पर 35 गुना तक) लेती हैं , इसलिए अपेक्षाकृत बड़े डेटा संरचनाओं के लिए ओवरहेड के बारे में सोचें।
तीसरा, एक FastCGI प्रोग्राम विभिन्न अनुरोधों के लिए डेटा को सामान्य रूप से संग्रहीत कर सकता है। उदाहरण के लिए, यदि PHP हर बार स्क्रैच से अनुरोध को संसाधित करना शुरू कर देता है, तो FastCGI प्रोग्राम पहले अनुरोध आने से पहले भी कई प्रारंभिक कार्रवाई कर सकता है, उदाहरण के लिए, मेमोरी आवंटित करें, अक्सर उपयोग किए गए डेटा लोड करें आदि। - जाहिर है, यह सब समग्र प्रणाली के प्रदर्शन को बढ़ा सकता है।
चौथा स्केलेबिलिटी है। यदि mod_php मानता है कि Apache वेब सर्वर और PHP एक ही मशीन पर हैं, तो FastCGI एप्लिकेशन टीसीपी जेब का उपयोग कर सकता है। दूसरे शब्दों में, आपके पास कई मशीनों का एक पूरा समूह हो सकता है जो आपके साथ नेटवर्क पर संचार करते हैं। इसी समय, FastCGI भी यूनिक्स डोमेन सॉकेट्स का समर्थन करता है, जो आपको आवश्यक होने पर उसी मशीन पर FastCGI एप्लिकेशन और वेब सर्वर को कुशलतापूर्वक चलाने की अनुमति देता है।
पांचवीं सुरक्षा है। आप इसे मानते नहीं हैं, लेकिन डिफ़ॉल्ट सेटिंग्स के साथ Apache आपको दुनिया में सब कुछ करने की अनुमति देता है। उदाहरण के लिए, यदि कोई हमलावर "निर्दोष छवि" की आड़ में किसी दुर्भावनापूर्ण शोषण.php.jpg स्क्रिप्ट को साइट पर अपलोड करता है और फिर उसे एक ब्राउज़र में खोलता है, तो Apache दुर्भावनापूर्ण php कोड को "ईमानदारी से" निष्पादित करेगा। शायद डाउनलोड किए गए फ़ाइलों के नामों से सभी संभावित खतरनाक एक्सटेंशन को निकालने या बदलने के लिए एकमात्र विश्वसनीय समाधान है, इस मामले में php, php4, php5, phtml, आदि। इस तरह की तकनीक का उपयोग किया जाता है, उदाहरण के लिए, ड्रुपल में - सभी "अतिरिक्त" एक्सटेंशन में एक अंडरस्कोर जोड़ा जाता है और शोषण। Php_.jpg प्राप्त किया जाता है। यह सच है, यह ध्यान दिया जाना चाहिए कि सिस्टम प्रशासक किसी भी अतिरिक्त फ़ाइल एक्सटेंशन को php हैंडलर के रूप में जोड़ सकता है, इसलिए कुछ .html अचानक एक भयानक सुरक्षा छेद में बदल सकते हैं। केवल इसलिए कि यह बदसूरत लग रहा था, यह SEO के लिए बुरा था। ग्राहक को पसंद नहीं आया। तो, सुरक्षा की दृष्टि से हमें FastCGI क्या देता है? सबसे पहले, यदि आप अपाचे के बजाय नग्नेक्स वेब सर्वर का उपयोग करते हैं, तो यह बस स्थैतिक फ़ाइलों को दूर कर देगा। बिंदु। दूसरे शब्दों में, शोषक.php.jpg फ़ाइल को सर्वर के किसी भी प्रसंस्करण के बिना "जैसा है" दिया जाएगा, इसलिए केवल एक दुर्भावनापूर्ण स्क्रिप्ट लॉन्च करने से काम नहीं चलेगा। दूसरे, FastCGI प्रोग्राम और वेब सर्वर विभिन्न उपयोगकर्ताओं से काम कर सकते हैं, जिसका अर्थ है कि उनके पास फ़ाइलों और फ़ोल्डरों के लिए अलग-अलग अधिकार होंगे। उदाहरण के लिए, एक वेब सर्वर केवल डाउनलोड की गई फ़ाइलों को पढ़ सकता है - यह स्थैतिक डेटा को वापस करने के लिए पर्याप्त है, और एक FastCGI प्रोग्राम केवल डाउनलोड की गई फ़ाइलों के साथ एक फ़ोल्डर की सामग्री को पढ़ और बदल सकता है - यह नई फ़ाइलों को डाउनलोड करने और पुरानी फ़ाइलों को हटाने के लिए पर्याप्त है, लेकिन डाउनलोड की गई फ़ाइलों तक सीधे पहुंचें नहीं होगा, जिसका अर्थ है कि यह दुर्भावनापूर्ण कोड को निष्पादित करने में सक्षम नहीं होगा। तीसरा, एक FastCGI प्रोग्राम एक वेब सर्वर के चेरोट के अलावा एक चेरोट में चल सकता है। अपने आप से, चेरोट (रूट निर्देशिका को बदलना) आपको प्रोग्राम के अधिकारों को गंभीर रूप से सीमित करने की अनुमति देता है, अर्थात, सिस्टम की समग्र सुरक्षा को बढ़ाता है, क्योंकि प्रोग्राम केवल निर्दिष्ट निर्देशिका के बाहर फ़ाइलों तक नहीं पहुंच सकता है।

FastCGI समर्थन वाला कौन सा वेब सर्वर चुनना बेहतर है?

संक्षेप में - मैं Nginx का उपयोग करता हूं। सामान्य तौर पर, FastCGI समर्थन के साथ काफी कम सर्वर हैं, जिनमें वाणिज्यिक भी शामिल हैं, इसलिए मुझे कुछ विकल्पों पर विचार करने दें।
अपाचे शायद पहली बात है जो दिमाग में आती है, हालांकि यह नग्नेक्स की तुलना में बहुत अधिक संसाधनों का उपभोग करता है। उदाहरण के लिए, 10,000 निष्क्रिय HTTP कीप-सजीव कनेक्शनों के लिए, नग्नेक्स लगभग 2.5M मेमोरी की खपत करता है, जो अपेक्षाकृत कमजोर मशीन के लिए भी काफी यथार्थवादी है, और अपाचे प्रत्येक नए कनेक्शन के लिए एक नया धागा बनाने के लिए मजबूर है, इसलिए 10,000 धागे बस शानदार हैं।
लाइटटैप - इस वेब सर्वर का मुख्य दोष यह है कि यह एक ही धागे में सभी अनुरोधों को संसाधित करता है। इसका मतलब यह है कि स्केलेबिलिटी के साथ समस्याएं हो सकती हैं - आप आधुनिक प्रोसेसर के सभी 4-8 कोर का उपयोग नहीं कर सकते हैं। और दूसरा - यदि किसी कारण से वेब सर्वर का प्रवाह लटका हुआ है (उदाहरण के लिए, हार्ड डिस्क से प्रतिक्रिया के लिए लंबे इंतजार के कारण), तो आपका पूरा सर्वर "हैंग" होगा। दूसरे शब्दों में, एक धीमी गति से अनुरोध के कारण अन्य सभी ग्राहक प्रतिक्रियाएं प्राप्त करना बंद कर देंगे।
एक अन्य उम्मीदवार चेरोकी है । डेवलपर्स के अनुसार, कुछ मामलों में यह नगनेक्स और लाइटटैप से तेज है।

FastCGI प्रोटोकॉल कार्यान्वयन क्या हैं?

फिलहाल FastCGI प्रोटोकॉल के दो कार्यान्वयन हैं - FastCGI प्रोटोकॉल के रचनाकारों से libfcgi.lib लाइब्रेरी, और Fastcgi ++ - C ++ क्लास लाइब्रेरी। Libfcgi 1996 के बाद से विकसित की गई है और, ओपन मार्केट के अनुसार, बहुत स्थिर है, इसके अलावा, यह अधिक सामान्य है, इसलिए हम इस लेख में इसका उपयोग करेंगे। मैं यह नोट करना चाहूंगा कि लाइब्रेरी सी में लिखी गई है, सी ++ के बिल्ट-इन "रैपर" को उच्च-स्तरीय नहीं कहा जा सकता है, इसलिए हम सी-इंटरफ़ेस का उपयोग करेंगे।
मुझे लगता है कि पुस्तकालय को स्थापित करने से रोकने का कोई मतलब नहीं है - इसमें एक बदलाव है, इसलिए कोई समस्या नहीं होनी चाहिए। इसके अलावा, लोकप्रिय वितरणों में, यह पुस्तकालय संकुल से उपलब्ध है।

सॉकेट्स क्या हैं?

सॉकेट की एक सामान्य अवधारणा विकिपीडिया पर उपलब्ध है। संक्षेप में, सॉकेट इंटरप्रोसेस संचार का एक तरीका है।
जैसा कि हम याद करते हैं, सभी आधुनिक ऑपरेटिंग सिस्टम में, प्रत्येक प्रक्रिया अपने स्वयं के एड्रेस स्पेस का उपयोग करती है। ऑपरेटिंग सिस्टम का कर्नेल रैम तक सीधी पहुंच के लिए जिम्मेदार है, और यदि प्रोग्राम एक गैर-मौजूद (इस प्रोग्राम के संदर्भ में) मेमोरी एड्रेस तक पहुंचता है, तो कर्नेल एक विभाजन दोष (विभाजन त्रुटि) को वापस कर देगा और प्रोग्राम को बंद कर देगा। यह अद्भुत है - अब एक कार्यक्रम में त्रुटियां बस दूसरों को नुकसान नहीं पहुंचा सकती हैं - वे हैं, जैसा कि अन्य आयामों में था। लेकिन चूंकि कार्यक्रमों में अलग-अलग पते के स्थान हैं, इसलिए साझा डेटा या डेटा एक्सचेंज से कोई डेटा एक्सचेंज नहीं हो सकता है। और अगर आपको वास्तव में एक प्रोग्राम से दूसरे में डेटा ट्रांसफर करने की आवश्यकता है, तो कैसे? दरअसल, इस समस्या को हल करने के लिए, सॉकेट विकसित किए गए थे - दो या अधिक प्रक्रियाएं (पढ़ें: प्रोग्राम) एक ही सॉकेट से कनेक्ट होती हैं और डेटा एक्सचेंज शुरू करती हैं। यह दूसरी दुनिया के लिए "विंडो" का एक प्रकार है - इसके माध्यम से आप अन्य धाराओं के लिए डेटा प्राप्त कर सकते हैं और भेज सकते हैं।
कनेक्शन के उपयोग के प्रकार के आधार पर, सॉकेट अलग-अलग हैं। उदाहरण के लिए, टीसीपी सॉकेट हैं - वे डेटा का आदान-प्रदान करने के लिए एक सामान्य नेटवर्क का उपयोग करते हैं, अर्थात, प्रोग्राम विभिन्न कंप्यूटरों पर चल सकते हैं। दूसरा सबसे आम विकल्प - यूनिक्स डोमेन सॉकेट्स (यूनिक्स डोमेन सॉकेट) - केवल एक ही मशीन के भीतर डेटा एक्सचेंज के लिए उपयुक्त हैं और फाइल सिस्टम में एक सामान्य पथ की तरह दिखते हैं, लेकिन असली हार्ड ड्राइव का उपयोग नहीं किया जाता है - सभी डेटा एक्सचेंज रैम में होते हैं। इस तथ्य के कारण कि आपको नेटवर्क स्टैक का उपयोग करने की आवश्यकता नहीं है, वे टीसीपी सॉकेट्स की तुलना में कुछ तेज़ी से (लगभग 10%) काम करते हैं। विंडोज के लिए, इस सॉकेट विकल्प को पाइप कहा जाता है।
जीएनयू / लिनक्स के लिए सॉकेट उपयोग के उदाहरण इस लेख में पाए जा सकते हैं। यदि आपने अभी तक सॉकेट्स के साथ काम नहीं किया है, तो मैं आपको सलाह दूंगा कि आप अपने आप को इसके साथ परिचित करें - यह आवश्यक नहीं है, लेकिन यहां वर्णित चीजों की आपकी समझ में सुधार होगा।

Libfcgi लाइब्रेरी का उपयोग कैसे करें?

इसलिए, हम एक बहु-थ्रेडेड FastCGI एप्लिकेशन बनाना चाहते हैं, इसलिए मुझे कुछ सबसे महत्वपूर्ण कार्यों का वर्णन करना चाहिए।
सबसे पहले, पुस्तकालय को आरंभ करने की आवश्यकता है:

int FCGX_Init(void);

चेतावनी! इस फ़ंक्शन को इस लाइब्रेरी के किसी भी अन्य कार्यों से पहले और केवल एक बार (केवल एक बार, किसी भी थ्रेड के लिए) कॉल करने की आवश्यकता है।

आगे हमें सुनने वाला सॉकेट खोलने की जरूरत है:

 int FCGX_OpenSocket(const char *path, int backlog);

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

 "/tmp/fastcgi/mysocket" "/tmp/fcgi_example.bare.sock"

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

 ":5000" ":9000"

इस मामले में, एक टीसी सॉकेट निर्दिष्ट पोर्ट (इस मामले में, क्रमशः 5000 या 9000) पर खोला जाता है, और किसी भी आईपी पते से अनुरोध स्वीकार किए जाएंगे। चेतावनी! यह विधि संभावित रूप से असुरक्षित है - यदि आपका सर्वर इंटरनेट से जुड़ा है, तो आपका FastCGI प्रोग्राम किसी अन्य कंप्यूटर से अनुरोध स्वीकार करेगा। इसका मतलब है कि कोई भी हमलावर आपके डेथ पैकेज को आपके FastCGI प्रोग्राम में भेज सकता है। बेशक, इसमें कुछ भी अच्छा नहीं है - सबसे अच्छे मामले में, आपका कार्यक्रम बस दुर्घटनाग्रस्त हो सकता है और सेवा से इनकार कर सकता है (DoS attack, यदि आप चाहते हैं), सबसे खराब, दूरस्थ कोड निष्पादन में (यदि यह सभी भाग्यशाली नहीं है), तो हमेशा सीमित करें फ़ायरवॉल (फ़ायरवॉल) का उपयोग करके ऐसे बंदरगाहों तक पहुंच, और एक्सेस केवल उन आईपी पते को दी जानी चाहिए जो वास्तव में FastCGI कार्यक्रम के सामान्य संचालन के दौरान उपयोग किए जाते हैं (सिद्धांत "सब कुछ निषिद्ध है जो स्पष्ट रूप से अनुमत नहीं है")।
निम्नलिखित उदाहरण कनेक्शन तार:

 "*:5000" "*:9000"

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

 "5.5.5.5:5000" "127.0.0.1:9000"

इस मामले में, अनुरोध केवल निर्दिष्ट आईपी पते से स्वीकार किया जाएगा (इस मामले में, क्रमशः 5.5.5.5 या 127.0.0.1), अन्य सभी आईपी पते के लिए यह बंदरगाह (इस मामले में, 5000 या 9000, क्रमशः) बंद हो जाएगा। यह सिस्टम की समग्र सुरक्षा को बढ़ाता है, इसलिए जब भी संभव हो तो हमेशा टीसीपी सॉकेट्स से कनेक्ट करने के लिए स्ट्रिंग के इस प्रारूप का उपयोग करें - क्या होगा यदि सिस्टम व्यवस्थापक फ़ायरवॉल को कॉन्फ़िगर करने के लिए "बस भूल जाता है"? मैं आपको दूसरे उदाहरण पर ध्यान देने के लिए कहता हूं - उसी मशीन का पता (लोकलहोस्ट) वहां इंगित किया गया है। यह आपको एक ही मशीन पर एक टीसी सॉकेट बनाने की अनुमति देता है यदि किसी कारण से आप यूनिक्स डोमेन सॉकेट्स का उपयोग नहीं कर सकते हैं (उदाहरण के लिए, क्योंकि चेरोट वेब सर्वर और चेरोट FastCGI प्रोग्राम विभिन्न फ़ोल्डरों में हैं और आम फ़ाइल पथ नहीं हैं )। दुर्भाग्य से, आप दो या अधिक भिन्न IP पते निर्दिष्ट नहीं कर सकते हैं, इसलिए यदि आपको वास्तव में विभिन्न कंप्यूटरों पर स्थित कई वेब सर्वरों से अनुरोध स्वीकार करने की आवश्यकता है, तो आपको पोर्ट को पूरी तरह से खोलना होगा (पिछली विधि देखें) और अपनी सेटिंग्स पर भरोसा करें फ़ायरवॉल, या विभिन्न बंदरगाहों पर कई सॉकेट का उपयोग करें। इसके अलावा, libfcgi लाइब्रेरी IPv6 पतों का समर्थन नहीं करती है - 1996 में वापस, यह मानक बस पैदा हुआ था, इसलिए आपको अपने भूख को नियमित IPv4 पतों तक सीमित करना होगा। सच है, अगर आपको वास्तव में IPv6 समर्थन की आवश्यकता है, तो इसे जोड़ना अपेक्षाकृत आसान है, FCGX_OpenSocket फ़ंक्शन को पैच करना - लाइब्रेरी लाइसेंस यह अनुमति देता है।
चेतावनी! सॉकेट बनाते समय एक आईपी पते को निर्दिष्ट करने के फ़ंक्शन का उपयोग करना पर्याप्त सुरक्षा नहीं है - आईपी स्पूफिंग हमले संभव हैं (पैकेट के प्रेषक के आईपी पते को खराब करना), इसलिए फ़ायरवॉल स्थापित करना अभी भी आवश्यक है। आमतौर पर, आईपी स्पूफिंग के खिलाफ सुरक्षा के रूप में, फ़ायरवॉल पैकेट के आईपी पते और नेटवर्क कार्ड के मैक पते के बीच हमारे स्थानीय नेटवर्क पर सभी मेजबानों (अधिक सटीक, हमारे मेजबान के साथ प्रसारण डोमेन के लिए) के पत्राचार की जांच करता है, और इंटरनेट से आने वाले सभी पैकेटों को डिस्कनेक्ट करता है जिसका रिवर्स पता निजी आईपी पते या स्थानीय होस्ट (मास्क 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00 :: / 7, 127.0.0.0/8 और :: 1/128) के क्षेत्र में स्थित है। फिर भी, लाइब्रेरी की इस विशेषता का उपयोग करना अभी भी बेहतर है - गलत तरीके से कॉन्फ़िगर किए गए फ़ायरवॉल के मामले में, एक फेक आईपी पते से "मौत का पैकेट" भेजना किसी भी एक की तुलना में बहुत अधिक कठिन है, क्योंकि टीसीपी प्रोटोकॉल ने आईपी स्पूफिंग के साथ अंतर्निहित सुरक्षा की है।
होस्ट डोमेन नाम का उपयोग करने के लिए अंतिम प्रकार का कनेक्शन स्ट्रिंग है:

 "example.com:5000" "localhost:9000"

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

बैकलॉग फ़ंक्शन के लिए दूसरा पैरामीटर सॉकेट अनुरोध कतार की लंबाई निर्धारित करता है। विशेष मान 0 (शून्य) का अर्थ है इस ऑपरेटिंग सिस्टम के लिए डिफ़ॉल्ट कतार लंबाई।
हर बार एक अनुरोध वेब सर्वर से आता है, हमारे FastCGI कार्यक्रम द्वारा प्रसंस्करण की प्रतीक्षा करते समय इस कतार में एक नया कनेक्शन डाला जाता है। यदि कतार पूरी तरह से भरी हुई है, तो बाद के सभी कनेक्शन अनुरोध विफल हो जाएंगे - वेब सर्वर को एक कनेक्शन अस्वीकृत प्रतिक्रिया (कनेक्शन मना कर दिया गया) प्राप्त होगा। सिद्धांत रूप में, इसमें कुछ भी गलत नहीं है - नग्नेक्स वेब सर्वर की अपनी अनुरोध कतार है, और यदि कोई मुक्त संसाधन नहीं हैं, तो नए अनुरोध वेब सर्वर कतार में पहले से ही संसाधित होने के लिए अपनी बारी का इंतजार करेंगे (कम से कम जब तक समय बाहर)। इसके अलावा, यदि आपके पास FastCGI-program चलाने वाले कई सर्वर हैं, तो Nginx इस तरह के अनुरोध को कम लोड वाले सर्वर में स्थानांतरित कर सकता है।
तो, चलो यह पता लगाने की कोशिश करें कि कौन सी कतार की लंबाई इष्टतम होगी। सामान्य तौर पर, तनाव परीक्षण के आंकड़ों के आधार पर इस पैरामीटर को व्यक्तिगत रूप से कॉन्फ़िगर करना बेहतर होता है, लेकिन हम इस मूल्य के लिए सबसे उपयुक्त सीमा का मूल्यांकन करने का प्रयास करेंगे। पहली चीज़ जो आपको जानना आवश्यक है कि अधिकतम कतार की लंबाई सीमित है (ऑपरेटिंग सिस्टम की कर्नेल सेटिंग्स द्वारा निर्धारित की जाती है, आमतौर पर 1024 कनेक्शन से अधिक नहीं)। दूसरा - कतार संसाधनों का उपभोग करता है, सस्ता है, लेकिन अभी भी संसाधन है, इसलिए यह अनुचित रूप से लंबे समय तक करने के लायक नहीं है। इसके अलावा, मान लें कि हमारे FastCGI कार्यक्रम में 8 वर्कफ़्लोज़ (आधुनिक 4-8-कोर प्रोसेसर के लिए काफी यथार्थवादी) हैं, और प्रत्येक थ्रेड को अपने स्वयं के कनेक्शन की आवश्यकता है - कार्यों को समानांतर में संसाधित किया जाता है। इसलिए, आदर्श रूप से, हमारे पास वेब सर्वर से पहले से ही 8 अनुरोध होने चाहिए, ताकि तुरंत, अनावश्यक देरी के बिना, यह सुनिश्चित करने के लिए कि सभी थ्रेड काम करते हैं। दूसरे शब्दों में, न्यूनतम अनुरोध कतार का आकार FastCGI प्रोग्राम के कार्य थ्रेड्स की संख्या है। आप लोडिंग के लिए कुछ मार्जिन प्रदान करने के लिए इस मूल्य को 50% -100% तक बढ़ाने की कोशिश कर सकते हैं, क्योंकि नेटवर्क पर डेटा ट्रांसफर का समय सीमित है।
अब इस मात्रा की ऊपरी सीमा को परिभाषित करते हैं। यहां आपको यह जानना होगा कि हम वास्तव में कितने अनुरोधों को संसाधित कर सकते हैं और इस मूल्य के लिए अनुरोधों की कतार को सीमित कर सकते हैं। कल्पना करें कि आपने इस कतार को बहुत बड़ा बना दिया है - इतना अधिक कि आपके ग्राहक अपनी बारी के इंतजार में ऊब गए हैं और वे बस आपकी साइट पर एक उत्तर की प्रतीक्षा किए बिना छोड़ देते हैं। जाहिर है, इसमें कुछ भी अच्छा नहीं है - वेब सर्वर को एक कनेक्शन खोलने के लिए अनुरोध भेजना था, जो अपने आप में महंगा है, और फिर इस कनेक्शन को केवल इसलिए बंद कर दें क्योंकि FastCGI प्रोग्राम के पास इस अनुरोध को संसाधित करने के लिए पर्याप्त समय नहीं था। एक शब्द में, हम केवल सीपीयू समय बर्बाद कर रहे हैं, लेकिन हमारे पास इसके लिए पर्याप्त नहीं है! लेकिन यह सबसे बुरी बात नहीं है - यह तब और बुरा होता है जब ग्राहक ने आपकी साइट से पहले ही इस क्षेत्र की जानकारी प्राप्त करने से इनकार कर दिया था। यह पता चला है कि हमें अनिवार्य रूप से अनावश्यक अनुरोध को पूरी तरह से संसाधित करना होगा, जिसे आप देखते हैं, केवल स्थिति खराब हो जाएगी। सैद्धांतिक रूप से, एक स्थिति उत्पन्न हो सकती है जब अधिकांश ग्राहक आपके प्रोसेसर के 100% लोड पर उत्तर की प्रतीक्षा नहीं करेंगे। यह अच्छा नहीं है।
तो, मान लें कि एक अनुरोध हम 300 मिलीसेकंड (यानी 0.3 सेकंड) में संसाधित कर सकते हैं। इसके अलावा, हम जानते हैं कि यदि वेब पेज 30 सेकंड से अधिक समय तक लोड रहता है, तो औसतन 50% आगंतुक संसाधन छोड़ देते हैं। जाहिर है, असंतुष्ट लोगों में से 50% बहुत अधिक हैं, इसलिए हम अधिकतम पृष्ठ लोड समय को 5 सेकंड तक सीमित कर देंगे। इसका मतलब है एक पूरी तरह से समाप्त वेब पेज - कैस्केडिंग स्टाइल शीट लगाने और जावा स्क्रिप्ट को निष्पादित करने के बाद - एक औसत साइट पर यह चरण कुल वेब पेज लोड समय का 70% तक ले सकता है। इसलिए, नेटवर्क पर डेटा डाउनलोड करने के लिए 5 * 0.3 = 1.5 सेकंड से अधिक नहीं बचे हैं। इसके अलावा यह याद रखना चाहिए कि HTML कोड, स्टाइल शीट, स्क्रिप्ट और ग्राफिक्स अलग-अलग फ़ाइलों में संचरित हैं, पहले html कोड, और फिर सब कुछ। हालांकि, HTML कोड प्राप्त करने के बाद, ब्राउज़र समानांतर में शेष संसाधनों का अनुरोध करना शुरू कर देता है, ताकि आप डेटा प्राप्त करने के लिए कुल समय के 50% के रूप में HTML कोड के लोडिंग समय का अनुमान लगा सकें। इसलिए, हमारे पास एक अनुरोध को संसाधित करने के लिए 1.5 * 0.5 = 0.75 सेकंड से अधिक नहीं बचा है। यदि औसतन एक धागा 0.3 सेकंड में अनुरोध को संसाधित करता है, तो कतार में प्रति धागा 0.75 / 0.3 = 2.5 अनुरोध होना चाहिए। चूंकि हमारे पास 8 वर्कफ़्लो हैं, जिसके परिणामस्वरूप कतार का आकार 2.5 * 8 = 20 अनुरोध होना चाहिए। मैं उपरोक्त गणनाओं के सम्मेलनों को नोट करना चाहूंगा - यदि आपके पास एक विशिष्ट साइट है, तो गणना में उपयोग किए जाने वाले मूल्यों को अधिक सटीक रूप से निर्धारित किया जा सकता है, लेकिन फिर भी यह अधिक इष्टतम प्रदर्शन ट्यूनिंग के लिए एक प्रारंभिक बिंदु प्रदान करता है।

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

 typedef struct FCGX_Request { int requestId; int role; FCGX_Stream *in; FCGX_Stream *out; FCGX_Stream *err; char **envp; struct Params *paramsPtr; int ipcFd; int isBeginProcessed; int keepConnection; int appStatus; int nWriters; int flags; int listen_sock; int detached; } FCGX_Request;

चेतावनी! एक नया अनुरोध प्राप्त करने के बाद, पिछले सभी डेटा खो जाएंगे, इसलिए यदि आपको डेटा के दीर्घकालिक भंडारण की आवश्यकता है, तो गहरी प्रतिलिपि का उपयोग करें (डेटा को स्वयं कॉपी करें, डेटा को इंगित नहीं करें)।
आपको इस संरचना के बारे में निम्नलिखित जानना चाहिए:
- क्रमशः, बाहर, और गलत तरीके से चर इनपुट, आउटपुट और त्रुटि प्रवाह की भूमिका निभाते हैं। इनपुट स्ट्रीम में POST रिक्वेस्ट का डेटा होता है, FastCGI प्रोग्राम की प्रतिक्रिया (उदाहरण के लिए, http- हेडर और वेब पेज का HTML-कोड) आउटपुट स्ट्रीम में भेजी जानी चाहिए, और एरर स्ट्रीम बस वेब सर्वर को एरर लॉग में जोड़ेगी। उसी समय, आपको त्रुटि स्ट्रीम का उपयोग करने की आवश्यकता नहीं है - यदि आपको वास्तव में त्रुटियों को लॉग करने की आवश्यकता है, तो शायद नेटवर्क पर एक अलग फ़ाइल - डेटा ट्रांसमिशन और वेब सर्वर द्वारा उनके बाद के प्रसंस्करण का उपयोग करना बेहतर है अतिरिक्त संसाधनों की खपत होती है।
- envp वैरिएबल में वेब सर्वर और http हेडर द्वारा सेट किए गए पर्यावरण वेरिएबल्स के मूल्य शामिल हैं, उदाहरण के लिए: SERVER_PROTOCOL, REQUEST_METHOD, REQUEST_URI, QUERY_STRING, CONTENT_LENGTH, HTTP_USER_AGENT, HTTP_COOKIE, HTTP_REFER और so ये हेडर क्रमशः CGI और HTTP प्रोटोकॉल मानकों द्वारा परिभाषित किए गए हैं, उनके उपयोग के उदाहरण किसी भी CGI प्रोग्राम में पाए जा सकते हैं। डेटा खुद को स्ट्रिंग के एक सरणी में संग्रहीत किया जाता है, सरणी के अंतिम तत्व को इंगित करने के लिए एक शून्य सूचक (NULL) युक्त सरणी के अंतिम तत्व के साथ। प्रत्येक पंक्ति (स्ट्रिंग ऐरे के प्रत्येक तत्व) में TITLE_VARIABLE = VALUE प्रारूप में एक चर मान होता है, उदाहरण के लिए: CONTENT_LENGTH = 0 (इस मामले में, इस अनुरोध में POST डेटा नहीं है, क्योंकि इसकी लंबाई शून्य है)। यदि एनवीपी स्ट्रिंग ऐरे में आपके पास आवश्यक हेडर नहीं है, तो इसे पारित नहीं किया गया है। यदि आप FastCGI प्रोग्राम में दिए गए चर के सभी मूल्यों को प्राप्त करना चाहते हैं, तो बस एनएलवी की सभी पंक्तियों को एक लूप में पढ़ें, जब तक कि आप NULL को पॉइंटर न ढूंढ लें।
दरअसल, हमने इसे इस संरचना के विवरण के साथ समाप्त किया है - आपको अन्य सभी चर की आवश्यकता नहीं होगी।

स्मृति आवंटित की गई थी, अब आपको अनुरोध संरचना को आरंभ करने की आवश्यकता है:

 int FCGX_InitRequest(FCGX_Request *request, int sock, int flags);

फ़ंक्शन पैरामीटर निम्नानुसार हैं:
अनुरोध - डेटा संरचना के लिए एक सूचक को आरंभीकृत किया जाना है
sock FCGX_OpenSocket फ़ंक्शन को कॉल करने के बाद प्राप्त सॉकेट डिस्क्रिप्टर है। मैं यह नोट करना चाहूंगा कि एक तैयार किए गए डिस्क्रिप्टर के बजाय, आप 0 (शून्य) पास कर सकते हैं और डिफ़ॉल्ट सेटिंग्स के साथ एक सॉकेट प्राप्त कर सकते हैं, लेकिन हमारे लिए यह विधि पूरी तरह से दिलचस्प नहीं है - सॉकेट एक यादृच्छिक मुक्त पोर्ट पर खोला जाएगा, जिसे हम अपने वेब को ठीक से कॉन्फ़िगर नहीं कर पाएंगे -सेवर - हम पहले से नहीं जानते हैं कि डेटा कहां भेजा जाए।
झंडे - झंडे। दरअसल, इस फंक्शन में केवल एक ही झंडा लगाया जा सकता है - FCGI_FAIL_ACCEPT_ON_INTR - FCGX_Accept_r को ब्रेक पर न बुलाएं।

उसके बाद, आपको एक नया अनुरोध प्राप्त करने की आवश्यकता है:

 int FCGX_Accept_r(FCGX_Request *request);

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

इसके बाद, आपको संभवतः पर्यावरण चर प्राप्त करने की आवश्यकता होगी, इसके लिए आप अनुरोध को स्वतंत्र रूप से संसाधित कर सकते हैं-> एनवीपी सरणी, या फ़ंक्शन का उपयोग करें

 char *FCGX_GetParam(const char *name, FCGX_ParamArray envp);

जहां नाम एक स्ट्रिंग है जिसमें पर्यावरण चर या http-हैडर का नाम है जिसका मूल्य आप प्राप्त करना चाहते हैं,
envp - पर्यावरण चर का एक सरणी जो अनुरोध में निहित है-> envp चर
फ़ंक्शन एक चर के रूप में हमारे द्वारा आवश्यक पर्यावरण चर का मान लौटाता है। सावधान पाठक को char ** और FCGX_ParamArray के बीच के बेमेल प्रकार से डरने की ज़रूरत नहीं है - इन प्रकारों को समानार्थक शब्द (typedef char ** FCGX_ParamArray) घोषित किया जाता है।
इसके अलावा, आपको संभवतः वेब सर्वर को एक प्रतिक्रिया भेजने की आवश्यकता होगी। ऐसा करने के लिए, आउटपुट स्ट्रीम और फ़ंक्शन का अनुरोध-> उपयोग करें

 int FCGX_PutStr(const char *str, int n, FCGX_Stream *stream);

जहां str एक बफर के आउटपुट के लिए डेटा युक्त होता है, बिना टर्मिनेटिंग जीरो (यानी, बफर में बाइनरी डेटा हो सकता है),
n - बाइट्स में बफर लंबाई,
स्ट्रीम - वह स्ट्रीम जिसमें हम डेटा (अनुरोध-> आउट या अनुरोध-> इरेट) को आउटपुट करना चाहते हैं।

यदि आप एक समाप्ति शून्य के साथ सी-स्ट्रिंग मानकों का उपयोग करते हैं, तो फ़ंक्शन का उपयोग करना अधिक सुविधाजनक होगा

 int FCGX_PutS(const char *str, FCGX_Stream *stream);

जो स्ट्रेल (स्ट्र) फ़ंक्शन के साथ बस स्ट्रिंग की लंबाई निर्धारित करता है और पिछले फ़ंक्शन को कॉल करता है। इसलिए, यदि आप पहले से स्ट्रिंग की लंबाई जानते हैं (उदाहरण के लिए, आप C ++ std :: string स्ट्रिंग्स का उपयोग करते हैं), तो दक्षता कारणों के लिए पिछले फ़ंक्शन का उपयोग करना बेहतर है।
मैं यह नोट करना चाहता हूं कि ये फ़ंक्शन UTF-8 स्ट्रिंग्स के साथ ठीक काम करते हैं, इसलिए बहुभाषी वेब अनुप्रयोगों के साथ कोई समस्या नहीं होनी चाहिए।
आप एक ही अनुरोध के प्रसंस्करण के दौरान कई बार इन कार्यों को भी कॉल कर सकते हैं, कुछ मामलों में यह प्रदर्शन में सुधार कर सकता है। उदाहरण के लिए, आपको कुछ बड़ी फ़ाइल भेजने की आवश्यकता है। हार्ड ड्राइव से पूरी फ़ाइल डाउनलोड करने के बजाय, और फिर इसे "एक टुकड़े में" भेजने के बजाय, आप तुरंत डेटा भेजना शुरू कर सकते हैं। नतीजतन, ब्राउज़र की सफेद स्क्रीन के बजाय क्लाइंट उसे रुचि के डेटा प्राप्त करना शुरू कर देगा, जो विशुद्ध रूप से मनोवैज्ञानिक रूप से उसे थोड़ी देर प्रतीक्षा करेगा। दूसरे शब्दों में, आप पृष्ठ को लोड करने के लिए कुछ समय प्राप्त कर रहे हैं। मैं यह भी नोट करना चाहूंगा कि अधिकांश संसाधन (कैस्केडिंग स्टाइल शीट, जावास्क्रिप्स, इत्यादि) वेब पेज की शुरुआत में इंगित किए गए हैं, अर्थात, ब्राउज़र HTML कोड के कुछ हिस्सों का विश्लेषण कर सकता है और इन संसाधनों को लोड करना शुरू कर सकता है - डेटा प्रदर्शित करने का एक और कारण भागों में।

अगली चीज़ जो आपको चाहिए वह है POST अनुरोध को संसाधित करना। इसके मूल्य प्राप्त करने के लिए, आपको फ़ंक्शन का उपयोग करके डेटा को अनुरोध-> से स्ट्रीम में पढ़ने की आवश्यकता है

 int FCGX_GetStr(char * str, int n, FCGX_Stream *stream);

जहां str एक बफर के लिए एक संकेतक है,
n बाइट्स में बफर का आकार है,
स्ट्रीम - वह स्ट्रीम जिससे हम डेटा पढ़ रहे हैं।
POST अनुरोध में प्रेषित डेटा का आकार (बाइट्स में) पर्यावरण चर CONTENT_LENGTH का उपयोग करके निर्धारित किया जा सकता है, जिसका मूल्य, जैसा कि हम याद करते हैं, FCGX_GetParam फ़ंक्शन का उपयोग करके प्राप्त किया जा सकता है। चेतावनी! बिना किसी प्रतिबंध के CONTENT_LENGTH वैरिएबल के मूल्य के आधार पर एक स्ट्रिफ़ बफर बनाना एक बहुत बुरा विचार है: कोई भी हमलावर किसी भी बड़े POST अनुरोध को भेज सकता है, और आपका सर्वर फ्री रैम से बाहर चला सकता है (यदि आप चाहें तो आपको DoS मिल जाएगा)। इसके बजाय, बफर के आकार को एक उचित मात्रा (कुछ किलोबाइट से कई मेगाबाइट तक) तक सीमित करना और FCGX_GetStr फ़ंक्शन को कई बार कॉल करना बेहतर है।

अंतिम महत्वपूर्ण फ़ंक्शन आउटपुट और एरर स्ट्रीम को फ्लैश करता है (क्लाइंट डेटा जो अभी भी नहीं भेजा गया है, जिसे हम आउटपुट और एरर स्ट्रीम में डालने में कामयाब रहे) और कनेक्शन को बंद कर देता है:

 void FCGX_Finish_r(FCGX_Request *request);

मैं इस बात पर जोर देना चाहूंगा कि यह फ़ंक्शन वैकल्पिक है: FCGX_Accept_r फ़ंक्शन क्लाइंट को डेटा भेजता है और एक नया अनुरोध प्राप्त करने से पहले वर्तमान कनेक्शन को बंद कर देता है। सवाल यह है: फिर इसकी आवश्यकता क्यों है?कल्पना करें कि आपने पहले ही क्लाइंट को सभी आवश्यक डेटा भेज दिए हैं, और अब आपको कुछ अंतिम ऑपरेशन करने की आवश्यकता है: डेटाबेस के लिए आंकड़े लिखें, लॉग फ़ाइल में त्रुटियां, आदि। जाहिर है, क्लाइंट के साथ संबंध अब आवश्यक नहीं है, लेकिन क्लाइंट (ब्राउज़र के अर्थ में) अभी भी हमसे जानकारी का इंतजार कर रहा है: अगर हम कुछ और भेजते हैं तो क्या होगा? यह स्पष्ट है कि हम समय से पहले FCGX_Accept_r को कॉल नहीं कर सकते हैं - इसके बाद हमें अगले अनुरोध को संसाधित करना शुरू करना होगा। बस इस मामले में, आपको FCGX_Finish_r फ़ंक्शन की आवश्यकता होगी - यह आपको एक नया अनुरोध प्राप्त करने से पहले वर्तमान कनेक्शन को बंद करने की अनुमति देगा। हां, हम इस फ़ंक्शन का उपयोग किए बिना प्रति यूनिट समय के समान अनुरोधों को संसाधित करने में सक्षम होंगे, लेकिन ग्राहक को पहले एक उत्तर प्राप्त होगा - उसे हमारे अंतिम संचालन के अंत तक इंतजार नहीं करना होगा,और यह ठीक है कि प्रसंस्करण अनुरोधों की अधिक गति के कारण हम FastCGI का उपयोग करते हैं।
इस पर, वास्तव में, पुस्तकालय के कार्यों का वर्णन समाप्त हो जाता है और प्राप्त आंकड़ों का प्रसंस्करण शुरू होता है।

एक बहु-थ्रेडेड FastCGI प्रोग्राम का एक सरल उदाहरण

मुझे लगता है कि उदाहरण में सब कुछ स्पष्ट हो जाएगा। केवल एक चीज यह है कि मुद्रण डिबगिंग संदेशों और वर्कफ़्लो के "सोते हुए" प्रदर्शन प्रयोजनों के लिए ही किए गए थे। प्रोग्राम को संकलित करते समय, libfcgi और libpthread लाइब्रेरी (gcc संकलक विकल्प: -lfcgi और -lpreadread) को शामिल करना सुनिश्चित करें।

 #include <pthread.h> #include <sys/types.h> #include <stdio.h> #include "fcgi_config.h" #include "fcgiapp.h" #define THREAD_COUNT 8 #define SOCKET_PATH "127.0.0.1:9000" //    static int socketId; static void *doit(void *a) { int rc, i; FCGX_Request request; char *server_name; if(FCGX_InitRequest(&request, socketId, 0) != 0) { //     printf("Can not init request\n"); return NULL; } printf("Request is inited\n"); for(;;) { static pthread_mutex_t accept_mutex = PTHREAD_MUTEX_INITIALIZER; //    printf("Try to accept new request\n"); pthread_mutex_lock(&accept_mutex); rc = FCGX_Accept_r(&request); pthread_mutex_unlock(&accept_mutex); if(rc < 0) { //    printf("Can not accept new request\n"); break; } printf("request is accepted\n"); //   server_name = FCGX_GetParam("SERVER_NAME", request.envp); //  HTTP- (    ) FCGX_PutS("Content-type: text/html\r\n", request.out); //         FCGX_PutS("\r\n", request.out); //   ( - html- -) FCGX_PutS("<html>\r\n", request.out); FCGX_PutS("<head>\r\n", request.out); FCGX_PutS("<title>FastCGI Hello! (multi-threaded C, fcgiapp library)</title>\r\n", request.out); FCGX_PutS("</head>\r\n", request.out); FCGX_PutS("<body>\r\n", request.out); FCGX_PutS("<h1>FastCGI Hello! (multi-threaded C, fcgiapp library)</h1>\r\n", request.out); FCGX_PutS("<p>Request accepted from host <i>", request.out); FCGX_PutS(server_name ? server_name : "?", request.out); FCGX_PutS("</i></p>\r\n", request.out); FCGX_PutS("</body>\r\n", request.out); FCGX_PutS("</html>\r\n", request.out); //"" -    sleep(2); //   FCGX_Finish_r(&request); //  -  ,    .. } return NULL; } int main(void) { int i; pthread_t id[THREAD_COUNT]; //  FCGX_Init(); printf("Lib is inited\n"); //   socketId = FCGX_OpenSocket(SOCKET_PATH, 20); if(socketId < 0) { //    return 1; } printf("Socket is opened\n"); //   for(i = 0; i < THREAD_COUNT; i++) { pthread_create(&id[i], NULL, doit, NULL); } //    for(i = 0; i < THREAD_COUNT; i++) { pthread_join(id[i], NULL); } return 0; }

सरल Nginx विन्यास उदाहरण

वास्तव में, एक विन्यास का सबसे सरल उदाहरण इस तरह दिखता है:

  सर्वर { 
	server_name लोकलहोस्ट; 

	 स्थान / { 
		fastcgi_pass 127.0.0.1:9000; 
		#fastcgi_pass यूनिक्स: / tmp / fastcgi / mysocket; 
		#fastcgi_pass localhost: 9000; 
		 
		fastcgi_params शामिल करें; 
	 } 
 }

इस स्थिति में, यह कॉन्फ़िगरेशन हमारे FastCGI प्रोग्राम के सही संचालन के लिए पर्याप्त है। टिप्पणी की गई लाइनें क्रमशः यूनिक्स डोमेन सॉकेट्स के साथ काम करने और आईपी पते के बजाय एक होस्ट डोमेन नाम निर्दिष्ट करने का एक उदाहरण हैं।
कार्यक्रम को संकलित करने और चलाने के बाद, और नगनेक्स को कॉन्फ़िगर करने पर, मुझे लोकलहोस्ट पर एक गर्वित शिलालेख मिला:
FastCGI नमस्कार! (मल्टी थ्रेडेड सी, fcgiapp लाइब्रेरी)

अंत में पढ़ने वाले सभी को धन्यवाद।

FastCGI का उपयोग करके C / C ++ वेब एप्लिकेशन - यह आसान है