वेब-सर्वर आईपी पते, इंटरप्ट या पोलिंग के लिए "सुनो" कैसे करते हैं?


87

मैं वेब सर्वर के निचले विवरण को समझने की कोशिश कर रहा हूं। मैं सोच रहा हूं कि क्या एक सर्वर, अपाचे का कहना है, नए अनुरोधों के लिए लगातार मतदान कर रहा है या यदि यह किसी प्रकार की रुकावट प्रणाली द्वारा काम करता है। यदि यह एक रुकावट है, तो रुकावट क्या है, क्या यह नेटवर्क कार्ड ड्राइवर है?


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

1
@sawdust बहुत दिलचस्प है। सवाल वास्तव में SW और HW प्रक्रियाओं के बीच संबंध को समझने के लिए है
user2202911

1
यह कमांड-लाइन (और अन्य GUI) प्रोग्राम के कीबोर्ड को सुनने के तरीके के समान है। विशेष रूप से एक विंडो सिस्टम में, जहां आपके पास कीबोर्ड डिवाइस से डेटा प्राप्त करने वाले कर्नेल का चरण है और इसे विंडो मैनेजर को सौंपना है, जो उस विंडो की पहचान करता है जिसमें फोकस है और उस विंडो को डेटा देता है।
जी-मैन

@ जी-मैन: मैं सिद्धांत, हाँ। वास्तव में अधिकांश टाइपिस्ट 1 Gbit / s पर टाइप नहीं करते हैं, जो दो अलग-अलग आर्किटेक्चर होने को सही ठहराते हैं। एक साफ, लचीला और धीमा, एक अनाड़ी लेकिन उच्च गति वाला।
एमएसलेटर

जवाबों:


181

संक्षिप्त उत्तर है: किसी प्रकार की व्यवधान प्रणाली। अनिवार्य रूप से, वे नए डेटा की प्रतीक्षा करते समय अवरुद्ध I / O का उपयोग करते हैं, जिसका अर्थ है कि वे सोते हैं (ब्लॉक)।

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

  2. जब नया डेटा नेटवर्क पर आता है, तो नेटवर्क कार्ड एक बाधा जारी करता है।

  3. यह देखते हुए कि नेटवर्क कार्ड से एक बाधा है, कर्नेल, नेटवर्क कार्ड ड्राइवर के माध्यम से, नेटवर्क कार्ड से नया डेटा पढ़ता है और इसे मेमोरी में संग्रहीत करता है। (यह जल्दी से किया जाना चाहिए और आम तौर पर बाधा हैंडलर के अंदर संभाला जाता है।)

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

  5. अपने अवकाश पर, कर्नेल अवरुद्ध वेबसर्वर प्रक्रिया को जगाएगा। (चूंकि अब यह चल रहा है।)

  6. वेबसर्वर प्रक्रिया ऐसे ही चलती रहती है जैसे कि कोई समय बीत गया हो। इसका ब्लॉकिंग सिस्टम कॉल रिटर्न देता है और यह किसी भी नए डेटा को प्रोसेस करता है। फिर ... चरण 1 पर जाएं।


18
+1 कर्नेल बनाम वेबसर्वर प्रक्रिया के स्पष्ट परिसीमन के लिए।
रसेल बोरोगोव

13
मैं कुछ जटिल के रूप में विश्वास नहीं कर सकता क्योंकि यह इतनी स्पष्ट रूप से और सरल रूप से संक्षेप किया जा सकता है, लेकिन आपने इसे किया। +1
ब्रैंडन

8
+1 महान जवाब। इसके अलावा, 2 और 3 के बीच के कदम आधुनिक एनआईसी, ओएस और ड्राइवरों के साथ थोड़ा अधिक जटिल हो सकते हैं। उदाहरण के लिए, लिनक्स पर NAPI के साथ , पैकेट वास्तव में रुकावट के संदर्भ में प्राप्त नहीं होते हैं। इसके बजाय, कर्नेल कहते हैं, "ठीक है एनआईसी, मैं समझता हूं कि आपको डेटा मिल गया है। मुझे बग़ल में रोकें (व्यवधान स्रोत को अक्षम करें), और मैं इस पैकेट और किसी भी बाद के पैकेट को हथियाने के लिए शीघ्र ही वापस आऊंगा जो मेरे आने से पहले हो सकता है।"
जोनाथन रेनहार्ट

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

3
"नेटवर्क कार्ड से नया डेटा पढ़ता है और इसे मेमोरी में स्टोर करता है। (इसे जल्दी से किया जाना चाहिए और आमतौर पर इंटरप्ट हैंडलर के अंदर संभाला जाता है।)" क्या यह डायरेक्ट मेमोरी एक्सेस के साथ नहीं किया गया है?
सियुआन रेन

9

बहुत सारे "निचले" विवरण हैं।

पहले, विचार करें कि कर्नेल में प्रक्रियाओं की एक सूची है, और किसी भी समय, इनमें से कुछ प्रक्रियाएं चल रही हैं, और कुछ नहीं हैं। कर्नेल प्रत्येक चलने की प्रक्रिया को सीपीयू समय के कुछ स्लाइस की अनुमति देता है, फिर इसे बाधित करता है और अगले पर जाता है। यदि कोई रन करने योग्य प्रक्रियाएं नहीं हैं, तो कर्नेल संभवतः CPU को HLT जैसा निर्देश जारी करेगा जो CPU को तब तक निलंबित करता है जब तक कि कोई हार्डवेयर व्यवधान न हो।

सर्वर में कहीं एक सिस्टम कॉल है जो कहता है "मुझे कुछ करने के लिए दो"। इसे करने के दो तरीके हैं। अपाचे के मामले में, यह acceptएक सॉकेट पर कॉल करता है। अपाचे पहले खोला गया है, शायद पोर्ट 80 पर सुन रहा है। कर्नेल कनेक्शन प्रयासों की एक कतार बनाए रखता है, और टीसीपी SYN प्राप्त होने पर हर बार उस कतार में जुड़ जाता है । एक कर्नेल को पता है कि टीसीपी SYN प्राप्त किया गया था, डिवाइस ड्राइवर पर निर्भर करता है; कई एनआईसी के लिए नेटवर्क डेटा प्राप्त होने पर संभवतः एक हार्डवेयर अवरोध होता है।

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

एक बार acceptलौटते समय, अपाचे जानता है कि कोई व्यक्ति कनेक्शन शुरू करने का प्रयास कर रहा है। यह फिर दो समान प्रक्रियाओं में अपाचे प्रक्रिया को विभाजित करने के लिए कांटा कहता है। इनमें से एक प्रक्रिया HTTP अनुरोध को संसाधित करने के लिए जाती है, दूसरे acceptको अगला कनेक्शन प्राप्त करने के लिए फिर से कॉल करता है। इस प्रकार, हमेशा एक मास्टर प्रक्रिया होती है जो acceptउप-प्रक्रियाओं को कॉल और स्पॉन करने के अलावा कुछ नहीं करती है, और फिर प्रत्येक अनुरोध के लिए एक उप-प्रक्रिया होती है।

यह एक सरलीकरण है: प्रक्रियाओं के बजाय थ्रेड्स के साथ ऐसा करना संभव है, और यह forkपहले से संभव भी है इसलिए अनुरोध प्राप्त होने पर एक कार्यकर्ता प्रक्रिया तैयार है, इस प्रकार स्टार्टअप ओवरहेड को कम करना। यह अपाचे को कैसे कॉन्फ़िगर किया गया है, इसके आधार पर यह इन चीजों में से एक हो सकता है।

यही कारण है कि यह कैसे करना है के पहले व्यापक श्रेणी है, और यह कहा जाता है आईओ अवरुद्ध क्योंकि सिस्टम की तरह कहता है acceptऔर readऔर writeजो सॉकेट पर काम प्रक्रिया को निलंबित कर देगा, जब तक वे वापस जाने के लिए कुछ है।

इसे करने का दूसरा व्यापक तरीका गैर-अवरोधक या घटना आधारित या अतुल्यकालिक आईओ कहा जाता है । यह सिस्टम कॉल जैसे selectया के साथ कार्यान्वित किया जाता है epoll। ये प्रत्येक एक ही काम करते हैं: आप उन्हें सॉकेट्स की सूची देते हैं (या सामान्य तौर पर, फाइल डिस्क्रिप्टर) और आप उनके साथ क्या करना चाहते हैं, और कर्नेल को तब तक ब्लॉक करता है जब तक कि उन चीजों में से एक करने के लिए तैयार न हो।

इस मॉडल के साथ, आप कर्नेल को बता सकते हैं (के साथ epoll), "मुझे बताएं कि पोर्ट 80 पर एक नया कनेक्शन है या इन 9471 अन्य कनेक्शनों में से किसी एक पर पढ़ने के लिए नया डेटा है"। epollजब तक उन चीजों में से एक तैयार न हो जाए, तब तक आप इसे करें। फिर आप दोहराते हैं। सिस्टम कॉल की तरह acceptऔर readऔर writeकभी नहीं ब्लॉक, भाग में, क्योंकि जब भी आप उन्हें फोन, epollकेवल आपके बताया कि वे तैयार हैं तो वहाँ ब्लॉक करने के लिए कोई कारण नहीं होगा, और इसलिए भी क्योंकि जब आप सॉकेट या फ़ाइल आपके द्वारा निर्दिष्ट खोलने आप उन्हें चाहते हैं कि गैर-अवरुद्ध मोड में, इसलिए वे कॉल EWOULDBLOCKअवरुद्ध होने के बजाय विफल हो जाएंगे ।

इस मॉडल का लाभ यह है कि आपको केवल एक प्रक्रिया की आवश्यकता है। इसका मतलब है कि आपको प्रत्येक अनुरोध के लिए स्टैक और कर्नेल संरचनाओं को आवंटित करने की आवश्यकता नहीं है। Nginx और HAProxy इस मॉडल का उपयोग करते हैं, और यह एक बड़ा कारण है कि वे समान हार्डवेयर पर Apache की तुलना में इतने अधिक कनेक्शन से निपट सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.