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

{{Infobox networking protocol
| title      = प्रसारण नियंत्रण प्रोटोकॉल
| logo       = 
| logo alt   = 
| image      = 
| image alt  = 
| caption    = 
| is stack   =हाँ 
| purpose    = 
| developer  = [[विंट सर्फ़]] और [[बॉब कान]]
| date       = 1974
| based on   = ट्रांसमिशन कंट्रोल प्रोग्राम 
| influenced = 
| osilayer   = [[परिवहन परत]] (4)
| ports      = 
| rfcs       = RFC 9293
| hardware   = 
}}

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

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

{{IPstack}}

== ऐतिहासिक उत्पत्ति ==
मई 1974 में, [[विंट सर्फ़]] और [[बॉब क्हान]] ने नेटवर्क नोड्स के बीच [[ पैकेट बदली |पैकेट बदली]] का उपयोग करके संसाधनों को साझा करने के लिए [[इंटरनेटवर्किंग]] प्रोटोकॉल का वर्णन किया।<ref>{{cite journal |author1=Vinton G. Cerf |author2=Robert E. Kahn |title=''ए प्रोटोकॉल फॉर पैकेट नेटवर्क इंटरकम्यूनिकेशन''|journal=IEEE Transactions on Communications |volume=22 |issue=5 |date=May 1974 |pages=637–648 |doi=10.1109/tcom.1974.1092259 |url=http://ece.ut.ac.ir/Classpages/F84/PrincipleofNetworkDesign/Papers/CK74.pdf |archive-url=https://web.archive.org/web/20160304150203/http://ece.ut.ac.ir/Classpages/F84/PrincipleofNetworkDesign/Papers/CK74.pdf |archive-date=March 4, 2016}}</ref> लेखक फ्रेंच [[साइक्लेड्स]] परियोजना से अवधारणाओं को नए नेटवर्क में सम्मलित करने के लिए जेरार्ड ले लान के साथ काम कर रहे थे।<ref>{{cite web |last1=Bennett |first1=Richard |title=Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate |url=https://www.itif.org/files/2009-designed-for-change.pdf |publisher=Information Technology and Innovation Foundation |access-date=11 September 2017 |page=11 |date=September 2009 |archive-date=29 August 2019 |archive-url=https://web.archive.org/web/20190829092926/http://www.itif.org/files/2009-designed-for-change.pdf |url-status=live }}</ref> परिणामी प्रोटोकॉल की [[विशिष्टता (तकनीकी मानक)]], {{IETF RFC|675}} ([[इंटरनेट]] ट्रांसमिशन कंट्रोल प्रोग्राम की विशिष्टता), विंट सेर्फ़, [[योगेन दलाल]] और कार्ल सनशाइन द्वारा लिखा गया था, और दिसंबर 1974 में प्रकाशित हुआ था। इसमें इंटरनेट शब्द का पहला प्रमाणित उपयोग सम्मलित है, जो इंटरनेटवर्क के लिए शॉर्टहैंड के रूप में है।{{Ref RFC|675}}

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

2004 में, विंट सेर्फ़ और बॉब क्हान को टीसीपी/आईपी पर उनके मूलभूत कार्य के लिए ट्यूरिंग पुरस्कार मिला।<ref>{{cite web |title=रॉबर्ट ई कान - ए.एम. ट्यूरिंग पुरस्कार विजेता|url=https://amturing.acm.org/award_winners/kahn_4598637.cfm |website=amturing.acm.org |access-date=2019-07-13 |archive-date=2019-07-13 |archive-url=https://web.archive.org/web/20190713004804/https://amturing.acm.org/award_winners/kahn_4598637.cfm |url-status=live }}</ref><ref>{{cite web |title=विंटन सर्फ़ - ए.एम. ट्यूरिंग पुरस्कार विजेता|url=https://amturing.acm.org/award_winners/cerf_1083211.cfm |website=amturing.acm.org |access-date=2019-07-13 |archive-date=2021-10-11 |archive-url=https://web.archive.org/web/20211011080741/https://amturing.acm.org/award_winners/cerf_1083211.cfm |url-status=live }}</ref>


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

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

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

टीसीपी समय पर वितरण के अतिरिक्त सटीक वितरण के लिए अनुकूलित है और आउट-ऑफ-ऑर्डर संदेशों या खोए संदेशों के पुन: प्रसारण की प्रतीक्षा करते समय अपेक्षाकृत लंबी देरी (सेकंड के क्रम में) हो सकती है। इसलिए, यह वास्तविक समय के अनुप्रयोगों जैसे [[आईपी पर आवाज]] के लिए विशेष रूप से उपयुक्त नहीं है। ऐसे अनुप्रयोगों के लिए, उपयोगकर्ता डेटाग्राम प्रोटोकॉल (यूडीपी) पर चलने वाले [[वास्तविक समय परिवहन प्रोटोकॉल]] (आरटीपी) जैसे प्रोटोकॉल सामान्यतः इसके अतिरिक्त अनुशंसित होते हैं।<ref name=comer>{{cite book |last=Comer |first=Douglas E. |author-link=Douglas Comer |title=Internetworking with TCP/IP: Principles, Protocols, and Architecture |publisher=Prentice Hall |year=2006 |edition=5th |volume=1 |isbn=978-0-13-187671-2}}</ref>
टीसीपी विश्वसनीय बाइट स्ट्रीम डिलीवरी सेवा है जो गारंटी देती है कि प्राप्त सभी बाइट समान होंगे और उसी क्रम में भेजे गए थे। चूंकि कई नेटवर्क द्वारा पैकेट स्थानांतरण विश्वसनीय नहीं है, इसलिए टीसीपी पुन: प्रसारण के साथ सकारात्मक पावती के रूप में जानी जाने वाली तकनीक का उपयोग करके इसे प्राप्त करता है। इसके लिए यह आवश्यक है कि प्राप्तकर्ता डेटा प्राप्त करते ही [[पावती (डेटा नेटवर्क)]] संदेश के साथ प्रतिक्रिया करे। प्रेषक प्रत्येक पैकेट का रिकॉर्ड रखता है जो वह भेजता है और पैकेट भेजे जाने के समय से टाइमर रखता है। यदि पावती प्राप्त करने से पहले टाइमर समाप्त हो जाता है तो प्रेषक पैकेट को फिर से प्रसारित करता है। पैकेट खो जाने या दूषित होने की स्थिति में टाइमर की आवश्यकता होती है।<ref name=comer/>

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

== टीसीपी खंड संरचना ==
ट्रांसमिशन कंट्रोल प्रोटोकॉल डेटा स्ट्रीम से डेटा को स्वीकार करता है, इसे चंक्स में विभाजित करता है, और टीसीपी हेडर जोड़ता है जो टीसीपी सेगमेंट बनाता है। टीसीपी खंड तब इंटरनेट प्रोटोकॉल (आईपी) डेटाग्राम में [[एनकैप्सुलेशन (नेटवर्किंग)]] होता है, और साथियों के साथ आदान-प्रदान होता है।<ref>{{cite web|url=http://www.linktionary.com/t/tcp.html|title=टीसीपी (ट्रांसमिशन कंट्रोल प्रोटोकॉल)|access-date=2019-06-26|archive-date=2013-04-07|archive-url=https://web.archive.org/web/20130407215545/http://www.linktionary.com/t/tcp.html|url-status=live}}</ref>
टीसीपी पैकेट शब्द अनौपचारिक और औपचारिक उपयोग दोनों में प्रकट होता है, जबकि अधिक सटीक शब्दावली खंड में टीसीपी [[प्रोटोकॉल डेटा यूनिट]] (पीडीयू), डेटाग्राम को संदर्भित करता है।{{Ref RFC|791}}{{rp|pages=5-6}} IP PDU के लिए, और [[सूचना श्रंखला तल]] PDU के लिए फ़्रेम:

प्रक्रियाएं टीसीपी पर कॉल करके और तर्कों के रूप में डेटा के बफ़र्स पास करके डेटा संचारित करती हैं। टीसीपी इन बफ़र्स से डेटा को खंडों में संकुलित करता है और इंटरनेट मॉड्यूल पर कॉल करता है [उदा। आईपी] प्रत्येक खंड को गंतव्य टीसीपी तक पहुंचाने के लिए।{{Ref RFC|9293}}

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

{| class="wikitable" style="margin: 0 auto; text-align:center"
|+टीसीपी सेगमेंट हेडर
|-
! colspan="2" | ''Offsets''
! style="border-left:1px; text-align:left;" colspan="10" | 0
! style="border-left:1px; text-align:left;" colspan="10" | 1
! style="border-left:1px; text-align:left;" colspan="10" | 2
! style="border-left:1px; text-align:left;" colspan="2"  | 3
|-
! [[Octet (computing)|Octet]] !! [[Bit]]
! style="text-align:left;" | 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9
! style="text-align:left;" | 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9
! style="text-align:left;" | 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9
! style="text-align:left;" | 0 !! 1
|-
! 0
! 0
| colspan="16"| सोर्स पोर्ट || colspan="16" | गंतव्य पोर्ट
|-
! 4
!32
| colspan="32"| अनुक्रम संख्या 
|-
! 8
!64
| colspan="32"| पावती संख्या (यदि एसीसी सेट है)
|-
! 12
! 96
| colspan="4"| डेटा ऑफसेट || colspan="4" | सुरक्षित<br/>'''0 0 0 0''' || {{Vertical text|CWR}}||{{Vertical text|ECE}}||{{Vertical text|URG}}||{{Vertical text|ACK}}||{{Vertical text|PSH}}||{{Vertical text|RST}}||{{Vertical text|SYN}}||{{Vertical text|FIN}}|| colspan="16"| विंडो Size
|-
! 16
!128
|colspan="16"| योग जांच करना || colspan="16" | तत्काल सूचक (if URG set)
|-
! 20<br/>
!160<br/>
| colspan="32" rowspan="3" style="background:#ffd0d0;"| विकल्प (यदि डेटा ऑफ़सेट> 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 को ऐतिहासिक स्थिति में ले जाया गया।<ref>{{Cite web |title=Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic |url=https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/ |access-date=2023-04-18 |website=datatracker.ietf.org |language=en}}</ref>
झंडे (8 बिट्स): निम्नानुसार 8 1-बिट झंडे (नियंत्रण बिट्स) सम्मलित हैं:
:*CWR (1 बिट): कंजेशन विंडो रिड्यूस्ड (CWR) फ्लैग भेजने वाले होस्ट द्वारा यह इंगित करने के लिए सेट किया गया है कि इसे ECE फ्लैग सेट के साथ TCP सेगमेंट प्राप्त हुआ है और इसने कंजेशन कंट्रोल मैकेनिज्म में प्रतिक्रिया दी है।{{efn|name=added3168|Added to header by RFC 3168}}
:*ECE (1 बिट): ECN-Echo की दोहरी भूमिका होती है, जो एसवाईएन ध्वज के मान पर निर्भर करता है। ये दर्शाता है:
::*यदि एसवाईएन फ़्लैग (1) सेट है, तो TCP पीयर [[स्पष्ट भीड़ अधिसूचना]] सक्षम है।
::*यदि एसवाईएन फ्लैग स्पष्ट (0) है, कि IP हेडर में कंजेशन एक्सपीरियंस्ड फ्लैग सेट (ECN=11) वाला पैकेट सामान्य ट्रांसमिशन के दौरान प्राप्त हुआ था।{{efn|name=added3168}} यह टीसीपी प्रेषक को नेटवर्क कंजेशन (या आसन्न कंजेशन) के संकेत के रूप में कार्य करता है।
:*URG (1 बिट): इंगित करता है कि तत्काल सूचक क्षेत्र महत्वपूर्ण है
:*एसीके (1 बिट): इंगित करता है कि पावती क्षेत्र महत्वपूर्ण है। क्लाइंट द्वारा भेजे गए शुरुआती एसवाईएन पैकेट के बाद सभी पैकेटों में यह फ्लैग सेट होना चाहिए।
:*PSH (1 बिट): पुश फंक्शन। बफ़र किए गए डेटा को प्राप्त करने वाले एप्लिकेशन को पुश करने के लिए कहता है।
:*RST (1 बिट): कनेक्शन को रीसेट करें
: * एसवाईएन (1 बिट): अनुक्रम संख्याओं को सिंक्रनाइज़ करें। केवल प्रत्येक छोर से भेजे गए पहले पैकेट में यह फ्लैग सेट होना चाहिए। कुछ अन्य झंडे और क्षेत्र इस ध्वज के आधार पर अर्थ बदलते हैं, और कुछ केवल तभी मान्य होते हैं जब यह सेट होता है, और अन्य जब यह स्पष्ट होता है।
:*FIN (1 बिट): प्रेषक से अंतिम पैकेट
विंडो आकार (16 बिट्स): प्राप्त विंडो का आकार, जो विंडो आकार इकाइयों की संख्या निर्दिष्ट करता है{{efn|Windows size units are, by default, bytes.}} कि इस खंड का प्रेषक वर्तमान में प्राप्त करने का इच्छुक है।{{efn|Window size is relative to the segment identified by the sequence number in the acknowledgment field.}} (देखना {{slink||फ्लो कंट्रोल }} और {{slink||विंडो स्केलिंग}}.)
; [[ अंततः, | अंततः,]] (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; पृष्ठभूमि:#सीसीसी; >[<sup></code></sup>एसवाईएन ]. विकल्प-प्रकार और मानक लंबाई (विकल्प-प्रकार, विकल्प-लंबाई) के रूप में दी गई है।
:{| class="wikitable"
|-
! विकल्प-प्रकार
! विकल्प-लंबाई
! विकल्प-डेटा
! उद्देश्य
! टिप्पणियाँ
|-
|0 
|{{n/a}}
|{{n/a}}
|विकल्प सूची का अंत
|
|-
|1
|{{n/a}}
|{{n/a}}
|कोई ऑपरेशन नहीं
|श्रेष्ठतर प्रदर्शन के लिए 32-बिट सीमाओं पर विकल्प फ़ील्ड को संरेखित करने के लिए इसका उपयोग किया जा सकता है।
|-
|2
|4
|SS
|अधिकतम अनुभाग माप
|देखे {{slink||Maximum segment size}} <sup><code style="color:#000; background:#ccc;">[एसवाईएन ]</code></sup>
|-
|3
|3
|S
|विंडोज स्केल
|देखे {{slink||Window scaling}} for details<ref>{{cite IETF |url=https://tools.ietf.org/html/rfc1323#page-9 |RFC=1323 |title=TCP Extensions for High Performance |section=2.2 }} {{Webarchive|url=https://web.archive.org/web/20200813202746/https://tools.ietf.org/html/rfc1323#page-9 |date=2020-08-13 }}</ref> <sup><code style="color:#000; background:#ccc;">[एसवाईएन ]</code></sup>
|-
|4
|2
|{{n/a}}
|चुनिंदा पावती की अनुमति है
|देखे {{slink||Selective acknowledgments}} for details{{Ref RFC|2018|rsection=2}}<sup><code style="color:#000; background:#ccc;">[एसवाईएन ]</code></sup>
|-
|5
|N (10, 18, 26, or 34)
|BBBB, EEEE, ...
|चयनात्मक पावती (सैक ){{Ref RFC|2018|rsection=3}}
|इन पहले दो बाइट्स के बाद 1-4 ब्लॉकों की एक सूची होती है, जिन्हें चुनिंदा रूप से स्वीकार किया जाता है, जिसे 32-बिट स्टार्ट/एंड पॉइंटर्स के रूप में निर्दिष्ट किया जाता है।
|-
|8
|10
|TTTT, EEEE
|टाइमस्टैम्प और पिछले टाइमस्टैम्प की प्रतिध्वनि 
|विवरण के लिए {{slink||TCP टाइमस्टैम्प}} देखें<ref>{{cite journal|url=https://tools.ietf.org/html/rfc1323#page-11|title=RFC 1323, TCP Extensions for High Performance, Section 3.2|year=1992 |doi=10.17487/RFC1323 |access-date=2009-09-07|archive-date=2009-09-05|archive-url=https://web.archive.org/web/20090905201334/http://tools.ietf.org/html/rfc1323#page-11|url-status=live|last1=Jacobson |first1=V. |last2=Braden |first2=R. |last3=Borman |first3=D. }}</ref>
|}
:शेष विकल्प-प्रकार के मूल्य ऐतिहासिक, अप्रचलित, प्रयोगात्मक, अभी तक मानकीकृत नहीं हैं, या असाइन नहीं किए गए हैं। विकल्प संख्या असाइनमेंट IANA द्वारा बनाए रखा जाता है।<ref>{{cite web|url=https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1|title=Transmission Control Protocol (TCP) Parameters: TCP Option Kind Numbers|publisher=IANA|access-date=2017-10-19|archive-date=2017-10-02|archive-url=https://web.archive.org/web/20171002210157/http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1|url-status=live}}</ref>
पैडिंग: टीसीपी हेडर पैडिंग का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि टीसीपी हेडर समाप्त होता है, और डेटा 32-बिट सीमा पर प्रारंभिक होता है। पैडिंग शून्य से बना है।{{Ref RFC|9293}}

== प्रोटोकॉल ऑपरेशन ==
[[File:Tcp state diagram fixed new.svg|right|thumbnail|250px|सरलीकृत टीसीपी राज्य आरेख। अधिक विस्तृत आरेखों के लिए [http://www.medianet.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf TCP EFSM आरेख] देखें, जिसमें स्थापित स्थिति पर विवरण सम्मलित है।]]टीसीपी प्रोटोकॉल संचालन को तीन चरणों में विभाजित किया जा सकता है। कनेक्शन स्थापना बहु-चरण हैंडशेक प्रक्रिया है जो डेटा ट्रांसफर चरण में प्रवेश करने से पहले कनेक्शन स्थापित करती है। डेटा ट्रांसफर पूरा होने के बाद, कनेक्शन समाप्ति कनेक्शन बंद कर देती है और सभी आवंटित संसाधनों को छोड़ देती है।

टीसीपी कनेक्शन ऑपरेटिंग सिस्टम द्वारा संसाधन के माध्यम से प्रबंधित किया जाता है जो संचार के लिए स्थानीय अंत-बिंदु, [[इंटरनेट सॉकेट]] का प्रतिनिधित्व करता है। टीसीपी कनेक्शन के जीवनकाल के दौरान, स्थानीय समापन बिंदु [[राज्य (कंप्यूटर विज्ञान)]] परिवर्तनों की श्रृंखला से गुजरता है:{{Ref RFC|9293|section=3.3.2|notes=no}}

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


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

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

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

=== कनेक्शन समाप्ति ===
[[File:TCP CLOSE.svg|right|thumbnail|260px|कनेक्शन समाप्ति]]कनेक्शन समाप्ति चरण चार-तरफ़ा हैंडशेक का उपयोग करता है, जिसमें कनेक्शन के प्रत्येक पक्ष स्वतंत्र रूप से समाप्त होते हैं। जब कोई समापन बिंदु अपने आधे कनेक्शन को रोकना चाहता है, तो वह फिन पैकेट भेजता है, जिसे दूसरा छोर एसीके के साथ स्वीकार करता है। इसलिए, विशिष्ट आंसू-डाउन के लिए प्रत्येक टीसीपी एंडपॉइंट से फिन और एसीके सेगमेंट की जोड़ी की आवश्यकता होती है। पहले एफआईएन भेजने वाले पक्ष ने अंतिम एसीके के साथ प्रतिक्रिया दी है, यह अंततः कनेक्शन बंद करने से पहले टाइमआउट की प्रतीक्षा करता है, जिसके दौरान स्थानीय बंदरगाह नए कनेक्शन के लिए अनुपलब्ध है; ट्रांज़िट में एसीके खो जाने की स्थिति में यह स्थिति TCP क्लाइंट को सर्वर को अंतिम पावती भेजने देती है। समय अवधि कार्यान्वयन-निर्भर है, किन्तु कुछ सामान्य मान 30 सेकंड, 1 मिनट और 2 मिनट हैं। समय समाप्त होने के बाद, क्लाइंट बंद स्थिति में प्रवेश करता है और स्थानीय पोर्ट नए कनेक्शन के लिए उपलब्ध हो जाता है।<ref>{{Cite book |last=Kurose |first=James F. |url=https://www.worldcat.org/oclc/936004518 |title=Computer networking : a top-down approach |date=2017 |others=Keith W. Ross |isbn=978-0-13-359414-0 |edition=7th |location=Harlow, England |pages=286 |oclc=936004518}}</ref>
3-तरफ़ा हैंडशेक द्वारा कनेक्शन को समाप्त करना भी संभव है, जब होस्ट A FIN भेजता है और होस्ट B FIN और एसीके के साथ उत्तर देता है (दो चरणों को में मिलाकर) और एसीके के साथ होस्ट A का उत्तर देता है।<ref>{{cite book|last= Tanenbaum|first= Andrew S.|author-link= Andrew S. Tanenbaum|title= कंप्यूटर नेटवर्क|edition= Fourth|date= 2003-03-17|publisher= Prentice Hall|isbn= 978-0-13-066102-9|url= https://archive.org/details/computernetworks00tane_2}}</ref>
कुछ ऑपरेटिंग सिस्टम, जैसे [[Linux]] और [[HP-UX]], हाफ-डुप्लेक्स क्लोज सीक्वेंस लागू करें। यदि होस्ट सक्रिय रूप से कनेक्शन बंद कर देता है, जबकि अभी भी अपठित इनकमिंग डेटा उपलब्ध है, तो होस्ट FIN के अतिरिक्त सिग्नल RST (किसी भी प्राप्त डेटा को खोना) भेजता है। यह आश्वस्त करता है कि टीसीपी एप्लिकेशन को पता है कि डेटा हानि हुई थी।{{Ref RFC|1122|section=4.2.2.13|notes=no}}

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

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

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

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

=== डेटा ट्रांसफर ===
उपयोगकर्ता डेटाग्राम प्रोटोकॉल की तुलना में ट्रांसमिशन कंट्रोल प्रोटोकॉल कई प्रमुख विशेषताओं में भिन्न है:
* आदेशित डेटा स्थानांतरण: गंतव्य होस्ट अनुक्रम संख्या के अनुसार खंडों को पुनर्व्यवस्थित करता है<ref name=comer/>* खोए हुए पैकेटों का पुनर्प्रसारण: किसी भी संचयी धारा को स्वीकार नहीं किया जाता है, जिसे पुन: प्रेषित किया जाता है<ref name=comer/>* त्रुटि मुक्त डेटा ट्रांसफर: दूषित पैकेट को खोया हुआ माना जाता है और फिर से भेजा जाता है<ref>{{cite web |url=http://www.linfo.org/tcp.html |title=टीसीपी परिभाषा|access-date=2011-03-12 |archive-date=2020-05-06 |archive-url=https://web.archive.org/web/20200506183752/http://www.linfo.org/tcp.html |url-status=live }}</ref>
* प्रवाह नियंत्रण: विश्वसनीय वितरण की गारंटी के लिए प्रेषक द्वारा डेटा स्थानांतरित करने की दर को सीमित करता है। रिसीवर प्रेषक को लगातार संकेत देता है कि कितना डेटा प्राप्त किया जा सकता है। जब प्राप्तकर्ता होस्ट का बफ़र भर जाता है, तो अगली पावती स्थानांतरण को निलंबित कर देती है और बफ़र में डेटा को संसाधित करने की अनुमति देती है।<ref name=comer/>* संकुलन नियंत्रण: खोए हुए पैकेट (जमाव के कारण अनुमानित) डेटा वितरण दर में कमी को ट्रिगर करते हैं<ref name=comer/>



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

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

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

जब टीसीपी सेगमेंट को फिर से प्रेषित किया जाता है, तो यह मूल वितरण प्रयास के समान क्रम संख्या को बनाए रखता है। वितरण और तार्किक डेटा ऑर्डरिंग के इस सम्मिश्रण का अर्थ है कि, जब पुन: प्रसारण के बाद पावती प्राप्त होती है, तो प्रेषक यह नहीं बता सकता है कि मूल संचरण या पुन: प्रसारण को स्वीकार किया जा रहा है, तथाकथित पुनर्संचरण अस्पष्टता।{{sfn|Karn|Partridge|1991|p=364}} पुनर्संचरण अस्पष्टता के कारण टीसीपी जटिलता उत्पन्न करता है।{{sfn|Iyengar|Swett|2021|loc=4.2. Monotonically Increasing Packet Numbers}}

=== डुपैक-आधारित पुनर्संचरण ===
यदि धारा में खंड (जैसे खंड संख्या 100) खो जाता है, तो रिसीवर उस खंड संख्या (100) से ऊपर के पैकेट को स्वीकार नहीं कर सकता क्योंकि यह संचयी एसीके का उपयोग करता है। इसलिए रिसीवर दूसरे डेटा पैकेट की प्राप्ति पर पैकेट 99 को फिर से स्वीकार करता है। यह डुप्लिकेट पावती पैकेट हानि के लिए संकेत के रूप में उपयोग की जाती है। अर्थात्, यदि प्रेषक को तीन डुप्लिकेट पावती प्राप्त होती हैं, तो यह अंतिम अस्वीकृत पैकेट को पुनः प्रेषित करता है। तीन की सीमा का उपयोग किया जाता है क्योंकि नेटवर्क डुप्लिकेट पावती के कारण सेगमेंट को पुन: व्यवस्थित कर सकता है। पुनर्क्रमित करने के कारण नकली पुन: प्रसारण से बचने के लिए इस सीमा का प्रदर्शन किया गया है।<ref>{{cite journal|last1=Mathis|last2=Mathew|last3=Semke|last4=Mahdavi|last5=Ott|title=टीसीपी कंजेशन परिहार एल्गोरिथम का मैक्रोस्कोपिक व्यवहार|journal=ACM SIGCOMM Computer Communication Review|volume=27|issue=3|pages=67–82|year=1997|doi=10.1145/263932.264023|citeseerx=10.1.1.40.7002|s2cid=1894993}}</ref> कुछ टीसीपी कार्यान्वयन प्राप्त किए गए सेगमेंट के बारे में स्पष्ट प्रतिक्रिया प्रदान करने के लिए चयनात्मक पावती (सैक s) का उपयोग करते हैं। यह टीसीपी की सही सेगमेंट को फिर से प्रसारित करने की क्षमता में काफी सुधार करता है।

यदि डुप्लिकेट पावती थ्रेशोल्ड से परे पुन: क्रमित किया जाता है, तो पुनर्संचरण अस्पष्टता नकली तेज़ पुन: प्रसारण और भीड़ से बचाव का कारण बन सकती है।{{sfn|Ludwig|Meyer|2003|p=4}}

=== समयबाह्य-आधारित पुन: प्रसारण ===
जब कोई प्रेषक किसी खंड को प्रसारित करता है, तो यह पावती के आगमन के समय के रूढ़िवादी अनुमान के साथ टाइमर को आरंभ करता है। यदि टाइमर समाप्त हो जाता है, तो सेगमेंट को पिछले मूल्य के दोगुने के नए टाइमआउट थ्रेशोल्ड के साथ फिर से प्रसारित किया जाता है, जिसके परिणामस्वरूप [[घातीय बैकऑफ़]] व्यवहार होता है। सामान्यतः , प्रारंभिक टाइमर मान है <math>\text{smoothed RTT} + \max(G, 4\times\text{RTT variation})</math>, कहाँ <math>G</math> घड़ी की ग्रैन्युलैरिटी है।{{Ref RFC|6298}}{{rp|page=2}} यह दोषपूर्ण या दुर्भावनापूर्ण तत्वों के कारण होने वाले अत्यधिक ट्रांसमिशन ट्रैफ़िक से सुरक्षा प्रदान करता है, जैसे कि [[मैन-इन-द-बीच हमला|मैन-इन-द-बीच अटैक]] डिनायल ऑफ़ सर्विस अटैक वर करता है।

नुकसान की वसूली के लिए सटीक आरटीटी अनुमान महत्वपूर्ण हैं, क्योंकि यह प्रेषक को यह मानने की अनुमति देता है कि पर्याप्त समय बीतने के बाद अनजाने पैकेट खो गया है (अर्थात , आरटीओ समय का निर्धारण)।{{sfn|Zhang|1986|p=399}} पुनर्संचारण अस्पष्टता प्रेषक के RTT के अनुमान को सटीक नहीं बना सकती है।{{sfn|Zhang|1986|p=399}} परिवर्ती RTT वाले परिवेश में, नकली टाइमआउट हो सकता है:{{sfn|Karn|Partridge|1991|p=365}} यदि RTT का अनुमान कम लगाया जाता है, तो RTO सक्रिय हो जाता है और अनावश्यक पुनःसंचारण और धीमी गति से प्रारंभ करता है। नकली पुनर्संचरण के बाद, जब मूल प्रसारण के लिए पावती आती है, तो प्रेषक को यह विश्वास हो सकता है कि वे पुनर्संचरण को स्वीकार कर रहे हैं और गलत तरीके से निष्कर्ष निकालते हैं, कि मूल संचरण और पुन: प्रसारण के बीच भेजे गए खंड खो गए हैं, जिससे आगे अनावश्यक पुन: प्रसारण हो सकता है। लिंक वास्तव में भीड़भाड़ वाला हो जाता है;{{sfn|Ludwig|Katz|2000|p=31-33}}{{sfn|Gurtov|Ludwig|2003|p=2}} चयनात्मक अभिस्वीकृति इस प्रभाव को कम कर सकती है।{{sfn|Gurtov|Floyd|2004|p=1}} RFC 6298 निर्दिष्ट करता है कि RTT का आकलन करते समय कार्यान्वयनों को पुन: प्रेषित खंडों का उपयोग नहीं करना चाहिए।{{sfn|Paxson|Allman|Chu|Sargent|2011|p=4}} कर्ण का एल्गोरिद्म यह सुनिश्चित करता है कि आरटीओ को समायोजित करने से पहले स्पष्ट पावती मिलने तक प्रतीक्षा करके—आखिरकार— अच्छा आरटीटी अनुमान तैयार किया जाएगा।{{sfn|Karn|Partridge|1991|p=370-372}} नकली पुन: प्रसारण के बाद, चूंकि, इस प्रकार की स्पष्ट पावती आने से पहले महत्वपूर्ण समय लग सकता है, अंतरिम में प्रदर्शन खराब हो सकता है।{{sfn|Allman|Paxson|1999|p=268}} टीसीपी टाइमस्टैम्प भी आरटीओ की स्थापना में पुनर्संचरण अस्पष्टता समस्या का समाधान करते हैं,{{sfn|Paxson|Allman|Chu|Sargent|2011|p=4}} चूंकि वे जरूरी नहीं कि आरटीटी अनुमान में सुधार करें।{{sfn|Borman|Braden|Jacobson|2014|p=7}}

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

शुद्धता सुनिश्चित करने के लिए चेकसम फ़ील्ड सम्मलित है; देखना {{slink||चेकसम गणना}} जानकारी के लिए। टीसीपी चेकसम आधुनिक मानकों द्वारा कमजोर जांच है और सामान्यतः टीसीपी और आईपी दोनों के नीचे [[परत 2]] पर चक्रीय अतिरेक जांच अखंडता जांच के साथ जोड़ा जाता है, जैसे कि [[पॉइंट-टू-पॉइंट प्रोटोकॉल]] या [[ईथरनेट]] फ्रेम में उपयोग किया जाता है। चूंकि, सीआरसी-संरक्षित हॉप्स के बीच पैकेट में त्रुटियों का परिचय सामान्य है और 16-बिट टीसीपी चेकसम इनमें से अधिकतर को पकड़ लेता है।<ref>{{Cite journal |last1=Stone |last2=Partridge |title=जब सीआरसी और टीसीपी चेकसम असहमत हों|journal=ACM SIGCOMM Computer Communication Review |pages=309–319 |year=2000 |url=http://citeseer.ist.psu.edu/stone00when.html |doi=10.1145/347059.347561 |citeseerx=10.1.1.27.7611 |isbn=978-1581132236 |s2cid=9547018 |access-date=2008-04-28 |archive-date=2008-05-05 |archive-url=https://web.archive.org/web/20080505024952/http://citeseer.ist.psu.edu/stone00when.html |url-status=live }}</ref>


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

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

[[File:Tcp.svg|right|thumbnail|250px|टीसीपी अनुक्रम संख्या और विंडोज़ प्राप्त करना घड़ी की प्रकार बहुत अधिक व्यवहार करता है। प्राप्त विंडो हर बार शिफ्ट हो जाती है जब रिसीवर प्राप्त करता है और डेटा के नए खंड को स्वीकार करता है। बार जब यह अनुक्रम संख्याओं से बाहर हो जाता है, तो अनुक्रम संख्या 0 पर वापस आ जाती है।]]जब कोई रिसीवर 0 के विंडो आकार का विज्ञापन करता है, तो प्रेषक डेटा भेजना बंद कर देता है और अपना स्थायी टाइमर प्रारंभिक कर देता है। परसिस्ट टाइमर का उपयोग टीसीपी को [[गतिरोध]] की स्थिति से बचाने के लिए किया जाता है, जो तब उत्पन्न हो सकता है जब रिसीवर से बाद का विंडो आकार अपडेट खो जाता है, और रिसीवर से नया विंडो आकार अपडेट प्राप्त होने तक प्रेषक अधिक डेटा नहीं भेज सकता है। जब स्थायी टाइमर समाप्त हो जाता है, तो टीसीपी प्रेषक छोटा पैकेट भेजकर पुनर्प्राप्ति का प्रयास करता है ताकि रिसीवर नए विंडो आकार वाली और पावती भेजकर प्रतिक्रिया दे।

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

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

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

टीसीपी के आधुनिक कार्यान्वयन में चार आपस में जुड़े हुए एल्गोरिदम हैं: टीसीपी कंजेशन कंट्रोल # स्लो स्टार्ट, [[टीसीपी भीड़ से बचाव एल्गोरिथ्म]], [[ तेजी से पुन: प्रेषित |तेजी से पुन: प्रेषित]] और [[ तेजी से पुनःप्राप्ति |तेजी से पुनःप्राप्ति]] ।{{Ref RFC|5681}}

इसके अलावा, प्रेषक रेट्रांस्मिशन टाइमआउट (आरटीओ) का उपयोग करते हैं जो प्रेषक और रिसीवर के बीच अनुमानित [[राउंड ट्रिप समय]] (आरटीटी) के साथ-साथ इस राउंड-ट्रिप समय में अंतर पर आधारित होता है।{{Ref RFC|6298}} आरटीटी के आकलन में बारीकियां हैं। उदाहरण के लिए, प्रेषकों को पुनः प्रेषित पैकेटों के लिए RTT नमूनों की गणना करते समय सावधान रहना चाहिए; सामान्यतः वे कर्ण के एल्गोरिदम या टीसीपी टाइमस्टैम्प का उपयोग करते हैं।{{Ref RFC|7323}} इन अलग-अलग आरटीटी नमूनों का समय के साथ औसत किया जाता है ताकि जैकबसन के एल्गोरिथम का उपयोग करके स्मूथ राउंड ट्रिप टाइम (एसआरटीटी) बनाया जा सके। यह SRTT मान वह है जो राउंड-ट्रिप समय अनुमान के रूप में उपयोग किया जाता है।

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

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

एमएसएस घोषणा को एमएसएस वार्ता भी कहा जा सकता है, किन्तु कड़ाई से बोलते हुए, एमएसएस पर बातचीत नहीं की जाती है। टीसीपी कनेक्शन में डेटा प्रवाह की दो दिशाओं के लिए एमएसएस के दो पूरी प्रकार से स्वतंत्र मूल्यों की अनुमति है,{{Ref RFC|1122}}{{Ref RFC|9293}} इसलिए द्विदिश कनेक्शन के लिए सामान्य एमएसएस कॉन्फ़िगरेशन पर सहमत होने की कोई आवश्यकता नहीं है।

=== चुनिंदा स्वीकृतियां ===
{{see also|SACK Panic}}
मूल टीसीपी द्वारा नियोजित संचयी पावती योजना पर विशुद्ध रूप से विश्वास करने से पैकेट खो जाने पर अक्षमता हो सकती है। उदाहरण के लिए, मान लें कि अनुक्रम संख्या 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 हेडर विकल्प का उपयोग करता है (देखें {{slink||टीसीपी खंड संरचना}} जानकारी के लिए)। सैक का उपयोग व्यापक हो गया है - सभी लोकप्रिय TCP स्टैक इसका समर्थन करते हैं। चयनात्मक पावती का उपयोग [[स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल]] (SCTP) में भी किया जाता है।

चयनात्मक अभिस्वीकृति 'पाखण्डी' हो सकती है, जहां रिसीवर एकतरफा रूप से चुनिंदा स्वीकृत डेटा को छोड़ देता है। RFC 2018 ने इस प्रकार के व्यवहार को हतोत्साहित किया, किन्तु इसे प्रतिबंधित नहीं किया ताकि रिसीवर्स को रेनेजिंग का विकल्प दिया जा सके, उदाहरण के लिए, वे बफर स्पेस से बाहर हो गए।{{sfn|Mathis|Mahdavi|Floyd|Romanow|1996|p=10}} पाखण्डी होने की संभावना प्रेषकों और प्राप्तकर्ताओं दोनों के लिए कार्यान्वयन जटिलता की ओर ले जाती है, और प्रेषक पर मेमोरी लागत भी लगाती है।{{sfn|Iyengar|Swett|2021|loc=4.4. No Reneging}}

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

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

कुछ राउटर और पैकेट फायरवॉल ट्रांसमिशन के दौरान विंडो स्केलिंग फैक्टर को फिर से लिखते हैं। यह अलग-अलग टीसीपी विंडो आकार ग्रहण करने के लिए पक्षों को भेजने और प्राप्त करने का कारण बनता है। परिणाम गैर-स्थिर यातायात है जो बहुत धीमा हो सकता है। दोषपूर्ण राउटर के पीछे कुछ साइटों पर समस्या दिखाई दे रही है।<ref>{{cite web |url=https://lwn.net/Articles/92727/ |title=टीसीपी विंडो स्केलिंग और टूटे राउटर|website=LWN.net |access-date=2016-07-21 |archive-date=2020-03-31 |archive-url=https://web.archive.org/web/20200331213612/https://lwn.net/Articles/92727/ |url-status=live }}</ref>


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

दो टाइमस्टैम्प फ़ील्ड हैं:
* 4-बाइट प्रेषक टाइमस्टैम्प मान (मेरा टाइमस्टैम्प)
* 4-बाइट प्रतिध्वनि उत्तर टाइमस्टैम्प मान (आपसे प्राप्त सबसे हाल का टाइमस्टैम्प)।

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

साथ ही, ईफेल डिटेक्शन एल्गोरिदम टीसीपी टाइमस्टैम्प का उपयोग यह निर्धारित करने के लिए करता है कि क्या रेट्रांस्मिशन हो रहे हैं क्योंकि पैकेट खो गए हैं या बस ऑर्डर से बाहर हैं।<ref>{{IETF RFC|3522}}</ref>
लिनक्स में टीसीपी टाइमस्टैम्प डिफ़ॉल्ट रूप से सक्षम हैं,<ref>{{cite web |title=आईपी sysctl|url=https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt |website=Linux Kernel Documentation |access-date=15 December 2018 |archive-date=5 March 2016 |archive-url=https://web.archive.org/web/20160305080444/https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt |url-status=live }}</ref> और विंडोज सर्वर 2008, 2012 और 2016 में डिफ़ॉल्ट रूप से अक्षम।<ref>{{cite web |last1=Wang |first1=Eve |title=टीसीपी टाइमस्टैम्प अक्षम है|url=https://social.technet.microsoft.com/Forums/office/en-US/6b1e4653-320f-4dbf-8b1a-64d27d8464fc/tcp-timestamp-is-disabled |website=Technet - Windows Server 2012 Essentials |publisher=Microsoft |access-date=2018-12-15 |archive-url=https://web.archive.org/web/20181215225201/https://social.technet.microsoft.com/Forums/office/en-US/6b1e4653-320f-4dbf-8b1a-64d27d8464fc/tcp-timestamp-is-disabled |archive-date=2018-12-15 |url-status=dead }}</ref>
हाल के आंकड़े बताते हैं कि विंडोज सर्वर 2008 के बाद से विंडोज सर्वर समर्थन छोड़ने के कारण टीसीपी टाइमस्टैम्प अपनाने का स्तर ~ 40% पर स्थिर हो गया है।<ref name="2017stats">{{cite web |url=http://profiles.murdoch.edu.au/myprofile/david-murray/files/2012/06/An_Analysis_of_Changing_Enterprise_Network_Traffic_Characteristics-22.pdf |title=एंटरप्राइज़ नेटवर्क ट्रैफ़िक विशेषताओं को बदलने का विश्लेषण|author1=David Murray |author2=Terry Koziniec |author3=Sebastian Zander |author4=Michael Dixon |author5=Polychronis Koutsakis |publisher=The 23rd Asia-Pacific Conference on Communications (APCC 2017) |date=2017 |access-date=3 October 2017 |archive-date=3 October 2017 |archive-url=https://web.archive.org/web/20171003124654/http://profiles.murdoch.edu.au/myprofile/david-murray/files/2012/06/An_Analysis_of_Changing_Enterprise_Network_Traffic_Characteristics-22.pdf |url-status=live }}</ref>


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

अत्यावश्यक सूचक केवल दूरस्थ होस्ट पर प्रसंस्करण को बदलता है और नेटवर्क पर किसी भी प्रसंस्करण को तेज नहीं करता है। क्षमता अलग-अलग प्रणालियों पर अलग-अलग या खराब तरीके से लागू की जाती है या समर्थित नहीं हो सकती है। जहां यह उपलब्ध है, यह मान लेना समझदारी है कि OOB डेटा के केवल बाइट को विश्वसनीय रूप से संभाला जाएगा।<ref>{{cite web |last= Gont |first= Fernando |title= टीसीपी तत्काल डेटा के कार्यान्वयन पर|publisher= 73rd IETF meeting |date= November 2008 |url= http://www.gont.com.ar/talks/IETF73/ietf73-tcpm-urgent-data.ppt |access-date= 2009-01-04 |archive-date= 2019-05-16 |archive-url= https://web.archive.org/web/20190516181338/https://www.gont.com.ar/talks/IETF73/ietf73-tcpm-urgent-data.ppt |url-status= live }}</ref><ref>{{cite book |last= Peterson |first= Larry |title= कंप्यूटर नेटवर्क|url= https://archive.org/details/computernetworks00pete_974 |url-access= limited |publisher= Morgan Kaufmann |year= 2003 |page= [https://archive.org/details/computernetworks00pete_974/page/n419 401] |isbn= 978-1-55860-832-0}}</ref> चूंकि सुविधा का अधिकांशतः उपयोग नहीं किया जाता है, यह कुछ प्लेटफार्मों पर अच्छी प्रकार से परीक्षण नहीं किया गया है और उदाहरण के लिए [[भेद्यता (कंप्यूटिंग)]], [[WinNuke|विनन्यूक]] से जुड़ा हुआ है।

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

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

RFC परिभाषित करता है <code>PSH</code> इस डेटा को प्राप्त करने वाले एप्लिकेशन तक तुरंत भेजने के लिए प्राप्तकर्ता टीसीपी स्टैक को संदेश के रूप में बिट पुश करें।<ref name=comer/>[[बर्कले सॉकेट]]्स का उपयोग करके उपयोगकर्ता स्थान में इसे इंगित या नियंत्रित करने का कोई तरीका नहीं है; इसे केवल [[प्रोटोकॉल स्टैक]] द्वारा नियंत्रित किया जाता है।<ref name="Stevens2006">{{cite book|author=Richard W. Stevens|title=TCP/IP Illustrated. Vol. 1, The protocols|url=https://archive.org/details/tcpipillustrated00stev|url-access=registration|date=November 2011|publisher=Addison-Wesley|isbn=978-0-201-63346-7|pages=Chapter 20}}</ref>


== भेद्यता ==
टीसीपी पर कई प्रकार से अटैक किया जा सकता है। 2009 में पहचाने गए मुद्दों के संभावित न्यूनीकरण के साथ-साथ टीसीपी के गहन सुरक्षा मूल्यांकन के परिणाम प्रकाशित किए गए थे।<ref>{{cite web |url=http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf |title=ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का सुरक्षा आकलन|access-date=2010-12-23 |url-status=bot: unknown |archive-url=https://web.archive.org/web/20090306052826/http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf |archive-date=March 6, 2009 }}</ref> और 2012 के माध्यम से [[आईईटीएफ]] के भीतर पीछा किया गया था।<ref>[https://tools.ietf.org/html/draft-ietf-tcpm-tcp-security Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations]</ref>


===सेवा से वंचित ===
[[आईपी एड्रेस स्पूफिंग]] का उपयोग करके और बार-बार उलझे हुए पैकेट एसवाईएन पैकेट भेजकर, कई एसीके पैकेटों के बाद, अटैक वर सर्वर को बड़ी मात्रा में संसाधनों का उपभोग करने के लिए फर्जी कनेक्शन का ट्रैक रख सकते हैं। इसे एसवाईएन बाढ़ हमले के रूप में जाना जाता है। इस समस्या के प्रस्तावित समाधानों में एसवाईएन कुकीज़ और क्रिप्टोग्राफ़िक पहेलियाँ सम्मलित हैं, चूँकि एसवाईएन कुकीज़ अपनी स्वयं की कमजोरियों के सेट के साथ आती हैं।<ref>{{Cite web |url=http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/ |title=SYN कुकीज़ के साथ क्विक ब्लाइंड TCP कनेक्शन स्पूफिंग|author=Jakob Lell |access-date=2014-02-05 |archive-date=2014-02-22 |archive-url=https://web.archive.org/web/20140222101226/http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-connection-spoofing-with-syn-cookies/ |url-status=live }}</ref> [[सॉकस्ट्रेस]] ऐसा ही अटैक है, जिसे सिस्टम संसाधन प्रबंधन से कम किया जा सकता है।<ref>{{cite web|url=http://www.gont.com.ar/talks/hacklu2009/fgont-hacklu2009-tcp-security.pdf|title=हाल ही में टीसीपी डीओएस (सेवा से वंचित) कमजोरियों के बारे में कुछ अंतर्दृष्टि|access-date=2010-12-23|archive-date=2013-06-18|archive-url=https://web.archive.org/web/20130618235445/http://www.gont.com.ar/talks/hacklu2009/fgont-hacklu2009-tcp-security.pdf|url-status=dead}}</ref> [[Phrack|Phr]]एसीके #66 में TCP पर्सिस्ट टाइमर के शोषण से जुड़े उन्नत DoS हमले का विश्लेषण किया गया था।<ref>{{cite web|url=http://phrack.org/issues.html?issue=66&id=9#article|title=टीसीपी और पर्सिस्ट टाइमर अनंतता का शोषण|access-date=2010-01-22|archive-date=2010-01-22|archive-url=https://web.archive.org/web/20100122131412/http://www.phrack.org/issues.html?issue=66&id=9#article|url-status=live}}</ref> PUSH और एसीके बाढ़ अन्य प्रकार हैं।<ref>{{cite web|url=https://f5.com/glossary/push-and-ack-flood|title=पुश और एसीके बाढ़|website=f5.com|access-date=2017-09-27|archive-date=2017-09-28|archive-url=https://web.archive.org/web/20170928005428/https://f5.com/glossary/push-and-ack-flood|url-status=live}}</ref>



=== कनेक्शन अपहरण ===
{{Main|टीसीपी अनुक्रम भविष्यवाणी अटैक }}
अटैक वर जो टीसीपी सत्र को छिपाने में सक्षम है और पैकेट को पुनर्निर्देशित करता है, वह टीसीपी कनेक्शन को हाईजैक कर सकता है। ऐसा करने के लिए, अटैक वर चल रहे संचार से अनुक्रम संख्या सीखता है और गलत खंड बनाता है जो धारा में अगले खंड की प्रकार दिखता है। इस प्रकार के साधारण हाईजैक के परिणामस्वरूप पैकेट को छोर पर गलत तरीके से स्वीकार किया जा सकता है। जब प्राप्तकर्ता होस्ट कनेक्शन के दूसरी तरफ अतिरिक्त खंड को स्वीकार करता है, तो सिंक्रनाइज़ेशन खो जाता है। हाइजैकिंग को [[ संकल्प आदर्श पत्र पता |संकल्प आदर्श पत्र पता]] (एड्रेस रेजोल्यूशन प्रोटोकॉल) या रूटिंग हमलों के साथ जोड़ा जा सकता है जो पैकेट प्रवाह को नियंत्रित करने की अनुमति देता है, ताकि अपहृत टीसीपी कनेक्शन का स्थायी नियंत्रण प्राप्त किया जा सके।<ref>{{cite web|url=http://www.usenix.org/publications/library/proceedings/security95/joncheray.html|title=Laurent Joncheray, ''Simple Active Attack Against TCP'', 1995|access-date=2007-11-25|archive-date=2007-12-07|archive-url=https://web.archive.org/web/20071207211528/http://www.usenix.org/publications/library/proceedings/security95/joncheray.html|url-status=live}}</ref>
आरएफसी 1948 से पहले अलग आईपी पते का प्रतिरूपण करना मुश्किल नहीं था, जब प्रारंभिक अनुक्रम संख्या सरलता से अनुमान लगाया जा सकता था। इसने अटैक वर को एआरपी या रूटिंग हमलों को तैनात करने की आवश्यकता के बिना, पैकेट के अनुक्रम को आँख बंद करके भेजने की अनुमति दी, जो रिसीवर को अलग आईपी पते से आने का विश्वास होगा: यह सुनिश्चित करने के लिए पर्याप्त है कि प्रतिरूपित आईपी पते का वैध होस्ट नीचे है , या डिनायल-ऑफ-सर्विस हमलों का उपयोग करके इसे उस स्थिति में लाएं। यही कारण है कि प्रारंभिक क्रम संख्या अब यादृच्छिक रूप से चुनी जाती है।

=== टीसीपी वीटो ===
अटैक वर जो छिपकर सुन सकता है और भेजे जाने वाले अगले पैकेट के आकार का अनुमान लगा सकता है, वह रिसीवर को उपस्तिथा कनेक्शन को बाधित किए बिना दुर्भावनापूर्ण पेलोड स्वीकार करने का कारण बन सकता है। अटैक वर दुर्भावनापूर्ण पैकेट को अनुक्रम संख्या और अगले अपेक्षित पैकेट के पेलोड आकार के साथ इंजेक्ट करता है। जब वैध पैकेट अंततः प्राप्त हो जाता है, तो यह पहले से प्राप्त पैकेट के समान अनुक्रम संख्या और लंबाई पाया जाता है और चुपचाप सामान्य डुप्लिकेट पैकेट के रूप में गिरा दिया जाता है - दुर्भावनापूर्ण पैकेट द्वारा वैध पैकेट को वीटो कर दिया जाता है। कनेक्शन हाइजैकिंग के विपरीत, कनेक्शन कभी भी डीसिंक्रनाइज़ नहीं होता है और दुर्भावनापूर्ण पेलोड स्वीकार किए जाने के बाद संचार सामान्य रूप से जारी रहता है। टीसीपी वीटो अटैक वर को संचार पर कम नियंत्रण देता है, किन्तु हमले को विशेष रूप से पहचान के लिए प्रतिरोधी बनाता है। एसीके स्टॉर्म से नेटवर्क ट्रैफिक में बड़ी वृद्धि से बचा जाता है। रिसीवर के लिए एकमात्र सबूत है कि कुछ गलत है, डुप्लिकेट पैकेट है, आईपी नेटवर्क में सामान्य घटना है। वीटो वाले पैकेट भेजने वाले को हमले का कोई सबूत नहीं दिखता.<ref>{{cite book |author1=John T. Hagen |author2=Barry E. Mullins |title=TCP veto: A novel network attack and its application to SCADA protocols |journal=Innovative Smart Grid Technologies (ISGT), 2013 IEEE PES |pages=1–6 |year=2013|doi=10.1109/ISGT.2013.6497785 |isbn=978-1-4673-4896-6 |s2cid=25353177 }}</ref>
अन्य भेद्यता टीसीपी रीसेट अटैक है।

== टीसीपी पोर्ट्स ==
टीसीपी कनेक्शन की पहचान स्रोत पते, स्रोत [[पोर्ट (कंप्यूटर नेटवर्किंग)]], गंतव्य पता, और गंतव्य पोर्ट (या समकक्ष, स्रोत और गंतव्य के लिए [[नेटवर्क सॉकेट]] की जोड़ी, जिनमें से प्रत्येक से बना है) के चार-[[टपल]] द्वारा की जाती है। पते और बंदरगाह का)।{{sfn|Eddy|2022|loc=4. Glossary}}{{sfn|Fairhurst|Trammell|Kuehlewind|2017|p=6}} विभिन्न सेवाओं की पहचान करने के लिए, और होस्ट के बीच कई कनेक्शनों को मल्टीप्लेक्स करने की अनुमति देने के लिए पोर्ट नंबरों का उपयोग किया जाता है।{{sfn|Eddy|2022|loc=2.2. Key TCP Concepts}} टीसीपी [[16-बिट]] पोर्ट नंबरों का उपयोग करता है, प्रत्येक स्रोत और गंतव्य पोर्ट के लिए 65,536 संभावित मानों का स्थान प्रदान करता है।{{sfn|Eddy|2022|loc=3.1. Header Format}} पतों पर कनेक्शन पहचान की निर्भरता का अर्थ है कि टीसीपी कनेक्शन एकल नेटवर्क पथ से बंधे हैं; टीसीपी अन्य मार्गों का उपयोग नहीं कर सकता है जो [[मल्टीहोम होस्ट]] उपलब्ध हैं, और समापन बिंदु का पता बदलने पर कनेक्शन टूट जाता है।{{sfn|Paasch|Bonaventure|2014|p=51}}

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

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

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

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

[[टीसीपी इंटरएक्टिव]] (आईटीसीपी) <ref>{{cite web|url=http://www.medianet.kent.edu/projects_files/projectITCP.html|title=टीसीपी इंटरएक्टिव|website=www.medianet.kent.edu|access-date=2008-04-28|archive-date=2008-08-20|archive-url=https://web.archive.org/web/20080820175714/http://www.medianet.kent.edu/projects_files/projectITCP.html|url-status=live}}</ref> टीसीपी एक्सटेंशन में शोध प्रयास है जो एप्लिकेशन को टीसीपी इवेंट्स की सदस्यता लेने और हैंडलर घटकों को पंजीकृत करने की अनुमति देता है जो एप्लिकेशन-सहायता वाले भीड़ नियंत्रण सहित विभिन्न उद्देश्यों के लिए एप्लिकेशन लॉन्च कर सकते हैं।

[[मल्टीपाथ टीसीपी]] (एमपीटीसीपी) {{ref RFC|6182}}{{ref RFC|6824}} IETF के भीतर सतत प्रयास है जिसका उद्देश्य संसाधनों के उपयोग को अधिकतम करने और अतिरेक को बढ़ाने के लिए TCP कनेक्शन को कई रास्तों का उपयोग करने की अनुमति देना है। वायरलेस नेटवर्क के संदर्भ में मल्टीपाथ टीसीपी द्वारा दी जाने वाली अतिरेक विभिन्न नेटवर्कों के साथ उपयोग को सक्षम बनाता है, जो उच्चतर थ्रूपुट और बेहतर हैंडओवर क्षमताओं को लाता है। मल्टीपाथ टीसीपी डेटासेंटर वातावरण में प्रदर्शन लाभ भी लाता है।<ref>{{Cite journal |last1=Raiciu |last2=Barre |last3=Pluntke |last4=Greenhalgh |last5=Wischik |last6=Handley |title=मल्टीपाथ टीसीपी के साथ डेटासेंटर के प्रदर्शन और मजबूती में सुधार|journal=ACM SIGCOMM Computer Communication Review |volume=41 |issue=4 |pages=266 |year=2011 |url=http://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp |doi=10.1145/2043164.2018467 |citeseerx=10.1.1.306.3863 |access-date=2011-06-29 |archive-date=2020-04-04 |archive-url=https://web.archive.org/web/20200404105843/https://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp |url-status=dead }}</ref> संदर्भ कार्यान्वयन<ref>{{cite web|url=http://www.multipath-tcp.org/|title=मल्टीपाथ टीसीपी - लिनक्स कर्नेल कार्यान्वयन|access-date=2013-03-24|archive-date=2013-03-27|archive-url=https://web.archive.org/web/20130327041817/http://www.multipath-tcp.org/|url-status=live}}</ref> मल्टीपाथ टीसीपी का लिनक्स कर्नेल में विकास किया जा रहा है।<ref>{{Cite journal |last1=Raiciu |last2=Paasch |last3=Barre |last4=Ford |last5=Honda |last6=Duchene |last7=Bonaventure |last8=Handley |title=How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP |journal=Usenix NSDI |pages=399–412 |year=2012 |url=https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp |access-date=2013-03-24 |archive-date=2013-06-03 |archive-url=https://web.archive.org/web/20130603045638/https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp |url-status=live }}</ref> Multipath TCP का उपयोग iPhones, iPads और Macs पर सिरी वॉइस रिकग्निशन एप्लिकेशन को सपोर्ट करने के लिए किया जाता है <ref>{{Cite journal |last1=Bonaventure |last2=Seo |title=बहुपथ टीसीपी परिनियोजन|journal=IETF Journal |year=2016 |url=https://www.ietfjournal.org/multipath-tcp-deployments/ |access-date=2017-01-03 |archive-date=2020-02-23 |archive-url=https://web.archive.org/web/20200223070325/https://www.ietfjournal.org/multipath-tcp-deployments/ |url-status=live }}</ref>
टीसीपी क्रिप्ट जुलाई 2010 में टीसीपी में सीधे परिवहन-स्तर एन्क्रिप्शन प्रदान करने के लिए प्रस्तावित एक्सटेंशन है। इसे पारदर्शी रूप से काम करने के लिए डिज़ाइन किया गया है और इसके लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है। [[ परिवहन परत सुरक्षा |परिवहन परत सुरक्षा]] (एसएसएल) के विपरीत, टीसीपी क्रिप्ट स्वयं प्रमाणीकरण प्रदान नहीं करता है, किन्तु ऐसा करने के लिए एप्लिकेशन को सरल प्रिमिटिव प्रदान करता है। {{As of|2010}}, पहला टीसीपी क्रिप्ट IETF ड्राफ्ट प्रकाशित किया गया है और कई प्रमुख प्लेटफॉर्मों के लिए कार्यान्वयन उपस्तिथ हैं।

[[टीसीपी फास्ट ओपन]] दो एंडपॉइंट्स के बीच लगातार टीसीपी कनेक्शन खोलने में तेजी लाने के लिए विस्तार है। यह क्रिप्टोग्राफ़िक कुकी का उपयोग करके तीन-तरफ़ा हैंडशेक को छोड़ कर काम करता है। यह T/TCP नामक पहले के प्रस्ताव के समान है, जिसे सुरक्षा मुद्दों के कारण व्यापक रूप से नहीं अपनाया गया था।<ref name=lwn>{{cite news |author=Michael Kerrisk |date=2012-08-01 |title=TCP Fast Open: expediting web services |publisher=[[LWN.net]] |url=https://lwn.net/Articles/508865/ |access-date=2014-07-21 |archive-date=2014-08-03 |archive-url=https://web.archive.org/web/20140803234830/http://lwn.net/Articles/508865/ |url-status=live }}</ref> टीसीपी फास्ट ओपन को 2014 में आरएफसी 7413 के रूप में प्रकाशित किया गया था।<ref name=":0">{{cite journal|url=https://tools.ietf.org/html/rfc7413|title=टीसीपी फास्ट ओपन|author1=Yuchung Cheng|author2=Jerry Chu|date=December 2014|publisher=IETF|access-date=10 January 2015|author3=Sivasankar Radhakrishnan|author4=Arvind Jain|doi=10.17487/RFC7413 |name-list-style=amp|archive-date=1 January 2015|archive-url=https://web.archive.org/web/20150101001102/http://tools.ietf.org/html/rfc7413|url-status=live}}</ref>
मई 2013 में प्रस्तावित, [[आनुपातिक दर में कमी]] (पीआरआर) [[Google]] इंजीनियरों द्वारा विकसित टीसीपी एक्सटेंशन है। PRR यह सुनिश्चित करता है कि रिकवरी के बाद TCP विंडो का आकार TCP कंजेशन नियंत्रण के जितना करीब हो सके धीमी शुरुआत थ्रेसहोल्ड जितना संभव हो सके।<ref>{{cite journal|title=RFC 6937 - Proportional Rate Reduction for TCP|date=May 2013|url=http://tools.ietf.org/html/rfc6937|access-date=6 June 2014|last1=Mathis|first1=Matt|last2=Dukkipati|first2=Nandita|last3=Cheng|first3=Yuchung|doi=10.17487/RFC6937 |archive-date=14 July 2014|archive-url=https://web.archive.org/web/20140714222922/http://tools.ietf.org/html/rfc6937|url-status=live}}</ref> एल्गोरिदम को पुनर्प्राप्ति की गति में सुधार करने के लिए डिज़ाइन किया गया है और लिनक्स 3.2+ कर्नेल में डिफ़ॉल्ट भीड़ नियंत्रण एल्गोरिदम है।<ref>{{cite book|last1=Grigorik|first1=Ilya|title=उच्च-प्रदर्शन ब्राउज़र नेटवर्किंग|date=2013|publisher=O'Reilly|location=Beijing|isbn=978-1449344764|edition=1.}}</ref>


=== बहिष्कृत प्रस्ताव ===
[[टीसीपी कुकी लेनदेन]] (टीसीपीसीटी) दिसंबर 2009 में प्रस्तावित विस्तार है{{Ref RFC|6013}} सर्वरों को डिनायल-ऑफ़-सर्विस हमलों से सुरक्षित करने के लिए। एसवाईएन कुकीज़ के विपरीत, TCPCT [[विंडो स्केलिंग]] जैसे अन्य TCP एक्सटेंशन के साथ विरोध नहीं करता है। TCPCT को [[DNSSEC]] की आवश्यकताओं के कारण डिज़ाइन किया गया था, जहाँ सर्वरों को बड़ी संख्या में अल्पकालिक TCP कनेक्शनों को संभालना पड़ता है। 2016 में, टीसीपीसीटी को टीसीपी फास्ट ओपन के पक्ष में हटा दिया गया था। मूल RFC की स्थिति ऐतिहासिक में बदल दी गई थी।{{Ref RFC|7805}}

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

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

टीसीपी की [[ तार छवि (नेटवर्किंग) |तार छवि (नेटवर्किंग)]] ऑन-पाथ पर्यवेक्षकों को महत्वपूर्ण सूचना-एकत्रीकरण और संशोधन के अवसर प्रदान करती है, क्योंकि प्रोटोकॉल मेटाडेटा [[स्पष्ट पाठ]] में प्रसारित होता है।{{sfn|Trammell|Kuehlewind|2019|p=6}}{{sfn|Hardie|2019|p=3}} जबकि यह पारदर्शिता नेटवर्क ऑपरेटरों के लिए उपयोगी है{{sfn|Fairhurst|Perkins|2021|loc=2. Current Uses of Transport Headers within the Network}} और शोधकर्ता,{{sfn|Fairhurst|Perkins|2021|loc=3. Research, Development, and Deployment}} प्रोटोकॉल मेटाडेटा से एकत्रित की गई जानकारी अंतिम-उपयोगकर्ता की गोपनीयता को कम कर सकती है।{{sfn|Hardie|2019|p=8}} मेटाडेटा की इस दृश्यता और आघातवर्धनीयता के कारण टीसीपी का विस्तार करना मुश्किल हो गया है - [[प्रोटोकॉल ओसिफिकेशन]] का मामला - क्योंकि कोई भी मध्यवर्ती नोड ( '[[ मिडिलबॉक्स ]]') उस मेटाडेटा के आधार पर निर्णय ले सकता है या इसे संशोधित भी कर सकता है,{{sfn|Thomson|Pauly|2021|loc=2.3. Multi-party Interactions and Middleboxes}}{{sfn|Thomson|Pauly|2021|loc=A.5. TCP}} [[एंड-टू-एंड सिद्धांत]] को तोड़ना।{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}} माप में पाया गया कि इंटरनेट पर तिहाई पथ कम से कम मध्यस्थ का सामना करते हैं जो टीसीपी मेटाडेटा को संशोधित करता है, और 6.5% पथ मध्यस्थों से हानिकारक ossifying प्रभाव का सामना करते हैं।{{sfn|Edeline|Donnet|2019|p=175-176}} बिचौलियों से एक्स्टेंसिबिलिटी खतरों से बचने के लिए [[एमपीटीसीपी]] के डिजाइन पर महत्वपूर्ण बाधाओं को रखा गया है,{{sfn|Raiciu|Paasch|Barre|Ford|2012|p=1}}{{sfn|Hesmans|Duchene|Paasch|Detal|2013|p=1}} और बिचौलियों के कारण होने वाली कठिनाइयों ने [[वेब ब्राउज़र्स]] में टीसीपी फास्ट ओपन की तैनाती में बाधा उत्पन्न की है।{{sfn|Rybczyńska|2020}} ossification का अन्य स्रोत एंडपॉइंट्स पर टीसीपी कार्यों के संशोधन की कठिनाई है, सामान्यतः [[ऑपरेटिंग सिस्टम कर्नेल]] में{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=621}} या टीसीपी ऑफलोड इंजन के साथ हार्डवेयर में।{{sfn|Corbet|2015}}

== प्रदर्शन ==

जैसा कि टीसीपी विश्वसनीय बाइट स्ट्रीम के अमूर्त के साथ अनुप्रयोग प्रदान करता है, यह हेड-ऑफ़-लाइन ब्लॉकिंग से पीड़ित हो सकता है: यदि [[पैकेट पुनर्क्रमित करना]] या पैकेट हानि होती है और इसे फिर से भेजने की आवश्यकता होती है (और इस प्रकार आउट-ऑफ-ऑर्डर), क्रमिक रूप से बाद में डेटा धारा के भाग क्रमिक रूप से धारा के पूर्व भागों से पहले प्राप्त हो सकते हैं; चूँकि, बाद के डेटा का उपयोग सामान्यतः तब तक नहीं किया जा सकता जब तक कि पहले का डेटा प्राप्त नहीं हो जाता, जिससे नेटवर्क विलंबता हो जाती है। यदि कई स्वतंत्र उच्च-स्तरीय संदेश ही टीसीपी कनेक्शन पर एनकैप्सुलेशन (नेटवर्किंग) और [[ समय विभाजन बहुसंकेतन |समय विभाजन बहुसंकेतन]] हैं, तो [[हेड-ऑफ-लाइन ब्लॉकिंग]] पूर्ण-प्राप्त संदेश के प्रसंस्करण का कारण बन सकता है जिसे बाद में संदेश की डिलीवरी के लिए प्रतीक्षा करने के लिए भेजा गया था। जो पहले भेजा गया था।{{sfn|Briscoe|Brunstrom|Petlund|Hayes|2006|p=29-30}} वेब ब्राउजर कई समानांतर कनेक्शन खोलकर हेड-ऑफ-लाइन ब्लॉकिंग को कम करने का प्रयास करते हैं। यह कनेक्शन स्थापित करने की लागत को बार-बार बढ़ाता है, साथ ही उन कनेक्शनों को समापन बिंदुओं पर ट्रैक करने के लिए आवश्यक संसाधनों को गुणा करता है।{{sfn|Marx|2020|loc=HOL blocking in HTTP/1.1}} समानांतर कनेक्शन में साथ जानकारी एकत्र करने में सक्षम होने और देखी गई नेटवर्क स्थितियों के लिए अधिक तुरंत प्रतिक्रिया करने के अतिरिक्त दूसरे से स्वतंत्र रूप से काम करने वाले कंजेशन नियंत्रण भी होते हैं;{{sfn|Marx|2020|loc=Bonus: Transport Congestion Control}} यदि एकाधिक समांतर कनेक्शन खोले जाते हैं तो टीसीपी के आक्रामक प्रारंभिक प्रेषण पैटर्न भीड़ का कारण बन सकते हैं; और प्रति-कनेक्शन निष्पक्षता मॉडल इस दृष्टिकोण को अपनाने वाले अनुप्रयोगों द्वारा संसाधनों के एकाधिकार की ओर ले जाता है।{{sfn|IETF HTTP Working Group|loc=Why just one TCP connection?}}

वेब उपयोगकर्ताओं द्वारा अनुभव किए गए विलंबता के लिए कनेक्शन स्थापना प्रमुख योगदानकर्ता है।{{sfn|Corbet|2018}}{{sfn|Cheng|Chu|Radhakrishnan|Jain|2014|p=3}} डेटा भेजे जाने से पहले कनेक्शन स्थापना के दौरान टीसीपी का तीन-तरफा हैंडशेक आरटीटी विलंबता का परिचय देता है।{{sfn|Cheng|Chu|Radhakrishnan|Jain|2014|p=3}} लघु प्रवाहों के लिए, ये विलंब बहुत महत्वपूर्ण हैं।{{sfn|Sy|Mueller|Burkert|Federrath|2020|p=271}} ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) को कनेक्शन स्थापना पर [[कुंजी विनिमय]] के लिए स्वयं के हैंडशेक की आवश्यकता होती है। स्तरित डिज़ाइन के कारण, टीसीपी हैंडशेक और टीएलएस हैंडशेक क्रमिक रूप से आगे बढ़ते हैं: टीसीपी हैंडशेक समाप्त होने तक टीएलएस हैंडशेक प्रारंभिक नहीं हो सकता है।{{sfn|Chen|Jero|Jagielski|Boldyreva|2021|p=8-9}} टीसीपी पर टीएलएस 1.3 के साथ कनेक्शन स्थापित करने के लिए दो आरटीटी आवश्यक हैं।{{sfn|Ghedini|2018}} टीएलएस 1.3 कुछ परिस्थितियों में शून्य आरटीटी कनेक्शन की बहाली की अनुमति देता है, किन्तु, टीसीपी पर स्तरित होने पर, टीसीपी हैंडशेक के लिए अभी भी आरटीटी की आवश्यकता होती है, और यह प्रारंभिक कनेक्शन में सहायता नहीं कर सकता है; शून्य आरटीटी हैंडशेक क्रिप्टोग्राफ़िक चुनौतियां भी प्रस्तुत करते हैं, क्योंकि कुशल, रीप्ले-सुरक्षित और [[आगे सुरक्षित]] [[गैर-संवादात्मक कुंजी विनिमय]] खुला शोध विषय है।{{sfn|Chen|Jero|Jagielski|Boldyreva|2021|p=3-4}} टीसीपी फास्ट ओपन कनेक्शन स्थापना के दौरान विलंबता के आरटीटी को हटाते हुए प्रारंभिक (अर्थात , एसवाईएन और एसवाईएन -ACK) पैकेट में डेटा के प्रसारण की अनुमति देता है।{{sfn|Cheng|Chu|Radhakrishnan|Jain|2014|p=1}} चूंकि, प्रोटोकॉल ऑसिफिकेशन के कारण टीसीपी फास्ट ओपन को तैनात करना मुश्किल हो गया है; 2020 में, किसी भी [[वेब ब्राउज़र]] ने डिफ़ॉल्ट रूप से इसका उपयोग नहीं किया।{{sfn|Rybczyńska|2020}}

टीसीपी थ्रूपुट पैकेट रीऑर्डरिंग से प्रभावित होता है। पुनर्क्रमित पैकेट डुप्लिकेट पावती भेजने का कारण बन सकते हैं, जो, यदि वे सीमा पार करते हैं, तो नकली पुन: प्रसारण और भीड़ नियंत्रण को ट्रिगर करेगा। ट्रांसमिशन व्यवहार भी कम सहज और अधिक बर्स्टी हो सकता है, क्योंकि रेंज की शुरुआत में पुनर्क्रमित पैकेट प्राप्त होने पर बड़ी रेंज को ही बार में स्वीकार किया जाता है (इसी प्रकार से हेड-ऑफ-लाइन ब्लॉकिंग अनुप्रयोगों को कैसे प्रभावित करता है)।{{sfn|Blanton|Allman|2002|p=1-2}} {{harvtxt|Blanton|Allman|2002}} ने पाया कि थ्रूपुट रीऑर्डरिंग की मात्रा से विपरीत रूप से संबंधित था, सीमा तक जहां सभी रीऑर्डरिंग नकली रीट्रांसमिशन को ट्रिगर करता है।{{sfn|Blanton|Allman|2002|p=4-5}} रीऑर्डरिंग को कम करना प्रेषक की यह निर्धारित करने की क्षमता पर निर्भर करता है कि इसने नकली रीट्रांसमिशन भेजा है, और इसलिए रीट्रांसमिशन अस्पष्टता को हल करने पर।{{sfn|Blanton|Allman|2002|p=3-4}} वास्तविक नुकसान से तेजी से रिकवरी के खिलाफ रीऑर्डरिंग-प्रेरित नकली रेट्रांस्मिशन ट्रेड ऑफ को कम करना।{{sfn|Blanton|Allman|2002|p=6-8}}

चयनात्मक स्वीकृति थ्रूपुट को महत्वपूर्ण लाभ प्रदान कर सकती है; {{harvtxt|ब्रुएर्न, हेमन और झांग 1998 | | | }} 45% तक का लाभ मापा गया।{{sfn|Bruyeron|Hemon|Zhang|1998|p=67}} सुधार में महत्वपूर्ण कारक यह है कि चयनात्मक अभिस्वीकृति अधिकांशतः नुकसान के बाद धीमी शुरुआत में जाने से बच सकती है और इसलिए उपलब्ध बैंडविड्थ का बेहतर उपयोग कर सकती है।{{sfn|Bruyeron|Hemon|Zhang|1998|p=72}} चूंकि, टीसीपी केवल अनुक्रम संख्या के अधिकतम तीन ब्लॉकों को चुनिंदा रूप से स्वीकार कर सकता है। यह पुनर्संचरण दर को सीमित कर सकता है और इसलिए नुकसान की वसूली या अनावश्यक पुन: प्रसारण का कारण बन सकता है, विशेष रूप से उच्च-नुकसान वाले वातावरण में।{{sfn|Bhat|Rizk|Zink|2017|p=14}}{{sfn|Iyengar|Swett|2021|loc=4.5. More ACK Ranges}}

टीसीपी मूल रूप से वायर्ड नेटवर्क के लिए डिजाइन किया गया था। पैकेट हानि को नेटवर्क संकुलन का परिणाम माना जाता है और संकुलन खिड़की का आकार एहतियात के तौर पर नाटकीय रूप से कम हो जाता है। चूंकि, वायरलेस लिंक को लुप्त होने, छायांकन, हैंड ऑफ, [[हस्तक्षेप (संचार)]] और अन्य रेडियो प्रभावों के कारण छिटपुट और सामान्यतः अस्थायी नुकसान का अनुभव करने के लिए जाना जाता है, जो कि सख्ती से भीड़भाड़ नहीं है। कंजेशन विंडो साइज के (गलत) बैक-ऑफ के बाद, वायरलेस पैकेट लॉस के कारण, विंडो साइज में रूढ़िवादी कमी के साथ कंजेशन अवॉइडेंस फेज हो सकता है। इससे रेडियो लिंक का कम उपयोग होता है। इन हानिकारक प्रभावों का मुकाबला करने के लिए व्यापक शोध किया गया है। सुझाए गए समाधानों को एंड-टू-एंड समाधानों के रूप में वर्गीकृत किया जा सकता है, जिसके लिए क्लाइंट या सर्वर पर संशोधन की आवश्यकता होती है,<ref name="Microsoft Academic Research">{{cite web |title= TCP performance over CDMA2000 RLP |url= http://academic.research.microsoft.com/Paper/3352358.aspx |access-date= 2010-08-30 |url-status= dead |archive-url= https://web.archive.org/web/20110503193100/http://academic.research.microsoft.com/Paper/3352358.aspx |archive-date= 2011-05-03 }}</ref> लिंक परत समाधान, जैसे कि सेलुलर नेटवर्क में [[रेडियो लिंक प्रोटोकॉल]] (रेडियो लिंक प्रोटोकॉल), या प्रॉक्सी-आधारित समाधान जिन्हें अंत नोड्स को संशोधित किए बिना नेटवर्क में कुछ बदलावों की आवश्यकता होती है।<ref name="Microsoft Academic Research"/><ref name="IEEE Computer Society">{{cite book |author1=Muhammad Adeel |author2=Ahmad Ali Iqbal |name-list-style=amp |year=2004 |title=TCP Congestion Window Optimization for CDMA2000 Packet Data Networks |journal=International Conference on Information Technology (ITNG'07) |pages=31–35 |doi=10.1109/ITNG.2007.190 |isbn=978-0-7695-2776-5|s2cid=8717768 }}</ref>
वायरलेस समस्या को हल करने में मदद करने के लिए टीसीपी वेगास, [[टीसीपी वेस्टवुड]], वेनो और सांता क्रूज़ जैसे कई वैकल्पिक भीड़ नियंत्रण एल्गोरिदम प्रस्तावित किए गए हैं।

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

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

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

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

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

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

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

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

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

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

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

[[यूडीपी आधारित डेटा ट्रांसफर प्रोटोकॉल]] (यूडीटी) में उच्च [[बैंडविड्थ-विलंब उत्पाद]] वाले नेटवर्क में टीसीपी की तुलना में बेहतर दक्षता और निष्पक्षता है।<ref>Yunhong Gu, Xinwei Hong, and Robert L. Grossman.
[http://udt.sourceforge.net/doc/gridnet-v8.pdf "An Analysis of AIMD Algorithm with Decreasing Increases"] {{Webarchive|url=https://web.archive.org/web/20160305003043/http://udt.sourceforge.net/doc/gridnet-v8.pdf |date=2016-03-05 }}.
2004.</ref>
बहुउद्देशीय लेन-देन प्रोटोकॉल (MTP/IP) पेटेंट स्वामित्व वाला सॉफ़्टवेयर है जिसे विभिन्न प्रकार की नेटवर्क स्थितियों में अनुकूली रूप से उच्च थ्रूपुट और लेनदेन प्रदर्शन प्राप्त करने के लिए डिज़ाइन किया गया है, विशेष रूप से जहां टीसीपी को अक्षम माना जाता है।

== चेकसम गणना ==

=== [[IPv4]] === के लिए टीसीपी चेकसम
जब टीसीपी IPv4 पर चलता है, तो चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि को निम्नानुसार परिभाषित किया गया है:{{Ref RFC|9293}}
<ब्लॉककोट>
चेकसम फ़ील्ड 16-बिट वाले का पूरक है, हेडर और टेक्स्ट में सभी 16-बिट शब्दों का पूरक योग है। चेकसम गणना को डेटा के 16-बिट संरेखण को सुनिश्चित करने की आवश्यकता है। यदि किसी सेगमेंट में विषम संख्या में हेडर और टेक्स्ट ऑक्टेट हैं, तो चेकसम उद्देश्यों के लिए 16-बिट शब्द बनाने के लिए अंतिम ऑक्टेट को शून्य के साथ पैडिंग करके संरेखण प्राप्त किया जा सकता है। पैड खंड के हिस्से के रूप में प्रसारित नहीं होता है। चेकसम की गणना करते समय, चेकसम फ़ील्ड को शून्य से बदल दिया जाता है।</blockquote>

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

{| class="wikitable" style="margin: 0 auto; text-align: center;"
|+सम चेक कंप्यूटेशन के लिए टीसीपी स्यूडो-हेडर (आईपीवी4)
|-
! बिट ऑफसेट
! colspan="4" style="width:11%;"| 0–3
! colspan="4" style="width:11%;"| 4–7
! colspan="8" style="width:22%;"| 8–15
! colspan="16" style="width:44%;"| 16–31
|-
! 0
| colspan="32" style="background:#fdd;"| स्रोत पता
|-
! 32
| colspan="32" style="background:#fdd;"| गंतव्य पता
|-
! 64
| colspan="8" style="background:#fdd;"| शून्य
| colspan="8" style="background:#fdd;"| प्रोटोकॉल
| colspan="16" style="background:#fdd;"| टीसीपी लंबाई
|-
! 96
| colspan="16"| स्रोत पोर्ट
| colspan="16"| गंतव्य पोर्ट
|-
! 128
| colspan="32"| अनुक्रम संख्या 
|-
! 160
| colspan="32"| पावती संख्या
|-
! 192
| colspan="4"| डेटा ऑफसेट 
| colspan="3" style="width:8.25%;| सुरक्षित
| colspan="9" style="width:13.75%;| फ्लैग
| colspan="16"| विंडो 
|-
! 224
| colspan="16" style="background:#fcd;"| योग जांच करना
| colspan="16"| तत्काल सूचक
|-
! 256
| colspan="32"| विकल्प (वैकल्पिक)
|-
! 256/288+
| colspan="32"| &nbsp;<br/>डेटा<br/>&nbsp;
|}
स्रोत और गंतव्य पते IPv4 हेडर के हैं। TCP के लिए प्रोटोकॉल मान 6 है (cf. IP प्रोटोकॉल नंबरों की सूची)। टीसीपी लंबाई क्षेत्र टीसीपी हेडर और डेटा (ओक्टेट में मापा गया) की लंबाई है।

<nowiki>===</nowiki> [[IPv6]] === के लिए टीसीपी चेकसम
जब TCP IPv6 पर चलता है, तो चेकसम की गणना करने के लिए उपयोग की जाने वाली विधि बदल जाती है:{{Ref RFC|8200}}
<ब्लॉककोट>
कोई भी परिवहन या अन्य ऊपरी-परत प्रोटोकॉल जिसमें IP शीर्षलेख से इसके चेकसम संगणना में पते सम्मलित हैं, को IPv6 पर उपयोग के लिए संशोधित किया जाना चाहिए, 32-बिट IPv4 पतों के अतिरिक्त 128-बिट IPv6 पतों को सम्मलित करने के लिए।
</ब्लॉककोट>
सूडो-हेडर जो चेकसम की गणना के लिए IPv6 हेडर की नकल करता है, नीचे दिखाया गया है।

{| class="wikitable" style="margin: 0 auto; text-align: center;"
|+सम चेक कंप्यूटेशन के लिए टीसीपी स्यूडो-हेडर (आईपीवी6)
|-
! बिट ऑफसेट
! colspan="8" style="width:22%;"| 0–7
! colspan="8" style="width:22%;"| 8–15
! colspan="8" style="width:22%;"| 16–23
! colspan="8" style="width:22%;"| 24–31
|-
! 0
| colspan="32" rowspan="4" style="background:#fdd;"| स्रोत पता
|-
! 32
|-
! 64
|-
! 96
|-
! 128
| colspan="32" rowspan="4" style="background:#fdd;"| गंतव्य पता
|-
! 160
|-
! 192
|-
! 224
|-
! 256
| colspan="32" style="background:#fdd;"| टीसीपी लंबाई
|-
! 288
| colspan="24" style="background:#fdd;"| शून्य
| colspan="8" style="background:#fdd;"| अगला हेडर
= प्रोटोकॉल
|-
! 320
| colspan="16"| स्रोत पोर्ट
| colspan="16"| गंतव्य पोर्ट
|-
! 352
| colspan="32"| अनुक्रम संख्या 
|-
! 384
| colspan="32"| पावती संख्या
|-
! 416
| colspan="4"| डेटा ऑफसेट 
| colspan="4"| सुरक्षित
| colspan="8"| फ्लैग
| colspan="16"| विंडो 
|-
! 448
| colspan="16" style="background:#fcd;"| योग जांच करना
| colspan="16"| तत्काल सूचक
|-
! 480
| colspan="32"| विकल्प (वैकल्पिक)
|-
! 480/512+
| colspan="32"| &nbsp;<br/>डेटा<br/>&nbsp;
|}
*स्रोत का पता: IPv6 हेडर में एक
*गंतव्य पता: अंतिम गंतव्य; यदि IPv6 पैकेट में रूटिंग हेडर नहीं है, तो TCP IPv6 हेडर में गंतव्य पते का उपयोग करता है, अन्यथा, मूल नोड पर, यह रूटिंग हेडर के अंतिम तत्व में पते का उपयोग करता है, और, प्राप्त नोड पर, यह IPv6 हेडर में डेस्टिनेशन एड्रेस का उपयोग करता है।
* टीसीपी लंबाई: टीसीपी हेडर और डेटा की लंबाई
*अगला शीर्षक: टीसीपी के लिए प्रोटोकॉल मान

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

यह सुविधा [[ पैकेट विश्लेषक |पैकेट विश्लेषक]] का कारण बन सकती है जो आउटबाउंड पैकेट में अमान्य चेकसम की रिपोर्ट करने के लिए चेकसम ऑफलोड के उपयोग के बारे में अनजान या अनिश्चित हैं जो अभी तक नेटवर्क एडेप्टर तक नहीं पहुंचे हैं।<ref>{{cite web|url=https://wiki.wireshark.org/CaptureSetup/Offloading|title=Wireshark: Offloading|quote=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.|access-date=2017-02-24|archive-date=2017-01-31|archive-url=https://web.archive.org/web/20170131220028/https://wiki.wireshark.org/CaptureSetup/Offloading/|url-status=live}}</ref> यह केवल उन पैकेटों के लिए होगा जो नेटवर्क एडॉप्टर द्वारा प्रसारित किए जाने से पहले इंटरसेप्ट किए गए हैं; तार पर नेटवर्क एडेप्टर द्वारा प्रेषित सभी पैकेटों में वैध चेकसम होंगे।<ref>{{cite web|url=https://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html|title=Wireshark: Checksums|quote=चेकसम ऑफलोडिंग अक्सर भ्रम पैदा करती है क्योंकि प्रसारित किए जाने वाले नेटवर्क पैकेट को वास्तव में चेकसम की गणना करने से पहले Wireshark को सौंप दिया जाता है। Wireshark इन "खाली" चेकसम को प्राप्त करता है और उन्हें अमान्य के रूप में प्रदर्शित करता है, भले ही पैकेट में बाद में नेटवर्क हार्डवेयर छोड़ने पर वैध चेकसम होंगे।|access-date=2017-02-24|archive-date=2016-10-22|archive-url=https://web.archive.org/web/20161022133751/https://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html|url-status=live}}</ref> यह समस्या तब भी हो सकती है जब मॉनिटरिंग पैकेट ही होस्ट पर वर्चुअल मशीनों के बीच प्रेषित किए जा रहे हों, जहां वर्चुअल डिवाइस ड्राइवर चेकसम गणना ( अनुकूलन के रूप में) को छोड़ सकता है, यह जानते हुए कि चेकसम की गणना बाद में VM होस्ट कर्नेल या उसके भौतिक द्वारा की जाएगी हार्डवेयर।

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

== यह भी देखें ==

{{div col|colwidth=30em}}
* कनेक्शन उन्मुख संचार
* [[टीसीपी और यूडीपी पोर्ट नंबरों की सूची]] (बंदरगाहों और सेवाओं की एक लंबी सूची)
* [[माइक्रो-फटना (नेटवर्किंग)]]
* टीसीपी का टी/टीसीपी संस्करण
* [[टीसीपी वैश्विक तुल्यकालन]]
* [[टीसीपी पेसिंग]]
* {{section link|ट्रांसपोर्ट लेयर |ट्रांसपोर्ट लेयर  प्रोटोकॉल की तुलना}}
* [[डब्ल्यूटीसीपी]] वायरलेस नेटवर्क के लिए टीसीपी का एक प्रॉक्सी-आधारित संशोधन है
{{div col end}}

==टिप्पणियाँ==
{{Notelist}}


==संदर्भ==
{{Reflist}}


== ग्रन्थसूची ==

* {{ cite journal | doi = 10.1145/316194.316230 | doi-access = free | title = On estimating end-to-end network path properties | date = October 1999 | last1 = Allman | first1 = Mark | last2 = Paxson | first2 = Vern | author2link = Vern Paxson | journal = ACM SIGCOMM Computer Communication Review }}
* {{ cite book | doi = 10.1145/3083165.3083175 | chapter = Not so QUIC: A Performance Study of DASH over QUIC | date = June 2017 | title = NOSSDAV'17: Proceedings of the 27th Workshop on Network and Operating Systems Support for Digital Audio and Video | pages = 13-18 | last1 = Bhat | first1 = Divyashri | last2 = Rizk | first2 = Amr | last3 = Zink | first3 = Michael }}
* {{ cite journal | doi = 10.1145/510726.510728 | url = https://www.icir.org/mallman/pubs/BA02/BA02.pdf | title = On making TCP more robust to packet reordering | date = January 2002 | journal = ACM SIGCOMM Computer Communication Review | last1 = Blanton | first1 = Ethan | last2 = Allman | first2 = Mark }}
* {{ cite ietf | rfc = 7323 | title = TCP Extensions for High Performance | date = September 2014 | last1 = Borman | first1 = David | last2 = Braden | first2 = Bob | author2link = Bob Braden | last3 = Jacobson | first3 = Van | author3link = Van Jacobson | editor1-last = Scheffenegger | editor1-first = Richard }}
* {{ cite journal | doi = 10.1109/COMST.2014.2375213 | title = Reducing Internet Latency: A Survey of Techniques and Their Merits | year = 2016 | last1 = Briscoe | first1 = Bob | last2 = Brunstrom | first2 = Anna | last3 = Petlund | first3 = Andreas | last4 = Hayes | first4 = David | last5 = Ros | first5 = David | last6 = Tsang | first6 = Ing-Jyh | last7 = Gjessing | first7 = Stein | last8 = Fairhurst | first8 = Gorry | last9 = Griwodz | first9 = Carsten | last10 = Welzl | first10 = Michael | journal = [[IEEE Communications Surveys & Tutorials]] | volume = 18 | issue = 3 | pages = 2149–2196 | hdl = 2164/8018 | hdl-access = free | s2cid = 206576469 }}
* {{ cite journal | doi = 10.1145/279345.279350 | doi-access = free | journal = ACM SIGCOMM Computer Communication Review | title = Experimentations with TCP selective acknowledgment | date = April 1998 | last1 = Bruyeron | first1 = Renaud | last2 = Hemon | first2 = Bruno | last3 = Zhang | first3 = Lixa }}
* {{ cite journal | doi = 10.1007/s00145-021-09389-w | doi-access = free | title = Secure Communication Channel Establishment: TLS 1.3 (Over TCP Fast Open) versus QUIC | year = 2021 | last1 = Chen | first1 = Shan | last2 = Jero | first2 = Samuel | last3 = Jagielski | first3 = Matthew | last4 = Boldyreva | first4 = Alexandra | last5 = Nita-Rotaru | first5 = Cristina | journal = [[Journal of Cryptology]] | volume = 34 | issue = 3 | s2cid = 235174220 }}
* {{ cite ietf | rfc = 7413 | title = TCP Fast Open | date = December 2014 | last1 = Cheng | first1 = Yuchung | last2 = Chu | first2 = Jerry | last3 = Radhakrishnan | first3 = Sivasankar | last4 = Jain | first4 = Arvind }}
* {{ cite web | url = https://lwn.net/Articles/667059/ | title = Checksum offloads and protocol ossification | date = 8 December 2015 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}
* {{ cite web | url = https://lwn.net/Articles/745590/ | title = QUIC as a solution to protocol ossification | work = [[LWN.net]] | date = 29 January 2018 | last = Corbet | first = Jonathan }}
* {{ cite ietf | rfc = 9293 | date = August 2022 | title = Transmission Control Protocol (TCP) | editor1-last = Eddy | editor1-first = Wesley M. }}
* {{ cite conference | doi = 10.23919/TMA.2019.8784690 | title = A Bottom-Up Investigation of the Transport-Layer Ossification | date = 2019 | conference = 2019 Network Traffic Measurement and Analysis Conference (TMA) | last1 = Edeline | first1 = Korian | last2 = Donnet | first2 = Benoit }}
* {{ cite ietf | rfc = 8095 | title = Services Provided by IETF Transport Protocols and Congestion Control Mechanisms | date = March 2017 | editor1-last = Fairhurst | editor1-first = Gorry | editor2-last = Trammell | editor2-first = Brian | editor3-last = Kuehlewind | editor3-first = Mirja }}
* {{ cite ietf | rfc = 9065 | title = Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols | date = July 2021 | last1 = Fairhurst | first1 = Gorry | last2 = Perkins | first2 = Colin }}
* {{ cite web | url = https://blog.cloudflare.com/the-road-to-quic/ | title = The Road to QUIC | date = 26 July 2018 | publisher = [[Cloudflare]] | last = Ghedini | first = Alessandro }}
* {{ cite conference | url = https://www.cs.helsinki.fi/u/gurtov/papers/heuristics.pdf | title = Resolving Acknowledgment Ambiguity in non-SACK TCP | last1 = Gurtov | first1 = Andrei | last2 = Floyd | first2 = Sally | author2link = Sally Floyd | date = February 2004 | conference = Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN'04) }}
* {{ cite conference | url = https://www.cs.helsinki.fi/u/gurtov/papers/infocom03.pdf | title = Responding to Spurious Timeouts in TCP | last1 = Gurtov | first1 = Andrei | last2 = Ludwig | first2 = Reiner | doi = 10.1109/INFCOM.2003.1209251 | date = 2003 | conference = IEEE INFOCOM 2003. Twenty-second Annual Joint Conference of the IEEE Computer and Communications Societies }}
* {{ cite ietf | rfc = 8558 | title = Transport Protocol Path Signals | date = April 2019 | editor-last = Hardie | editor-first = Ted }}
* {{ cite conference | doi = 10.1145/2535828.2535830 | title = Are TCP extensions middlebox-proof? | date = 2013 | conference = HotMiddlebox '13 | last1 = Hesmans | first1 = Benjamin | last2 = Duchene | first2 = Fabien | last3 = Paasch | first3 = Christoph | last4 = Detal | first4 = Gregory | last5 = Bonaventure | first5 = Olivier }}
* {{ cite ietf | rfc = 9002 | title = QUIC Loss Detection and Congestion Control | date = May 2021 | editor1-last = Iyengar | editor1-first = Jana | editor2-first = Ian | editor2-last = Swett }}
* {{ cite web | url = https://http2.github.io/faq/ | title = HTTP/2 Frequently Asked Questions |author = IETF HTTP Working Group }}
* {{ cite journal | doi = 10.1145/118544.118549 | doi-access = free | title = Improving round-trip time estimates in reliable transport protocols | last1 = Karn | first1 = Phil | author1link = Phil Karn | last2 = Partridge | first2 = Craig | author2link = Craig Partridge | date = November 1991 | journal = ACM Transactions on Computer Systems }}
* {{ cite journal | doi = 10.1145/505688.505692 | doi-access = free | title = The Eifel algorithm: making TCP robust against spurious retransmissions | date = January 2000 | last1 = Ludwig | first1 = Reiner | last2 = Katz | first2 = Randy Howard | author2link = Randy Katz | journal = ACM SIGCOMM Computer Communication Review }}
* {{ cite ietf | rfc = 3522 | title = The Eifel Detection Algorithm for TCP | date = April 2003 | last1 = Ludwig | first1 = Reiner | last2 = Meyer | first2 = Michael }}
* {{ cite web | url = https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/ | title = Head-of-Line Blocking in QUIC and HTTP/3: The Details | last = Marx | first = Robin | date = 3 December 2020 }}
* {{ cite ietf | rfc = 2018 | title = TCP Selective Acknowledgment Options | date = October 1996 | last1 = Mathis | first1 = Matt | last2 = Mahdavi | first2 = Jamshid | last3 = Floyd | first3 = Sally | last4 = Romanow | first4 = Allyn }}
* {{ cite journal | doi = 10.1145/2578901 | title = Multipath TCP | last1 = Paasch | first1 = Christoph | last2 = Bonaventure | first2 = Olivier | date = 1 April 2014 | journal = [[Communications of the ACM]] }}
* {{ cite journal | doi = 10.1109/COMST.2016.2626780 | title = De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives | date = 2017 | journal = [[IEEE Communications Surveys & Tutorials]] | last1 = Papastergiou | first1 = Giorgos | last2 = Fairhurst | first2 = Gorry | last3 = Ros | first3 = David | last4 = Brunstrom | first4 = Anna | last5 = Grinnemo | first5 = Karl-Johan | last6 = Hurtig | first6 = Per | last7 = Khademi | first7 = Naeem | last8 = Tüxen | first8 = Michael | last9 = Welzl | first9 = Michael | last10 = Damjanovic | first10 = Dragana | last11 = Mangiante | first11 = Simone | volume = 19 | pages = 619–639 | hdl = 2164/8317 | s2cid = 1846371 }}
* {{ cite ietf | rfc = 6298 | title = Computing TCP's Retransmission Timer | date = June 2011 | last1 = Paxson | first1 = Vern | author1link = Vern Paxson | last2 = Allman | first2 = Mark | last3 = Chu | first3 = H.K. Jerry | last4 = Sargent | first4 = Matt }}
* {{ cite web | url = https://lwn.net/Articles/814522/ | title = A QUIC look at HTTP/3 | date = 13 March 2020 | last = Rybczyńska | first = Marta | work = [[LWN.net]] }}
* {{ Cite journal | arxiv = 1905.03518 | last1 = Sy | first1 = Erik | last2 = Mueller | first2 = Tobias | last3 = Burkert | first3 = Christian | last4 = Federrath | first4 = Hannes | last5 = Fischer | first5 = Mathias | title = Enhanced Performance and Privacy for TLS over TCP Fast Open | journal = Proceedings on Privacy Enhancing Technologies | year = 2020 | volume = 2020 | issue = 2 | pages = 271–287 | doi = 10.2478/popets-2020-0027 | doi-access = free }}
* {{ cite ietf | rfc = 9170 | title = Long-Term Viability of Protocol Extension Mechanisms | date = December 2021 | last1 = Thomson | first1 = Martin | last2 = Pauly | first2 = Tommy }}
* {{ cite ietf | rfc = 8546 | title = The Wire Image of a Network Protocol | date = April 2019 | last1 = Trammell | first1 = Brian | last2 = Kuehlewind | first2 = Mirja }}
* {{ cite journal | doi = 10.1145/1013812.18216 | doi-access = free | title = Why TCP timers don't work well | last = Zhang | first = Lixia | authorlink = Lixia Zhang | date = 5 August 1986 | journal = ACM SIGCOMM Computer Communication Review }}


==अग्रिम पठन==
*{{Cite book |last=Stevens |first=W. Richard |author-link=W. Richard Stevens |title=TCP/IP Illustrated, Volume 1: The Protocols |isbn=978-0-201-63346-7 |date=1994-01-10 |url=https://archive.org/details/tcpipillustrated00stev |publisher=Addison-Wesley Pub. Co. }}
*{{Cite book |last1=Stevens |first1=W. Richard |last2=Wright |first2=Gary R |title=TCP/IP Illustrated, Volume 2: The Implementation |isbn=978-0-201-63354-2 |year=1994 |url=https://archive.org/details/tcpipillustrated00stev_1 }}
*{{Cite book |last=Stevens |first=W. Richard |title=TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols |isbn=978-0-201-63495-2|year=1996 }}**


==बाहरी संबंध==
{{Wikiversity | Transmission Control Protocol}}
{{Commons|TCP|Transmission Control Protocol}}
*[http://purl.umn.edu/107387 Oral history interview with Robert E. Kahn]
*[https://www.iana.org/assignments/port-numbers IANA पोर्ट Assignments]
*[https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml IANA TCP Parameters]
*[http://condor.depaul.edu/~jkristof/technotes/tcp.html John Kristoff's Overview of TCP (Fundamental concepts behind TCP और how it is used to transपोर्ट डेटा between two अंतिम बिंदु s)]
*[http://mathforum.org/library/drmath/view/54379.html योग जांच करना example]

[[Category:All articles containing potentially dated statements]]
[[Category:Articles containing potentially dated statements from 2010]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:CS1 English-language sources (en)]]
[[Category:CS1 errors]]
[[Category:CS1 maint]]
[[Category:Created On 11/05/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Webarchive template wayback links]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:ट्रांसमिशन कंट्रोल प्रोटोकॉल| ट्रांसमिशन कंट्रोल प्रोटोकॉल ]]
[[Category:परिवहन परत प्रोटोकॉल]]