القائمة الرئيسية

الصفحات

دورة CCNA 200-301 - الدرس العاشر (بروتوكلات TCP و UDP)

دورة CCNA 200-301 - الدرس العاشر (بروتوكلات TCP و UDP)

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

TCP_UDP


يعتبر كل من TCP و UDP بروتوكولات تعمل في طبقة النقل (لكل من نموذج OSI و TCP / IP) ولكن لماذا نحتاج إلى كلاهما؟ الجواب هو:
  • TCP أبطأ ولكنه موثوق
  • UDP أسرع ولكن غير موثوق به

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

ولكن كل شي بثمن ...

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

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

يمكن لـ TCP أيضًا إبطاء الإرسال إذا رأى أن المسار إلى الوجهة مزدحم للغاية. لا تريد أن يبطئ بروتوكول TCP صوتك في ساعات ازدحام حركة البيانات أيضًا. على سبيل المثال عندما تقول "مرحبًا ، كيف حالك؟" ، قد يسمع صديقك في الطرف الآخر "Hellooooo، …… hooooooooow arrrrrrrre yyyyyoou". انها محادثة فظيعة! اليس كذلك؟

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

حتى الآن لدينا الفهم الأساسي لـ TCP و UDP. في الجزء التالي سنتعلم المزيد عن TCP. لنبدأ بكيفية إعداد اتصال TCP وإنهاء الاتصال.

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

TCP_Three_way_handshake


  • سيرسل المضيف الأول A رسالة SYN (يتم تعيين مقطع TCP مع إشارة SYN إلى 1 ، SYN اختصار لـ SYNchronize) للإشارة إلى رغبته في إعداد اتصال مع المضيف B. تتضمن هذه الرسالة رقم تسلسلي (SEQ) لغرض تتبع الهدف. يمكن أن يكون رقم التسلسل هذا أي رقم من 32 بت (النطاق من 0 إلى 232) لذا نستخدم "x" لتمثيله.
  • بعد تلقي رسالة SYN من المضيف A ، يرد المضيف B برسالة SYN-ACK (قد تسميها بعض الكتب "SYN / ACK" أو رسالة "SYN، ACK". ACK اختصار لـ ACKnowledge). تتضمن هذه الرسالة رقم تسلسل SYN ورقم ACK:
    • رقم تسلسل SYN (لنطلق عليه "y") هو رقم عشوائي وليس له أي علاقة برقم SYN SEQ للمضيف A.
    • رقم ACK هو الرقم التالي لرقم تسلسل SYN للمضيف A الذي استلمه ، لذلك فإننا نمثله بـ "x + 1". هذا يعني "تلقيت الجزء الخاص بك. أرسل لي الآن الجزء التالي (x +1) ".

تشير رسالة SYN-ACK إلى موافقة المضيف B التحدث إلى المضيف A (عبر جزء الـ ACK). والتاكد إذا كان المضيف A لا يزال يريد التحدث إليه أيضًا (عبر جزء SYN).

  •  بعد استلام المضيف A لرسالة SYN-ACK من المضيف B ، يرسل رسالة ACK برقم ACK "y + 1" إلى المضيف B. هذا يؤكد أن المضيف A لا يزال يريد التحدث إلى المضيف B.


إذا كنت لا تزال لم تفهم العملية ، فلنخصص: x = 1 و y = 50:

TCP_Three_way_handshake_number_assigned


في هذه العملية ، يجب إرسال ثلاث رسائل ، لذلك نسميها غالبًا "مصافحة ثلاثية".

رائع ، الآن فهمت مصافحة TCP ثلاثية الأطراف ، أليس كذلك؟ يمكن للمضيف "أ" بدء إرسال حركة مرور حقيقية إلى المضيف "ب" بعد عملية المصافحة ثلاثية الاتجاهات.

يقوم TCP أيضًا بالشيء نفسه تقريبًا عندما يريد أحد الطرفين إنهاء الاتصال بعملية TCP ذات الأربع اتجاهات لإنهاء الاتصال.

إنهاء TCP رباعي الاتجاه (لإنهاء الاتصال)

TCP_Four_way_Termination


افترض أن المضيف A يريد إنهاء الاتصال بالمضيف B ، سيرسل المضيف A رسالة FIN (حزمة TCP مع تعيين FIN بالقيمة 1) ، FIN مختصر لـ FINISH. الغرض من رسالة FIN هو تمكين TCP من إنهاء اتصال مؤسس بأمان. ثم يدخل المضيف A حالة تسمى حالة FIN-WAIT. في حالة FIN-WAIT ، يستمر المضيف A في تلقي مقاطع TCP من المضيف B ويتابع الأجزاء الموجودة بالفعل في قائمة الانتظار ، ولكن المضيف A لن يرسل أي بيانات إضافية.

سيؤكد الجهاز B أنه تلقى رسالة FIN مع ACK (بتسلسل x + 1). من هذه النقطة ، لن يقبل المضيف B اي بيانات من المضيف أ. يمكن للمضيف ب الاستمرار في إرسال البيانات إلى المضيف أ. إذا لم يكن لدى المضيف ب بيانات أخرى لإرسالها ، فسيتم إنهاء الاتصال أيضًا عن طريق إرسال رسالة FIN. ثم يقوم المضيف أ بتاكيد قطع هذا الاتصال وإنهائه.

يتطلب بروتوكول TCP إنشاء الاتصال وإنهائه قبل وبعد تبادل حركة المرور الحقيقية ، لذا يطلق عليه اسم البروتوكول الموجه للاتصال. لا يدعم بروتوكول UDP هذه الميزات ، لذلك يطلق عليه بروتوكول بدون الاتصال.

يمكن تعريف هذه المصطلحات على النحو التالي:
  • بروتوكول موجه الاتصال: يتطلب إنشاء اتصال منطقي بين الطرفين قبل تبادل البيانات.
  • بروتوكول بدون اتصال: السماح بتبادل البيانات دون إنشاء اتصال.


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

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

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

أعلاه يتم حل السؤال باستخدام أرقام المنافذ. سيستخدم كل تطبيق رقم منفذ مختلف ومتاح للتواصل مع العالم الخارجي. على سبيل المثال ، يمكن لجهاز الكمبيوتر المحمول اختيار المنفذ 50000 لتصفح الويب ، والمنفذ 50001 للاتصال عبر البريد الإلكتروني ، والمنفذ 50002 لتحميل ملفات FTP.


TCP_Multiplexing_port_numbers


لاحظ أن الكمبيوتر الخاص بك يمكنه اختيار أي منفذ مصدر متاح ولكن يجب أن يستخدم منافذ وجهة محددة مسبقًا لخدمات معروفة. يتم تعريف أرقام المنافذ في ثلاثة نطاقات:

  • أرقام المنافذ المعروفة (من 0 إلى 1023): يتم تعيينها للخدمات الأساسية التي تقدمها الأنظمة.
  • أرقام المنافذ المسجلة (1024 إلى 49151): مخصصة للتطبيقات والعمليات الصناعية. على سبيل المثال: تم تعيين 1433 لعمليات Microsoft SQL Server.
  • أرقام المنافذ الديناميكية (49152 حتى 65535): تستخدم كمنافذ مؤقتة لاتصالات محددة. يمكن للكمبيوتر المحمول الخاص بنا استخدام هذه المنافذ للاتصال.


يسرد الجدول أدناه منافذ TCP للخدمات المعروفة:
TCP ServiceDescriptionPort
FTPFile Transfer Protocol20, 21
SSHSecure shell22
TelnetTerminal network23
SMTPSimple Mail Transfer Protocol25
DNSDomain Name Server53
HTTPHyper Text Transfer Protocol80
HTTPSHyper Text Transfer Protocol Secure443

ملاحظة: هناك بعض المنافذ المعروفة الأخرى غير مدرجة هنا. يتم تعيين المنافذ المعروفة من قبل هيئة أرقام الإنترنت المخصصة (IANA) في النطاق من 0 إلى 1023.

يعتمد تعدد الإرسال على مفهوم يسمى المقبس Socket. يتكون المقبس من ثلاثة أشياء:

  • عنوان IP
  • بروتوكول نقل
  •  رقم منفذ


لذا لنفترض أن عنوان IP جهاز الكمبيوتر المحمول الخاص بنا هو 123.1.1.1 ونستخدم بروتوكول TCP للوصول إلى خادم الويب بالمنفذ 50000 ، قد نكتب المقبس (123.1.1.1 ، TCP ، 50000). بالنسبة لتطبيق خادم الويب الذي يعمل على خادم الويب باستخدام الايبي 200.1.1.1 ، يجب أن يكون المقبس (200.1.1.1 ، TCP ، 80) حيث يستخدم خادم الويب المنفذ 80 المعروف لـ HTTP.

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

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


TCP_Source_Port_Destination_Port


ملاحظة: يستخدم كل من TCP و UDP تعدد الإرسال multiplexing مع أرقام المنافذ الخاصة بكل خدمة من خدماتهم.

التحكم في التدفق باستخدام النوافذ
يوجد في هيدر TCP حقل يسمى "Window" والذي يلعب دورًا مهمًا في إرسال TCP. تحدد "النافذة" عدد الأجزاء التي يمكن للمرسل إعادة توجيهها دون تلقي إقرار ACK. هذا هو المفتاح لنقل البيانات والتحكم في التدفق بكفاءة. دعنا نرى كيف يعمل!

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


TCP_Simple_Window_Sliding


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


TCP_Window_Sliding


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

حجم النافذة متغير خلال عمر الاتصال ، لذلك غالبًا ما نشير إليه على أنه "نافذة منزلقة" أو sliding window.


إذا لم يستلم المرسل ACK في الوقت المناسب ، فإنه يعلم أن اجزاء البيانات يجب أن يعاد ارسالها ، وأن معدل الإرسال يجب أن يتباطأ. أسفل. افترض أن المضيف "أ" لم يستلم ال ACK رقم 7 التي يتنظرها ، إذًا يعرف أن الأجزاء 4 و 5 و 6 يجب أن يعاد ارسالها.


TCP_Window_Sliding_error


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

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

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

في الإرسال أدناه ، يرسل المضيف A ثلاثة أجزاء 1 ، 2 ، 3 إلى المضيف B. يتم فقدان الجزء 2 بينما وصل الجزء 3 إلى المضيف B. ثم رد المضيف B مع ACK 2 ، مما يعني أنه يتوقع الجزء 2 التالي. يمكن للمضيف A إعادة إرسال الجزء رقم 2 لاسترداد الجزء المفقود. إذا تلقى المضيف ب ذلك الجزء، فسيطلب الجزء رقم 4 (لأنه تلقى بالفعل الجزء رقم 3).


TCP_Error_Recovery خطأ الاسترداد


قد تسأل "ماذا سيحدث إذا فقدت ACK 2 المرسلة من المضيف B أيضًا؟" في الواقع ، بعد إرسال كل قطعة ، يقوم المضيف أ بتعيين موقت إعادة الإرسال ، فقط في حالة فقد ACK (أو في حالة فقدان جميع مقاطع الإرسال ؛ لن يرسل المضيف ب ACK في هذه الحالة لأنه لم يتلق أي شيء). إذا انتهت صلاحية هذا المؤقت ، سيرسل المضيف أ جميع الأجزاء مرة أخرى.

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

نقاط التشابه:

  • يعمل كل من TCP و UDP في طبقة النقل
  • يستخدم كل من TCP و UDP تعدد الإرسال عبر أرقام المنافذ


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




أخيرًا ، نعرض هيدر TCP و UDP بالتفصيل كمرجع لك. هناك بعض الحقول التي تقع خارج نطاق هذا الدرس.


رأس TCP 20 بايت


لاحظ حقول FLAG (بين الحقلين "Reserved" و "Window Size"). إذا تم تشغيل بت SYN ، فهي رسالة SYN. إذا تم تشغيل بت ACK ، فهي رسالة ACK. إذا تم تشغيل كل من بت SYN و ACK ، فهي رسالة SYN-ACK.

وهذا هو هيدر UDP:
رأس UDP_header (8 بايت)

آمل أن يكون هذا الدرس مفيدًا . إذا كان لديك أي أسئلة ، فلا تتردد في ترك تعليق هنا.

reaction:

تعليقات