😨 🙋🏻 🧓🏻 IIS आर्किटेक्चर मूल बातें, या ASP.NET के लिए क्वेरी प्रावधान ⚗️ ™️ 🧕🏽

पिछले साल मुझे औसत योग्यता के ASP.NET पर वेब प्रोग्रामर के पद के लिए लगभग 10-15 उम्मीदवारों का साक्षात्कार करना था। एक "बैकफ़िल" या "एक तारांकन के साथ" सवालों के रूप में, मैंने आपको यह बताने के लिए कहा कि उस समय से HTTP अनुरोध के साथ क्या होता है जो सर्वर के 80 वें पोर्ट पर पहुंचता है, जो कि aspx पेज कोड पर नियंत्रण स्थानांतरित करता है। आंकड़े निराशाजनक थे: कोई भी उम्मीदवार समझदारी से कुछ भी देने में सक्षम नहीं था। और इसकी अपनी व्याख्या है: न तो MSDN में तकनीकी के साथ, न ही विशेष संसाधन iis.net पर, न ही इन-ला पुस्तकों में "ASP.NET पेशेवरों के लिए", और न ही ब्लॉग्स में, इस विषय पर उचित ध्यान दिया गया है - जानकारी लगभग एकत्र की जानी है बिट द्वारा। मैं ऐसे लोगों को भी जानता हूं, जिन्होंने अपना वेब सर्वर (इगोर, जॉर्ज, हाय!) लिखने का फैसला किया, ताकि आईआईएस के काम को नहीं समझा जा सके। एकमात्र समझदार लेख रीगन टैंपलिन द्वारा " IIS आर्किटेक्चर का परिचय " है। लेकिन वह भी asnets के हितों की परिधि पर बनी हुई है।

हालाँकि, मैं व्यक्तिगत रूप से विशुद्ध रूप से तकनीकी मुद्दों में दिलचस्पी नहीं रखता, लेकिन मैंने अपने संचित अनुभव को एक साथ रखने का फैसला किया, वेब पर दिलचस्प विवरण खोदें और इस पवित्र ज्ञान को जन-जन तक पहुंचाने से पहले इसे अप्रचलित हो गया। मुझे तुरंत यह कहना होगा कि लेख IIS 7.x पर अधिक केंद्रित है, कभी-कभी 6-कू के बारे में शाखाएं होंगी। मैं काम में 8 वें संस्करण में नहीं आया था, इसलिए मैंने इस लेख में इसके चारों ओर जाने का फैसला किया। लेकिन, मुझे यकीन है कि पाठक नीचे प्रस्तुत सामग्री में आसानी से महारत हासिल कर लेंगे।

1. सामान्य योजना
2. बंद हुआ
2.1। http.sys
2.2। वर्ल्ड वाइड वेब पब्लिशिंग सर्विस (W3SVC)
2.3। Windows प्रक्रिया सक्रियण सेवा (WAS)
2.4। अनुप्रयोग पूल
2.5। अनुप्रयोग डोमेन, अनुप्रयोग
3. आगे क्या?
सूत्रों का कहना है

1. सामान्य योजना

तो, चलो अंत से शुरू करते हैं, और फिर व्यक्तिगत पहलुओं पर थोड़ा और बारीकी से विचार करते हैं।
अंग्रेजी साहित्य में, IIS में अनुरोध प्रसंस्करण पाइपलाइन को "अनुरोध प्रसंस्करण पाइपलाइन" कहा जाता है - "अनुरोध प्रसंस्करण पाइपलाइन" जैसी कुछ। सामान्य शब्दों में, इसे http अनुरोध के लिए नीचे दिए गए चित्र में प्रस्तुत किया गया है।

अंजीर। 1. HTTP अनुरोध प्रसंस्करण पाइपलाइन (IIS 7.x)।

इस प्रकार, http अनुरोध पाइपलाइन के असेंबली लाइन से होकर गुजरता है:

1. ब्राउज़र एक विशिष्ट URL पर वेब सर्वर तक पहुंचता है, सर्वर साइड पर अनुरोध HTTP.SYS ड्राइवर को स्वीकार करता है ।
2. HTTP.SYS कॉन्फ़िगरेशन रिपॉजिटरी से जानकारी प्राप्त करने के लिए WAS पर दस्तक दे रहा है।
3. WAS भंडारण से कॉन्फ़िगरेशन का अनुरोध करता है - IIS फ़ोल्डर में एक फ़ाइल (ApplicationHost.config) से।
4. चूंकि यह अनुरोध HTTP के माध्यम से प्राप्त किया गया था, W3SVC सेवा कॉन्फ़िगरेशन जानकारी प्राप्त करता है (यह तस्वीर में WWW सेवा भी है), इस जानकारी में एप्लिकेशन पूल और अन्य साइट मापदंडों के बारे में डेटा है।
5. W3SVC सेवा HTTP.SYS को कॉन्फ़िगर करने के लिए इस जानकारी का उपयोग करती है ।
6. WAS सेवा अनुप्रयोग पूल के लिए W3WP.exe प्रक्रिया शुरू करती है अगर यह पहले से शुरू नहीं हुई है।
7. W3WP.exe प्रक्रिया में, एक वेबसाइट एप्लिकेशन चल रहा है, जो वास्तव में, HTTP.YS चालक की प्रतिक्रिया देता है और उत्पन्न करता है।
8. HTTP.SYS ब्राउज़र को प्रतिक्रिया भेजता है।

सिद्धांत रूप में, यह योजना पहले से ही अधिकांश कंपनियों में साक्षात्कार से गुजरने और आईआईएस वास्तुकला का एक सामान्य विचार प्राप्त करने के लिए पर्याप्त है। लेकिन अगर आप टिक के लिए यहां नहीं आए हैं, तो कृपया आगे का पालन करें।

2. बंद हुआ

अब हम उल्लिखित घटकों में से प्रत्येक पर अधिक विस्तार से ध्यान दें।

2.1। http.sys

परिवहन स्तर पर, IIS प्रोटोकॉल श्रोताओं का उपयोग करता है, जो टीसीपी / आईपी स्टैक के शीर्ष पर स्थित हैं। हमारे लिए सबसे दिलचस्प घटक HTTP.sys सिस्टम ड्राइवर है, जो ओएस कर्नेल में एकीकृत है और HTTP और HTTPS प्रोटोकॉल के साथ काम करता है, जो उन सभी बंदरगाहों पर सुनने के लिए स्वतंत्र रूप से पंजीकृत है जो IIS में साइटों के लिए अनुरोध प्राप्त करेंगे।

HTTP.sys बिल्ट-इन कर्नेल IIS 6 में एक नवाचार बन गया, जो Windows सॉकेट API की जगह ले रहा है, जो IIS और HTTPS अनुरोधों को आईआईएस के पूर्व संस्करणों में उपयोगकर्ता स्तर पर इंटरसेप्ट करने के लिए एक घटक है। संभवतः, कर्नेल में ड्राइवर का एकीकरण बहुत ही कारण है कि IIS संस्करण कसकर विंडोज संस्करण से बंधा हुआ है।

ड्राइवर सभी आने वाले अनुरोधों को स्वीकार करता है और उन्हें वांछित एप्लिकेशन पूल में पुनर्निर्देशित करता है। यदि किसी कारण से वर्कफ़्लो जिसमें आवश्यक पूल की मेजबानी की जाती है, तो रोक दिया जाता है (विफलता, निष्क्रिय समय समाप्ति, कॉन्फ़िगरेशन परिवर्तन, आदि) या अभी भी शुरू हो रहा है, तो HTTP.sys प्रत्येक पूल के लिए विशेष रूप से आवंटित कतार में आने वाले अनुरोधों को बचाता है। इस प्रकार, उपयोगकर्ता अनुरोध कहीं भी गायब नहीं होते हैं, और वे आमतौर पर IIS चलाने वाली साइटों के काम में किसी भी रुकावट को नोटिस नहीं करते हैं।

इसके अलावा, HTTP.sys प्रतिक्रियाओं को कैश कर सकता है (और अधिक विस्तार में, जिसमें HTTP.sys कैश सामग्री नहीं देता है ), इसलिए कुछ अनुरोधों को आवेदन स्तर पर पारित किए बिना संसाधित किया जाता है, और यह अनुरोध URI को पार्स करता है और इसे RFC 2396 (कुछ के अनुसार मान्य करता है) -यहाँ से चमकाया जा सकता है - विशेष पात्रों जैसे '%' '' और ':' का उपयोग IIS URL में ) और अनुरोध / प्रतिक्रिया लॉगिंग।

कुछ HTTP.sys सेटिंग्स विंडोज रजिस्ट्री में बनाई जाती हैं (अधिक विस्तार से, विंडोज के लिए Http.sys रजिस्ट्री सेटिंग्स )। वैसे, उसी स्थान पर - रजिस्ट्री में - आप हमारे नागरिक पंजीकरण के सामान्य स्थान पर देख सकते हैं:% SystemRoot% \ system32 \ driver \ http.sys।

सच कहूँ तो, इस लेख को लिखने की प्रक्रिया में, मैंने अपने लिए कुछ विवरणों की खोज की। उदाहरण के लिए, HTTP.sys ड्राइवर के स्तर पर कैशिंग प्रतिक्रियाएँ। इससे मुझे एक अजीब के एक मामले की व्याख्या करने में मदद मिली, जैसा कि मुझे तब लगा, आईआईएस के व्यवहार में घटना। मार्केटर्स ने अगली छुट्टी से पहले साइट पर एक swf कार्ड पोस्ट किया, लेकिन फिर उन्हें फ़ाइल नाम में कुछ पसंद नहीं आया और उन्होंने इसका नाम बदल दिया। हालाँकि, साइट पुराने URL पर एक पोस्टकार्ड जारी करती रही, और यहां तक कि ब्राउज़र कैश को साफ़ करने से भी मदद नहीं मिली। मैं पहले से ही यहां से जुड़ा हुआ हूं, लेकिन न तो वेबसाइट और पूरे एप्लिकेशन पूल को फिर से शुरू करना, न ही कॉर्पोरेट प्रॉक्सी सर्वर को दरकिनार कर साइट तक पहुंचना अपेक्षित परिणाम देता है। लेकिन अब हम जानते हैं कि किसे दोष देना है।

2.2। वर्ल्ड वाइड वेब पब्लिशिंग सर्विस (W3SVC)

यह सेवा IIS 6 में HTTP / HTTPS प्रोटोकॉल के साथ काम करने और अनुप्रयोग वर्कफ़्लोज़ के प्रबंधन के लिए एक अलग घटक के रूप में प्रस्तुत की गई थी और निम्नलिखित कार्य किए गए थे:

HTTP.sys ड्राइवर प्रशासन।
वर्कफ़्लो प्रबंधन।
वेबसाइट प्रदर्शन मेट्रिक्स की निगरानी करना।

यह सेवा Svchost.exe प्रक्रिया के संदर्भ में विंडोज सर्वर 2003 में काम करती है (सेटिंग्स को HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ W3Svc रजिस्ट्री में देखा जा सकता है), अन्य सभी IIS के विपरीत, जिन्हें Inetinfo.exe प्रक्रिया के संदर्भ में निष्पादित किया जाता है, इसे Iisw3adm में लागू किया जाता है। .dll।

IIS 7.x में, आर्किटेक्चर को सार्वभौमिक बनाने के लिए प्रक्रिया नियंत्रण फ़ंक्शन को एक अलग सेवा में स्थानांतरित किया गया था - WAS (क्लॉज 2.3 देखें)। अब WWW सेवा HTTP / HTTPS प्रोटोकॉल में विशेषज्ञता प्राप्त एडेप्टर में से एक बन गई है - HTTP.sys ड्राइवर के शीर्ष पर काम करना। हालांकि, डब्ल्यूडब्ल्यूडब्ल्यू सेवा आईआईएस की आधारशिला घटक बनी हुई है, इसलिए इसका कॉन्फ़िगरेशन एडेप्टर के कॉन्फ़िगरेशन से अन्य प्रोटोकॉल (यहां थोड़ा अधिक समान है) से अलग है; यह WAS के समान वर्कफ़्लो में कार्य करता है, और इसे उसी लाइब्रेरी (चित्र 2) में लागू किया जाता है।

अंजीर। २। W3SVC और WAS के साथ वर्कफ़्लो।

चूँकि हम प्रोटोकॉल श्रोताओं (प्रोटोकॉल श्रोता adpater) के लिए एडेप्टर के बारे में बात कर रहे हैं, चलो बस थोड़ा सा लिंटर करें और देखें कि वे क्या हैं। सिद्धांत रूप में, IIS 7.x को मानक HTTP और FTP के अलावा किसी भी प्रोटोकॉल का उपयोग करते हुए अनुरोधों को संसाधित करने के लिए कॉन्फ़िगर किया जा सकता है, उदाहरण के लिए, POP3, SMTP, गोफर। आप अपनी वेब या डब्ल्यूसीएफ सेवा के लिए अपने स्वयं के प्रोटोकॉल के साथ आने के लिए स्वतंत्र हैं और इसके लिए सभी आवश्यक घटकों को लागू करते हैं, अगर आपको अपने समय के लिए खेद नहीं है। सबसे अधिक संभावना है, सबसे आम प्रोटोकॉल के लिए एडेप्टर और श्रोता मुफ्त और व्यावसायिक डाउनलोड के लिए उपलब्ध हैं - मैंने इसका परीक्षण नहीं किया है। लेकिन सबसे पहले, आपको मानक सेवाओं (छवि 3) पर ध्यान देना चाहिए, जो .NET फ्रेमवर्क के साथ आपूर्ति की जाती हैं और IIS के साथ एकीकृत होती हैं:

टीसीपी के लिए नेटटेकपिटिवेटर;
नामित पाइपों के लिए नेटपाइपएक्टिवेटर;
संदेश कतार के लिए NetMsmqActivator (उर्फ MSMQ)।

अंजीर। 3. विंडोज सेवा स्नैप-इन में मानक गैर-HTTP एडेप्टर की एक सूची।

लेकिन फिर भी, हमारे लिए सबसे महत्वपूर्ण एडॉप्टर WWW सेवा, incl है। आइए हम IIS 6 से शेष दो कार्यों पर थोड़ा और ध्यान दें।

HTTP (एस) का प्रशासन और विन्यास। वेबसाइटों के कॉन्फ़िगरेशन को अपडेट करने के समय, डब्ल्यूएएस सेवा इस जानकारी को डब्ल्यूडब्ल्यूडब्ल्यू सेवा को पास करती है, और यह बदले में, HTTP.sys को विशिष्ट बंदरगाहों पर सुनने के लिए कॉन्फ़िगर करती है, आईपी और हेडर को अनुरोधित साइट और अन्य संभावित मापदंडों को पार्स करती है। विपरीत दिशा में, W3SVC WAS को संदर्भित करता है जब कोई नया HTTP.sys में अनुरोध कतार में आता है, इस अनुरोध को संसाधित करने वाले वर्कफ़्लो को प्राप्त करने के लिए।

ट्रैक प्रदर्शन मैट्रिक्स। WWW सेवा इस उद्देश्य के लिए HTTP.sys ड्राइवर का उपयोग करके प्रदर्शन काउंटरों को बनाए रखती है और वेबसाइटों और IIS कैश को अपनी मैट्रिक्स प्रदान करती है। मुझे इस मुद्दे पर अधिक विस्तृत जानकारी नहीं मिली।

2.3। Windows प्रक्रिया सक्रियण सेवा (WAS)

इसलिए, IIS 6 में WWW सेवा, जैसे IIS 6 में, HTTP.sys को प्रबंधित करने और वेबसाइट के प्रदर्शन मेट्रिक्स को प्रबंधित करने के कार्यों को जारी रखती है। लेकिन वर्कफ़्लो के प्रबंधन का कार्य एक अलग सेवा - WAS में स्थानांतरित कर दिया गया है। इसे सिस्टम द्वारा एक ही कॉपी में लॉन्च किया जाता है, फाइल से फाइल को पढ़ता है SystemRoot% \ System32 \ inetsrv \ config \ ApplicationHost.config और संबंधित श्रोताओं के माध्यम से प्रोटोकॉल श्रोताओं को उसमें निर्दिष्ट सूचनाओं के अनुसार कॉन्फ़िगर करता है। HTTP / HTTPS प्रोटोकॉल के लिए याद रखें कि एडॉप्टर W3SVC सेवा है, और श्रोता HTTP.sys ड्राइवर है। जब कोई श्रोता अपने एडाप्टर के माध्यम से एक अनुरोध स्वीकार करता है, तो वह एप्लिकेशन वर्कफ़्लो प्राप्त करने के लिए WAS सेवा को कॉल करता है, जिसके लिए अनुरोध को संसाधित किया जाएगा और क्लाइंट को एक प्रतिक्रिया उत्पन्न होगी।

उपयोगकर्ता अनुरोध को संसाधित करने के लिए आवश्यक एप्लिकेशन को सक्रिय करते समय, निम्नलिखित घटक शामिल होते हैं:

श्रोता एडेप्टर विशेष विंडोज सेवाएं हैं जो एक विशिष्ट प्रोटोकॉल के साथ काम करती हैं और सही वर्कफ़्लो के लिए सीधे अनुरोधों के लिए डब्ल्यूएएस के साथ बातचीत करती हैं।
वास्तव में डब्ल्यू.ए.एस. वह कार्य प्रक्रियाओं को बनाने और उनके जीवनकाल के प्रबंधन के लिए जिम्मेदार है।
W3wp.exe निष्पादन योग्य फ़ाइल एक वर्कफ़्लो टेम्पलेट है।
एप्लिकेशन प्रबंधक वर्कफ़्लो के भीतर होस्ट किए गए एप्लिकेशन डोमेन के निर्माण और उपयोग का प्रबंधन करता है।
प्रोटोकॉल हैंडलर एक वर्कफ़्लो के भीतर प्रोटोकॉल-निर्भर घटक होते हैं जो किसी विशेष एडाप्टर और वर्कफ़्लो के बीच डेटा के आदान-प्रदान के लिए जिम्मेदार होते हैं। प्रोटोकॉल हैंडलर 2 प्रकार के होते हैं: प्रक्रिया (प्रोसेस प्रोटोकॉल हैंडलर - पीपीएच) और एप्लिकेशन डोमेन (AppDomain प्रोटोकॉल हैंडलर - ADPH)।

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

अंजीर। बाहरी घटकों के साथ बातचीत के लिए 4. घटक w3wp.exe।

जैसा कि ऊपर उल्लेख किया गया है, .NET फ्रेमवर्क HTTP / HTTPS प्रोटोकॉल (हमारे पसंदीदा ASP.NET), net.tcp, net.pipe और MSMQ के लिए घटकों का कार्यान्वयन करता है। HTTP / HTTPS और FTP प्रोटोकॉल स्टैक अभी भी IIS और OS में अधिक निकटता से एकीकृत हैं, इसलिए नए प्रोटोकॉल के लिए सेटिंग्स कम लोकप्रिय Donnet प्रोटोकॉल का उपयोग करके सबसे अच्छा प्रदर्शन किया जाता है। इसलिए, ढांचा स्थापित करने के बाद, निम्नलिखित प्रविष्टियां IIS ApplicationHost.config कॉन्फ़िगरेशन फ़ाइल में दिखाई देती हैं:

<system.applicationHost> <listenerAdapters> <add name="http" /> <add name="net.tcp" identity="S-1-5-80-3579033775-2824656752-1522793541-1960352512-462907086" /> <add name="net.pipe" identity="S-1-5-80-2943419899-937267781-4189664001-1229628381-3982115073" /> <add name="net.msmq" identity="S-1-5-80-89244771-1762554971-1007993102-348796144-2203111529" /> <add name="msmq.formatname" identity="S-1-5-80-89244771-1762554971-1007993102-348796144-2203111529" /> </listenerAdapters> </system.applicationHost>

और इसी PPH और ADPH घटक को डोनेट मशीन में कॉन्फ़िगर किया गया है ।config:

 <system.web> <protocols> <add name="net.tcp" processHandlerType="System.ServiceModel.WasHosting.TcpProcessProtocolHandler" appDomainHandlerType="System.ServiceModel.WasHosting.TcpAppDomainProtocolHandler" validate="false" /> <add name="net.pipe" processHandlerType="System.ServiceModel.WasHosting.NamedPipeProcessProtocolHandler" appDomainHandlerType="System.ServiceModel.WasHosting.NamedPipeAppDomainProtocolHandler”/> <add name="net.msmq" processHandlerType="System.ServiceModel.WasHosting.MsmqProcessProtocolHandler" appDomainHandlerType="System.ServiceModel.WasHosting.MsmqAppDomainProtocolHandler" validate="false" /> </protocols> </system.web>

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

  <bindings> <binding protocol="http" bindingInformation="109.120.157.xxx:80:dddddd.info" /> <binding protocol="http" bindingInformation="109.120.157.xxx:80:www.ddddd.info" /> </bindings>

कृपया ध्यान दें कि मानक IIS ऑपरेशन मोड में, WAS सेवा, प्रत्येक प्रोटोकॉल श्रोता के लिए एडेप्टर सेवा (W3SVC सहित) और प्रत्येक प्रोटोकॉल के चालक / श्रोता (HTTP.sys सहित) स्वयं OS में एकल में चल रहे हैं कॉपी। लेकिन अलग-अलग अनुरोध अलग-अलग वर्कफ़्लोज़ में अलग-अलग एप्लिकेशन को भेजे जा सकते हैं। दूसरी ओर, अलग-अलग प्रोटोकॉल के लिए अनुरोधों को संबंधित एडेप्टर के माध्यम से एक विशेष एप्लिकेशन में भेजा जा सकता है। जाहिरा तौर पर, इस व्यवहार के सही कार्यान्वयन के लिए, प्रोटोकॉल ड्राइवर का आर्किटेक्चरल कनेक्शन - प्रोटोकॉल ड्राइवर एडॉप्टर - सक्रियण सेवा (एक प्रकार का नियामक, या बल्कि, राउटर) - एक वर्कफ़्लो था।

2.4। अनुप्रयोग पूल

एक वेब एप्लिकेशन को कॉन्फ़िगर करते समय, मापदंडों और अन्य सेटिंग्स का अनुरोध करने के लिए बाध्यकारी के अलावा, एप्लिकेशन पूल में सदस्यता का संकेत दिया जाता है। अनुप्रयोग पूल IIS 6 में एक नवाचार था और इसे वेब अनुप्रयोगों को एक-दूसरे से अलग करने के लिए डिज़ाइन किया गया था और इस तरह संपूर्ण रूप से वेब सर्वर की स्थिरता में वृद्धि हुई थी। लब्बोलुआब यह है कि एप्लिकेशन कोड एक विशेष विंडोज प्रक्रिया के अंदर चलता है - w3wp.exe। इसलिए, एक वेब एप्लिकेशन के अंदर एक अपवाद केवल इस प्रक्रिया को क्रैश करेगा और अन्य पूल में वेब एप्लिकेशन की उपलब्धता और IIS के संचालन को प्रभावित नहीं करेगा। इसके अलावा, WAS सेवा गिर साइट को पुनः आरंभ करने का प्रयास करेगी, और बाहरी क्लाइंट को सर्वर में समस्याएँ भी नहीं दिखेंगी।

एकल w3wp.exe वर्कफ़्लो के कुछ मापदंडों को प्रबंधित करने के लिए, IIS एक एप्लिकेशन पूल का उपयोग करता है। सबसे अधिक उपयोग किए जाने वाले खाते हैं जिसके तहत प्रक्रिया शुरू की जाएगी, अनुरोध कतार पर प्रतिबंध, विभिन्न टाइमर और काउंटर स्वचालित रूप से प्रक्रिया को फिर से शुरू करने के लिए, x86 / x64 आर्किटेक्चर (IIS 7.x में) और कुछ अन्य (छवि। 5,)। एक उत्सुक पाठक आसानी से MSDN और अपने पसंदीदा खोज इंजन पर पढ़ सकता है। इस प्रकार आप w3wp.exe प्रक्रिया और एप्लिकेशन पूल की पहचान के बारे में (कुछ आरक्षण के साथ, 2.5 में अंतिम पैराग्राफ भी) बात कर सकते हैं।

अंजीर। 5 उन्नत अनुप्रयोग पूल सेटिंग्स

IIS 7.x में एप्लिकेशन पूल की अवधारणा में एक महत्वपूर्ण नवाचार एक नया पैरामीटर था - एक कंटेनर प्रबंधन मॉडल जो 2 मान ले सकता है: क्लासिक (क्लासिक मोड) और एम्बेडेड मॉडल (एकीकृत मोड)।
ऑपरेशन के इन तरीकों के बीच अंतर को समझाने के लिए, आपको IIS 6 / 7.x में "मॉड्यूल" की अवधारणा और IIS + ASP.NET में इवेंट-संचालित अनुरोध प्रसंस्करण मॉडल से परिचित होना होगा। यह विषय एक अलग लेख के योग्य है, लेकिन अफसोस, मेरे पास पहले से ही इसके लिए पर्याप्त नहीं है, जाहिरा तौर पर। यहां मैं आपके ध्यान में केवल सामान्य, मुख्य बिंदुओं को लाऊंगा।

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

अंजीर। 6. IIS में मॉड्यूल की विचारधारा।

क्लासिक कंटेनर प्रबंधन मॉडल IIS 6 में वर्कफ़्लो आइसोलेशन मोड के साथ बैकवर्ड संगतता प्रदान करता है - ASP.NET साइट के अनुरोधों को पहले देशी मॉड्यूल के माध्यम से पारित किया जाता है और फिर एक प्रबंधित वातावरण में मॉड्यूल द्वारा प्रसंस्करण के लिए Aspnet_isapi.dll में स्थानांतरित किया जाता है। IIS और ASP.NET के बीच यह पृथक्करण कुछ कार्यों के दोहराव की ओर जाता है, जैसे प्रमाणीकरण और प्राधिकरण। और आपके पास मूल मॉड्यूल के व्यवहार को प्रोग्रामेटिक रूप से नियंत्रित करने की क्षमता नहीं है (एक उदाहरण, हालांकि सबसे ज्यादा जलने वाला नहीं है, लेकिन फिर भी - इस लेख में अनुभाग "हम सर्वर हेडर को हटा देते हैं")।

एम्बेडेड मॉडल IIS और ASP.NET के बीच घनिष्ठ सहभागिता मानता है। ऐसी प्रसंस्करण वास्तुकला में एक अनुरोध घटनाओं के एक स्थापित अनुक्रम के माध्यम से पारित किया जाता है, जिनमें से प्रत्येक में एक अनुरोध देशी और प्रबंधित मॉड्यूल के माध्यम से पारित किया जाता है। इस मोड में, IIS और ASP.NET अनुरोध प्रसंस्करण मॉडल को एक एकल मॉडल में संयोजित किया जाता है, जो कार्यों के दोहराव से बचने और अनुरोध प्रसंस्करण के लिए अधिक नियंत्रण प्राप्त करने में मदद करता है।

व्यवहार में, वेब अनुप्रयोगों को विकसित और तैनात करते समय विचार करने के लिए सबसे महत्वपूर्ण बात इन दो मोडों की आंशिक असंगति है। यानी किसी साइट का अनुवाद करते समय (अधिक सटीक रूप से, एप्लिकेशन पूल जिसमें साइट संचालित होती है) शास्त्रीय मॉडल से एम्बेडेड मॉडल, कोड समायोजन (हालांकि शायद महत्वपूर्ण नहीं), साथ ही कठोर परीक्षण, लगभग हमेशा आवश्यक होंगे।

2.5। अनुप्रयोग डोमेन, अनुप्रयोग

वेब एप्लिकेशन के प्रत्यक्ष कंटेनर एप्लिकेशन और एप्लिकेशन डोमेन (एप्लिकेशन डोमेन, AppDomain) हैं। अक्सर इन दो अवधारणाओं की पहचान की जाती है, लेकिन फिर भी ये कुछ अलग चीजें हैं। एक अनुप्रयोग एक IIS अवधारणा है, और एक अनुप्रयोग डोमेन ASP.NET से है। इसके अलावा, सामान्य स्थिति में, एक एप्लिकेशन में कई डोमेन हो सकते हैं। आप IIS कंसोल से एप्लिकेशन को प्रबंधित कर सकते हैं, और एप्लिकेशन डोमेन ज्यादातर प्रोग्रामेटिक रूप से है। इसलिए, उदाहरण के लिए, एप्लिकेशन कंसोल से पुनरारंभ होता है। और जब हम web.config को फिर से सहेजते हैं, तो यह एप्लिकेशन डोमेन है जिसे IIS एप्लिकेशन को छूने के बिना रिबूट किया जाता है।

व्यावहारिक दृष्टिकोण से अधिक महत्वपूर्ण, एप्लिकेशन / एप्लिकेशन डोमेन आपके ASP.NET साइट के कोड के लिए सैंडबॉक्स है (पूल के मामले में इस तरह के विश्वसनीय अलगाव के साथ नहीं, लेकिन फिर भी)। मैं आपको मेरा एक पसंदीदा प्रश्न देता हूँ जो मैंने आवेदकों से साक्षात्कार के लिए पूछा था। वेबसाइट -1 और वेबसाइट -2 के साथ-साथ कुछ लाइब्रेरी MyLib.dll भी होने दें, जिसमें स्थिर क्षेत्र Field1 के साथ वर्ग MyClass1 को परिभाषित किया गया है। तो, दोनों साइटें एक ही एप्लिकेशन पूल चला रही हैं और एक ही लाइब्रेरी MyLib.dll का उपयोग करती हैं। वेबसाइट -1 MyClass1.Field1 = 16 (चित्र 7) को लिखती है। प्रश्न: क्या वेबसाइट 2 में किए गए बदलावों को देखेंगे? जवाब है नहीं। लेकिन क्यों? क्योंकि, IIS अनुप्रयोगों के लिए, असम्बद्ध पते स्थान आवंटित किए जाते हैं, भले ही वे एक ही वर्कफ़्लो के अंदर काम करते हों, इसलिए, असेंबली की प्रतियां वेब एप्लिकेशन मेमोरी में लोड की जाती हैं (कृपया .NET फ्रेमवर्क में मेमोरी के साथ काम करने के मामले में संभव अशुद्धियों के साथ गलती नहीं पाते हैं)।

अंजीर। 7. पहेली के लिए चित्र।

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

3. आगे क्या?

इसके बाद, आपको मॉड्यूल (IIS शब्दों में) और ईवेंट मॉडल के संचालन को समझने की आवश्यकता है, जिसमें अनुरोध प्रसंस्करण पहले से ही हो रहा है, जैसा कि अनुभाग 2.4 में उल्लेख किया गया है। आम तौर पर बोलते हुए, यह विषय एक अलग लेख के योग्य है, जो, मुझे डर है, मेरे लिए पर्याप्त नहीं होगा। लेकिन इसके बिना, यह नहीं कहा जा सकता है कि हमने प्रसंस्करण अनुरोधों के लिए पूरी पाइपलाइन की जांच की। इसलिए, हम संक्षेप में यहाँ मुख्य बिंदुओं पर जाते हैं कि एक जिज्ञासु पाठक अपने दम पर काम कर सकता है।

जैसा कि ऊपर 2.4 खंड में उल्लेख किया गया है, IIS मॉड्यूल वर्कफ़्लो के भीतर समाहित हैं। एक अनुरोध उनके माध्यम से क्रमिक रूप से (HttpHandlers के विपरीत) पारित किया जाता है। उनका सेट और ऑर्डर सर्वर और / या एक विशिष्ट वेब एप्लिकेशन के कॉन्फ़िगरेशन से निर्धारित होता है। मॉड्यूल अलग-अलग, संकीर्ण रूप से केंद्रित कार्यों के लिए डिज़ाइन किए गए हैं, जैसे कि प्राधिकरण, कैशिंग, कस्टम लॉगिंग, संपीड़न, स्थिर सामग्री वापस करना, और निश्चित रूप से, किसी दिए गए URL पर HTML पृष्ठ उत्पन्न करना।

जैसा कि हम पहले से ही जानते हैं, IIS में 2 प्रकार के मॉड्यूल होते हैं: देशी और प्रबंधित। आप MSDN में या रेगन टेम्पलिन लेख में मॉड्यूल की सटीक सूची पा सकते हैं। आप हमेशा अपने मॉड्यूल को लिख सकते हैं, उदाहरण के लिए, रीडायरेक्ट के लिए। ज्यादातर, ज़ाहिर है, वे प्रबंधित मॉड्यूल करते हैं, क्योंकि उन्हें लागू करना सबसे आसान है। वैसे, ASP.NET WebForms और MVC ऐसे प्रबंधित मॉड्यूल के रूप में काम करते हैं। सहित मेरे पास व्यक्तिगत रूप से होलीवारा WebForms बनाम है। एमवीसी एक मुस्कुराहट और ट्रोल के लिए एक कठिन स्वभाव की इच्छा का कारण बनता है। IIS और ASP.NET के सिद्धांतों को जानने के बाद, आप स्वयं अपने पसंद के किसी भी पैटर्न को लागू कर पाएंगे।

अगले स्तर के विचार में, हम ASP.NET घटकों जैसे HttpHandlers और पृष्ठ प्रसंस्करण घटनाओं का सामना करेंगे। इस बारे में बहुत सारे लेख लिखे गए हैं। मुझे इस पर लगाम लगाने का कोई कारण नहीं दिखता है। केवल एक चीज मैं खुद को उन लोगों को सलाह देने की अनुमति देता हूं जो बैठक से पहले खोज इंजन "ASP.NET पृष्ठ जीवनचक्र" में स्कोर करने के लिए जाते हैं - यह, निश्चित रूप से, मेरे लिए गहरी समझ में उन विशेषज्ञों के लिए शर्मनाक है जो खुद को ASP.NET पर डेवलपर्स मानते हैं।

ApplicationHost.config में देशी मॉड्यूल की डिफ़ॉल्ट सेटिंग्स का एक उदाहरण

 <system.webServer> <globalModules> <add name="UriCacheModule" image="%windir%\System32\inetsrv\cachuri.dll" /> <add name="FileCacheModule" image="%windir%\System32\inetsrv\cachfile.dll" /> <add name="TokenCacheModule" image="%windir%\System32\inetsrv\cachtokn.dll" /> <add name="HttpCacheModule" image="%windir%\System32\inetsrv\cachhttp.dll" /> <add name="StaticCompressionModule" image="%windir%\System32\inetsrv\compstat.dll" /> <add name="DefaultDocumentModule" image="%windir%\System32\inetsrv\defdoc.dll" /> <add name="DirectoryListingModule" image="%windir%\System32\inetsrv\dirlist.dll" /> <add name="ProtocolSupportModule" image="%windir%\System32\inetsrv\protsup.dll" /> <add name="HttpRedirectionModule" image="%windir%\System32\inetsrv\redirect.dll" /> <add name="ServerSideIncludeModule" image="%windir%\System32\inetsrv\iis_ssi.dll" /> <add name="StaticFileModule" image="%windir%\System32\inetsrv\static.dll" /> <add name="AnonymousAuthenticationModule" image="%windir%\System32\inetsrv\authanon.dll" /> <add name="CertificateMappingAuthenticationModule" image="%windir%\System32\inetsrv\authcert.dll" /> <add name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" /> <add name="BasicAuthenticationModule" image="%windir%\System32\inetsrv\authbas.dll" /> <add name="WindowsAuthenticationModule" image="%windir%\System32\inetsrv\authsspi.dll" /> <add name="DigestAuthenticationModule" image="%windir%\System32\inetsrv\authmd5.dll" /> <add name="IISCertificateMappingAuthenticationModule" image="%windir%\System32\inetsrv\authmap.dll" /> <add name="IpRestrictionModule" image="%windir%\System32\inetsrv\iprestr.dll" /> <add name="RequestFilteringModule" image="%windir%\System32\inetsrv\modrqflt.dll" /> <add name="CustomLoggingModule" image="%windir%\System32\inetsrv\logcust.dll" /> <add name="CustomErrorModule" image="%windir%\System32\inetsrv\custerr.dll" /> <add name="HttpLoggingModule" image="%windir%\System32\inetsrv\loghttp.dll" /> <add name="TracingModule" image="%windir%\System32\inetsrv\iisetw.dll" /> <add name="FailedRequestsTracingModule" image="%windir%\System32\inetsrv\iisfreb.dll" /> <add name="RequestMonitorModule" image="%windir%\System32\inetsrv\iisreqs.dll" /> <add name="IsapiModule" image="%windir%\System32\inetsrv\isapi.dll" /> <add name="IsapiFilterModule" image="%windir%\System32\inetsrv\filter.dll" /> <add name="ConfigurationValidationModule" image="%windir%\System32\inetsrv\validcfg.dll" /> <add name="ManagedEngine64" image="%windir%\Microsoft.NET\Framework64\v2.0.50727\webengine.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness64" /> <add name="ManagedEngine" image="%windir%\Microsoft.NET\Framework\v2.0.50727\webengine.dll" preCondition="integratedMode,runtimeVersionv2.0,bitness32" /> <add name="ManagedEngineV4.0_32bit" image="c:\Windows\Microsoft.NET\Framework\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness32" /> <add name="ManagedEngineV4.0_64bit" image="c:\Windows\Microsoft.NET\Framework64\v4.0.30319\webengine4.dll" preCondition="integratedMode,runtimeVersionv4.0,bitness64" /> </globalModules> </system.webServer>

ApplicationHost.config में प्रबंधित मॉड्यूल की डिफ़ॉल्ट सेटिंग्स का उदाहरण

 <system.webServer> <modules> *** <add name="OutputCache" type="System.Web.Caching.OutputCacheModule" preCondition="managedHandler" /> <add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="managedHandler" /> <add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" preCondition="managedHandler" /> <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" /> <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" /> <add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" /> <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" /> <add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule" preCondition="managedHandler" /> <add name="AnonymousIdentification" type="System.Web.Security.AnonymousIdentificationModule" preCondition="managedHandler" /> <add name="Profile" type="System.Web.Profile.ProfileModule" preCondition="managedHandler" /> <add name="UrlMappingsModule" type="System.Web.UrlMappingsModule" preCondition="managedHandler" /> <add name="ServiceModel-4.0" type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler,runtimeVersionv4.0" /> <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="managedHandler,runtimeVersionv4.0" /> <add name="ScriptModule-4.0" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler,runtimeVersionv4.0" /> </modules> </system.webServer>

ApplicationHost.config में HTTP हैंडलर्स के लिए डिफ़ॉल्ट सेटिंग्स उदाहरण

 <system.webServer> <handlers accessPolicy="Read, Script"> *** <add name="AssemblyResourceLoader-Integrated" path="WebResource.axd" verb="GET,DEBUG" type="System.Web.Handlers.AssemblyResourceLoader" preCondition="integratedMode" /> <add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" /> <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.SimpleHandlerFactory" preCondition="integratedMode" /> <add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" preCondition="integratedMode,runtimeVersionv2.0" /> <add name="HttpRemotingHandlerFactory-rem-Integrated" path="*.rem" verb="GET,HEAD,POST,DEBUG" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" /> <add name="HttpRemotingHandlerFactory-soap-Integrated" path="*.soap" verb="GET,HEAD,POST,DEBUG" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" /> <add name="AXD-ISAPI-2.0" path="*.axd" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0" /> *** </handlers> </system.webServer>

ASP.NET 2.0 वेबफ़ॉर्म में पेज जीवन चक्र

ASP.NET 4.0 वेबफ़ॉर्म में पेज जीवन चक्र

IIS आर्किटेक्चर मूल बातें, या ASP.NET के लिए क्वेरी प्रावधान