مقدمة

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

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

دور TCP ومفهوم الاتصال الموجّه

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

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

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

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

مقاطع TCP وأرقام التسلسل والإقرار

يتبادل TCP البيانات في وحدات تسمى المقاطع، وتُغلّف داخل رزم IP. يحتوي ترويس TCP على حقول ضرورية لإدارة الاتصال، من أهمها منفذا المصدر والوجهة، ورقم التسلسل Sequence Number، ورقم الإقرار Acknowledgment Number، وأعلام التحكم، وحجم النافذة.

رقم التسلسل لا يشير فقط إلى ترتيب المقاطع، بل إلى موضع بايتات البيانات داخل تيار البيانات المنطقي. فإذا أرسل طرف بيانات تبدأ برقم تسلسل 1000 وطولها 500 بايت، فإن الطرف المستقبِل، بعد استلامها كاملة، يرسل عادة إقراراً بالرقم 1500. ومعنى ذلك: «وصلتني جميع البايتات حتى الرقم 1499، وأتوقع البايت الذي رقمه 1500». لذلك يكون الإقرار في TCP إقراراً تراكمياً، وهو أسلوب يقلل عدد رسائل التحكم المطلوبة.

توجد أعلام تحكم مهمة، أبرزها SYN لطلب مزامنة أرقام التسلسل وبدء الاتصال، وACK للدلالة على أن حقل الإقرار صالح، وFIN لطلب الإغلاق المنظم، وRST لإنهاء الاتصال أو رفضه بصورة فورية. ويستهلك كل من العلمين SYN وFIN رقماً واحداً من فضاء أرقام التسلسل، حتى لو لم يحتو المقطع على بيانات تطبيقية.

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

المصافحة الثلاثية لإنشاء اتصال TCP

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

في الخطوة الأولى، يرسل العميل مقطعاً يحمل العلم SYN إلى الخادم. ينتقل العميل بعد ذلك إلى حالة SYN-SENT، وينتظر استجابة الخادم. يحتوي هذا المقطع على رقم التسلسل الابتدائي للعميل، ولنفترض أنه 1000. لا يكون الاتصال قد اكتمل في هذه المرحلة، لأن العميل لم يتأكد بعد من وصول طلبه أو من جاهزية الخادم.

في الخطوة الثانية، إذا كان الخادم يستمع على المنفذ المطلوب ويقبل الاتصال، فإنه يرد بمقطع يحمل العلمين SYN وACK. يكون رقم الإقرار فيه 1001، لأن SYN الخاص بالعميل استهلك رقماً واحداً، ويحتوي كذلك على رقم التسلسل الابتدائي للخادم، ولنفترض أنه 7000. ينتقل الخادم إلى حالة SYN-RECEIVED، إذ لا يزال ينتظر التأكيد الأخير من العميل.

في الخطوة الثالثة، يستقبل العميل مقطع SYN-ACK، ويتحقق من أن الإقرار يطابق SYN الذي أرسله. ثم يرسل مقطع ACK برقم إقرار 7001 لتأكيد SYN الخاص بالخادم. بعد إرسال هذا الإقرار ينتقل العميل إلى حالة ESTABLISHED، وعند وصوله إلى الخادم ينتقل الخادم أيضاً إلى الحالة نفسها. عندئذ فقط يصبح الطرفان جاهزين لتبادل بيانات التطبيق.

العميل                              الخادم
CLOSED                               LISTEN
  | ---- SYN, Seq=1000 ---------->    |
SYN-SENT                            SYN-RECEIVED
  | <-- SYN+ACK, Seq=7000, Ack=1001 - |
  | ---- ACK, Ack=7001 ---------->    |
ESTABLISHED                        ESTABLISHED

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

لماذا تحتاج TCP إلى ثلاث رسائل بدلاً من رسالتين؟

قد يبدو أن رسالة SYN من العميل ورسالة SYN-ACK من الخادم كافيتان، لكنهما لا تثبتان أن الخادم يستطيع التأكد من وصول استجابته إلى العميل. المصافحة الثنائية تجعل الخادم يضطر إلى افتراض أن العميل استلم رده، وقد يحتفظ بموارد اتصال لحالة لا وجود لها فعلياً إذا ضاعت الاستجابة أو كان الطلب الأصلي قديماً ومتأخراً.

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

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

ومن الناحية الأمنية، قد يستغل مهاجم إرسال أعداد كبيرة من رسائل SYN دون إكمال الإقرار الأخير، فتتراكم اتصالات في حالة SYN-RECEIVED، وهو ما يعرف بهجوم إغراق SYN. تستخدم الأنظمة وسائل دفاع مثل قوائم الانتظار المحدودة وملفات تعريف SYN المؤقتة لتقليل أثر هذه الهجمات، مع المحافظة على التوافق مع آلية TCP الأساسية.

حالات TCP وانتقالاتها أثناء الجلسة

يصف TCP دورة حياة الاتصال عبر آلة حالات محددة. البداية المعتادة لدى العميل هي CLOSED، ثم ينتقل إلى SYN-SENT بعد إرسال SYN. أما الخادم فينتقل من CLOSED إلى LISTEN عندما يطلب التطبيق الاستماع على منفذ، ثم إلى SYN-RECEIVED بعد تلقي SYN وإرسال SYN-ACK. وعندما تكتمل المصافحة يصل الطرفان إلى ESTABLISHED.

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

إذا أُغلق الاتصال بصورة غير طبيعية، مثل وصول مقطع يحمل RST أو حدوث خطأ جسيم في التطبيق أو البروتوكول، قد ينتقل الاتصال مباشرة إلى CLOSED. يختلف RST عن FIN في أنه لا يمنح الطرف الآخر فرصة لتصريف البيانات المتبقية بصورة منظمة. لذلك قد تظهر للتطبيق أخطاء مثل «إعادة تعيين الاتصال من النظير» عند محاولة القراءة أو الكتابة بعد هذا النوع من الإغلاق.

يمكن لمسؤول الشبكة مراقبة الحالات عملياً بأوامر النظام. على أن أسماء الأدوات ومخرجاتها تختلف باختلاف نظام التشغيل:

ss -tan

# مثال على مخرجات مختصرة
ESTAB      0      0      192.168.1.10:51524   203.0.113.20:443
TIME-WAIT  0      0      192.168.1.10:51526   203.0.113.20:443
LISTEN     0      128    0.0.0.0:8080         0.0.0.0:*

تساعد هذه الحالات في تشخيص الأعطال. فبقاء اتصالات كثيرة في SYN-SENT قد يشير إلى عدم وصول رد الخادم أو إلى جدار ناري يحجب الاستجابة. أما كثرة الاتصالات في TIME-WAIT فقد تكون طبيعية لخادم أو عميل نشط، لكنها قد تتطلب مراجعة تصميم التطبيق إذا استهلكت منافذ مؤقتة بسرعة كبيرة.

إنهاء الاتصال: الإغلاق الرباعي وحالة TIME-WAIT

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

لنفترض أن العميل هو من يبدأ الإغلاق. يرسل العميل FIN وينتقل إلى FIN-WAIT-1. عندما يستلم الخادم هذا المقطع، يرسل ACK لتأكيده وينتقل إلى CLOSE-WAIT، بينما ينتقل العميل إلى FIN-WAIT-2. في هذه المرحلة يستطيع الخادم مواصلة إرسال أي بيانات متبقية إلى العميل، وهي خاصية مهمة عندما يحتاج التطبيق إلى إنهاء الإرسال في اتجاه واحد مع إبقاء الاتجاه الآخر مفتوحاً مؤقتاً.

عندما ينتهي الخادم بدوره من الإرسال، يرسل FIN وينتقل إلى LAST-ACK. يرد العميل بإقرار ACK أخير، فيدخل العميل حالة TIME-WAIT، بينما ينتقل الخادم إلى CLOSED بعد تلقي الإقرار. ينتظر العميل في TIME-WAIT مدة محددة قبل الإغلاق النهائي.

العميل                              الخادم
ESTABLISHED                        ESTABLISHED
  | ---- FIN -------------------->   |
FIN-WAIT-1                         CLOSE-WAIT
  | <--- ACK ---------------------   |
FIN-WAIT-2                         CLOSE-WAIT
  | <--- FIN ---------------------   |
TIME-WAIT                          LAST-ACK
  | ---- ACK -------------------->   |
CLOSED                             CLOSED

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

خاتمة

يبني TCP موثوقيته على إدارة دقيقة للحالة في طرفي الاتصال. تبدأ العملية بالمصافحة الثلاثية: SYN من العميل، ثم SYN-ACK من الخادم، ثم ACK أخير يثبت التزامن المتبادل. وبعد ذلك تضمن أرقام التسلسل والإقرارات والنوافذ وصول البيانات بترتيب صحيح قدر الإمكان رغم طبيعة IP غير المضمونة.

وعند انتهاء العمل، لا يقطع TCP الجلسة بصورة عشوائية، بل يستخدم FIN وACK لإغلاق كل اتجاه على حدة، مع الاحتفاظ بحالة TIME-WAIT عند الطرف الذي يبدأ الإغلاق. إن فهم حالات مثل LISTEN وSYN-SENT وESTABLISHED وFIN-WAIT وTIME-WAIT يمنح مطوري التطبيقات ومسؤولي الشبكات أساساً عملياً لتحليل الاتصالات، وتشخيص المشكلات، وتصميم خدمات شبكة أكثر استقراراً وأماناً.