कर्नेल मोड वेब सर्वर: एक चतुर अनुकूलन या एक सुरक्षा दुःस्वप्न?


28

मैं एक हैकर न्यूज थ्रेड पढ़ रहा था, जहां एक उपयोगकर्ता 2011 से एक लिंक पोस्ट कर रहा है जिसमें बताया गया है कि आईआईएस अन्य (* निक्स) वेब सर्वरों की तुलना में बहुत तेज है। एक अन्य उपयोगकर्ता ने उत्तर दिया, यह समझाते हुए कि IIS को HTTP.sys नामक कर्नेल मॉड्यूल होने से वह लाभ मिलता है । मेरी जानकारी के लिए, 2015 में अधिकांश अन्य लोकप्रिय वेब सर्वर ऐसा नहीं करते हैं।

मैं कर्नेल मोड वेब सर्वर कभी नहीं लिखना चाहूंगा, क्योंकि मैं कभी भी अपने आप को सुरक्षा कारनामों से मुक्त करने के लिए भरोसा नहीं कर सकता था (जो कम सुरक्षा रिंग में कम गंभीर होगा)।

सॉफ्टवेयर इंजीनियर के दृष्टिकोण से (वेब ​​सर्वर के लिए एक ग्राहक के विपरीत), कर्नेल मोड में एक स्मार्ट प्रदर्शन निर्णय ले रहा है? क्या कर्नेल मोड सर्वर को उपभोक्ता के लिए शुद्ध लाभ बनाने के बिंदु पर अनुप्रयोग विकास में सुरक्षा चिंताओं को कम किया जा सकता है?


5
"सर्वर दोष प्रणाली और नेटवर्क प्रशासकों के लिए एक प्रश्न और उत्तर साइट है।" Sysadmins और नेटवर्क व्यवस्थापक वेब सर्वर नहीं लिखते हैं; वे उन्हें स्थापित और बनाए रखते हैं। मुझे लगता है कि कर्नेल मोड / उपयोगकर्ता मोड का सवाल स्थापना समय की तुलना में विकास के समय में अधिक प्रासंगिक है। मुझे कोई आपत्ति नहीं है कि प्रश्न कहीं और प्रासंगिक हो गया है, लेकिन मुझे लगता है कि सर्वर फॉल्ट इसे विषय पर भी नहीं मिलेगा।
जेम्स मिश्रा

ठीक है, इस प्रश्न को फिर से दोहराते हुए, मुझे लगता है कि इसकी व्याख्या एक सामान्य सॉफ़्टवेयर आर्किटेक्चर प्रश्न के रूप में की जा सकती है, न कि मौजूदा वेब सर्वर के पेशेवरों और विपक्षों के बारे में एक प्रश्न के रूप में, इसलिए मेरे करीबी वोट को वापस ले लिया गया। लेकिन आप सामान्य सॉफ़्टवेयर आर्किटेक्चर पहलू को उजागर करने के लिए अपने प्रश्न को संपादित करने पर विचार कर सकते हैं।
डॉक्टर ब्राउन

2
जो कोई भी यह सोचता है कि कर्नेल मोड वेब सर्वर प्रदर्शन में सुधार कर सकता है क्योंकि उसे संदर्भ स्विच करने की आवश्यकता नहीं है, तो पढ़ना चाहिए: अक्षांश क्रमांक जो हर प्रोग्रामर को पता होना चाहिए । लिनक्स में पूर्ण संदर्भ स्विच की कीमत लगभग 3000ns ( स्रोत ) है, लेकिन कई syscalls को वास्तव में पूर्ण संदर्भ स्विच की आवश्यकता नहीं होती है और 50ns के रूप में कम जा सकता है, मेरे पास विंडोज के लिए नंबर नहीं हैं। यह कहीं न कहीं 2 / 3rd कॉलम के साथ है। निष्कर्ष: नेटवर्क अनुरोध और डिस्क को कम से कम करें, संदर्भ स्विच के बारे में चिंता न करें।
रेयान

जवाबों:


24

Http.sys इतना वेब सर्वर नहीं है जितना प्रॉक्सी-फारवर्डर है। इसे कई वेब सर्वरों को विंडोज बॉक्स पर सह-अस्तित्व देने की अनुमति देने के लिए डिज़ाइन किया गया है, इसलिए आप IIS को एक वेब साइट चला सकते हैं, लेकिन कई WCF सेवाएँ जो http / REST या SOAP इंटरफेस के साथ चल रही हैं, सभी मानक पोर्ट 80 पर हैं। (यही कारण है कि आप बिना थके हुए विंडोज पर अपाचे नहीं चला सकते हैं, अपाचे को इस पंजीकरण प्रणाली के साथ काम करने के लिए संशोधित नहीं किया गया है, शर्म की बात है कि यह अनुप्रयोगों के लिए अधिक पारदर्शी नहीं था और इसमें हुक करने के लिए कुछ काफी जटिल संशोधनों की आवश्यकता थी)।

जिस तरह से यह काम करता है वह यह है कि आप इसके साथ एक यूआरएल रजिस्टर करते हैं और संबंधित अनुप्रयोग, ans जब एक HTTP अनुरोध पोर्ट 80 पर किया जाता है, http.sys इसे स्वीकार करता है लेकिन फिर उस URL लक्ष्य को संभालने के लिए जो भी आवेदन पंजीकृत होता है उस पर अनुरोध पारित करता है।


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


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

3
मुझे लगता है कि HTTP.sys एक ऐसे समय से है जहां CPU साइकिल बहुत अधिक दुर्लभ थे ... यहां तक ​​कि छोटी स्थिर फ़ाइलों (जो HTTP.sys के लिए सबसे लाभप्रद मामला है) की सेवा करते समय एक पूर्ण उपयोगकर्ता मोड HTTP सर्वर संभवतः अधिकांश नेटवर्क को अधिकतम कर देगा। ।
usr

4
@usr Http.sys एक अपेक्षाकृत नई चीज है, जिसे विंडोज सर्वर 2003 में पेश किया गया है। मुझे पूरा यकीन है कि इसके साथ ही आप पोर्ट 80 पर एक साथ कई वेब एपीआई सेवाएं चला सकते हैं।
gbjbaanb

2
@gbjbaanb एक उपयोगकर्ता मोड सर्वर उसके लिए भी अनुमति दे सकता है। विंडोज में मेमोरी (बफ़र्स के लिए) साझा करने और सॉकेट हैंडल को एक अलग प्रक्रिया में पारित करने की क्षमता है।
usr

1
@JamesMishra मेरे दिमाग में, हाँ। तब सीपीयू शायद 10x कम शक्तिशाली थे। इसके अलावा, सुरक्षा मानसिकता वास्तव में वहाँ नहीं थी। आज यह सिर्फ एक बुरा फोन है।
यूएसआर

14

Http.sys केवल कर्नेल-मोड वेब सर्वर उपलब्ध नहीं है: लिनक्स के तहत भी टक्स है । जैसा कि आपने सही तरीके से पहचाना है, सुरक्षा इस प्रकार के सर्वरों के साथ एक चिंता है, जिसके कारण टक्स को मेनलाइन लिनक्स कर्नेल में शामिल नहीं किया जा सकता है (और मेरा मानना ​​है कि अधिक हाल के कर्नेल संस्करणों के लिए अपडेट नहीं किया गया है)।

एक बेहतर समाधान एक ऑपरेटिंग सिस्टम का उपयोग होगा जो प्रक्रिया सुरक्षा को लागू करने के लिए हार्डवेयर सुरक्षा पर निर्भर नहीं होता है, जैसे कि Microsoft की विशिष्टता: इस तरह की प्रणाली सुरक्षा जोखिमों के बिना कर्नेल मोड सर्वर की दक्षता हासिल करने की अनुमति देती है। दुर्भाग्य से, इस सिद्धांत पर आधारित कोई भी उत्पादन तैयार ऑपरेटिंग सिस्टम 2015 तक उपलब्ध नहीं है, और AFAIK कोई भी गंभीरता से एक या तो काम नहीं कर रहा है (सिंगुलैरिटी प्रोजेक्ट रद्द कर दिया गया था)।


सिंगुलैरिटी दृष्टिकोण के साथ बड़ी समस्या यह है कि इसका मतलब है कि जेटर में लेकिन आसानी से विशेषाधिकार वृद्धि हो सकती है।
कोडइन्चोस

2
टक्स विकिपीडिया लेख एक दिलचस्प पढ़ा है। टक्स गैर-स्थिर सामग्री के लिए HTTP अनुरोधों को अपाचे जैसे "असली" वेब सर्वर के लिए अग्रेषित कर सकता है, जो लगता है कि Http.sys का उपयोग किस लिए किया जाता है। मैं नहीं बता सकता कि टक्स Http.sys के रूप में प्रदर्शन कर रहा था, लेकिन मैंने जो कुछ भी पढ़ा है, उसके आधार पर, ऐसा लगता है कि लिनक्स कर्नेल देव माइक्रोसॉफ्ट के फैसले से तेजी से असहमत होंगे।
जेम्स मिश्रा

10

Http.sys कम जोखिम वाला है, क्योंकि यह तीसरे पक्ष द्वारा प्रदान की गई किसी भी सहायता को नहीं चला सकता है।

Http.sys कुछ कार्य करता है।

  • यह प्रॉक्सी-फारवर्डर के रूप में कार्य करता है, इसलिए कई प्रक्रियाओं को HTTP नाम स्थान के विभिन्न भागों में अनुरोध करने के लिए प्रतिक्रिया करने की अनुमति देता है। gbjbaanb उत्तर इसे अच्छी तरह से कवर करता है।

  • यह स्टैटिक फाइल्स को सेव करता है, सीधे विंडोज़ फाइल्स कैशे से। यह छोटी फाइल्स की स्टैटिक फाइल्स के लिए बढ़िया स्पीडअप प्रदान करता है, क्योंकि इसमें कोई संदर्भ स्विच नहीं हैं।

  • यह किसी भी एप्लिकेशन से आउटपुट को कैश करेगा जो कि HTTP रिक्वेस्ट को फॉरवर्ड करता है और कैशेड रिजल्ट को लौटाता है। एप्लिकेशन पूर्ण नियंत्रण में है कि कैशिंग कितने समय तक (यदि कोई है) रहता है।

Http.sys सरल कार्यों को बहुत तेजी से करने के लिए डिज़ाइन किया गया है, जबकि उपयोगकर्ता अंतरिक्ष में एक प्रक्रिया के लिए बाकी सब कुछ गुजर रहा है।

टिप्पणी के जवाब में

"कम जोखिम, क्योंकि यह किसी तीसरे पक्ष द्वारा प्रदान किए गए किसी भी कोड को नहीं चला सकता है" - यही वे हमेशा कहते हैं, और यह लगभग कभी सच नहीं है।

मुद्दा यह है कि आपको इस प्रश्न को पूछने के लिए जटिल कर्नेल कोड लिखने के लिए Microsoft पर भरोसा करना चाहिए, अन्यथा आप वेब होस्टिंग के लिए विंडोज़ का उपयोग न करने का निर्णय लेते हैं । Http.sys कर्नेल बग के जोखिम को बहुत कम जोड़ता है, यह देखते हुए कि कर्नेल कितना जटिल है।

यदि कुछ भी Http.sys जोखिम को कम करता है, क्योंकि "निम्न स्तर" वेब सेवारत और एप्लिकेशन कोड के नीचे इस तरह की स्पष्ट पृथक्करण है।

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


1
Usermode अनुप्रयोगों को अक्सर ऐसी असुरक्षित भाषाओं में लिखा जाता है जो अधिकांश मेमोरी करप्शन आधारित बग्स को नियंत्रित करती हैं (ये आमतौर पर वे होते हैं जो दूरस्थ कोड निष्पादन को जन्म देते हैं)।
कोडइन्चोस

3
मुझे यकीन नहीं है कि अगर मैं तर्क को खरीदता हूं कि अगर मैं माइक्रोसॉफ्ट को कर्नेल कोड लिखने के लिए भरोसा करता हूं, तो यह है कि कर्नेल मोड वेब सर्वर कोड लिखने के लिए उन पर भरोसा करने के लिए यह एक छोटी सी छलांग है। मैं एक सूचना सुरक्षा के दृष्टिकोण से काफी अनुभवहीन हूं, लेकिन मुझे लगता है कि डिवाइस ड्राइवर या कर्नेल के कुछ अन्य भाग की तुलना में Http.sys में बफर ओवरफ्लो को इंटरनेट से दूर करना आसान होगा।
जेम्स मिश्रा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.