بروتوكول التحكم في الإرسال

بروتوكول التحكم في الإرسال

مجموعة البروتوكولات
اختصار	بروتوكول التحكم في الإرسال
المطور(ون)	فينت سيرف وبوب كاهن
مقدمة	1974 ؛ منذ 50 عامًا ( 1974 )
مرتكز على	برنامج التحكم في ناقل الحركة
طبقة OSI	طبقة النقل (4)
طلبات التعليقات	9293

بروتوكول التحكم في الإرسال ( TCP ) هو أحد البروتوكولات الرئيسية لمجموعة بروتوكولات الإنترنت . نشأ في التنفيذ الأولي للشبكة حيث استكمل بروتوكول الإنترنت (IP). لذلك، يشار إلى المجموعة بأكملها عادةً باسم TCP/IP . يوفر TCP تسليمًا موثوقًا ومنظمًا وخالي من الأخطاء لتدفق من الثمانيات (البايتات) بين التطبيقات التي تعمل على مضيفين يتواصلون عبر شبكة IP. تعتمد تطبيقات الإنترنت الرئيسية مثل شبكة الويب العالمية والبريد الإلكتروني والإدارة عن بُعد ونقل الملفات على TCP، وهو جزء من طبقة النقل في مجموعة TCP/IP. غالبًا ما يعمل SSL/TLS أعلى TCP.

يعتمد بروتوكول التحكم في الإرسال على الاتصال ، مما يعني أن المرسل والمستقبل يحتاجان أولاً إلى إنشاء اتصال بناءً على المعلمات المتفق عليها؛ ويفعلان ذلك من خلال إجراء المصافحة ثلاثية الاتجاهات. ^[1] يجب أن يستمع الخادم (الفتح السلبي) لطلبات الاتصال من العملاء قبل إنشاء الاتصال. تضيف المصافحة ثلاثية الاتجاهات (الفتح النشط)، وإعادة الإرسال ، واكتشاف الأخطاء إلى الموثوقية ولكنها تطيل زمن الوصول . قد تستخدم التطبيقات التي لا تتطلب خدمة دفق بيانات موثوقة بروتوكول بيانات المستخدم (UDP) بدلاً من ذلك، والذي يوفر خدمة بيانات بدون اتصال تعطي الأولوية للوقت على الموثوقية. يستخدم بروتوكول التحكم في الإرسال تجنب ازدحام الشبكة . ومع ذلك، هناك نقاط ضعف في بروتوكول التحكم في الإرسال، بما في ذلك رفض الخدمة ، واختطاف الاتصال ، ونقض بروتوكول التحكم في الإرسال، وهجوم إعادة الضبط .

مجموعة بروتوكولات الإنترنت
طبقة التطبيق
بروتوكول بوابة الحدود DHCP ( الإصدار 6 ) نظام اسم النطاق بروتوكول نقل الملفات HTTP  ( HTTP/3 ) HTTPS بروتوكول IMAP اي ار سي بروتوكول LDAP إم جي سي بي ام كيو تي تي إن إن تي بي برنامج إن تي بي بروتوكول OSPF بوب بروتوكول نقل الملفات أو إن سي/آر بي سي نسبة العائد إلى اللاعب خطة الاسترداد النقدي قطع رشفة بروتوكول نقل البريد البسيط بروتوكول إدارة الشبكة البسيطة (SNMP) SSH تلنت TLS/SSL إكس إم بي بي أكثر...
طبقة النقل
بروتوكول التحكم في الإرسال بروتوكول بيانات المستخدم دي سي بي مركز مراقبة الجودة من فضلك، أرسل رد كويك أكثر...
طبقة الانترنت
الملكية الفكرية الإصدار الرابع الإصدار 6 بروتوكول ICMP ( الإصدار 6 ) الحزب الديمقراطي الجديد شبكة الاتصالات الإلكترونية بروتوكول الإنترنت العالمي للشبكات بروتوكول الإنترنت الآمن أكثر...
طبقة الارتباط
بروتوكول ARP الأنفاق حزب الشعب الباكستاني ماك أكثر...
ف ت هـ

في مايو 1974، وصف فينت سيرف وبوب كاهن بروتوكول شبكات الإنترنت لمشاركة الموارد باستخدام تبديل الحزم بين عقد الشبكة. ^[2] كان المؤلفان يعملان مع جيرارد لو لان لدمج المفاهيم من مشروع سيكلاد الفرنسي في الشبكة الجديدة. ^[3] تمت كتابة مواصفات البروتوكول الناتج، RFC 675 ( مواصفات برنامج التحكم في نقل الإنترنت )، بواسطة فينت سيرف ويوجين دلال وكارل صن شاين، ونشرت في ديسمبر 1974. ^[4] تحتوي على أول استخدام موثق لمصطلح الإنترنت ، كاختصار لشبكة الإنترنت . ^{[ بحاجة لمصدر ]}

دمج برنامج التحكم في الإرسال كلًا من الروابط الموجهة للاتصال وخدمات البيانات بين المضيفين. في الإصدار 4، تم تقسيم برنامج التحكم في الإرسال المتجانس إلى بنية معيارية تتكون من بروتوكول التحكم في الإرسال وبروتوكول الإنترنت . ^{[5] [6]} أدى هذا إلى نموذج شبكات أصبح معروفًا بشكل غير رسمي باسم TCP / IP ، على الرغم من أنه تمت الإشارة إليه رسميًا بشكل مختلف باسم نموذج بنية الإنترنت لوزارة الدفاع ( نموذج وزارة الدفاع باختصار) أو نموذج وكالة مشاريع الأبحاث الدفاعية المتقدمة . ^{[7] [8] [9]} لاحقًا، أصبح جزءًا من مجموعة بروتوكولات الإنترنت ومرادفًا لها .

تصف مستندات تجربة الإنترنت (IEN) التالية تطور TCP إلى الإصدار الحديث: ^[10]

• IEN 5 مواصفات برنامج التحكم في نقل الإنترنت TCP الإصدار 2 ( مارس 1977).
• IEN 21 مواصفات برنامج التحكم في نقل الشبكات الداخلية TCP الإصدار 3 ( يناير 1978).
• إيين 27
• إيين 40
• إيين 44
• إيين 55
• إيين 81
• إيين 112
• إيين 124

تم توحيد بروتوكول TCP في يناير 1980 تحت اسم RFC  761.

في عام 2004، حصل فينت سيرف وبوب كان على جائزة تورينج لعملهما التأسيسي في مجال بروتوكول TCP/IP. ^{[11] [12]}

يوفر بروتوكول التحكم في الإرسال خدمة اتصال على مستوى وسيط بين برنامج تطبيق وبروتوكول الإنترنت. فهو يوفر اتصالاً بين مضيف ومضيف عند طبقة النقل في نموذج الإنترنت . ولا يحتاج التطبيق إلى معرفة الآليات الخاصة لإرسال البيانات عبر رابط إلى مضيف آخر، مثل تجزئة IP المطلوبة لاستيعاب وحدة الإرسال القصوى لوسيط الإرسال. وعند طبقة النقل، يتعامل بروتوكول التحكم في الإرسال مع جميع تفاصيل المصافحة والإرسال ويقدم تجريدًا لاتصال الشبكة بالتطبيق عادةً من خلال واجهة مقبس الشبكة .

في المستويات الأدنى من مكدس البروتوكول، بسبب ازدحام الشبكة أو موازنة تحميل حركة المرور أو سلوك الشبكة غير المتوقع، قد تُفقد حزم IP أو تتكرر أو تُسلم خارج الترتيب . يكتشف بروتوكول التحكم في الإرسال هذه المشكلات ويطلب إعادة إرسال البيانات المفقودة وإعادة ترتيب البيانات غير المرتبة بل ويساعد حتى في تقليل ازدحام الشبكة لتقليل حدوث المشكلات الأخرى. إذا ظلت البيانات غير مُسلَّمة، يتم إخطار المصدر بهذا الفشل. بمجرد أن يعيد مستقبل بروتوكول التحكم في الإرسال تجميع تسلسل الثماني بتات المرسلة في الأصل، فإنه يمررها إلى التطبيق المستقبل. وبالتالي، يجرد بروتوكول التحكم في الإرسال اتصالات التطبيق من تفاصيل الشبكة الأساسية.

يتم استخدام TCP على نطاق واسع بواسطة العديد من تطبيقات الإنترنت، بما في ذلك شبكة الويب العالمية (WWW)، والبريد الإلكتروني، وبروتوكول نقل الملفات ، و Secure Shell ، ومشاركة الملفات من نظير إلى نظير ، وبث الوسائط .

تم تحسين بروتوكول TCP للتسليم الدقيق بدلاً من التسليم في الوقت المناسب ويمكن أن يتسبب في تأخيرات طويلة نسبيًا (بترتيب ثوانٍ) أثناء انتظار الرسائل غير المنظمة أو إعادة إرسال الرسائل المفقودة. لذلك، فهو غير مناسب بشكل خاص للتطبيقات في الوقت الفعلي مثل الصوت عبر IP . لمثل هذه التطبيقات، عادةً ما يتم التوصية ببروتوكولات مثل بروتوكول النقل في الوقت الفعلي (RTP) الذي يعمل عبر بروتوكول بيانات المستخدم (UDP) بدلاً من ذلك. ^[13]

TCP هي خدمة توصيل دفق بايتات موثوقة تضمن أن تكون جميع البايتات المستلمة متطابقة وبنفس ترتيب البايتات المرسلة. نظرًا لأن نقل الحزم بواسطة العديد من الشبكات ليس موثوقًا به، فإن TCP يحقق ذلك باستخدام تقنية تُعرف باسم الإقرار الإيجابي مع إعادة الإرسال . يتطلب هذا من المستقبل الرد برسالة إقرار أثناء استلامه للبيانات. يحتفظ المرسل بسجل لكل حزمة يرسلها ويحافظ على مؤقت من وقت إرسال الحزمة. يعيد المرسل إرسال الحزمة إذا انتهت صلاحية المؤقت قبل استلام الإقرار. يكون المؤقت ضروريًا في حالة فقد الحزمة أو تلفها. ^[13]

بينما يتولى بروتوكول IP عملية التسليم الفعلي للبيانات، يتتبع بروتوكول TCP المقاطع - الوحدات الفردية لنقل البيانات التي تنقسم إليها الرسالة من أجل التوجيه الفعال عبر الشبكة. على سبيل المثال، عندما يتم إرسال ملف HTML من خادم ويب، تقسم طبقة برنامج TCP لهذا الخادم الملف إلى مقاطع وترسلها بشكل فردي إلى طبقة الإنترنت في مكدس الشبكة . يغلف برنامج طبقة الإنترنت كل مقطع TCP في حزمة IP عن طريق إضافة رأس يتضمن (من بين بيانات أخرى) عنوان IP الوجهة . عندما يستقبلها برنامج العميل على الكمبيوتر الوجهة، يعيد برنامج TCP في طبقة النقل تجميع المقاطع ويضمن ترتيبها بشكل صحيح وخلوها من الأخطاء أثناء بث محتويات الملف إلى التطبيق المستقبل.

يتقبل بروتوكول التحكم في الإرسال البيانات من مجرى البيانات، ويقسمها إلى أجزاء، ويضيف رأس TCP لإنشاء جزء TCP. ثم يتم تغليف جزء TCP في مخطط بيانات بروتوكول الإنترنت (IP)، وتبادله مع الأقران. ^[14]

يظهر مصطلح حزمة TCP في الاستخدام الرسمي وغير الرسمي، بينما في المصطلحات الأكثر دقة يشير segment إلى وحدة بيانات بروتوكول TCP (PDU)، و datagram ^[15] إلى IP PDU، و frame إلى طبقة ارتباط البيانات PDU:

تنقل العمليات البيانات عن طريق استدعاء بروتوكول التحكم في الإرسال (TCP) وتمرير مخازن البيانات كحجج. يقوم بروتوكول التحكم في الإرسال (TCP) بتجميع البيانات من هذه المخازن في أجزاء ثم يستدعي وحدة الإنترنت [على سبيل المثال بروتوكول IP] لنقل كل جزء إلى بروتوكول التحكم في الإرسال (TCP) الوجهة. ^[16]

يتكون مقطع TCP من رأس مقطع وقسم بيانات . يحتوي رأس المقطع على 10 حقول إلزامية وحقل امتداد اختياري ( خيارات ، خلفية وردية في الجدول). يتبع قسم البيانات الرأس وهو بيانات الحمولة المحمولة للتطبيق. ^[17] لا يتم تحديد طول قسم البيانات في رأس المقطع؛ يمكن حسابه عن طريق طرح الطول المجمع لرأس المقطع ورأس IP من إجمالي طول مخطط بيانات IP المحدد في رأس IP. ^{[ بحاجة لمصدر ]}

تنسيق رأس TCP ^[17]

الإزاحة	ثماني بتات	0								1								2								3
ثماني بتات	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	منفذ المصدر																ميناء الوجهة
4	32	رقم التسلسل
8	64	رقم الإقرار (ذو معنى عند تعيين بت الإقرار)
12	96	إزاحة البيانات				محجوز				الأقارب البرية للماشية	التعليم في مرحلة الطفولة المبكرة	أورغ	إك	بي اس اتش	ر.س.ت	سين	الزعنفة	نافذة
16	128	المجموع الاختباري																مؤشر عاجل (ذو معنى عند تعيين بت URG) [18]
20	160	(الخيارات) إذا كانت موجودة، فسيكون إزاحة البيانات أكبر من 5. يتم تعبئتها بالأصفار إلى مضاعفات 32 بت، حيث تحسب إزاحة البيانات الكلمات المكونة من 4 ثماني بتات.
⋮	⋮
56	448
60	480	بيانات
64	512
⋮	⋮

منفذ المصدر: 16 بت

يحدد منفذ الإرسال.

منفذ الوجهة: 16 بت

يحدد منفذ الاستقبال.

رقم التسلسل: 32 بت

له دور مزدوج:

• إذا تم تعيين علامة SYN (1)، فهذا هو رقم التسلسل الأولي. ثم يصبح رقم التسلسل لأول بايت بيانات فعلي ورقم الإقرار في الإقرار المقابل هو رقم التسلسل هذا بالإضافة إلى 1.
• إذا تم إلغاء تعيين علم SYN (0)، فسيكون هذا هو رقم التسلسل التراكمي لأول بايت بيانات لهذا الجزء للجلسة الحالية.

رقم الإقرار: 32 بت

إذا تم تعيين علامة الإقرار، فإن قيمة هذا الحقل هي رقم التسلسل التالي الذي يتوقعه مرسل الإقرار. وهذا يؤكد استلام جميع البايتات السابقة (إن وجدت). ^[19] ويؤكد الإقرار الأول الذي يتم إرساله من كل طرف على رقم التسلسل الأولي للطرف الآخر نفسه، ولكن بدون بيانات. ^[20]

إزاحة البيانات  (DOffset): 4 بت

يحدد حجم رأس TCP بكلمات 32 بت . الحد الأدنى لحجم الرأس هو 5 كلمات والحد الأقصى هو 15 كلمة، مما يعطي الحد الأدنى لحجم 20 بايت والحد الأقصى 60 بايت، مما يسمح بما يصل إلى 40 بايت من الخيارات في الرأس. يحصل هذا الحقل على اسمه من حقيقة أنه يمثل أيضًا الإزاحة من بداية مقطع TCP إلى البيانات الفعلية. ^{[ بحاجة لمصدر ]}

محجوز  (Rsrvd): 4 بتات

للاستخدام المستقبلي ويجب ضبطها على الصفر؛ ولا ينبغي للمرسلين ضبط هذه الإعدادات ويجب على المستلمين تجاهلها إذا تم ضبطها، في حالة عدم وجود مزيد من المواصفات والتنفيذ.

من عام 2003 إلى عام 2017، تم تعريف البت الأخير (البت 103 من الرأس) باعتباره علم NS (مجموع Nonce) بواسطة RFC 3540 التجريبي، ECN-nonce. لم يتم استخدام ECN-nonce على نطاق واسع وتم نقل RFC إلى حالة تاريخية. ^[21]

الأعلام: 8 بت

تحتوي على 8 أعلام 1 بت (بتات التحكم) على النحو التالي:

CWR: 1 بت

يتم تعيين علم تقليل نافذة الازدحام (CWR) بواسطة المضيف المرسل للإشارة إلى أنه تلقى مقطع TCP مع تعيين علم ECE واستجاب في آلية التحكم في الازدحام. ^{[22] [أ]}

ECE: 1 بت

يتمتع ECN-Echo بدور مزدوج، اعتمادًا على قيمة علم SYN. ​​يشير إلى:

• إذا تم تعيين علم SYN (1)، فإن نظير TCP قادر على ECN . ^[23]
• إذا تم إلغاء تعيين علم SYN (0)، يتم استلام حزمة مع تعيين علم Congestion Experienced (ECN=11) في رأس IP الخاص بها أثناء الإرسال العادي. ^[أ] يعمل هذا كمؤشر على ازدحام الشبكة (أو الازدحام الوشيك) لمرسل TCP. ^[24]

URG: 1 بت

يشير إلى أن حقل المؤشر العاجل له أهمية.

ACK: 1 بت

يشير إلى أن حقل الإقرار مهم. يجب تعيين هذا العلم على جميع الحزم بعد حزمة SYN الأولية التي يرسلها العميل. ^[25]

PSH: 1 بت

وظيفة الدفع. تطلب دفع البيانات المخزنة مؤقتًا إلى التطبيق المستقبل.

RST: 1 بت

إعادة تعيين الاتصال

SYN: 1 بت

مزامنة أرقام التسلسل. يجب تعيين هذا العلم فقط على أول حزمة يتم إرسالها من كل طرف. تتغير بعض الأعلام والحقول الأخرى بناءً على هذا العلم، وبعضها صالح فقط عند تعيينه، وبعضها الآخر صالح عند مسحه.

الزعنفة: 1 بت

الحزمة الأخيرة من المرسل

النافذة: 16 بت

حجم نافذة الاستقبال ، والذي يحدد عدد وحدات حجم النافذة ^[ب] التي يرغب مرسل هذا الجزء في استلامها حاليًا. ^[ج] (انظر § التحكم في التدفق و§ قياس النافذة.)

المجموع الاختباري : 16 بت

يتم استخدام حقل المجموع الاختباري المكون من 16 بتًا للتحقق من أخطاء رأس TCP والحمولة ورأس IP الزائف. يتكون الرأس الزائف من عنوان IP المصدر وعنوان IP الوجهة ورقم البروتوكول لبروتوكول TCP (6) وطول رؤوس TCP والحمولة (بالبايت).

مؤشر عاجل: 16 بت

إذا تم تعيين علم URG، فسيكون هذا الحقل المكون من 16 بت بمثابة إزاحة من رقم التسلسل الذي يشير إلى آخر بايت بيانات عاجلة.

الخيارات  (خيار TCP): متغير 0–320 بت، بوحدات 32 بت؛ الحجم (الخيارات) == (DOffset - 5) * 32

يتم تحديد طول هذا الحقل بواسطة حقل إزاحة البيانات . يتم استخدام حشو رأس TCP لضمان انتهاء رأس TCP وبدء البيانات على حدود 32 بت. يتكون الحشو من أصفار. ^[16]

تحتوي الخيارات على ما يصل إلى ثلاثة حقول: نوع الخيار (1 بايت)، وطول الخيار (1 بايت)، وبيانات الخيار (متغير). يشير حقل نوع الخيار إلى نوع الخيار وهو الحقل الوحيد الذي ليس اختياريًا. اعتمادًا على قيمة نوع الخيار، يمكن تعيين الحقلين التاليين. يشير طول الخيار إلى الطول الإجمالي للخيار، ويحتوي بايت بيانات الخيار على البيانات المرتبطة بالخيار، إذا كان ذلك ممكنًا. على سبيل المثال، يشير بايت نوع الخيار 1 إلى أن هذا خيار بدون عملية يستخدم فقط للحشو، ولا يتبعه حقل طول الخيار أو بيانات الخيار. يشير بايت نوع الخيار 0 إلى نهاية الخيارات، وهو بايت واحد فقط أيضًا. يتم استخدام بايت نوع الخيار 2 للإشارة إلى خيار حجم القطعة الأقصى، وسيتبعه بايت طول الخيار الذي يحدد طول حقل MSS. طول الخيار هو الطول الإجمالي لحقل الخيارات المعطى، بما في ذلك حقلي نوع الخيار وطول الخيار. لذا، بينما يتم التعبير عن قيمة MSS عادةً في بايتين، فإن طول الخيار سيكون 4 بايتات. على سبيل المثال، يتم ترميز حقل خيار MSS بقيمة 0x05B4 على النحو التالي ( 0x02 0x04 0x05B4 ) في قسم خيارات TCP.

قد يتم إرسال بعض الخيارات فقط عند تعيين SYN؛ وهي موضحة أدناه على النحو التالي ^[SYN]. يتم إعطاء نوع الخيار والأطوال القياسية على النحو التالي (نوع الخيار، طول الخيار).

نوع الخيار	طول الخيار	خيار البيانات	غاية	ملحوظات
0	—	—	نهاية قائمة الخيارات
1	—	—	لا يوجد عملية	يمكن استخدام هذا لمحاذاة حقول الخيار على حدود 32 بت للحصول على أداء أفضل.
2	4	اس اس	الحد الأقصى لحجم القطعة	راجع § الحد الأقصى لحجم القطعة للحصول على التفاصيل.[SYN]
3	3	س	مقياس النافذة	انظر § قياس النافذة للحصول على التفاصيل. [26] [SYN]
4	2	—	مسموح بالإقرار الانتقائي	انظر § الإقرارات الانتقائية للمزيد من التفاصيل. [27] [SYN]
5	ن (10، 18، 26، أو 34)	BBBB، EEEE، ...	الإقرار الانتقائي (SACK) [28]	يتبع هذين البايتين الأولين قائمة مكونة من 1 إلى 4 كتل يتم التعرف عليها بشكل انتقائي، ويتم تحديدها كمؤشرات بداية/نهاية مكونة من 32 بت.
8	10	TTTT، EEEE	الطابع الزمني وصدى الطابع الزمني السابق	راجع § طوابع زمنية TCP للحصول على التفاصيل. [26]
28	4	—	خيار مهلة المستخدم	انظر RFC 5482.
29	ن	—	خيار مصادقة TCP (TCP-AO)	بالنسبة لمصادقة الرسائل، تم استبدال مصادقة MD5 (الخيار 19) المصممة في الأصل لحماية جلسات BGP . [29] راجع RFC 5925.
30	ن	—	بروتوكول TCP متعدد المسارات (MPTCP)	راجع TCP متعدد المسارات للحصول على التفاصيل.

القيم المتبقية لنوع الخيار هي قيم تاريخية أو قديمة أو تجريبية أو لم يتم توحيدها بعد أو لم يتم تخصيصها. تتم صيانة تعيينات أرقام الخيار بواسطة هيئة أرقام الإنترنت المخصصة (IANA). ^[30]

البيانات : متغير

حمولة حزمة TCP

يمكن تقسيم عمليات بروتوكول TCP إلى ثلاث مراحل. إنشاء الاتصال عبارة عن عملية مصافحة متعددة الخطوات يتم من خلالها إنشاء اتصال قبل الدخول في مرحلة نقل البيانات . بعد اكتمال نقل البيانات، يؤدي إنهاء الاتصال إلى إغلاق الاتصال وإطلاق جميع الموارد المخصصة.

يتم إدارة اتصال TCP بواسطة نظام تشغيل من خلال مورد يمثل نقطة النهاية المحلية للاتصالات، وهو مقبس الإنترنت . أثناء عمر اتصال TCP، تخضع نقطة النهاية المحلية لسلسلة من تغييرات الحالة : ^[31]

حالات مأخذ TCP

ولاية	نقطة النهاية	وصف
يستمع	الخادم	في انتظار طلب اتصال من أي نقطة نهاية TCP بعيدة.
متزامنة	عميل	في انتظار طلب اتصال مطابق بعد إرسال طلب اتصال.
تم استلام المزامنة	الخادم	في انتظار تأكيد طلب الاتصال بعد استلام وإرسال طلب الاتصال.
مقرر	الخادم والعميل	اتصال مفتوح، يمكن تسليم البيانات المستلمة للمستخدم. الحالة الطبيعية لمرحلة نقل البيانات في الاتصال.
فين-وايت-1	الخادم والعميل	في انتظار طلب إنهاء الاتصال من TCP البعيد، أو إقرار بطلب إنهاء الاتصال الذي تم إرساله مسبقًا.
فين-وايت-2	الخادم والعميل	في انتظار طلب إنهاء الاتصال من TCP البعيد.
إغلاق-انتظار	الخادم والعميل	في انتظار طلب إنهاء الاتصال من المستخدم المحلي.
إغلاق	الخادم والعميل	في انتظار تأكيد طلب إنهاء الاتصال من TCP البعيد.
آخر مرة	الخادم والعميل	انتظار تأكيد طلب إنهاء الاتصال الذي تم إرساله مسبقًا إلى TCP البعيد (الذي يتضمن تأكيدًا لطلب إنهاء الاتصال الخاص به).
الوقت-الانتظار	الخادم أو العميل	انتظار مرور وقت كافٍ للتأكد من انتهاء صلاحية جميع الحزم المتبقية على الاتصال.
مغلق	الخادم والعميل	لا يوجد حالة اتصال على الإطلاق.

قبل أن يحاول العميل الاتصال بخادم، يجب على الخادم أولاً الارتباط بمنفذ والاستماع إليه لفتحه للاتصالات: وهذا ما يسمى بالفتح السلبي. بمجرد إنشاء الفتح السلبي، يمكن للعميل إنشاء اتصال من خلال بدء فتح نشط باستخدام المصافحة ثلاثية الاتجاهات (أو ثلاثية الخطوات):

1. SYN : يتم تنفيذ الفتح النشط من خلال قيام العميل بإرسال SYN إلى الخادم. يقوم العميل بتعيين رقم تسلسل القطعة إلى قيمة عشوائية A.
2. SYN-ACK : في الاستجابة، يرد الخادم بـ SYN-ACK. يتم تعيين رقم التأكيد على رقم واحد أكثر من رقم التسلسل المستلم، أي A+1، ورقم التسلسل الذي يختاره الخادم للحزمة هو رقم عشوائي آخر، B.
3. ACK : أخيرًا، يرسل العميل ACK مرة أخرى إلى الخادم. يتم تعيين رقم التسلسل على قيمة الإقرار المستلمة أي A+1، ويتم تعيين رقم الإقرار على قيمة أكبر من رقم التسلسل المستلم أي B+1.

الخطوتان 1 و2 تحددان وتقرّان برقم التسلسل لاتجاه واحد (من العميل إلى الخادم). الخطوتان 2 و3 تحددان وتقرّان برقم التسلسل للاتجاه الآخر (من الخادم إلى العميل). بعد إكمال هذه الخطوات، يتلقى كل من العميل والخادم إقرارات ويتم إنشاء اتصال ثنائي الاتجاه.

تستخدم مرحلة إنهاء الاتصال مصافحة رباعية الاتجاهات، حيث ينتهي كل جانب من الاتصال بشكل مستقل. عندما ترغب نقطة نهاية في إيقاف نصف الاتصال الخاص بها، فإنها ترسل حزمة FIN، والتي يقرها الطرف الآخر بإقرار. لذلك، تتطلب عملية الإزالة النموذجية زوجًا من مقاطع FIN وACK من كل نقطة نهاية TCP. بعد أن يستجيب الجانب الذي أرسل FIN الأول بإقرار نهائي، فإنه ينتظر مهلة زمنية قبل إغلاق الاتصال أخيرًا، وخلال هذه الفترة يكون المنفذ المحلي غير متاح لاتصالات جديدة؛ تتيح هذه الحالة لعميل TCP إعادة إرسال الإقرار النهائي إلى الخادم في حالة فقد الإقرار أثناء النقل. تعتمد مدة الوقت على التنفيذ، ولكن بعض القيم الشائعة هي 30 ثانية ودقيقة واحدة ودقيقتين. بعد مهلة زمنية، يدخل العميل حالة CLOSED ويصبح المنفذ المحلي متاحًا لاتصالات جديدة. ^[32]

من الممكن أيضًا إنهاء الاتصال عن طريق مصافحة ثلاثية الاتجاهات، عندما يرسل المضيف أ FIN ويرد المضيف ب بـ FIN & ACK (دمج الخطوتين في واحدة) ويرد المضيف أ بـ ACK. ^[33]

^تطبق بعض أنظمة التشغيل، مثل Linux و HP-UX ، تسلسل إغلاق نصف مزدوج. إذا أغلق المضيف اتصالاً ^{بنشاط ، مع استمرار توفر بيانات واردة غير مقروءة، يرسل المضيف إشارة RST (فقدان أي بيانات مستلمة) بدلاً من} FIN. يضمن هذا أن تطبيق TCP على علم بوجود فقدان للبيانات. ^[34]

يمكن أن يكون الاتصال في حالة نصف مفتوحة ، وفي هذه الحالة يكون أحد الجانبين قد أنهى الاتصال، ولكن الجانب الآخر لم يقم بذلك. لا يمكن للجانب الذي أنهى الاتصال إرسال أي بيانات إلى الاتصال، ولكن يمكن للجانب الآخر القيام بذلك. يجب أن يستمر الجانب الذي أنهى الاتصال في قراءة البيانات حتى ينهي الجانب الآخر الاتصال أيضًا. ^{[ بحاجة لمصدر ]}

تخصص معظم التطبيقات إدخالاً في جدول يربط جلسة بعملية نظام تشغيل قيد التشغيل. ولأن حزم TCP لا تتضمن معرف جلسة، فإن كلا النقطتين النهائيتين تحددان الجلسة باستخدام عنوان ومنفذ العميل. كلما تم استلام حزمة، يجب على تطبيق TCP إجراء بحث في هذا الجدول للعثور على عملية الوجهة. يُعرف كل إدخال في الجدول باسم كتلة التحكم في الإرسال أو TCB. ويحتوي على معلومات حول النقاط النهائية (عنوان IP والمنفذ)، وحالة الاتصال، والبيانات الجارية حول الحزم التي يتم تبادلها، والمخازن المؤقتة لإرسال واستقبال البيانات.

يقتصر عدد الجلسات في جانب الخادم على الذاكرة فقط ويمكن أن يزداد مع وصول اتصالات جديدة، ولكن يجب على العميل تخصيص منفذ مؤقت قبل إرسال أول SYN إلى الخادم. يظل هذا المنفذ مخصصًا طوال المحادثة ويحد فعليًا من عدد الاتصالات الصادرة من كل عنوان IP للعميل. إذا فشل أحد التطبيقات في إغلاق الاتصالات غير المطلوبة بشكل صحيح، فقد ينفد موارد العميل ويصبح غير قادر على إنشاء اتصالات TCP جديدة، حتى من تطبيقات أخرى.

يجب على كلا نقطتي النهاية أيضًا تخصيص مساحة للحزم غير المؤكدة والبيانات المستلمة (ولكن غير المقروءة).

يختلف بروتوكول التحكم في الإرسال عن بروتوكول بيانات المستخدم في العديد من الميزات الرئيسية :

• نقل البيانات المنظم: يقوم المضيف الوجهة بإعادة ترتيب المقاطع وفقًا لرقم تسلسلي ^[13]
• إعادة إرسال الحزم المفقودة: يتم إعادة إرسال أي تدفق تراكمي غير معترف به ^[13]
• نقل البيانات بدون أخطاء: يتم التعامل مع الحزم التالفة على أنها مفقودة ويتم إعادة إرسالها ^[14]
• التحكم في التدفق: يحدد معدل نقل المرسل للبيانات لضمان التسليم الموثوق. يلمح المستقبل باستمرار إلى المرسل بشأن مقدار البيانات التي يمكن استلامها. عندما يمتلئ مخزن المضيف المستقبل، يعلق الإقرار التالي النقل ويسمح بمعالجة البيانات الموجودة في المخزن. ^[13]
• التحكم في الازدحام: تؤدي الحزم المفقودة (التي يُفترض أنها بسبب الازدحام) إلى انخفاض معدل تسليم البيانات ^[13]

يستخدم بروتوكول TCP رقم تسلسل لتحديد كل بايت من البيانات. يحدد رقم التسلسل ترتيب البايتات المرسلة من كل جهاز كمبيوتر حتى يمكن إعادة بناء البيانات بالترتيب، بغض النظر عن أي تسليم خارج الترتيب قد يحدث. يتم اختيار رقم التسلسل للبايت الأول بواسطة المرسل للحزمة الأولى، والتي يتم تمييزها بعلامة SYN. ​​يمكن أن يكون هذا الرقم تعسفيًا، ويجب أن يكون في الواقع غير قابل للتنبؤ به للدفاع ضد هجمات التنبؤ بتسلسل بروتوكول TCP .

يتم إرسال الإقرارات (ACKs) برقم تسلسلي من قبل متلقي البيانات لإخبار المرسل بأن البيانات قد تم استلامها إلى البايت المحدد. لا تعني الإقرارات أن البيانات تم تسليمها إلى التطبيق، بل تشير فقط إلى أن مسؤولية تسليم البيانات تقع الآن على عاتق المتلقي.

يتم تحقيق الموثوقية من خلال اكتشاف المرسل للبيانات المفقودة وإعادة إرسالها. يستخدم بروتوكول التحكم في الإرسال (TCP) تقنيتين أساسيتين لتحديد الفقدان. مهلة إعادة الإرسال (RTO) والإقرارات التراكمية المكررة (DupAcks).

عندما يتم إعادة إرسال جزء TCP، فإنه يحتفظ بنفس رقم التسلسل مثل محاولة التسليم الأصلية. هذا الدمج بين التسليم وترتيب البيانات المنطقية يعني أنه عند تلقي الإقرار بعد إعادة الإرسال، لا يستطيع المرسل معرفة ما إذا كان يتم الإقرار بالإرسال الأصلي أو إعادة الإرسال، وهو ما يسمى غموض إعادة الإرسال . ^[35] يتعرض TCP للتعقيد بسبب غموض إعادة الإرسال. ^[36]

إذا فقدت قطعة واحدة (لنفترض رقم القطعة 100) في مجرى ما، فلن يتمكن المستقبل من تأكيد الحزم التي تزيد عن رقم القطعة (100) لأنه يستخدم إقرارات تراكمية. وبالتالي، يقر المستقبل بالحزمة 99 مرة أخرى عند استلام حزمة بيانات أخرى. يتم استخدام هذا الإقرار المكرر كإشارة لفقدان الحزمة. أي أنه إذا تلقى المرسل ثلاثة إقرارات مكررة، فإنه يعيد إرسال آخر حزمة غير معترف بها. يتم استخدام عتبة ثلاثة لأن الشبكة قد تعيد ترتيب القطع مما يتسبب في إقرارات مكررة. وقد ثبت أن هذه العتبة تتجنب عمليات إعادة الإرسال الزائفة بسبب إعادة الترتيب. ^[37] تستخدم بعض تطبيقات TCP الإقرارات الانتقائية (SACKs) لتوفير ملاحظات صريحة حول القطع التي تم استلامها. وهذا يحسن بشكل كبير من قدرة TCP على إعادة إرسال القطع الصحيحة.

يمكن أن يتسبب غموض إعادة الإرسال في حدوث عمليات إعادة إرسال سريعة زائفة وتجنب الازدحام إذا كان هناك إعادة ترتيب يتجاوز عتبة الإقرار المكرر. ^[38] في العقدين الماضيين، لوحظ المزيد من إعادة ترتيب الحزم عبر الإنترنت ^[39] مما دفع تنفيذات TCP، مثل تلك الموجودة في Linux Kernel إلى تبني أساليب استدلالية لتوسيع عتبة الإقرار المكرر. ^[40] في الآونة الأخيرة، كانت هناك جهود للتخلص التدريجي تمامًا من عمليات إعادة الإرسال السريعة القائمة على dupack واستبدالها بأخرى تعتمد على المؤقت. ^[41] (لا ينبغي الخلط بينه وبين RTO الكلاسيكي الذي تمت مناقشته أدناه). تم اعتماد خوارزمية اكتشاف الخسارة القائمة على الوقت والتي تسمى الإقرار الأخير (RACK) ^[42] كخوارزمية افتراضية في Linux وWindows. ^[43]

عندما يرسل المرسل مقطعًا، فإنه يقوم بتهيئة مؤقت بتقدير متحفظ لوقت وصول الإقرار. يتم إعادة إرسال المقطع إذا انتهى المؤقت، مع حد مهلة جديد يبلغ ضعف القيمة السابقة، مما يؤدي إلى سلوك تراجع أسي . عادةً، تكون قيمة المؤقت الأولية هي ، حيث هي حبيبات الساعة. ^[44] هذا يحمي من حركة المرور المفرطة في الإرسال بسبب الجهات الفاعلة المعيبة أو الخبيثة، مثل مهاجمي رفض الخدمة من الوسط . ${\displaystyle {\text{smoothed RTT}}+\max(G,4\times {\text{RTT variation}})}$${\displaystyle G}$

تعتبر تقديرات RTT الدقيقة مهمة لاستعادة الخسارة، حيث إنها تسمح للمرسل بافتراض فقدان حزمة غير مؤكدة بعد مرور وقت كافٍ (أي تحديد وقت RTO). ^[45] يمكن أن يؤدي غموض إعادة الإرسال إلى أن يكون تقدير المرسل لـ RTT غير دقيق. ^[45] في بيئة ذات أوقات RTT متغيرة، يمكن أن تحدث مهلة زمنية زائفة: ^[46] إذا تم التقليل من تقدير RTT، فإن RTO ينطلق ويؤدي إلى إعادة إرسال غير ضرورية وبدء بطيء. بعد إعادة إرسال زائفة، عندما تصل الإقرارات للإرسالات الأصلية، قد يعتقد المرسل أنها تقر بإعادة الإرسال ويستنتج بشكل غير صحيح أن المقاطع المرسلة بين الإرسال الأصلي وإعادة الإرسال قد فقدت، مما يتسبب في المزيد من عمليات إعادة الإرسال غير الضرورية إلى الحد الذي يصبح فيه الرابط مزدحمًا حقًا؛ ^{[47] [48]} يمكن أن يقلل الإقرار الانتقائي من هذا التأثير. ^[49] تحدد RFC 6298 أنه لا يجب على التطبيقات استخدام المقاطع المعاد إرسالها عند تقدير RTT. ^{[50] تضمن} خوارزمية Karn إنتاج تقدير جيد لـ RTT - في النهاية - من خلال الانتظار حتى يكون هناك إقرار لا لبس فيه قبل ضبط RTO. ^[51] ومع ذلك، بعد عمليات إعادة الإرسال الزائفة، قد يستغرق الأمر وقتًا طويلاً قبل وصول مثل هذا الإقرار الواضح، مما يؤدي إلى تدهور الأداء في هذه الأثناء. ^[52] تعمل طوابع زمنية TCP أيضًا على حل مشكلة غموض إعادة الإرسال في ضبط RTO، ^[50] على الرغم من أنها لا تعمل بالضرورة على تحسين تقدير RTT. ^[53]

تسمح أرقام التسلسل للمستقبلين بالتخلص من الحزم المكررة وترتيب الحزم غير المرتبة بشكل صحيح. تسمح الإقرارات للمرسلين بتحديد موعد إعادة إرسال الحزم المفقودة.

لضمان صحة البيانات، يتم تضمين حقل المجموع الاختباري؛ راجع § حساب المجموع الاختباري للحصول على التفاصيل. المجموع الاختباري لـ TCP هو اختبار ضعيف وفقًا للمعايير الحديثة وعادةً ما يقترن بفحص سلامة CRC في الطبقة 2 ، أسفل كل من TCP وIP، كما هو مستخدم في PPP أو إطار Ethernet . ومع ذلك، فإن إدخال أخطاء في الحزم بين القفزات المحمية بواسطة CRC أمر شائع ويلتقط المجموع الاختباري لـ TCP المكون من 16 بت معظم هذه الأخطاء. ^[54]

يستخدم بروتوكول التحكم في التدفق من البداية إلى النهاية لتجنب إرسال المرسل للبيانات بسرعة كبيرة بحيث لا يتمكن المستقبل من استقبالها ومعالجتها بشكل موثوق. يعد وجود آلية للتحكم في التدفق أمرًا ضروريًا في بيئة تتواصل فيها أجهزة ذات سرعات شبكة مختلفة. على سبيل المثال، إذا أرسل جهاز كمبيوتر بيانات إلى هاتف ذكي يعالج البيانات المستلمة ببطء، فيجب أن يكون الهاتف الذكي قادرًا على تنظيم تدفق البيانات حتى لا يغمره. ^[13]

يستخدم بروتوكول التحكم في التدفق نافذة منزلقة . في كل جزء من أجزاء بروتوكول التحكم في الإرسال، يحدد المستقبل في حقل نافذة الاستقبال مقدار البيانات الإضافية المستقبلة (بالبايتات) التي يرغب في تخزينها مؤقتًا للاتصال. لا يمكن للمضيف المرسل إرسال سوى هذا المقدار من البيانات قبل أن يتعين عليه انتظار الإقرار وتحديث نافذة الاستقبال من المضيف المستقبل.

عندما يعلن المستقبل عن حجم نافذة 0، يتوقف المرسل عن إرسال البيانات ويبدأ مؤقت الاستمرار . يُستخدم مؤقت الاستمرار لحماية TCP من موقف الجمود الذي قد ينشأ في حالة فقد تحديث لاحق لحجم النافذة من المستقبل، ولا يستطيع المرسل إرسال المزيد من البيانات حتى استلام تحديث جديد لحجم النافذة من المستقبل. عندما تنتهي صلاحية مؤقت الاستمرار، يحاول مرسل TCP الاسترداد عن طريق إرسال حزمة صغيرة حتى يستجيب المستقبل بإرسال إقرار آخر يحتوي على حجم النافذة الجديد.

إذا كان جهاز الاستقبال يعالج البيانات الواردة بزيادات صغيرة، فقد يعلن بشكل متكرر عن نافذة استقبال صغيرة. ويشار إلى هذا بمتلازمة النافذة السخيفة ، حيث أنه من غير الفعّال إرسال بضعة بايتات فقط من البيانات في جزء TCP، نظرًا للتكلفة الزائدة الكبيرة نسبيًا لرأس TCP.

الجانب الرئيسي الأخير لبروتوكول التحكم في الإرسال هو التحكم في الازدحام . يستخدم بروتوكول التحكم في الإرسال عددًا من الآليات لتحقيق أداء عالٍ وتجنب الانهيار الازدحامي ، وهو موقف متوقف حيث يتدهور أداء الشبكة بشدة. تتحكم هذه الآليات في معدل البيانات التي تدخل الشبكة، مما يحافظ على تدفق البيانات أقل من المعدل الذي قد يؤدي إلى الانهيار. كما أنها توفر تخصيصًا عادلاً تقريبًا بين التدفقات.

يستخدم المرسلون إشعارات استلام البيانات المرسلة، أو عدم وجود إشعارات، لاستنتاج ظروف الشبكة بين المرسل والمستقبل عبر بروتوكول التحكم في الإرسال (TCP). وباستخدام المؤقتات، يمكن للمرسلين والمستقبلين عبر بروتوكول التحكم في الإرسال (TCP) تغيير سلوك تدفق البيانات. ويشار إلى هذا بشكل عام باسم التحكم في الازدحام أو تجنب الازدحام.

تحتوي التطبيقات الحديثة لبروتوكول التحكم في الإرسال على أربع خوارزميات متشابكة: البداية البطيئة ، وتجنب الازدحام ، وإعادة الإرسال السريع ، والاسترداد السريع . ^[55]

بالإضافة إلى ذلك، يستخدم المرسلون مهلة إعادة الإرسال (RTO) التي تعتمد على وقت الرحلة ذهابًا وإيابًا المقدر (RTT) بين المرسل والمستقبل، بالإضافة إلى التباين في وقت الرحلة ذهابًا وإيابًا هذا. ^[56] هناك تفاصيل دقيقة في تقدير RTT. على سبيل المثال، يجب على المرسلين توخي الحذر عند حساب عينات RTT للحزم المعاد إرسالها؛ وعادةً ما يستخدمون خوارزمية كارن أو طوابع زمنية TCP. ^[26] ثم يتم حساب متوسط ​​عينات RTT الفردية هذه بمرور الوقت لإنشاء وقت رحلة ذهابًا وإيابًا سلسًا (SRTT) باستخدام خوارزمية جاكوبسون. قيمة SRTT هذه هي ما يتم استخدامه كتقدير لوقت الرحلة ذهابًا وإيابًا.

إن تحسين بروتوكول التحكم في الإرسال (TCP) للتعامل بشكل موثوق مع الخسارة وتقليل الأخطاء وإدارة الازدحام والتحرك بسرعة في البيئات عالية السرعة هي مجالات بحثية مستمرة وتطوير معايير. ونتيجة لذلك، هناك عدد من الاختلافات في خوارزميات تجنب ازدحام بروتوكول التحكم في الإرسال (TCP) .

الحجم الأقصى للقطعة (MSS) هو أكبر كمية من البيانات، المحددة بالبايتات، التي يرغب TCP في تلقيها في قطعة واحدة. للحصول على أفضل أداء، يجب ضبط MSS على حجم صغير بما يكفي لتجنب تجزئة IP ، مما قد يؤدي إلى فقدان الحزم وإعادة الإرسال المفرطة. لتحقيق ذلك، عادةً ما يتم الإعلان عن MSS من قبل كل جانب باستخدام خيار MSS عند إنشاء اتصال TCP. يتم اشتقاق قيمة الخيار من حجم وحدة الإرسال القصوى (MTU) لطبقة ارتباط البيانات للشبكات التي يتصل بها المرسل والمستقبل مباشرة. يمكن لمرسلي TCP استخدام اكتشاف MTU للمسار لاستنتاج الحد الأدنى لـ MTU على طول مسار الشبكة بين المرسل والمستقبل، واستخدام هذا لضبط MSS ديناميكيًا لتجنب تجزئة IP داخل الشبكة.

قد يُطلق على إعلان MSS أيضًا اسم تفاوض MSS ، ولكن بالمعنى الدقيق للكلمة، لا يتم التفاوض على MSS . يُسمح بقيمتين مستقلتين تمامًا لـ MSS لاتجاهي تدفق البيانات في اتصال TCP، ^{[57] [16]} لذلك ليست هناك حاجة للاتفاق على تكوين MSS مشترك لاتصال ثنائي الاتجاه.

إن الاعتماد بشكل كامل على مخطط الإقرار التراكمي الذي يستخدمه بروتوكول TCP الأصلي قد يؤدي إلى عدم الكفاءة عند فقدان الحزم. على سبيل المثال، لنفترض أن البايتات التي تحمل رقم التسلسل 1000 إلى 10999 يتم إرسالها في 10 قطاعات TCP مختلفة بنفس الحجم، وأن القطاع الثاني (أرقام التسلسل 2000 إلى 2999) قد ضاع أثناء الإرسال. في بروتوكول الإقرار التراكمي البحت، لا يستطيع المستقبل إلا إرسال قيمة إقرار تراكمية تبلغ 2000 (رقم التسلسل الذي يلي مباشرة آخر رقم تسلسل للبيانات المستلمة) ولا يمكنه القول إنه تلقى البايتات 3000 إلى 10999 بنجاح. وبالتالي، قد يضطر المرسل بعد ذلك إلى إعادة إرسال جميع البيانات التي تبدأ برقم التسلسل 2000.

لتخفيف هذه المشكلة، يستخدم بروتوكول TCP خيار الإقرار الانتقائي (SACK) ، الذي تم تعريفه في عام 1996 في RFC 2018، والذي يسمح للمستقبل بالإقرار بالكتل المتقطعة من الحزم التي تم استلامها بشكل صحيح، بالإضافة إلى رقم التسلسل الذي يلي مباشرة آخر رقم تسلسل لآخر بايت متجاور تم استلامه على التوالي، كما هو الحال في إقرار TCP الأساسي. يمكن أن يتضمن الإقرار عددًا من كتل SACK ، حيث يتم نقل كل كتلة SACK بواسطة الحافة اليسرى للكتلة (رقم التسلسل الأول للكتلة) والحافة اليمنى للكتلة (رقم التسلسل الذي يلي مباشرة آخر رقم تسلسل للكتلة)، مع كون الكتلة نطاقًا متجاورًا استقبله المستقبل بشكل صحيح. في المثال أعلاه، سيرسل المستقبل مقطع إقرار بقيمة إقرار تراكمية تبلغ 2000 ورأس خيار SACK بأرقام التسلسل 3000 و11000. وعليه، فإن المرسل سوف يعيد إرسال الجزء الثاني فقط بأرقام التسلسل من 2000 إلى 2999.

قد يفسر مرسل TCP تسليم شريحة غير مرتبة على أنها شريحة مفقودة. وإذا فعل ذلك، فسيعيد مرسل TCP إرسال الشريحة السابقة للحزمة غير المرتبة ويبطئ معدل تسليم البيانات لهذا الاتصال. يحل خيار duplicate-SACK، وهو امتداد لخيار SACK الذي تم تعريفه في مايو 2000 في RFC 2883، هذه المشكلة. بمجرد اكتشاف مستقبل TCP لحزمة مكررة ثانية، فإنه يرسل D-ACK للإشارة إلى عدم فقد أي شرائح، مما يسمح لمرسل TCP بإعادة معدل الإرسال الأعلى.

لا يعد خيار SACK إلزاميًا ولا يدخل حيز التنفيذ إلا إذا كان الطرفان يدعمانه. يتم التفاوض على ذلك عند إنشاء اتصال. يستخدم SACK خيار رأس TCP (انظر § بنية شريحة TCP للحصول على التفاصيل). أصبح استخدام SACK واسع الانتشار - تدعمه جميع حزم TCP الشائعة. يتم استخدام الإقرار الانتقائي أيضًا في بروتوكول نقل التحكم في التدفق (SCTP).

يمكن "التراجع" عن الإقرارات الانتقائية، حيث يتجاهل المستقبل من جانب واحد البيانات التي تم الإقرار بها انتقائيًا. لقد ثبطت RFC 2018 مثل هذا السلوك، لكنها لم تحظره للسماح للمستقبلين بخيار التراجع إذا نفدت مساحة المخزن المؤقت لديهم على سبيل المثال. ^[58] تؤدي إمكانية التراجع إلى تعقيد التنفيذ لكل من المرسلين والمستقبلين، كما تفرض تكاليف الذاكرة على المرسل. ^[59]

من أجل استخدام أكثر كفاءة لشبكات النطاق الترددي العالي، يمكن استخدام حجم نافذة TCP أكبر. يتحكم حقل حجم نافذة TCP 16 بت في تدفق البيانات وتقتصر قيمته على 65535 بايت. نظرًا لأنه لا يمكن توسيع حقل الحجم إلى ما بعد هذا الحد، يتم استخدام عامل التدرج. يعد خيار مقياس نافذة TCP ، كما هو محدد في RFC 1323، خيارًا يستخدم لزيادة الحد الأقصى لحجم النافذة إلى 1 جيجابايت. يعد التدرج إلى أحجام النوافذ الأكبر هذه ضروريًا لضبط TCP .

يتم استخدام خيار مقياس النافذة فقط أثناء المصافحة ثلاثية الاتجاهات لبروتوكول TCP. تمثل قيمة مقياس النافذة عدد البتات التي يجب تحريك حقل حجم النافذة المكون من 16 بتًا إلى اليسار عند تفسيره. يمكن ضبط قيمة مقياس النافذة من 0 (بدون تحريك) إلى 14 لكل اتجاه بشكل مستقل. يجب على كلا الجانبين إرسال الخيار في مقاطع SYN الخاصة بهما لتمكين تحريك النافذة في أي اتجاه.

تقوم بعض أجهزة التوجيه وجدران الحماية الخاصة بالحزم بإعادة كتابة عامل قياس النافذة أثناء الإرسال. ويؤدي هذا إلى جعل الجانبين المرسل والمستقبل يتخذان أحجامًا مختلفة لنافذة TCP. والنتيجة هي حركة مرور غير مستقرة وقد تكون بطيئة للغاية. وتظهر المشكلة في بعض المواقع خلف جهاز توجيه معيب. ^[60]

يمكن أن تساعد طوابع TCP الزمنية، المحددة في RFC 1323 في عام 1992، TCP في تحديد الترتيب الذي تم إرسال الحزم به. لا تتم محاذاة طوابع TCP الزمنية عادةً مع ساعة النظام وتبدأ بقيمة عشوائية. ستزيد العديد من أنظمة التشغيل من الطابع الزمني لكل مللي ثانية منقضية؛ ومع ذلك، تنص RFC فقط على أن النبضات يجب أن تكون متناسبة.

هناك حقلين للطابع الزمني:

• قيمة طابع زمني للمرسل مكونة من 4 بايتات (طابع زمني خاص بي)
• قيمة طابع زمني للرد على الصدى مكونة من 4 بايتات (أحدث طابع زمني تم استلامه منك).

تُستخدم طوابع زمنية لبروتوكول TCP في خوارزمية تُعرف باسم الحماية ضد أرقام التسلسل المغلفة، أو PAWS . تُستخدم PAWS عندما تتجاوز نافذة الاستلام حدود التفاف رقم التسلسل. وفي حالة إعادة إرسال حزمة محتملة، فإنها تجيب على السؤال: "هل رقم التسلسل هذا موجود في أول 4 جيجابايت أم الثانية؟" ويُستخدم الطابع الزمني لكسر التعادل.

كما تستخدم خوارزمية اكتشاف Eifel طوابع زمنية TCP لتحديد ما إذا كانت عمليات إعادة الإرسال تحدث بسبب فقدان الحزم أو خروجها عن الترتيب ببساطة. ^[61]

يتم تمكين الطوابع الزمنية لـ TCP افتراضيًا في Linux، ^[62] ويتم تعطيلها افتراضيًا في Windows Server 2008 و2012 و2016. ^[63]

تظهر الإحصائيات الأخيرة أن مستوى اعتماد الطابع الزمني لـ TCP قد توقف عند حوالي 40%، وذلك بسبب توقف Windows Server عن الدعم منذ Windows Server 2008. ^[64]

من الممكن مقاطعة أو إلغاء التدفق الموجود في قائمة الانتظار بدلاً من انتظار انتهاء التدفق. يتم ذلك عن طريق تحديد البيانات على أنها عاجلة . هذا يميز الإرسال كبيانات خارج النطاق (OOB) ويخبر البرنامج المستقبل بمعالجتها على الفور. عند الانتهاء، يقوم TCP بإبلاغ التطبيق واستئناف قائمة انتظار التدفق. أحد الأمثلة على ذلك هو عندما يتم استخدام TCP لجلسة تسجيل دخول عن بُعد حيث يمكن للمستخدم إرسال تسلسل لوحة مفاتيح يقاطع أو يلغى البرنامج الذي يعمل عن بُعد دون انتظار البرنامج لإنهاء نقله الحالي. ^[13]

لا يغير المؤشر العاجل سوى المعالجة على المضيف البعيد ولا يسرع أي معالجة على الشبكة نفسها. يتم تنفيذ هذه القدرة بشكل مختلف أو سيئ على أنظمة مختلفة أو قد لا تكون مدعومة. عندما تكون متاحة، فمن الحكمة افتراض أن بايتات مفردة فقط من بيانات OOB سيتم التعامل معها بشكل موثوق. ^{[65] [66]} نظرًا لأن الميزة لا تُستخدم بشكل متكرر، فهي غير مُختبرة جيدًا على بعض الأنظمة الأساسية وقد ارتبطت بثغرات أمنية ، على سبيل المثال WinNuke .

في العادة، ينتظر بروتوكول TCP لمدة 200 مللي ثانية لإرسال حزمة بيانات كاملة ( تحاول خوارزمية ناجل تجميع الرسائل الصغيرة في حزمة واحدة). ويؤدي هذا الانتظار إلى حدوث تأخيرات صغيرة ولكنها خطيرة محتملة إذا تكررت باستمرار أثناء نقل الملف. على سبيل المثال، تكون كتلة الإرسال النموذجية 4 كيلوبايت، وتكون MSS النموذجية 1460، وبالتالي تخرج حزمتان على شبكة إيثرنت بسرعة 10 ميجابت/ثانية تستغرق كل منهما حوالي 1.2 مللي ثانية تليها حزمة ثالثة تحمل الـ 1176 المتبقية بعد توقف مؤقت لمدة 197 مللي ثانية لأن بروتوكول TCP ينتظر امتلاء المخزن المؤقت. وفي حالة بروتوكول telnet، يتم إرجاع كل ضغطة مفتاح من قبل الخادم قبل أن يتمكن المستخدم من رؤيتها على الشاشة. ويصبح هذا التأخير مزعجًا للغاية.

يؤدي ضبط خيار المقبسTCP_NODELAY إلى تجاوز فترة التأخير الافتراضية للإرسال والتي تبلغ 200 مللي ثانية. تستخدم برامج التطبيقات خيار المقبس هذا لإجبار إرسال الإخراج بعد كتابة حرف أو سطر من الأحرف.

يحدد RFC ^{[ which? ]}PSH بت الدفع على أنه "رسالة إلى مكدس TCP المستقبل لإرسال هذه البيانات على الفور إلى التطبيق المستقبل". ^[13] لا توجد طريقة للإشارة إليها أو التحكم فيها في مساحة المستخدم باستخدام مآخذ بيركلي ؛ يتم التحكم فيها بواسطة مكدس البروتوكول فقط. ^[67]

قد يتعرض بروتوكول التحكم في الإرسال للهجوم بعدة طرق. وقد نُشرت نتائج تقييم أمني شامل لبروتوكول التحكم في الإرسال، إلى جانب التدابير الممكنة للتخفيف من حدة المشكلات التي تم تحديدها، في عام 2009، ^[68] وتم متابعتها داخل فريق عمل هندسة الإنترنت (IETF) حتى عام 2012. ^[69] وتتضمن نقاط الضعف البارزة رفض الخدمة، واختطاف الاتصال، ونقض بروتوكول التحكم في الإرسال، وهجوم إعادة تعيين بروتوكول التحكم في الإرسال .

من خلال استخدام عنوان IP مزيف وإرسال حزم SYN مجمعة بشكل مقصود بشكل متكرر ، متبوعة بالعديد من حزم ACK، يمكن للمهاجمين التسبب في استهلاك الخادم لكميات كبيرة من الموارد لتتبع الاتصالات المزيفة. يُعرف هذا باسم هجوم SYN Flux . تتضمن الحلول المقترحة لهذه المشكلة ملفات تعريف ارتباط SYN والألغاز التشفيرية، على الرغم من أن ملفات تعريف ارتباط SYN تأتي مع مجموعة خاصة بها من نقاط الضعف. ^[70] Sockstress هو هجوم مماثل، يمكن تخفيفه من خلال إدارة موارد النظام. ^{[71] تم تحليل هجوم DoS متقدم يتضمن استغلال} مؤقت استمرار TCP في Phrack No. 66. ^{[72] تعد} فيضانات PUSH وACK متغيرات أخرى. ^[73]

يمكن للمهاجم الذي يستطيع التنصت على جلسة TCP وإعادة توجيه الحزم أن يختطف اتصال TCP. للقيام بذلك، يتعلم المهاجم رقم التسلسل من الاتصال الجاري ويزور مقطعًا زائفًا يبدو مثل المقطع التالي في الدفق. يمكن أن يؤدي الاختطاف البسيط إلى قبول حزمة واحدة عن طريق الخطأ في أحد الطرفين. عندما يقر المضيف المتلقي بالمقطع الزائف، يتم فقد المزامنة. ^[74] يمكن دمج الاختطاف مع انتحال ARP أو هجمات التوجيه الأخرى التي تسمح للمهاجم بالسيطرة الدائمة على اتصال TCP.

لم يكن انتحال عنوان IP مختلف أمرًا صعبًا قبل RFC 1948 عندما كان من السهل تخمين رقم التسلسل الأولي . سمحت التنفيذات السابقة للمهاجم بإرسال سلسلة من الحزم بشكل أعمى يعتقد المتلقي أنها جاءت من عنوان IP مختلف، دون الحاجة إلى اعتراض الاتصالات من خلال ARP أو هجمات التوجيه: يكفي التأكد من أن المضيف الشرعي لعنوان IP المنتحل معطل، أو إحضاره إلى هذه الحالة باستخدام هجمات رفض الخدمة . هذا هو السبب في اختيار رقم التسلسل الأولي الآن بشكل عشوائي.

يستطيع المهاجم الذي يستطيع التنصت والتنبؤ بحجم الحزمة التالية التي سيتم إرسالها أن يجعل المستقبل يقبل حمولة ضارة دون تعطيل الاتصال الحالي. يقوم المهاجم بحقن حزمة ضارة برقم التسلسل وحجم الحمولة للحزمة المتوقعة التالية. عندما يتم استلام الحزمة الشرعية في النهاية، يتم اكتشاف أنها تحمل نفس رقم التسلسل وطول الحزمة المستلمة بالفعل ويتم إسقاطها بصمت كحزمة مكررة عادية - يتم رفض الحزمة الشرعية بواسطة الحزمة الضارة. على عكس اختطاف الاتصال، لا يتم إلغاء مزامنة الاتصال أبدًا ويستمر الاتصال بشكل طبيعي بعد قبول الحمولة الضارة. يمنح رفض TCP المهاجم سيطرة أقل على الاتصال ولكنه يجعل الهجوم مقاومًا بشكل خاص للكشف. الدليل الوحيد للمستقبل على وجود خطأ ما هو حزمة مكررة واحدة، وهو حدث طبيعي في شبكة IP. لا يرى مرسل الحزمة التي تم رفضها أي دليل على وجود هجوم. ^[75]

يتم تحديد اتصال TCP من خلال أربعة أرقام من عنوان المصدر ومنفذ المصدر وعنوان الوجهة ومنفذ الوجهة. ^{[d] [76] [77]} تُستخدم أرقام المنافذ لتحديد الخدمات المختلفة، والسماح باتصالات متعددة بين المضيفين. ^[14] يستخدم TCP أرقام منافذ مكونة من 16 بتًا ، مما يوفر 65536 قيمة ممكنة لكل من منافذ المصدر والوجهة. ^[17] تعني اعتماد هوية الاتصال على العناوين أن اتصالات TCP مرتبطة بمسار شبكة واحد؛ لا يمكن لـ TCP استخدام طرق أخرى متاحة للمضيفين متعددي المنازل ، وتنقطع الاتصالات إذا تغير عنوان نقطة النهاية. ^[78]

يتم تصنيف أرقام المنافذ إلى ثلاث فئات أساسية: معروفة ومسجلة وديناميكية أو خاصة. يتم تعيين المنافذ المعروفة بواسطة هيئة أرقام الإنترنت المخصصة (IANA) وعادةً ما تستخدمها العمليات على مستوى النظام. تستخدم التطبيقات المعروفة التي تعمل كخوادم وتستمع بشكل سلبي للاتصالات هذه المنافذ عادةً. تتضمن بعض الأمثلة: FTP (20 و21)، وSSH (22)، و TELNET (23)، و SMTP (25)، و HTTP عبر SSL/TLS (443)، و HTTP (80). ^[e] تُستخدم المنافذ المسجلة عادةً بواسطة تطبيقات المستخدم النهائي كمنافذ مصدر مؤقتة عند الاتصال بالخوادم، ولكنها يمكنها أيضًا تحديد الخدمات المسماة التي تم تسجيلها بواسطة جهة خارجية. يمكن أيضًا استخدام المنافذ الديناميكية أو الخاصة بواسطة تطبيقات المستخدم النهائي، ومع ذلك، لا تحتوي هذه المنافذ عادةً على أي معنى خارج اتصال TCP معين.

تستخدم ترجمة عناوين الشبكة (NAT) عادةً أرقام منافذ ديناميكية، على الجانب المواجه للجمهور، لإزالة الغموض عن تدفق حركة المرور التي تمر بين شبكة عامة وشبكة فرعية خاصة ، مما يسمح بخدمة العديد من عناوين IP (ومنافذها) على الشبكة الفرعية بواسطة عنوان عام واحد.

يُعد بروتوكول التحكم في الإرسال (TCP) بروتوكولًا معقدًا. ومع ذلك، على الرغم من التحسينات الكبيرة التي تم إجراؤها واقتراحها على مر السنين، فإن تشغيله الأساسي لم يتغير بشكل كبير منذ مواصفة RFC 675 الأولى في عام 1974، ومواصفات الإصدار الرابع RFC 793، المنشورة في سبتمبر 1981. أوضحت RFC 1122، المنشورة في أكتوبر 1989، عددًا من متطلبات تنفيذ بروتوكول التحكم في الإرسال (TCP). تتوفر قائمة بالمواصفات الثمانية المطلوبة وأكثر من 20 تحسينًا مشجعًا بشدة في RFC 7414. ومن بين هذه القائمة RFC 2581، التحكم في ازدحام TCP، وهو أحد أهم RFCs المتعلقة بـ TCP في السنوات الأخيرة، ويصف خوارزميات محدثة تتجنب الازدحام غير المبرر. في عام 2001، تمت كتابة RFC 3168 لوصف إشعار الازدحام الصريح (ECN)، وهي آلية إشارات لتجنب الازدحام.

كانت خوارزمية تجنب ازدحام TCP الأصلية تُعرف باسم TCP Tahoe ، ولكن تم اقتراح العديد من الخوارزميات البديلة منذ ذلك الحين (بما في ذلك TCP Reno ، وTCP Vegas ، و FAST TCP ، و TCP New Reno ، و TCP Hybla ).

بروتوكول TCP متعدد المسارات (MPTCP) ^{[79] [80]} هو جهد مستمر ضمن IETF يهدف إلى السماح لاتصال TCP باستخدام مسارات متعددة لزيادة استخدام الموارد وزيادة التكرار. يتيح التكرار الذي يوفره بروتوكول TCP متعدد المسارات في سياق الشبكات اللاسلكية الاستخدام المتزامن لشبكات مختلفة، مما يوفر إنتاجية أعلى وقدرات تسليم أفضل. كما يوفر بروتوكول TCP متعدد المسارات فوائد الأداء في بيئات مراكز البيانات. ^[81] تم تطوير التنفيذ المرجعي ^[82] لبروتوكول TCP متعدد المسارات في نواة Linux. ^[83] يتم استخدام بروتوكول TCP متعدد المسارات لدعم تطبيق التعرف على الصوت Siri على أجهزة iPhone وiPad وMac. ^[84]

tcpcrypt هو امتداد تم اقتراحه في يوليو 2010 لتوفير تشفير على مستوى النقل مباشرة في TCP نفسه. تم تصميمه للعمل بشفافية وعدم الحاجة إلى أي تكوين. على عكس TLS (SSL)، لا يوفر tcpcrypt نفسه المصادقة، ولكنه يوفر بدائيات بسيطة للتطبيق للقيام بذلك. تم نشر RFC الخاص بـ tcpcrypt بواسطة IETF في مايو 2019. ^[85]

TCP Fast Open هو امتداد لتسريع فتح اتصالات TCP المتعاقبة بين نقطتي نهاية. وهو يعمل عن طريق تخطي المصافحة ثلاثية الاتجاهات باستخدام ملف تعريف ارتباط مشفر . وهو مشابه لاقتراح سابق يسمى T/TCP ، والذي لم يتم اعتماده على نطاق واسع بسبب مشكلات الأمان. ^[86] تم نشر TCP Fast Open باسم RFC 7413 في عام 2014. ^[87]

تم اقتراح Proportional Rate Reduction (PRR) في مايو 2013، وهو عبارة عن امتداد TCP تم تطويره بواسطة مهندسي Google. يضمن PRR أن يكون حجم نافذة TCP بعد الاسترداد قريبًا قدر الإمكان من عتبة البداية البطيئة . ^[88] تم تصميم الخوارزمية لتحسين سرعة الاسترداد وهي خوارزمية التحكم في الازدحام الافتراضية في نوى Linux 3.2+. ^[89]

معاملات ملفات تعريف الارتباط TCP (TCPCT) هي امتداد تم اقتراحه في ديسمبر 2009 ^[90] لتأمين الخوادم ضد هجمات رفض الخدمة. على عكس ملفات تعريف الارتباط SYN، لا يتعارض TCPCT مع امتدادات TCP الأخرى مثل توسيع النافذة . تم تصميم TCPCT بسبب ضروريات DNSSEC ، حيث يتعين على الخوادم التعامل مع أعداد كبيرة من اتصالات TCP قصيرة العمر. في عام 2016، تم إيقاف TCPCT لصالح TCP Fast Open. تم تغيير حالة RFC الأصلية إلى تاريخية . ^[91]

تتمثل إحدى الطرق للتغلب على متطلبات طاقة المعالجة لبروتوكول التحكم في الإرسال في بناء تطبيقات للأجهزة، والمعروفة على نطاق واسع باسم محركات تفريغ بروتوكول التحكم في الإرسال (TOE). تكمن المشكلة الرئيسية في محركات تفريغ بروتوكول التحكم في الإرسال في صعوبة دمجها في أنظمة الحوسبة، مما يتطلب تغييرات واسعة النطاق في نظام التشغيل الخاص بالكمبيوتر أو الجهاز.

توفر بيانات الأسلاك الخاصة ببروتوكول التحكم في الإرسال فرصًا كبيرة لجمع المعلومات وتعديلها للمراقبين على المسار، حيث يتم نقل بيانات بروتوكول التعريف في نص عادي . ^{[92] [93]} وفي حين أن هذه الشفافية مفيدة لمشغلي الشبكة ^[94] والباحثين، ^[95] فإن المعلومات التي يتم جمعها من بيانات بروتوكول التعريف قد تقلل من خصوصية المستخدم النهائي. ^[96] وقد أدت هذه الرؤية وقابلية تشكيل بيانات بروتوكول التعريف إلى صعوبة توسيع بروتوكول التحكم في الإرسال - وهي حالة من تصلب البروتوكول - حيث يمكن لأي عقدة وسيطة (" صندوق وسطي ") اتخاذ قرارات بناءً على تلك البيانات الوصفية أو حتى تعديلها، ^{[97] [98]} وكسر مبدأ النهاية إلى النهاية . ^[99] وجد أحد القياسات أن ثلث المسارات عبر الإنترنت تواجه وسيطًا واحدًا على الأقل يعدل بيانات بروتوكول التعريف، وأن 6.5٪ من المسارات تواجه تأثيرات تصلب ضارة من الوسطاء. ^[100] إن تجنب مخاطر التوسع من الوسطاء فرض قيودًا كبيرة على تصميم MPTCP ، ^{[101] [102]} كما أعاقت الصعوبات الناجمة عن الوسطاء نشر TCP Fast Open في متصفحات الويب . ^[103] مصدر آخر للتصلب هو صعوبة تعديل وظائف TCP في نقاط النهاية، عادةً في نواة نظام التشغيل ^[104] أو في الأجهزة التي تحتوي على محرك تفريغ TCP . ^[105]

نظرًا لأن بروتوكول التحكم في الإرسال يوفر للتطبيقات تجريدًا لتدفق بايتات موثوق به ، فقد يعاني من حجب رأس السطر : إذا تمت إعادة ترتيب الحزم أو فقدها وتحتاج إلى إعادة إرسالها (وبالتالي إعادة ترتيبها)، فقد يتم استلام البيانات من أجزاء لاحقة متسلسلة من التدفق قبل أجزاء سابقة متسلسلة من التدفق؛ ومع ذلك، لا يمكن عادةً استخدام البيانات اللاحقة حتى يتم استلام البيانات السابقة، مما يتسبب في حدوث تأخير في الشبكة . إذا تم تغليف رسائل متعددة مستقلة عالية المستوى وإرسالها في اتصال TCP واحد، فقد يتسبب حجب رأس السطر في معالجة رسالة مستلمة بالكامل تم إرسالها لاحقًا لانتظار تسليم رسالة تم إرسالها سابقًا. ^{[106] تحاول} متصفحات الويب التخفيف من حجب رأس السطر من خلال فتح اتصالات متوازية متعددة. يؤدي هذا إلى تكلفة إنشاء الاتصال بشكل متكرر، بالإضافة إلى مضاعفة الموارد اللازمة لتتبع هذه الاتصالات في نقاط النهاية. ^[107] تتمتع الاتصالات المتوازية أيضًا بميزة التحكم في الازدحام التي تعمل بشكل مستقل عن بعضها البعض، بدلاً من القدرة على تجميع المعلومات معًا والاستجابة بشكل أسرع لظروف الشبكة الملاحظة؛ ^[108] يمكن أن تتسبب أنماط الإرسال الأولية العدوانية لـ TCP في حدوث ازدحام إذا تم فتح اتصالات متوازية متعددة؛ ويؤدي نموذج العدالة لكل اتصال إلى احتكار الموارد بواسطة التطبيقات التي تتبنى هذا النهج. ^[109]

يُعد إنشاء الاتصال مساهمًا رئيسيًا في زمن الوصول كما يختبره مستخدمو الويب. ^{[110] [111]} تُدخل مصافحة TCP ثلاثية الاتجاهات زمن وصول واحد أثناء إنشاء الاتصال قبل إرسال البيانات. ^[111] بالنسبة للتدفقات القصيرة، تكون هذه التأخيرات كبيرة جدًا. ^{[112] تتطلب} أمان طبقة النقل (TLS) مصافحة خاصة بها لتبادل المفاتيح عند إنشاء الاتصال. نظرًا للتصميم الطبقي، تستمر مصافحة TCP ومصافحة TLS بشكل تسلسلي؛ لا يمكن أن تبدأ مصافحة TLS حتى تنتهي مصافحة TCP. ^[113] يلزم وجود مصافحتي RTT لإنشاء الاتصال باستخدام TLS 1.2 عبر TCP. ^{[114] يسمح} TLS 1.3 باستئناف اتصال RTT صفر في بعض الظروف، ولكن عند وضعه على طبقات عبر TCP، لا يزال يلزم وجود RTT واحد لمصافحة TCP، ولا يمكن لهذا مساعدة الاتصال الأولي؛ كما تقدم مصافحات RTT الصفرية تحديات تشفيرية، حيث أن تبادل المفاتيح غير التفاعلي الفعّال والآمن لإعادة التشغيل والآمن للأمام هو موضوع بحث مفتوح. ^[115] يسمح TCP Fast Open بنقل البيانات في الحزم الأولية (أي SYN وSYN-ACK)، مما يزيل زمن انتقال RTT واحد أثناء إنشاء الاتصال. ^[116] ومع ذلك، كان من الصعب نشر TCP Fast Open بسبب تصلب البروتوكول؛ اعتبارًا من عام 2020 ، لم تستخدمه أي متصفحات ويب بشكل افتراضي. ^{[103][update]}

يتأثر معدل نقل البيانات في بروتوكول التحكم في الإرسال بإعادة ترتيب الحزم . يمكن أن تتسبب الحزم المعاد ترتيبها في إرسال إقرارات مكررة، والتي إذا تجاوزت حدًا معينًا، فستؤدي بعد ذلك إلى إعادة إرسال زائفة والتحكم في الازدحام. يمكن أن يصبح سلوك الإرسال متقطعًا أيضًا، حيث يتم إقرار النطاقات الكبيرة دفعة واحدة عند استلام حزمة أعيد ترتيبها في بداية النطاق (بطريقة مماثلة لكيفية تأثير حظر رأس الخط على التطبيقات). ^[117] وجد بلانتون وأولمان (2002) أن معدل النقل كان مرتبطًا عكسيًا بكمية إعادة الترتيب، حتى الحد الذي يؤدي فيه كل إعادة ترتيب إلى إعادة إرسال زائفة. ^[118] يعتمد تخفيف إعادة الترتيب على قدرة المرسل على تحديد أنه أرسل إعادة إرسال زائفة، وبالتالي على حل غموض إعادة الإرسال. ^[119] قد يؤدي تقليل عمليات إعادة الإرسال الزائفة الناجمة عن إعادة الترتيب إلى إبطاء التعافي من الخسارة الحقيقية. ^[120]

يمكن أن يوفر الإقرار الانتقائي فائدة كبيرة للإنتاجية؛ حيث قام Bruyeron وHemon وZhang (1998) بقياس مكاسب تصل إلى 45%. ^[121] أحد العوامل المهمة في التحسين هو أن الإقرار الانتقائي يمكنه في كثير من الأحيان تجنب الدخول في بداية بطيئة بعد الخسارة وبالتالي يمكنه استخدام النطاق الترددي المتاح بشكل أفضل. ^[122] ومع ذلك، لا يمكن لـ TCP الإقرار بشكل انتقائي إلا بثلاث كتل من أرقام التسلسل كحد أقصى. يمكن أن يحد هذا من معدل إعادة الإرسال وبالتالي استعادة الخسارة أو يتسبب في إعادة إرسال غير ضرورية، خاصة في البيئات ذات الخسارة العالية. ^{[123] [124]}

تم تصميم بروتوكول التحكم في الإرسال في الأصل للشبكات السلكية. ويعتبر فقدان الحزمة نتيجة لازدحام الشبكة ويتم تقليل حجم نافذة الازدحام بشكل كبير كإجراء احترازي. ومع ذلك، من المعروف أن الروابط اللاسلكية تعاني من خسائر متقطعة ومؤقتة عادةً بسبب التلاشي والتظليل والتسليم والتداخل وتأثيرات الراديو الأخرى، والتي لا تعتبر ازدحامًا بشكل صارم. بعد التراجع (الخاطئ) لحجم نافذة الازدحام، بسبب فقدان الحزمة اللاسلكية، قد تكون هناك مرحلة تجنب الازدحام مع انخفاض متحفظ في حجم النافذة. يتسبب هذا في عدم استخدام رابط الراديو بشكل كافٍ. تم إجراء بحث مكثف لمكافحة هذه التأثيرات الضارة. يمكن تصنيف الحلول المقترحة على أنها حلول شاملة، تتطلب تعديلات على العميل أو الخادم، ^[125] حلول طبقة الارتباط، مثل بروتوكول الارتباط اللاسلكي ( RLP ) في الشبكات الخلوية، أو حلول تعتمد على الوكيل والتي تتطلب بعض التغييرات في الشبكة دون تعديل العقد الطرفية. ^{[125] [126]}

وقد تم اقتراح عدد من خوارزميات التحكم في الازدحام البديلة، مثل فيجاس ، وويستوود ، وفينو، وسانتا كروز، للمساعدة في حل مشكلة الاتصال اللاسلكي. ^{[ بحاجة لمصدر ]}

تتمثل فكرة مسرع TCP في إنهاء اتصالات TCP داخل معالج الشبكة ثم نقل البيانات إلى اتصال ثانٍ نحو النظام النهائي. يتم تخزين حزم البيانات التي تنشأ من المرسل مؤقتًا في عقدة المسرع، وهي المسؤولة عن إجراء عمليات إعادة الإرسال المحلية في حالة فقدان الحزمة. وبالتالي، في حالة حدوث خسائر، يتم تقصير حلقة التغذية الراجعة بين المرسل والمستقبل إلى تلك الموجودة بين عقدة التسريع والمستقبل والتي تضمن تسليمًا أسرع للبيانات إلى المستقبل. ^[127] يمكن لتسريع TCP تقليل وقت تحميل صفحات الويب / الملفات ويحسن أيضًا من إدراك المستخدم للسرعة في شبكة الهاتف المحمول. فيما يتعلق بالعمليات، يضمن تسريع TCP التلقائي دائمًا أن تنقل شبكة الهاتف المحمول أكثر من نصف البيانات على النحو الأمثل، مما يزيد من استخدام النطاق الترددي المتاح. ^[128]

نظرًا لأن بروتوكول TCP هو بروتوكول يتكيف مع المعدلات، فإن المعدل الذي يحقن به مرسل TCP الحزم في الشبكة يتناسب بشكل مباشر مع حالة الحمل السائدة داخل الشبكة بالإضافة إلى سعة معالجة المستقبل. يحكم المرسل على الظروف السائدة داخل الشبكة على أساس الإقرارات التي يتلقاها. تقسم عقدة التسارع حلقة التغذية الراجعة بين المرسل والمستقبل وبالتالي تضمن وقت رحلة ذهاب وإياب أقصر (RTT) لكل حزمة. يعد وقت الرحلة ذهابًا وإيابًا الأقصر مفيدًا لأنه يضمن وقت استجابة أسرع لأي تغييرات في الشبكة وتكيفًا أسرع من قبل المرسل لمكافحة هذه التغييرات.

تتضمن عيوب هذه الطريقة حقيقة مفادها أنه يجب توجيه جلسة TCP عبر المسرع؛ وهذا يعني أنه إذا تغير التوجيه بحيث لم يعد المسرع موجودًا في المسار، فسوف ينقطع الاتصال. كما أنها تدمر خاصية النهاية إلى النهاية لآلية إقرار TCP؛ فعندما يستقبل المرسل الإقرار، يتم تخزين الحزمة بواسطة المسرع، وليس تسليمها إلى المستقبل.

يمكن أن يكون برنامج مراقبة الحزم ، الذي يعترض حركة مرور TCP على رابط شبكة، مفيدًا في تصحيح أخطاء الشبكات ومجموعات الشبكات والتطبيقات التي تستخدم TCP من خلال إظهار الحزم التي تمر عبر رابط للمستخدم. تدعم بعض مجموعات الشبكات خيار مأخذ التوصيل SO_DEBUG، والذي يمكن تمكينه على المقبس باستخدام setsockopt. يقوم هذا الخيار بإلقاء جميع الحزم وحالات TCP والأحداث على هذا المقبس، وهو أمر مفيد في تصحيح الأخطاء. Netstat هي أداة مساعدة أخرى يمكن استخدامها لتصحيح الأخطاء.

بالنسبة للعديد من التطبيقات، لا يعد بروتوكول TCP مناسبًا. إحدى المشكلات (على الأقل مع التطبيقات العادية) هي أن التطبيق لا يستطيع الوصول إلى الحزم القادمة بعد الحزمة المفقودة حتى يتم استلام النسخة المعاد إرسالها من الحزمة المفقودة. يتسبب هذا في حدوث مشكلات للتطبيقات في الوقت الفعلي مثل الوسائط المتدفقة والألعاب متعددة اللاعبين في الوقت الفعلي والصوت عبر بروتوكول الإنترنت (VoIP) حيث يكون من المفيد بشكل عام الحصول على معظم البيانات في الوقت المناسب بدلاً من الحصول على جميع البيانات بالترتيب.

لأسباب تاريخية وأخرى تتعلق بالأداء، تستخدم معظم شبكات منطقة التخزين (SAN) بروتوكول قناة الألياف (FCP) عبر اتصالات قناة الألياف .

أيضًا، بالنسبة للأنظمة المضمنة ، والتمهيد عبر الشبكة ، والخوادم التي تخدم طلبات بسيطة من أعداد ضخمة من العملاء (مثل خوادم DNS )، يمكن أن تكون تعقيدات بروتوكول TCP مشكلة. أخيرًا، بعض الحيل مثل نقل البيانات بين مضيفين كلاهما خلف NAT (باستخدام STUN أو أنظمة مماثلة) تكون أبسط كثيرًا بدون بروتوكول معقد نسبيًا مثل TCP.

بشكل عام، عندما يكون بروتوكول TCP غير مناسب، يتم استخدام بروتوكول بيانات المستخدم (UDP). يوفر هذا البروتوكول الإرسال المتعدد للتطبيقات ومجموعات التحقق التي يوفرها بروتوكول TCP، ولكنه لا يتعامل مع التدفقات أو إعادة الإرسال، مما يمنح مطور التطبيق القدرة على ترميزها بطريقة مناسبة للموقف، أو استبدالها بأساليب أخرى مثل تصحيح الخطأ الأمامي أو الاستيفاء .

بروتوكول التحكم في نقل البيانات (SCTP) هو بروتوكول آخر يوفر خدمات موثوقة موجهة نحو التدفق تشبه بروتوكول TCP. وهو أحدث وأكثر تعقيدًا من بروتوكول TCP، ولم يتم نشره على نطاق واسع بعد. ومع ذلك، فهو مصمم خصيصًا للاستخدام في المواقف التي تكون فيها اعتبارات الموثوقية والوقت الحقيقي تقريبًا مهمة.

بروتوكول نقل فينتوري (VTP) هو بروتوكول خاص حاصل على براءة اختراع تم تصميمه ليحل محل بروتوكول TCP بشكل شفاف للتغلب على عدم الكفاءة الملحوظة المتعلقة بنقل البيانات لاسلكيًا.

يواجه بروتوكول TCP أيضًا مشكلات في البيئات ذات النطاق الترددي العالي. تعمل خوارزمية تجنب ازدحام بروتوكول TCP بشكل جيد للغاية في البيئات غير المخصصة حيث لا يكون مرسل البيانات معروفًا مسبقًا. إذا كانت البيئة متوقعة، فيمكن لبروتوكول قائم على التوقيت مثل وضع النقل غير المتزامن (ATM) تجنب تكلفة إعادة الإرسال لبروتوكول TCP.

يتمتع بروتوكول نقل البيانات (UDT) القائم على UDP بكفاءة وعدالة أفضل من TCP في الشبكات التي تحتوي على معدل تأخير النطاق الترددي العالي . ^[129]

بروتوكول المعاملات متعدد الأغراض (MTP/IP) عبارة عن برنامج خاص حاصل على براءة اختراع تم تصميمه لتحقيق إنتاجية عالية وأداء معاملات بشكل متكيف في مجموعة واسعة من ظروف الشبكة، وخاصة تلك التي يُنظر فيها إلى بروتوكول TCP على أنه غير فعال.

عندما يتم تشغيل TCP عبر IPv4 ، يتم تعريف الطريقة المستخدمة لحساب المجموع الاختباري على النحو التالي: ^[16]

حقل المجموع الاختباري هو المكمل المكون من 16 بتًا لمجموع المكمل المكون من 16 بتًا لجميع الكلمات المكونة من 16 بتًا في الرأس والنص. يجب أن تضمن عملية حساب المجموع الاختباري محاذاة البيانات التي يتم جمعها على هيئة 16 بتًا. إذا احتوى مقطع على عدد فردي من ثماني بتات الرأس والنص، فيمكن تحقيق المحاذاة عن طريق حشو الثماني بتات الأخيرة بأصفار على يمينها لتشكيل كلمة مكونة من 16 بتًا لأغراض المجموع الاختباري. لا يتم نقل الحشو كجزء من المقطع. أثناء حساب المجموع الاختباري، يتم استبدال حقل المجموع الاختباري نفسه بأصفار.

بعبارة أخرى، بعد الحشو المناسب، تتم إضافة جميع الكلمات المكونة من 16 بتًا باستخدام حساب المكمل الواحد . ثم يتم استكمال المجموع بتيًا وإدراجه كحقل المجموع الاختباري. يظهر في الجدول أدناه رأس وهمي يحاكي رأس حزمة IPv4 المستخدم في حساب المجموع الاختباري.

رأس TCP الزائف لحساب المجموع الاختباري (IPv4)

الإزاحة	ثماني بتات	0								1								2								3
ثماني بتات	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	عنوان المصدر
4	32	عنوان الوجهة
8	64	الأصفار								البروتوكول  (6)								طول TCP
12	96	منفذ المصدر																ميناء الوجهة
16	128	رقم التسلسل
20	160	رقم الإقرار
24	192	إزاحة البيانات				محجوز				الأعلام								نافذة
28	224	المجموع الاختباري																مؤشر عاجل
32	256	(خيارات)
36	288	بيانات
40	320
⋮	⋮

يتم حساب المجموع الاختباري عبر الحقول التالية:

عنوان المصدر: 32 بت

عنوان المصدر في رأس IPv4

عنوان الوجهة: 32 بت

عنوان الوجهة في رأس IPv4.

الأصفار: 8 بت؛ الأصفار == ​​0

كل الأصفار.

البروتوكول: 8 بت

قيمة البروتوكول لـ TCP: 6 .

طول TCP: 16 بت

طول رأس TCP والبيانات (مقاسة بالثمانيات). على سبيل المثال، لنفترض أن لدينا حزمة IPv4 بطول إجمالي يبلغ 200 بايت وقيمة IHL 5، مما يشير إلى طول 5 × 32 بت = 160 بت = 20 بايت. يمكننا حساب طول TCP على النحو التالي ، أي ، مما ينتج عنه بايتات.${\displaystyle {\text{Total Length}}-{\text{IPv4 Header Length}}}$${\displaystyle {\text{200}}-{\text{20}}}$${\displaystyle 180}$

عند تشغيل TCP عبر IPv6 ، تتغير الطريقة المستخدمة لحساب المجموع الاختباري: ^[130]

يجب تعديل أي بروتوكول نقل أو أي بروتوكول آخر من الطبقة العليا يتضمن العناوين من رأس IP في حساب المجموع الاختباري الخاص به للاستخدام عبر IPv6، ليشمل عناوين IPv6 ذات 128 بت بدلاً من عناوين IPv4 ذات 32 بت.

يظهر أدناه رأس وهمي يحاكي رأس IPv6 لحساب المبلغ الاختباري.

رأس TCP الزائف لحساب المجموع الاختباري (IPv6)

الإزاحة	ثماني بتات	0								1								2								3
ثماني بتات	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	عنوان المصدر
4	32
8	64
12	96
16	128	عنوان الوجهة
20	160
24	192
28	224
32	256	طول TCP
36	288	الأصفار																								العنوان التالي  (6)
40	320	منفذ المصدر																ميناء الوجهة
44	352	رقم التسلسل
48	384	رقم الإقرار
52	416	إزاحة البيانات				محجوز				الأعلام								نافذة
56	448	المجموع الاختباري																مؤشر عاجل
60	480	(خيارات)
64	512	بيانات
68	544
⋮	⋮

يتم حساب المجموع الاختباري عبر الحقول التالية:

عنوان المصدر: 128 بت

العنوان في رأس IPv6.

عنوان الوجهة: 128 بت

الوجهة النهائية؛ إذا كانت حزمة IPv6 لا تحتوي على رأس التوجيه، يستخدم TCP عنوان الوجهة في رأس IPv6، وإلا، في العقدة الأصلية، فإنه يستخدم العنوان الموجود في العنصر الأخير من رأس التوجيه، وفي العقدة المستقبلة، فإنه يستخدم عنوان الوجهة في رأس IPv6.

طول TCP: 32 بت

طول رأس TCP والبيانات (مقاسة بالثمانيات).

الأصفار: 24 بت؛ الأصفار == ​​0

كل الأصفار.

العنوان التالي: 8 بت

قيمة البروتوكول لـ TCP: 6 .

توفر العديد من تطبيقات حزمة برامج TCP/IP خيارات لاستخدام مساعدة الأجهزة لحساب المجموع الاختباري تلقائيًا في محول الشبكة قبل الإرسال إلى الشبكة أو عند الاستلام من الشبكة للتحقق من صحته. وقد يخفف هذا من عناء نظام التشغيل استخدام دورات وحدة المعالجة المركزية الثمينة لحساب المجموع الاختباري. وبالتالي، يتم تحسين الأداء العام للشبكة.

قد تتسبب هذه الميزة في قيام محللي الحزم الذين لا يدركون أو غير متأكدين من استخدام تفريغ المجموع الاختباري بالإبلاغ عن مجموعات اختبارية غير صالحة في الحزم الصادرة التي لم تصل بعد إلى محول الشبكة. ^[131] سيحدث هذا فقط للحزم التي تم اعتراضها قبل إرسالها بواسطة محول الشبكة؛ ستحتوي جميع الحزم المنقولة بواسطة محول الشبكة على السلك على مجموعات اختبارية صالحة. ^[132] يمكن أن تحدث هذه المشكلة أيضًا عند مراقبة الحزم التي يتم إرسالها بين الآلات الافتراضية على نفس المضيف، حيث قد يغفل برنامج تشغيل الجهاز الافتراضي حساب المجموع الاختباري (كتحسين)، مع العلم أن المجموع الاختباري سيتم حسابه لاحقًا بواسطة نواة مضيف الجهاز الافتراضي أو أجهزته المادية.

• سيرف، فينت ؛ دلال، يوجن ؛ صن شاين، كارل (ديسمبر 1974). مواصفات برنامج التحكم في نقل الإنترنت، إصدار ديسمبر 1974. doi : 10.17487/RFC0675 . RFC 675.
• بوستل ، جون (سبتمبر 1981). بروتوكول الإنترنت. دوى : 10.17487/RFC0791 . آر إف سي 791.
• بوستل، جون (سبتمبر 1981). بروتوكول التحكم في الإرسال. doi : 10.17487/RFC0793 . RFC 793.
• برادن، روبرت ، محرر (أكتوبر 1989). متطلبات مضيفات الإنترنت – طبقات الاتصال. doi : 10.17487/RFC1122 . RFC 1122.
• جاكوبسون، فان ؛ برادين، بوب ؛ بورمان، ديف (مايو 1992). ملحقات TCP للأداء العالي. doi : 10.17487/RFC1323 . RFC 1323.
• بيلوفين، ستيفن م. (مايو 1996). الدفاع ضد هجمات أرقام التسلسل. doi : 10.17487/RFC1948 . RFC 1948.
• ماثيس، مات؛ مهدوي، جمشيد؛ فلويد، سالي؛ رومانو، ألين (أكتوبر 1996). خيارات الإقرار الانتقائي لبروتوكول التحكم في الإرسال. doi : 10.17487/RFC2018 . RFC 2018.
• Allman, Mark; Paxson, Vern ; Stevens, W. Richard (أبريل 1999). التحكم في ازدحام TCP. doi : 10.17487/RFC2581 . RFC 2581.
• فلويد، سالي ؛ مهدوي، جمشيد؛ ماثيس، مات؛ بودولسكي، ماثيو (يوليو 2000). امتداد لخيار الإقرار الانتقائي (SACK) لـ TCP. doi : 10.17487/RFC2883 . RFC 2883.
• Ramakrishnan, KK; Floyd, Sally ; Black, David (سبتمبر 2001). إضافة إشعار الازدحام الصريح (ECN) إلى IP. doi : 10.17487/RFC3168 . RFC 3168.
• لودفيج، راينر؛ ماير، مايكل (أبريل 2003). خوارزمية اكتشاف إيفل لبروتوكول التحكم في الإرسال. doi : 10.17487/RFC3522 . RFC 3522.
• Spring, Neil; Weatherall, David; Ely, David (يونيو 2003). إشارات الإشعار الصريح القوي للازدحام (ECN) باستخدام الأرقام العشوائية. doi : 10.17487/RFC3540 . RFC 3540.
• Allman, Mark; Paxson, Vern ; Blanton, Ethan (سبتمبر 2009). التحكم في ازدحام TCP. doi : 10.17487/RFC5681 . RFC 5681.
• سيمبسون، ويليام ألين (يناير 2011). معاملات ملفات تعريف الارتباط TCP (TCPCT). doi : 10.17487/RFC6013 . RFC 6013.
• فورد، آلان؛ رايسيو، كوستين؛ هاندلي، مارك ؛ باري، سيباستيان؛ أيينجار، جاناردان (مارس 2011). المبادئ التوجيهية المعمارية لتطوير بروتوكول TCP متعدد المسارات. doi : 10.17487/RFC6182 . RFC 6182.
• Paxson, Vern ; Allman, Mark; Chu, HK Jerry; Sargent, Matt (يونيو 2011). حساب مؤقت إعادة الإرسال في بروتوكول التحكم في الإرسال. doi : 10.17487/RFC6298 . RFC 6298.
• فورد، آلان؛ رايسيو، كوستين؛ هاندلي، مارك ؛ بونافينتور، أوليفييه (يناير 2013). ملحقات TCP للعمليات متعددة المسارات مع عناوين متعددة. doi : 10.17487/RFC6824 . RFC 6824.
• ماثيس، مات؛ دوكيباتي، نانديتا؛ تشنغ، يوتشونج (مايو 2013). خفض المعدل النسبي لبروتوكول التحكم في الإرسال. doi : 10.17487/RFC6937 . RFC 6937.
• بورمان، ديفيد؛ برادين، بوب ؛ جاكوبسون، فان (سبتمبر 2014). شيفينيجر، ريتشارد (محرر). ملحقات TCP للأداء العالي. doi : 10.17487/RFC7323 . RFC 7323.
• دوق، مارتن؛ برادين، روبرت ؛ إيدي، ويسلي إم؛ بلانتون، إيثان؛ زيمرمان، ألكسندر (فبراير 2015). خارطة طريق لوثائق مواصفات بروتوكول التحكم في الإرسال (TCP). doi : 10.17487/RFC7414 . RFC 7414.
• تشنغ، يوتشونغ؛ تشو، جيري. راداكريشنان، سيفاسانكار؛ جاين ، آرفيند (ديسمبر 2014). فتح سريع لـ TCP. دوى : 10.17487/RFC7413 . آر إف سي 7413.
• Zimmermann, Alexander; Eddy, Wesley M.; Eggert, Lars (أبريل 2016). نقل ملحقات TCP القديمة والمستندات المتعلقة بـ TCP إلى حالة تاريخية أو إعلامية. doi : 10.17487/RFC7805 . RFC 7805.
• Fairhurst, Gorry; Trammell, Brian; Kuehlewind, Mirja, eds. (مارس 2017). الخدمات التي تقدمها بروتوكولات النقل وآليات التحكم في الازدحام التابعة لـ IETF. doi : 10.17487/RFC8095 . RFC 8095.
• تشنغ، يوتشونغ؛ كاردويل، نيل؛ دوكيباتي، نانديتا؛ جها، بريارانجان، محرران. (فبراير 2021). خوارزمية الكشف عن الخسارة RACK-TLP لـ TCP. دوى : 10.17487/RFC8985 . آر إف سي 8985.
• Deering, Stephen E .; Hinden, Robert M. (يوليو 2017). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). doi : 10.17487/RFC8200 . RFC 8200.
• تراميل، بريان؛ كوهليويند، ميرجا (أبريل 2019). الصورة السلكية لبروتوكول الشبكة. doi : 10.17487/RFC8546 . RFC 8546.
• هاردي، تيد، محرر (أبريل 2019). إشارات مسار بروتوكول النقل. doi : 10.17487/RFC8558 . RFC 8558.
• Iyengar, Jana; Swett, Ian, eds. (مايو 2021). اكتشاف الخسارة والتحكم في الازدحام في QUIC. doi : 10.17487/RFC9002 . RFC 9002.
• فيرهرست، جوري؛ بيركنز، كولين (يوليو 2021). اعتبارات حول سرية رأس النقل، وعمليات الشبكة، وتطور بروتوكولات نقل الإنترنت. doi : 10.17487/RFC9065 . RFC 9065.
• تومسون، مارتن؛ باولي، تومي (ديسمبر 2021). جدوى آليات تمديد البروتوكول على المدى الطويل. doi : 10.17487/RFC9170 . RFC 9170.
• إيدي، ويسلي م.، محرر (أغسطس 2022). بروتوكول التحكم في الإرسال (TCP). doi : 10.17487/RFC9293 . RFC 9293.

• Allman, Mark; Paxson, Vern (أكتوبر 1999). "حول تقدير خصائص مسار الشبكة من البداية إلى النهاية". ACM SIGCOMM Computer Communication Review . 29 (4): 263–274. doi : 10.1145/316194.316230 . hdl : 2060/20000004338 .
• بهات، ديفياشري؛ رزق، عمرو؛ زينك، مايكل (يونيو 2017). "ليس سريع الاستجابة: دراسة أداء DASH مقارنة بـ QUIC". NOSSDAV'17: وقائع ورشة العمل السابعة والعشرين حول دعم الشبكات وأنظمة التشغيل للصوت والفيديو الرقمي . ص 13-18. doi :10.1145/3083165.3083175. S2CID  32671949.
• بلانتون، إيثان؛ أولمان، مارك (يناير 2002). "حول جعل بروتوكول التحكم في الإرسال أكثر قوة في مواجهة إعادة ترتيب الحزم" (ملف PDF) . مجلة ACM SIGCOMM Computer Communication Review . 32 : 20–30. doi :10.1145/510726.510728. S2CID  15305731.
• بريسكوي، بوب؛ برونستروم، آنا؛ بيتلوند، أندرياس؛ هايز، ديفيد؛ روس، ديفيد؛ تسانج، إنج-جيه؛ جيسينج، شتاين؛ فيرهرست، جوري؛ جريودز، كارستن؛ ويلزل، مايكل (2016). "تقليل زمن انتقال الإنترنت: دراسة استقصائية للتقنيات ومزاياها". استطلاعات ودروس تعليمية حول الاتصالات في معهد مهندسي الكهرباء والإلكترونيات . 18 (3): 2149-2196. doi :10.1109/COMST.2014.2375213. hdl : 2164/8018 . S2CID  206576469.
• برويرون، رينو؛ هيمون، برونو؛ تشانج، ليكسا (أبريل 1998). "التجارب مع الإقرار الانتقائي لبروتوكول التحكم في الإرسال". مجلة مراجعة الاتصالات الحاسوبية ACM SIGCOMM . 28 (2): 54–77. doi :10.1145/279345.279350. S2CID  15954837.
• تشن شان. جيرو، صموئيل. جاجيلسكي، ماثيو؛ بولديريفا، ألكسندرا؛ نيتا روتارو، كريستينا (2021). “إنشاء قناة اتصال آمنة: TLS 1.3 (عبر TCP Fast Open) مقابل QUIC”. مجلة علم التشفير . 34 (3). دوى : 10.1007/s00145-021-09389-ث . S2CID  235174220.
• كوربيت، جوناثان (8 ديسمبر 2015). "تفريغ المجموع الاختباري وتصلب البروتوكول". LWN.net .
• كوربيت ، جوناثان (29 يناير 2018). “QUIC كحل لتعظم البروتوكول”. LWN.net .
• إيدلين، كوريان؛ دونيت، بينوا (2019). تحقيق من أسفل إلى أعلى في تصلب طبقة النقل . مؤتمر قياس وتحليل حركة الشبكة 2019 (TMA). doi :10.23919/TMA.2019.8784690.
• جيديني، أليساندرو (26 يوليو 2018). "الطريق إلى QUIC". Cloudflare .
• جورتوف، أندريه؛ فلويد، سالي (فبراير 2004). حل غموض الإقرار في بروتوكول TCP غير SACK (ملف PDF) . الجيل التالي من الاتصالات الهاتفية والشبكات المتقدمة السلكية/اللاسلكية (NEW2AN'04).
• جورتوف، أندريه؛ لودفيج، راينر (2003). الاستجابة لحالات انقطاع الاتصال الزائفة في بروتوكول التحكم في الإرسال (PDF) . IEEE INFOCOM 2003. المؤتمر السنوي المشترك الثاني والعشرون لجمعيات الحاسبات والاتصالات التابعة لمعهد مهندسي الكهرباء والإلكترونيات. doi :10.1109/INFCOM.2003.1209251.
• Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). هل ملحقات TCP محمية من Middlebox؟ . HotMiddlebox '13. CiteSeerX  10.1.1.679.6364 . doi :10.1145/2535828.2535830.
• مجموعة عمل HTTP التابعة لـ IETF. "الأسئلة الشائعة حول HTTP/2".
• كارن، فيل ؛ بارتريدج، كريج (نوفمبر 1991). "تحسين تقديرات وقت الرحلة ذهابًا وإيابًا في بروتوكولات النقل الموثوقة". معاملات ACM لأنظمة الكمبيوتر . 9 (4): 364-373. doi : 10.1145/118544.118549 .
• لودفيج، راينر؛ كاتز، راندي هوارد (يناير 2000). "خوارزمية إيفل: جعل بروتوكول التحكم في الإرسال قويًا ضد عمليات إعادة الإرسال الزائفة". مجلة مراجعة الاتصالات الحاسوبية ACM SIGCOMM . doi : 10.1145/505688.505692 .
• ماركس، روبن (3 ديسمبر 2020). "حظر رأس السطر في QUIC وHTTP/3: التفاصيل".
• Paasch, Christoph; Bonaventure, Olivier (1 أبريل 2014). "Multipath TCP". Communications of the ACM . 57 (4): 51–57. doi :10.1145/2578901. S2CID  17581886.
• باباستيرجيو، جيورجوس؛ فيرهرست، جوري؛ روس، ديفيد؛ برونستروم، آنا؛ جرينيمو، كارل يوهان؛ هورتيج، بير؛ خادمي، نعيم؛ توكسين، مايكل؛ ويلزل، مايكل؛ داميانوفيتش، دراجانا؛ مانجيانتي، سيمون (2017). "إزالة التحجر من طبقة نقل الإنترنت: دراسة استقصائية ووجهات نظر مستقبلية". دراسات استقصائية ودروس تعليمية من معهد مهندسي الكهرباء والإلكترونيات للاتصالات . 19 : 619–639. doi :10.1109/COMST.2016.2626780. hdl : 2164/8317 . S2CID  1846371.
• Rybczyńska, Marta (13 مارس 2020). "نظرة سريعة على HTTP/3". LWN.net .
• Sy, Erik; Mueller, Tobias; Burkert, Christian; Federrath, Hannes; Fischer, Mathias (2020). "تحسين الأداء والخصوصية لـ TLS عبر TCP Fast Open". وقائع تقنيات تحسين الخصوصية . 2020 (2): 271-287. arXiv : 1905.03518 . doi : 10.2478/popets-2020-0027 .
• Zhang, Lixia (5 أغسطس 1986). "لماذا لا تعمل مؤقتات TCP بشكل جيد". ACM SIGCOMM Computer Communication Review . 16 (3): 397–405. doi :10.1145/1013812.18216.

• ستيفنز، دبليو ريتشارد (10 يناير 1994). TCP/IP Illustrated، المجلد 1: البروتوكولات. شركة أديسون ويسلي للنشر، رقم ISBN 978-0-201-63346-7.
• ستيفنز، دبليو ريتشارد؛ رايت، جاري ر. (1994). TCP/IP Illustrated، المجلد 2: التنفيذ. أديسون ويسلي. ISBN 978-0-201-63354-2.
• ستيفنز، دبليو ريتشارد (1996). TCP/IP Illustrated، المجلد 3: TCP للمعاملات، HTTP، NNTP، وبروتوكولات UNIX Domain Protocols . Addison-Wesley. ISBN 978-0-201-63495-2.**

• مقابلة تاريخية شفوية مع روبرت إي كاهن
• مهام منفذ IANA
• معلمات IANA TCP
• نظرة عامة لجون كريستوف على TCP (المفاهيم الأساسية وراء TCP وكيفية استخدامه لنقل البيانات بين نقطتين نهائيتين)
• مثال على المجموع الاختباري