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

الصفحات

دورة CCNA 200-301 - الدرس الثاني عشر (TCP Window Size Scaling)

دورة CCNA 200-301 - الدرس الثاني عشر (TCP Window Size Scaling)

دورة CCNA 200-301 - الدرس الثاني عشر (TCP Window Size Scaling)
TCP (بروتوكول التحكم في الإرسال) هو بروتوكول موجه للاتصال مما يعني أننا نتتبع مقدار البيانات التي تم إرسالها. سيرسل المرسل بعض البيانات ويجب على المستلم أن يقر بها. عندما لا نتلقى الإقرار في الوقت المناسب ، يقوم المرسل بإعادة إرسال البيانات.

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

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

عادةً ما يبدأ اتصال TCP بحجم نافذة صغير وفي كل مرة يكون هناك إقرار ناجح ، سيزداد حجم النافذة. إليك مثال:

حجم نافذة TCP 1


أعلاه لدينا مضيفين ، سيرسل المضيف على الجانب الأيسر مقطعًا واحدًا ويرسل المضيف على الجانب الأيمن إقرارًا في المقابل. نظرًا لنجاح الإقرار ، سيزداد حجم النوافذ:

حجم نافذة برنامج التعاون الفني 2


يرسل المضيف على الجانب الأيسر الآن جزأين وسيعيد المضيف على الجانب الأيمن إقرارًا واحدًا. كل شيء يعمل على ما يرام لذا فإن حجم النافذة سيزيد أكثر:

حجم نافذة TCP 4


يرسل المضيف الآن أربعة أجزاء ويستجيب المضيف على الجانب الأيمن بإقرار واحد.

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

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

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

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

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

التزامن العالمي لـ TCP


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

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

لمنع المزامنة الشاملة ، يمكننا استخدام RED (الاكتشاف المبكر العشوائي). هذه ميزة تسقط الحزم "العشوائية" من تدفقات بروتوكول TCP بناءً على عدد الحزم في قائمة الانتظار والعلامة TOS (نوع الخدمة) للحزم. عندما يتم إسقاط الحزم قبل امتلاء قائمة الانتظار ، يمكننا تجنب المزامنة العامة.

ستبدو النتيجة النهائية مشابهة لهذه:

التزامن العالمي لـ TCP


عندما نستخدم RED ، سيتحسن متوسط ​​استخدام الوصلة.

الآن لديك فكرة عن حجم نافذة TCP ، دعنا نلقي نظرة على مثال حقيقي لكيفية استخدام حجم النافذة. يمكننا استخدام wireshark لهذا الغرض.

التقاطات Wireshark
لفحص حجم نافذة TCP ، سأستخدم جهازين:

استضافة التوت بي


الجهاز الموجود على الجانب الأيسر هو جهاز كمبيوتر حديث مزود بوصلة gigabit. على الجانب الأيمن ، لدينا جهاز raspberry pi صغير له وصلة FastEthernet. إن raspberry pi  هو جهاز صغير رائع ولكن وصلة وحدة المعالجة المركزية / الذاكرة / الإيثرنت محدودة. للحصول على مخرجات نريدها ، سأقوم بنسخ ملف كبير من خلال SSH من جهاز الكمبيوتر الخاص بي إلى raspberry pi والذي سيتم تحميله بسهولة.

إليك ما يحدث ، ألق نظرة على هذه الصورة:

الرسوم البيانية Wireshark IO انخفاض حجم النافذة


في الرسم البياني أعلاه ، يمكنك رؤية حجم النافذة الذي تم استخدامه أثناء هذا الاتصال. بدأ نقل الملفات بعد حوالي 6 ثوانٍ ويمكنك أن ترى أن حجم النافذة زاد بسرعة. ارتفعت قليلاً وهبطت قليلاً ولكن في حوالي 30 ثانية ، انهارت تماماً. بعد بضع ثوانٍ زادت مرة أخرى وتمكنت من إكمال نقل الملف. دعونا نلقي نظرة فاحصة على نقل الملفات هذا ، والذي يبدأ بمصافحة ثلاثية:

يلتقط Wireshark حجم إطار TCP SYN ACK


يستخدم جهاز الكمبيوتر السريع الخاص بي الايبي 10.56.100.1 ويستخدم raspberry pi الايبي 10.56.100.164. أعلاه يمكنك أن ترى أنه في رسالة SYN/ACK بأن raspberry pi يريد استخدام حجم نافذة 29200. جهاز الكمبيوتر الخاص بي يريد استخدام حجم نافذة 8388480 (win = 65535 * ws = 128) وهو غير ذي صلة الآن لأننا نرسل البيانات إلى raspberry pi.

بعد عدد قليل من الحزم ، يبدو حجم نافذة raspberry pi كما يلي:

Wireshark Capture TCP SYN ACK حجم النافذة كبير


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

عند حوالي 10 ثوانٍ ، انخفض حجم النافذة. إليك ما حدث:

Wireshark Capture TCP Window Full


يبدو أن raspberry pi يواجه صعوبة في مواكبة ذلك وقد يكون مخزن الاستلام ممتلئًا على الأرجح. ويقوم باخبار الكمبيوتر أن يستخدم نافذة بحجم 26752 من الآن فصاعدًا. يرسل الكمبيوتر 18 قطعة مع 1460 بايت ومقطع واحد من 472 بايت (إجمالي 26752 بايت). تظهر لنا الحزمة الأخيرة رسالة "TCP Window Full". هذا شيء يبلغنا عنه wireshark ، لقد ملأ جهاز الكمبيوتر الخاص بنا تمامًا المخزن المؤقت للاستلام لدى الـ raspberry pi.

بمجرد أن يلتقط raspberry pi حوالي 30 ثانية ، يحدث شيء سيئ. ألق نظرة على لقطة Wireshark أدناه:

Wireshark التقاط نافذة TCP صفر


أعلاه يمكنك أن ترى أن raspberry pi يرسل ACK إلى الكمبيوتر بحجم نافذة 0. وهذا يعني أن حجم النافذة سيظل عند 0 لفترة محددة من الوقت ، فإن raspberry pi غير قادر على استقبال أي بيانات أخرى في هذا اللحظة وسيتم إيقاف إرسال TCP مؤقتًا لفترة بينما تتم معالجة المخزن المؤقت للاستقبال.

إليك الحزمة الفعلية:

Wireshark Capture TCP Window Zero Packet


أعلاه يمكنك أن ترى أن حجم النافذة الآن هو 0. بمجرد معالجة المخزن المؤقت للاستلام ، سيرسل ACK  raspberry pi بحجم نافذة جديد:

حجم نافذة Wireshark بعد صفر


يبلغ حجم النافذة الآن 25600 بايت فقط ولكنها ستنمو مرة أخرى. وسيستمر الإرسال المتبقي دون أي مشاكل وسيكتمل نقل الملف.

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


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

آمل أن تكون قد استمتعت بهذا الدرس ، إذا كان لديك أي أسئلة أخرى فلا تتردد في ترك تعليق هنا.
reaction:

تعليقات