प्रसारण नियंत्रण प्रोटोकॉल

प्रसारण नियंत्रण प्रोटोकॉल
Communication protocol
Developer(s)	विंट सर्फ़ और बॉब कान
Introduction	1974
Based on	ट्रांसमिशन कंट्रोल प्रोग्राम
OSI layer	परिवहन परत (4)
RFC(s)	RFC 9293

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

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

ऐतिहासिक उत्पत्ति

मई 1974 में, विंट सर्फ़ और बॉब क्हान ने नेटवर्क नोड्स के बीच पैकेट बदली का उपयोग करके संसाधनों को साझा करने के लिए इंटरनेटवर्किंग प्रोटोकॉल का वर्णन किया।^[1] लेखक फ्रेंच साइक्लेड्स परियोजना से अवधारणाओं को नए नेटवर्क में सम्मलित करने के लिए जेरार्ड ले लान के साथ काम कर रहे थे।^[2] परिणामी प्रोटोकॉल की विशिष्टता (तकनीकी मानक), RFC 675 (इंटरनेट ट्रांसमिशन कंट्रोल प्रोग्राम की विशिष्टता), विंट सेर्फ़, योगेन दलाल और कार्ल सनशाइन द्वारा लिखा गया था, और दिसंबर 1974 में प्रकाशित हुआ था। इसमें इंटरनेट शब्द का पहला प्रमाणित उपयोग सम्मलित है, जो इंटरनेटवर्क के लिए शॉर्टहैंड के रूप में है।^[3]

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

2004 में, विंट सेर्फ़ और बॉब क्हान को टीसीपी/आईपी पर उनके मूलभूत कार्य के लिए ट्यूरिंग पुरस्कार मिला।^[4]^[5]

नेटवर्क फ़ंक्शन

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

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

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

टीसीपी समय पर वितरण के अतिरिक्त सटीक वितरण के लिए अनुकूलित है और आउट-ऑफ-ऑर्डर संदेशों या खोए संदेशों के पुन: प्रसारण की प्रतीक्षा करते समय अपेक्षाकृत लंबी देरी (सेकंड के क्रम में) हो सकती है। इसलिए, यह वास्तविक समय के अनुप्रयोगों जैसे आईपी पर आवाज के लिए विशेष रूप से उपयुक्त नहीं है। ऐसे अनुप्रयोगों के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल (यूडीपी) पर चलने वाले वास्तविक समय परिवहन प्रोटोकॉल (आरटीपी) जैसे प्रोटोकॉल सामान्यतः इसके अतिरिक्त अनुशंसित होते हैं।^[6] टीसीपी विश्वसनीय बाइट स्ट्रीम डिलीवरी सेवा है जो गारंटी देती है कि प्राप्त सभी बाइट समान होंगे और उसी क्रम में भेजे गए थे। चूंकि कई नेटवर्क द्वारा पैकेट स्थानांतरण विश्वसनीय नहीं है, इसलिए टीसीपी पुन: प्रसारण के साथ सकारात्मक पावती के रूप में जानी जाने वाली तकनीक का उपयोग करके इसे प्राप्त करता है। इसके लिए यह आवश्यक है कि प्राप्तकर्ता डेटा प्राप्त करते ही पावती (डेटा नेटवर्क) संदेश के साथ प्रतिक्रिया करे। प्रेषक प्रत्येक पैकेट का रिकॉर्ड रखता है जो वह भेजता है और पैकेट भेजे जाने के समय से टाइमर रखता है। यदि पावती प्राप्त करने से पहले टाइमर समाप्त हो जाता है तो प्रेषक पैकेट को फिर से प्रसारित करता है। पैकेट खो जाने या दूषित होने की स्थिति में टाइमर की आवश्यकता होती है।^[6]

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

टीसीपी खंड संरचना

ट्रांसमिशन कंट्रोल प्रोटोकॉल डेटा स्ट्रीम से डेटा को स्वीकार करता है, इसे चंक्स में विभाजित करता है, और टीसीपी हेडर जोड़ता है जो टीसीपी सेगमेंट बनाता है। टीसीपी खंड तब इंटरनेट प्रोटोकॉल (आईपी) डेटाग्राम में एनकैप्सुलेशन (नेटवर्किंग) होता है, और साथियों के साथ आदान-प्रदान होता है।^[7] टीसीपी पैकेट शब्द अनौपचारिक और औपचारिक उपयोग दोनों में प्रकट होता है, जबकि अधिक सटीक शब्दावली खंड में टीसीपी प्रोटोकॉल डेटा यूनिट (पीडीयू), डेटाग्राम को संदर्भित करता है।^[8]^: 5–6 IP PDU के लिए, और सूचना श्रंखला तल PDU के लिए फ़्रेम:

प्रक्रियाएं टीसीपी पर कॉल करके और तर्कों के रूप में डेटा के बफ़र्स पास करके डेटा संचारित करती हैं। टीसीपी इन बफ़र्स से डेटा को खंडों में संकुलित करता है और इंटरनेट मॉड्यूल पर कॉल करता है [उदा। आईपी] प्रत्येक खंड को गंतव्य टीसीपी तक पहुंचाने के लिए।REFERENCE FOR RFC9293 IS NOT DEFINED YET. You are invited to add it here.

टीसीपी सेगमेंट में सेगमेंट हेडर और डेटा सेक्शन होता है। सेगमेंट हेडर में 10 अनिवार्य फ़ील्ड और वैकल्पिक एक्सटेंशन फ़ील्ड (विकल्प, तालिका में गुलाबी पृष्ठभूमि) सम्मलित हैं। डेटा अनुभाग हेडर का अनुसरण करता है और एप्लिकेशन के लिए किया गया पेलोड डेटा है। सेगमेंट हेडर में डेटा सेक्शन की लंबाई निर्दिष्ट नहीं है; इसकी गणना आईपी हेडर में निर्दिष्ट कुल आईपी डेटाग्राम लंबाई से सेगमेंट हेडर और आईपी हेडर की संयुक्त लंबाई घटाकर की जा सकती है।

टीसीपी सेगमेंट हेडर
Offsets		0										1										2										3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
0	0	सोर्स पोर्ट																गंतव्य पोर्ट
4	32	अनुक्रम संख्या
8	64	पावती संख्या (यदि एसीसी सेट है)
12	96	डेटा ऑफसेट				सुरक्षित 0 0 0 0				CWR	ECE	URG	ACK	PSH	RST	SYN	FIN	विंडो Size
16	128	योग जांच करना																तत्काल सूचक (if URG set)
20	160	विकल्प (यदि डेटा ऑफ़सेट> 5. यदि आवश्यक हो तो "0" बिट्स के साथ अंत में पैडेड।)
⋮	⋮
56	448

स्रोत पोर्ट (16 बिट्स): भेजने वाले पोर्ट की पहचान करता है। डेस्टिनेशन पोर्ट (16 बिट्स): रिसीविंग पोर्ट की पहचान करता है।अनुक्रम संख्या (32 बिट्स): दोहरी भूमिका है:

* यदि एसवाईएन फ्लैग सेट (1) है, तो यह प्रारंभिक अनुक्रम संख्या है। वास्तविक पहले डेटा बाइट की अनुक्रम संख्या और संबंधित एसीके में स्वीकृत संख्या तब यह अनुक्रम संख्या प्लस 1 है।

* यदि एसवाईएन ध्वज स्पष्ट (0) है, तो यह वर्तमान सत्र के लिए इस खंड के पहले डेटा बाइट की संचित क्रम संख्या है।

पावती संख्या (32 बिट्स): यदि एसीके ध्वज सेट किया गया है तो इस फ़ील्ड का मान अगली अनुक्रम संख्या है जो एसीके के प्रेषक की अपेक्षा कर रहा है। यह सभी पूर्व बाइट्स (यदि कोई हो) की प्राप्ति को स्वीकार करता है। प्रत्येक छोर द्वारा भेजा गया पहला एसीके दूसरे छोर के प्रारंभिक अनुक्रम संख्या को ही स्वीकार करता है, किन्तु कोई डेटा नहीं। डेटा ऑफ़सेट (4 बिट्स): 32-बिट शब्द (कंप्यूटर आर्किटेक्चर) में टीसीपी हेडर के आकार को निर्दिष्ट करता है। हेडर का न्यूनतम आकार 5 शब्द है और अधिकतम 15 शब्द है, इस प्रकार न्यूनतम आकार 20 बाइट्स और अधिकतम 60 बाइट्स देता है, हेडर में 40 बाइट्स के विकल्प की अनुमति देता है। इस क्षेत्र का नाम इस तथ्य से मिलता है कि यह टीसीपी सेगमेंट की शुरुआत से लेकर वास्तविक डेटा तक की ऑफसेट भी है। आरक्षित (4 बिट्स): भविष्य में उपयोग के लिए और शून्य पर सेट होना चाहिए।

2003–2017 से, प्रायोगिक RFC 3540,ईसीएन-नोंसे द्वारा अंतिम बिट (हेडर के बिट 103) को NS (नॉनस सम) फ़्लैग के रूप में परिभाषित किया गया था।ईसीएन-नोंसे का व्यापक उपयोग कभी नहीं हुआ और RFC को ऐतिहासिक स्थिति में ले जाया गया।^[9]

झंडे (8 बिट्स): निम्नानुसार 8 1-बिट झंडे (नियंत्रण बिट्स) सम्मलित हैं:

CWR (1 बिट): कंजेशन विंडो रिड्यूस्ड (CWR) फ्लैग भेजने वाले होस्ट द्वारा यह इंगित करने के लिए सेट किया गया है कि इसे ECE फ्लैग सेट के साथ TCP सेगमेंट प्राप्त हुआ है और इसने कंजेशन कंट्रोल मैकेनिज्म में प्रतिक्रिया दी है।^{[lower-alpha 1]}
ECE (1 बिट): ECN-Echo की दोहरी भूमिका होती है, जो एसवाईएन ध्वज के मान पर निर्भर करता है। ये दर्शाता है:

यदि एसवाईएन फ़्लैग (1) सेट है, तो TCP पीयर स्पष्ट भीड़ अधिसूचना सक्षम है।
यदि एसवाईएन फ्लैग स्पष्ट (0) है, कि IP हेडर में कंजेशन एक्सपीरियंस्ड फ्लैग सेट (ECN=11) वाला पैकेट सामान्य ट्रांसमिशन के दौरान प्राप्त हुआ था।^{[lower-alpha 1]} यह टीसीपी प्रेषक को नेटवर्क कंजेशन (या आसन्न कंजेशन) के संकेत के रूप में कार्य करता है।

URG (1 बिट): इंगित करता है कि तत्काल सूचक क्षेत्र महत्वपूर्ण है
एसीके (1 बिट): इंगित करता है कि पावती क्षेत्र महत्वपूर्ण है। क्लाइंट द्वारा भेजे गए शुरुआती एसवाईएन पैकेट के बाद सभी पैकेटों में यह फ्लैग सेट होना चाहिए।
PSH (1 बिट): पुश फंक्शन। बफ़र किए गए डेटा को प्राप्त करने वाले एप्लिकेशन को पुश करने के लिए कहता है।
RST (1 बिट): कनेक्शन को रीसेट करें

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

FIN (1 बिट): प्रेषक से अंतिम पैकेट

विंडो आकार (16 बिट्स): प्राप्त विंडो का आकार, जो विंडो आकार इकाइयों की संख्या निर्दिष्ट करता है^{[lower-alpha 2]} कि इस खंड का प्रेषक वर्तमान में प्राप्त करने का इच्छुक है।^{[lower-alpha 3]} (देखना § फ्लो कंट्रोल और § विंडो स्केलिंग.)

अंततः, (16 बिट्स): 16-बिट चेकसम फील्ड का उपयोग टीसीपी हेडर, पेलोड और आईपी स्यूडो-हेडर की एरर चेक्ड के लिए किया जाता है। स्यूडो-हेडर में IPv4#सोर्स एड्रेस, IPv4#डेस्टिनेशन एड्रेस, TCP प्रोटोकॉल के लिए IP प्रोटोकॉल नंबरों की सूची (6) और TCP हेडर की लंबाई और पेलोड (बाइट्स में) सम्मलित हैं।

तत्काल सूचक (16 बिट्स): यदि यूआरजी ध्वज सेट किया गया है, तो यह 16-बिट फ़ील्ड अनुक्रम संख्या से ऑफ़सेट है जो अंतिम तत्काल डेटा बाइट दर्शाता है।

विकल्प (32 बिट्स की इकाइयों में परिवर्तनीय 0–320 बिट्स): इस फ़ील्ड की लंबाई डेटा ऑफ़सेट फ़ील्ड द्वारा निर्धारित की जाती है। विकल्पों में अधिकतम तीन क्षेत्र होते हैं: विकल्प-प्रकार (1 बाइट), विकल्प-लंबाई (1 बाइट), विकल्प-डेटा (चर)। विकल्प-प्रकार फ़ील्ड विकल्प के प्रकार को इंगित करता है और यह एकमात्र फ़ील्ड है जो वैकल्पिक नहीं है। विकल्प-प्रकार मान के आधार पर, अगले दो फ़ील्ड सेट किए जा सकते हैं। विकल्प-लंबाई विकल्प की कुल लंबाई को इंगित करता है, और विकल्प-डेटा में विकल्प से जुड़ा डेटा होता है, यदि लागू हो। उदाहरण के लिए, 1 का विकल्प-प्रकार बाइट इंगित करता है कि यह केवल पैडिंग के लिए उपयोग किया जाने वाला कोई ऑपरेशन विकल्प नहीं है, और इसके बाद कोई विकल्प-लंबाई या विकल्प-डेटा फ़ील्ड नहीं है। 0 का विकल्प-प्रकार का बाइट विकल्पों के अंत को चिह्नित करता है, और यह भी केवल बाइट है। अधिकतम खंड आकार विकल्प को इंगित करने के लिए 2 की विकल्प-प्रकार बाइट का उपयोग किया जाता है, और एमएसएस फ़ील्ड की लंबाई निर्दिष्ट करने वाली विकल्प-लंबाई बाइट द्वारा पीछा किया जाएगा। विकल्प-लंबाई दिए गए विकल्प फ़ील्ड की कुल लंबाई है, जिसमें विकल्प-प्रकार और विकल्प-लंबाई फ़ील्ड सम्मलित हैं। इसलिए जबकि MSS मान सामान्यतः दो बाइट्स में व्यक्त किया जाता है, विकल्प-लंबाई 4 होगी। उदाहरण के तौर पर, 0x05B4 के मान वाले MSS विकल्प फ़ील्ड को TCP विकल्प अनुभाग में (0x02 0x04 0x05B4) के रूप में कोडित किया गया है।; कुछ विकल्प केवल तभी भेजे जा सकते हैं जब एसवाईएन सेट हो; उन्हें नीचे दर्शाया गया है <कोड शैली = रंग:#000; पृष्ठभूमि:#सीसीसी; >[एसवाईएन ]. विकल्प-प्रकार और मानक लंबाई (विकल्प-प्रकार, विकल्प-लंबाई) के रूप में दी गई है।

विकल्प-प्रकार	विकल्प-लंबाई	विकल्प-डेटा	उद्देश्य	टिप्पणियाँ
0	—	—	विकल्प सूची का अंत
1	—	—	कोई ऑपरेशन नहीं	श्रेष्ठतर प्रदर्शन के लिए 32-बिट सीमाओं पर विकल्प फ़ील्ड को संरेखित करने के लिए इसका उपयोग किया जा सकता है।
2	4	SS	अधिकतम अनुभाग माप	देखे § Maximum segment size ^{[एसवाईएन ]}
3	3	S	विंडोज स्केल	देखे § Window scaling for details^[10] ^{[एसवाईएन ]}
4	2	—	चुनिंदा पावती की अनुमति है	देखे § Selective acknowledgments for detailsREFERENCE FOR RFC2018 IS NOT DEFINED YET. You are invited to add it here.^{[एसवाईएन ]}
5	N (10, 18, 26, or 34)	BBBB, EEEE, ...	चयनात्मक पावती (सैक )REFERENCE FOR RFC2018 IS NOT DEFINED YET. You are invited to add it here.	इन पहले दो बाइट्स के बाद 1-4 ब्लॉकों की एक सूची होती है, जिन्हें चुनिंदा रूप से स्वीकार किया जाता है, जिसे 32-बिट स्टार्ट/एंड पॉइंटर्स के रूप में निर्दिष्ट किया जाता है।
8	10	TTTT, EEEE	टाइमस्टैम्प और पिछले टाइमस्टैम्प की प्रतिध्वनि	विवरण के लिए § TCP टाइमस्टैम्प देखें^[11]

शेष विकल्प-प्रकार के मूल्य ऐतिहासिक, अप्रचलित, प्रयोगात्मक, अभी तक मानकीकृत नहीं हैं, या असाइन नहीं किए गए हैं। विकल्प संख्या असाइनमेंट IANA द्वारा बनाए रखा जाता है।^[12]

पैडिंग: टीसीपी हेडर पैडिंग का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि टीसीपी हेडर समाप्त होता है, और डेटा 32-बिट सीमा पर प्रारंभिक होता है। पैडिंग शून्य से बना है।REFERENCE FOR RFC9293 IS NOT DEFINED YET. You are invited to add it here.

प्रोटोकॉल ऑपरेशन

सरलीकृत टीसीपी राज्य आरेख। अधिक विस्तृत आरेखों के लिए TCP EFSM आरेख देखें, जिसमें स्थापित स्थिति पर विवरण सम्मलित है।

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

टीसीपी कनेक्शन ऑपरेटिंग सिस्टम द्वारा संसाधन के माध्यम से प्रबंधित किया जाता है जो संचार के लिए स्थानीय अंत-बिंदु, इंटरनेट सॉकेट का प्रतिनिधित्व करता है। टीसीपी कनेक्शन के जीवनकाल के दौरान, स्थानीय समापन बिंदु राज्य (कंप्यूटर विज्ञान) परिवर्तनों की श्रृंखला से गुजरता है:REFERENCE FOR RFC9293 IS NOT DEFINED YET. You are invited to add it here.

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

कनेक्शन स्थापना

इससे पहले कि कोई क्लाइंट किसी सर्वर से कनेक्ट करने का प्रयास करे, सर्वर को कनेक्शन के लिए इसे खोलने के लिए पहले पोर्ट को बांधना और सुनना चाहिए: इसे पैसिव ओपन कहा जाता है। बार पैसिव ओपन स्थापित हो जाने के बाद, क्लाइंट तीन-तरफ़ा (या 3-स्टेप) हैंडशेक का उपयोग करके सक्रिय ओपन प्रारंभिक करके कनेक्शन स्थापित कर सकता है:

एसवाईएन : सक्रिय ओपन क्लाइंट द्वारा सर्वर को एसवाईएन भेजकर किया जाता है। क्लाइंट खंड के अनुक्रम संख्या को यादृच्छिक मान A पर सेट करता है।
एसवाईएन -ACK: प्रतिक्रिया में, सर्वर एसवाईएन -एसीके के साथ उत्तर देता है। पावती संख्या प्राप्त अनुक्रम संख्या अर्थात A + 1 से से अधिक पर सेट है, और अनुक्रम संख्या जिसे सर्वर पैकेट के लिए चुनता है वह और यादृच्छिक संख्या है, बी।
ACK: अंत में, क्लाइंट सर्वर को एसीके वापस भेजता है। अनुक्रम संख्या प्राप्त पावती मान अर्थात A+1 पर सेट है, और पावती संख्या प्राप्त अनुक्रम संख्या अर्थात B+1 से अधिक पर सेट है।

चरण 1 और 2 दिशा के लिए क्रम संख्या को स्थापित और स्वीकार करते हैं। चरण 2 और 3 दूसरी दिशा के लिए क्रम संख्या को स्थापित और स्वीकार करते हैं। इन चरणों के पूरा होने के बाद, क्लाइंट और सर्वर दोनों को पावती मिल गई है और पूर्ण-द्वैध संचार स्थापित हो गया है।

कनेक्शन समाप्ति

कनेक्शन समाप्ति चरण चार-तरफ़ा हैंडशेक का उपयोग करता है, जिसमें कनेक्शन के प्रत्येक पक्ष स्वतंत्र रूप से समाप्त होते हैं। जब कोई समापन बिंदु अपने आधे कनेक्शन को रोकना चाहता है, तो वह फिन पैकेट भेजता है, जिसे दूसरा छोर एसीके के साथ स्वीकार करता है। इसलिए, विशिष्ट आंसू-डाउन के लिए प्रत्येक टीसीपी एंडपॉइंट से फिन और एसीके सेगमेंट की जोड़ी की आवश्यकता होती है। पहले एफआईएन भेजने वाले पक्ष ने अंतिम एसीके के साथ प्रतिक्रिया दी है, यह अंततः कनेक्शन बंद करने से पहले टाइमआउट की प्रतीक्षा करता है, जिसके दौरान स्थानीय बंदरगाह नए कनेक्शन के लिए अनुपलब्ध है; ट्रांज़िट में एसीके खो जाने की स्थिति में यह स्थिति TCP क्लाइंट को सर्वर को अंतिम पावती भेजने देती है। समय अवधि कार्यान्वयन-निर्भर है, किन्तु कुछ सामान्य मान 30 सेकंड, 1 मिनट और 2 मिनट हैं। समय समाप्त होने के बाद, क्लाइंट बंद स्थिति में प्रवेश करता है और स्थानीय पोर्ट नए कनेक्शन के लिए उपलब्ध हो जाता है।^[13]

3-तरफ़ा हैंडशेक द्वारा कनेक्शन को समाप्त करना भी संभव है, जब होस्ट A FIN भेजता है और होस्ट B FIN और एसीके के साथ उत्तर देता है (दो चरणों को में मिलाकर) और एसीके के साथ होस्ट A का उत्तर देता है।^[14] कुछ ऑपरेटिंग सिस्टम, जैसे Linux और HP-UX, हाफ-डुप्लेक्स क्लोज सीक्वेंस लागू करें। यदि होस्ट सक्रिय रूप से कनेक्शन बंद कर देता है, जबकि अभी भी अपठित इनकमिंग डेटा उपलब्ध है, तो होस्ट FIN के अतिरिक्त सिग्नल RST (किसी भी प्राप्त डेटा को खोना) भेजता है। यह आश्वस्त करता है कि टीसीपी एप्लिकेशन को पता है कि डेटा हानि हुई थी।REFERENCE FOR RFC1122 IS NOT DEFINED YET. You are invited to add it here.

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

संसाधन उपयोग

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

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

दोनों समापन बिंदुओं को अनजाने पैकेट और प्राप्त (किन्तु अपठित) डेटा के लिए स्थान आवंटित करना चाहिए।

डेटा ट्रांसफर

उपयोगकर्ता डेटाग्राम प्रोटोकॉल की तुलना में ट्रांसमिशन कंट्रोल प्रोटोकॉल कई प्रमुख विशेषताओं में भिन्न है:

आदेशित डेटा स्थानांतरण: गंतव्य होस्ट अनुक्रम संख्या के अनुसार खंडों को पुनर्व्यवस्थित करता है^[6]* खोए हुए पैकेटों का पुनर्प्रसारण: किसी भी संचयी धारा को स्वीकार नहीं किया जाता है, जिसे पुन: प्रेषित किया जाता है^[6]* त्रुटि मुक्त डेटा ट्रांसफर: दूषित पैकेट को खोया हुआ माना जाता है और फिर से भेजा जाता है^[15]
प्रवाह नियंत्रण: विश्वसनीय वितरण की गारंटी के लिए प्रेषक द्वारा डेटा स्थानांतरित करने की दर को सीमित करता है। रिसीवर प्रेषक को लगातार संकेत देता है कि कितना डेटा प्राप्त किया जा सकता है। जब प्राप्तकर्ता होस्ट का बफ़र भर जाता है, तो अगली पावती स्थानांतरण को निलंबित कर देती है और बफ़र में डेटा को संसाधित करने की अनुमति देती है।^[6]* संकुलन नियंत्रण: खोए हुए पैकेट (जमाव के कारण अनुमानित) डेटा वितरण दर में कमी को ट्रिगर करते हैं^[6]

विश्वसनीय संचरण

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

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

प्रेषक द्वारा खोए हुए डेटा का पता लगाने और उसे पुनः प्रेषित करने से विश्वसनीयता प्राप्त होती है। हानि की पहचान करने के लिए टीसीपी दो प्राथमिक तकनीकों का उपयोग करता है। रेट्रांस्मिशन टाइमआउट (आरटीओ) और डुप्लिकेट संचयी पावती (डुपएक्स)।

जब टीसीपी सेगमेंट को फिर से प्रेषित किया जाता है, तो यह मूल वितरण प्रयास के समान क्रम संख्या को बनाए रखता है। वितरण और तार्किक डेटा ऑर्डरिंग के इस सम्मिश्रण का अर्थ है कि, जब पुन: प्रसारण के बाद पावती प्राप्त होती है, तो प्रेषक यह नहीं बता सकता है कि मूल संचरण या पुन: प्रसारण को स्वीकार किया जा रहा है, तथाकथित पुनर्संचरण अस्पष्टता।^[16] पुनर्संचरण अस्पष्टता के कारण टीसीपी जटिलता उत्पन्न करता है।^[17]

डुपैक-आधारित पुनर्संचरण

यदि धारा में खंड (जैसे खंड संख्या 100) खो जाता है, तो रिसीवर उस खंड संख्या (100) से ऊपर के पैकेट को स्वीकार नहीं कर सकता क्योंकि यह संचयी एसीके का उपयोग करता है। इसलिए रिसीवर दूसरे डेटा पैकेट की प्राप्ति पर पैकेट 99 को फिर से स्वीकार करता है। यह डुप्लिकेट पावती पैकेट हानि के लिए संकेत के रूप में उपयोग की जाती है। अर्थात्, यदि प्रेषक को तीन डुप्लिकेट पावती प्राप्त होती हैं, तो यह अंतिम अस्वीकृत पैकेट को पुनः प्रेषित करता है। तीन की सीमा का उपयोग किया जाता है क्योंकि नेटवर्क डुप्लिकेट पावती के कारण सेगमेंट को पुन: व्यवस्थित कर सकता है। पुनर्क्रमित करने के कारण नकली पुन: प्रसारण से बचने के लिए इस सीमा का प्रदर्शन किया गया है।^[18] कुछ टीसीपी कार्यान्वयन प्राप्त किए गए सेगमेंट के बारे में स्पष्ट प्रतिक्रिया प्रदान करने के लिए चयनात्मक पावती (सैक s) का उपयोग करते हैं। यह टीसीपी की सही सेगमेंट को फिर से प्रसारित करने की क्षमता में काफी सुधार करता है।

यदि डुप्लिकेट पावती थ्रेशोल्ड से परे पुन: क्रमित किया जाता है, तो पुनर्संचरण अस्पष्टता नकली तेज़ पुन: प्रसारण और भीड़ से बचाव का कारण बन सकती है।^[19]

समयबाह्य-आधारित पुन: प्रसारण

जब कोई प्रेषक किसी खंड को प्रसारित करता है, तो यह पावती के आगमन के समय के रूढ़िवादी अनुमान के साथ टाइमर को आरंभ करता है। यदि टाइमर समाप्त हो जाता है, तो सेगमेंट को पिछले मूल्य के दोगुने के नए टाइमआउट थ्रेशोल्ड के साथ फिर से प्रसारित किया जाता है, जिसके परिणामस्वरूप घातीय बैकऑफ़ व्यवहार होता है। सामान्यतः , प्रारंभिक टाइमर मान है ${\text{smoothed RTT}}+\max(G,4\times {\text{RTT variation}})$ , कहाँ $G$ घड़ी की ग्रैन्युलैरिटी है।REFERENCE FOR RFC6298 IS NOT DEFINED YET. You are invited to add it here.^: 2 यह दोषपूर्ण या दुर्भावनापूर्ण तत्वों के कारण होने वाले अत्यधिक ट्रांसमिशन ट्रैफ़िक से सुरक्षा प्रदान करता है, जैसे कि मैन-इन-द-बीच अटैक |मैन-इन-द-मिडल डिनायल ऑफ़ सर्विस अटैक वर।

नुकसान की वसूली के लिए सटीक आरटीटी अनुमान महत्वपूर्ण हैं, क्योंकि यह प्रेषक को यह मानने की अनुमति देता है कि पर्याप्त समय बीतने के बाद अनजाने पैकेट खो गया है (अर्थात , आरटीओ समय का निर्धारण)।^[20] पुनर्संचारण अस्पष्टता प्रेषक के RTT के अनुमान को सटीक नहीं बना सकती है।^[20] परिवर्ती RTT वाले परिवेश में, नकली टाइमआउट हो सकता है:^[21] यदि RTT का अनुमान कम लगाया जाता है, तो RTO सक्रिय हो जाता है और अनावश्यक पुनःसंचारण और धीमी गति से प्रारंभ करता है। नकली पुनर्संचरण के बाद, जब मूल प्रसारण के लिए पावती आती है, तो प्रेषक को यह विश्वास हो सकता है कि वे पुनर्संचरण को स्वीकार कर रहे हैं और गलत तरीके से निष्कर्ष निकालते हैं, कि मूल संचरण और पुन: प्रसारण के बीच भेजे गए खंड खो गए हैं, जिससे आगे अनावश्यक पुन: प्रसारण हो सकता है। लिंक वास्तव में भीड़भाड़ वाला हो जाता है;^[22]^[23] चयनात्मक अभिस्वीकृति इस प्रभाव को कम कर सकती है।^[24] RFC 6298 निर्दिष्ट करता है कि RTT का आकलन करते समय कार्यान्वयनों को पुन: प्रेषित खंडों का उपयोग नहीं करना चाहिए।^[25] कर्ण का एल्गोरिद्म यह सुनिश्चित करता है कि आरटीओ को समायोजित करने से पहले स्पष्ट पावती मिलने तक प्रतीक्षा करके—आखिरकार— अच्छा आरटीटी अनुमान तैयार किया जाएगा।^[26] नकली पुन: प्रसारण के बाद, चूंकि, इस प्रकार की स्पष्ट पावती आने से पहले महत्वपूर्ण समय लग सकता है, अंतरिम में प्रदर्शन खराब हो सकता है।^[27] टीसीपी टाइमस्टैम्प भी आरटीओ की स्थापना में पुनर्संचरण अस्पष्टता समस्या का समाधान करते हैं,^[25] चूंकि वे जरूरी नहीं कि आरटीटी अनुमान में सुधार करें।^[28]

त्रुटि का पता लगाना

अनुक्रम संख्या रिसीवर को डुप्लिकेट पैकेटों को त्यागने और आउट-ऑफ-ऑर्डर पैकेटों को ठीक से अनुक्रमित करने की अनुमति देती है। पावती प्रेषकों को यह निर्धारित करने की अनुमति देती है कि खोए हुए पैकेटों को कब पुनः प्रेषित किया जाए।

शुद्धता सुनिश्चित करने के लिए चेकसम फ़ील्ड सम्मलित है; देखना § चेकसम गणना जानकारी के लिए। टीसीपी चेकसम आधुनिक मानकों द्वारा कमजोर जांच है और सामान्यतः टीसीपी और आईपी दोनों के नीचे परत 2 पर चक्रीय अतिरेक जांच अखंडता जांच के साथ जोड़ा जाता है, जैसे कि पॉइंट-टू-पॉइंट प्रोटोकॉल या ईथरनेट फ्रेम में उपयोग किया जाता है। चूंकि, सीआरसी-संरक्षित हॉप्स के बीच पैकेट में त्रुटियों का परिचय सामान्य है और 16-बिट टीसीपी चेकसम इनमें से अधिकतर को पकड़ लेता है।^[29]

प्रवाह नियंत्रण

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

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

टीसीपी अनुक्रम संख्या और विंडोज़ प्राप्त करना घड़ी की प्रकार बहुत अधिक व्यवहार करता है। प्राप्त विंडो हर बार शिफ्ट हो जाती है जब रिसीवर प्राप्त करता है और डेटा के नए खंड को स्वीकार करता है। बार जब यह अनुक्रम संख्याओं से बाहर हो जाता है, तो अनुक्रम संख्या 0 पर वापस आ जाती है।

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

यदि कोई रिसीवर आने वाले डेटा को छोटी वृद्धि में संसाधित कर रहा है, तो वह बार-बार छोटी सी प्राप्त विंडो का विज्ञापन कर सकता है। इसे मूर्खतापूर्ण खिड़की सिंड्रोम के रूप में संदर्भित किया जाता है, क्योंकि टीसीपी हेडर के अपेक्षाकृत बड़े ओवरहेड को देखते हुए टीसीपी खंड में केवल कुछ बाइट डेटा भेजना अक्षम है।

भीड़ नियंत्रण

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

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

टीसीपी के आधुनिक कार्यान्वयन में चार आपस में जुड़े हुए एल्गोरिदम हैं: टीसीपी कंजेशन कंट्रोल # स्लो स्टार्ट, टीसीपी भीड़ से बचाव एल्गोरिथ्म, तेजी से पुन: प्रेषित और तेजी से पुनःप्राप्ति ।REFERENCE FOR RFC5681 IS NOT DEFINED YET. You are invited to add it here.

इसके अलावा, प्रेषक रेट्रांस्मिशन टाइमआउट (आरटीओ) का उपयोग करते हैं जो प्रेषक और रिसीवर के बीच अनुमानित राउंड ट्रिप समय (आरटीटी) के साथ-साथ इस राउंड-ट्रिप समय में अंतर पर आधारित होता है।REFERENCE FOR RFC6298 IS NOT DEFINED YET. You are invited to add it here. आरटीटी के आकलन में बारीकियां हैं। उदाहरण के लिए, प्रेषकों को पुनः प्रेषित पैकेटों के लिए RTT नमूनों की गणना करते समय सावधान रहना चाहिए; सामान्यतः वे कर्ण के एल्गोरिदम या टीसीपी टाइमस्टैम्प का उपयोग करते हैं।REFERENCE FOR RFC7323 IS NOT DEFINED YET. You are invited to add it here. इन अलग-अलग आरटीटी नमूनों का समय के साथ औसत किया जाता है ताकि जैकबसन के एल्गोरिथम का उपयोग करके स्मूथ राउंड ट्रिप टाइम (एसआरटीटी) बनाया जा सके। यह SRTT मान वह है जो राउंड-ट्रिप समय अनुमान के रूप में उपयोग किया जाता है।

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

अधिकतम खंड आकार

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

एमएसएस घोषणा को एमएसएस वार्ता भी कहा जा सकता है, किन्तु कड़ाई से बोलते हुए, एमएसएस पर बातचीत नहीं की जाती है। टीसीपी कनेक्शन में डेटा प्रवाह की दो दिशाओं के लिए एमएसएस के दो पूरी प्रकार से स्वतंत्र मूल्यों की अनुमति है,REFERENCE FOR RFC1122 IS NOT DEFINED YET. You are invited to add it here.'REFERENCE FOR RFC9293 IS NOT DEFINED YET. You are invited to add it here. इसलिए द्विदिश कनेक्शन के लिए सामान्य एमएसएस कॉन्फ़िगरेशन पर सहमत होने की कोई आवश्यकता नहीं है।

चुनिंदा स्वीकृतियां

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

इस समस्या को कम करने के लिए टीसीपी चयनात्मक पावती (सैक ) विकल्प को नियोजित करता है, जिसे 1996 में RFC 2018 में परिभाषित किया गया था, जो रिसीवर को सही ढंग से प्राप्त किए गए पैकेटों के बंद ब्लॉकों को स्वीकार करने की अनुमति देता है, साथ ही अनुक्रम संख्या के अंतिम अनुक्रम संख्या के तुरंत बाद। मूल टीसीपी पावती के रूप में अंतिम सन्निहित बाइट क्रमिक रूप से प्राप्त हुई। पावती में कई सैक ब्लॉक सम्मलित हो सकते हैं, जहां प्रत्येक सैक ब्लॉक को ब्लॉक के लेफ्ट एज (ब्लॉक की पहली अनुक्रम संख्या) और ब्लॉक के राइट एज (ब्लॉक के अंतिम अनुक्रम संख्या के तुरंत बाद अनुक्रम संख्या) द्वारा व्यक्त किया जाता है। ), ब्लॉक के साथ सन्निहित सीमा होती है जिसे रिसीवर सही ढंग से प्राप्त करता है। ऊपर दिए गए उदाहरण में, रिसीवर 2,000 के संचयी एसीके मान के साथ एसीके सेगमेंट और अनुक्रम संख्या 3,000 और 11,000 के साथ सैक विकल्प हेडर भेजेगा। प्रेषक तदनुसार अनुक्रम संख्या 2,000 से 2,999 के साथ केवल दूसरे खंड को पुनः प्रेषित करेगा।

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

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

चयनात्मक अभिस्वीकृति 'पाखण्डी' हो सकती है, जहां रिसीवर एकतरफा रूप से चुनिंदा स्वीकृत डेटा को छोड़ देता है। RFC 2018 ने इस प्रकार के व्यवहार को हतोत्साहित किया, किन्तु इसे प्रतिबंधित नहीं किया ताकि रिसीवर्स को रेनेजिंग का विकल्प दिया जा सके, उदाहरण के लिए, वे बफर स्पेस से बाहर हो गए।^[30] पाखण्डी होने की संभावना प्रेषकों और प्राप्तकर्ताओं दोनों के लिए कार्यान्वयन जटिलता की ओर ले जाती है, और प्रेषक पर मेमोरी लागत भी लगाती है।^[31]

विंडो स्केलिंग

उच्च-बैंडविड्थ नेटवर्क के अधिक कुशल उपयोग के लिए, बड़े टीसीपी विंडो आकार का उपयोग किया जा सकता है। 16-बिट टीसीपी विंडो आकार क्षेत्र डेटा के प्रवाह को नियंत्रित करता है और इसका मान 65,535 बाइट्स तक सीमित है। चूंकि आकार क्षेत्र को इस सीमा से अधिक विस्तारित नहीं किया जा सकता है, स्केलिंग कारक का उपयोग किया जाता है। टीसीपी विंडो स्केल विकल्प, जैसा कि आरएफसी 1323 में परिभाषित किया गया है, विकल्प है जिसका उपयोग अधिकतम विंडो आकार को 1 गीगाबाइट तक बढ़ाने के लिए किया जाता है। टीसीपी ट्यूनिंग के लिए इन बड़े विंडो आकारों तक स्केलिंग आवश्यक है।

विंडो स्केल विकल्प का उपयोग केवल टीसीपी 3-वे हैंडशेक के दौरान किया जाता है। विंडो स्केल मान 16-बिट विंडो आकार फ़ील्ड को व्याख्या करते समय बाईं ओर शिफ्ट करने के लिए बिट्स की संख्या का प्रतिनिधित्व करता है। स्वतंत्र रूप से प्रत्येक दिशा के लिए विंडो स्केल मान को 0 (कोई बदलाव नहीं) से 14 तक सेट किया जा सकता है। विंडो स्केलिंग को किसी भी दिशा में सक्षम करने के लिए दोनों पक्षों को अपने एसवाईएन सेगमेंट में विकल्प भेजना होगा।

कुछ राउटर और पैकेट फायरवॉल ट्रांसमिशन के दौरान विंडो स्केलिंग फैक्टर को फिर से लिखते हैं। यह अलग-अलग टीसीपी विंडो आकार ग्रहण करने के लिए पक्षों को भेजने और प्राप्त करने का कारण बनता है। परिणाम गैर-स्थिर यातायात है जो बहुत धीमा हो सकता है। दोषपूर्ण राउटर के पीछे कुछ साइटों पर समस्या दिखाई दे रही है।^[32]

टीसीपी टाइमस्टैम्प

टीसीपी टाइमस्टैम्प, 1992 में आरएफसी 1323 में परिभाषित, टीसीपी को यह निर्धारित करने में मदद कर सकता है कि पैकेट किस क्रम में भेजे गए थे। टीसीपी टाइमस्टैम्प सामान्य रूप से सिस्टम क्लॉक से संरेखित नहीं होते हैं और कुछ यादृच्छिक मान से प्रारंभिक होते हैं। कई ऑपरेटिंग सिस्टम प्रत्येक बीता हुआ मिलीसेकंड के लिए टाइमस्टैम्प बढ़ा देंगे; चूँकि, RFC केवल यह बताता है कि टिक आनुपातिक होना चाहिए।

दो टाइमस्टैम्प फ़ील्ड हैं:

4-बाइट प्रेषक टाइमस्टैम्प मान (मेरा टाइमस्टैम्प)
4-बाइट प्रतिध्वनि उत्तर टाइमस्टैम्प मान (आपसे प्राप्त सबसे हाल का टाइमस्टैम्प)।

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

साथ ही, ईफेल डिटेक्शन एल्गोरिदम टीसीपी टाइमस्टैम्प का उपयोग यह निर्धारित करने के लिए करता है कि क्या रेट्रांस्मिशन हो रहे हैं क्योंकि पैकेट खो गए हैं या बस ऑर्डर से बाहर हैं।^[33] लिनक्स में टीसीपी टाइमस्टैम्प डिफ़ॉल्ट रूप से सक्षम हैं,^[34] और विंडोज सर्वर 2008, 2012 और 2016 में डिफ़ॉल्ट रूप से अक्षम।^[35] हाल के आंकड़े बताते हैं कि विंडोज सर्वर 2008 के बाद से विंडोज सर्वर समर्थन छोड़ने के कारण टीसीपी टाइमस्टैम्प अपनाने का स्तर ~ 40% पर स्थिर हो गया है।^[36]

आउट-ऑफ़-बैंड डेटा

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

अत्यावश्यक सूचक केवल दूरस्थ होस्ट पर प्रसंस्करण को बदलता है और नेटवर्क पर किसी भी प्रसंस्करण को तेज नहीं करता है। क्षमता अलग-अलग प्रणालियों पर अलग-अलग या खराब तरीके से लागू की जाती है या समर्थित नहीं हो सकती है। जहां यह उपलब्ध है, यह मान लेना समझदारी है कि OOB डेटा के केवल बाइट को विश्वसनीय रूप से संभाला जाएगा।^[37]^[38] चूंकि सुविधा का अधिकांशतः उपयोग नहीं किया जाता है, यह कुछ प्लेटफार्मों पर अच्छी प्रकार से परीक्षण नहीं किया गया है और उदाहरण के लिए भेद्यता (कंप्यूटिंग), विनन्यूक से जुड़ा हुआ है।

जबरदस्ती डेटा वितरण

सामान्यतः, टीसीपी डेटा के पूरे पैकेट भेजने के लिए 200 एमएस की प्रतीक्षा करता है (नागल का एल्गोरिथम छोटे संदेशों को पैकेट में समूहित करने की कोशिश करता है)। फ़ाइल स्थानांतरण के दौरान लगातार दोहराए जाने पर यह प्रतीक्षा छोटी, किन्तु संभावित रूप से गंभीर देरी पैदा करती है। उदाहरण के लिए, सामान्य सेंड ब्लॉक 4 KB होगा, सामान्य MSS 1460 है, इसलिए 2 पैकेट 10 Mbit/s ईथरनेट पर ~1.2 ms लेते हुए निकलते हैं, जिसके बाद तीसरा 197 ms पॉज़ के बाद शेष 1176 ले जाता है क्योंकि TCP पूर्ण बफ़र की प्रतीक्षा कर रहा है। टेलनेट के स्थितियों में, प्रत्येक उपयोगकर्ता कीस्ट्रोक को सर्वर द्वारा वापस प्रतिध्वनित किया जाता है, इससे पहले कि उपयोगकर्ता इसे स्क्रीन पर देख सके। यह विलंब बहुत कष्टप्रद होगा।

नेटवर्क सॉकेट विकल्प सेट करना TCP_NODELAY डिफ़ॉल्ट 200 एमएस भेजने में देरी को ओवरराइड करता है। एप्लिकेशन प्रोग्राम इस सॉकेट विकल्प का उपयोग किसी वर्ण या वर्णों की पंक्ति लिखने के बाद आउटपुट भेजने के लिए बाध्य करने के लिए करते हैं।

RFC परिभाषित करता है PSH इस डेटा को प्राप्त करने वाले एप्लिकेशन तक तुरंत भेजने के लिए प्राप्तकर्ता टीसीपी स्टैक को संदेश के रूप में बिट पुश करें।^[6]बर्कले सॉकेट्स का उपयोग करके उपयोगकर्ता स्थान में इसे इंगित या नियंत्रित करने का कोई तरीका नहीं है; इसे केवल प्रोटोकॉल स्टैक द्वारा नियंत्रित किया जाता है।^[39]

भेद्यता

टीसीपी पर कई प्रकार से अटैक किया जा सकता है। 2009 में पहचाने गए मुद्दों के संभावित न्यूनीकरण के साथ-साथ टीसीपी के गहन सुरक्षा मूल्यांकन के परिणाम प्रकाशित किए गए थे।^[40] और 2012 के माध्यम से आईईटीएफ के भीतर पीछा किया गया था।^[41]

सेवा से वंचित

आईपी एड्रेस स्पूफिंग का उपयोग करके और बार-बार उलझे हुए पैकेट एसवाईएन पैकेट भेजकर, कई एसीके पैकेटों के बाद, अटैक वर सर्वर को बड़ी मात्रा में संसाधनों का उपभोग करने के लिए फर्जी कनेक्शन का ट्रैक रख सकते हैं। इसे एसवाईएन बाढ़ हमले के रूप में जाना जाता है। इस समस्या के प्रस्तावित समाधानों में एसवाईएन कुकीज़ और क्रिप्टोग्राफ़िक पहेलियाँ सम्मलित हैं, चूँकि एसवाईएन कुकीज़ अपनी स्वयं की कमजोरियों के सेट के साथ आती हैं।^[42] सॉकस्ट्रेस ऐसा ही अटैक है, जिसे सिस्टम संसाधन प्रबंधन से कम किया जा सकता है।^[43] Phrएसीके #66 में TCP पर्सिस्ट टाइमर के शोषण से जुड़े उन्नत DoS हमले का विश्लेषण किया गया था।^[44] PUSH और एसीके बाढ़ अन्य प्रकार हैं।^[45]

कनेक्शन अपहरण

अटैक वर जो टीसीपी सत्र को छिपाने में सक्षम है और पैकेट को पुनर्निर्देशित करता है, वह टीसीपी कनेक्शन को हाईजैक कर सकता है। ऐसा करने के लिए, अटैक वर चल रहे संचार से अनुक्रम संख्या सीखता है और गलत खंड बनाता है जो धारा में अगले खंड की प्रकार दिखता है। इस प्रकार के साधारण हाईजैक के परिणामस्वरूप पैकेट को छोर पर गलत तरीके से स्वीकार किया जा सकता है। जब प्राप्तकर्ता होस्ट कनेक्शन के दूसरी तरफ अतिरिक्त खंड को स्वीकार करता है, तो सिंक्रनाइज़ेशन खो जाता है। हाइजैकिंग को संकल्प आदर्श पत्र पता (एड्रेस रेजोल्यूशन प्रोटोकॉल) या रूटिंग हमलों के साथ जोड़ा जा सकता है जो पैकेट प्रवाह को नियंत्रित करने की अनुमति देता है, ताकि अपहृत टीसीपी कनेक्शन का स्थायी नियंत्रण प्राप्त किया जा सके।^[46] आरएफसी 1948 से पहले अलग आईपी पते का प्रतिरूपण करना मुश्किल नहीं था, जब प्रारंभिक अनुक्रम संख्या सरलता से अनुमान लगाया जा सकता था। इसने अटैक वर को एआरपी या रूटिंग हमलों को तैनात करने की आवश्यकता के बिना, पैकेट के अनुक्रम को आँख बंद करके भेजने की अनुमति दी, जो रिसीवर को अलग आईपी पते से आने का विश्वास होगा: यह सुनिश्चित करने के लिए पर्याप्त है कि प्रतिरूपित आईपी पते का वैध होस्ट नीचे है , या डिनायल-ऑफ-सर्विस हमलों का उपयोग करके इसे उस स्थिति में लाएं। यही कारण है कि प्रारंभिक क्रम संख्या अब यादृच्छिक रूप से चुनी जाती है।

टीसीपी वीटो

अटैक वर जो छिपकर सुन सकता है और भेजे जाने वाले अगले पैकेट के आकार का अनुमान लगा सकता है, वह रिसीवर को उपस्तिथा कनेक्शन को बाधित किए बिना दुर्भावनापूर्ण पेलोड स्वीकार करने का कारण बन सकता है। अटैक वर दुर्भावनापूर्ण पैकेट को अनुक्रम संख्या और अगले अपेक्षित पैकेट के पेलोड आकार के साथ इंजेक्ट करता है। जब वैध पैकेट अंततः प्राप्त हो जाता है, तो यह पहले से प्राप्त पैकेट के समान अनुक्रम संख्या और लंबाई पाया जाता है और चुपचाप सामान्य डुप्लिकेट पैकेट के रूप में गिरा दिया जाता है - दुर्भावनापूर्ण पैकेट द्वारा वैध पैकेट को वीटो कर दिया जाता है। कनेक्शन हाइजैकिंग के विपरीत, कनेक्शन कभी भी डीसिंक्रनाइज़ नहीं होता है और दुर्भावनापूर्ण पेलोड स्वीकार किए जाने के बाद संचार सामान्य रूप से जारी रहता है। टीसीपी वीटो अटैक वर को संचार पर कम नियंत्रण देता है, किन्तु हमले को विशेष रूप से पहचान के लिए प्रतिरोधी बनाता है। एसीके स्टॉर्म से नेटवर्क ट्रैफिक में बड़ी वृद्धि से बचा जाता है। रिसीवर के लिए एकमात्र सबूत है कि कुछ गलत है, डुप्लिकेट पैकेट है, आईपी नेटवर्क में सामान्य घटना है। वीटो वाले पैकेट भेजने वाले को हमले का कोई सबूत नहीं दिखता.^[47] अन्य भेद्यता टीसीपी रीसेट अटैक है।

टीसीपी पोर्ट्स

टीसीपी कनेक्शन की पहचान स्रोत पते, स्रोत पोर्ट (कंप्यूटर नेटवर्किंग), गंतव्य पता, और गंतव्य पोर्ट (या समकक्ष, स्रोत और गंतव्य के लिए नेटवर्क सॉकेट की जोड़ी, जिनमें से प्रत्येक से बना है) के चार-टपल द्वारा की जाती है। पते और बंदरगाह का)।^[48]^[49] विभिन्न सेवाओं की पहचान करने के लिए, और होस्ट के बीच कई कनेक्शनों को मल्टीप्लेक्स करने की अनुमति देने के लिए पोर्ट नंबरों का उपयोग किया जाता है।^[50] टीसीपी 16-बिट पोर्ट नंबरों का उपयोग करता है, प्रत्येक स्रोत और गंतव्य पोर्ट के लिए 65,536 संभावित मानों का स्थान प्रदान करता है।^[51] पतों पर कनेक्शन पहचान की निर्भरता का अर्थ है कि टीसीपी कनेक्शन एकल नेटवर्क पथ से बंधे हैं; टीसीपी अन्य मार्गों का उपयोग नहीं कर सकता है जो मल्टीहोम होस्ट उपलब्ध हैं, और समापन बिंदु का पता बदलने पर कनेक्शन टूट जाता है।^[52]

पोर्ट नंबरों को तीन मूल श्रेणियों में वर्गीकृत किया गया है: प्रसिद्ध, पंजीकृत और गतिशील/निजी। जाने-माने पोर्ट इंटरनेट निरुपित नंबर प्राधिकरण (IANA) द्वारा असाइन किए जाते हैं और सामान्यतः सिस्टम-लेवल या रूट प्रोसेस द्वारा उपयोग किए जाते हैं। सर्वर के रूप में चलने वाले और कनेक्शन के लिए निष्क्रिय रूप से सुनने वाले प्रसिद्ध एप्लिकेशन सामान्यतः इन पोर्ट का उपयोग करते हैं। कुछ उदाहरणों में सम्मलित हैं: फाइल ट्रांसफर प्रोटोकॉल (20 और 21), सिक्योर शेल (22), टेलनेट (23), एसएमटीपी (25), एचटीटीपीएस|एसएसएल/टीएलएस पर एचटीटीपी (443), और एचटीटीपी (80)। नोट, नवीनतम मानक के रूप में, HTTP/3, QUIC का उपयोग TCP के अतिरिक्त ट्रांसपोर्ट के रूप में किया जाता है। पंजीकृत बंदरगाहों का उपयोग सामान्यतः अंतिम उपयोगकर्ता अनुप्रयोगों द्वारा सर्वर से संपर्क करते समय क्षणिक बंदरगाह स्रोत बंदरगाहों के रूप में किया जाता है, किन्तु वे उन नामित सेवाओं की पहचान भी कर सकते हैं जिन्हें किसी तीसरे पक्ष द्वारा पंजीकृत किया गया है। डायनेमिक/निजी पोर्ट का उपयोग अंतिम उपयोगकर्ता अनुप्रयोगों द्वारा भी किया जा सकता है, किन्तु ऐसा सामान्यतः कम होता है। गतिशील/निजी बंदरगाहों में किसी विशेष टीसीपी कनेक्शन के बाहर कोई अर्थ नहीं होता है।

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

विकास

टीसीपी जटिल प्रोटोकॉल है। चूँकि, जबकि महत्वपूर्ण सुधार किए गए हैं और वर्षों से प्रस्तावित हैं, इसका सबसे बुनियादी संचालन 1974 में इसके पहले विनिर्देश RFC 675 और सितंबर 1981 में प्रकाशित v4 विनिर्देश RFC 793 के बाद से महत्वपूर्ण रूप से नहीं बदला है। RFC 1122, इंटरनेट के लिए होस्ट आवश्यकताएँ होस्ट ने कई टीसीपी प्रोटोकॉल कार्यान्वयन आवश्यकताओं को स्पष्ट किया। RFC 7414 में 8 आवश्यक विनिर्देशों और 20 से अधिक दृढ़ता से प्रोत्साहित संवर्द्धन की सूची उपलब्ध है। इस सूची में RFC 2581, TCP कंजेशन कंट्रोल, हाल के वर्षों में सबसे महत्वपूर्ण TCP-संबंधित RFC में से है, अद्यतन एल्गोरिदम का वर्णन करता है जो अनुचित भीड़ से बचाता है। . 2001 में, RFC 3168 को स्पष्ट भीड़ अधिसूचना (स्पष्ट भीड़ अधिसूचना) का वर्णन करने के लिए लिखा गया था, भीड़ से बचाव सिग्नलिंग तंत्र।

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

टीसीपी इंटरएक्टिव (आईटीसीपी) ^[53] टीसीपी एक्सटेंशन में शोध प्रयास है जो एप्लिकेशन को टीसीपी इवेंट्स की सदस्यता लेने और हैंडलर घटकों को पंजीकृत करने की अनुमति देता है जो एप्लिकेशन-सहायता वाले भीड़ नियंत्रण सहित विभिन्न उद्देश्यों के लिए एप्लिकेशन लॉन्च कर सकते हैं।

मल्टीपाथ टीसीपी (एमपीटीसीपी) REFERENCE FOR RFC6182 IS NOT DEFINED YET. You are invited to add it here.'REFERENCE FOR RFC6824 IS NOT DEFINED YET. You are invited to add it here. IETF के भीतर सतत प्रयास है जिसका उद्देश्य संसाधनों के उपयोग को अधिकतम करने और अतिरेक को बढ़ाने के लिए TCP कनेक्शन को कई रास्तों का उपयोग करने की अनुमति देना है। वायरलेस नेटवर्क के संदर्भ में मल्टीपाथ टीसीपी द्वारा दी जाने वाली अतिरेक विभिन्न नेटवर्कों के साथ उपयोग को सक्षम बनाता है, जो उच्चतर थ्रूपुट और बेहतर हैंडओवर क्षमताओं को लाता है। मल्टीपाथ टीसीपी डेटासेंटर वातावरण में प्रदर्शन लाभ भी लाता है।^[54] संदर्भ कार्यान्वयन^[55] मल्टीपाथ टीसीपी का लिनक्स कर्नेल में विकास किया जा रहा है।^[56] Multipath TCP का उपयोग iPhones, iPads और Macs पर सिरी वॉइस रिकग्निशन एप्लिकेशन को सपोर्ट करने के लिए किया जाता है ^[57] टीसीपी क्रिप्ट जुलाई 2010 में टीसीपी में सीधे परिवहन-स्तर एन्क्रिप्शन प्रदान करने के लिए प्रस्तावित एक्सटेंशन है। इसे पारदर्शी रूप से काम करने के लिए डिज़ाइन किया गया है और इसके लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है। परिवहन परत सुरक्षा (एसएसएल) के विपरीत, टीसीपी क्रिप्ट स्वयं प्रमाणीकरण प्रदान नहीं करता है, किन्तु ऐसा करने के लिए एप्लिकेशन को सरल प्रिमिटिव प्रदान करता है। As of 2010^[update], पहला टीसीपी क्रिप्ट IETF ड्राफ्ट प्रकाशित किया गया है और कई प्रमुख प्लेटफॉर्मों के लिए कार्यान्वयन उपस्तिथ हैं।

टीसीपी फास्ट ओपन दो एंडपॉइंट्स के बीच लगातार टीसीपी कनेक्शन खोलने में तेजी लाने के लिए विस्तार है। यह क्रिप्टोग्राफ़िक कुकी का उपयोग करके तीन-तरफ़ा हैंडशेक को छोड़ कर काम करता है। यह T/TCP नामक पहले के प्रस्ताव के समान है, जिसे सुरक्षा मुद्दों के कारण व्यापक रूप से नहीं अपनाया गया था।^[58] टीसीपी फास्ट ओपन को 2014 में आरएफसी 7413 के रूप में प्रकाशित किया गया था।^[59] मई 2013 में प्रस्तावित, आनुपातिक दर में कमी (पीआरआर) Google इंजीनियरों द्वारा विकसित टीसीपी एक्सटेंशन है। PRR यह सुनिश्चित करता है कि रिकवरी के बाद TCP विंडो का आकार TCP कंजेशन नियंत्रण के जितना करीब हो सके धीमी शुरुआत थ्रेसहोल्ड जितना संभव हो सके।^[60] एल्गोरिदम को पुनर्प्राप्ति की गति में सुधार करने के लिए डिज़ाइन किया गया है और लिनक्स 3.2+ कर्नेल में डिफ़ॉल्ट भीड़ नियंत्रण एल्गोरिदम है।^[61]

बहिष्कृत प्रस्ताव

टीसीपी कुकी लेनदेन (टीसीपीसीटी) दिसंबर 2009 में प्रस्तावित विस्तार हैREFERENCE FOR RFC6013 IS NOT DEFINED YET. You are invited to add it here. सर्वरों को डिनायल-ऑफ़-सर्विस हमलों से सुरक्षित करने के लिए। एसवाईएन कुकीज़ के विपरीत, TCPCT विंडो स्केलिंग जैसे अन्य TCP एक्सटेंशन के साथ विरोध नहीं करता है। TCPCT को DNSSEC की आवश्यकताओं के कारण डिज़ाइन किया गया था, जहाँ सर्वरों को बड़ी संख्या में अल्पकालिक TCP कनेक्शनों को संभालना पड़ता है। 2016 में, टीसीपीसीटी को टीसीपी फास्ट ओपन के पक्ष में हटा दिया गया था। मूल RFC की स्थिति ऐतिहासिक में बदल दी गई थी।REFERENCE FOR RFC7805 IS NOT DEFINED YET. You are invited to add it here.

हार्डवेयर कार्यान्वयन

टीसीपी की प्रसंस्करण शक्ति आवश्यकताओं को दूर करने का तरीका इसके हार्डवेयर कार्यान्वयन का निर्माण करना है, जिसे व्यापक रूप से टीसीपी ऑफलोड इंजन (टीओई) के रूप में जाना जाता है। TOE की मुख्य समस्या यह है कि उन्हें कंप्यूटिंग सिस्टम में एकीकृत करना कठिन होता है, जिसके लिए कंप्यूटर या डिवाइस के ऑपरेटिंग सिस्टम में व्यापक बदलाव की आवश्यकता होती है। इस प्रकार के उपकरण को विकसित करने वाली कंपनी अलाक्रिटेक थी।

वायर इमेज और ऑसिफिकेशन

टीसीपी की तार छवि (नेटवर्किंग) ऑन-पाथ पर्यवेक्षकों को महत्वपूर्ण सूचना-एकत्रीकरण और संशोधन के अवसर प्रदान करती है, क्योंकि प्रोटोकॉल मेटाडेटा स्पष्ट पाठ में प्रसारित होता है।^[62]^[63] जबकि यह पारदर्शिता नेटवर्क ऑपरेटरों के लिए उपयोगी है^[64] और शोधकर्ता,^[65] प्रोटोकॉल मेटाडेटा से एकत्रित की गई जानकारी अंतिम-उपयोगकर्ता की गोपनीयता को कम कर सकती है।^[66] मेटाडेटा की इस दृश्यता और आघातवर्धनीयता के कारण टीसीपी का विस्तार करना मुश्किल हो गया है - प्रोटोकॉल ओसिफिकेशन का मामला - क्योंकि कोई भी मध्यवर्ती नोड ( 'मिडिलबॉक्स ') उस मेटाडेटा के आधार पर निर्णय ले सकता है या इसे संशोधित भी कर सकता है,^[67]^[68] एंड-टू-एंड सिद्धांत को तोड़ना।^[69] माप में पाया गया कि इंटरनेट पर तिहाई पथ कम से कम मध्यस्थ का सामना करते हैं जो टीसीपी मेटाडेटा को संशोधित करता है, और 6.5% पथ मध्यस्थों से हानिकारक ossifying प्रभाव का सामना करते हैं।^[70] बिचौलियों से एक्स्टेंसिबिलिटी खतरों से बचने के लिए एमपीटीसीपी के डिजाइन पर महत्वपूर्ण बाधाओं को रखा गया है,^[71]^[72] और बिचौलियों के कारण होने वाली कठिनाइयों ने वेब ब्राउज़र्स में टीसीपी फास्ट ओपन की तैनाती में बाधा उत्पन्न की है।^[73] ossification का अन्य स्रोत एंडपॉइंट्स पर टीसीपी कार्यों के संशोधन की कठिनाई है, सामान्यतः ऑपरेटिंग सिस्टम कर्नेल में^[74] या टीसीपी ऑफलोड इंजन के साथ हार्डवेयर में।^[75]

प्रदर्शन

जैसा कि टीसीपी विश्वसनीय बाइट स्ट्रीम के अमूर्त के साथ अनुप्रयोग प्रदान करता है, यह हेड-ऑफ़-लाइन ब्लॉकिंग से पीड़ित हो सकता है: यदि पैकेट पुनर्क्रमित करना या पैकेट हानि होती है और इसे फिर से भेजने की आवश्यकता होती है (और इस प्रकार आउट-ऑफ-ऑर्डर), क्रमिक रूप से बाद में डेटा धारा के भाग क्रमिक रूप से धारा के पूर्व भागों से पहले प्राप्त हो सकते हैं; चूँकि, बाद के डेटा का उपयोग सामान्यतः तब तक नहीं किया जा सकता जब तक कि पहले का डेटा प्राप्त नहीं हो जाता, जिससे नेटवर्क विलंबता हो जाती है। यदि कई स्वतंत्र उच्च-स्तरीय संदेश ही टीसीपी कनेक्शन पर एनकैप्सुलेशन (नेटवर्किंग) और समय विभाजन बहुसंकेतन हैं, तो हेड-ऑफ-लाइन ब्लॉकिंग पूर्ण-प्राप्त संदेश के प्रसंस्करण का कारण बन सकता है जिसे बाद में संदेश की डिलीवरी के लिए प्रतीक्षा करने के लिए भेजा गया था। जो पहले भेजा गया था।^[76] वेब ब्राउजर कई समानांतर कनेक्शन खोलकर हेड-ऑफ-लाइन ब्लॉकिंग को कम करने का प्रयास करते हैं। यह कनेक्शन स्थापित करने की लागत को बार-बार बढ़ाता है, साथ ही उन कनेक्शनों को समापन बिंदुओं पर ट्रैक करने के लिए आवश्यक संसाधनों को गुणा करता है।^[77] समानांतर कनेक्शन में साथ जानकारी एकत्र करने में सक्षम होने और देखी गई नेटवर्क स्थितियों के लिए अधिक तुरंत प्रतिक्रिया करने के अतिरिक्त दूसरे से स्वतंत्र रूप से काम करने वाले कंजेशन नियंत्रण भी होते हैं;^[78] यदि एकाधिक समांतर कनेक्शन खोले जाते हैं तो टीसीपी के आक्रामक प्रारंभिक प्रेषण पैटर्न भीड़ का कारण बन सकते हैं; और प्रति-कनेक्शन निष्पक्षता मॉडल इस दृष्टिकोण को अपनाने वाले अनुप्रयोगों द्वारा संसाधनों के एकाधिकार की ओर ले जाता है।^[79]

वेब उपयोगकर्ताओं द्वारा अनुभव किए गए विलंबता के लिए कनेक्शन स्थापना प्रमुख योगदानकर्ता है।^[80]^[81] डेटा भेजे जाने से पहले कनेक्शन स्थापना के दौरान टीसीपी का तीन-तरफा हैंडशेक आरटीटी विलंबता का परिचय देता है।^[81] लघु प्रवाहों के लिए, ये विलंब बहुत महत्वपूर्ण हैं।^[82] ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) को कनेक्शन स्थापना पर कुंजी विनिमय के लिए स्वयं के हैंडशेक की आवश्यकता होती है। स्तरित डिज़ाइन के कारण, टीसीपी हैंडशेक और टीएलएस हैंडशेक क्रमिक रूप से आगे बढ़ते हैं: टीसीपी हैंडशेक समाप्त होने तक टीएलएस हैंडशेक प्रारंभिक नहीं हो सकता है।^[83] टीसीपी पर टीएलएस 1.3 के साथ कनेक्शन स्थापित करने के लिए दो आरटीटी आवश्यक हैं।^[84] टीएलएस 1.3 कुछ परिस्थितियों में शून्य आरटीटी कनेक्शन की बहाली की अनुमति देता है, किन्तु, टीसीपी पर स्तरित होने पर, टीसीपी हैंडशेक के लिए अभी भी आरटीटी की आवश्यकता होती है, और यह प्रारंभिक कनेक्शन में सहायता नहीं कर सकता है; शून्य आरटीटी हैंडशेक क्रिप्टोग्राफ़िक चुनौतियां भी प्रस्तुत करते हैं, क्योंकि कुशल, रीप्ले-सुरक्षित और आगे सुरक्षित गैर-संवादात्मक कुंजी विनिमय खुला शोध विषय है।^[85] टीसीपी फास्ट ओपन कनेक्शन स्थापना के दौरान विलंबता के आरटीटी को हटाते हुए प्रारंभिक (अर्थात , एसवाईएन और एसवाईएन -ACK) पैकेट में डेटा के प्रसारण की अनुमति देता है।^[86] चूंकि, प्रोटोकॉल ऑसिफिकेशन के कारण टीसीपी फास्ट ओपन को तैनात करना मुश्किल हो गया है; 2020 में, किसी भी वेब ब्राउज़र ने डिफ़ॉल्ट रूप से इसका उपयोग नहीं किया।^[73]

टीसीपी थ्रूपुट पैकेट रीऑर्डरिंग से प्रभावित होता है। पुनर्क्रमित पैकेट डुप्लिकेट पावती भेजने का कारण बन सकते हैं, जो, यदि वे सीमा पार करते हैं, तो नकली पुन: प्रसारण और भीड़ नियंत्रण को ट्रिगर करेगा। ट्रांसमिशन व्यवहार भी कम सहज और अधिक बर्स्टी हो सकता है, क्योंकि रेंज की शुरुआत में पुनर्क्रमित पैकेट प्राप्त होने पर बड़ी रेंज को ही बार में स्वीकार किया जाता है (इसी प्रकार से हेड-ऑफ-लाइन ब्लॉकिंग अनुप्रयोगों को कैसे प्रभावित करता है)।^[87] Blanton & Allman (2002) ने पाया कि थ्रूपुट रीऑर्डरिंग की मात्रा से विपरीत रूप से संबंधित था, सीमा तक जहां सभी रीऑर्डरिंग नकली रीट्रांसमिशन को ट्रिगर करता है।^[88] रीऑर्डरिंग को कम करना प्रेषक की यह निर्धारित करने की क्षमता पर निर्भर करता है कि इसने नकली रीट्रांसमिशन भेजा है, और इसलिए रीट्रांसमिशन अस्पष्टता को हल करने पर।^[89] वास्तविक नुकसान से तेजी से रिकवरी के खिलाफ रीऑर्डरिंग-प्रेरित नकली रेट्रांस्मिशन ट्रेड ऑफ को कम करना।^[90]

चयनात्मक स्वीकृति थ्रूपुट को महत्वपूर्ण लाभ प्रदान कर सकती है; ब्रुएर्न, हेमन और झांग 1998 45% तक का लाभ मापा गया।^[91] सुधार में महत्वपूर्ण कारक यह है कि चयनात्मक अभिस्वीकृति अधिकांशतः नुकसान के बाद धीमी शुरुआत में जाने से बच सकती है और इसलिए उपलब्ध बैंडविड्थ का बेहतर उपयोग कर सकती है।^[92] चूंकि, टीसीपी केवल अनुक्रम संख्या के अधिकतम तीन ब्लॉकों को चुनिंदा रूप से स्वीकार कर सकता है। यह पुनर्संचरण दर को सीमित कर सकता है और इसलिए नुकसान की वसूली या अनावश्यक पुन: प्रसारण का कारण बन सकता है, विशेष रूप से उच्च-नुकसान वाले वातावरण में।^[93]^[94]

टीसीपी मूल रूप से वायर्ड नेटवर्क के लिए डिजाइन किया गया था। पैकेट हानि को नेटवर्क संकुलन का परिणाम माना जाता है और संकुलन खिड़की का आकार एहतियात के तौर पर नाटकीय रूप से कम हो जाता है। चूंकि, वायरलेस लिंक को लुप्त होने, छायांकन, हैंड ऑफ, हस्तक्षेप (संचार) और अन्य रेडियो प्रभावों के कारण छिटपुट और सामान्यतः अस्थायी नुकसान का अनुभव करने के लिए जाना जाता है, जो कि सख्ती से भीड़भाड़ नहीं है। कंजेशन विंडो साइज के (गलत) बैक-ऑफ के बाद, वायरलेस पैकेट लॉस के कारण, विंडो साइज में रूढ़िवादी कमी के साथ कंजेशन अवॉइडेंस फेज हो सकता है। इससे रेडियो लिंक का कम उपयोग होता है। इन हानिकारक प्रभावों का मुकाबला करने के लिए व्यापक शोध किया गया है। सुझाए गए समाधानों को एंड-टू-एंड समाधानों के रूप में वर्गीकृत किया जा सकता है, जिसके लिए क्लाइंट या सर्वर पर संशोधन की आवश्यकता होती है,^[95] लिंक परत समाधान, जैसे कि सेलुलर नेटवर्क में रेडियो लिंक प्रोटोकॉल (रेडियो लिंक प्रोटोकॉल), या प्रॉक्सी-आधारित समाधान जिन्हें अंत नोड्स को संशोधित किए बिना नेटवर्क में कुछ बदलावों की आवश्यकता होती है।^[95]^[96] वायरलेस समस्या को हल करने में मदद करने के लिए टीसीपी वेगास, टीसीपी वेस्टवुड, वेनो और सांता क्रूज़ जैसे कई वैकल्पिक भीड़ नियंत्रण एल्गोरिदम प्रस्तावित किए गए हैं।

त्वरण

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

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

विधि के नुकसान में यह तथ्य सम्मलित है कि टीसीपी सत्र को त्वरक के माध्यम से निर्देशित किया जाना है; इसका मतलब यह है कि यदि रूटिंग बदल जाती है, ताकि एक्सीलरेटर अब रास्ते में न रहे, तो कनेक्शन टूट जाएगा। यह TCP एसीके मैकेनिज्म की एंड-टू-एंड प्रॉपर्टी को भी नष्ट कर देता है; जब एसीके प्रेषक द्वारा प्राप्त किया जाता है, तो पैकेट को त्वरक द्वारा संग्रहीत किया जाता है, रिसीवर को वितरित नहीं किया जाता है।

डिबगिंग

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

विकल्प

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

ऐतिहासिक और प्रदर्शन कारणों से, अधिकांश संरक्षण क्षेत्र नियंत्रण कार्य (SANs) फाइबर चैनल कनेक्शन पर फाइबर चैनल प्रोटोकॉल (FCP) का उपयोग करते हैं।

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

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

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

वेंटुरी ट्रांसपोर्ट प्रोटोकॉल (वीटीपी) पेटेंट स्वामित्व प्रोटोकॉल है जिसे वायरलेस डेटा ट्रांसपोर्ट से संबंधित कथित अक्षमताओं को दूर करने के लिए टीसीपी को पारदर्शी रूप से बदलने के लिए डिज़ाइन किया गया है।

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

यूडीपी आधारित डेटा ट्रांसफर प्रोटोकॉल (यूडीटी) में उच्च बैंडविड्थ-विलंब उत्पाद वाले नेटवर्क में टीसीपी की तुलना में बेहतर दक्षता और निष्पक्षता है।^[97] बहुउद्देशीय लेन-देन प्रोटोकॉल (MTP/IP) पेटेंट स्वामित्व वाला सॉफ़्टवेयर है जिसे विभिन्न प्रकार की नेटवर्क स्थितियों में अनुकूली रूप से उच्च थ्रूपुट और लेनदेन प्रदर्शन प्राप्त करने के लिए डिज़ाइन किया गया है, विशेष रूप से जहां टीसीपी को अक्षम माना जाता है।

चेकसम गणना

=== IPv4 === के लिए टीसीपी चेकसम जब टीसीपी IPv4 पर चलता है, तो चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि को निम्नानुसार परिभाषित किया गया है:REFERENCE FOR RFC9293 IS NOT DEFINED YET. You are invited to add it here. <ब्लॉककोट>

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

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

TCP pseudo-header for योग जांच करना computation (IPv4)
Bit offset	0–3	4–7		8–15	16–31
0	स्रोत पता
32	गंतव्य पता
64	शून्य			Protocol	टीसीपी लंबाई
96	स्रोत पोर्ट				गंतव्य पोर्ट
128	अनुक्रम संख्या
160	पावती संख्या
192	डेटा ऑफसेट	सुरक्षित	फ्लैग		विंडो
224	योग जांच करना				तत्काल सूचक
256	विकल्प (वैकल्पिक)
256/288+	डेटा

स्रोत और गंतव्य पते IPv4 हेडर के हैं। TCP के लिए प्रोटोकॉल मान 6 है (cf. IP प्रोटोकॉल नंबरों की सूची)। टीसीपी लंबाई क्षेत्र टीसीपी हेडर और डेटा (ओक्टेट में मापा गया) की लंबाई है।

=== IPv6 === के लिए टीसीपी चेकसम जब TCP IPv6 पर चलता है, तो चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि बदल जाती है:REFERENCE FOR RFC8200 IS NOT DEFINED YET. You are invited to add it here. <ब्लॉककोट> कोई भी परिवहन या अन्य ऊपरी-परत प्रोटोकॉल जिसमें IP शीर्षलेख से इसके चेकसम संगणना में पते सम्मलित हैं, को IPv6 पर उपयोग के लिए संशोधित किया जाना चाहिए, 32-बिट IPv4 पतों के अतिरिक्त 128-बिट IPv6 पतों को सम्मलित करने के लिए। </ब्लॉककोट> सूडो-हेडर जो चेकसम की गणना के लिए IPv6 हेडर की नकल करता है, नीचे दिखाया गया है।

TCP pseudo-header for योग जांच करना computation (IPv6)
Bit offset	0–7		8–15	16–23	24–31
0	स्रोत पता
32
64
96
128	गंतव्य पता
160
192
224
256	टीसीपी लंबाई
288	शून्य				अगला हेडर = प्रोटोकॉल
320	स्रोत पोर्ट			गंतव्य पोर्ट
352	अनुक्रम संख्या
384	पावती संख्या
416	डेटा ऑफसेट	सुरक्षित	फ्लैग	विंडो
448	योग जांच करना			तत्काल सूचक
480	विकल्प (वैकल्पिक)
480/512+	डेटा

स्रोत का पता: IPv6 हेडर में एक
गंतव्य पता: अंतिम गंतव्य; यदि IPv6 पैकेट में रूटिंग हेडर नहीं है, तो TCP IPv6 हेडर में गंतव्य पते का उपयोग करता है, अन्यथा, मूल नोड पर, यह रूटिंग हेडर के अंतिम तत्व में पते का उपयोग करता है, और, प्राप्त नोड पर, यह IPv6 हेडर में डेस्टिनेशन एड्रेस का उपयोग करता है।
टीसीपी लंबाई: टीसीपी हेडर और डेटा की लंबाई
अगला शीर्षक: टीसीपी के लिए प्रोटोकॉल मान

चेकसम ऑफलोड

कई टीसीपी/आईपी सॉफ्टवेयर स्टैक कार्यान्वयन नेटवर्क पर ट्रांसमिशन से पहले या सत्यापन के लिए नेटवर्क से रिसेप्शन पर नेटवर्क एडेप्टर में स्वचालित रूप से चेकसम की गणना करने के लिए हार्डवेयर सहायता का उपयोग करने के विकल्प प्रदान करते हैं। यह चेकसम की गणना करने वाले कीमती CPU चक्रों का उपयोग करने से OS को राहत दे सकता है। इसलिए, समग्र नेटवर्क प्रदर्शन बढ़ जाता है।

यह सुविधा पैकेट विश्लेषक का कारण बन सकती है जो आउटबाउंड पैकेट में अमान्य चेकसम की रिपोर्ट करने के लिए चेकसम ऑफलोड के उपयोग के बारे में अनजान या अनिश्चित हैं जो अभी तक नेटवर्क एडेप्टर तक नहीं पहुंचे हैं।^[98] यह केवल उन पैकेटों के लिए होगा जो नेटवर्क एडॉप्टर द्वारा प्रसारित किए जाने से पहले इंटरसेप्ट किए गए हैं; तार पर नेटवर्क एडेप्टर द्वारा प्रेषित सभी पैकेटों में वैध चेकसम होंगे।^[99] यह समस्या तब भी हो सकती है जब मॉनिटरिंग पैकेट ही होस्ट पर वर्चुअल मशीनों के बीच प्रेषित किए जा रहे हों, जहां वर्चुअल डिवाइस ड्राइवर चेकसम गणना ( अनुकूलन के रूप में) को छोड़ सकता है, यह जानते हुए कि चेकसम की गणना बाद में VM होस्ट कर्नेल या उसके भौतिक द्वारा की जाएगी हार्डवेयर।

आरएफसी दस्तावेज

RFC 675 - इंटरनेट ट्रांसमिशन कंट्रोल प्रोग्राम की विशिष्टता, दिसंबर 1974 संस्करण
RFC 793 - टीसीपी
RFC 1122 - टीसीपी के लिए कुछ त्रुटि सुधार सम्मलित हैं
RFC 1323 - उच्च प्रदर्शन के लिए टीसीपी एक्सटेंशन [आरएफसी 7323 द्वारा अप्रचलित]
RFC 1379 - लेन-देन के लिए टीसीपी का विस्तार-अवधारणाएं [आरएफसी 6247 द्वारा अप्रचलित]
RFC 1948 - अनुक्रम संख्या हमलों के खिलाफ बचाव
RFC 2018 - टीसीपी चयनात्मक पावती विकल्प
RFC 5681 - टीसीपी कंजेशन कंट्रोल
RFC 6247 – बेरोजगार टीसीपी एक्सटेंशन को स्थानांतरित करना RFC 1072, 1106, 1110, 1145, 1146, 1379, 1644 and 1693 ऐतिहासिक स्थिति के लिए
RFC 6298 - टीसीपी के रेट्रांस्मिशन टाइमर की गणना करना
RFC 6824 - एकाधिक पतों के साथ मल्टीपाथ ऑपरेशन के लिए टीसीपी एक्सटेंशन
RFC 7323 – उच्च प्रदर्शन के लिए टीसीपी एक्सटेंशन
RFC 7414 - टीसीपी विशिष्टता दस्तावेज़ों के लिए रोडमैप
RFC 9293 - ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी)

यह भी देखें

कनेक्शन उन्मुख संचार
टीसीपी और यूडीपी पोर्ट नंबरों की सूची (बंदरगाहों और सेवाओं की एक लंबी सूची)
माइक्रो-फटना (नेटवर्किंग)
टीसीपी का टी/टीसीपी संस्करण
टीसीपी वैश्विक तुल्यकालन
टीसीपी पेसिंग
Transport layer § Comparison of transport layer protocols
डब्ल्यूटीसीपी वायरलेस नेटवर्क के लिए टीसीपी का एक प्रॉक्सी-आधारित संशोधन है

संदर्भ

↑ Vinton G. Cerf; Robert E. Kahn (May 1974). "ए प्रोटोकॉल फॉर पैकेट नेटवर्क इंटरकम्यूनिकेशन" (PDF). IEEE Transactions on Communications. 22 (5): 637–648. doi:10.1109/tcom.1974.1092259. Archived from the original (PDF) on March 4, 2016.
↑ Bennett, Richard (September 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate" (PDF). Information Technology and Innovation Foundation. p. 11. Archived (PDF) from the original on 29 August 2019. Retrieved 11 September 2017.
↑ {{#section:Template:Ref RFC/db/6|rfc675ref}} {{#section:Template:Ref RFC/db/6|rfc675status}}. {{#section:Template:Ref RFC/db/6|rfc675notes}}
↑ "रॉबर्ट ई कान - ए.एम. ट्यूरिंग पुरस्कार विजेता". amturing.acm.org. Archived from the original on 2019-07-13. Retrieved 2019-07-13.
↑ "विंटन सर्फ़ - ए.एम. ट्यूरिंग पुरस्कार विजेता". amturing.acm.org. Archived from the original on 2021-10-11. Retrieved 2019-07-13.
↑ ^6.0 ^6.1 ^6.2 ^6.3 ^6.4 ^6.5 ^6.6 ^6.7 ^6.8 Comer, Douglas E. (2006). Internetworking with TCP/IP: Principles, Protocols, and Architecture. Vol. 1 (5th ed.). Prentice Hall. ISBN 978-0-13-187671-2.
↑ "टीसीपी (ट्रांसमिशन कंट्रोल प्रोटोकॉल)". Archived from the original on 2013-04-07. Retrieved 2019-06-26.
↑ {{#section:Template:Ref RFC/db/7|rfc791ref}} {{#section:Template:Ref RFC/db/7|rfc791status}}. {{#section:Template:Ref RFC/db/7|rfc791notes}}
↑ "Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic". datatracker.ietf.org (in English). Retrieved 2023-04-18.
↑ TCP Extensions for High Performance. sec. 2.2. RFC 1323. Archived 2020-08-13 at the Wayback Machine
↑ Jacobson, V.; Braden, R.; Borman, D. (1992). "RFC 1323, TCP Extensions for High Performance, Section 3.2". doi:10.17487/RFC1323. Archived from the original on 2009-09-05. Retrieved 2009-09-07. {{cite journal}}: Cite journal requires |journal= (help)
↑ "Transmission Control Protocol (TCP) Parameters: TCP Option Kind Numbers". IANA. Archived from the original on 2017-10-02. Retrieved 2017-10-19.
↑ Kurose, James F. (2017). Computer networking : a top-down approach. Keith W. Ross (7th ed.). Harlow, England. p. 286. ISBN 978-0-13-359414-0. OCLC 936004518.{{cite book}}: CS1 maint: location missing publisher (link)
↑ Tanenbaum, Andrew S. (2003-03-17). कंप्यूटर नेटवर्क (Fourth ed.). Prentice Hall. ISBN 978-0-13-066102-9.
↑ "टीसीपी परिभाषा". Archived from the original on 2020-05-06. Retrieved 2011-03-12.
↑ Karn & Partridge 1991, p. 364.
↑ Iyengar & Swett 2021, 4.2. Monotonically Increasing Packet Numbers.
↑ Mathis; Mathew; Semke; Mahdavi; Ott (1997). "टीसीपी कंजेशन परिहार एल्गोरिथम का मैक्रोस्कोपिक व्यवहार". ACM SIGCOMM Computer Communication Review. 27 (3): 67–82. CiteSeerX 10.1.1.40.7002. doi:10.1145/263932.264023. S2CID 1894993.
↑ Ludwig & Meyer 2003, p. 4.
↑ ^20.0 ^20.1 Zhang 1986, p. 399.
↑ Karn & Partridge 1991, p. 365.
↑ Ludwig & Katz 2000, p. 31-33.
↑ Gurtov & Ludwig 2003, p. 2.
↑ Gurtov & Floyd 2004, p. 1.
↑ ^25.0 ^25.1 Paxson et al. 2011, p. 4.
↑ Karn & Partridge 1991, p. 370-372.
↑ Allman & Paxson 1999, p. 268.
↑ Borman, Braden & Jacobson 2014, p. 7.
↑ Stone; Partridge (2000). "जब सीआरसी और टीसीपी चेकसम असहमत हों". ACM SIGCOMM Computer Communication Review: 309–319. CiteSeerX 10.1.1.27.7611. doi:10.1145/347059.347561. ISBN 978-1581132236. S2CID 9547018. Archived from the original on 2008-05-05. Retrieved 2008-04-28.
↑ Mathis et al. 1996, p. 10.
↑ Iyengar & Swett 2021, 4.4. No Reneging.
↑ "टीसीपी विंडो स्केलिंग और टूटे राउटर". LWN.net. Archived from the original on 2020-03-31. Retrieved 2016-07-21.
↑ RFC 3522
↑ "आईपी sysctl". Linux Kernel Documentation. Archived from the original on 5 March 2016. Retrieved 15 December 2018. {{cite web}}: zero width space character in |title= at position 6 (help)
↑ Wang, Eve. "टीसीपी टाइमस्टैम्प अक्षम है". Technet - Windows Server 2012 Essentials. Microsoft. Archived from the original on 2018-12-15. Retrieved 2018-12-15.
↑ David Murray; Terry Koziniec; Sebastian Zander; Michael Dixon; Polychronis Koutsakis (2017). "एंटरप्राइज़ नेटवर्क ट्रैफ़िक विशेषताओं को बदलने का विश्लेषण" (PDF). The 23rd Asia-Pacific Conference on Communications (APCC 2017). Archived (PDF) from the original on 3 October 2017. Retrieved 3 October 2017.
↑ Gont, Fernando (November 2008). "टीसीपी तत्काल डेटा के कार्यान्वयन पर". 73rd IETF meeting. Archived from the original on 2019-05-16. Retrieved 2009-01-04.
↑ Peterson, Larry (2003). कंप्यूटर नेटवर्क. Morgan Kaufmann. p. 401. ISBN 978-1-55860-832-0.
↑ Richard W. Stevens (November 2011). TCP/IP Illustrated. Vol. 1, The protocols. Addison-Wesley. pp. Chapter 20. ISBN 978-0-201-63346-7.
↑ "ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का सुरक्षा आकलन" (PDF). Archived from the original on March 6, 2009. Retrieved 2010-12-23.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
↑ Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations
↑ Jakob Lell. "SYN कुकीज़ के साथ क्विक ब्लाइंड TCP कनेक्शन स्पूफिंग". Archived from the original on 2014-02-22. Retrieved 2014-02-05.
↑ "हाल ही में टीसीपी डीओएस (सेवा से वंचित) कमजोरियों के बारे में कुछ अंतर्दृष्टि" (PDF). Archived from the original (PDF) on 2013-06-18. Retrieved 2010-12-23.
↑ "टीसीपी और पर्सिस्ट टाइमर अनंतता का शोषण". Archived from the original on 2010-01-22. Retrieved 2010-01-22.
↑ "पुश और एसीके बाढ़". f5.com. Archived from the original on 2017-09-28. Retrieved 2017-09-27.
↑ "Laurent Joncheray, Simple Active Attack Against TCP, 1995". Archived from the original on 2007-12-07. Retrieved 2007-11-25.
↑ John T. Hagen; Barry E. Mullins (2013). TCP veto: A novel network attack and its application to SCADA protocols. pp. 1–6. doi:10.1109/ISGT.2013.6497785. ISBN 978-1-4673-4896-6. S2CID 25353177. {{cite book}}: |journal= ignored (help)
↑ Eddy 2022, 4. Glossary.
↑ Fairhurst, Trammell & Kuehlewind 2017, p. 6.
↑ Eddy 2022, 2.2. Key TCP Concepts.
↑ Eddy 2022, 3.1. Header Format.
↑ Paasch & Bonaventure 2014, p. 51.
↑ "टीसीपी इंटरएक्टिव". www.medianet.kent.edu. Archived from the original on 2008-08-20. Retrieved 2008-04-28.
↑ Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "मल्टीपाथ टीसीपी के साथ डेटासेंटर के प्रदर्शन और मजबूती में सुधार". ACM SIGCOMM Computer Communication Review. 41 (4): 266. CiteSeerX 10.1.1.306.3863. doi:10.1145/2043164.2018467. Archived from the original on 2020-04-04. Retrieved 2011-06-29.
↑ "मल्टीपाथ टीसीपी - लिनक्स कर्नेल कार्यान्वयन". Archived from the original on 2013-03-27. Retrieved 2013-03-24.
↑ Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". Usenix NSDI: 399–412. Archived from the original on 2013-06-03. Retrieved 2013-03-24.
↑ Bonaventure; Seo (2016). "बहुपथ टीसीपी परिनियोजन". IETF Journal. Archived from the original on 2020-02-23. Retrieved 2017-01-03.
↑ Michael Kerrisk (2012-08-01). "TCP Fast Open: expediting web services". LWN.net. Archived from the original on 2014-08-03. Retrieved 2014-07-21.
↑ Yuchung Cheng; Jerry Chu; Sivasankar Radhakrishnan & Arvind Jain (December 2014). "टीसीपी फास्ट ओपन". IETF. doi:10.17487/RFC7413. Archived from the original on 1 January 2015. Retrieved 10 January 2015. {{cite journal}}: Cite journal requires |journal= (help)
↑ Mathis, Matt; Dukkipati, Nandita; Cheng, Yuchung (May 2013). "RFC 6937 - Proportional Rate Reduction for TCP". doi:10.17487/RFC6937. Archived from the original on 14 July 2014. Retrieved 6 June 2014. {{cite journal}}: Cite journal requires |journal= (help)
↑ Grigorik, Ilya (2013). उच्च-प्रदर्शन ब्राउज़र नेटवर्किंग (1. ed.). Beijing: O'Reilly. ISBN 978-1449344764.
↑ Trammell & Kuehlewind 2019, p. 6.
↑ Hardie 2019, p. 3.
↑ Fairhurst & Perkins 2021, 2. Current Uses of Transport Headers within the Network.
↑ Fairhurst & Perkins 2021, 3. Research, Development, and Deployment.
↑ Hardie 2019, p. 8.
↑ Thomson & Pauly 2021, 2.3. Multi-party Interactions and Middleboxes.
↑ Thomson & Pauly 2021, A.5. TCP.
↑ Papastergiou et al. 2017, p. 620.
↑ Edeline & Donnet 2019, p. 175-176.
↑ Raiciu et al. 2012, p. 1.
↑ Hesmans et al. 2013, p. 1.
↑ ^73.0 ^73.1 Rybczyńska 2020.
↑ Papastergiou et al. 2017, p. 621.
↑ Corbet 2015.
↑ Briscoe et al. 2006, p. 29-30.
↑ Marx 2020, HOL blocking in HTTP/1.1.
↑ Marx 2020, Bonus: Transport Congestion Control.
↑ IETF HTTP Working Group, Why just one TCP connection?.
↑ Corbet 2018.
↑ ^81.0 ^81.1 Cheng et al. 2014, p. 3.
↑ Sy et al. 2020, p. 271.
↑ Chen et al. 2021, p. 8-9.
↑ Ghedini 2018.
↑ Chen et al. 2021, p. 3-4.
↑ Cheng et al. 2014, p. 1.
↑ Blanton & Allman 2002, p. 1-2.
↑ Blanton & Allman 2002, p. 4-5.
↑ Blanton & Allman 2002, p. 3-4.
↑ Blanton & Allman 2002, p. 6-8.
↑ Bruyeron, Hemon & Zhang 1998, p. 67.
↑ Bruyeron, Hemon & Zhang 1998, p. 72.
↑ Bhat, Rizk & Zink 2017, p. 14.
↑ Iyengar & Swett 2021, 4.5. More ACK Ranges.
↑ ^95.0 ^95.1 "TCP performance over CDMA2000 RLP". Archived from the original on 2011-05-03. Retrieved 2010-08-30.
↑ Muhammad Adeel & Ahmad Ali Iqbal (2004). TCP Congestion Window Optimization for CDMA2000 Packet Data Networks. pp. 31–35. doi:10.1109/ITNG.2007.190. ISBN 978-0-7695-2776-5. S2CID 8717768. {{cite book}}: |journal= ignored (help)
↑ Yunhong Gu, Xinwei Hong, and Robert L. Grossman. "An Analysis of AIMD Algorithm with Decreasing Increases" Archived 2016-03-05 at the Wayback Machine. 2004.
↑ "Wireshark: Offloading". Archived from the original on 2017-01-31. Retrieved 2017-02-24. Wireshark captures packets before they are sent to the network adapter. It won't see the correct checksum because it has not been calculated yet. Even worse, most OSes don't bother initialize this data so you're probably seeing little chunks of memory that you shouldn't. New installations of Wireshark 1.2 and above disable IP, TCP, and UDP checksum validation by default. You can disable checksum validation in each of those dissectors by hand if needed.
↑ "Wireshark: Checksums". Archived from the original on 2016-10-22. Retrieved 2017-02-24. चेकसम ऑफलोडिंग अक्सर भ्रम पैदा करती है क्योंकि प्रसारित किए जाने वाले नेटवर्क पैकेट को वास्तव में चेकसम की गणना करने से पहले Wireshark को सौंप दिया जाता है। Wireshark इन "खाली" चेकसम को प्राप्त करता है और उन्हें अमान्य के रूप में प्रदर्शित करता है, भले ही पैकेट में बाद में नेटवर्क हार्डवेयर छोड़ने पर वैध चेकसम होंगे।

ग्रन्थसूची

Allman, Mark; Paxson, Vern (October 1999). "On estimating end-to-end network path properties". ACM SIGCOMM Computer Communication Review. doi:10.1145/316194.316230.
Bhat, Divyashri; Rizk, Amr; Zink, Michael (June 2017). "Not so QUIC: A Performance Study of DASH over QUIC". NOSSDAV'17: Proceedings of the 27th Workshop on Network and Operating Systems Support for Digital Audio and Video. pp. 13–18. doi:10.1145/3083165.3083175.
Blanton, Ethan; Allman, Mark (January 2002). "On making TCP more robust to packet reordering" (PDF). ACM SIGCOMM Computer Communication Review. doi:10.1145/510726.510728.
Borman, David; Braden, Bob; Jacobson, Van (September 2014). Scheffenegger, Richard (ed.). TCP Extensions for High Performance. doi:10.17487/RFC7323. RFC 7323.
Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). "Reducing Internet Latency: A Survey of Techniques and Their Merits". IEEE Communications Surveys & Tutorials. 18 (3): 2149–2196. doi:10.1109/COMST.2014.2375213. hdl:2164/8018. S2CID 206576469.
Bruyeron, Renaud; Hemon, Bruno; Zhang, Lixa (April 1998). "Experimentations with TCP selective acknowledgment". ACM SIGCOMM Computer Communication Review. doi:10.1145/279345.279350.
Chen, Shan; Jero, Samuel; Jagielski, Matthew; Boldyreva, Alexandra; Nita-Rotaru, Cristina (2021). "Secure Communication Channel Establishment: TLS 1.3 (Over TCP Fast Open) versus QUIC". Journal of Cryptology. 34 (3). doi:10.1007/s00145-021-09389-w. S2CID 235174220.
Cheng, Yuchung; Chu, Jerry; Radhakrishnan, Sivasankar; Jain, Arvind (December 2014). TCP Fast Open. doi:10.17487/RFC7413. RFC 7413.
Corbet, Jonathan (8 December 2015). "Checksum offloads and protocol ossification". LWN.net.
Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net.
Eddy, Wesley M., ed. (August 2022). Transmission Control Protocol (TCP). doi:10.17487/RFC9293. RFC 9293.
Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690.
Fairhurst, Gorry; Trammell, Brian; Kuehlewind, Mirja, eds. (March 2017). Services Provided by IETF Transport Protocols and Congestion Control Mechanisms. doi:10.17487/RFC8095. RFC 8095.
Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065.
Ghedini, Alessandro (26 July 2018). "The Road to QUIC". Cloudflare.
Gurtov, Andrei; Floyd, Sally (February 2004). Resolving Acknowledgment Ambiguity in non-SACK TCP (PDF). Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN'04).
Gurtov, Andrei; Ludwig, Reiner (2003). Responding to Spurious Timeouts in TCP (PDF). IEEE INFOCOM 2003. Twenty-second Annual Joint Conference of the IEEE Computer and Communications Societies. doi:10.1109/INFCOM.2003.1209251.
Hardie, Ted, ed. (April 2019). Transport Protocol Path Signals. doi:10.17487/RFC8558. RFC 8558.
Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). Are TCP extensions middlebox-proof?. HotMiddlebox '13. doi:10.1145/2535828.2535830.
Iyengar, Jana; Swett, Ian, eds. (May 2021). QUIC Loss Detection and Congestion Control. doi:10.17487/RFC9002. RFC 9002.
IETF HTTP Working Group. "HTTP/2 Frequently Asked Questions".
Karn, Phil; Partridge, Craig (November 1991). "Improving round-trip time estimates in reliable transport protocols". ACM Transactions on Computer Systems. doi:10.1145/118544.118549.
Ludwig, Reiner; Katz, Randy Howard (January 2000). "The Eifel algorithm: making TCP robust against spurious retransmissions". ACM SIGCOMM Computer Communication Review. doi:10.1145/505688.505692.
Ludwig, Reiner; Meyer, Michael (April 2003). The Eifel Detection Algorithm for TCP. doi:10.17487/RFC3522. RFC 3522.
Marx, Robin (3 December 2020). "Head-of-Line Blocking in QUIC and HTTP/3: The Details".
Mathis, Matt; Mahdavi, Jamshid; Floyd, Sally; Romanow, Allyn (October 1996). TCP Selective Acknowledgment Options. doi:10.17487/RFC2018. RFC 2018.
Paasch, Christoph; Bonaventure, Olivier (1 April 2014). "Multipath TCP". Communications of the ACM. doi:10.1145/2578901.
Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371.
Paxson, Vern; Allman, Mark; Chu, H.K. Jerry; Sargent, Matt (June 2011). Computing TCP's Retransmission Timer. doi:10.17487/RFC6298. RFC 6298.
Rybczyńska, Marta (13 March 2020). "A QUIC look at HTTP/3". LWN.net.
Sy, Erik; Mueller, Tobias; Burkert, Christian; Federrath, Hannes; Fischer, Mathias (2020). "Enhanced Performance and Privacy for TLS over TCP Fast Open". Proceedings on Privacy Enhancing Technologies. 2020 (2): 271–287. arXiv:1905.03518. doi:10.2478/popets-2020-0027.
Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170.
Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. doi:10.17487/RFC8546. RFC 8546.
Zhang, Lixia (5 August 1986). "Why TCP timers don't work well". ACM SIGCOMM Computer Communication Review. doi:10.1145/1013812.18216.

अग्रिम पठन

Stevens, W. Richard (1994-01-10). TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Pub. Co. ISBN 978-0-201-63346-7.
Stevens, W. Richard; Wright, Gary R (1994). TCP/IP Illustrated, Volume 2: The Implementation. ISBN 978-0-201-63354-2.
Stevens, W. Richard (1996). TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. ISBN 978-0-201-63495-2.**

बाहरी संबंध

[added3168-10] 1.0 ^1.1 Added to header by RFC 3168

[11] Windows size units are, by default, bytes.

[12] Window size is relative to the segment identified by the sequence number in the acknowledgment field.

[1] Vinton G. Cerf; Robert E. Kahn (May 1974). "ए प्रोटोकॉल फॉर पैकेट नेटवर्क इंटरकम्यूनिकेशन" (PDF). IEEE Transactions on Communications. 22 (5): 637–648. doi:10.1109/tcom.1974.1092259. Archived from the original (PDF) on March 4, 2016.

[2] Bennett, Richard (September 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate" (PDF). Information Technology and Innovation Foundation. p. 11. Archived (PDF) from the original on 29 August 2019. Retrieved 11 September 2017.

[rfc675-3] {{#section:Template:Ref RFC/db/6|rfc675ref}} {{#section:Template:Ref RFC/db/6|rfc675status}}. {{#section:Template:Ref RFC/db/6|rfc675notes}}

[4] "रॉबर्ट ई कान - ए.एम. ट्यूरिंग पुरस्कार विजेता". amturing.acm.org. Archived from the original on 2019-07-13. Retrieved 2019-07-13.

[5] "विंटन सर्फ़ - ए.एम. ट्यूरिंग पुरस्कार विजेता". amturing.acm.org. Archived from the original on 2021-10-11. Retrieved 2019-07-13.

[comer-6] 6.0 ^6.1 ^6.2 ^6.3 ^6.4 ^6.5 ^6.6 ^6.7 ^6.8 Comer, Douglas E. (2006). Internetworking with TCP/IP: Principles, Protocols, and Architecture. Vol. 1 (5th ed.). Prentice Hall. ISBN 978-0-13-187671-2.

[7] "टीसीपी (ट्रांसमिशन कंट्रोल प्रोटोकॉल)". Archived from the original on 2013-04-07. Retrieved 2019-06-26.

[rfc791-8] {{#section:Template:Ref RFC/db/7|rfc791ref}} {{#section:Template:Ref RFC/db/7|rfc791status}}. {{#section:Template:Ref RFC/db/7|rfc791notes}}

[9] "Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic". datatracker.ietf.org (in English). Retrieved 2023-04-18.

[13] TCP Extensions for High Performance. sec. 2.2. RFC 1323. Archived 2020-08-13 at the Wayback Machine

[14] Jacobson, V.; Braden, R.; Borman, D. (1992). "RFC 1323, TCP Extensions for High Performance, Section 3.2". doi:10.17487/RFC1323. Archived from the original on 2009-09-05. Retrieved 2009-09-07. {{cite journal}}: Cite journal requires |journal= (help)

[15] "Transmission Control Protocol (TCP) Parameters: TCP Option Kind Numbers". IANA. Archived from the original on 2017-10-02. Retrieved 2017-10-19.

[16] Kurose, James F. (2017). Computer networking : a top-down approach. Keith W. Ross (7th ed.). Harlow, England. p. 286. ISBN 978-0-13-359414-0. OCLC 936004518.{{cite book}}: CS1 maint: location missing publisher (link)

[17] Tanenbaum, Andrew S. (2003-03-17). कंप्यूटर नेटवर्क (Fourth ed.). Prentice Hall. ISBN 978-0-13-066102-9.

[18] "टीसीपी परिभाषा". Archived from the original on 2020-05-06. Retrieved 2011-03-12.

[FOOTNOTEKarnPartridge1991364-19] Karn & Partridge 1991, p. 364.

[FOOTNOTEIyengarSwett20214.2._Monotonically_Increasing_Packet_Numbers-20] Iyengar & Swett 2021, 4.2. Monotonically Increasing Packet Numbers.

[21] Mathis; Mathew; Semke; Mahdavi; Ott (1997). "टीसीपी कंजेशन परिहार एल्गोरिथम का मैक्रोस्कोपिक व्यवहार". ACM SIGCOMM Computer Communication Review. 27 (3): 67–82. CiteSeerX 10.1.1.40.7002. doi:10.1145/263932.264023. S2CID 1894993.

[FOOTNOTELudwigMeyer20034-22] Ludwig & Meyer 2003, p. 4.

[FOOTNOTEZhang1986399-23] 20.0 ^20.1 Zhang 1986, p. 399.

[FOOTNOTEKarnPartridge1991365-24] Karn & Partridge 1991, p. 365.

[FOOTNOTELudwigKatz200031-33-25] Ludwig & Katz 2000, p. 31-33.

[FOOTNOTEGurtovLudwig20032-26] Gurtov & Ludwig 2003, p. 2.

[FOOTNOTEGurtovFloyd20041-27] Gurtov & Floyd 2004, p. 1.

[FOOTNOTEPaxsonAllmanChuSargent20114-28] 25.0 ^25.1 Paxson et al. 2011, p. 4.

[FOOTNOTEKarnPartridge1991370-372-29] Karn & Partridge 1991, p. 370-372.

[FOOTNOTEAllmanPaxson1999268-30] Allman & Paxson 1999, p. 268.

[FOOTNOTEBormanBradenJacobson20147-31] Borman, Braden & Jacobson 2014, p. 7.

[32] Stone; Partridge (2000). "जब सीआरसी और टीसीपी चेकसम असहमत हों". ACM SIGCOMM Computer Communication Review: 309–319. CiteSeerX 10.1.1.27.7611. doi:10.1145/347059.347561. ISBN 978-1581132236. S2CID 9547018. Archived from the original on 2008-05-05. Retrieved 2008-04-28.

[FOOTNOTEMathisMahdaviFloydRomanow199610-33] Mathis et al. 1996, p. 10.

[FOOTNOTEIyengarSwett20214.4._No_Reneging-34] Iyengar & Swett 2021, 4.4. No Reneging.

[35] "टीसीपी विंडो स्केलिंग और टूटे राउटर". LWN.net. Archived from the original on 2020-03-31. Retrieved 2016-07-21.

[36] RFC 3522

[37] "आईपी sysctl". Linux Kernel Documentation. Archived from the original on 5 March 2016. Retrieved 15 December 2018. {{cite web}}: zero width space character in |title= at position 6 (help)

[38] Wang, Eve. "टीसीपी टाइमस्टैम्प अक्षम है". Technet - Windows Server 2012 Essentials. Microsoft. Archived from the original on 2018-12-15. Retrieved 2018-12-15.

[2017stats-39] David Murray; Terry Koziniec; Sebastian Zander; Michael Dixon; Polychronis Koutsakis (2017). "एंटरप्राइज़ नेटवर्क ट्रैफ़िक विशेषताओं को बदलने का विश्लेषण" (PDF). The 23rd Asia-Pacific Conference on Communications (APCC 2017). Archived (PDF) from the original on 3 October 2017. Retrieved 3 October 2017.

[40] Gont, Fernando (November 2008). "टीसीपी तत्काल डेटा के कार्यान्वयन पर". 73rd IETF meeting. Archived from the original on 2019-05-16. Retrieved 2009-01-04.

[41] Peterson, Larry (2003). कंप्यूटर नेटवर्क. Morgan Kaufmann. p. 401. ISBN 978-1-55860-832-0.

[Stevens2006-42] Richard W. Stevens (November 2011). TCP/IP Illustrated. Vol. 1, The protocols. Addison-Wesley. pp. Chapter 20. ISBN 978-0-201-63346-7.

[43] "ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का सुरक्षा आकलन" (PDF). Archived from the original on March 6, 2009. Retrieved 2010-12-23.{{cite web}}: CS1 maint: bot: original URL status unknown (link)

[44] Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations

[45] Jakob Lell. "SYN कुकीज़ के साथ क्विक ब्लाइंड TCP कनेक्शन स्पूफिंग". Archived from the original on 2014-02-22. Retrieved 2014-02-05.

[46] "हाल ही में टीसीपी डीओएस (सेवा से वंचित) कमजोरियों के बारे में कुछ अंतर्दृष्टि" (PDF). Archived from the original (PDF) on 2013-06-18. Retrieved 2010-12-23.

[47] "टीसीपी और पर्सिस्ट टाइमर अनंतता का शोषण". Archived from the original on 2010-01-22. Retrieved 2010-01-22.

[48] "पुश और एसीके बाढ़". f5.com. Archived from the original on 2017-09-28. Retrieved 2017-09-27.

[49] "Laurent Joncheray, Simple Active Attack Against TCP, 1995". Archived from the original on 2007-12-07. Retrieved 2007-11-25.

[50] John T. Hagen; Barry E. Mullins (2013). TCP veto: A novel network attack and its application to SCADA protocols. pp. 1–6. doi:10.1109/ISGT.2013.6497785. ISBN 978-1-4673-4896-6. S2CID 25353177. {{cite book}}: |journal= ignored (help)

[FOOTNOTEEddy20224._Glossary-51] Eddy 2022, 4. Glossary.

[FOOTNOTEFairhurstTrammellKuehlewind20176-52] Fairhurst, Trammell & Kuehlewind 2017, p. 6.

[FOOTNOTEEddy20222.2._Key_TCP_Concepts-53] Eddy 2022, 2.2. Key TCP Concepts.

[FOOTNOTEEddy20223.1._Header_Format-54] Eddy 2022, 3.1. Header Format.

[FOOTNOTEPaaschBonaventure201451-55] Paasch & Bonaventure 2014, p. 51.

[56] "टीसीपी इंटरएक्टिव". www.medianet.kent.edu. Archived from the original on 2008-08-20. Retrieved 2008-04-28.

[57] Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "मल्टीपाथ टीसीपी के साथ डेटासेंटर के प्रदर्शन और मजबूती में सुधार". ACM SIGCOMM Computer Communication Review. 41 (4): 266. CiteSeerX 10.1.1.306.3863. doi:10.1145/2043164.2018467. Archived from the original on 2020-04-04. Retrieved 2011-06-29.

[58] "मल्टीपाथ टीसीपी - लिनक्स कर्नेल कार्यान्वयन". Archived from the original on 2013-03-27. Retrieved 2013-03-24.

[59] Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". Usenix NSDI: 399–412. Archived from the original on 2013-06-03. Retrieved 2013-03-24.

[60] Bonaventure; Seo (2016). "बहुपथ टीसीपी परिनियोजन". IETF Journal. Archived from the original on 2020-02-23. Retrieved 2017-01-03.

[lwn-61] Michael Kerrisk (2012-08-01). "TCP Fast Open: expediting web services". LWN.net. Archived from the original on 2014-08-03. Retrieved 2014-07-21.

[:0-62] Yuchung Cheng; Jerry Chu; Sivasankar Radhakrishnan & Arvind Jain (December 2014). "टीसीपी फास्ट ओपन". IETF. doi:10.17487/RFC7413. Archived from the original on 1 January 2015. Retrieved 10 January 2015. {{cite journal}}: Cite journal requires |journal= (help)

[63] Mathis, Matt; Dukkipati, Nandita; Cheng, Yuchung (May 2013). "RFC 6937 - Proportional Rate Reduction for TCP". doi:10.17487/RFC6937. Archived from the original on 14 July 2014. Retrieved 6 June 2014. {{cite journal}}: Cite journal requires |journal= (help)

[64] Grigorik, Ilya (2013). उच्च-प्रदर्शन ब्राउज़र नेटवर्किंग (1. ed.). Beijing: O'Reilly. ISBN 978-1449344764.

[FOOTNOTETrammellKuehlewind20196-65] Trammell & Kuehlewind 2019, p. 6.

[FOOTNOTEHardie20193-66] Hardie 2019, p. 3.

[FOOTNOTEFairhurstPerkins20212._Current_Uses_of_Transport_Headers_within_the_Network-67] Fairhurst & Perkins 2021, 2. Current Uses of Transport Headers within the Network.

[FOOTNOTEFairhurstPerkins20213._Research,_Development,_and_Deployment-68] Fairhurst & Perkins 2021, 3. Research, Development, and Deployment.

[FOOTNOTEHardie20198-69] Hardie 2019, p. 8.

[FOOTNOTEThomsonPauly20212.3._Multi-party_Interactions_and_Middleboxes-70] Thomson & Pauly 2021, 2.3. Multi-party Interactions and Middleboxes.

[FOOTNOTEThomsonPauly2021A.5._TCP-71] Thomson & Pauly 2021, A.5. TCP.

[FOOTNOTEPapastergiouFairhurstRosBrunstrom2017620-72] Papastergiou et al. 2017, p. 620.

[FOOTNOTEEdelineDonnet2019175-176-73] Edeline & Donnet 2019, p. 175-176.

[FOOTNOTERaiciuPaaschBarreFord20121-74] Raiciu et al. 2012, p. 1.

[FOOTNOTEHesmansDuchenePaaschDetal20131-75] Hesmans et al. 2013, p. 1.

[FOOTNOTERybczyńska2020-76] 73.0 ^73.1 Rybczyńska 2020.

[FOOTNOTEPapastergiouFairhurstRosBrunstrom2017621-77] Papastergiou et al. 2017, p. 621.

[FOOTNOTECorbet2015-78] Corbet 2015.

[FOOTNOTEBriscoeBrunstromPetlundHayes200629-30-79] Briscoe et al. 2006, p. 29-30.

[FOOTNOTEMarx2020HOL_blocking_in_HTTP/1.1-80] Marx 2020, HOL blocking in HTTP/1.1.

[FOOTNOTEMarx2020Bonus:_Transport_Congestion_Control-81] Marx 2020, Bonus: Transport Congestion Control.

[FOOTNOTEIETF_HTTP_Working_GroupWhy_just_one_TCP_connection?-82] IETF HTTP Working Group, Why just one TCP connection?.

[FOOTNOTECorbet2018-83] Corbet 2018.

[FOOTNOTEChengChuRadhakrishnanJain20143-84] 81.0 ^81.1 Cheng et al. 2014, p. 3.

[FOOTNOTESyMuellerBurkertFederrath2020271-85] Sy et al. 2020, p. 271.

[FOOTNOTEChenJeroJagielskiBoldyreva20218-9-86] Chen et al. 2021, p. 8-9.

[FOOTNOTEGhedini2018-87] Ghedini 2018.

[FOOTNOTEChenJeroJagielskiBoldyreva20213-4-88] Chen et al. 2021, p. 3-4.

[FOOTNOTEChengChuRadhakrishnanJain20141-89] Cheng et al. 2014, p. 1.

[FOOTNOTEBlantonAllman20021-2-90] Blanton & Allman 2002, p. 1-2.

[FOOTNOTEBlantonAllman20024-5-91] Blanton & Allman 2002, p. 4-5.

[FOOTNOTEBlantonAllman20023-4-92] Blanton & Allman 2002, p. 3-4.

[FOOTNOTEBlantonAllman20026-8-93] Blanton & Allman 2002, p. 6-8.

[FOOTNOTEBruyeronHemonZhang199867-94] Bruyeron, Hemon & Zhang 1998, p. 67.

[FOOTNOTEBruyeronHemonZhang199872-95] Bruyeron, Hemon & Zhang 1998, p. 72.

[FOOTNOTEBhatRizkZink201714-96] Bhat, Rizk & Zink 2017, p. 14.

[FOOTNOTEIyengarSwett20214.5._More_ACK_Ranges-97] Iyengar & Swett 2021, 4.5. More ACK Ranges.

[Microsoft_Academic_Research-98] 95.0 ^95.1 "TCP performance over CDMA2000 RLP". Archived from the original on 2011-05-03. Retrieved 2010-08-30.

[IEEE_Computer_Society-99] Muhammad Adeel & Ahmad Ali Iqbal (2004). TCP Congestion Window Optimization for CDMA2000 Packet Data Networks. pp. 31–35. doi:10.1109/ITNG.2007.190. ISBN 978-0-7695-2776-5. S2CID 8717768. {{cite book}}: |journal= ignored (help)

[100] Yunhong Gu, Xinwei Hong, and Robert L. Grossman. "An Analysis of AIMD Algorithm with Decreasing Increases" Archived 2016-03-05 at the Wayback Machine. 2004.

[101] "Wireshark: Offloading". Archived from the original on 2017-01-31. Retrieved 2017-02-24. Wireshark captures packets before they are sent to the network adapter. It won't see the correct checksum because it has not been calculated yet. Even worse, most OSes don't bother initialize this data so you're probably seeing little chunks of memory that you shouldn't. New installations of Wireshark 1.2 and above disable IP, TCP, and UDP checksum validation by default. You can disable checksum validation in each of those dissectors by hand if needed.

[102] "Wireshark: Checksums". Archived from the original on 2016-10-22. Retrieved 2017-02-24. चेकसम ऑफलोडिंग अक्सर भ्रम पैदा करती है क्योंकि प्रसारित किए जाने वाले नेटवर्क पैकेट को वास्तव में चेकसम की गणना करने से पहले Wireshark को सौंप दिया जाता है। Wireshark इन "खाली" चेकसम को प्राप्त करता है और उन्हें अमान्य के रूप में प्रदर्शित करता है, भले ही पैकेट में बाद में नेटवर्क हार्डवेयर छोड़ने पर वैध चेकसम होंगे।

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[lower-alpha 1]

[lower-alpha 2]

[lower-alpha 3]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

[86]

[87]

[88]

[89]

[90]

[91]

[92]

[93]

[94]

[95]

[96]

[97]

Anonymous

Search