हमें 3-तरफ़ा हैंडशेक की आवश्यकता क्यों है? सिर्फ 2-वे ही क्यों?

Question

टीसीपी 3-रास्ता हैंडशेक इस तरह काम करता है:

Client ------SYN-----> Server
Client <---ACK/SYN---- Server
Client ------ACK-----> Server

सिर्फ यही क्यों नहीं?

Client ------SYN-----> Server
Client <-----ACK------ Server

Comments

हमें हैंडशेक की भी आवश्यकता क्यों है? संदेश को पहले पैकेट के साथ क्यों नहीं भेजा जा सकता है?

— मेहरदाद

यदि आप हैंडशेक को छोड़ना चाहते हैं तो आप इसके बजाय UDP का उपयोग कर सकते हैं।

— OzNetNerd

@ मेहरदाद, यदि आपका खुद का प्रश्न है, तो कृपया अपना स्वयं का पोस्ट करने के लिए पृष्ठ के शीर्ष पर प्रश्न पूछें लिंक का उपयोग करें ।

— YLearn

@YLearn: क्षमा करें, यह वास्तव में मेरे खुद का सवाल नहीं है, बल्कि यह पाठकों को जवाब देने के लिए प्रेरित करने के लिए था जो वास्तव में कहा गया है, की तुलना में थोड़ा गहरा खुदाई करते हैं।

— मेहरदाद

टीसीपी फास्ट ओपन (RFC 7413) के बारे में मत भूलना

— Alnitak

Answer 1

यह वास्तव में क्या कर रहा है में हाथ मिलाना तोड़ो।

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

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

तो आप ऐलिस और बॉब के बीच एक टीसीपी वार्तालाप की शुरुआत के लिए घटनाओं के इस क्रम को समाप्त करते हैं:

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

ध्यान दें, चार घटनाएं घट रही हैं:

1. एलिस एक ISN चुनती है और इसे बॉब के साथ सिंक करती है।
2. बॉब ACNnowledges ISN।
3. बॉब एक ​​ISN चुनता है और इसे ऐलिस के साथ सिंक करता है।
4. एलिस ACKnowledges ISN।

हालांकि वास्तविकता में, मध्य दो घटनाएं (# 2 और # 3) एक ही पैकेट में होती हैं। क्या एक पैकेट एक SYNया ACKएक बस बाइनरी झंडे प्रत्येक टीसीपी हैडर के अंदर पर या बंद कर दिया जाता है , इसलिए इन दोनों झंडों को एक ही पैकेट पर सक्षम होने से रोकने के लिए कुछ भी नहीं है। तो तीन तरह से हाथ मिलाना समाप्त होता है:

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK     

"SYN" और "ACK", दोनों दिशाओं में से प्रत्येक के दोनों उदाहरणों को देखें।

---

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

लेकिन टीसीपी एक द्वि-दिशात्मक संचार प्रोटोकॉल है, जिसका अर्थ है कि अंत में डेटा को मज़बूती से भेजने में सक्षम होना चाहिए। दोनों पक्षों को आईएसएन स्थापित करने की आवश्यकता है, और दोनों पक्षों को दूसरे के आईएसएन को स्वीकार करने की आवश्यकता है।

तो वास्तव में, आपके पास दो तरफा हैंडशेक का वर्णन है, लेकिन प्रत्येक दिशा में । इसलिए, चार घटनाएं घटती हैं। और फिर, मध्य दो झंडे एक ही पैकेट में होते हैं। के रूप में इस तरह के तीन पैकेट एक पूर्ण टीसीपी कनेक्शन दीक्षा प्रक्रिया में शामिल हैं।

Comments

हमें ISNs की आवश्यकता क्यों है? मनुष्य को इसकी आवश्यकता नहीं है, कंप्यूटर क्यों करते हैं? क्या इसका कोई प्रमाण है, या क्या हम उनके पास सिर्फ इसलिए हैं क्योंकि वे सुविधाजनक हैं?

— मेहरदाद 20

@ मेहरदाद: ठीक से काम करने (या वास्तव में) के लिए आपको रिट्रांसमिशन के लिए अनुक्रम संख्या की आवश्यकता होती है। अनुक्रम भविष्यवाणी हमलों के कारण ISN शून्य नहीं हो सकता ।

— केविन

@ मेहरदाद चैट रूम में 'वास्तविक समय' होना जरूरी नहीं है, हम एक दूसरे के लिए संदेश छोड़ सकते हैं। इसका कारण मैंने इसे कहीं और निर्देशित करने के लिए सोचा क्योंकि आप अब एक अलग सवाल पूछ रहे हैं। ओपी ने पूछा "यह 2 के बजाय 3 तरह से हैंडशेक क्यों है", लेकिन अब आप सवाल कर रहे हैं कि "हमें सीक्वेंस नंबरों की आवश्यकता क्यों है", जो अलग है। इस सूत्र को पटरी से उतारने के बजाय, मुझे लगा कि हमें चैट में दूसरे प्रश्न पर चर्चा करनी चाहिए। वैकल्पिक रूप से , आप एक नया प्रश्न पोस्ट कर सकते हैं, मुझे यकीन है कि यह कुछ अच्छे उत्तरों को शुद्ध करेगा।

— एडी

शानदार, संक्षिप्त जवाब। "ACK SYN" पढ़ना मौलिक रूप से गलत लगता है, लेकिन आपने यह भी समझाया कि +1।

— लीलिएन्थल

के अनुसार आरएफसी 793, ट्रांसमिशन कंट्रोल प्रोटोकॉल : " तीन तरह हाथ मिलाना के लिए सिद्धांत कारण भ्रम पैदा से पुराने डुप्लीकेट कनेक्शन पहल को रोकने के लिए है। "

— रॉन Maupin

Answer 2

क्योंकि दोनों पार्टियों की जरूरत है तीन तरह हाथ मिलाना आवश्यक है syn chronize उनके खंड अनुक्रम उनके प्रसारण के दौरान इस्तेमाल किया संख्या। इस के लिए, उनमें से प्रत्येक के लिए भेजता है (बदले में) एक यादृच्छिक मान पर सेट एक दृश्य संख्या के साथ एक SYN खंड n है, जो तब है पावती करने के लिए सेट एक दृश्य संख्या के साथ एक एसीके खंड के माध्यम से अन्य पार्टी द्वारा nowledged n + 1 ।

Comments

पावती की आवश्यकता क्यों है?

— पाओलो एबरमन

@ Pa @loEbermann: क्योंकि अन्यथा सर्वर को इस बात का कोई अंदाजा नहीं है कि क्लाइंट को कभी SYN प्राप्त हुआ, और यह महत्वपूर्ण है कि क्लाइंट को वह प्राप्त हो।

— मूविंग डक

@ Pa @loEbermann और इसे साबित करने के लिए, ACK कदम को [X + 1] के साथ स्वीकार करना है। - Eddieउसके जवाब से टिप्पणी से उद्धृत ।

— smwikipedia

Answer 3

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

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

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

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

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

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

Comments

यह असत्य है: "एक एसीके (जो केवल एसवाईएन के जवाब में भेजा जाता है, और इस तरह यह साबित होता है कि एसवाईएन के माध्यम से मिला)।" प्रत्येक छोर से भेजे गए पहले पैकेट में केवल SYN ध्वज सेट होता है, और 3-तरह के हैंडशेक के पहले पैकेट के अलावा सभी पैकेटों में ACK ध्वज सेट होता है। पहला पैकेट ACK नहीं हो सकता क्योंकि दूसरी पार्टी ने अभी तक SYNed नहीं किया है, लेकिन पहले पैकेट के बाद हर पैकेट को ACK जो भी पहले से दूसरे छोर से प्राप्त हुआ है, चाहे कोई भी डेटा वापस भेजा जाए या नहीं।

— मोंटी हार्डर

धन्यवाद। रिकॉर्डिंग: SYK के जवाब में भेजे जाने के बजाय ACK को एक बार SYN के माध्यम से भेजे जाने के बाद भेजा जाता है।

— स्पूनिएस्ट

यह सबसे अच्छा जवाब है जो तार्किक रूप से समझा सकता है कि हमें तीसरे संदेश की आवश्यकता क्यों है। धन्यवाद, चम्मच।

— पार्थ पटेल

Answer 4

दरअसल, टीसीपी कनेक्शन स्थापित करने का एकमात्र साधन 3-वे हैंडशेक नहीं है। एक साथ SYN एक्सचेंज की अनुमति भी है: http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm

इसे एक तरह से डबल 2-वे हैंडशेक के रूप में देखा जा सकता है।

Comments

अच्छा बिंदु, हालांकि यह बहुत दुर्लभ है क्योंकि दोनों उपकरणों को एक ही स्रोत / गंतव्य पोर्ट का उपयोग करना होगा और दोनों उपकरणों को SYN भेजने से पहले दूसरे को SYN भेजना होगा। जब यह होता है, तब भी इसमें चार पैकेट भेजे जाते हैं, जो कि पारंपरिक 3-वे हैंडशेक द्वारा आवश्यक तीन पैकेटों से अधिक है; अंततः कम समग्र दक्षता की लागत पर समग्र समय के संदर्भ में स्थापित करने के लिए थोड़ा तेज़ होने की संभावना (केवल 33% अधिक पैकेट को प्रेषित करने की आवश्यकता होती है)।

— YLearn

Answer 5

टीसीपी कनेक्शन द्विदिश है। इसका मतलब यह है कि यह वास्तव में एक तरफ़ा कनेक्शन की एक जोड़ी है। सर्जक SYN भेजता है, उत्तरदाता ACK भेजता है: एक सिम्प्लेक्स कनेक्शन शुरू होता है। "फिर" उत्तरदाता SYN भेजता है, सर्जक ACK भेजता है: एक और सिम्प्लेक्स कनेक्शन शुरू होता है। दो सिंप्लेक्स कनेक्शन एक डुप्लेक्स टीसीपी सत्र बनाते हैं, सहमत हैं? इसलिए तार्किक रूप से इसमें चार चरण शामिल हैं; लेकिन क्योंकि SYN और ACK झंडे टीसीपी हैडर के अलग-अलग "फ़ील्ड" हैं, उन्हें एक साथ सेट किया जा सकता है - दूसरा और तीसरा चरण (चार में से) संयुक्त हैं, इसलिए तकनीकी रूप से तीन पैकेट एक्सचेंज हैं। प्रत्येक सिम्प्लेक्स (आधा-) कनेक्शन 2-तरफा विनिमय का उपयोग करता है, जैसा कि आपने प्रस्तावित किया था।

Answer 6

यदि सर्वर और क्लाइंट कनेक्शन बनाना चाहते हैं, तो उन्हें चार चीजों की पुष्टि करने की आवश्यकता है:

1. सर्वर को यह पुष्टि करने की आवश्यकता है कि वह ग्राहक से पैकेट प्राप्त कर सकता है

2. क्लाइंट को यह पुष्टि करने की आवश्यकता है कि वह सर्वर से पैकेट प्राप्त कर सकता है

3. क्लाइंट को किसी चीज़ की पुष्टि करने की आवश्यकता होती है: सर्वर क्लाइंट से पैकेट प्राप्त कर सकता है

4. सर्वर को एक चीज़ की पुष्टि करने की आवश्यकता है: क्लाइंट को सर्वर से पैकेट प्राप्त हो सकता है

बाद Client ------SYN-----> Server, नियम 1 की पुष्टि की जाती है।

बाद Client <---ACK/SYN---- Server, नियम 2 और 3 की पुष्टि की जाती है।

तो, नियम 4 की पुष्टि करने के लिए तीसरे पैकेट की आवश्यकता है।

Answer 7

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

पिछले उत्तर केवल पहले क्रम में यादृच्छिक अनुक्रम संख्या आदि की आवश्यकता पर चर्चा किए बिना प्रणाली का वर्णन करते हैं। मूल प्रश्न खुद टीसीपी के डिजाइन के बारे में था - जाहिर है अगर आप टीसीपी प्रोटोकॉल का उपयोग करते हैं तो आपको तीन संदेशों की आवश्यकता होती है क्योंकि वह प्रोटोकॉल है। लेकिन पहली बार में टीसीपी को इस तरह से डिजाइन क्यों किया गया था?

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

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

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

टीसीपी अक्षमता के आसपास काम करने के लिए, हम HTTP 1.1 जैसे प्रोटोकॉल का उपयोग करते हैं जो कई अनुरोधों के लिए एक ही कनेक्शन का पुन: उपयोग कर सकते हैं, और इस तरह टीसीपी हैंडशेक से बचें जो पहली जगह में आवश्यक नहीं था।

लेकिन Http 1.1 अपेक्षाकृत नया है। और एसएसएल / टीएलएस को पीकेआई एल्गोरिदम की लागत के कारण सत्र से पुन: उपयोग करने का एक तरीका चाहिए था। ताकि प्रोटोकॉल में अपना स्वयं का सत्र पुन: उपयोग तंत्र शामिल हो जो कि एचटीटीपी 1.1 के शीर्ष पर चलता है जो टीसीपी के शीर्ष पर चलता है।

सॉफ्टवेयर के साथ ऐसा ही है। कीचड़ पर ठगना जो संयुक्त होने पर, एक स्वीकार्य परिणाम उत्पन्न करता है।

Comments

OSI लेयर -4 (जैसे HTTP, एफ़टीपी, आदि) के ऊपर कुछ भी स्पष्ट रूप से यहाँ विषय से दूर है। परतों 1 से 4 में, क्लाइंट / सर्वर जैसी कोई चीज नहीं है। टीसीपी साथियों के बीच एक संबंध है। हां, ऊपरी परत प्रोटोकॉल एक ग्राहक / सर्वर संबंध बनाते हैं, लेकिन यहां ऑफ विषय है।

— रॉन Maupin

वैसे, HTTP टीसीपी का उपयोग करता है, इसलिए टीसीपी हैंडशेक अभी भी आवश्यक है। RFC 793 पठन को नियंत्रित करें कि क्यों न करें। HTTP जैसे प्रोटोकॉल को बहुसंकेतन करने के लिए एप्लिकेशन की आवश्यकता होती है जो टीसीपी सामान्य रूप से आवेदन के लिए करेगा।

— रॉन Maupin

@RonMaupin मूल प्रश्न क्यों था? और इसका उत्तर एक उपयोग के मामले का समर्थन करना है जो अभ्यास में ऊपरी स्तर की परतों द्वारा कभी भी उपयोग नहीं किया जाता है। इसलिए, बहुत प्रासंगिक लगता है।

— टंटेबल

@RonMaupin हाँ, HTTP टीसीपी का उपयोग करता है। जिसे मैंने स्पष्ट किया है, धन्यवाद। लेकिन यह किसी भी गहरे अर्थ में TCP हैंडशेक को आवश्यक नहीं बनाता है।

— टंटेबल

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

— रॉन Maupin

Answer 8

एडी के उत्तर को पढ़ने के बाद (सही के रूप में स्वीकार किया गया), अभी भी सवाल हैं कि 1 होस्ट ISN को यादृच्छिक संख्याओं के साथ असाइन नहीं कर सकता है और दूसरा इसे स्वीकार करता है। 3-वे हैंडशेक का उपयोग करने का वास्तविक कारण आधे कनेक्शन से बचना है । 2-वे हैंडशेक में आधा कनेक्शन परिदृश्य:
1) क्लाइंट --- SYN -> सर्वर
2) क्लाइंट अपना दिमाग बदलता है और अब और कनेक्ट नहीं करना चाहता है
3) क्लाइंट <-X-ACK-- सर्वर // ACK खो गया था
सर्वर को SYN नहीं दिखाई देता, इसलिए वह सोचता है कि क्लाइंट को उसका ACK मिल गया और कनेक्शन स्थापित हो गया। परिणामस्वरूप सर्वर में कनेक्शन होता है जो कभी बंद नहीं होगा

Comments

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

— रॉन Maupin

@RonMaupin तब मान लेते हैं कि एसीके पैकेट खो गया था।

— सांझर येलेवोव

यदि एसीके खो गया है, तो चरण 1 में शुरू किया गया कनेक्शन समय समाप्त हो जाएगा। RFC 793 में आरेखों सहित सभी प्रकार के परिदृश्यों की पूरी व्याख्या है।

— रॉन Maupin

@RonMaupin मेरा मतलब है कि अगर मेरे पद से परिदृश्य समान रहे, केवल एक चीज जो बदल गई, वह एसीके खो गया।

— सांझर येलेवोव

यह सब RFC में है। कनेक्शन खुला होने तक, प्राप्त किसी भी ट्रैफ़िक का परिणाम एक आरएसटी होगा। तीन-तरफ़ा हैंडशेक कनेक्शन मापदंडों पर बातचीत करता है, इसलिए "सर्वर" कुछ भी "क्लाइंट" को वापस नहीं भेज सकता है, लेकिन यह SYN / ACK है जब तक कि यह "क्लाइंट" से ACK प्राप्त नहीं करता है। यदि "क्लाइंट" SYN / ACK वापस "क्लाइंट" खो जाता है, तो "सर्वर" फिर से कोशिश करेगा। आरएफसी यह सब समझाती है।

— रॉन Maupin