فهم حدود إنتاجية بروتوكول TCP
تحدد ظروف مسار الشبكة السقف الفعلي لأداء تدفق TCP فردي. لا تعتمد السرعة الحقيقية لنقل البيانات على النطاق الترددي المتاح فحسب، بل تتأثر بشكل مباشر بزمن الانتقال (وقت الذهاب والإياب) وحجم نافذة الاستقبال وفقدان الحزم. يقوم نظام الحساب هنا بتحديد السقف الأقل من بين ثلاثة حدود مستقلة وموازنتها لتحديد الأداء المتوقع.
يعمل هذا النموذج الحسابي على افتراض تدفق TCP واحد في الحالة المستقرة. يجب الأخذ في الاعتبار أن عوامل الواقع العملي مثل مرحلة البداية البطيئة (TCP slow start)، وضبط خوارزميات التحكم في الاحتقان، وبطء استجابة الطرف المستقبل، ومصافحات بروتوكول TLS تقع خارج نطاق هذا النموذج، مما يجعل عمليات النقل الحقيقية تبدأ بشكل أبطأ وقد تسجل أداءً يقل عن السقوف المحسوبة.
معلمات المسار والشبكة المدخلة
لإجراء الحسابات بدقة، يتطلب النموذج تزويده بالمعلومات الأساسية التالية التي تصف المسار الفيزيائي ومعلمات البروتوكول:
- معدل الرابط: يمثل أبطأ قفزة على المسار، وهي غالباً السرعة المحددة في خطتك الاشتراكية. يجب أن تكون هذه القيمة أكبر من الصفر.
- وقت الذهاب والإياب (RTT): وهو وقت البينج إلى الطرف البعيد، ويُفضل استخدام أكبر قيمة تتوقعها تحت الضغط الفعلي للشبكة. يجب أن تكون القيمة أكبر من الصفر.
- حجم البيانات: حجم الحمولة النافعة المراد نقلها، مثل ملف أو نسخة احتياطية أو مجموعة بيانات. يجب أن تكون القيمة أكبر من الصفر.
- نافذة الاستقبال: كمية البايتات التي يمكن للمستقبل تخزينها مؤقتاً. القيمة 65,535 بايت هي الحد الأقصى غير المقاس، وترك هذا الحقل فارغاً يعني عدم وجود حد للنافذة. يجب أن تكون القيمة أكبر من الصفر ولا تتجاوز 1,073,725,440 بايت.
- MSS (بايت): أقصى حجم للجزء، وهو يمثل بايتات الحمولة النافعة لكل حزمة (القيمة 1,460 تملأ إطار Ethernet قياسي). ترك الحقل فارغاً يتجاهل العبء الإضافي والفقدان. يجب أن يكون عدداً صحيحاً بين 1 و65,495.
- فقدان الحزم (%): متوسط احتمال فقدان الحزم على المسار. ترك الحقل فارغاً أو وضع القيمة 0 يعني عدم وجود حد للفقدان. يجب أن تكون القيمة بين 0 و100 بالمئة.
- الكسور العشرية المعروضة: للتحكم في دقة عرض الأرقام والنتائج.
يوفر البرنامج زراً مخصصاً لـ تحميل مثال لتعبئة الحقول تلقائياً ببيانات افتراضية، وزر مسح لإعادة تعيين كافة المدخلات.
مخرجات الحسابات والنتائج التفصيلية
تظهر النتائج مقسمة عبر أقسام رئيسية لتوضيح الأداء وعنق الزجاجة النشط:
الإنتاجية ووقت النقل
- إنتاجية TCP المتوقعة: القيمة الكلية المتوقعة للإنتاجية، وتظهر مصحوبة بعبارة توضح عنق الزجاجة النشط: "محدودة بـ
‹constraint›"، حيث يتم تحديد القيد ديناميكياً بناءً على الحسابات ليكون إما سعة الرابط، أو نافذة الاستقبال، أو فقدان الحزم. - وقت النقل.
- الوقت حتى البايت الأول (1 RTT).
- وقت نقل البيانات الضخمة.
- حاصل ضرب النطاق الترددي والتأخير.
- النافذة المطلوبة لملء المسار.
- الإنتاجية المحدودة بالنافذة.
- الإنتاجية المحدودة بالفقدان (Mathis).
- سقف الرابط بعد العبء الإضافي.
- كفاءة البروتوكول.
ملاحظات النظام الديناميكية
تظهر رسائل تنبيهية بناءً على القيم المدخلة لتوضيح قيود البروتوكول:
- عند الحاجة لتوسيع النافذة: "يتطلب ملء هذا المسار نافذة
‹window›— وهي أعلى من الحد الأقصى غير المقاس البالغ 65,535 بايت، لذا يجب على كلا الطرفين التفاوض على مقياس نافذة TCP (RFC 7323).". - عند تجاوز الحد الأقصى المطلق للنافذة: "يتطلب ملء هذا المسار
‹window›— وهو ما يتجاوز أكبر نافذة يمكن لـ TCP التفاوض عليها (1,073,725,440 بايت). لا يمكن لتدفق واحد على هذا المسار أن يتجاوز‹value›أبداً.". - لتحسين الأداء عبر تعديل النافذة: "إن رفع نافذة الاستقبال إلى
‹window›سيسمح لعملية النقل هذه بالوصول إلى ما يصل إلى‹value›.". - عند ارتفاع معدل الفقدان: "الفقدان الذي يزيد عن 1% يقع خارج النطاق الموثوق لنموذج Mathis — تعامل مع سقف الفقدان كتقدير متفائل.".
الصيغ الرياضية والتعويض المباشر
يعتمد البرنامج على مجموعة من المعادلات الرياضية لحساب السقوف المختلفة ومقارنتها:
- الصيغة العامة: الإنتاجية = min(المعدل × الكفاءة، النافذة ÷ RTT، MSS ÷ RTT ÷ √p) · BDP = المعدل × RTT
- كفاءة البروتوكول:
كفاءة البروتوكول = MSS ÷ (MSS + 78 B) =
‹mss›÷‹frame›=‹eff›(رؤوس حزم 40 B + 38 B على السلك) - سقف الرابط:
سقف الرابط = المعدل × الكفاءة =
‹rate›×‹eff›=‹value› - حاصل ضرب النطاق الترددي والتأخير (BDP):
BDP = المعدل × RTT =
‹rate›×‹rtt›=‹bdp›=‹bytes› - النافذة المطلوبة لملء المسار:
النافذة لملء المسار = BDP ÷ 8 =
‹bdp›←‹window› - سقف النافذة:
سقف النافذة = النافذة ÷ RTT =
‹window›÷‹rtt›=‹value› - سقف الفقدان (Mathis):
سقف الفقدان (Mathis) = MSS ÷ RTT ÷ √p =
‹mss›÷‹rtt›÷ √‹p›=‹value› - الإنتاجية المتوقعة:
الإنتاجية المتوقعة = الحد الأدنى من هذه السقوف =
‹value›← محدودة بـ‹constraint› - وقت النقل:
وقت النقل = RTT + 8 × الحجم ÷ الإنتاجية =
‹rtt›+ 8 ׋size›÷‹throughput›=‹time›
يمكن نسخ كافة البيانات المحسوبة مباشرة باستخدام زر نسخ النتيجة.
قواعد الحساب والحالات الاستثنائية
- اتفاقيات الوحدات: جميع الوحدات المستخدمة في الحسابات عشرية الأساس (على سبيل المثال: 1 kbit يعادل 1,000 بت، و1 MB يعادل 1,000,000 بايت). تختلف هذه الوحدات عن الأنظمة الثنائية القائمة على 1024 والتي تستخدمها برامج إدارة الملفات عادةً (حيث يكون ملف بحجم "100 MB" في الواقع هو 100 MiB، أي ما يقارب 104.86 ميجابايت عشري).
- حسابات العبء الإضافي: يتم احتساب العبء الإضافي للبروتوكول بناءً على معيار Ethernet القياسي، حيث يضاف 78 بايت لكل حزمة (40 بايت لرؤوس حزم TCP/IP و38 بايت كعبء فيزيائي على السلك).
- حدود نموذج Mathis: يفترض نموذج Mathis لفقدان الحزم وجود فقدان مستقل وموزع بالتساوي. هذا النموذج دقيق وموثوق فقط عندما تكون معدلات الفقدان أقل من 1% تقريباً. إذا تجاوز الفقدان هذه النسبة، تظهر رسالة التنبيه للإشارة إلى أن سقف الفقدان المحسوب يعد تقديراً متفائلاً.
- حدود مقياس النافذة: الحد الأقصى للنافذة غير المقاسة هو 65,535 بايت. إذا تطلب المسار نافذة أكبر لملئه، يجب تفعيل مقياس نافذة TCP وفقاً للمعيار RFC 7323. الحد الأقصى المطلق الذي يمكن لـ TCP التفاوض عليه باستخدام هذا المقياس هو 1,073,725,440 بايت، وأي تجاوز لهذا الحد سيؤدي إلى تقييد التدفق الفردي بشكل دائم.
معالجة البيانات والخصوصية
يتم حساب كل قيمة تدخلها في هذا المتصفح محلياً بالكامل — لا يتم إرسال أي شيء إلى أي مكان. تضمن هذه الآلية معالجة البيانات مباشرة داخل جهازك دون رفع أي مدخلات إلى خوادم خارجية.
الأسئلة الشائعة
س: ما هو حاصل ضرب النطاق الترددي والتأخير، ولماذا يحدد حجم النافذة؟
ج: إن BDP — معدل الرابط × وقت الذهاب والإياب — هو كمية البيانات قيد النقل في أي لحظة. يمكن لـ TCP أن يمتلك نافذة واحدة غير مؤكدة معلقة كحد أقصى، لذا فإن النافذة الأصغر من BDP تترك الأنبوب فارغاً جزئياً: عند سرعة 100 Mbit/s مع RTT يبلغ 50 ms، يتسع الأنبوب لـ 625 kB، ونافذة بحجم 65,535 بايت تملأ بالكاد عُشره. لهذا السبب تحتاج المسارات السريعة والطويلة إلى مقياس نافذة TCP (RFC 7323)، والذي يرفع الحد الأقصى القابل للتفاوض من 65,535 بايت إلى حوالي 1 GB.
س: لماذا يعد نقلي أبطأ من معدل الرابط الذي أدفع ثمنه؟
ج: يواجه تدفق TCP الفردي ثلاثة سقوف مستقلة، والحد الأدنى بينها هو الذي يفرض نفسه. يقلل العبء الإضافي للبروتوكول من الرابط نفسه بنسبة 5% تقريباً — حيث يحمل إطار Ethernet القياسي 1,460 بايت من الحمولة النافعة من أصل 1,538 بايت على السلك. وتضع نافذة الاستقبال حداً أقصى للإنتاجية عند window ÷ RTT، لذا فإن النافذة الكلاسيكية البالغة 65,535 بايت تحد من مسار 50 ms إلى حوالي 10.5 Mbit/s مهما كانت سرعة الرابط. ويحد الفقدان من الإنتاجية عند (MSS ÷ RTT) ÷ √loss. وتوضح النتيجة أعلاه أي السقوف هو الذي يقيد أرقامك.
س: كيف يحد فقدان الحزم من إنتاجية TCP؟
ج: يتعامل TCP مع الفقدان كاحتقان وينصف معدل الإرسال الخاص به عند كل حدث فقدان، لذا فإن معدلات الفقدان الضئيلة تؤثر بشكل كبير على المسارات السريعة. يقدر نموذج Mathis السقف بـ (MSS ÷ RTT) ÷ √p — عند فقدان بنسبة 0.01% على مسار 50 ms مع MSS يبلغ 1,460 بايت، يكون ذلك حوالي 23 Mbit/s، بغض النظر عن سرعة الرابط. يفترض النموذج أحداث فقدان مستقلة وموزعة بالتساوي؛ وتحت نسبة 1% تقريباً، فإنه يتطابق مع الواقع بشكل جيد، بينما يكون متفائلاً في حالات الفقدان المتتابع.
س: هل الميجابايت هنا هي نفسها الموجودة في مدير الملفات الخاص بي؟
ج: ليس تماماً. تستخدم هذه الصفحة الوحدات العشرية، وهي العرف المتبع في الشبكات: 1 kbit = 1,000 bits و1 MB = 1,000,000 بايت. تحسب معظم برامج إدارة الملفات بوحدات تعتمد على 1024، وغالباً ما تُسمى خطأً MB — فملف بحجم "100 MB" هناك هو عادةً 100 MiB ≈ 104.86 MB عشري، لذا يستغرق نقله وقتاً أطول بنسبة 5% تقريباً مما يشير إليه الرقم العشري. أدخل 104.86 MB هنا لمطابقته تماماً.