البحث في الموقع

لقد اعتُمدت الإنترنت منذ نشأتها على أساس نموذج نظيف، تكون فيه الموجّهات routers داخل الشبكة مسؤولةً عن تمرير الرزم من المصدر إلى الوجهة، وتُشغَّل البرامج التطبيقية على الأجهزة المضيفة المتصلة بأطراف الشبكة. يلتزم نموذج العميل / الخادم الموضح في التطبيقات التي ناقشناها سابقًا على هذا النموذج، لكن أصبح التمييز بين تمرير الرزم ومعالجة التطبيقات أقل وضوحًا في السنوات القليلة الماضية، حيث توزَّع التطبيقات الجديدة عبر الإنترنت، وفي كثيرٍ من الحالات تتخذ هذه التطبيقات قرارات التمرير الخاصة بها. يمكن أحيانًا تنفيذ هذه التطبيقات الهجينة الجديدة من خلال توسيع الموجّهات والمبدّلات التقليدية لدعم قدرٍ صغيرٍ من المعالجة الخاصة بالتطبيقات، حيث يتواجد مثلًا ما يسمى بمبدّلات المستوى 7 أمام عناقيد الخادم server clusters، وتمرر طلبات HTTP إلى خادمٍ معين بناءً على عنوان URL المطلوب، وتظهر شبكات التراكب overlay networks بسرعةٍ مثل آليةٍ مختارةٍ لإدخال وظائف جديدةٍ إلى الإنترنت. يمكنك التفكير في التراكب على أنه شبكةٌ منطقيةٌ مُطبَّقةٌ فوق بعض الشبكات الأساسية، فقد بدأت الإنترنت من خلال هذا التعريف مثل شبكة تراكبٍ على الروابط التي توفرها شبكة الهاتف القديمة. يوضح الشكل السابق تراكبًا مطبَّقًا على شبكةٍ أساسية، وكل عقدة في شبكة التراكب موجودةٌ أيضًا في الشبكة الأساسية؛ أي أن هذا التراكب يعالج ويمرر الرزم بطريقةٍ خاصةٍ بالتطبيق. تُنفَّذ الروابط التي تربط عقد التراكب مثل أنفاق tunnels عبر الشبكة الأساسية، ويمكن أن توجد شبكات تراكبٍ متعددةٍ على نفس الشبكة الأساسية، فتطبّق كل منها سلوكها الخاص بالتطبيق، ويمكن أن تتداخل التراكبات، أي تراكبٌ فوق الآخر، وتُعامِل جميعُ أمثلة شبكات التراكب التي نُوقشت في هذا القسم الإنترنت اليوم على أنه الشبكة الأساسية. رأينا بالفعل أمثلةً عن إنشاء أنفاقٍ لتنفيذ الشبكات الوهمية الخاصة VPN، حيث تعامِل العقدُ الموجودة على طرفي النفق المسارَ متعدد القفزات بينها مثل رابطٍ منطقي واحد، ولا تدركُ العقد الممرَّرة عبر نفقٍ باستخدام رزم التمرير المستندة على الترويسة الخارجية أن العقد النهائية قد أرفَقت ترويسةً داخليةً. يوضح الشكل السابق ثلاث عقد تراكب (A وB وC) متصلةً بواسطة زوجٍ من الأنفاق. قد تتخذ عقدة التراكب B في هذا المثال قرارًا بتمرير الرزم من العقدة A إلى العقدة C استنادًا إلى الترويسة الداخلية IHdr، ثم ترفِق ترويسةً خارجية OHdr تحدّد العقدة C على أنها وِجهةٌ في الشبكة الأساسية. يمكن للعقد A وB وC تفسير كلٍّ من الترويسة الداخلية والخارجية، بينما لا تفهم الموجّهات الوسيطة سوى الترويسة الخارجية، وتكون للعقد A وB وC عناوينٌ في كلٍ من شبكة التراكب والشبكة الأساسية، ولكنها ليست عناوينًا متطابقةً بالضرورة؛ فقد يكون العنوان الأساسي هو عنوان IP مؤلَّفٌ من 32 بتًا، بينما قد يكون عنوان التراكب عنوانًا تجريبيًا مؤلفًّا من 128 بتًا. لا تحتاج شبكة التراكب إلى استخدام عناوينٍ تقليديةٍ على الإطلاق، ولكنها قد توجِّه بناءً على عناوين URL، أو أسماء النطاق أو استعلامات XML، أو حتى محتوى الرزمة. توجيه شبكة التراكب أبسط نوعٍ من التراكب هو الذي يوجد فقط لدعم استراتيجية توجيهٍ بديلة؛ حيث تُجرَى معالجةٌ إضافيةٌ على مستوى التطبيق في عُقد التراكب، حيث يمكنك استخدام شبكةٍ وهميةٍ خاصة VPN بمثابة مثالٍ عن توجيه شبكات التراكب، ولكن لا يحدد هذا المثال الكثير لاستراتيجيةٍ أو خوارزميةٍ بديلة، لأنه يدخل مدخلات جدول توجيهٍ بديلة لتُعالَج بواسطة خوارزمية تمرير IP القياسية، حيث يُقال في هذه الحالة بالذات أن التراكب يستخدم أنفاق IP، وتُدعمَ القدرة على استخدام شبكات VPN هذه في العديد من الموجّهات التجارية. لنفترض أنك أردت استخدام خوارزمية توجيه لم يرغب مصنّعو الموجّهات التجارية في تضمينها في منتجاتهم. إذًا ماذا ستفعل؟ يمكنك ببساطةٍ تشغيل الخوارزمية الخاصة بك على مجموعةٍ من المضيفين النهائيين، وتشغيل النفق عبر موجّهات الإنترنت، حيث سيتصرّف هؤلاء المضيفون مثل موجهاتٍ في شبكة التراكب، أي مثل مضيفين متصلين بالإنترنت، من خلال رابطٍ فيزيائيٍ واحدٍ فقط، ويتصرفون مثل عقدةٍ في التراكب، ويُوصلون بالعديد من الجيران عبر الأنفاق. تُعَد التراكبات وسيلةٌ لإدخال تقنياتٍ جديدةٍ مستقلةٍ عن المعايير الأساسية، فلا توجد تراكباتٌ معياريةٌ يمكننا الإشارة إليها على أنها أمثلة، لذلك سنوضح الفكرة العامة لتوجيه التراكبات من خلال وصف العديد من الأنظمة التجريبية التي أنشأها باحثو الشبكات. إصدارات تجريبية من بروتوكول IP تُعَد التراكبات مثاليةً لنشر إصدارات تجريبية من بروتوكول IP التي تأمل أن تسيطر على العالم في النهاية، حيث بدأ بث IP المتعدد على سبيل المثال مثل إضافةٍ لبروتوكول IP، ولكن لم يُفعَّل في العديد من موجهات الإنترنت حتى اليوم، كما كانت شبكة MBone شبكة العمود الفقري متعدد البث multicast backbone عبارةً عن شبكة تراكب طبّقت بروتوكول IP متعدد البث على التوجيه أحادي البث الذي يوفره الإنترنت. وقد طُوِّرت أدوات المؤتمرات متعددة الوسائط ونُشِرت على شبكة Mbone، حيث بُثَّت اجتماعات منظمة IETF التي تستغرق أسبوعًا وتجذب الآلاف من المشاركين لسنواتٍ عديدة عبر شبكة MBone على سبيل المثال، ولكن حلّ التوافر الواسع لأدوات المؤتمرات التجارية محل النهج القائم على شبكة MBone. استخدمت شبكة MBone مثل شبكات VPN كلًا من أنفاق وعناوين IP، ولكنها طبّقت خوارزمية تمريرٍ مختلفةٍ عن تلك المستخدمة في شبكات VPN، حيث استخدمت تمرير الرزم إلى جميع الأجهزة الموجودة تحتها في المسار الأقصر لشجرة البث المتعدد. تمر الموجهات ذات البث المتعدد عبر نفقٍ من الموجهات القديمة مثل تراكب overlay، على أمل ألا تكون هناك يومًا ما موجهاتٌ قديمة. كانت شبكة 6-BONE شبكة تراكبٍ مشابهة، واُستخدِمت لنشر الإصدار IPv6 تدريجيًا، حيث استخدمت شبكةُ 6-BONE، مثل شبكة MBone، الأنفاقَ لتمرير الرزم عبر موجّهات IPv4، لكن لم تقدّم عقد شبكة 6-BONE تفسيرًا جديدًا لعناوين IPv4 المؤلفة من 32 بتًا على عكس شبكة MBone، حيث مررت العقد الرزم بناءً على حيز عناوين IPv6 ذات 128 بتًا، ودعمت شبكة 6-BONE أيضًا بث IPv6 المتعدد. بث النظام النهائي المتعدد End System Multicast بث بروتوكول IP المتعدد شائعٌ بين الباحثين وقطاعات معينة من مجتمع الشبكات، إلا أن نشره في الإنترنت العالمي كان محدودًا. لذلك تحوّلت التطبيقات القائمة على البث المتعدد مثل مؤتمرات الفيديو مؤخرًا إلى استراتيجيةٍ بديلةٍ، هي بث النظام النهائي المتعدد، حيث تتمثل فكرة هذه الاستراتيجية في قبول أن البث المتعدد لبروتوكول IP لن يصبح موجودًا في كل مكانٍ مطلقًا، ولذلك يُسمَح للمضيفين النهائيين المشاركين في تطبيقٍ معينٍ قائمٍ على البث المتعدد بتطبيق أشجار البث المتعدد الخاصة بهم. يجب أن نفهم أولًا أن بث النظام النهائي المتعدد، على عكس شبكات VPN وMBone، يفترض مشاركة مضيفي الإنترنت فقط دون موجهات الإنترنت في التراكب، ويتبادل هؤلاء المضيفون الرسائل مع بعضهم بعضًا من خلال أنفاق UDP، بدلًا من أنفاق IP، مما يسهّل تنفيذها مثل برامج تطبيقاتٍ عادية، ويؤدي إلى إمكانية عرض الشبكة الأساسية مثل رسمٍ بيانيٍ متصلٍ بالكامل، حيث أن كل مضيف في الإنترنت قادرٌ على إرسال رسالةٍ إلى كل مضيفٍ آخر. إذًا، يحل بث النظام النهائي المتعدد مشكلة العثور على شجرة البث المتعدد المضمَّنة التي تمتد عبر جميع أعضاء المجموعة، بدءًا من رسمٍ بيانيٍ متصلٍ بالكامل يمثّل الإنترنت. لاحظ أن هناك نسخةً أبسط من هذه المشكلة من خلال التوافر الجاهز للآلات الافتراضية VM المستضافة على السحابة حول العالم، حيث يمكن أن تعمل الأنظمة النهائية ذات البث المتعدد آلاتٍ افتراضيةٍ في مواقعٍ متعددة؛ هذه المواقع معروفةٌ جيدًا وثابتةٌ نسبيًا، لذلك يمكن إنشاء شجرةٍ ثابتةٍ متعددة البث في السحابة، ويمكن جعل المضيفين النهائيين الفعليين يتصلون ببساطةٍ بأقرب موقعٍ سحابي. بما أننا نفترض أن شبكة الإنترنت الأساسية متصلةٌ بصورةٍ كاملة، فإن الحل البسيط هو أن يكون كل مصدر متصلًا مباشرةً بكل عضوٍ في المجموعة، أي يمكن تطبيق بث النظام النهائي المتعدد من خلال إرسال كل عقدةٍ رسائل أحادية البث إلى كل عضوٍ في المجموعة. ضع في حساباتك مثال مخطط الشبكة الموضح في الشكل السابق لفهم المشكلة، حيث أن الموجهَين R1 وR2 متصلان باستخدام رابط عابرٍ للقارات بحيز نطاقٍ تراسلي منخفض، والمضيفات A وB وC وD هي مضيفاتٌ نهائية وتأخيرات الروابط مُعطاةٌ مثل أوزانٍ للأضلاع. بافتراض أن المضيف A أراد إرسال رسالةٍ متعددة البث إلى المضيفين الثلاثة الآخرين مثلما يوضح الشكل السابق كيف سيعمل البث الأحادي البسيط، لكنه غير مرغوبٍ لأن نفس الرسالة يجب أن تعبر الرابط بين المضيف A والموجّه R1 ثلاث مرات، وتعبر نسختان من الرسالة الرابط بين الموجه R1 والموجه R2. يوضح الشكل السابق أيضًا شجرة بث IP المتعدد التي أنشأها بروتوكول التوجيه متعدد البث لمُتجّه المسافات Distance Vector Multicast Routing Protocol -أو اختصارًا DVMRP. يلغي هذا الأسلوب الرسائل الزائدة، لكن بدون دعمٍ من الموجهات، فإن أفضل ما يمكن تتمناه من بث النظام النهائي المتعدد هو شجرةٌ مشابهةٌ لتلك الموضحة في الشكل السابق، حيث يحدد بث النظام النهائي المتعدد معماريةً لإنشاء هذه الشجرة. يتمثل النهج العام في دعم مستوياتٍ متعددةٍ من شبكات التراكب، حيث يَستخرج كلٌ منها رسمًا بيانيًا فرعيًا من التراكب الموجود أسفله، حتى نختار الرسم البياني الفرعي الذي يتوقعه التطبيق. يحدث هذا على مرحلتين بالنسبة إلى بث النظام النهائي المتعدد، هما: إنشاء تراكبٍ شبكيٍ بسيط على شبكة الإنترنت المتصلة بالكامل. اختيار شجرةٍ متعددة البث داخل هذه الشبكة. يوضح الشكل السابق هذه الفكرة، بافتراض وجود المضيفين النهائيين الأربعة A وB وC وD. بمجرد اختيار شبكة تراكب شبكة مناسبة، نشغّل خوارزميةَ توجيه البث المتعدد القياسية مثل بروتوكول DVMRP فوقها لبناء شجرة البث المتعدد. يمكننا أيضًا تجاهل مشكلة قابلية التوسع التي يواجهها البث المتعدد على مستوى الإنترنت، حيث يمكن تحديد الشبكة الوسيطة لتضمين فقط العقد التي ترغب في المشاركة في مجموعة بثٍ متعدد معينة. إن مفتاح إنشاء شبكة تراكبٍ وسيطة هو تحديد مخطط شبكةٍ متوافق تقريبًا مع مخطط شبكة الإنترنت الأساسي، ولكن يجب علينا فعل ذلك دون أن نعلم بما يبدو عليه الإنترنت الأساسي في الواقع، نظرًا لأننا نعمل فقط على المضيفين النهائيين وليس على الموجّهات. تتمثل الإستراتيجية العامة للمضيفين النهائيين في قياس زمن الانتقال ذهابًا وإيابًا إلى العقد الأخرى واتخاذ قرار إضافة روابطٍ إلى الشبكة فقط عندما تكون الأمور جيدةً، حيث يحصل ذلك على النحو التالي: أولًا، افترض وجود شبكةٍ بالفعل، حيث تتبادل كل عقدةٍ قائمةً list بجميع العقد الأخرى التي تعتقد أنها جزءٌ من الشبكة مع جيرانها المتصلين مباشرةً. إذا تلقّت العقدة قائمةَ العضوية من أحد الجيران، فإنها تدمج تلك المعلومات في قائمة العضوية الخاصة بها وتمرر القائمة الناتجة إلى جيرانها. تنتشر هذه المعلومات في النهاية عبر الشبكة، كما هو الحال في بروتوكول توجيه متجه المسافات. إذا أراد مضيفٌ الانضمام إلى شبكة تراكب البث المتعدد، فيجب أن يعرف عنوان IP لعقدةٍ أخرى على الأقل موجودةٍ بالفعل في شبكة التراكب، ثم يرسل رسالة الانضمام إلى الشبكة join mesh إلى هذه العقدة، وهذا يربط العقدة الجديدة بالشبكة عن طريق ضلعٍ إلى العقدة المعروفة. قد ترسل العقدة الجديدة رسالة انضمامٍ إلى عقدٍ حالية متعددة، وبالتالي تنضم إلى الشبكة عن طريق روابطٍ متعددة، وترسل العقدة الجديدة دوريًا رسائل أنها لا زالت نشطة keepalive إلى جيرانها بمجرد توصيلها بالشبكة من خلال مجموعةٍ من الروابط، لإعلام جيرانها بأنها لا تزال تريد أن تكون جزءًا من المجموعة. ترسل العقدة التي تغادر المجموعة رسالة ترك الشبكة leave mesh إلى جيرانها المتصلين مباشرةً، وتُنشَر هذه المعلومات إلى العقد الأخرى في الشبكة عبر قائمة العضوية الموضحة أعلاه. يمكن أن تفشل العقدة أو تقرر ترك المجموعة بصمت، وفي هذه الحالة يكتشف جيرانها أنها لم تَعُد ترسل رسائل keepalive. بعض حالات مغادرة العقدة لها تأثيرٌ ضئيلٌ على الشبكة، ولكن إذا اكتشفت العقدة أن الشبكة أصبحت مقسَّمةً بسبب مغادرة عقدةٍ ما، فإنها تنشئ ضلعًا جديدًا إلى عقدةٍ في القسم الآخر بإرسال رسالة انضمام إلى الشبكة. لاحظ أنه يمكن للجيران المتعددين أن يقرروا في نفس الوقت حدوث تقسيمٍ في الشبكة، مما يؤدي إلى إضافة أضلاعٍ متعددة إلى الأقسام المتقاطعة من الشبكة. ستتشكّل في النهاية شبكةٌ تمثل رسمًا فرعيًا من شبكة الإنترنت الأصلية المتصلة بالكامل، ولكن قد يكون لها أداءٌ دون المستوى الأمثل للأسباب الأربعة التالية: اختيار الجار الأولي يضيف روابطًا عشوائيةً إلى مخطط الشبكة. قد يضيف إصلاح التقسيم أضلاعًا أساسيةً في الوقت الحالي، ولكنها ليست مفيدةً على المدى الطويل. قد تتغير عضوية المجموعة بسبب عمليات الانضمام والمغادرة الديناميكية. قد تتغير ظروف الشبكة الأساسية. ما يجب أن يحدث هو أن يقيّم النظام قيمة كل ضلع، مما يؤدي إلى إضافة أضلاعٍ جديدة إلى الشبكة وإزالة الأضلاع الموجودة بمرور الوقت. لإضافة أضلاعٍ جديدة، تتحقق كل عقدةٍ i دوريًا من بعض الأعضاء العشوائية j التي لا تتصل بها حاليًا في الشبكة، وتقيس زمن انتقال الأضلاع ذهابًا وإيابًا (i,j)، ثم تقيّم فائدة إضافة هذا الضلع، حيث يُضاف الرابط (i,j) إلى الشبكة إذا كانت الفائدة أعلى من حدٍ معين. يكون تقييم فائدة إضافة الضلع (i,j) على النحو التالي: EvaluateUtility(j) utility = 0 for each member m not equal to i CL = current latency to node m along route through mesh NL = new latency to node m along mesh if edge (i,j) is added} if (NL < CL) then utility += (CL - NL)/CL return utility قرار إزالة ضلعٍ مماثلٌ لإضافة ضلع باستثناء أن كل عقدة i تحسب تكلفة كل رابطٍ إلى الجار الحالي j على النحو التالي: EvaluateCost(j) Cost[i,j] = number of members for which i uses j as next hop Cost[j,i] = number of members for which j uses i as next hop return max(Cost[i,j], Cost[j,i]) ثم تختار العقدة الجار ذا التكلفة الأقل، وتلغيه إذا انخفضت التكلفة إلى ما دون حدٍ معين. أخيرًا، بما أن الحفاظ على الشبكة يحدث باستخدام بروتوكول متجه مسافة، فلا يُعَد تشغيل بروتوكول DVMRP للعثور على شجرة البث المتعدد المناسبة في الشبكة أمرًا مفيدًا. لاحظ أنه ليس من الممكن إثبات أن البروتوكول الموصوف للتو ينتج عن شبكةٍ مثلى، مما يسمح لبروتوكول DVMRP بتحديد أفضل شجرةٍ متعددة البث ممكنة، لكن تشير كلٌ من المحاكاة والخبرة العملية الواسعة إلى أنها تعمل جيدًا. شبكات التراكب المرنة Resilient Overlay Networks يمكن أن يؤدي التراكب وظيفةً أخرى وهي إيجاد طرقٍ بديلة لتطبيقات البث الأحادي التقليدية، حيث تستغل هذه التراكباتُ الملاحَظةَ التي تفيد بأن عدم المساواة في المثلث لا ينطبق على شبكة الإنترنت. يوضح الشكل الآتي ما نعنيه بذلك، فليس غريبًا العثور على ثلاثة مواقعٍ على الإنترنت A وB وC، بحيث يكون زمن الانتقال بين الموقعين A وB أكبرُ من مجموع فترات الانتقال من الموقع A إلى الموقع C، ومن الموقع C إلى الموقع B؛ أي يُفضَّل في بعض الأحيان إرسال الرزم الخاصة بك بصورةٍ غير مباشرة عبر عقدةٍ وسيطةٍ بدلًا من إرسالها مباشرةً إلى الوِجهة. لكن كيف يمكن أن يحدث هذا؟ لم يَعِد بروتوكول البوابة الحدودية Border Gateway Protocol -أو اختصارًا BGP- أبدًا بأنه سيجد أقصر مسارٍ بين أي موقعين، فهو يحاول فقط إيجاد مسارٍ ما. تتأثر مسارات بروتوكول BGP بشدة بأمور السياسات policy، مثل سياسة من يدفع لمن ينقل حركة المرور. يحدث هذا غالبًا عند نقاط التناظر بين مزودي خدمة الإنترنت الأساسيين، فلا ينبغي أن يكون عدم وجود مساواة بمثلثٍ في شبكة الإنترنت أمرًا مفاجئًا. كيف نستغل هذه الملاحظة؟ تتمثل الخطوة الأولى في إدراك أن هناك مقايضةً أساسيةً بين قابلية التوسع والأمثلية لخوارزمية التوجيه. ويتوسّع نطاق بروتوكول BGP لشبكات كبيرة جدًا، ولكنه غالبًا لا يختار أفضل مسارٍ ممكن ويكون بطيئًا في التكيف مع انقطاعات الشبكة؛ فإذا كنت قلقًا فقط بشأن العثور على أفضل مسارٍ بين عددٍ قليلٍ من المواقع، فيمكنك التوجّه إلى عملٍ أفضل بكثير من مراقبة جودة كل مسار قد تستخدمه، مما يتيح لك تحديد أفضل مسارٍ ممكنٍ في أي لحظة. أدّى تراكبٌ تجريبي يُسمى شبكة التراكب المرنة Resilient Overlay Network -أو اختصارًا RON- ذلك بالضبط، حيث توسّعت شبكة RON إلى بضع عشراتٍ فقط من العقد، وذلك لأنها استخدمت استراتيجية N × N لمراقبة ثلاثة جوانبٍ لجودة المسار عن كثب عبر بحثٍ نشطٍ بين كل زوجٍ من المواقع، وهذه الجوانب الثلاثة هي: زمن الانتقال latency، وحيز النطاق التراسلي bandwidth المتاح، واحتمالية الخسارة loss probability. أصبحت شبكة RON بعد ذلك قادرةً على تحديد المسار الأمثل بين أي زوجٍ من العقد، وتغيير المسارات بسرعةٍ في حالة تغير ظروف الشبكة، فقد أظهرت التجربة أن شبكة RON كانت قادرةً على تقديم تحسيناتٍ متواضعة في الأداء للتطبيقات، ولكن الأهم من ذلك أنها تعافت من أعطال الشبكة بسرعةٍ أكبر. اكتشَف مثيلٌ لشبكة RON يعمل على 12 عقدةً 32 انقطاعًا استمر لأكثر من 30 دقيقةً خلال فترةٍ واحدةٍ مدتها 64 ساعةً في عام 2001 على سبيل المثال، وتمكَّن من التعافي منها جميعًا في أقل من 20 ثانيةً وسطيًا. اقترحت هذه التجربة أيضًا أن تمرير البيانات من خلال عقدةٍ وسيطةٍ واحدةٍ فقط يكون كافيًا عادةً للتعافي من حالات فشل الإنترنت. بما أن شبكة RON غير مصمَّمةٍ لتكون نهجًا قابلًا للتوسّع، فلا يمكن استخدامها لمساعدة المضيف العشوائي A على التواصل مع المضيف العشوائي B؛ أي يجب أن يعرف المضيفان A وB مسبقًا أنه من المُحتمَل أن يتواصلا، ثم ينضما إلى نفس شبكة RON. تُعَد شبكة RON فكرةً جيدةً في إعداداتٍ معينة، مثل توصيل بضع عشراتٍ من مواقع الشركات المنتشرة عبر الإنترنت أو السماح لك أنت و50 صديقٍ من أصدقائك بإنشاء شبكة تراكبٍ خاصة بك من أجل تشغيل بعض التطبيقات، حيث تطبَّق هذه الفكرة اليوم مع الاسم التسويقي Software-Defined WAN -أو اختصارًا SD-WAN-، لكن السؤال الحقيقي هو ماذا يحدث عندما يبدأ الجميع في تشغيل شبكة RON الخاصة بهم؟ وهل يؤدي حمل الملايين من شبكات RON التي تستكشف المسارات بقوة إلى إغراق الشبكة؟ وهل يرى أي شخصٍ تحسّن السلوك عندما تتنافس عدة شبكات RON على نفس المسارات؟ لا تزال هذه الأسئلة دون إجابة. توضِّح كل هذه التراكبات مفهومًا أساسيًا لشبكات الحاسوب هو الافتراضية virtualization، أي يمكن بناء شبكةٍ افتراضية من موارد مجردة أو منطقية على شبكةٍ فيزيائيةٍ مبنيةٍ من موارد فيزيائية أيضًا. يمكن تكديس هذه الشبكات الافتراضية فوق بعضها بعضًا، كما ويمكن أن تتعايش شبكاتٌ افتراضيةٌ متعددةٌ على نفس المستوى، حيث توفر كل شبكةٍ افتراضيةٍ بدورها إمكاناتٍ جديدة ذات قيمة لمجموعةٍ معينةٍ من المستخدمين، أو التطبيقات، أو الشبكات ذات المستوى الأعلى. ترجمة -وبتصرّف- للقسم Overlay Networks من فصل Applications من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: تطبيقات البنية التحتية في الشبكات الحاسوبية تطبيقات الشبكات الحاسوبية: خدمات الويب تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا