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

الموسوعة الحرة

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

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

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

الأصل التاريخي

في مايو 1974، وصف فينت سيرف وبوب كان بروتوكولًا للربط الشبكي لمشاركة الموارد باستخدام تبديل الحزم بين عُقد الشبكة. [ 3 ] كان المؤلفان يعملان مع جيرار لو لان لدمج مفاهيم من مشروع CYCLADES الفرنسي في الشبكة الجديدة. [ 4 ] كُتبت مواصفات البروتوكول الناتج، RFC 675 ( مواصفات برنامج التحكم في نقل الإنترنت )، بواسطة فينت سيرف ويوجين دلال وكارل سانشاين، ونُشرت في ديسمبر 1974. [ 5 ] وهي تتضمن أول استخدام موثق لمصطلح "الإنترنت" كاختصار لـ "الربط الشبكي" .

تضمن برنامج التحكم في الإرسال (TCP) روابط موجهة نحو الاتصال وخدمات حزم البيانات بين الأجهزة المضيفة. في الإصدار الرابع، قُسِّم برنامج التحكم في الإرسال المتكامل إلى بنية معيارية تتألف من بروتوكول التحكم في الإرسال وبروتوكول الإنترنت . [ 6 ] [ 7 ] نتج عن ذلك نموذج شبكي عُرف بشكل غير رسمي باسم TCP/IP ، على الرغم من أنه كان يُشار إليه رسميًا بأسماء مختلفة مثل نموذج بنية الإنترنت لوزارة الدفاع الأمريكية ( نموذج وزارة الدفاع الأمريكية اختصارًا) أو نموذج داربا . [ 8 ] [ 9 ] [ 10 ] لاحقًا، أصبح جزءًا من مجموعة بروتوكولات الإنترنت ومرادفًا لها . لا يزال بروتوكول التحكم في الإرسال يتطور، مع تحديثات تدريجية وأفضل الممارسات المُصاغة في وثائق طلب التعليقات (RFCs) مثل RFC 9293 (2022). [ 11 ]

تصف وثائق ملاحظات تجارب الإنترنت (IEN) التالية تطور بروتوكول TCP إلى الإصدار الحديث: [ 12 ]

  • IEN #5 مواصفات برنامج التحكم في نقل الإنترنت TCP الإصدار 2 (مارس 1977)
  • IEN #21 مواصفات برنامج التحكم في نقل الشبكة TCP الإصدار 3 (يناير 1978)
  • IEN #27 اقتراح لتنسيق رأس TCP الإصدار 3.1 (فبراير 1978)
  • مسودة بروتوكول التحكم في الإرسال رقم 40 (يونيو 1978)
  • IEN #44 أحدث تنسيقات رأس الصفحة (يونيو 1978)
  • IEN #55 مواصفات بروتوكول التحكم في نقل الشبكة الإصدار 4 (سبتمبر 1978)
  • بروتوكول التحكم في الإرسال رقم 81 الإصدار 4 (فبراير 1979)
  • بروتوكول التحكم في الإرسال رقم 112 الصادر عن IEN (أغسطس 1979)
  • بروتوكول التحكم القياسي في الإرسال IEN رقم 124 التابع لوزارة الدفاع (ديسمبر 1979)

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

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

وظيفة الشبكة

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

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

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

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

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

بنية مقطع TCP

يستقبل بروتوكول التحكم بالنقل البيانات من تدفق البيانات، ويقسمها إلى أجزاء، ويضيف إليها رأس TCP لتكوين مقطع TCP. ثم يُغلّف مقطع TCP في حزمة بيانات بروتوكول الإنترنت (IP)، ويتم تبادله مع النظراء. [ 16 ]

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

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

يتكون مقطع TCP من رأس المقطع وقسم البيانات . يحتوي رأس المقطع على 10 حقول إلزامية، وحقل امتداد اختياري ( خيارات ، الأجزاء من 20 إلى 56 في الجدول). يلي رأس المقطع قسم البيانات، وهو بيانات الحمولة التي يحملها التطبيق. [ 19 ] لا يُحدد طول قسم البيانات في رأس المقطع؛ ويمكن حسابه بطرح الطول الإجمالي لرأس المقطع ورأس IP من إجمالي طول حزمة بيانات IP المحدد في رأس IP.

تنسيق رأس TCP [ 19 ]
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00منفذ المصدرميناء الوجهة
432رقم التسلسل
864رقم الإقرار (ذي معنى عند ضبط بت الإقرار)
1296إزاحة البياناتمحجوزCWRهندسة الإلكترونيات والاتصالاتعاجلإقرارPSHRSTسينالنهايةنافذة
16128مجموع التحققمؤشر عاجل (ذو معنى عند تعيين بت URG) [ 20 ]
20160(خيارات) إذا كان موجودًا، فسيكون إزاحة البيانات أكبر من 5. يتم إضافة أصفار إلى مضاعفات 32 بت، لأن إزاحة البيانات تحسب الكلمات المكونة من 4 بايتات.
⋮⋮
56448
60480بيانات
64512
⋮⋮
منفذ المصدر : 16 بت
يحدد منفذ الإرسال.
منفذ الوجهة : 16 بت
يحدد منفذ الاستقبال.
رقم التسلسل : 32 بت
له دور مزدوج:
  • إذا تم ضبط علامة SYN (1)، فهذا هو رقم التسلسل الأولي. ويكون رقم تسلسل أول بايت بيانات فعلي ورقم الإقرار في رسالة ACK المقابلة هو رقم التسلسل هذا مضافًا إليه 1.
  • إذا لم يتم تعيين علامة SYN (0)، فهذا هو رقم التسلسل المتراكم لأول بايت بيانات من هذا الجزء للجلسة الحالية.
رقم الإقرار : 32 بت
إذا تم ضبط علامة ACK، فإن قيمة هذا الحقل هي رقم التسلسل التالي الذي يتوقعه مُرسِل ACK. وهذا يُؤكد استلام جميع البايتات السابقة (إن وُجدت). [ 21 ] يُؤكد أول ACK مُرسَل من كل طرف رقم التسلسل الأولي للطرف الآخر نفسه، ولكن دون أي بيانات. [ 22 ]
إزاحة البيانات  (DOffset) : 4 بتات
يُحدد هذا الحقل حجم رأس بروتوكول TCP بوحدات 32 بت . الحد الأدنى لحجم الرأس هو 5 كلمات، والحد الأقصى هو 15 كلمة، مما يُعطي حجمًا أدنى يبلغ 20 بايتًا وحدًا أقصى يبلغ 60 بايتًا، مع إمكانية إضافة خيارات تصل إلى 40 بايتًا في الرأس. سُمي هذا الحقل بهذا الاسم لأنه يُمثل أيضًا الإزاحة من بداية مقطع TCP إلى البيانات الفعلية.
محجوز  (Rsrvd) : 4 بتات
للاستخدام المستقبلي، ويجب ضبطها على الصفر؛ يجب على المرسلين عدم ضبطها، ويجب على المستلمين تجاهلها إذا تم ضبطها، في حالة عدم وجود مزيد من المواصفات والتنفيذ.
من عام 2003 إلى عام 2017، عُرّف البت الأخير (البت 103 من الترويسة) على أنه علامة NS (مجموع الأرقام العشوائية) في معيار RFC 3540 التجريبي ، ECN-nonce. لم ينتشر استخدام ECN-nonce على نطاق واسع، ونُقل معيار RFC إلى حالة تاريخية. [ 23 ]
يقترح مشروع RFC [ 24 ] استخدامًا جديدًا لهذه البتة. تُستخدم البتة الآن للتفاوض على استخدام Accurate ECN .
الأعلام : 8 بت
يحتوي على 8 علامات أحادية البت (بتات تحكم) كما يلي. عند استخدام tcpdump ، يتم الإشارة إلى العلامة المُفعّلة بالحرف الموجود بين قوسين.
CWR  (W) : 1 بت
يتم ضبط علامة تقليل نافذة الازدحام (CWR) بواسطة المضيف المُرسِل للإشارة إلى أنه استقبل مقطع TCP مع ضبط علامة ECE، وأنه استجاب وفقًا لآلية التحكم في الازدحام. [ 25 ] [ أ ]
ECE  (E) : 1 بت
يؤدي ECN-Echo دورًا مزدوجًا، اعتمادًا على قيمة علامة SYN. ​​فهو يشير إلى:
  • إذا تم ضبط علامة SYN (1)، فإن نظير TCP قادر على ECN . [ 26 ]
  • إذا لم يتم تعيين علامة SYN (0)، فهذا يعني أنه تم استلام حزمة بيانات تحتوي على علامة "ازدحام الشبكة" (ECN=11) في رأس بروتوكول الإنترنت (IP) أثناء الإرسال العادي. [ أ ] يشير هذا إلى ازدحام الشبكة (أو الازدحام الوشيك) لمرسل بروتوكول التحكم بالنقل (TCP). [ 27 ]
URG  (U) : 1 بت
يشير هذا إلى أن حقل مؤشر "عاجل" مهم.
ACK  (.) : 1 بت
يشير هذا إلى أهمية حقل الإقرار. يجب أن تحتوي جميع الحزم التي تلي حزمة SYN الأولية المرسلة من العميل على هذه العلامة. [ 28 ]
PSH  (P) : 1 بت
وظيفة الدفع. تطلب دفع البيانات المخزنة مؤقتًا على السلك (أي إرسالها) من طرف المرسل وإلى تطبيق الاستقبال من طرف المستقبل. [ 19 ]
RST  (R) : بت واحد
أعد ضبط الاتصال
SYN  (S) : 1 بت
مزامنة أرقام التسلسل. يجب أن تحتوي الحزمة الأولى المرسلة من كل طرف فقط على هذا الخيار. تتغير معاني بعض الخيارات والحقول الأخرى بناءً على هذا الخيار، وبعضها لا يكون صالحًا إلا عند تفعيله، والبعض الآخر عند تعطيله.
FIN  (F) : 1 بت
آخر حزمة بيانات من المرسل
نافذة : 16 بت
حجم نافذة الاستقبال ، الذي يحدد عدد وحدات حجم النافذة [ ب ] التي يرغب مرسل هذا الجزء في استقبالها حاليًا. [ ج ] (انظر §  التحكم في التدفق و §  توسيع النافذة .)
مجموع التحقق : 16 بت
يُستخدم حقل المجموع الاختباري ذو الـ 16 بت للتحقق من أخطاء رأس TCP، والحمولة، ورأس IP الزائف. يتكون الرأس الزائف من عنوان IP المصدر ، وعنوان IP الوجهة ، ورقم بروتوكول TCP (6)، وطول رؤوس TCP والحمولة (بالبايت).
مؤشر عاجل : 16 بت
إذا تم تعيين علامة URG، فإن هذا الحقل المكون من 16 بت يمثل إزاحة من رقم التسلسل الذي يشير إلى آخر بايت من البيانات العاجلة.
الخيارات  (خيار TCP) : طول متغير، يصل إلى 40 بايت (320 بت) ؛Options length (bytes) = (Data Offset − 5) × 4; equivalent bit formula per RFC 9293: (Data Offset − 5) × 32
يُحدد طول هذا الحقل بواسطة حقل إزاحة البيانات . تُستخدم حشوة رأس بروتوكول التحكم بالنقل (TCP) لضمان انتهاء رأس بروتوكول التحكم بالنقل وبدء البيانات عند حد 32 بت. تتكون الحشوة من أصفار. [ 18 ]
تحتوي الخيارات على ثلاثة حقول كحد أقصى: نوع الخيار (بايت واحد)، وطول الخيار (بايت واحد)، وبيانات الخيار (متغير). يشير حقل نوع الخيار إلى نوع الخيار، وهو الحقل الوحيد غير الاختياري. بناءً على قيمة نوع الخيار، يمكن تحديد الحقلين التاليين. يشير طول الخيار إلى الطول الإجمالي للخيار، بينما يحتوي حقل بيانات الخيار على البيانات المرتبطة بالخيار، إن وجدت. على سبيل المثال، يشير بايت نوع الخيار 1 إلى أن هذا خيار لا يُستخدم إلا لإضافة مساحة، ولا يتبعه حقلا طول الخيار أو بيانات الخيار. يشير بايت نوع الخيار 0 إلى نهاية الخيارات، وهو أيضًا بايت واحد. يُستخدم بايت نوع الخيار 2 للإشارة إلى خيار الحد الأقصى لحجم المقطع، وسيتبعه بايت طول الخيار الذي يحدد طول حقل الحد الأقصى لحجم المقطع. يمثل Option-Length الطول الإجمالي لحقل الخيارات المحدد، بما في ذلك حقلي Option-Kind وOption-Length. لذا، بينما تُعبّر قيمة MSS عادةً عن بايتين، فإن Option-Length سيكون 4 بايتات. على سبيل المثال، يُرمز لحقل خيارات MSS بقيمة 0x05B4 بالصيغة ( 0x02 0x04 0x05B4 ) في قسم خيارات TCP.
قد يتم إرسال بعض الخيارات فقط عند تعيين SYN؛ وهي موضحة أدناه على أنها [SYN]. يتم تحديد نوع الخيار والأطوال القياسية على النحو التالي (نوع الخيار، طول الخيار).
نوع الخيارطول الخياربيانات الخياراتغايةملحوظات
0غير متوفرغير متوفرنهاية قائمة الخيارات
1غير متوفرغير متوفرلا توجد عمليةيمكن استخدام هذا لمحاذاة حقول الخيارات على حدود 32 بت لتحسين الأداء.
24SSالحد الأقصى لحجم القطعةانظر إلى قسم "  الحد الأقصى لحجم القطعة" لمزيد من التفاصيل.[SYN]
33Sمقياس النافذةانظر قسم  تغيير حجم النافذة لمزيد من التفاصيل. [ 29 ][SYN]
42غير متوفريُسمح بالاعتراف الانتقائيانظر قسم "  الشكر والتقدير الانتقائي" للاطلاع على التفاصيل. [ 30 ][SYN]
5N (10، 18، 26، أو 34)BBBB، EEEE، ...الإقرار الانتقائي (SACK) [ 31 ]يتبع أول بايتين قائمة من 1-4 كتل يتم تأكيدها بشكل انتقائي، ويتم تحديدها كمؤشرات بداية/نهاية 32 بت.
810TTTT, EEEEالطابع الزمني وصدى الطابع الزمني السابقانظر قسم  الطوابع الزمنية لبروتوكول TCP لمزيد من التفاصيل. [ 29 ]
284غير متوفرخيار مهلة المستخدمانظر RFC 5482 . 
29شمالغير متوفرخيار مصادقة TCP (TCP-AO)لأغراض مصادقة الرسائل، يتم استبدال مصادقة MD5 (الخيار 19) المصممة أصلاً لحماية جلسات BGP . [ 32 ] انظر RFC 5925 . 
30شمالغير متوفربروتوكول TCP متعدد المسارات (MPTCP)راجع بروتوكول TCP متعدد المسارات لمزيد من التفاصيل.
أما قيم Option-Kind المتبقية فهي تاريخية، أو قديمة، أو تجريبية، أو غير موحدة بعد، أو غير مخصصة. وتتولى هيئة أرقام الإنترنت المخصصة (IANA) مسؤولية تخصيص أرقام الخيارات. [ 33 ]
البيانات : متغير
حمولة حزمة TCP

تشغيل البروتوكول

مخطط حالة TCP مبسط

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

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

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

إنشاءات الاتصال

إنشاءات الاتصال

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

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

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

إنهاء الاتصال

إنهاء الاتصال
مخطط تفصيلي لتسلسل إغلاق TCP

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

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

تُطبّق بعض أنظمة التشغيل، مثل لينكس [ 37 ] ، تسلسل إغلاق نصف مزدوج. إذا أغلق المضيف اتصالاً بشكلٍ فعلي، مع وجود بيانات واردة غير مقروءة، فإنه يُرسل إشارة RST (مع فقدان أي بيانات مُستلمة) بدلاً من FIN. وهذا يضمن أن يكون تطبيق TCP على دراية بفقدان البيانات . [ 38 ]

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

استخدام الموارد

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

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

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

نقل البيانات

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

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

ناقل حركة موثوق

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

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

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

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

إعادة الإرسال بناءً على تأكيد الاستلام المكرر

إذا فُقد جزء واحد (مثلاً الجزء رقم 100) من تدفق البيانات، فلن يتمكن المُستقبِل من تأكيد استلام الحزم التي تلي هذا الجزء (100) لأنه يستخدم تأكيدات الاستلام التراكمية. لذا، يُؤكد المُستقبِل استلام الحزمة رقم 99 مرة أخرى عند استلام حزمة بيانات أخرى. يُستخدم هذا التأكيد المُكرر كإشارة لفقدان الحزمة. أي، إذا استلم المُرسِل ثلاثة تأكيدات مُكررة، فإنه يُعيد إرسال آخر حزمة لم يتم تأكيد استلامها. يُستخدم حدٌّ أقصى قدره ثلاثة تأكيدات لأن الشبكة قد تُعيد ترتيب الأجزاء مما يُؤدي إلى تأكيدات مُكررة. وقد ثبت أن هذا الحد يُجنّب عمليات إعادة الإرسال غير المقصودة الناتجة عن إعادة الترتيب. [ 43 ] تستخدم بعض تطبيقات بروتوكول التحكم بالنقل (TCP ) تأكيدات الاستلام الانتقائية (SACKs) لتوفير معلومات واضحة حول الأجزاء التي تم استلامها. يُحسّن هذا بشكل كبير قدرة بروتوكول التحكم بالنقل على إعادة إرسال الأجزاء الصحيحة.

قد يؤدي غموض إعادة الإرسال إلى عمليات إعادة إرسال سريعة زائفة وتجنب الازدحام إذا تجاوزت إعادة ترتيب الحزم عتبة الإقرار المكرر. [ 44 ] في العقدين الماضيين، لوحظ ازدياد في إعادة ترتيب الحزم عبر الإنترنت [ 45 ] ، مما دفع تطبيقات بروتوكول TCP، مثل تلك الموجودة في نواة لينكس، إلى تبني أساليب استدلالية لتوسيع نطاق عتبة الإقرار المكرر. [ 46 ] مؤخرًا، بُذلت جهود للتخلص نهائيًا من عمليات إعادة الإرسال السريعة القائمة على الإقرار المكرر واستبدالها بعمليات إعادة إرسال تعتمد على المؤقت. [ 47 ] (لا ينبغي الخلط بينها وبين RTO الكلاسيكي المذكور أدناه). تم اعتماد خوارزمية كشف الفقد القائمة على الوقت، والتي تُسمى الإقرار الأخير (RACK) [ 48 ] ، كخوارزمية افتراضية في لينكس وويندوز. [ 49 ]

إعادة الإرسال بناءً على مهلة زمنية

عندما يُرسل المُرسِل جزءًا من البيانات، فإنه يُهيئ مؤقتًا بتقدير مُتحفظ لوقت وصول إشعار الاستلام. يُعاد إرسال الجزء إذا انتهت صلاحية المؤقت، مع عتبة مهلة جديدة تُساوي ضعف القيمة السابقة، مما يُؤدي إلى سلوك تراجع أُسّي . عادةً، تكون قيمة المؤقت الأولية هي RTT المُنعّم + max( G , 4 × تباين RTT) ، حيث G هي دقة الساعة. [ 50 ] يحمي هذا من حركة مرور الإرسال الزائدة الناتجة عن جهات فاعلة مُختلة أو خبيثة، مثل مُهاجمي هجمات حجب الخدمة من نوع "الرجل في المنتصف" .

تُعدّ تقديرات زمن الاستجابة (RTT) الدقيقة مهمة لاستعادة الحزم المفقودة، إذ تسمح للمرسل بافتراض فقدان الحزمة غير المُستلمة بعد مرور وقت كافٍ (أي تحديد زمن إعادة الإرسال). [ 51 ] قد يؤدي غموض إعادة الإرسال إلى عدم دقة تقدير المرسل لزمن الاستجابة. [ 51 ] في بيئة ذات أزمنة استجابة متغيرة، قد تحدث مهلات زائفة: [ 52 ] إذا تم التقليل من تقدير زمن الاستجابة، فسيتم تفعيل مهلة إعادة الإرسال، مما يؤدي إلى إعادة إرسال غير ضرورية وبدء تشغيل بطيء. بعد إعادة الإرسال الزائفة، عندما تصل إشعارات الاستلام للإرسالات الأصلية، قد يعتقد المرسل أنها تُقرّ بإعادة الإرسال، ويستنتج، بشكل خاطئ، أن الأجزاء المرسلة بين الإرسال الأصلي وإعادة الإرسال قد فُقدت، مما يتسبب في المزيد من عمليات إعادة الإرسال غير الضرورية إلى الحد الذي يصبح فيه الرابط مزدحمًا بالفعل؛ [ 53 ] [ 54 ] يمكن أن يقلل الإقرار الانتقائي من هذا التأثير. [ 55 ] تنصّ RFC 6298 على أنه لا يجوز للتطبيقات استخدام المقاطع المُعاد إرسالها عند تقدير زمن الاستجابة (RTT). [ 56 ] تضمن خوارزمية كارن الحصول على تقدير جيد لزمن الاستجابة (RTT) في نهاية المطاف ، وذلك بالانتظار حتى ورود إشعار استلام واضح قبل تعديل وقت إعادة الإرسال المستهدف (RTO). [ 57 ] مع ذلك، بعد عمليات إعادة الإرسال غير المقصودة، قد يستغرق الأمر وقتًا طويلاً قبل وصول إشعار الاستلام الواضح هذا، مما يؤدي إلى تدهور الأداء خلال هذه الفترة. [ 58 ] كما تعمل الطوابع الزمنية لبروتوكول TCP على حل مشكلة غموض إعادة الإرسال عند تحديد وقت إعادة الإرسال المستهدف (RTO)، [ 56 ] على الرغم من أنها لا تُحسّن بالضرورة تقدير زمن الاستجابة (RTT). [ 59 ]

اكتشاف الأخطاء

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

لضمان صحة البيانات، يُضاف حقل مجموع التحقق؛ راجع قسم  حساب مجموع التحقق لمزيد من التفاصيل. يُعدّ مجموع التحقق الخاص ببروتوكول TCP فحصًا ضعيفًا وفقًا للمعايير الحديثة، وعادةً ما يُستخدم مع فحص سلامة CRC في الطبقة الثانية ، أسفل كلٍّ من TCP وIP، كما هو الحال في بروتوكول PPP أو إطار الإيثرنت . مع ذلك، يُعدّ إدخال أخطاء في الحزم بين القفزات المحمية بواسطة CRC أمرًا شائعًا، ويكشف مجموع التحقق الخاص ببروتوكول TCP ذو 16 بت معظم هذه الأخطاء. [ 60 ]

التحكم في التدفق

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

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

تتصرف أرقام تسلسل TCP ونوافذ الاستقبال بشكل مشابه للساعة. تتغير نافذة الاستقبال في كل مرة يستقبل فيها المُستقبِل جزءًا جديدًا من البيانات ويؤكد استلامه. وبمجرد نفاد أرقام التسلسل، يعود رقم التسلسل إلى الصفر.

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

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

التحكم في الازدحام

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

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

تحتوي التطبيقات الحديثة لبروتوكول TCP على أربع خوارزميات مترابطة: بدء التشغيل البطيء ، وتجنب الازدحام ، وإعادة الإرسال السريع ، والاسترداد السريع . [ 61 ]

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

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

الحد الأقصى لحجم القطعة

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

قد يُطلق على إعلان حجم القطعة القصوى (MSS) أيضًا اسم تفاوض حجم القطعة القصوى، ولكن بالمعنى الدقيق، لا يتم التفاوض على حجم القطعة القصوى . يُسمح بقيمتين مستقلتين تمامًا لحجم القطعة القصوى لاتجاهي تدفق البيانات في اتصال TCP، [ 63 ] [ 18 ] لذا لا حاجة للاتفاق على تكوين مشترك لحجم القطعة القصوى لاتصال ثنائي الاتجاه.

شكر وتقدير انتقائي

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

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

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

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

يمكن "التراجع" عن الإقرارات الانتقائية، حيث يتجاهل المُستقبِل البيانات التي تم تأكيدها بشكل انتقائي من جانب واحد. وقد ثبطت RFC 2018 هذا السلوك، لكنها لم تمنعه، بل منحت المُستقبِلين خيار التراجع إذا نفدت مساحة التخزين المؤقت لديهم، على سبيل المثال. [ 64 ] وتؤدي إمكانية التراجع إلى تعقيد التنفيذ لكل من المُرسِلين والمُستقبِلين، كما تفرض تكاليف ذاكرة على المُرسِل. [ 65 ]

تغيير حجم النافذة

لتحسين استخدام الشبكات ذات النطاق الترددي العالي، يمكن استخدام حجم نافذة TCP أكبر. يتحكم حقل حجم نافذة TCP ذو 16 بت في تدفق البيانات، وقيمته محدودة بـ 65,535 بايت. ولأن حقل الحجم لا يمكن توسيعه إلى ما بعد هذا الحد، يُستخدم عامل قياس. يُعد خيار قياس نافذة TCP ، كما هو مُعرّف في RFC 1323 ، خيارًا يُستخدم لزيادة الحد الأقصى لحجم النافذة إلى 1 جيجابايت. يُعد التوسع إلى هذه الأحجام الأكبر للنافذة ضروريًا لضبط TCP .

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

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

الطوابع الزمنية لبروتوكول TCP

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

يوجد حقلان للطابع الزمني:

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

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

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

يتم تمكين الطوابع الزمنية لبروتوكول TCP بشكل افتراضي في نظام Linux، [ 68 ] ويتم تعطيلها بشكل افتراضي في Windows Server 2008 و2012 و2016. [ 69 ]

تشير الإحصائيات الحديثة إلى أن مستوى اعتماد الطابع الزمني لبروتوكول TCP قد استقر عند حوالي 40٪، وذلك بسبب توقف دعم Windows Server منذ Windows Server 2008. [ 70 ]

بيانات خارج النطاق

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

لا يُؤثر مؤشر الحالة العاجلة إلا على معالجة البيانات على المضيف البعيد، ولا يُسرّع أي معالجة على الشبكة نفسها. تختلف طريقة تنفيذ هذه الخاصية أو تكون غير فعّالة على الأنظمة المختلفة، أو قد لا تكون مدعومة أصلاً. وعند توفرها، يُنصح بافتراض أن بايتات البيانات خارج النطاق (OOB) ستُعالج بشكل موثوق. [ 71 ] [ 72 ] ونظرًا لقلة استخدام هذه الخاصية، فإنها لم تُختبر جيدًا على بعض المنصات، وقد رُبطت بثغرات أمنية ، مثل برنامج WinNuke .

إجبار تسليم البيانات

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

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

يُعرّف RFC 793PSH بت الدفع بأنه "رسالة إلى حزمة بروتوكول TCP المُستقبِلة لإرسال هذه البيانات فورًا إلى التطبيق المُستقبِل". [ 15 ] لا توجد طريقة للإشارة إليه أو التحكم فيه في مساحة المستخدم باستخدام مقابس بيركلي ؛ إذ يتم التحكم فيه بواسطة حزمة البروتوكول فقط. [ 73 ]

نقاط الضعف

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

رفض الخدمة

باستخدام عنوان IP مزيف وإرسال حزم SYN مُجمّعة عمدًا بشكل متكرر ، متبوعةً بالعديد من حزم ACK، يستطيع المهاجمون إجبار الخادم على استهلاك كميات كبيرة من الموارد لتتبع الاتصالات الوهمية. يُعرف هذا بهجوم فيضان SYN . ​​تشمل الحلول المقترحة لهذه المشكلة ملفات تعريف ارتباط SYN وألغاز التشفير، مع العلم أن ملفات تعريف ارتباط SYN تنطوي على ثغرات أمنية خاصة بها. [ 76 ] يُعدّ هجوم Sockstress هجومًا مشابهًا، ويمكن التخفيف من حدّته من خلال إدارة موارد النظام . [ 77 ] تم تحليل هجوم DoS متقدم يتضمن استغلال مؤقت استمرار TCP في Phrack رقم 66. [ 78 ] تُعدّ هجمات فيضان PUSH وACK من الأنواع الأخرى. [ 79 ]

اختطاف الاتصال

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

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

حق النقض TCP

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

منافذ TCP

يُعرَّف اتصال TCP برباعية تتكون من عنوان المصدر، ومنفذ المصدر ، وعنوان الوجهة، ومنفذ الوجهة. [ د ] [ 82 ] [ 83 ] تُستخدم أرقام المنافذ لتمييز الخدمات المختلفة، وللسماح باتصالات متعددة بين الأجهزة المضيفة. [ 16 ] يستخدم TCP أرقام منافذ 16 بت ، مما يوفر 65,536 قيمة ممكنة لكل من منفذي المصدر والوجهة. [ 19 ] يعني اعتماد هوية الاتصال على العناوين أن اتصالات TCP مرتبطة بمسار شبكة واحد؛ لا يمكن لـ TCP استخدام المسارات الأخرى المتاحة للأجهزة المضيفة متعددة المنافذ ، وتنقطع الاتصالات إذا تغير عنوان نقطة النهاية. [ 84 ]

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

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

تطوير

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

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

يُعدّ بروتوكول TCP متعدد المسارات (MPTCP) [ 85 ] [ 86 ] جهدًا مستمرًا ضمن فريق عمل هندسة الإنترنت (IETF) يهدف إلى تمكين اتصال TCP من استخدام مسارات متعددة لتحقيق أقصى استفادة من الموارد وزيادة التكرار. يُمكّن التكرار الذي يوفره بروتوكول TCP متعدد المسارات في سياق الشبكات اللاسلكية من الاستخدام المتزامن لشبكات مختلفة، مما يُحسّن الإنتاجية وقدرات التسليم. كما يُحسّن بروتوكول TCP متعدد المسارات الأداء في بيئات مراكز البيانات. [ 87 ] طُوّر التطبيق المرجعي [88] لبروتوكول TCP متعدد المسارات في نواة لينكس. [ 89 ] يُستخدم بروتوكول TCP متعدد المسارات لدعم تطبيق التعرف على الصوت Siri على أجهزة iPhone وiPad وMac. [ 90 ]

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

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

تم اقتراح تقنية تقليل معدل النقل النسبي (PRR) في مايو 2013، وهي امتداد لبروتوكول TCP طوّره مهندسو جوجل. تضمن هذه التقنية أن يكون حجم نافذة TCP بعد الاستعادة أقرب ما يمكن إلى عتبة بدء التشغيل البطيء . [ 94 ] صُممت هذه الخوارزمية لتحسين سرعة الاستعادة، وهي خوارزمية التحكم في الازدحام الافتراضية في نواة لينكس 3.2 والإصدارات الأحدث. [ 95 ]

المقترحات المهملة

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

تطبيقات الأجهزة

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

لقد ثبت أن بروتوكول TCP منخفض الطاقة ( TCPlp ) يعمل في بيئات محدودة الموارد حيث يُفضل استخدام بروتوكول CoAP القائم على UDP. [ 98 ] [ 99 ]

صورة سلكية وتعظم

توفر بيانات بروتوكول TCP فرصًا كبيرة لجمع المعلومات وتعديلها للمراقبين على طول المسار، نظرًا لأن بيانات البروتوكول الوصفية تُرسل كنص عادي . [ 100 ] [ 101 ] في حين أن هذه الشفافية مفيدة لمشغلي الشبكات [ 102 ] والباحثين، [ 103 ] إلا أن المعلومات المُجمعة من بيانات البروتوكول الوصفية قد تُقلل من خصوصية المستخدم النهائي. [ 104 ] وقد أدى هذا الوضوح وقابلية تعديل البيانات الوصفية إلى صعوبة توسيع بروتوكول TCP - وهو ما يُعرف بتصلب البروتوكول - حيث يمكن لأي عقدة وسيطة ( جهاز وسيط ) اتخاذ قرارات بناءً على تلك البيانات الوصفية أو حتى تعديلها، [ 105 ] [ 106 ] مما يُخل بمبدأ الاتصال من طرف إلى طرف . [ 107 ] وقد وجدت إحدى الدراسات أن ثلث المسارات عبر الإنترنت تواجه وسيطًا واحدًا على الأقل يُعدّل بيانات TCP الوصفية، وأن 6.5% من المسارات تواجه آثارًا ضارة لتصلب البروتوكول من قِبل الوسطاء. [ 108 ] فرض تجنب مخاطر قابلية التوسع الناتجة عن الوسطاء قيودًا كبيرة على تصميم بروتوكول MPTCP ، [ 109 ] [ 110 ] وقد أعاقت الصعوبات الناجمة عن الوسطاء نشر بروتوكول TCP Fast Open في متصفحات الويب . [ 111 ] ومن مصادر التصلب الأخرى صعوبة تعديل وظائف TCP عند نقاط النهاية، عادةً في نواة نظام التشغيل [ 112 ] أو في الأجهزة المزودة بمحرك تفريغ TCP . [ 113 ]

أداء

بما أن بروتوكول TCP يوفر للتطبيقات تجريدًا لتدفق بايتات موثوق ، فإنه قد يعاني من مشكلة حجب رأس السطر : فإذا أُعيد ترتيب الحزم أو فُقدت واحتاجت إلى إعادة إرسال (وبالتالي أُعيد ترتيبها)، فقد تُستقبل البيانات من الأجزاء اللاحقة من التدفق قبل الأجزاء السابقة؛ ومع ذلك، لا يمكن عادةً استخدام البيانات اللاحقة حتى تُستقبل البيانات السابقة، مما يُسبب تأخيرًا في الشبكة . إذا تم تغليف عدة رسائل مستقلة عالية المستوى ودمجها في اتصال TCP واحد، فقد يتسبب حجب رأس السطر في انتظار معالجة رسالة مستلمة بالكامل أُرسلت لاحقًا لتسليم رسالة أُرسلت سابقًا. [ 114 ] تحاول متصفحات الويب التخفيف من مشكلة حجب رأس السطر عن طريق فتح اتصالات متوازية متعددة. وهذا يُكبّد تكلفة إنشاء الاتصال بشكل متكرر، بالإضافة إلى مضاعفة الموارد اللازمة لتتبع هذه الاتصالات عند نقاط النهاية. [ 115 ] تتميز الاتصالات المتوازية أيضًا بآليات تحكم في الازدحام تعمل بشكل مستقل عن بعضها البعض، بدلاً من تجميع المعلومات والاستجابة بشكل أسرع لظروف الشبكة المرصودة؛ [ 116 ] يمكن أن تتسبب أنماط الإرسال الأولية العدوانية لبروتوكول TCP في حدوث ازدحام إذا تم فتح اتصالات متوازية متعددة؛ ويؤدي نموذج الإنصاف لكل اتصال إلى احتكار الموارد من قبل التطبيقات التي تتبع هذا النهج. [ 117 ]

يُعدّ إنشاء الاتصال عاملاً رئيسياً في زمن الاستجابة الذي يلاحظه مستخدمو الإنترنت. [ 118 ] [ 119 ] تُضيف عملية المصافحة الثلاثية لبروتوكول TCP زمن استجابة قدره RTT واحد أثناء إنشاء الاتصال قبل إرسال البيانات. [ 119 ] بالنسبة للتدفقات القصيرة، تكون هذه التأخيرات كبيرة جدًا. [ 120 ] يتطلب بروتوكول أمان طبقة النقل (TLS) مصافحة خاصة به لتبادل المفاتيح عند إنشاء الاتصال. وبسبب التصميم الطبقي، تتم مصافحة TCP ومصافحة TLS بالتتابع؛ ولا يمكن أن تبدأ مصافحة TLS إلا بعد انتهاء مصافحة TCP. [ 121 ] يتطلب إنشاء الاتصال باستخدام TLS 1.2 عبر TCP زمنَي RTT. [ 122 ] يسمح TLS 1.3 باستئناف الاتصال بدون زمن استجابة في بعض الحالات، ولكن عند استخدامه فوق TCP، يظل زمن استجابة واحد RTT مطلوبًا لمصافحة TCP، وهذا لا يُساعد في إنشاء الاتصال الأولي. تُشكّل المصافحات ذات زمن الاستجابة الصفري (ROT) تحديات تشفيرية، إذ يُعدّ تبادل المفاتيح غير التفاعلي بكفاءة وأمان ضد إعادة الإرسال وآمنًا للتمرير موضوعًا بحثيًا مفتوحًا. [ 123 ] يسمح بروتوكول TCP Fast Open بنقل البيانات في الحزم الأولية (أي SYN وSYN-ACK)، مما يُزيل زمن استجابة RTT واحدًا أثناء إنشاء الاتصال. [ 124 ] مع ذلك، كان نشر بروتوكول TCP Fast Open صعبًا بسبب جمود البروتوكول؛ اعتبارًا من عام 2020لم تستخدم أي متصفحات ويب هذه الميزة بشكل افتراضي. [ 111 ]

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

يمكن أن يُحسّن الإقرار الانتقائي معدل نقل البيانات بشكل ملحوظ؛ فقد قاس برويرون وهيمون وتشانغ (1998) مكاسب تصل إلى 45%. [ 129 ] ومن العوامل المهمة في هذا التحسين أن الإقرار الانتقائي يُجنّب في أغلب الأحيان الدخول في مرحلة بدء التشغيل البطيء بعد فقدان البيانات، وبالتالي يُحسّن استخدام النطاق الترددي المتاح. [ 130 ] مع ذلك، لا يستطيع بروتوكول TCP الإقرار الانتقائي إلا لثلاث مجموعات كحد أقصى من أرقام التسلسل. وهذا قد يُحدّ من معدل إعادة الإرسال، وبالتالي استعادة البيانات المفقودة، أو يُسبّب عمليات إعادة إرسال غير ضرورية، خاصةً في البيئات ذات معدلات فقدان البيانات العالية. [ 131 ] [ 132 ]

صُمم بروتوكول TCP في الأصل للشبكات السلكية، حيث يُعتبر فقدان الحزم ناتجًا عن ازدحام الشبكة ، ويتم تقليص حجم نافذة الازدحام بشكل كبير كإجراء احترازي. مع ذلك، من المعروف أن الروابط اللاسلكية تعاني من فقدان متقطع ومؤقت عادةً بسبب التلاشي ، والتظليل، والتسليم، والتداخل ، وغيرها من التأثيرات اللاسلكية، والتي لا تُعد ازدحامًا بالمعنى الدقيق. بعد التراجع (الخاطئ) لحجم نافذة الازدحام، نتيجةً لفقدان الحزم اللاسلكية، قد تحدث مرحلة لتجنب الازدحام مع انخفاض تدريجي في حجم النافذة. يؤدي هذا إلى عدم استغلال الرابط اللاسلكي بالشكل الأمثل. وقد أُجريت أبحاث مكثفة لمكافحة هذه الآثار الضارة. يمكن تصنيف الحلول المقترحة إلى حلول شاملة، تتطلب تعديلات على مستوى العميل أو الخادم، [ 133 ] وحلول طبقة الربط، مثل بروتوكول الربط اللاسلكي في الشبكات الخلوية، أو حلول قائمة على الوكيل تتطلب بعض التغييرات في الشبكة دون تعديل العقد الطرفية. [ 133 ] [ 134 ] تم اقتراح عدد من خوارزميات التحكم في الازدحام البديلة، مثل Vegas و Westwood و Veno و Santa Cruz، للمساعدة في حل مشكلة الاتصالات اللاسلكية.

تسريع

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

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

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

تصحيح الأخطاء

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

البدائل

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

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

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

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

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

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

صُمم بروتوكول نقل البيانات القائم على UDP (UDT) لبيئات الشبكات ذات النطاق الترددي العالي وزمن الاستجابة العالي، وخاصةً لنقل البيانات على نطاق واسع مثل بث الملفات أو الوسائط. في الشبكات ذات حاصل ضرب النطاق الترددي في زمن الاستجابة العالي ، [ 136 ] يوفر UDT مزايا على TCP، إذ يُحسّن الكفاءة والعدالة.

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

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

مجموع التحقق TCP لـ IPv4

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

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

بمعنى آخر، بعد إضافة الحشو المناسب، تُجمع جميع الكلمات ذات الـ 16 بت باستخدام حساب المتمم الأحادي . ثم يُعكس المجموع بتيًا ويُدرج كحقل التحقق. وفيما يلي رأس زائف يُحاكي رأس حزمة IPv4 المستخدم في حساب التحقق:

رأس TCP الزائف لحساب المجموع الاختباري (IPv4)
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00عنوان المصدر
432عنوان الوجهة
864أصفارالبروتوكول  (6) الاسمطول TCP
1296منفذ المصدرميناء الوجهة
16128رقم التسلسل
20160رقم الإقرار
24192إزاحة البياناتمحجوزالأعلامنافذة
28224مجموع التحققمؤشر عاجل
32256(خيارات)
36288بيانات
40320
⋮⋮

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

عنوان المصدر : 32 بت
عنوان المصدر في رأس IPv4
عنوان الوجهة : 32 بت
عنوان الوجهة في رأس IPv4
الأصفار : 8 بتات
جميعها أصفار
البروتوكول : 8 بت
قيمة البروتوكول لـ TCP:6
طول TCP : 16 بت
طول رأس TCP والبيانات (يُقاس بالبايتات). على سبيل المثال، لنفترض أن لدينا حزمة IPv4 بطول إجمالي قدره200  بايت وقيمة IHL تساوي 5، مما يشير إلى طول5  بت × 32  بت =160  بت =٢٠  بايت . يمكننا حساب طول TCP كالتالي: (الطول الإجمالي) - (طول رأس IPv4)، أي ٢٠٠ - ٢٠ ، مما ينتج عنه180  بايت .

مجموع التحقق TCP لـ IPv6

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

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

يظهر أدناه رأس زائف يحاكي رأس IPv6 لحساب المجموع الاختباري.

رأس TCP الزائف لحساب المجموع الاختباري (IPv6)
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00عنوان المصدر
432
864
1296
16128عنوان الوجهة
20160
24192
28224
32256طول TCP
36288أصفارالعنوان التالي  (6)
40320منفذ المصدرميناء الوجهة
44352رقم التسلسل
48384رقم الإقرار
52416إزاحة البياناتمحجوزالأعلامنافذة
56448مجموع التحققمؤشر عاجل
60480(خيارات)
64512بيانات
68544
⋮⋮

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

عنوان المصدر : 128 بت
العنوان الموجود في رأس IPv6.
عنوان الوجهة : 128 بت
الوجهة النهائية؛ إذا لم تحتوي حزمة IPv6 على رأس توجيه، فإن TCP يستخدم عنوان الوجهة في رأس IPv6، وإلا، فإنه يستخدم العنوان الموجود في العنصر الأخير من رأس التوجيه عند العقدة الأصلية، ويستخدم عنوان الوجهة الموجود في رأس IPv6 عند العقدة المستقبلة.
طول TCP : 32 بت
طول رأس TCP والبيانات (مقاسًا بالوحدات الثمانية).
الأصفار : 24 بت ؛Zeroes == 0
جميعها أصفار.
العنوان التالي : 8 بت
قيمة البروتوكول لـ TCP:6 .

تفريغ مجموع التحقق

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

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

انظر أيضاً

ملحوظات

  1. تمت إضافته إلى رأس الصفحة بواسطة RFC 3168
  2. ↑ وحدات حجم نظام التشغيل ويندوز هي، بشكل افتراضي، بايت.
  3. ↑ حجم النافذة نسبي للجزء المحدد بواسطة رقم التسلسل في حقل الإقرار.
  4. ↑ وبالمثل، زوج من منافذ الشبكة للمصدر والوجهة، يتكون كل منهما من عنوان ومنفذ
  5. ↑ اعتبارًا من أحدث معيار، HTTP/3 ، يتم استخدام QUIC كوسيلة نقل بدلاً من TCP.

مراجع

  1. ↑ كومر، دي إي (2021). الربط الشبكي باستخدام بروتوكول TCP/IP ( الطبعة السادسة). بيرسون. 
  2. ↑ لابرادور، ميغيل أ.؛ بيريز، ألفريدو ج.؛ وايتمان، بيدرو م. (2010). أنظمة المعلومات القائمة على الموقع: تطوير تطبيقات التتبع في الوقت الحقيقي . مطبعة سي آر سي. رقم ISBN 9781000556803.
  3. ↑ فينتون ج. سيرف؛ روبرت إي. كان (مايو 1974). "بروتوكول للتواصل بين شبكات الحزم" (ملف PDF) . معاملات IEEE في الاتصالات . 22 (5): 637-648 . رمز Bibcode : 1974ITCom..22..637C . doi : 10.1109/tcom.1974.1092259 . مؤرشف من النسخة الأصلية (ملف PDF) في 4 مارس 2016.
  4. ↑ بينيت، ريتشارد (سبتمبر 2009). "مصمم للتغيير: حجج شاملة، ابتكار الإنترنت، وجدل حيادية الإنترنت" (ملف PDF) . مؤسسة تكنولوجيا المعلومات والابتكار. ص 11. مؤرشف (ملف PDF) من الأصل في 29 أغسطس 2019. تم الاطلاع عليه في 11 سبتمبر 2017 . 
  5. ↑ RFC 675 .
  6. ↑ راسل، أندرو لورانس (2008)."الهيئات التشريعية الصناعية": توحيد المعايير بالتوافق في الثورتين الصناعيتين الثانية والثالثة (أطروحة).انظر: Abbate، اختراع الإنترنت ، 129-130؛ Vinton G. Cerf (أكتوبر 1980). "بروتوكولات شبكات الحزم المترابطة". ACM SIGCOMM Computer Communication Review . 10 (4): 10-11 .؛ و RFC 760. IETF . doi : 10.17487 /RFC0760 ."
  7. ↑ بوستل، جون (15 أغسطس 1977)، تعليقات على بروتوكول الإنترنت وTCP ، IEN 2، مؤرشف من الأصل في 16 مايو 2019 ، تم استرجاعه في 11 يونيو 2016 ، إننا نُخطئ في تصميم بروتوكولات الإنترنت بانتهاك مبدأ الطبقات. تحديدًا، نحاول استخدام TCP للقيام بأمرين: العمل كبروتوكول شامل على مستوى المضيف، والعمل كبروتوكول لتغليف وتوجيه الإنترنت. يجب توفير هذين الأمرين بطريقة طبقية ووحداتية.
  8. ↑ سيرف، فينتون ج. (1 أبريل 1980). "التقرير النهائي لمشروع TCP بجامعة ستانفورد" .
  9. ↑ سيرف، فينتون جي؛ كاين، إدوارد (أكتوبر 1983). "نموذج بنية الإنترنت لوزارة الدفاع". شبكات الحاسوب . 7 (5): 307-318 . doi : 10.1016/0376-5075(83)90042-9 .
  10. ↑ "دليل TCP/IP - بنية TCP/IP ونموذج TCP/IP" . www.tcpipguide.com . تاريخ الاسترجاع: 11 فبراير 2020 .
  11. ↑ إيدي، ويسلي (أغسطس 2022). بروتوكول التحكم في الإرسال (TCP) . IETF . doi : 10.17487/RFC9293 . RFC 9293 .
  12. ↑ "فهرس ملاحظات تجارب الإنترنت" . www.rfc-editor.org . تاريخ الاسترجاع: 21 يناير 2024 .
  13. ↑ "روبرت إي كان - الحائز على جائزة تورينج" . amturing.acm.org . مؤرشف من الأصل بتاريخ 13 يوليو 2019. تم الاطلاع عليه بتاريخ 13 يوليو 2019 .
  14. ↑ "فينتون سيرف - الحائز على جائزة تورينج" . amturing.acm.org . مؤرشف من الأصل بتاريخ 11 أكتوبر 2021. تم الاطلاع عليه بتاريخ 13 يوليو 2019 .
  15. 1 2 3 4 5 6 7 8 9 كومر، دوغلاس إي. (2006). الربط الشبكي باستخدام بروتوكول TCP/IP: المبادئ والبروتوكولات والبنية . المجلد 1 ( الطبعة الخامسة). برنتيس هول. ISBN   978-0-13-187671-2.
  16. 1 2 3 RFC 9293 ، 2.2. مفاهيم TCP الرئيسية.
  17. ↑ RFC 791 ، الصفحات 5-6.
  18. 1 2 3 4 RFC 9293 .
  19. 1 2 3 4 RFC 9293 ، 3.1. تنسيق الرأس.
  20. ↑ RFC 9293 ، 3.8.5 نقل المعلومات العاجلة.
  21. ↑ RFC 9293 ، 3.4. أرقام التسلسل.
  22. ↑ RFC 9293 ، 3.4.1. اختيار رقم التسلسل الأولي.
  23. ↑ "تغيير RFC 3540 "إشعار الازدحام الصريح القوي (ECN) باستخدام الأرقام العشوائية" إلى تاريخي" . datatracker.ietf.org . تم الاطلاع عليه بتاريخ 18-04-2023 .
  24. ↑ بريسكو، بوب؛ كوليويند، ميرجا؛ شيفينيغر، ريتشارد (10 مارس 2025). إشعار ازدحام أكثر دقة وصراحة (AccECN) في بروتوكول TCP . IETF . المعرف: draft-ietf-tcpm-accurate-ecn . تاريخ الاسترجاع: 24 أكتوبر 2025 .
  25. ↑ RFC 3168 ، الصفحات 13-14.
  26. ↑ RFC 3168 ، ص 15.
  27. ↑ RFC 3168 ، الصفحات 18-19.
  28. ↑ RFC 793 .
  29. 1 2 3 RFC 7323 .
  30. ↑ RFC 2018 ، 2. خيار الإقالة المسموح به.
  31. ↑ RFC 2018 ، 3. تنسيق خيار الإقالة.
  32. ↑ هيفيرنان، آندي (أغسطس 1998). حماية جلسات بروتوكول بوابة الحدود (BGP) عبر خيار توقيع MD5 لبروتوكول TCP . IETF. doi : 10.17487/RFC2385 . RFC 2385. تاريخ الاسترجاع: 30 ديسمبر 2023 .
  33. ↑ "معلمات بروتوكول التحكم في الإرسال (TCP): أرقام أنواع خيارات TCP" . هيئة الأرقام المخصصة للإنترنت (IANA). مؤرشف من الأصل بتاريخ 2017-10-02 . تم الاطلاع عليه بتاريخ 2017-10-19 .
  34. ↑ RFC 9293 ، 3.3.2. نظرة عامة على آلة الحالة.
  35. ↑ كوروز، جيمس ف. (2017). شبكات الحاسوب : منهج من أعلى إلى أسفل . كيث و. روس ( الطبعة السابعة). هارلو، إنجلترا. ص 286. ISBN    978-0-13-359414-0. OCLC 936004518 . {{cite book}}: CS1 maint: موقع الناشر مفقود ( رابط )
  36. ↑ تانينباوم، أندرو س. (17 مارس 2003). شبكات الحاسوب ( الطبعة الرابعة). برنتيس هول. ISBN  978-0-13-066102-9.
  37. ↑ "linux/net/ipv4/tcp_minisocks.c at master · torvalds/linux" . GitHub . تم الاسترجاع في 24 أبريل 2025 .
  38. ↑ RFC 1122 ، 4.2.2.13. إغلاق الاتصال.
  39. ↑ "بروتوكول التحكم في الإرسال (TCP) - شرح بروتوكول الإرسال" . الدليل الرقمي لشركة IONOS . 2020-03-02 . تاريخ الاسترجاع: 2025-04-24 .
  40. ↑ "دليل TCP/IP - إنهاء اتصال TCP" . www.tcpipguide.com . تاريخ الاسترجاع: 24-04-2025 .
  41. ↑ كارن وبارتريدج 1991 ، ص 364.
  42. ↑ RFC 9002 ، 4.2. أرقام الحزم المتزايدة بشكل رتيب.
  43. ↑ ماثيس؛ ماثيو؛ سيمكي؛ مهدوي؛ أوت (1997). "السلوك الكلي لخوارزمية تجنب ازدحام بروتوكول التحكم بالنقل". مجلة ACM SIGCOMM لمراجعة اتصالات الحاسوب . 27 (3): 67-82 . CiteSeerX 10.1.1.40.7002 . doi : 10.1145/263932.264023 . S2CID 1894993 .  
  44. ↑ RFC 3522 ، ص 4.
  45. ↑ ليونغ، كا-تشيونغ؛ لي، فيكتور أوك؛ يانغ، داي تشين (2007). "نظرة عامة على إعادة ترتيب الحزم في بروتوكول التحكم في الإرسال (TCP): المشكلات والحلول والتحديات". معاملات IEEE في الأنظمة المتوازية والموزعة . 18 (4): 522-535 . Bibcode : 2007ITPDS..18..522L . doi : 10.1109/TPDS.2007.1011 .
  46. ↑ يوهانسن، مادز (2015). دراسة إعادة ترتيب البيانات في بروتوكول TCP في نظام لينكس (رسالة ماجستير). جامعة أوسلو.
  47. ↑ تشنغ، يوتشونغ (2015). RACK: كشف سريع لفقدان البيانات يعتمد على الوقت لبروتوكول TCP draft-cheng-tcpm-rack-00 (PDF) . IETF94. يوكوهاما: IETF.
  48. ↑ RFC 8985 .
  49. ↑ تشنغ، يوتشونغ؛ كاردويل، نيل؛ دوكيباتي، نانديتا ؛ جها، بريارانجان (2017). RACK: مسودة استعادة سريعة للبيانات المفقودة تعتمد على الوقت draft-ietf-tcpm-rack-02 (ملف PDF) . IETF100. يوكوهاما: IETF.
  50. ↑ RFC 6298 ، ص. 2.
  51. 1 2 Zhang 1986 ، ص. 399.
  52. ↑ كارن وبارتريدج 1991 ، ص 365.
  53. ^ لودفيج وكاتز 2000 ، ص 31-33.
  54. ↑ جورتوف ولودفيج 2003 ، ص. 2.
  55. ↑ غورتوف وفلويد 2004 ، ص. 1.
  56. 1 2 RFC 6298 ، ص. 4.
  57. ↑ كارن وبارتريدج 1991 ، ص 370-372.
  58. ↑ ألمان وباكسون 1999 ، ص 268.
  59. ↑ RFC 7323 ، ص 7.
  60. ↑ ستون؛ بارتريدج (2000). "عندما يختلف مجموع التحقق CRC وTCP" . وقائع مؤتمر التطبيقات والتقنيات والهياكل والبروتوكولات الخاصة باتصالات الحاسوب . مجلة ACM SIGCOMM لمراجعة اتصالات الحاسوب . الصفحات 309-319 . CiteSeerX 10.1.1.27.7611 . doi : 10.1145/347059.347561 . ISBN   978-1581132236S2CID 9547018. مؤرشف من الأصل بتاريخ 2008-05-05 . تم الاطلاع عليه بتاريخ 2008-04-28 . 
  61. ↑ RFC 5681 .
  62. ↑ RFC 6298 .
  63. ↑ RFC 1122 .
  64. ↑ RFC 2018 ، ص 10.
  65. ↑ RFC 9002 ، 4.4. لا تراجع.
  66. ↑ كوربيت، جوناثان (7 يوليو 2004). "توسيع نطاق نافذة TCP وأجهزة التوجيه المعطلة" . LWN.net . مؤرشف من الأصل في 31 مارس 2020. تم الاطلاع عليه في 21 يوليو 2016 .
  67. ↑ RFC 3522 .
  68. ↑ "IP sysctl" . وثائق نواة لينكس . مؤرشف من الأصل في 5 مارس 2016. تم الاطلاع عليه في 15 ديسمبر 2018 .
  69. ↑ وانغ، إيف. "تم تعطيل الطابع الزمني لبروتوكول TCP" . تكنيت - أساسيات ويندوز سيرفر 2012. مايكروسوفت. مؤرشف من الأصل بتاريخ 15 ديسمبر 2018. تم الاطلاع عليه بتاريخ 15 ديسمبر 2018 .
  70. ↑ ديفيد موراي؛ تيري كوزينيك؛ سيباستيان زاندر؛ مايكل ديكسون؛ بوليكرونيس كوتساكيس (2017). "تحليل لخصائص حركة مرور شبكات المؤسسات المتغيرة" (ملف PDF) . المؤتمر الثالث والعشرون لآسيا والمحيط الهادئ للاتصالات (APCC 2017). مؤرشف (ملف PDF) من الأصل في 3 أكتوبر 2017. تم الاطلاع عليه في 3 أكتوبر 2017 .
  71. ↑ غونت، فرناندو (نوفمبر 2008). "حول تطبيق بيانات TCP العاجلة" . الاجتماع الثالث والسبعون لـ IETF. مؤرشف من الأصل بتاريخ 16 مايو 2019. تم الاطلاع عليه بتاريخ 4 يناير 2009 .
  72. ↑ بيترسون ، لاري (2003). شبكات الحاسوب . مورغان كوفمان. ص 401. ISBN  978-1-55860-832-0.
  73. ↑ ريتشارد دبليو. ستيفنز (نوفمبر 2011). بروتوكول TCP/IP المصور. المجلد 1، البروتوكولات . أديسون-ويسلي. ص. الفصل 20. ISBN  978-0-201-63346-7.
  74. ↑ "تقييم أمني لبروتوكول التحكم في الإرسال (TCP)" (ملف PDF) . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 6 مارس 2009. تم الاطلاع عليه بتاريخ 23 ديسمبر 2010 .
  75. ↑ دراسة استقصائية لأساليب تعزيز أمان تطبيقات بروتوكول التحكم في الإرسال (TCP) . IETF . المعرف: draft-ietf-tcpm-tcp-security.
  76. ↑ جاكوب ليل (13 أغسطس 2013). "انتحال سريع لاتصال TCP الأعمى باستخدام ملفات تعريف الارتباط SYN" . مؤرشف من الأصل في 22 فبراير 2014. تم الاطلاع عليه في 5 فبراير 2014 .
  77. ↑ "بعض المعلومات حول ثغرات هجمات حجب الخدمة (DoS) الأخيرة في بروتوكول TCP" (ملف PDF) . مؤرشف من النسخة الأصلية (PDF) بتاريخ 18 يونيو 2013. تم الاطلاع عليه بتاريخ 23 ديسمبر 2010 .
  78. ↑ "استغلال بروتوكول TCP وخاصية استمرار المؤقت اللانهائي" . مؤرشف من الأصل بتاريخ 22-01-2010 . تم الاطلاع عليه بتاريخ 22-01-2010 .
  79. ↑ "PUSH and ACK Flood" . f5.com . مؤرشف من الأصل بتاريخ 28-09-2017 . تم الاطلاع عليه بتاريخ 27-09-2017 .
  80. ↑ لوران جونشيري (1995). هجوم نشط بسيط ضد بروتوكول TCP (ملف PDF) . ندوة USENIX الخامسة لأمن أنظمة يونكس . تاريخ الاسترجاع: 4 يونيو 2023 .
  81. ↑ جون تي. هاجن؛ باري إي. مولينز (2013). حق النقض TCP: هجوم شبكي جديد وتطبيقه على بروتوكولات SCADA . مؤتمر IEEE PES لتقنيات الشبكات الذكية المبتكرة (ISGT) لعام 2013. الصفحات 1-6 . doi : 10.1109/ISGT.2013.6497785 . ISBN  978-1-4673-4896-6. S2CID 25353177 . 
  82. ↑ RFC 9293 ، 4. مسرد المصطلحات.
  83. ↑ RFC 8095 ، ص 6.
  84. ^ باش وبونافنتورا 2014 ، ص. 51.
  85. ↑ RFC 6182 .
  86. ↑ RFC 6824 .
  87. ↑ رايسيو؛ بار؛ بلونتك؛ غرينهاغ؛ ويشيك؛ هاندلي (2011). "تحسين أداء مراكز البيانات وموثوقيتها باستخدام بروتوكول TCP متعدد المسارات" . مجلة ACM SIGCOMM لمراجعة اتصالات الحاسوب . 41 (4): 266. CiteSeerX 10.1.1.306.3863 . doi : 10.1145/2043164.2018467 . مؤرشف من الأصل بتاريخ 2020-04-04 . تم الاطلاع عليه بتاريخ 2011-06-29 . 
  88. ↑ "بروتوكول TCP متعدد المسارات - تطبيق نواة لينكس" . مؤرشف من الأصل بتاريخ 27-03-2013 . تم الاطلاع عليه بتاريخ 24-03-2013 .
  89. ↑ رايسيو؛ باش؛ بار؛ فورد؛ هوندا؛ دوشين؛ بونافنتور؛ هاندلي (2012). "ما مدى صعوبة ذلك؟ تصميم وتنفيذ بروتوكول TCP متعدد المسارات قابل للنشر" . Usenix NSDI : 399-412 . مؤرشف من الأصل في 3 يونيو 2013. تم الاطلاع عليه في 24 مارس 2013 .
  90. ↑ بونافنتور؛ سيو (2016). "نشر بروتوكول TCP متعدد المسارات" . مجلة IETF . مؤرشف من الأصل بتاريخ 23 فبراير 2020. تم الاطلاع عليه بتاريخ 3 يناير 2017 .
  91. ↑ الحماية التشفيرية لتدفقات TCP (tcpcrypt) . IETF . مايو 2019. doi : 10.17487/RFC8548 . RFC 8548 .
  92. ↑ مايكل كيريسك (1 أغسطس 2012). "TCP Fast Open: تسريع خدمات الويب" . LWN.net . مؤرشف من الأصل في 3 أغسطس 2014. تم الاطلاع عليه في 21 يوليو 2014 .
  93. ↑ RFC 7413 .
  94. ↑ RFC 6937 .
  95. ↑ غريغوريك، إيليا (2013). شبكات المتصفح عالية الأداء ( الطبعة الأولى). بكين: أورايلي. ISBN  978-1449344764.
  96. ↑ RFC 6013 .
  97. ↑ RFC 7805 .
  98. ↑ كومار، سام؛ بي أندرسن، مايكل؛ كيم، هيونغ سين؛ إي. كولر، ديفيد (2020). بروتوكول TCP عالي الأداء للشبكات اللاسلكية منخفضة الطاقة . NSDI '20. USENIX.
  99. ↑ كومار، سام (2023). إعادة النظر في تصميم النظام للتشفير التعبيري (ملف PDF) (أطروحة دكتوراه). جامعة كاليفورنيا، بيركلي. مؤرشف (ملف PDF) من الأصل في 13 أكتوبر 2025.
  100. ↑ RFC 8546 ، ص 6.
  101. ↑ RFC 8558 ، ص 3.
  102. ↑ RFC 9065 ، 2. الاستخدامات الحالية لرؤوس النقل داخل الشبكة.
  103. ↑ RFC 9065 ، 3. البحث والتطوير والنشر.
  104. ↑ RFC 8558 ، ص 8.
  105. ↑ RFC 9170 ، 2.3. التفاعلات متعددة الأطراف والصناديق الوسيطة.
  106. ↑ RFC 9170 ، A.5. TCP.
  107. ^ باباسترجيو وآخرون. 2017 ، ص. 620.
  108. ^ إيديلين ودونيت 2019 ، ص 175–176.
  109. ^ رايسيو وآخرون. 2012 ، ص. 1.
  110. ^ هيسمانز وآخرون. 2013 ، ص. 1.
  111. 1 2 Rybczyńska 2020 .
  112. ^ باباسترجيو وآخرون. 2017 ، ص. 621.
  113. ↑ كوربيت 2015 .
  114. ^ بريسكو وآخرون. 2016 ، ص. 29-30.
  115. ↑ ماركس 2020 ، حظر HOL في HTTP/1.1.
  116. ↑ ماركس 2020 ، إضافة: التحكم في ازدحام النقل.
  117. ↑ مجموعة عمل بروتوكول الإنترنت (IETF) لبروتوكول HTTP ، لماذا اتصال TCP واحد فقط؟
  118. ↑ كوربيت 2018 .
  119. 1 2 RFC 7413 ، ص. 3.
  120. ↑ Sy et al. 2020 ، ص. 271.
  121. ^ تشن وآخرون. 2021 ، ص. 8-9.
  122. ↑ غيديني 2018 .
  123. ^ تشن وآخرون. 2021 ، ص. 3-4.
  124. ↑ RFC 7413 ، ص 1.
  125. ↑ بلانتون وألمان 2002 ، ص 1-2.
  126. ↑ بلانتون وألمان 2002 ، ص 4-5.
  127. ↑ بلانتون وألمان 2002 ، ص 3-4.
  128. ↑ بلانتون وألمان 2002 ، ص 6-8.
  129. ↑ برويرون، هيمون وتشانغ 1998 ، ص 67.
  130. ↑ برويرون، هيمون وتشانغ 1998 ، ص 72.
  131. ^ بهات ورزق وزنك 2017 ، ص. 14.
  132. ↑ RFC 9002 ، 4.5. نطاقات ACK إضافية.
  133. 1 2 "أداء بروتوكول TCP عبر CDMA2000 RLP" . مؤرشف من الأصل بتاريخ 2011-05-03 . تم الاطلاع عليه بتاريخ 2010-08-30 .
  134. ↑ محمد عادل؛ أحمد علي إقبال (2007). "تحسين نافذة ازدحام بروتوكول التحكم في الإرسال (TCP) لشبكات بيانات الحزم CDMA2000". المؤتمر الدولي الرابع لتكنولوجيا المعلومات (ITNG'07) . الصفحات 31-35 . doi : 10.1109/ITNG.2007.190 . ISBN  978-0-7695-2776-5. S2CID 8717768 . 
  135. ↑ "تسريع بروتوكول TCP" . مؤرشف من الأصل بتاريخ 22-04-2024 . تم الاطلاع عليه بتاريخ 18-04-2024 .
  136. ↑ يون هونغ غو؛ شينوي هونغ؛ روبرت ل. غروسمان (2004). "تحليل خوارزمية AIMD مع الزيادات المتناقصة" (ملف PDF) . مؤرشف (ملف PDF) من الأصل بتاريخ 2016-03-05.
  137. ↑ RFC 8200 .
  138. ↑ "Wireshark: تفريغ البيانات" . مؤرشف من الأصل بتاريخ 31 يناير 2017. تم الاطلاع عليه بتاريخ 24 فبراير 2017. يلتقط برنامج Wireshark الحزم قبل إرسالها إلى محول الشبكة. لن يرى البرنامج مجموع التحقق الصحيح لأنه لم يتم حسابه بعد. والأسوأ من ذلك، أن معظم أنظمة التشغيل لا تُهيئ هذه البيانات، لذا من المحتمل أنك ترى أجزاءً صغيرة من الذاكرة لا ينبغي أن تراها. تُعطّل عمليات التثبيت الجديدة لبرنامج Wireshark 1.2 والإصدارات الأحدث التحقق من مجموع التحقق لبروتوكولات IP وTCP وUDP افتراضيًا. يمكنك تعطيل التحقق من مجموع التحقق في كل محلل من هذه المحللات يدويًا إذا لزم الأمر.
  139. ↑ "Wireshark: Checksums" . مؤرشف من الأصل بتاريخ 22-10-2016 . تم الاطلاع عليه بتاريخ 24-02-2017 . غالبًا ما يتسبب تفريغ حساب المجموع الاختباري في حدوث لبس، حيث تُسلّم حزم الشبكة المراد إرسالها إلى Wireshark قبل حساب المجموع الاختباري فعليًا. يحصل Wireshark على هذه المجاميع الاختبارية "الفارغة" ويعرضها على أنها غير صالحة، على الرغم من أن الحزم ستحتوي على مجاميع اختبارية صالحة عند مغادرتها جهاز الشبكة لاحقًا.

فهرس

طلبات التعليقات

وثائق أخرى

للمزيد من القراءة