icnd1/ccent 100-101 طبقة النقل في بروتوكول TCP/IP


عبد اللطيف ايمش

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

transport-layer.thumb.png.fd0673c9c3202f

يتوفَّر بروتوكولان في طبقة النقل هما: 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.

6-1.thumb.jpg.c2a7955231dabc78b05321a390

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

6-2.thumb.jpg.f21aa9fba1c912d8e890d876ab

وبشكلٍ مشابه، سيحتاج بروتوكولَيّ 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) وراية الإشعار. وتُستخدَم أيضًا الأرقام التسلسلية لإشعار استلام السلسلة التالية من البتات؛ يُنشَأ الاتصال بشكل كامل عندما يُرسَل الإشعار النهائي من المستلم؛ بت التحكم المُستخدم في الإشعار النهائي هو راية الإشعار فقط. وهذا يُشبِه محادثة الهاتف حيث نبدأ المحادثة بقول «مرحبًا» ويُرَدُّ علينا بالجملة «أهلًا، أنا هنا» ثم سيقول المُرسِل «حسنًا، لقد أنشَأنا الاتصال، لنبدأ التحدث».

6-3.thumb.jpg.a335c84ea18efd5eddd97713f8

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

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

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

6-4.thumb.jpg.28ef3eb7803581c9d00616240c

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

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

6-5.thumb.jpg.914c3b9b41b9d3383445251635

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

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

6-6.thumb.jpg.a85f1ab5b7f4f914fb86d91137

ترجمة -وبتصرّف- للمقال Understanding The TCP/IP Transport Layer.





تفاعل الأعضاء


لا توجد أيّة تعليقات بعد



يجب أن تكون عضوًا لدينا لتتمكّن من التعليق

انشاء حساب جديد

يستغرق التسجيل بضع ثوان فقط


سجّل حسابًا جديدًا

تسجيل الدخول

تملك حسابا مسجّلا بالفعل؟


سجّل دخولك الآن