क्या टीसीपी भेजे जाने वाले हर पैकेट के लिए एक नया कनेक्शन खोलता है?

Question

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

मेरे एक मित्र कह रहे हैं कि टीसीपी इस प्रवेश द्वार के लिए एक समस्या होगी क्योंकि यह प्रत्येक संदेश के लिए एक नया कनेक्शन स्थापित करने जा रहा है (कफका नहीं है लेकिन अंतर्निहित परिवहन प्रोटोकॉल ही मुद्दा है), हर बार एक नया पोर्ट की आवश्यकता होती है। दर पर हम इन ग्राहकों के संदेश (गीगाबाइट) भेजेंगे, काफ्का बंदरगाहों से बाहर पढ़ने के लिए चलेगा ??

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

जहाँ तक पोर्ट जाते हैं, एक पोर्ट का उपयोग प्रसारण के लिए किया जाता है और आंतरिक फ़ाइल डिस्क्रिप्टर पोर्ट व्यक्तिगत क्लाइंट के पढ़ने / लिखने के लिए एप्लिकेशन प्रबंधित करता है। मैंने टीसीपी को हर पैकेट के लिए नए कनेक्शन स्थापित करने के लिए कभी नहीं समझा।

मैं अग्रिम में माफी माँगता हूँ अगर यह प्रश्न प्रत्यक्ष नहीं है और बहुत अस्पष्ट है। मैं वास्तव में चकित हूं और उम्मीद कर रहा हूं कि कोई मेरे सहयोगी कह रहे हैं कि कुछ और संदर्भ प्रदान कर सकते हैं?

Comments

मुझे लगता है कि आप गलत समझ गए हैं कि आपका दोस्त क्या कह रहा था। टीसीपी ऐसी कोई बात नहीं करता है, लेकिन यह संभव है कि एक निश्चित ग्राहक प्रत्येक संदेश के लिए एक नया टीसीपी कनेक्शन बनाएगा जिसे वह पास करना चाहता है।

— हॉब

टीसीपी संभवतः प्रत्येक पैकेट के लिए एक नया कनेक्शन नहीं खोल सकता था क्योंकि उसे नया कनेक्शन खोलने के लिए कई पैकेटों की आवश्यकता होती है। और यह प्रत्येक संदेश के लिए एक नया कनेक्शन नहीं खोल सकता क्योंकि टीसीपी के पास संदेश की कोई अवधारणा नहीं है। आपका दोस्त बहुत भ्रमित है। टीसीपी, सबसे मौलिक अवधारणा के बारे में समझने के लिए सबसे महत्वपूर्ण बात यह है कि टीसीपी एक बाइट स्ट्रीम प्रोटोकॉल है।

— डेविड श्वार्ट्ज

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

— user1643723

Answer 1

मेरे एक मित्र कह रहे हैं कि टीसीपी इस प्रवेश द्वार के लिए एक समस्या होगी क्योंकि यह प्रत्येक संदेश के लिए एक नया कनेक्शन स्थापित करने जा रहा है (कफका नहीं है लेकिन अंतर्निहित परिवहन प्रोटोकॉल ही मुद्दा है), हर बार एक नया पोर्ट की आवश्यकता होती है। दर पर हम इन ग्राहकों के संदेश (गीगाबाइट) भेजेंगे, काफ्का बंदरगाहों से बाहर पढ़ने के लिए चलेगा ??

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

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

(व्यवहार में, टीसीपी के शीर्ष पर निर्मित अधिकांश प्रोटोकॉल में कुछ चीजें होती हैं, जो संदेश से मिलती-जुलती हैं, जैसे HTTP अनुरोध और प्रतिक्रिया। लेकिन टीसीपी ऐसी चीजों की संरचनाओं के बारे में नहीं जानता या देखभाल नहीं करता है।)

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

Answer 2

मेरी समझ यह है कि जब आप एक टीसीपी कनेक्शन स्थापित करते हैं, तो यह कनेक्शन तब तक खुला रहता है जब तक कि यह एप्लिकेशन द्वारा समाप्त न हो जाए या सर्वर या क्लाइंट द्वारा जबरन बंद कर दिया जाए।

टीसीपी के दृष्टिकोण से, कोई क्लाइंट या सर्वर नहीं है (क्लाइंट / सर्वर एक एप्लिकेशन अवधारणा है जो यहां ऑफ-टॉपिक है)। टीसीपी साथियों के बीच एक संबंध स्थापित करता है, और दोनों साथी कनेक्शन पर भेज और प्राप्त कर सकते हैं जब तक कि या तो सहकर्मी इसे बंद नहीं करता है, या यह निष्क्रियता से बाहर है।

इस कनेक्शन पर भेजा गया डेटा एक स्ट्रीम है और 3 V (वॉल्यूम, वेग, विविधता) की परवाह किए बिना नए कनेक्शन को नहीं खोलेगा / बंद करेगा।

क्या स्थिति भ्रामक हो सकती है कि कुछ एप्लिकेशन, जैसे ब्राउज़र, वेब पेज के तत्वों जैसी चीजों को एक साथ लोड करने के लिए कई कनेक्शन खोलेंगे।

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

Comments

हालांकि टीसीपी में एक साथी है जिसने कनेक्शन शुरू किया (जिसे अक्सर "क्लाइंट" कहा जाता है) और दूसरा एक (जिसे अक्सर "सर्वर" कहा जाता है)। बेशक, कनेक्शन स्थापित होने के बाद, यह अंतर अब और मायने नहीं रखता है।

— पाओलो एबरमैन

@ Pa @loEbermann, क्लाइंट या सर्वर के बारे में TCP RFC में कुछ भी नहीं है। क्लाइंट / सर्वर अवधारणा एक एप्लिकेशन अवधारणा है। ओएसआई लेयर -4 के नीचे या नीचे प्रोटोकॉल पर क्या है, और उन प्रोटोकॉल में कोई क्लाइंट या सर्वर नहीं हैं। वास्तव में, आप एक ग्राहक (टीसीपी कनेक्शन खोलने वाले) को क्या मान सकते हैं, वास्तव में, एक एप्लिकेशन सर्वर हो सकता है। हमारे पास ऐसे सर्वर हैं जो सुरक्षा जांच और अपडेट जैसी चीजों को करने के लिए ग्राहकों को टीसीपी कनेक्शन देते हैं।

— रॉन Maupin

Answer 3

नहीं, टीसीपी को भेजे जाने वाले प्रत्येक पैकेट के लिए एक नया कनेक्शन खोलने की आवश्यकता नहीं है।

आप HTTP लगातार कनेक्शन के माध्यम से कई पैकेट भेज सकते हैं , जहां:

... एक ही टीसीपी कनेक्शन भेजने और प्राप्त करने के लिए कई HTTP अनुरोधों / प्रतिक्रियाओं [उपयोग किया जाता है], हर एक अनुरोध या प्रतिक्रिया जोड़ी के लिए एक नया कनेक्शन खोलने के विपरीत।

संलग्न एक आकृति है जो कई कनेक्शनों के बीच अंतर दिखाती है (प्रति कनेक्शन एक वस्तु भेजने के लिए स्थापित कई कनेक्शन) और एक स्थायी कनेक्शन (एक कनेक्शन स्थापित और कई वस्तुओं को भेजा जाता है):

स्रोत: https://www.vcloudnine.de/how-to-dramatically-improve-website-load-tirs/

Comments

यह उत्तर परतों को भ्रमित करने वाला प्रतीत होता है। एक HTTP अनुरोध / प्रतिक्रिया शायद ही कभी एक पैकेट है।

— बरमार

प्रत्येक "ओपन" का उल्लेख नहीं करना वास्तव में 3 तीर (syn, synack, ack) है, और प्रत्येक "close" एक और 4 (फिन, ack 2x सर्वर और क्लाइंट) है, इसलिए यदि वास्तव में प्रति पैकेट एक कनेक्शन है, तो ओवरहेड जल्दी से जोड़ देंगे।

— htmlcoderexe

Answer 4

टीसीपी कैसे सही है, इसकी आपकी व्याख्या।

जैसा कि आपके मित्र ने कहा था, मुझे यहां दो संभावनाएं दिखती हैं:

1. आपने अपने मित्र को गलत समझा, जो कुछ एप्लिकेशन-लेयर सीमा का उल्लेख कर रहा था, जिसके परिणामस्वरूप प्रत्येक संदेश को एक नए कनेक्शन पर भेजा जा रहा है (और यह आवश्यक नहीं है कि असामान्य हो; यह इस व्यवहार के आधार पर तय करना संभव नहीं हो सकता है, जो कि सॉफ्टवेयर पर निर्भर करता है) स्टैक आप उपयोग कर रहे हैं);

2. आपका दोस्त गलत है

Answer 5

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

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

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

अंत में, जैसा कि दूसरों ने उल्लेख किया है, टीसीपी स्ट्रीम-उन्मुख है। जो भी हो कोई फीलिंग नहीं है। सिर्फ इसलिए कि एक सहकर्मी ने डेटा को एक विशेष तरीके से लिखा है (जैसे 1 256 बाइट राइट कॉल 2 256 बाइट राइट कॉल के बाद), यह गारंटी नहीं देता है कि दूसरा सहकर्मी इसे उसी आकार के चक्रों में पढ़ेगा (उदाहरण के लिए यह सभी 1536 ज़िप मिल सकता है) एक रीड कॉल में)। इस प्रकार यदि आप कच्चे टीसीपी सॉकेट्स पर कई "संदेश" भेज रहे हैं, तो आपको अलग-अलग संदेशों को डिलीट करने के लिए अपना स्वयं का फ्रेमन प्रोटोकॉल प्रदान करना होगा। हालांकि निश्चित रूप से ऐसा करने के सरल तरीके हैं, यह आमतौर पर बीमार है, क्योंकि इस समस्या को हल करने के लिए टीसीपी के ऊपर कई प्रोटोकॉल बनाए गए हैं। आगे की चर्चा के लिए, इस पर परामर्श करें: https://blog.stephencleary.com/2009/04/message-framing.html

Answer 6

मुझे लगता है कि आपका दोस्त HTTP के बारे में बात कर रहा था, टीसीपी नहीं।

HTTP मूल रूप से एक स्टेटलेस प्रोटोकॉल था: प्रत्येक HTTP अनुरोध एक अलग टीसीपी कनेक्शन का उपयोग करेगा। यही कारण है कि सत्रों को लागू करने के लिए हमें कुकीज़ (या कुछ समान) की आवश्यकता होती है।

Answer 7

आपने "एकल कनेक्शन और हर बार एक नए पोर्ट की आवश्यकता" का उल्लेख किया है, और मैं व्याख्या करता हूं कि आपके पास अपने संगठन के बाहर सर्वर से कनेक्ट करने के लिए उसी नेटवर्क वातावरण में पैट तकनीक का उपयोग करने वाले कई क्लाइंट हैं। PAT में 65535 (IPv4 एड्रेस पर टीसीपी सत्र सीमा) की सीमा होगी। यदि यह सत्य है, तो आपके पास सीमा है।

क्या टीसीपी भेजे जाने वाले हर पैकेट के लिए एक नया कनेक्शन खोलता है? नहीं, यह तब तक नहीं है जब तक कि टीसीपी सत्र वैध नहीं है। तथा ...

Answer 8

मुझे टीसीपी पर उत्कृष्ट विकिपीडिया पृष्ठ पसंद है । यह स्पष्ट रूप से दिखाता है कि पोर्ट नंबर के साथ क्या होता है। यह संयोग से, ressource उपयोग पर एक उपयोगी अध्याय भी शामिल है:

संसाधन उपयोग

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

सर्वर साइड में सत्रों की संख्या केवल मेमोरी द्वारा सीमित है और नए कनेक्शन आने के साथ बढ़ सकती है, लेकिन क्लाइंट को सर्वर को पहला SYN भेजने से पहले एक यादृच्छिक पोर्ट आवंटित करना होगा। यह पोर्ट पूरी बातचीत के दौरान आबंटित रहता है, और क्लाइंट के प्रत्येक आईपी पते से आउटगोइंग कनेक्शन की संख्या को प्रभावी रूप से सीमित करता है। यदि कोई एप्लिकेशन बिना कनेक्शन के ठीक से बंद होने में विफल रहता है, तो क्लाइंट संसाधनों से बाहर निकल सकता है और अन्य अनुप्रयोगों के साथ भी नए टीसीपी कनेक्शन स्थापित करने में असमर्थ हो सकता है।

संक्षेप में, टीसीपी एक बहुत ही बारीक रीसोर्स का उपयोग करता है , जो क्लाइंट पर पोर्ट की संख्या है (जो टीसीपी हेडर, 16 बिट्स में पोर्ट फ़ील्ड के आकार तक सीमित है)।

तो, TCP पोर्ट से बाहर भागने में सक्षम है, अगर कोई क्लाइंट उन्हें बंद किए बिना समानांतर में बहुत सारे TCP कनेक्शन खोलता है। समस्या केवल क्लाइंट-साइड में होती है, और इससे कोई फर्क नहीं पड़ता कि कनेक्शन एक ही या अलग सर्वर आईपी पते या सर्वर पोर्ट के साथ हैं।

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

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

यदि आपके पास केवल कुछ मुट्ठी भर ग्राहक हैं, जो 65k-ish से कम है, और / या आप अपने Kafka ब्राउज़र से एक ही कनेक्शन रखते हैं, तो आप ठीक हो जाएंगे।