شبكات توزيع المحتوى Content Distribution Networks

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

رأينا بالفعل كيف يسمح تشغيل بروتوكول HTTP عبر بروتوكول TCP لمتصفحات الويب باسترداد الصفحات من خوادم الويب، ولكن يعرف أي شخصٍ ينتظر إلى الأبد لاسترداد صفحة ويب أن النظام بعيدٌ عن الكمال. تُنشَأ شبكة الإنترنت الرئيسية backbone الآن من روابطٍ ذات 40 جيجابت في الثانية، لذلك ليس واضحًا سبب حدوث ذلك. هناك أربع نقاط اختناقٍ محتملة في النظام عندما يتعلق الأمر بتنزيل صفحات الويب هي:

الميل الأول The first mile، حيث قد يحتوي الإنترنت على روابطٍ ذات سعةٍ عالية، ولكن هذا لا يساعدك على تنزيل صفحة ويب بصورةٍ أسرع عندما تكون متصلًا بخط DSL بسرعة 1.5 ميجابت في الثانية أو رابطٍ لاسلكي سيء الأداء.
الميل الأخير The last mile، حيث يمكن أن يُحمَّل الرابط الذي يربط الخادم بالإنترنت بصورةٍ كبيرة عن طريق طلباتٍ كثيرة جدًا، حتى إذا كان حيز النطاق التراسلي bandwidth الإجمالي لذلك الرابط مرتفعًا جدًا.
الخادم نفسه The server itself، حيث يحتوي الخادم على كميةٍ محدودةٍ من الموارد مثل وحدة المعالجة المركزية، والذاكرة، وحيز نطاق القرص الصلب وغير ذلك، ويمكن تحميله بصورةٍ كبيرة overload بسبب العديد من الطلبات المتزامنة.
نقاط التناظر Peering points، حيث قد يكون لدى عددٍ من مزودي خدمة الإنترنت الذين يطبّقون جميعًا شبكة الإنترنت الرئيسية backbone أنابيبًا ذات حيز نطاقٍ تراسلي عالٍ، لكن لديهم القليل من الحافز لتوفير اتصالٍ عالي السعة لأندادهم؛ فإذا كنت متصلًا بمزود خدمة الإنترنت A وكان الخادم متصلًا بمزود خدمة الإنترنت B، فقد تُسقَط الصفحة التي تطلبها عند النقطة التي يتقابل فيها المزوّدان A وB مع بعضهما بعضًا.

ليس هناك الكثير من الأشياء الممكن فعلها بشأن المشكلة الأولى، ولكن يمكن استخدام النسخ أو التضاعف لمعالجة المشكلات المتبقية، وتُسمّى الأنظمة المسؤولة عن ذلك بشبكات توزيع المحتوى Content Distribution Networks -أو اختصارًا CDNs-، حيث تدير أكاماي Akamai أشهر شبكة CDN.

تتمثل فكرة شبكة CDN في توزيع مجموعةٍ من بدائل الخادم server surrogates جغرافيًا، والتي تضع الصفحات ضمن الذاكرة المخبئية في مجموعةٍ معينةٍ من خوادم الواجهة الخلفية backend servers. وبالتالي يمكن نشر الحِمل على عدة خوادم، بدلًا من أن ينتظر الملايين من المستخدمين إلى الأبد للاتصال عند ظهور قصةٍ إخباريةٍ كبيرة، حيث يُعرَف مثل هذا الموقف بالتجمّع المفاجئ flash crowd. وبدلًا من الاضطرار إلى عبور عددٍ من مزودي خدمة الإنترنت للوصول إلى الموقع www.cnn.com، فيجب أن يكون ممكنًا الوصول إلى خادمٍ بديلٍ دون الحاجة إلى عبور نقطة تناظر، إذا كانت هذه الخوادم البديلة منتشرةً عبر جميع مزودي خدمة الإنترنت الأساسيين. صيانةُ آلاف الخوادم البديلة في أنحاء شبكة الإنترنت مكلفٌ للغاية لأي موقعٍ يريد توفير وصولٍ أفضل إلى صفحات الويب الخاصة به. توفّر شبكات CDN التجارية هذه الخدمة للعديد من المواقع، وهذا يؤدي إلى تسديد التكلفة عبر العديد من العملاء.

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

لا يحلّ وجودُ مجموعةٍ كبيرة من الخوادم الموزّعة جغرافيًا المشكلة تمامًا، حيث تحتاج شبكات CDN أيضًا إلى توفير مجموعةٍ من مُعيدات التوجيه redirectors التي تمرر طلبات العميل إلى الخادم الأنسب، كما هو موضحٌ في الشكل السابق. يتمثل الهدف الأساسي من معيدات التوجيه بتحديد الخادم لكل طلبٍ ينتج عنه أفضل وقت استجابةٍ response time للعميل؛ أما الهدف الثانوي فهو معالجة النظام عددًا من الطلبات في الثانية والتي يستطيع العتاد الأساسي مثل روابط الشبكة وخوادم الويب دعمها. يُعَد متوسط عدد الطلبات الممكن تلبيتها في فترةٍ زمنيةٍ معينة، والمعروفة باسم إنتاجية النظام system throughput، مشكلةً أساسيةً عندما يكون النظام تحت عبءٍ ثقيل، مثل وصول تجمّعٍ مفاجئ إلى مجموعةٍ صغيرةٍ من الصفحات أو هجماتٍ موزَّعة لحجب الخدمة Distributed Denial of Service -أو اختصارًا DDoS- على موقعٍ ما، كما حدث لمواقع CNN وYahoo والعديد من المواقع البارزة الأخرى في فبراير (شباط) عام 2000.

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

الآليات Mechanisms

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

الآلية الأولى هي تطبيق إعادة التوجيه عن طريق تعزيز نظام DNS لإرجاع عناوين خوادم مختلفة للعملاء، حيث يمكن لخادم DNS إرجاع عنوان IP للخادم الذي يستضيف صفحات الويب الخاصة بموقع CNN والمعروف عنه أنه يحتوي على أخف حِمل، عندما يطلب أحد العملاء تحليل resolve الاسم www.cnn.com على سبيل المثال؛ بينما قد ترجع مجموعةٌ معينةٌ من الخوادم العناوين فقط بطريقة جولة روبن round robin الدورية.

لاحظ أن دقة إعادة التوجيه المستندة إلى نظام DNS تكون عادةً على مستوى الموقع، مثل cnn.com عوضًا عن عنوان URL محدد، مثل:

https://www.cnn.com/2020/11/12/politics
Biden-wins-arizona
index.html

لكن يمكن للخادم إعادة كتابة عنوان URL عند إرجاع رابطٍ مضمَّن، وبالتالي توجيه العميل بفعالية إلى الخادم الأنسب لهذا الكائن المحدد.

تستخدم شبكات CDN التجارية تركيبةً من إعادة كتابة عناوين URL مع إعادة التوجيه المستندة إلى نظام DNS، حيث يشير خادم DNS عالي المستوى أولًا ولأسبابٍ تتعلق بقابلية التوسع، إلى خادم DNS على المستوى الإقليمي، الذي يرد بعنوان الخادم الفعلي. تعدّل خوادم DNS فترات TTL لسجلات الموارد التي تعود إلى فترةٍ قصيرة جدًا مثل 20 ثانية، بهدف الاستجابة للتغيرات بسرعة، ويُعَد هذا ضروريًا حتى لا يضع العملاء النتائج في ذاكرةٍ مخبئية وبالتالي يفشلون في الرجوع إلى خادم DNS للحصول على أحدث ربطٍ بين عنوان URL والخادم.

الآلية الثانية هي استخدام ميزة إعادة توجيه بروتوكول HTTP، حيث يرسل العميل رسالة طلبٍ إلى الخادم، الذي يستجيب بخادمٍ جديدٍ أفضل يتوجب على العميل الاتصال به للحصول على الصفحة. تتطلب إعادة التوجيه المستندة إلى الخادم وقتًا إضافيًا ذهابًا وإيابًا عبر الإنترنت، ويمكن أيضًا أن تكون الخوادم عرضةً للحِمل الزائد بسبب مهمة إعادة التوجيه redirection نفسها. بدلًا من ذلك، إذا كانت هناك عقدةٌ قريبةٌ من العميل، مثل وكيل ويب محلي local Web proxy على درايةٍ بالخوادم المتاحة، فيمكنها اعتراض رسالة الطلب وإرشاد العميل لطلب الصفحة من خادمٍ آخر مناسب. إما أن يكون معيد التوجيه في هذه الحالة ضمن نقطة اختناقٍ بحيث تمر جميع الطلبات التي تغادر الموقع من خلالها، أو سيتعيّن على العميل التعاون من خلال معالجة الوكيل صراحةً، كما هو الحال مع الوكيل الكلاسيكي وليس الوكيل الشفّاف transparent proxy؛ الذي هو خادمٌ يقع بين حاسوبك والإنترنت ويعيد توجيه طلباتك واستجاباتك دون تعديلها.

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

السياسات Policies

نستعرض الآن بعض الأمثلة عن السياسات التي قد يستخدمها مُعيدو التوجيه لتمرير الطلبات، حيث اقترحنا بالفعل سياسةً واحدةً بسيطةً وهي جولة روبن round-robin، وسيكون المثال الآخر هو اختيار أحد الخوادم المتاحة عشوائيًا. يوزع كلا الأسلوبين الحِمل بالتساوي عبر شبكة توصيل المحتوى، لكنهما لا يقلّلان من وقت الاستجابة المتوقَّع للعميل.

من الواضح عدم أخذ هذين الأسلوبين قُرب الشبكة في حساباتهما، وتجاهلهما أيضًا للمنطقة المحلية؛ أي يُعاد توجيه الطلبات الخاصة بعنوان URL نفسه إلى خوادم مختلفة، مما يقلل من احتمالية تخديم الصفحة من الذاكرة المخبئية الموجودة ضمن الخادم المحدد. هذا يفرض على الخادم استرداد الصفحة من قرصه الصلب، أو ربما من خادم الواجهة الخلفية. كيف يمكن لمجموعةٍ موزعةٍ من معيدات التوجيه أن تتسبب في انتقال الطلبات لنفس الصفحة إلى نفس الخادم أو إلى مجموعةٍ صغيرةٍ من الخوادم دون تنسيقٍ عالمي؟ الإجابة بسيطةٌ وهي: تستخدم جميع مُعيدات التوجيه شكلًا من أشكال تطبيق التعمية hashing لربط عناوين URL بمجالٍ صغير من القيم. الفائدة الأساسية من هذا النهج هي أنه لا حاجة لوجود اتصالٍ بين معيدي التوجيه لتحقيق عمليةٍ منسقة؛ فإن عملية التعمية تنتج نفس الخرج بغض النظر عن معيد التوجيه الذي يتلقى عنوان URL.

إذًا ما الذي يجعل مخطط التعمية جيدًا؟ مخطط تعمية النموذج الكلاسيكي، الذي يجري تعميةً على كل وحدة URL مع عددٍ من الخوادم، غير مناسبٍ لهذه البيئة، لأن حساب النموذج في حالة تغيير عدد الخوادم سيؤدي إلى تناقص الصفحات التي تحتفظ بتخصيصات الخادوم نفسها. لا نتوقع حدوث تغييراتٍ متكررةٍ في مجموعة الخوادم، إلا أن حقيقة إضافة خوادمٍ جديدة إلى المجموعة ستؤدي إلى إعادة تخصيص ضخمة أمرٌ غير مرغوبِ فيه.

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

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

يجري معيد التوجيه تعميةً على عنوان URL المُستقبَل مع كلٍ من الخوادم المتاحة ويرتّب القيم الناتجة، حيث تحدّد هذه القائمة المرتَّبة بفعالية الترتيب الذي سينظر فيه معيد التوجيه في الخوادم المتاحة، ثم يتحرّك معيد التوجيه في هذه القائمة حتى يعثر على خادمٍ يكون الحِمل عليه أقل من حدٍ معين. تتمثل فائدة هذا الأسلوب في أن ترتيب الخادم يختلف باختلاف عنوان URL، لذلك إذا فشل خادمٌ ما، فسيُوزَّع حِمله بالتساوي بين الأجهزة الأخرى. يُعَد هذا النهج أساس بروتوكول توجيه ذاكرة المصفوفة المخبئية Cache Array Routing Protocol -أو اختصارًا CARP- الموضّح في الشيفرة التالية:

SelectServer(URL, S)
    for each server s in server set S
        weight[s] = hash(URL, address[s])
    sort weight
    for each server s in decreasing order of weight
        if Load(s) < threshold then
            return s
       return server with highest weight

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

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

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

منظور الفصل التاسع: السحابة هي شبكة الإنترنت الجديدة

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

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

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

توجد طريقةٌ للدفع لشخصٍ ما مقابل حقوق تحميل وتشغيل برنامجك على خوادمٍ منتشرةٍ في جميع أنحاء العالم؛ وهذا هو بالضبط ما توفره السحابات السلعية مثل Amazon AWS و Microsoft Azure و Google Cloud Platform، حيث توفّر السحابة عددًا غير محدودٍ من الخوادم ظاهريًا، ولكنها لا تقل أهميةً، إن لم تكن الأهم، عن مكان وجود هذه الخوادم، حيث تُوزَّع على نطاقٍ واسع عبر أكثر من 150 موقعًا متصلًا بصورةٍ جيدة.

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

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

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