تعني إعادة إرسال TCP إعادة إرسال الحزم المفقودة أو التالفة عبر الشبكة. هنا، إعادة الإرسال هي آلية تستخدمها بروتوكولات مثل برنامج التعاون الفني لتوفير اتصالات موثوقة. هنا، يعني الاتصال الموثوق به أن البروتوكول يضمن تسليم الحزمة حتى في حالة فقدان حزمة البيانات أو تلفها.
ما هو الفرق بين الميجابايت والجيجابايت
الشبكات غير موثوقة ولا تضمن تأخير أو إعادة إرسال الحزم المفقودة أو التالفة. توفر الشبكة التي تستخدم مزيجًا من الإقرار وإعادة إرسال الحزم التالفة أو المفقودة الموثوقية.
آلية إعادة الإرسال
هنا، تعني إعادة الإرسال فقدان حزم البيانات، مما يؤدي إلى عدم الإقرار بالاستلام. يؤدي هذا النقص في الإقرار إلى تشغيل مؤقت لانتهاء المهلة، مما يؤدي إلى إعادة إرسال حزم البيانات. هنا، يعني المؤقت أنه إذا لم يتم تلقي أي إقرار قبل انتهاء صلاحية المؤقت، فسيتم إعادة إرسال حزمة البيانات.
دعونا نفكر في السيناريوهات التالية لإعادة الإرسال.
السيناريو 1: عند فقدان حزمة البيانات أو وجود خطأ فيها.
في هذا السيناريو، يتم إرسال الحزمة إلى المتلقي، ولكن لم يتم تلقي أي إقرار خلال فترة المهلة تلك. عند انتهاء فترة المهلة، تتم إعادة إرسال الحزمة مرة أخرى. عند إعادة إرسال الحزمة، يتم تلقي الإقرار. بمجرد استلام الإقرار، لن تتم إعادة الإرسال مرة أخرى.
السيناريو 2: عند استلام الحزمة ولكن يتم فقدان الإقرار.
في هذا السيناريو، يتم استلام الحزمة على الجانب الآخر، ولكن يتم فقدان الإقرار، أي لم يتم استلام ACK على جانب المرسل. بمجرد انتهاء فترة المهلة، تتم إعادة إرسال الحزمة. توجد نسختان من الحزم على الجانب الآخر؛ على الرغم من استلام الحزمة بشكل صحيح، لم يتم استلام الإقرار، لذلك يقوم المرسل بإعادة إرسال الحزمة. في هذه الحالة، كان من الممكن تجنب إعادة الإرسال، ولكن بسبب فقدان ACK، يتم إعادة إرسال الحزمة.
السيناريو 3: عند حدوث المهلة المبكرة.
في هذا السيناريو، يتم إرسال الحزمة، ولكن بسبب التأخير في الإقرار أو انتهاء المهلة قبل انتهاء المهلة الفعلية، تتم إعادة إرسال الحزمة. في هذه الحالة، تم إرسال الحزمة مرة أخرى دون داع بسبب التأخير في الإقرار أو تم تعيين المهلة قبل المهلة الفعلية.
في السيناريوهات المذكورة أعلاه، لا يمكن تجنب السيناريو الأول، ولكن يمكن تجنب السيناريوهين الآخرين. دعونا نرى كيف يمكننا تجنب هذه المواقف.
كم من الوقت يجب أن ينتظر المرسل؟
يقوم المرسل بتعيين فترة المهلة لـ ACK. يمكن أن تكون فترة المهلة من نوعين:
سلسلة تقسيم باش
ومن أجل التغلب على الحالتين المذكورتين أعلاه، برنامج التعاون الفني يضبط المهلة كدالة لـ RTT (وقت الرحلة ذهابًا وإيابًا) حيث يكون وقت الرحلة ذهابًا وإيابًا هو الوقت المطلوب لانتقال الحزمة من المصدر إلى الوجهة ثم العودة مرة أخرى.
كيف يمكننا الحصول على RTT؟
يمكن أن يختلف وقت الإرسال والاستقبال (RTT) وفقًا لخصائص الشبكة، أي إذا كانت الشبكة مزدحمة، فهذا يعني أن وقت الإرسال والاستقبال (RTT) مرتفع جدًا. يمكننا تقدير RTT بمجرد مشاهدة ACKs.
دعونا نرى كيف يمكننا قياس RTT.
سوف نستخدم الخوارزمية الأصلية لقياس RTT.
الخطوة 1: أولا، نقوم بقياس سامبلرتت لكل قطعة أو زوج ACK. عندما يرسل المرسل الحزمة، فإننا نعرف المؤقت الذي تم إرسال الحزمة فيه، ونعرف أيضًا المؤقت الذي يتم فيه استلام الإقرار. احسب الوقت بين هذين، ويصبح سامبلرتت .
الخطوة 2: لن نأخذ عينة واحدة فقط سنستمر في أخذ عينات مختلفة وحساب المتوسط المرجح لهذه العينات، ويصبح هذا هو EstRTT (RTT المقدر).
حيث α+ β = 1
α يقع بين 0.8 و 0.9
β تقع بين 0.1 و 0.2
الخطوه 3: يتم تعيين المهلة بناءً على EstRTT.
المهلة = 2 * EstRTT.
كيفية تحويل السلسلة إلى int جافا
تم ضبط المهلة على ضعف مدة RTT المقدرة. هذه هي الطريقة التي يتم بها حساب عامل المهلة الفعلي.
عيب في هذا النهج
هناك خلل في الخوارزمية الأصلية. دعونا نفكر في سيناريوهين.
السيناريو 1.
يوضح الرسم البياني أعلاه أن المرسل يرسل البيانات، والتي يقال إنها إرسال أصلي. خلال فترة المهلة، لم يتم تلقي أي إقرار. لذلك، يقوم المرسل بإعادة إرسال البيانات. بعد إعادة إرسال البيانات، يتم استلام الإقرار. لنفترض أنه تم استلام الإقرار للإرسال الأصلي، وليس لإعادة الإرسال. منذ أن حصلنا على إقرار بالإرسال الأصلي، لذلك سامبلرتت يتم حسابه بين وقت الإرسال الأصلي ووقت استلام الإقرار. ولكن في الواقع، سامبلرتت يجب أن يكون بين وقت إعادة الإرسال ووقت الإقرار.
السيناريو 2.
يوضح الرسم البياني أعلاه أن المرسل يرسل حزمة البيانات الأصلية التي نحصل على الإقرار بها أيضًا. ولكن يتم استلام الإقرار بعد إعادة إرسال البيانات. فإذا افترضنا أن الإقرار ينتمي إلى إعادة الإرسال، إذن سامبلرتت يتم حسابه بين وقت إعادة الإرسال ووقت الإقرار.
في كلا السيناريوهين أعلاه، هناك غموض في عدم معرفة ما إذا كان الإقرار للإرسال الأصلي أم لإعادة الإرسال.
اختتام الخوارزمية المذكورة أعلاه.
- هنا، لا يعني ACK الإقرار بالإرسال، ولكنه في الواقع يقر باستلام البيانات.
- إذا أخذنا في الاعتبار السيناريو الأول، فسيتم إجراء إعادة الإرسال للحزمة المفقودة. في هذه الحالة، نفترض أن ACK ينتمي إلى الإرسال الأصلي الذي بسببه أصبح SampleRTT كبيرًا جدًا.
- إذا أخذنا في الاعتبار السيناريو الثاني، فسيتم إرسال حزمتين متماثلتين، وبالتالي يحدث الازدواجية في هذه الحالة. في هذه الحالة، نفترض أن ACK ينتمي إلى عملية إعادة الإرسال التي بسببها أصبح SampleRTT صغيرًا جدًا.
للتغلب على المشاكل المذكورة أعلاه، يتم تقديم حل بسيط من خلال خوارزمية Karn/Partridge. أعطت هذه الخوارزمية حلاً بسيطًا يجمع العينات المرسلة في وقت واحد ولا يأخذ العينات في وقت إعادة الإرسال في الاعتبار لحساب RTT المقدرة.
خوارزمية كارن/بارتريدج
في السيناريوهين المذكورين أعلاه، تحدث إعادة الإرسال، وقد أخذنا بعين الاعتبار عينة RTT. لكن هذه الخوارزمية لا تأخذ بعين الاعتبار عينة RTT عند إعادة الإرسال. منذ حدوث إعادة الإرسال، مما يعني حدوث شيء ما في وقت الذهاب والإياب هذا أو قد يحدث بعض الازدحام في الشبكة. للتغلب على هذه المشكلة، تقوم هذه الخوارزمية بمضاعفة المهلة بعد كل عملية إعادة إرسال. يتم تنفيذ هذه الخوارزمية في شبكة TCP.
القيد
لا يأخذ في الاعتبار التباين في RTT.
للتغلب على القيد المذكور أعلاه، تم تطوير خوارزمية جاكوبسون/كاريلس التي تقدم عامل التباين في RTT.
خوارزمية جاكوبسون/كاريلز
مؤشر سلسلة جافا
تم تطوير هذه الخوارزمية للتغلب على قيود كارن / الحجل خوارزمية. فهو يحسب الفرق بين SampleRTT وAccedRTT، ويعزز RTT بناءً على الفرق.
حسابات متوسط RTT
- أولا، نحسب عامل الفرق.
فرق = SampleRTT - المقدرة RTT
- الآن، نقوم بحساب RTT المقدرة، والتي سيتم حسابها بنفس الطريقة التي قمنا بها أعلاه.
EstRTT = EstRTT + (δ*Diff)
- الآن، نحسب متوسط عامل الفرق.
Dev = Dev + δ ( |Diff| - Dev)
تعليم مارك زوكربيرج
هنا، Dev هو عامل الانحراف، وδ هو عامل بين 0 و1 ديف هو تقدير التباين من إسترت .
- سننظر في التباين أثناء حساب قيمة المهلة.
أين، μ = 1 و ɸ = 4
إعادة الإرسال السريع
استراتيجية المستندة إلى المهلة لإعادة الإرسال غير فعالة. TCP هو نوع من البروتوكولات ذات النافذة المنزلقة، لذا كلما حدثت إعادة الإرسال، فإنه يبدأ في إرسالها من الحزمة المفقودة فصاعدًا.
لنفترض أنني قمت بنقل الحزم 0 و1 و2 و3. وبما أنه تم استلام الحزمة 0 والحزمة 1 على الجانب الآخر، فسيتم فقدان الحزمة 2 في الشبكة. لقد تلقيت إقرارًا بالحزمة 0 والحزمة 1، لذا أرسل حزمتين إضافيتين، أي الحزمة 4 والحزمة 5. عند إرسال الحزم 3 و4 و5، سأحصل على إقرار الحزمة 1 كإقرارات TCP تراكمية، لذا فهي تعترف بالحزمة التي استلمتها بالترتيب. لم أتلق إقرارًا بالحزمة 2 و3 و4 و5 خلال فترة المهلة، لذلك أعيد إرسال الحزم 2 و3 و4 و5. نظرًا لفقد الحزمة 2، ولكن الحزم الأخرى، أي 3 و4 ،5 يتم استقبالها على الجانب الآخر، ولا يزال يتم إعادة إرسالها بسبب آلية المهلة هذه.
كيف يمكن إزالة عدم كفاءة المهلة هذه؟
الحل الأفضل تحت نافذة منزلقة:
لنفترض أن الحزمة n قد فقدت، ولكن لا يزال يتم استلام الحزم n+1 وn+2 وما إلى ذلك. يستقبل جهاز الاستقبال الحزم باستمرار ويرسل حزم ACK مشيرًا إلى أن جهاز الاستقبال لا يزال ينتظر الحزمة n. يرسل المتلقي إقرارات متكررة أو مكررة. في الحالة المذكورة أعلاه، يتم إرسال ACK للحزمة 1 ثلاث مرات نظرًا لفقدان الحزمة 2. تعد حزمة ACK المكررة هذه إشارة إلى أن الحزمة n مفقودة، ولكن تم استلام الحزم الأحدث.
يمكن حل الوضع أعلاه بالطرق التالية:
- يمكن للمرسل أن يأخذ 'الإقرارات المكررة' كإشارة مبكرة إلى فقدان الحزمة n حتى يتمكن المرسل من إعادة الإرسال في أقرب وقت ممكن، أي يجب ألا ينتظر المرسل حتى انتهاء المهلة.
- يمكن للمرسل تنفيذ استراتيجية إرسال سريع في TCP. في استراتيجية الإرسال السريع، يجب على المرسل اعتبار الـ ACKs المكررة الثلاثية بمثابة مشغل وإعادة إرسالها.
يستخدم TCP ثلاثة ACKs مكررة كمشغل ثم يقوم بإعادة الإرسال. في الحالة المذكورة أعلاه، عند تلقي ثلاثة ACKs من الحزمة 1، يجب على المرسل إرسال الحزمة المفقودة، أي الحزمة 2، دون انتظار حدوث فترة المهلة.