أساسيات الشبكات العوامل المؤثرة في أداء الشبكات الحاسوبية

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

حيز النطاق التراسلي (Bandwidth) ووقت الاستجابة (Latency)

يُقاس أداء الشبكة بطريقتين أساسيتين: حيز النطاق التراسلي (bandwidth) ويسمى أيضًا الإنتاجية (throughput)، ووقت الاستجابة (latency) ويسمى أيضًا التأخير (delay). يعبّر عن حيز نطاق الشبكة التراسلي بعدد البِتات التي يمكن إرسالها عبر الشبكة في فترة زمنية معيّنة. على سبيل المثال، قد يكون للشبكة حيز نطاق تراسلي يبلغ 10 مليون بت في الثانية (Mbps)، مما يعني أنها قادرة على توصيل 10 مليون بِت في الثانية. من المفيد أحيانًا التفكير في حيز النطاق التراسلي من حيث المدة التي يستغرقها إرسال كل جزء من البيانات. يستغرق 0.1 ميكروثانية (μs) لإرسال كل بِت على شبكة بسرعة 10 ميجابت في الثانية على سبيل المثال.

حيز النطاق التراسلي والإنتاجية هما مصطلحان مختلفان اختلافًا دقيقًا. بدايةً، حيز النطاق التراسلي هو بالمعنى الحرفي قياسٌ لعرض نطاق التردد. على سبيل المثال، كانت خطوط الهاتف القديمة من الدرجة الصوتية تدعم نطاق تردد يتراوح بين 300 إلى 3300 هرتز؛ وكان يقال أنّ حيز النطاق التراسلي هو : 3300 هرتز - 300 هرتز = 3000 هرتز. إذا رأيت مصطلح حيز النطاق التراسلي (bandwidth) مستخدمًا في حالةٍ يقاس فيها بالهرتز، فمن الراجح أنه يشير إلى نطاق الإشارات التي يمكن استيعابها.

عندما نتحدث عن حيز النطاق التراسلي لرابط اتصالٍ، فإننا نشير عادةً إلى عدد البِتات في الثانية التي يمكن إرسالها على الرابط. يُسمى هذا أحيانًا أيضًا معدّل البيانات (data rate). يمكن أن نقول أنّ حيز النطاق التراسلي لرابطٍ إثيرنت هو 10 ميجابت في الثانية. ومع ذلك، نستطيع أيضًا أن نميّز على نحو مفيدٍ بين الحدّ الأقصى لمعدل البيانات المتاح على الرابط وعدد البِتات في الثانية التي يمكننا بالفعل إرسالها عبر الرابط من الناحية العملية. نميل إلى استخدام كلمة الإنتاجية للإشارة إلى الأداء المُقَاس للنظام. وبالتالي، وبسبب أوجه القصور المختلفة في التنفيذ، قد يحقّق زوج من العقد متصل عبر رابط بجيز نطاق تراسلي يبلغ 10 ميجابت في الثانية إنتاجيةً لا تتجاوز 2 ميجابت في الثانية فقط. وهذا يعني أن التطبيق على أحد المضيفين يمكن أن يرسل البيانات إلى المضيف الآخر بسرعة 2 ميجابت في الثانية.

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

رغم أنّنا نستطيع أن نتكلّم عن حيز النطاق التراسلي للشبكة بأكملها، فإنّنا في بعض الأحيان نرغب أن نكون أكثر دقة بالتركيز مثلًا على حيز النطاق التراسلي لرابط فيزيائي واحدٍ أو قناة منطقية من عمليةٍ لعملية. على المستوى الفيزيائي، يتحسّن حيز النطاق التراسلي باستمرار، وبلا نهاية في الأفق. بصورة بديهية، إذا نظرت إلى ثانية من الزمن على أنّها مسافة يمكنك قياسها باستخدام المسطرةِ وإلى حيز النطاق التراسلي على أنّه عدد البِتات التي تتناسب مع هذه المسافة، فيمكنك التفكير في كل بِت على شكل نبضةٍ ذات عرض معيّن. على سبيل المثال في رابطٍ 1 ميجابت في الثانية كما في القسم (أ) من الشكل الآتي، وسيكون عرض كل بِت هو 1 ميكرو ثانية، بينما في رابطٍ 2 ميجابت في الثانية كما في القسم (ب) من الشكل الآتي، وسيكون عرض كل بت هو 0.5 ميكرو ثانية. كلما كانت تقنية الإرسال والاستقبال أعقد، كلما أصبح كل بِت أضيق، وبالتالي كلما زاد حيز النطاق التراسلي. بالنسبة للقنوات المنطقية من عملية لعملية، يتأثر جيز النطاق التراسلي أيضًا بعوامل أخرى، بما في ذلك عدد المرات التي يجب على البرنامج الذي ينفّذ القناة التعاملَ فيها مع كل بِت من البيانات، وربما تحويله.

يتوافق مقياس الأداء الثاني، أي وقت الاستجابة (latency)، مع المدّة التي تستغرقها رسالةٌ للانتقال من أحد طرفي الشبكة إلى الطرف الآخر. (وكما هو الحال مع حيز النطاق التراسلي، يمكن أن نركّز على وقت الاستجابة على رابطٍ واحدٍ أو قناة من طرف لطرف)، حيث يُقاس وقت الاستجابة بدقّة نسبة إلى الزمن. على سبيل المثال، يمكن أن يكون وقت الاستجابة لشبكةٍ عابرةٍ للقارات 24 ميلي ثانية (ms)؛ وهذا يعني أنّ الرسالة تستغرق 24 ميلي ثانية للانتقال من أحد ساحلي أمريكا الشمالية إلى الساحل الآخر. هناك العديد من المواقف التي يكون فيها مهمًّا للغاية معرفةُ الوقت المستغرق لإرسال رسالة من أحد طرفي الشبكة إلى الطرف الآخر والعكس كذلك عوض وقت الاستجابة في اتجاه واحدٍ. نسمي ذلك وقت الذهاب والإياب (round-trip time أو اختصارًا RTT) للشبكة.

غالبًا ما ننظر إلى وقت الاستجابة على أنه يتكوّن من ثلاث عناصر. العنصر الأول هو تأخير انتشار سرعة الضوء، ويحدث هذا التأخير لأنه لا يوجد شيء، بما في ذلك بِتٌ يتنقل عبر سلكٍ، يمكنه أن يتجاوز سرعة الضوء. إذا كنت تعرف المسافة بين نقطتين، فيمكنك حساب وقت الاستجابة لسرعة الضوء، ولكن يجب عليك توخي الحذر لأن الضوء ينتقل عبر وسائط مختلفة بسرعات مختلفة: فهو ينتقل بسرعة 3.0 × 108 m/s في الفراغ، وبسرعة 2.3 × 108 m/s في الكابل النحاسي و 2.0 × 108 m/s في الألياف البصرية. العنصر الثاني هو مقدار الوقت المستغرق لإرسال وحدة بيانات، وهو تناسبٌ بين حيز النطاق التراسلي للشبكة وحجم الرزمة التي تُنقَل البيانات فيها. أمّا العنصر الأخير فهو التأخير الذي قد يكون في طابورٍ داخل الشبكة نظرًا لأن المبدّلات تحتاج عمومًا إلى تخزين الرزَم لبعض الوقت قبل إعادة توجيهها على رابطٍ صادرٍ. وعلى أساس ما سبق، يمكننا تحديد وقت الاستجابة الإجمالي على النّحو التالي :

اقتباس

وقت الاستجابة (Latency) = الانتشار (Propagation) + الإرسال (Transmit) + الطابور (Queue)

الانتشار (Propagation) = المسافة (Distance) / سرعة الضوء (SpeedOfLight)

الإرسال (Transmit) = الحجم (Size) / حيز النطاق التراسلي (Bandwidth)

تُعبِّر المسافة Distance هنا عن طول السلك الذي ستنتقل عليه البيانات، وسرعة الضوء SpeedOfLight هي السرعة الفعلية للضوء على هذا السلك، والحجم هو حجم Size رزمة البيانات، وحيز النطاق التراسلي Bandwidth هو حيز النطاق التراسلي الذي تُرسَل الرزمة عليه. لاحظ أنه إذا كانت الرسالة تحتوي على بِتٍ واحدٍ فقط وكنّا نتحدث عن رابط واحد (وليس الشبكة بأكملها)، فإن عنصري الإرسال Transmit والطابور Queue لا تكون لهما قيمة، وعليه يُوافق وقتُ الاستجابة تأخيرَ الانتشار فحسب.

يُحدّد مفهوما حيز النطاق التراسلي ووقت الاستجابة معًا خصائصَ الأداء لرابط أو قناة معينة. ومع ذلك، تعتمد أهميتهما النسبية على التطبيق. فبالنسبة لبعض التطبيقات، يهيمن وقت الاستجابة على حيز النطاق التراسلي. على سبيل المثال، العميل الذي يرسل رسالةً مؤلفة من بايتٍ واحد إلى خادومٍ ويتلقى رسالةً مؤلفة من بايت واحدٍ في المقابل يكون محدودًا في وقت الاستجابة. إذا افترضنا أنه لا توجد حوسبةٌ حقيقية في عملية إعداد الرّد، فإن التطبيق سيعمل بصورة مختلفة كثيرًا على قناة عابرة للقارات بزمنٍ RTT يساوي 100 ميلي ثانية مقارنةً بقناةٍ عبر الغرفة بزمنٍ RTT يساوي 1 ميلي ثانية. سواءٌ كانت القناة 1 ميجابت في الثانية أو 100 ميجابت في الثانية فهذا غير مهمّ نسبيًا، رغم أنّ الأوّل يشير إلى أن وقت إرسال البايت Transmit هو 8 ميكرو ثانية والأخير يشير إلى وقت إرسالٍ Transmit هو 0.08 ميكرو ثانية.

في المقابل، لنأخذ برنامج مكتبة رقمية يُطلب منه إحضار صورة بحجم 25 ميجا بايت، كلّما زاد حيز النطاق التراسلي المتوفر، كلما زادت قدرته على إرسال الصورة إلى المستخدم بصورةٍ أسرع. في هذه الحالة، يهيمن حيز النطاق التراسلي للقناة على الأداء. لرؤية هذا الأمر، نفترض أن القناة لديها حيز نطاق تراسلي يبلغ 10 ميجابت في الثانية، سيستغرق الأمر 20 ثانية لإرسال الصورة (25×106×8 بِت) / (10×106 بِت في الثانية) = 20 ثانية، ولهذا لن يكون الأمر ذا أهمّية نسبيًا سواءٌ كانت الصورة على الجانب الآخر من قناة 1 ميلي ثانية أو من قناةٍ 100 ميلي ثانية، لأن الفرق بين زمن استجابة 20.001 ثانية وزمن استجابة 20.1 ثانية لا يكاد يذكر.

يُعطي الشكل التالي فكرةً عن الكيفية التي يمكن أن يهيمن بها وقت الاستجابة أو حيز النطاق التراسلي على الأداء في ظروف مختلفة. ويوضح الرسم البياني المدة التي يستغرقها نقل الكائنات ذات الأحجام المختلفة (1 بايت، 2 كيلوبايت، 1 ميجابايت) عبر الشبكات بأزمنةِ RTT تتراوح من 1 إلى 100 ميلي ثانية وسرعات روابط تبلغ 1.5 أو 10 ميجابت في الثانية. ونستخدم المقاييس اللوغاريتمية لإظهار الأداء النسبي. بالنسبة لكائن 1 بايت (ضغطةٌ على لوحة المفاتيح مثلًا)، يظل وقت الاستجابة مساويًا تمامًا تقريبًا لزمن RTT، إذ لا يمكنك التمييز بين شبكة 1.5 ميجابت في الثانية وشبكة 10 ميجابت في الثانية. بالنسبة لكائنٍ 2 كيلوبايت (على سبيل المثال مثلًا) ، فإن سرعة الرابط تحدث فرقًا كبيرًا على شبكةٍ ذات زمن RTT يبلغ 1 ميلي ثانية ولكن الفرق لا يذكر على شبكةٍ ذات زمن RTT يساوي 100 ميلي ثانية. وبالنسبة لكائن 1 ميجابايت (صورة رقمية مثلًا)، فإن RTT لا يشكّل أيّ فرقٍ، إنها سرعة الرابط هي التي تسيطر على الأداء عبر المجال الكامل لزمن RTT.

لاحظ أنه في هذا الكتاب نستخدم المصطلحين وقت الاستجابة والتأخير بصورة عامة للإشارة إلى الوقت الذي يستغرقه أداء وظيفة معينة، مثل توصيل رسالة أو نقل كائن. عندما نشير إلى مقدار الوقت المحدد الذي يستغرقه إرسال إشارة تنتشر من أحد طرفي الرابط إلى طرف آخر، فإننا نستخدم مصطلح تأخير الانتشار (propagation delay). ونوضح كذلك في سياق الحديث ما إذا كنا نشير إلى وقت الاستجابة في اتجاه واحدٍ أو وقت ذهاب وإياب.

نشير هنا كذلك إلى أنّ أجهزة الحاسوب أصبحت سريعةً جدًا لدرجة أنه عندما نربطها بالشبكات، يكون من المفيد أحيانًا التفكير، مجازيًا على الأقل، بما يمكن أن نسمّيه التعليمات لكلّ ميل. خُذ ما يحدث عندما يرسل جهاز حاسوب قادر على تنفيذ 100 مليار تعليمة في الثانية رسالةً على قناة ذات زمن RTT هو 100 ميلي ثانية. (لتسهيل العملية الحسابية، افترض أن الرسالة تغطي مسافة 5000 ميل). إذا كان هذا الحاسوب يبقى في وضع الخمول خلال المدّة 100 ميلي ثانية انتظارًا لرسالة الرّد، فإنّه ضيّع الفرصة لتنفيذ 10 مليار تعليمة، أو 2 مليون تعليمة لكل ميل. وكان من الأفضل بالنّسبة له الخروج من الشبكة لتجاوز هذا الهدر.

جداء التأخير في حيز النطاق التراسلي (Delay × Bandwidth Product)

من المفيد أيضًا التحدث عن جداء هذين المقياسين، الذي يسمى غالبًا جداء حيز النطاق التراسلي في وقت الاستجابة (delay × bandwidth product). بصورة بديهية، إذا نظرنا إلى قناةٍ بين زوج من العمليات على شكل أنبوب مجوف كما في الشكل التالي، إذ يقابل وقتُ الاستجابة طولَ الأنبوب ويمثّل قطرُ الأنبوب حيزَ النطاق التراسلي، فإن جداء حيز النطاق التراسلي في وقت الاستجابة سيعطي حجم الأنبوب، أي الحدّ الأقصى لعدد البِتات التي يمكن أن تمرّ عبر الأنبوب في أي لحظة معينة. يُمكن أن نعبّر عنها بطريقة أخرى، إذا كان وقت الاستجابة (الذي يقاس بالزمن) يتوافق مع طول الأنبوب، فعندما تعطي عرض كل بِت (يقاس أيضًا بالزمن)، فيمكنك حساب عدد البِتات التي ستملأ الأنبوب. على سبيل المثال، يمكن لقناة عابرة للقارات ذات وقت استجابة في اتجاه واحد قدره 50 ميلي ثانية وحيز نطاق تراسلي يبلغ 45 ميجابت في الثانية أن تستوعب ما مقداره:

50 × 10-3 × 45 × 106 bits/sec = 2.25 × 106 bits

أو حوالي 280 كيلو بايت من البيانات. وبعبارة أخرى، فإن هذه القناة (الأنبوب) في المثال يمكنها أن تَسَعَ نفس عدد بايتات ذاكرة حاسوب شخصي من فترة أوائل الثمانينات.

تُعدّ معرفة جداء حيز النطاق التراسلي في وقت الاستجابة أمرًا مهمًّا عند إنشاء شبكات عالية الأداء لأنه يتوافق مع عدد البِتات التي يجب أن يرسلها المرسل قبل وصول البِت الأول إلى جهاز الاستقبال. إذا كان المُرسِل يتوقع من الجهاز المُستقبِل أن يشير بطريقة ما إلى أن البِتات قد بدأت في الوصول، وكان الأمر يستغرق وقت استجابة آخر تعيد فيه القناة هذه الإشارة إلى المرسل، فيمكن أن يكون هذا الأخير قد أرسل ما يُعادل جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يسمع من المُستقبِل أن كل شيء على ما يرام. يُقال هنا أن البِتات في الأنبوب "في حالة طيران"، مما يعني أنه إذا طلب المُستقبِل من المُرسِل التوقف عن الإرسال، فقد يتلقى ما مقداره جداء حيز النطاق التراسلي في الزمن RTT من البيانات قبل أن يتمكن المرسل من الاستجابة. في المثال أعلاه، يُعادل هذا المقدار 5.5 × 106 بِت (671 كيلوبايت) من البيانات. من ناحية أخرى، إذا لم يملأ المرسل الأنبوب، أي لم يرسل بيانات تُعادل في مقدارها جداء حيز النطاق التراسلي في الزمن RTT قبل توقّفه لانتظار الإشارة، فإن المرسل لن يكون استخدم الشبكة بالكامل.

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

الشبكات عالية السرعة (High-Speed Networks)

تدفع الزيادة المستمرة الملحوظة في حيز النطاق التراسلي مصمّمي الشبكة للتفكير في الذي يحدث في المستوى الحدّي أو، بعبارة أخرى، كيف يُؤثّر وجود حيز نطاق تراسلي لا نهائي متاحٍ على تصميم الشبكة.

ورغم أنّ الشبكات عالية السرعة تجلب تغييرًا كبيرًا في حيز النطاق التراسلي المتاح للتطبيقات، إلا أنّ تأثيرها في كثير من النواحي على كيفية تفكيرنا بشأن الشبكات يكون بخصوص ما الذي لا يتغير عند زيادة حيز النطاق التراسلي : وهو سرعة الضوء. على حد تعبير سكوتي في سلسلة الخيال العلمي ستار تريك : "إنّنا لا نستطيع تغيير قوانين الفيزياء". وبعبارة أخرى، لا تعني "السرعة العالية" أن وقت الاستجابة يتحسن بنفس معدّل تحسّن حيز النطاق التراسلي. إنّ الزمن RTT عبر القارات لرابط بسرعة 1 جيجابت في الثانية يساوي 100 ميلي ثانية، وهو نفسُه تمامًا لرابط 1 ميجابت في الثانية.

لتقدير أهمية زيادة حيز النطاق التراسلي مقابل وقت الاستجابة الثابت، انظر إلى ما يتطلّبه إرسال ملف حجمه 1 ميجا بايت عبر شبكة 1 ميجابت في الثانية مقابل شبكة 1 جيجابت في الثانية، وكلاهما لهما زمن RTT يساوي 100 ميلي ثانية . في حالة شبكة 1 ميجابت في الثانية، تحتاج إلى 80 مرة ذهابًا وإيابًا لإرسال الملف؛ فخلال كل RTT، يُرسَل 1.25% من حجم الملف. وعلى النقيض، لا يكاد نفس الملف ذو الحجم 1 ميجابايت يشغل قيمة زمن RTT واحدٍ للرابط 1 جيجابت في الثانية، والذي قيمة جداء التأخيرxحيز النطاق الترسلي هي 12.5 ميجا بايت.

يوضح الشكل التالي الفرق بين الشبكتين. في الواقع، يبدو ملف 1 ميجا بايت وكأنه تدفقٌ من البيانات التي يجب إرسالها عبر شبكة 1 ميجابت في الثانية، بينما يبدو وكأنه مجرّد رزمة واحدة على شبكة 1 جيجابت في الثانية. لمساعدتك في فهم هذه النقطة، لاحظ أن ملف 1 ميجا بايت لشبكة 1 جيجابت في الثانية يمكنه أن يمثّل رزمة 1 كيلوبايت لشبكة 1 ميجابت في الثانية.

هناك طريقة أخرى للنظر إلى هذه المسألة هي أنه يمكن إرسال المزيد من البيانات خلال كل زمنٍ RTT على شبكة عالية السرعة، لدرجة أن زمن RTT واحدًا يصبح مقدارًا كبيرًا من الوقت. وبالتالي، في حين أنك لن تبالي بالفرق بين نقل الملفات الذي يستغرق 101 ضعفٍ لزمن RTT عوض 100 ضعفٍ لزمن RTT (فالفرق النسبي هو 1% فقط)، فإنّ الفرق بين ضعفٍ واحدٍ لزمن RTT و ضعفين لزمن RTT يصبح كبيرًا بصورة مفاجئة، بزيادةٍ بنسبة 100%. وبعبارة أخرى، فإن معيار وقت الاستجابة يبدأ في الهيمنة على تفكيرنا حول تصميم الشبكة عوضَ معيار الإنتاجية.

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

اقتباس

الإنتاجية (Throughput) = حجم النقل (TransferSize) \ زمن النقل (TransferTime)

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

اقتباس

TransferTime = RTT + 1/Bandwidth x TransferSize

نستخدم في هذه العلاقة لحساب رسالة طلب تُرسَل عبر الشبكة والبيانات التي ترسَل في الردّ عليها. على سبيل المثال، لنأخذ موقفًا يريد فيه المستخدم إحضار ملف 1 ميجا بايت عبر رابطٍ 1 جيجابت في الثانية مع زمن ذهاب وإياب يبلغ 100 ميلي ثانية. يتضمن هذا كلاً من وقت الإرسال لـ 1 ميجا بايت (1 \ 1 جيجابت في الثانية × 1 ميجابايت = 8 ميلي ثانية) وزمن RTT الذي هو 100 ميلي ثانية، بزمن نقل إجمالي يبلغ 108 ميلي ثانية. هذا يعني أن الإنتاجية الفعلية ستكون : 1 ميجا بايت \ 108 ميلي ثانية = 74.1 ميجابت في الثانية، وليس 1 جيجابت في الثانية.

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

متطلّبات أداء التطبيق الفعال

ركّزت المناقشة في هذا القسم بصورة محورية على أداء الشبكة؛ أي أنّ حديثنا انصبّ حول ما سيدعمه رابط أو قناة معينة. وكان الافتراض الذي لم يُفصح عنه هو أن برامج التطبيقات لها احتياجات بسيطة، فهي تريد نفس القدر من حيز النطاق التراسلي الذي يمكن أن توفره الشبكة. وينطبق هذا بالتأكيد على برنامج المكتبة الرقمية المذكور أعلاه والذي يسترجع صورة بحجم 250 ميجا بايت. وهكذا تزداد قدرة البرنامج على إعادة الصورة بصورة أسرع إلى المستخدم بزيادة حيز النطاق التراسلي المتوفر.

ومع ذلك، فإن بعض التطبيقات قادرة على تعيين حدّ أعلى لمقدار حيز النطاق التراسلي الذي تحتاجه. تطبيقات الفيديو هي مثال رئيسي. لنفترض أنك ترغب في تدفق مقطع فيديو بحجم ربع شاشة التلفزيون القياسية؛ أي أنه يحتوي على دقة 352×240 بكسل. إذا مثّلنا كل بكسل بـ 24 بِت من المعلومات، كما هو الحال بالنسبة للألوان 24 بِت، فسيكون حجم كل إطار (352 × 240 × 24) / 8 = 247.5 كيلوبايت. إذا كان التطبيق يحتاج إلى دعم معدّل إطارات بمقدار 30 إطارًا في الثانية، فإنه قد يطلب معدل إنتاجية يبلغ 75 ميجابت في الثانية. وهكذا، فإن قدرة الشبكة على توفير المزيد من حيز النطاق التراسلي ليست ذات فائدة لمثل هذا التطبيق لأنه يحتوي فقط على الكثير من البيانات لإرسالها في فترة زمنية معينة.

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

القضية الرئيسية هنا هي المجال الزمني الذي يُحسَب المعدّل من خلاله. لنفترض أنه يمكن ضغط تطبيق الفيديو هذا إلى الحدّ الذي يجعله يحتاج إلى 2 ميجابت في الثانية في المتوسط فقط. إذا أرسل 1 ميجابت في فاصل زمني مدته ثانية واحدة و3 ميجابت في الفاصل الزمني الموالي الذي مدته ثانية واحدة كذلك، فإنه في المجال الزمني الاجمالي الذي مدته ثانيتان سيكون الإرسال بمعدل 2 ميجابت في الثانية؛ ومع ذلك، لن يعني هذا الكثير بالنسبة لقناة صُمِّمت لدعم ما لا يزيد عن 2 ميجابت في الثانية الواحدة. وعليه، من الواضح أن مجرد معرفة متوسط احتياجات عرض النطاق التراسلي لتطبيقٍ ما لن يكون كافيًا دائمًا.

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

ومثلما يحتاج عرض النطاق التراسلي للتطبيق أن يكون شيئًا مختلفًا عن "كلّ ما يمكن الحصول عليه"، قد تكون متطلبات التأخير الخاص بالتطبيق أعقد من مجرد "أقلّ قدرٍ ممكن من التأخير". في حالة التأخير، لا يهم أحيانًا ما إذا كان زمن الوصول الأحادي للشبكة هو 100 ميلي ثانية أو 500 ميلي ثانية بقدر أهمّية الاختلاف في وقت الاستجابة من رزمةٍ إلى أخرى. يسمى هذا الاختلاف في وقت الاستجابة التقلقل (jitter).

لنأخذ الحالة التي يرسل فيها المصدر رزمةً مرة كل 33 ميلي ثانية، كما هو الحال بالنسبة لتطبيق فيديو يرسل إطارات 30 مرة في الثانية. إذا وصلت الحرزم إلى الوجهة متباعدة بمسافة 33 ميلي ثانية بالضبط، فيمكننا أن نستنتج أن التأخير الذي واجهته كل رزمة في الشبكة كان هو نفسه تمامًا. إذا كان التباعد بين وقت وصول الرزم إلى الوجهة، الذي يسمى أحيانًا الفجوة بين الرزَم (inter-packet gap)، متغيرًا، فيجب أن يكون التأخير الذي يحدثه تسلسل الرزم متغيرًا أيضًا، ويقال أن الشبكة أدخلت تقلقلًا في تدفق الرزمة، كما هو موضح في الشكل التالي. لا يدخل هذا الاختلاف بصفة عامة في رابط فيزيائي واحدٍ، ولكن يمكن أن يحدث عندما تواجه الرزم تأخيرات مختلفة في طابور شبكة تبديل الرزم متعدّدة العُقَد التوجيهية. يتوافق هذا التأخير في الطابور مع عنصر وقت الاستجابة المحدّد مسبقًا في هذا القسم، والذي يتغيّر مع الوقت.

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

منظور الفصل الأول: سرعة الميزة (Feature Velocity)

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

من بين هذه العوامل، يكون السوق هو الأكثر تأثيرًا، ويتوافق مع التفاعل بين مشغلي الشبكات (AT&T و Comcast و Verizon و DT و NTT وChina Unicom على سبيل المثال) ومورّدي معدّات الشبكة (مثل Cisco و Juniper و Ericsson و Nokia و Huawei وNEC) ومزوّدي التطبيقات والخدمات (مثل Facebook و Google و Amazon و Microsoft و Apple و Netflix و Spotify)، وبطبيعة الحال كذلك المشتركين والعملاء (أي الأفراد، ولكن أيضًا المؤسّسات والشركات). لا تكون الخطوط بين هؤلاء الفاعلين واضحة دائمًا، إذ تلعب العديد من الشركات أدوارًا متعددة. وأبرز مثال على ذلك هو مزودو الخدمات السحابية الضخمة، الذين (a) يبنون معدات شبكاتهم الخاصة باستخدام مكوناتٍ قليلة التكلفة، (b) وينشرون ويديرون شبكاتهم الخاصة، (c) ويقدّمون خدمات وتطبيقات للمستخدم النهائي على الشبكة.

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

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

بالنسبة للنقطة الثانية، فإن الشركات التي تبني الشبكات دائمًا ما تكون هي نفسها التي تديرها. وهي تُعرف إجمالًا باسم مشغلي الشبكات (network operators)، وتشمل الشركات المدرجة أعلاه. ولكن إذا نظرنا مرة أخرى إلى مفهوم السحابة للاستلهام منه، فإننا نرى أن مسألة التطوير-مع-التشغيل ليس معمولًا بها على مستوى الشركة فقط، ولكن أيضًا في كيفية تنظيم شركات الخدمات السحابية السريعة لفرقها الهندسية حول نموذج DevOps. (إذا لم تكن لديك دراية بمفهوم DevOps، ننصحك بالاطّلاع على هذين المقالين "ما المقصود بـ DevOps؟" و "لماذا ينبغي على فرق التطوير تبنّي ثقافة DevOps؟" لأخذ فكرة عنه وعن كيفية عمله وتطبيقه).

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

يُطلق على هذا التحول أحيانًا "إضفاء الطابع السّحابي (cloudification)" أو "إضفاء الطابع البرمجي (softwarization)" على الشبكة، ورغم أن الإنترنت كان لديها دائمًا نظام بيئي قوي للبرمجيات، إلا أنّه كان مقصورًا تاريخيًا على التطبيقات التي تعمل في المستوى الأعلى للشّبكة (مثل استخدام واجهة Socket API). ما تغيّر في الوقت الحالي هو تطبيق نفس الممارسات الهندسية المستوحاة من السحابة على الأجزاء الداخلية للشبكة. وتمثّل هذه المقاربة الجديدة، المعروفة بالشبكات المعرّفة برمجيًّا Software) Defined Networks أو اختصارًا SDN)، عاملًا مغيّرًا للعبة، ليس من حيث كيفية التعامل مع التحديات التقنية الأساسية للتأطير والتوجيه والتجزئة/إعادة التجميع وجدولة الرزم والتحكم في الاحتقان والأمن وما إلى ذلك. ولكن من حيث سرعة تطوّر الشبكة لدعم الميزات الجديدة.

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

اقتباس

نوصي لمعرفة المزيد حول DevOps بما يلي: Site Reliability Engineering: How Google Runs ProductionSystems, 2016

ترجمة -وبتصرّف- للقسم Performance من الفصل Foundation من كتاب Computer Networks: A Systems Approach