مجتمع الهكر الأخلاقي: طبقة النقل في بروتوكول TCP/IP

طبقة النقل في بروتوكول TCP/IP

الوظيفة الرئيسية لطبقة النقل هي إخفاء تعقيدات الشبكة عن الطبقات العليا (التطبيق والعرض والجلسة)، مُتيحةً لمُطورِيّ التطبيقات تطويرَ البرمجيات دون التفكير في طريقة التعامل مع الشبكة. مما يوفِّر استقلاليّةً في نشر (deployment) وتطوير المكونات (components) في تجميعة بروتوكول IP.

يتوفَّر بروتوكولان في طبقة النقل هما: UDP ‏(User Datagram Protocol)، و TCP ‏(Transmission Control Protocol). يقوم كلاهما بالإرسال المتعدد للجلسة (session multiplexing)، الذي هو أحد الوظائف الرئيسية لطبقة النقل، الذي يعني أنه يتمّكن جهازٌ ما يستعمل عدِّة جلسات أو عدِّة اتصالات من استخدام عنوان IP ذاته للتواصل مع الشبكة. مثال: تتمكن الخواديم التي توفِّر خدمات الويب وFTP من استخدام نفس عنوان IP.

ميزةٌ أخرى هي«التقطيع» (segmentation) التي تُحضِّر وحدات المعلومات (units of information) من طبقة التطبيقات وتُقسِّمها إلى قطع لتغليفها في رزم لإرسالها عبر الشبكة. وقد تتأكد طبقة النقل -اختياريًّا- أن تلك الرزم قد وصلت إلى الوجهة عبر آليات التحكم في الجريان (flow control). ما سبق اختيارٌ لأنَّ بروتوكول TCP هو من يوفِّر تلك الخدمة فقط، لأنه بروتوكولٌ يعتمد على الاتصالات (connection-oriented)؛ على عكس UDP الذي هو بروتوكول عديم الاتصال (connectionless)، ويُستخدَم عندما تكون السرعةُ عاملًا مهمًّا، حيث يؤدي التحكم في الجريان والوثوقية (reliability) إلى إبطاء سرعة الاتصال.

فإذا أردنا أن نقارن بروتوكولَي طبقة النقل، فسيكون بروتوكول TCP معتمدًا على الاتصالات، وهو بروتوكولٌ ذو وثوقيةٍ عالية، ويوفِّر آلياتٍ مثل ترقيم الرزم وإعادة تجميعها في الوجهة بنفس الترتيب، وآليةٌ كاملةٌ لتحديد التوقيت لضمان تسليم الرزم... أما UDP فهو بروتوكولٌ عديم الاتصال، ولا يوفِّر أي ترتيبٍ للرزم ولا أي نوعٍ من ضمانة توصيلها.

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

لكن قد تتعامل الطبقات العليا مع بروتوكول UDP بطريقةٍ مختلفة، وتزيد من وثوقية توصيله للرزم. أمثلة على استخدام كلي البروتوكولَين: تَستخدم خدمات البريد الإلكتروني ونقل الملفات والتنزيل بروتوكول TCP ذا الوثوقيّة العالية؛ أما اتصالات الصوت والفيديو فستستفيد من التخلص من عبء التحقق من الوصول والوثوقية مما يؤدي إلى تسريع تسليم الرزم، حيث تستطيع تلك التطبيقات التعامل مع فقدان بعض الرزم الشبكيّة.

	الوثوقية	أفضل جهد (Best-Effort)
البروتوكول	TCP	UDP
نوع الاتصال	ذو اتصال	عديم الاتصال
ترتيب الرزم	نعم	لا
الاستخدامات	البريد الإلكتروني مشاركة الملفات تنزيل الملفات	تدفق الصوت تدفق الفيديو الخدمات التي تعمل بالوقت الحقيقي

خصائص بروتوكول UDP

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

تحتوي ترويسة UDP على المنافذ في المصدر والوجهة، التي تُحدِّد التطبيقات التي تتصل عبر UDP، ويوجد أيضًا طول الحمولة (payload) وطول الترويسة والمجموع الاختباري للتحقق من سلامة البيانات.

خصائص بروتوكول TCP

يُوفِّرُ بروتوكولٌ يعتمد على الاتصالات، مثل TCP، وثوقيةً واكتشافًا للأخطاء وتصحيحًا لها، ويَضمن أيضًا توصيل الرزم؛ ولهذه الأسباب، سيكون أكثر تعقيدًا من UDP؛ إذ يُوفِّر تحققًا من الأخطاء على شكل مجموعات اختباريّة (checksums) بالإضافة إلى ترقيم كل رزمة لكي تتأكد الوجهة من الترتيب وتبحث عن الأجزاء أو الرزم الناقصة؛ يشبه اتصال TCP محادثةً تتم عبر الجهاز اللاسلكي (walkie-talkie)؛ حيث تتضمن إشعاراتٍ (acknowledgments) من كل طرف أنَّ الطرفَ الآخر قد استلم البيانات، وسيتم إكمال إرسال البيانات بعد استلام تأكيد بأنَّ الرزم السابقة قد وصلت. ولدى هذا البروتوكول آليةٌ لكي يعيد إرسال البيانات؛ فإن فُقِدَت رزمةٌ ما أثناء النقل، فيمكن إعادة إرسالها بمعرفة رقمها التسلسلي.

لن تؤدي العملية السابقة إلى المزيد من الإجراءات والبروتوكولات -مثل حساب الأرقام التسلسلية وآلية «sliding windows»- فحسب، بل وستؤدي أيضًا إلى وجود المزيد من المعلومات التي يجب تضمينها في الترويسة؛ ففي بروتوكول TCP، لن نشاهد منافذ المصدر والوجهة في الترويسة فقط، وإنما سنشاهد أيضًا الأرقام التسلسلية، وأرقام إشعارات الاستلام. يُحدَّد حجم النافذة (window size) لتسهيل عملية تأكيد وصول عدِّة رزم في مرة واحدة؛ وسيضمن المجموع الاختباري سلامة البيانات المنقولة. وهنالك أنماطٌ مختلفةٌ من التوصيل عبر استعمال «مؤشِّر الرزم المُستعجَلة» (urgent pointer)، والخيارات، والرايات (flags).

لمحة عن طبقة التطبيقات في TCP/IP

مهمة طبقة النقل هي إخفاء تعقيد الشبكة عن التطبيقات في الطبقة العليا؛ يمكن بناء تلك التطبيقات باستخدام TCP أو UDP اعتمادًا على حاجاتها، فيما إذا كانت تريد اتصالًا ذو وثوقيةٍ عالية، أو كانت تفضِّل سرعة النقل؛ مثالٌ عن التطبيقات هو تطبيقات FTP، و TFTP، وNFS لنقل الملفات؛ وSTMP، و POS3 للبريد الإلكتروني؛ ومختلف تطبيقات الوصول عن بُعد؛ و SNMP لإدارة الشبكة؛ وخدمة DNS لتحويل أسماء المضيفين إلى عناوين IP.

أحد أهم المفاهيم الأساسية لأي نموذج متعدد الطبقات هو التفاعل بين الطبقات؛ والطبقتان 3 و 4 من نموذج OSI ليستا استثناءً؛ فمثلًا، لو استقبل جهازٌ معيّن رزمًا من الشبكة وعالجها عبر بروتوكول IP في الطبقة الثالثة، فسيحتاج إلى مزيدٍ من المعلومات لتحديد البروتوكول الملائم لمعالجة تلك الرزمة، هل هو TCP أم UDP؛ بكلامٍ آخر، ما هو بروتوكول طبقة النقل الذي يجب أن يتوَّلى أمر الرزمة من هنا؟ يَستخدم IP حقل «البروتوكول» لتحديد بروتوكول طبقة النقل المُستخدَم؛ فمثلًا، الرقم «6» في حقل البروتوكول يعني أن TCP هو بروتوكول طبقة النقل الذي يجب أن يُعالِج تلك الرزمة، بينما «17» يعني أنَّ UDP هو البروتوكول الذي عليه معالجة الرزمة.

وبشكلٍ مشابه، سيحتاج بروتوكولَيّ TCP و UDP إلى المزيد من المعلومات ليعلما أيُّ تطبيقٍ في الطبقات العليا سيستلم الرزم الموجَّهة إليه؛ وذلك عبر أرقام المنافذ التي ستُذكَر في ترويسة طبقة النقل؛ على سبيل المثال، يُمثِّل المنفذ 21 خدمة FTP، و23 خدمة Telnet، بينما 80 يُمثِّل خدمة الويب على شكل بروتوكول HTTP؛ أما 53 فلخدمة DNS، و69 لخدمة TFTP، و 161 لخدمة SNMP؛ يجب أن تكون تلك الأرقام فريدةً، وهي مُسندةٌ من هيئة IANA؛ تكون أرقام المنافذ الشهيرة تحت 1023، لكن هنالك مجالاتٌ أخرى للمنافذ المُسجَّلة لكنّها تتبع للتطبيقات الاحتكاريّة؛ وحتى هنالك مجالاتٌ متوفرة للمنافذ التي تُحدَّد ديناميكيًا.

إنشاء اتصال

بروتوكول TCP مسؤولٌ عن إنشاء الاتصالات قبل إرسال الرزم؛ سيُستعمَل هذا الاتصال من كلي الطرفين لإنشاء جلسة معيّنة وإخفاء تعقيد الشبكة عنهما؛ بكلامٍ آخر، سيرى المُضيفان مُعرِّف الاتصال (connection identifier) وليس الشبكة المعقدة التي تقع «تحت» ذاك الاتصال؛ ومن واجبات بروتوكول TCP أيضًا إنشاء، وإدارة، وإنهاء الاتصالات بعد الانتهاء منها.

عملية «إنشاء الاتصال ثلاثية الاتجاه» (three-way handshake) هي عملية لمزامنة (synchronizing) جهازَين ليعلما أنهما متصلان عبر TCP؛ تَستخدِم هذه العملية رزمًا خاصةً التي تستعمل حقول التحكم (control fields) وترويسة TCP؛ حقول التحكم تلك مُعرَّفةٌ بالكلمة المفتاحية CTL في المخطط البياني التالي. ويبدأ الأمر بأكمله بإرسال رزمةٍ لها رقمٌ تسلسليٌ معيّن؛ وبكل تأكيد، سيكون «بت» التحكم هو SYN؛ ستُرسَل الرزمة وتعالجها النهاية المُستقبِلة وتُرسِل ما يُعرَف بإشعار SYN، التي (أي رزمة ذاك الإشعار) تكون فيها راية SYN ‏(SYN flag) وراية الإشعار. وتُستخدَم أيضًا الأرقام التسلسلية لإشعار استلام السلسلة التالية من البتات؛ يُنشَأ الاتصال بشكل كامل عندما يُرسَل الإشعار النهائي من المستلم؛ بت التحكم المُستخدم في الإشعار النهائي هو راية الإشعار فقط. وهذا يُشبِه محادثة الهاتف حيث نبدأ المحادثة بقول «مرحبًا» ويُرَدُّ علينا بالجملة «أهلًا، أنا هنا» ثم سيقول المُرسِل «حسنًا، لقد أنشَأنا الاتصال، لنبدأ التحدث».

التحكم في الجريان (Flow Control)

تؤدي آلية التحكم في الجريان في طبقة النقل والبروتوكولات مثل TCP إلى وظيفتين مستقلتين لكن توجد علاقةٌ تربط بينهما؛ أولاهما هي إشعارات استلام الرزم؛ والإشعارات ما هي إلا رزمٌ خاصةٌ تمثِّل تأكيدًا أن البيانات قد وصلت إلى وجهتها؛ ولن يُكمِل المُرسِل إرسال بياناتٍ إضافيةٍ ما لم يحصل على إشعارٍ باستلام البيانات المُرسَلة سابقًا.

الآلية الثانية هي «النوافذ» (windows)، التي تخدم هدف إرسال إشعار باستلام قطع من البيانات؛ بكلامٍ آخر، بدلًا من إرسال إشعار باستلام كل رزمة؛ فسنطلب من المُرسِل أن يُرسِل سلسلةً من الرزم دفعةً واحدة، بدلًا من إرسالها مُتفرِّقةً. وتُساهِم هذه الآلية بزيادة التحكم بكمية البيانات المُرسَلة، فعندما يُرسِل المُستقبِل حجم نافذة مساوٍ للقيمة 0، فإنه يقول للمُرسِل: «حافظتي ممتلئة، لا أستطيع معالجة أيّة بياناتٍ إضافيةً، أتمنى أن تنتظر حتى إشعارٍ آخر»، وعندما تصبح حافظة المستقبِل فارغةً ويصبح بمقدوره استلام المزيد من الرزم، فسيُستأنَف نقل البيانات عبر إرسال حجم نافذة مختلف؛ وفي هذه النقطة، سيُعيد المُرسِل تهيئة عملية النقل مجددًا.

حجم النافذة ما هو إلا مقدار المعلومات التي لم يُرسَل إشعارٌ باستلامها التي يمكن أن تكون قيد الإرسال؛ فعندما يُرسِل المُرسِل قطعة (chunk) البيانات رقم 1 (وتُعرَّف تلك القطعة بعدد البايتات أو الكيلوبايتات التي ستُرسَل)، فسيعمله المُستقبِل بذلك عبر تحديد القطعة التالية التي يتوقع وصولها؛ بكلامٍ آخر، لن يقول المُستقبِل: «أنا أعلمك أنني استلمت القطعة رقم 1 من البيانات»، بل سيقول: «أرسِل لي قطعة البيانات رقم 2 الآن»؛ يكون حجم النافذة في المثال السابق هو «1»، أي أننا نُرسِل إشعارًا باستلام كل قطعة، وهذا سيصبح أمرًا معقّدًا ويسبب بطئًا في الشبكة؛ حيث يلزم المزيد من الإشعارات للتحكم في التدفق ولإكمال الإرسال. فمن المهم أن نفهم أنَّ ما نسميّه «قطعًا» (chunks) يكون على شكل «segments» في طبقة النقل، وتكون تلك القطعة بوحدة بايت أو كيلوبايت.

لا يُسبِّب إشعارٌ واحدٌ لكل وحدة بيانات حِملًا ثقيلًا على الشبكة فحسب، بل يُبطِئ أيضًا من سرعة الاتصال؛ وهذا يشبه كثيرًا قول كلمة «حوِّل» (في مثالنا عن «اتصال الراديو» السابق) بعد كل كلمة يقولها المُرسِل: «أهلًا حوِّل»، «بِك حوِّل» ...إلخ. يتضمّن بروتوكول TCP آليةً للنوافذ، التي تسمح بزيادة عدد القطع المُرسَلة قبل إشعار استلامها؛ وبهذا، تستطيع أن تقول «أهلًا بِك» ثم تقول كلمة «حوِّل» في نهاية الجملة. يُمثِّل حجم النافذة عدد البايتات أو الكيلوبايتات التي يمكن أن تُرسَل دفعةً واحدة؛ ففي المخطط الآتي، ستُرسَل ثلاث قطع، ثم سيُرسِل المُستقبِل إشعارًا بالاستلام بقوله: «أرسل لي الرقم 4». وبهذا نكون قد أرسلنا إشعارًا باستلام أول ثلاث قطع دفعةً واحدة. يكون حجم النافذة في الحياة العملية بوحدة الكيلوبايت، أي ستكون طريقة زيادة حجم النافذة كالآتي: «كنت أُرسِل 64 كليوبايت، وأنا الآن أُرسِل 128 كيلوبايت، ويمكنك إرسال إشعار باستلام 128 كيلوبايت بدلًا من 64».

لا يُفضَّل استخدام نافذةٌ ذات حجمٍ ثابت للمُستقبِل والمُرسِل لملائمة ازدحام الشبكة (network congestion) والتأقلم تبعًا له؛ يسمح لك حجم نافذة محجوزٌ ديناميكيًا (ويُعرَف أيضًا بالمصطلح «sliding window») بالتأقلم دون التسبب بازدحامٍ في الشبكة ويعمل أيضًا كآلية للتحكم بالجريان (flow control mechanism).

تكتمل آلية التحكم عبر استخدام أرقام تسلسلية وأرقام إشعارات الاستلام؛ لاحظ أنه في هذا الرسم التوضيحي تكون الأرقام التسلسلية أكثر واقعيةً حيث تَظهِر كميّة البيانات بوحدة البايت التي ستُرسَل في كل قطعة؛ أي أنَّ الرقم التسلسلي «10» يعني أنَّه قد أُرسِل 10 بايتات من البيانات؛ ورقم إشعار الاستلام 11 يعني أن أول 10 بايتات قد اُستُلِمَت ويتوقع المُستقبِل إرسال القطعة التي تلي تلك البايتات؛ التبادل التالي ذو الرقم 260 يعني أن 250 بايتًا من البيانات قد أُرسِل، أي أن الرقم التسلسلي يمثِّل إزاحةً لها علاقة بالقطعة التي أُرسِلت في البداية. لاحظ أن المُرسِل والمُستقبِل يعلمان عن هذه المحادثة ويمكن أن يعتبرانها اتصالًا واحدًا بناءً على المنافذ المُستخدَمة في المصدر والوجهة. يُولَّد منفذ المصدر عشوائيًا وقت الاتصال، لكن يجب معرفة منفذ الوجهة مسبقًا، الذي يُعرِّف تطبيقًا معيّنًا، وهو Telnet في هذا الرسم التوضيحي: