Bandwidth وThroughput وLatency: الفرق وكيف تحسب زمن نقل البيانات

Bandwidth وThroughput وLatency ليست أسماء مختلفة لسرعة الإنترنت. كل مصطلح يقيس جانبًا مختلفًا من أداء الشبكة: Bandwidth يصف السعة، وThroughput يصف المعدل الذي يتحقق فعليًا، وGoodput يركز على بيانات التطبيق المفيدة، بينما Latency تقيس الزمن الذي تستغرقه البيانات أثناء الانتقال.

هذا الفرق مهم عند تحليل شبكة منزلية أو رابط Ethernet أو اتصال Wi-Fi أو حتى مسار عبر الإنترنت. فقد تمتلك رابطًا بسرعة اسمية 1 Gb/s، ومع ذلك يكون تحميل ملف بطيئًا بسبب الكمون أو فقد الحزم أو الازدحام أو الخادم نفسه.

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

الفرق بين Bandwidth وThroughput وGoodput وLatency

المصطلح	ماذا يقيس؟	وحدة شائعة	مثال
Bandwidth / Capacity	السعة التي يستطيع الرابط أو المسار حملها وفق التعريف المستخدم	Mb/s أو Gb/s	منفذ Ethernet اسميًا 1 Gb/s
Throughput	معدل البيانات الذي يتحقق فعليًا أثناء النقل	Mb/s أو Gb/s	اختبار يحقق 830 Mb/s
Goodput	معدل بيانات التطبيق المفيدة بعد استبعاد بعض الـOverhead والبيانات المعاد إرسالها	Mb/s أو MB/s	سرعة وصول محتوى الملف فعليًا إلى التطبيق
Latency	الزمن الذي تستغرقه البيانات أو الاستجابة	ms	RTT يساوي 20 ms

المشكلة تبدأ عندما نختصر هذه المقاييس جميعًا بكلمة «السرعة». اتصال ذو Bandwidth مرتفع لا يعني تلقائيًا Latency منخفضة، كما أن السعة الاسمية للرابط لا تضمن أن تطبيقًا واحدًا سيستهلكها كاملة.

ما هو Bandwidth في الشبكات؟

لكلمة Bandwidth أكثر من معنى حسب السياق. في الاتصالات والفيزياء قد تعني نطاقًا من الترددات ويُقاس بالهرتز Hz. أما في الحديث اليومي عن الشبكات، فتُستخدم غالبًا للإشارة إلى قدرة الرابط على حمل البيانات، مثل 100 Mb/s أو 1 Gb/s.

ولهذا من الأفضل عند الحديث بدقة استخدام كلمات مثل Link Capacity أو Path Capacity عندما يكون المقصود هو قدرة نقل البيانات. يوضح RFC 5136 من IETF أن تعريف السعة يعتمد أيضًا على الطبقة التي نقيس عندها، ويفرق بين السعة الاسمية للرابط والسعة على مستوى IP والسعة المتاحة في لحظة معينة.

هذه نقطة تمنع خطأ شائعًا: لا يصح دائمًا أخذ رقم من الطبقة الفيزيائية ومقارنته مباشرة برقم لبيانات التطبيق وكأنهما يقيسان الشيء نفسه.

السعة الاسمية ليست السعة المتاحة

إذا كان منفذ Ethernet يعمل عند 1 Gb/s فهذا يخبرك بمعدل الرابط الاسمي، لكنه لا يعني أن لديك دائمًا 1 Gb/s متاحة لاتصال واحد من طرف إلى طرف.

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

ويمكن فهم العلاقة بصورة مبسطة هكذا:

السعة الاسمية للرابط ≠ السعة المتاحة الآن ≠ Throughput الذي سيحققه التطبيق

أما كيفية تحويل البتات إلى إشارات ونقلها عبر النحاس أو الألياف أو الهواء فهي من وظائف Physical Layer في نموذج OSI، ولا نحتاج إلى إعادة شرح تفاصيل الطبقة الفيزيائية هنا.

ما هو Throughput؟

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

فإذا كان لديك رابط 1 Gb/s وحقق اختبار معين 750 Mb/s، فإن 1 Gb/s تصف السعة الاسمية للرابط في ذلك السياق، بينما 750 Mb/s هي النتيجة الفعلية لذلك الاختبار.

لكن حتى كلمة Throughput يجب تفسيرها وفق ما يتم قياسه. ففي اختبارات أجهزة الشبكات، يعرف RFC 1242 Throughput ضمن منهجية Benchmarking محددة، بينما يمكن أن نتحدث في سياقات أخرى عن TCP Throughput أو معدل نقل على مستوى مختلف.

لماذا يكون Throughput أقل من معدل الرابط؟

من الأسباب الشائعة:

• مشاركة الرابط مع أجهزة أو اتصالات أخرى.
• ازدحام الشبكة وامتلاء Queues.
• Packet Loss وما قد ينتج عنه من إعادة إرسال.
• ترويسات البروتوكولات ومعلومات التحكم.
• قيود Wi-Fi والتداخل وجودة الإشارة.
• قدرات الراوتر أو Switch أو بطاقة الشبكة.
• أداء CPU أو التخزين في الطرفين.
• قيود الخادم الذي تُنزّل منه البيانات.
• خصائص TCP وظروف المسار مثل RTT.

وعندما ترى ترويسات Ethernet وIP وTCP ستدرك لماذا لا تكون كل البتات المنقولة محتوى تطبيق مفيدًا. يمكنك مراجعة بنية Ethernet Frame وحقولها لفهم جزء من هذا الـOverhead على مستوى طبقة ربط البيانات.

ما هو Goodput؟

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

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

يستخدم RFC 8238 مصطلح Goodput لوصف Application-level Throughput في سياق اختبارات مراكز البيانات، مع استبعاد البيانات المعاد إرسالها من القياس.

لذلك عند حساب «كم سيستغرق تنزيل ملف؟» يكون معدل البيانات المفيدة الذي يصل إلى التطبيق أكثر واقعية من الاعتماد الأعمى على الرقم المكتوب على منفذ الشبكة.

ما هي Latency؟

Latency تتعلق بالزمن وليس بكمية البيانات في الثانية. ولهذا تقاس عادة بالميلي ثانية ms، ولا يصح مقارنتها مباشرة برقم مثل 500 Mb/s.

يعرّف RFC 7679 مقياسًا معياريًا للـOne-Way Delay، أي الزمن الذي تستغرقه حزمة في اتجاه واحد عبر مسار IP.

أما أدوات مثل ping فتُستخدم عادة لمشاهدة Round-Trip Time أو RTT: الزمن من إرسال الطلب حتى عودة الرد. لذلك رقم Ping ليس بالضرورة One-Way Latency.

مم يتكون التأخير داخل الشبكة؟

يمكن تحليل التأخير إلى عدة مكونات رئيسية:

• Transmission Delay أو Serialization Delay: الزمن اللازم لوضع Bits الحزمة على الرابط.
• Propagation Delay: الزمن الذي تحتاجه الإشارة للانتقال عبر المسافة الفيزيائية.
• Processing Delay: الزمن الذي تقضيه الأجهزة في معالجة الحزمة.
• Queuing Delay: الزمن الذي تنتظره الحزمة داخل طابور قبل إرسالها.

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

كيف نحسب Transmission Delay؟

Transmission Delay هو الزمن اللازم لإدخال جميع Bits الخاصة بالحزمة أو البيانات إلى الرابط. المعادلة الأساسية هي:

Transmission Delay = N / R

حيث:

• N = حجم البيانات بالبت Bit.
• R = معدل الرابط بالبت في الثانية bit/s.

مثال: حزمة حجمها 12,000 Bit على رابط 100 Mb/s

أولًا نحول المعدل:

100 Mb/s = 100,000,000 bit/s

ثم:

12000 / 100000000 = 0.00012 s

أي:

Transmission Delay = 0.12 ms

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

ما هو Propagation Delay وكيف يُحسب؟

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

المعادلة:

Propagation Delay = Distance / Propagation Speed

زيادة معدل الرابط من 1 Gb/s إلى 10 Gb/s تستطيع تقليل Serialization Delay لنفس كمية البيانات، لكنها لا تلغي المسافة الفيزيائية بين نقطتين.

وهذا يشرح لماذا يمكن لرابط ذي سعة ضخمة بين قارتين أن يمتلك Latency أعلى من رابط أبطأ داخل المبنى نفسه.

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

Transmission Delay ليس هو Propagation Delay

الخلط بينهما من أكثر الأخطاء شيوعًا في مسائل الشبكات.

Transmission Delay يعتمد أساسًا على:

حجم البيانات ÷ معدل الرابط

أما Propagation Delay فيعتمد على:

المسافة ÷ سرعة انتشار الإشارة

لذلك:

• زيادة حجم Packet تزيد Transmission Delay.
• رفع معدل الرابط يقلل Transmission Delay.
• زيادة المسافة تزيد Propagation Delay.
• رفع Bandwidth لا يجعل الإشارة تنتقل لحظيًا بين مدينتين.

كيف نحسب زمن نقل ملف؟

في أبسط مسألة نظرية، إذا عرفت حجم البيانات ومعدل النقل يمكنك استخدام:

Transfer Time = Data Size in bits / Data Rate in bit/s

مثال: ملف 100 MB عبر 100 Mb/s

نستخدم هنا الوحدات العشرية:

100 MB = 800 Mb

إذن:

800 Mb / 100 Mb/s = 8 seconds

ثماني ثوانٍ هي نتيجة نظرية إذا كان معدل نقل البيانات 100 Mb/s طوال العملية ولم نحسب عوامل أخرى.

إذا كان الـGoodput الفعلي 80 Mb/s مثلًا:

800 Mb / 80 Mb/s = 10 seconds

ولهذا فإن استخدام معدل النقل الذي يتحقق فعليًا يعطي تقديرًا أفضل من استخدام معدل الرابط الاسمي وحده.

Mbps وMB/s: لماذا الفرق يساوي ثمانية؟

هذه من أكثر النقاط التي تربك المستخدم عند مقارنة باقة الإنترنت ببرنامج التحميل.

b الصغيرة تعني bit، بينما B الكبيرة تعني Byte.

وبما أن:

1 Byte = 8 bits

فإن:

100 Mb/s ÷ 8 = 12.5 MB/s

وبالمثل:

• 200 Mb/s = 25 MB/s
• 500 Mb/s = 62.5 MB/s
• 1 Gb/s = 125 MB/s

هذه حدود تحويل رياضية وليست ضمانًا لسرعة تنزيل التطبيق. الأداء الفعلي قد يكون أقل بسبب الشبكة والبروتوكولات والخادم والطرف المستقبل.

كما أن بادئات SI مثل kilo وmega وgiga تمثل قوى عشرية؛ ويمكن مراجعة تعريفاتها لدى المكتب الدولي للأوزان والمقاييس BIPM.

لماذا اتصال 1 Gb/s قد يبدو بطيئًا؟

لأن «سرعة الرابط» ليست العامل الوحيد في تجربة المستخدم.

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

ولهذا قد يتأثر التطبيق بأحد العوامل التالية:

• RTT مرتفع إلى الخادم.
• Packet Loss.
• ازدحام Wi-Fi أو تداخل القنوات.
• مسار طويل أو مزدحم عبر الإنترنت.
• بطء DNS.
• زمن معالجة مرتفع في الخادم.
• قيود TCP أو التطبيق.
• بطء التخزين أو CPU.
• وجود Bottleneck أبطأ في جزء آخر من المسار.

وفي الشبكات اللاسلكية تحديدًا، لا يكفي النظر إلى الرقم التسويقي لمعيار Wi-Fi، لأن الوسط مشترك وتتغير ظروف القناة والإشارة باستمرار. يشرح مقال وسائط الإرسال اللاسلكي خصائص الوسط الراديوي بصورة مستقلة.

كيف تؤثر Latency في TCP Throughput؟

يمكن أن يمتلك المسار Bandwidth مرتفعًا ومع ذلك لا يستفيد اتصال TCP واحد من كامل السعة إذا لم يستطع الاحتفاظ بكمية كافية من البيانات قيد النقل.

من المفاهيم المهمة هنا Bandwidth-Delay Product أو BDP:

BDP = Bandwidth × RTT

وهو يمثل تقريبًا كمية البيانات التي يجب أن تكون «في الطريق» حتى يبقى المسار ممتلئًا عند معدل معين.

على سبيل المثال، مسار 1 Gb/s مع RTT مرتفع يحتاج إلى كمية أكبر من البيانات غير المؤكدة قيد النقل مقارنة بمسار له نفس السعة وRTT منخفض.

يستخدم RFC 6349 الخاص بقياس TCP Throughput كلًا من Bottleneck Bandwidth وRTT وTCP Window وPath MTU ضمن العوامل المهمة عند تقييم الأداء القابل للتحقيق بواسطة TCP.

وهذا يوضح لماذا عبارة «Latency لا علاقة لها بالتحميل» غير دقيقة. Latency ليست Bandwidth، لكنها قد تؤثر في قدرة بروتوكول النقل على الاستفادة من السعة المتاحة.

ولفهم وظيفة TCP وعلاقته بطبقة النقل دون توسيع هذا المقال إلى شرح للبروتوكولات، يمكنك الرجوع إلى دليل البروتوكولات الشبكية وTCP وUDP.

ماذا يقيس Speed Test فعلًا؟

اختبار السرعة لا يكتشف رقمًا سحريًا ثابتًا اسمه «سرعة الإنترنت». هو ينشئ حركة بيانات بين جهازك وخادم اختبار ويقيس الأداء الذي أمكن تحقيقه في تلك الظروف.

لذلك يمكن أن تتغير النتيجة بتغير:

• خادم الاختبار.
• المسار إليه.
• وقت إجراء الاختبار.
• وجود حركة مرور أخرى.
• استخدام Wi-Fi أو Ethernet.
• الجهاز والمتصفح أو التطبيق.
• سياسات مزود الخدمة.

نتيجة 900 Mb/s إلى خادم قريب لا تعني أن كل خادم على الإنترنت سيعطيك 900 Mb/s، كما أن نتيجة منخفضة إلى خادم بعيد لا تثبت وحدها أن رابط الوصول لديك معطل.

كيف تشخص اتصالًا بطيئًا بطريقة صحيحة؟

بدل استخدام كلمة «السرعة» لوصف كل مشكلة، حدد المقياس الذي يبدو غير طبيعي:

1. تحقق من Link Rate: هل تفاوض منفذ Ethernet على 1 Gb/s أم 100 Mb/s؟
2. قس Throughput: ما معدل النقل الذي يتحقق فعلًا؟
3. قس RTT: هل التأخير إلى الوجهة مرتفع؟
4. افحص Packet Loss: هل توجد حزم مفقودة أو إعادة إرسال؟
5. حدد مكان الاختناق: الجهاز، Wi-Fi، الراوتر، مزود الخدمة، المسار أم الخادم؟
6. قارن داخل الشبكة وخارجها: اختبار LAN يساعد على فصل مشكلة الشبكة المحلية عن مشكلة الإنترنت.

فإذا كان النقل داخل LAN سريعًا لكن الإنترنت بطيء، فالاختناق غالبًا خارج جزء من الشبكة المحلية. وإذا كان الأداء سيئًا حتى بين جهازين محليين، فمن المنطقي فحص Wi-Fi والكابلات والمنافذ والأجهزة قبل لوم مزود الإنترنت.

الخلاصة

أفضل طريقة لفهم أداء الشبكة هي التوقف عن استخدام كلمة «السرعة» كمقياس واحد لكل شيء.

Bandwidth أو Capacity تصف مقدار البيانات الذي يستطيع الرابط أو المسار حمله وفق الطبقة والتعريف المستخدم. Throughput يخبرك بما تحقق فعليًا أثناء النقل، وGoodput يقترب أكثر من معدل بيانات التطبيق المفيدة. أما Latency فتعبر عن الزمن، ويمكن أن تشمل Transmission وPropagation وProcessing وQueuing Delays.

ولحساب زمن وضع البيانات على الرابط استخدم N / R، بينما يُحسب Propagation Delay من Distance / Propagation Speed. وعند تقدير زمن تنزيل ملف، احرص على تحويل Bytes إلى bits ومقارنة الوحدات نفسها، وتذكر أن المعدل الفعلي أكثر واقعية من الاعتماد على السعة الاسمية وحدها.

بمجرد الفصل بين هذه المقاييس يصبح تشخيص مشاكل الشبكة أوضح بكثير: اتصال ذو Bandwidth مرتفع يمكن أن يعاني Latency عالية، ورابط سريع يمكن أن يعطي Throughput منخفضًا، واختبار سرعة ممتاز لا يضمن الأداء نفسه مع كل خادم أو تطبيق.