TCP_DEFER_ACCEPT का वास्तविक-विश्व उपयोग?

Question

मैं अपाचे httpd मैनुअल को ऑनलाइन मना कर रहा था और इसे सक्षम करने के लिए एक निर्देश आया। इसके लिए मैन पेज में एक विवरण मिला tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

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

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

लेख के लिए, यह भी मुझे प्रतीत होगा कि TCP_DEFER_ACCEPTसॉकेट की स्थिति कोई फर्क नहीं पड़ता , आपको अभी भी चार पैकेट (प्रत्येक मामले में डेटा फिर हाथ मिलाना) की आवश्यकता होगी। मैं नहीं जानता कि उन्हें कैसे तीन तक गिनती मिलती है, न ही यह कैसे सार्थक वृद्धि प्रदान करता है।

तो मेरा प्रश्न मूल रूप से है: क्या यह सिर्फ एक पुराना अप्रचलित विकल्प है या इस विकल्प का वास्तविक उपयोग मामला है?

Comments

मैं इस बात पर स्पष्ट नहीं हूं कि "तीन से नीचे की गिनती प्राप्त करें" से आपका क्या मतलब है, जिससे मुझे संदेह है कि आपको तीन तरह से हाथ मिलाने की गलतफहमी है। यह एक टीसीपी "ओपन कनेक्शन" लेनदेन है और इसमें कुल 3 पैकेट शामिल हैं। इन 3 पूर्ण होने तक, कोई डेटा नहीं है, और कोई ऐसा कनेक्शन नहीं है जो वैध हो। इस तरह के डेटा के रूप में हैंडशेकिंग ओवरहेड में कभी कारक नहीं होते हैं। TCP_DEFER_ACCEPT से प्राप्त की जाने वाली दक्षता वृद्धि 'tcp 3 तरीके से हैंडशेक' को पूरा करने के बीच का अंतर होगी, और पहला डेटा पैकेट (मेरा मानना ​​है कि, ज्यादातर यहाँ 3 बनाम 4 तरीके से

— टाइप

इसके अलावा, यह 'स्वैपिंग' से बचने के बारे में नहीं है, यह संसाधनों को बर्बाद नहीं करने के बारे में है। यदि स्वैपिंग एक HTTP कार्यकर्ता को सक्रिय करने में एक कारक बन गया था, तो आप डेटा तैयार होने से पहले अपने कार्यकर्ता को समय से पहले स्वैप करने के लिए मजबूर कर रहे हैं ... और यदि स्वैपिंग हो रही है, तो इसका मतलब है कि आप कुछ और मजबूर कर रहे हैं RAM ... कुछ ऐसा जो शायद कुछ कर रहा था और आपके स्वीकार / डेटा भाग के बीच वापस स्वैप हो जाता है ... जो भी संसाधन - सीपीयू, डिस्कियो, इन-रैम पृष्ठ, यदि कोई डेटा नहीं है, तो कोई बिंदु नहीं है जिससे काम हो सकता है।

— ।

यदि कार्यकर्ता प्रक्रिया पहले से ही स्मृति में है, तो संभवतः डिस्क पर जाने की तुलना में यह बहुत कम विलंबता नहीं है? "डाउन टू थ्री" लेख का एक संदर्भ है जिसमें कहा गया है कि किसी तरह यह ऐसा होगा ताकि ग्राहक का पहला पैकेट तीसरे पैकेट पर होगा।

— ब्राचली

इसके अलावा, सैद्धांतिक स्वैप-में वैसे भी होने जा रहा है, यह इस टीसीपी विकल्प के साथ नहीं बदलेगा। मैं यह नहीं देखता कि टीसीपी कनेक्शन बनाने और डेटा ट्रांसफर में डालने से कितना अंतर है। कम से कम जब आप इसे टीसीपी कनेक्शन बनाने के दौरान कर रहे हैं तो दो के समानांतर होने (समय की मात्रा कम होने) की संभावना है।

— ब्राचली

बस एक उत्तर लिखा होना चाहिए ... इसके संबंध में एक विकल्प होने के नाते, ठीक है, यह नहीं कि "सामान्य" यूनिक्स मानक कैसे काम करते हैं ... विशेष रूप से HTTP के बारे में मुख्य बिंदु यह है कि क्लाइंट (वेब ​​ब्राउज़र) बातचीत के साथ पहल करता है लाइन प्राप्त करें ... तो सर्वर वास्तविक कनेक्शन के बारे में परवाह नहीं करता है, सिर्फ पहला डेटा। जैसा कि एसएमटीपी कहने के लिए विरोध किया जाता है, जिसके लिए क्लाइंट को तब तक इंतजार करना पड़ता है जब तक सर्वर अपना "220 स्वागत बैनर" संदेश जारी नहीं करता। यानी डेटा पर नहीं, कनेक्ट पर सर्वर को जानना होगा।

— 15

Answer 1

(ओपी पर मेरी टिप्पणियों को संक्षेप में प्रस्तुत करने के लिए)

तीन-तरफा हैंडशेक जिसे वे संदर्भित कर रहे हैं वह टीसीपी कनेक्शन प्रतिष्ठान का हिस्सा है, प्रश्न में विकल्प विशेष रूप से इससे संबंधित नहीं है। यह भी ध्यान दें कि डेटा एक्सचेंज तीन तरह से हैंडशेक का हिस्सा नहीं है, यह सिर्फ खुले / स्थापित राज्य में टीसीपी कनेक्शन बनाता है।

इस विकल्प की मौजूदगी के बारे में, यह एक सॉकेट का पारंपरिक व्यवहार नहीं है, आम तौर पर कनेक्शन स्वीकार किए जाने पर सॉकेट हैंडलर का धागा जाग जाता है (जो तीन तरह से हैंडशेक पूरा होने के बाद भी), और कुछ प्रोटोकॉल के लिए गतिविधि यहां शुरू होती है ( जैसे SMTP सर्वर 220 ग्रीटिंग लाइन भेजता है), लेकिन HTTP के लिए वार्तालाप में पहला संदेश वेब ब्राउज़र है जो अपना GET / POST / etc लाइन भेज रहा है, और जब तक ऐसा नहीं होता है HTTP सर्वर को कनेक्शन में कोई दिलचस्पी नहीं है (समय के अलावा अन्य) यह बाहर), इस प्रकार HTTP प्रक्रिया को जाग्रत करने पर सॉकेट स्वीकार करना एक बेकार गतिविधि है क्योंकि प्रक्रिया तुरंत आवश्यक डेटा के इंतजार में सो जाएगी।

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

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

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

Comments

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

— राम

Answer 2

मैं स्पष्ट नहीं हूं कि तीन तरह से हाथ मिलाने का इंतजार करने का क्या फायदा होगा।

वॉइस टेलीफोनी में थ्री-वे हैंडशेक एक सामान्य प्रोटोकॉल है:

1. सर्वर : "शुभ दोपहर, एपिफ़ाइट कॉर्प"
2. कॉलर : "हैलो, यह रैंडी है।"
3. सर्वर : "हाँ, मैं आपकी कैसे मदद कर सकता हूँ?"
4. कॉलर : कॉल ऑफ बॉडी एक मजाक का अनुरोध करना शुरू कर देता है

चैनल की स्थापना के लिए वे टीसीपी में महत्वपूर्ण हैं। यदि क्लाइंट ने सुनवाई से पहले कॉल की बॉडी भेजना शुरू कर दिया (3) एक मौका है कि सर्वर सुन नहीं रहा है या तैयार नहीं है। श्रवण (3) इस बात की गारंटी नहीं देता है कि ट्रांसमिशन के बाद सर्वर को सहज दहन का सामना नहीं करना पड़ा, लेकिन यह विश्वास को बढ़ाता है कि सर्वर प्राप्त करने के लिए तैयार है।

जैसा कि हैंडशेकिंग पर विकिपीडिया में दिया गया है :

1. ऐलिस [सर्वर] पावती नंबर y + 1 के साथ एक पावती संदेश के साथ उत्तर देता है, जिसे बॉब [क्लाइंट] प्राप्त करता है और जिसके लिए उसे जवाब देने की आवश्यकता नहीं होती है ।

इसलिए यदि आप सर्वर से तैयार होने के लिए थोड़ा जोड़ा निश्चित करने के लिए तैयार हैं, तो सर्वर चरण (3) को छोड़ सकता है और क्लाइंट बस मान लेगा कि सर्वर तैयार था। यह ऊपर प्रोटोकॉल एक्सचेंज में बदल जाता है:

1. सर्वर : "शुभ दोपहर, एपिफ़ाइट कॉर्प"
2. कॉलर : "हैलो, यह रैंडी है।"
3. कॉलर : "क्या आप इमेल्डा मार्कोस के बारे में कोई चुटकुला जानते हैं?"

Comments

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

— ४

श्रवण (3) इस बात की गारंटी नहीं देता है कि ट्रांसमिशन के बाद सर्वर को सहज दहन का सामना नहीं करना पड़ा, लेकिन यह विश्वास को बढ़ाता है कि सर्वर प्राप्त करने के लिए तैयार है।

— msw

बढ़ना? शून्य से? ठीक है, मुझे लगता है कि यह शाब्दिक रूप से सही है, लेकिन ज्यादातर लोगों को लगता है कि पैकेट 3 को बढ़ाने से पहले / कुछ / मौका था। और वहाँ नहीं है। यह सिर्फ वाक्यांश "आत्मविश्वास बढ़ाएं" है जो मुझे पसंद नहीं है, और मुझे नहीं लगता कि 0.001% 'वास्तविक विश्व प्रमुख मुद्दों' में फैक्टरिंग करने से समस्या स्पष्ट होती है। बेशक, परमाणु युद्ध हो सकता है इससे पहले कि सर्वर को पैकेट मिले, बहुत सारी चीजें हो सकती हैं।

— 17

इसके अलावा, मैंने अभी पिछले पैराग्राफ पर उठाया है, जहां आप चरण 3 को वैकल्पिक करते हैं। यह नहीं है, बिल्कुल नहीं है। पैराग्राफ को फिर से बनाएं, चरण 3 "एक पावती के साथ उत्तर दें" है। यह वैकल्पिक नहीं है। बॉब इसका उत्तर दे रहा है (एक सैद्धांतिक 4 वें चरण)।

— आईएनसी