لربما من غير المفاجئ أن تعلم أن الأجهزة المتنقلة تمثّل بعض التحديات لِمعمارية الإنترنت. صُمِّم الإنترنت في عصرٍ كانت فيه الحواسيب كبيرة وغير متحركة، وبينما كان لدى مصممي الإنترنت على الأرجح فكرة أن الأجهزة المتنقلة قد تظهر في المستقبل، فمن العدل أن نفترض أنها لم تكن أولويةً قصوى لاستيعابها. توجد اليوم الحواسيب المتنقّلة في كل مكان، لا سيما على شكل حواسيب محمولة laptops وهواتف ذكية smartphones، وبصورةٍ متزايدة في أشكال أخرى، مثل الطائرات بدون طيار drones. سنلقي نظرةً في هذا القسم على بعض التحديات التي يفرضها ظهور الأجهزة المتنقّلة وبعض الأساليب الحالية لاستيعابها.
تحديات الشبكات المتنقلة
من السهل اليوم الظهور في نقطة اتصال لاسلكية، والاتصال بالإنترنت باستخدام المعيار 802.11 أو بعض بروتوكولات الشبكات اللاسلكية الأخرى، والحصول على خدمة إنترنت جيدة جدًا. إحدى تقنيات التفعيل الرئيسية التي جعلت نقطة الاتصال hotspot ممكنة هي بروتوكول DHCP. يمكنك الاستقرار في المقهى، وفتح الحاسوب المحمول، والحصول على عنوان IP لحاسوبك المحمول الذي يتحدث إلى موجهٍ افتراضي default router وخادم نظام أسماء النطاقات Domain Name System أو اختصارًا DNS، وبالتالي لديك كل ما تحتاجه بالنسبة لفئة واسعة من التطبيقات.
ولكن إذا نظرنا عن كثب قليلًا، فمن الواضح أنه بالنسبة لبعض سيناريوهات التطبيقات، فإن مجرد الحصول على عنوان IP جديد في كل مرة تتحرك فيها، وهو ما يفعله بروتوكول DHCP لك، لا يكفي دائمًا. لنفترض أنك تستخدم الحاسوب المحمول أو الهاتف الذكي لإجراء مكالمةٍ هاتفية عبر بروتوكول الإنترنت الصوتي، وتنتقل من نقطة اتصالٍ إلى أخرى أثناء التحدث على الهاتف، أو حتى التبديل من شبكة Wi-Fi إلى الشبكة الخلوية للاتصال بالإنترنت.
من الواضح أنك تحتاج إلى الحصول على عنوان IP جديد عندما تنتقل من شبكة وصول إلى أخرى، وهو عنوانٌ متوافق مع الشبكة الجديدة. ولكن لا يعرف الحاسوب أو الهاتف الموجود في الطرف الآخر من محادثتك على الفور المكانَ الذي انتقلت إليه أو عنوان IP الجديد الخاص بك. وبالتالي سيستمر إرسال الرزم إلى العنوان الذي اعتدت أن تكون فيه في حالة عدم وجود آلية أخرى، وليس إلى مكان وجودك الآن. هذه المشكلة موضحة في الشكل الآتي، حيث تحتاج الرزم من عقدة التراسل المقابلة correspondent node إلى إيجاد طريقها إلى الشبكة الجديدة ثم الانتقال إلى العقدة المتنقلة، عندما تنتقل العقدة المتنقلة من شبكة 802.11 في القسم (أ) إلى الشبكة الخلوية في القسم (ب) من الشكل التالي:
هناك العديد من الطرق المختلفة لمعالجة المشكلة الموضحة للتو، وسنلقي نظرةً على بعضٍ منها. بافتراض وجود طريقة ما لتمرير الرزم بحيث تصل إلى عنوانك الجديد بدلًا من عنوانك القديم، فإن المشاكل التالية الظاهرة على الفور تتعلق بالأمن. إذا كانت هناك آلية يمكنك من خلالها أن تقول، "عنوان IP الجديد الخاص بي هو X" على سبيل المثال، فكيف يمكنك منع بعض المهاجمين من إصدار مثل هذا البيان دون إذنك، وبالتالي تمكينهم إما من استلام الرزم الخاصة بك، أو تمرير رزمك إلى طرف ثالث غير مقصود؟ وبالتالي نرى أن الأمن security والتنقل mobility مرتبطان ارتباطًا وثيقًا.
إحدى القضايا التي أبرزتها المناقشة أعلاه هي حقيقة أن عناوين IP تخدم مهمتين في الواقع، فهي تُستخدَم مثل معرّفٍ identifier لنقطة النهاية، كما تُستخدَم لتحديد locate موقع نقطة النهاية. فكّر في المعرّف على أنه اسم طويل العمر لنقطة النهاية، ومحدّد locator الموقع على أنه بعض المعلومات المؤقتة المحتملة حول كيفية توجيه الرزم إلى نقطة النهاية. طالما أن الأجهزة لا تتحرك، أو لا تتحرك كثيرًا، فإن استخدام عنوان واحد لكلتا الوظيفتين يبدو معقولًا جدًا. ولكن بمجرد أن تبدأ الأجهزة في التحرك، فإنك تفضل أن يكون لديك معرّف لا يتغير أثناء التنقل وهذا ما يسمى أحيانًا معرّف نقطة النهاية أو معرّف المضيف، مع محدّد موقعٍ منفصل. كانت فكرة فصل محددات المواقع عن المعرّفات موجودةً منذ وقت طويل، ومعظم أساليب التعامل مع التنقل الموصوفة أدناه توفر مثل هذا الفصل بشكلٍ ما.
يُظهر الافتراض بأن عناوين IP لا تتغير في العديد من الأماكن المختلفة. حيث وضعت بروتوكولات النقل مثل بروتوكولات TCP افتراضاتٍ تاريخية حول بقاء عنوان IP ثابتًا طوال عمر الاتصال على سبيل المثال، لذلك يمكن أن يتمثل أحد الأساليب في إعادة تصميم بروتوكولات النقل بحيث يمكنها العمل مع تغيير عناوين نقطة النهاية.
البديل الشائع لمحاولة تغيير بروتوكول TCP هو أن يعيد التطبيق إنشاء اتصال TCP دوريًا في حالة تغيير عنوان IP الخاص بالعميل. قد يبدو هذا غريبًا، ولكن هذا هو بالضبط ما يحدث إذا كان التطبيق قائمًا على بروتوكول HTTP (متصفح ويب مثل كرومChrome أو تطبيق تدفق مثل نتفلكس Netflix على سبيل المثال). تتمثل الإستراتيجية في أن يعمل التطبيق حول الحالات الممكن أن يكون فيها عنوان IP الخاص بالمستخدم قد تغير، بدلًا من محاولة الحفاظ على المظهر الذي لا يتغير.
بينما نحن جميعًا على دراية بنقاط النهاية التي تتحرك، فإن الموجهات يمكنها أيضًا التحرك. هذا بالتأكيد أقل شيوعًا اليوم من تنقل نقط النهاية، ولكن هناك الكثير من البيئات التي قد يكون فيها الموجه المتنقل منطقيًا. أحد الأمثلة هو فريق الاستجابة للطوارئ الذي يحاول نشر شبكةٍ بعد أن تسببت بعض الكوارث الطبيعية في تدمير جميع البنية التحتية الثابتة. هناك افتراضات إضافية عندما تكون جميع العقد في الشبكة، وليس فقط نقاط النهاية، متنقلة، وهو موضوعٌ سيُناقش لاحقًا.
توجد نقطتان للتوضيح قبل أن نبدأ في إلقاء نظرة على بعض الأساليب لدعم الأجهزة المتنقلة. من الشائع أن نجد الناس يخلطون بين الشبكات اللاسلكية والتنقل. فغالبًا ما يُعثَر على التنقل واللاسلكية معًا. لكن يتعلق الاتصال اللاسلكي حقًا بالحصول على البيانات من العقدة A إلى العقدة B بدون سلك، بينما يتعلق التنقل بالتعامل مع ما يحدث عندما تتحرك العقدة أثناء اتصالها. من المؤكد أن العديد من العقد التي تستخدم قنوات الاتصال اللاسلكي ليست متنقلة، وتستخدم العقد المتنقلة اتصالًا سلكيًا في بعض الأحيان (على الرغم من أن هذا أقل شيوعًا).
أخيرًا، نحن مهتمون في الغالب بما يمكن أن نسميه التنقل في طبقة الشبكة. أي أننا مهتمون بكيفية التعامل مع العقد التي تنتقل من شبكةٍ إلى أخرى. يمكن التعامل مع الانتقال من نقطة وصول إلى أخرى في نفس شبكة 802.11 بآليات خاصة بمعيار 802.11، والشبكات الخلوية لديها أيضًا طرق للتعامل مع التنقل، ولكن نحتاج في الأنظمة غير المتجانسة الكبيرة مثل الإنترنت إلى دعم التنقل على نطاق أوسع عبر الشبكات.
التوجيه إلى المضيفين المتنقلين باستخدام بروتوكول Mobile IP
بروتوكول IP المتنقّل هو الآلية الأساسية في معمارية الإنترنت اليوم لمعالجة مشكلة توجيه الرزم إلى المضيفين المتنقلين. حيث يقدم بعض الإمكانيات الجديدة ولكنه لا يتطلب أي تغيير من المضيفين غير المتنقلين أو معظم الموجهات، مما يجعله قابلًا للانتشار بصورة متزايدة.
من المفترض أن يكون للمضيف المتنقل عنوان IP دائم، يُسمى العنوان المحلي home address الخاص به، والذي يحتوي على بادئة شبكة تساوي تلك الخاصة بشبكته المحلية home network. هذا هو العنوان الذي سيستخدمه المضيفون الآخرون عندما يرسلون الرزم في البداية إلى المضيف المتنقل، نظرًا لأنه لا يتغير، ويمكن أن تستخدمه التطبيقات طويلة العمر أثناء تجوال المضيف. ويمكننا التفكير فيه كمعرّف المضيف طويل الأمد.
يكتسب عادةً المضيف، عندما ينتقل إلى شبكةٍ خارجيةٍ foreign network جديدة بعيدة عن شبكته المحلية، عنوانًا جديدًا على تلك الشبكة باستخدام بعض الوسائل مثل بروتوكول DHCP. سيتغير هذا العنوان في كل مرة يتجول فيها المضيف إلى شبكة جديدة، لذلك يمكننا التفكير به على أنه أشبه بمحدّد موقع للمضيف، ولكن من المهم ملاحظة أن المضيف لا يفقد عنوانه المحلي الدائم عندما يكتسب عنوانًا جديدًا على الشبكة الخارجية. يُعَد هذا العنوان المحلي أمرًا بالغ الأهمية لقدرته على الحفاظ على الاتصالات أثناء تحرك المضيف.
اقتباسلم تتطلب معايير بروتوكول IP المتنقلة الأصلية بروتوكولَ DHCP نظرًا لأن بروتوكول DHCP طُوِّر في نفس وقت تطوير بروتوكول Mobile IP تقريبًا، ولكن بروتوكول DHCP موجود في كل مكان اليوم.
يتطلب دعم التنقل بعض الوظائف الجديدة في موجهٍ واحد على الأقل بينما تظل غالبية الموجّهات دون تغيير، ويُعرف هذا الموجه بالوكيل المحلي home agent للعقدة المتنقلة. ويقع هذا الموجه على الشبكة المحلية للمضيف المتنقل. يلزم أيضًا موجهٌ ثانٍ بوظيفة محسّنة في بعض الحالات، وهو الوكيل الخارجي foreign agent، ويقع هذا الموجه على شبكة تتصل بها العقدة المتنقلة عندما تكون بعيدةً عن شبكتها المحلية. سننظر أولاً في تشغيل بروتوكول Mobile IP عند استخدام وكيلٍ خارجي. يوضح الشكل التالي مثالاً لشبكة مع وكلاء محليين وخارجيين:
يعلن كلٌّ من الوكلاء المحليين والخارجيين دوريًا عن وجودهم على الشبكات التي يرتبطون بها باستخدام رسائل إعلان الوكيل. قد يطلب مضيف متنقل أيضًا إعلانًا عند توصيله بشبكة جديدة. يمكّن إعلانُ الوكيل المحلي المضيفَ المتنقل من معرفة عنوان الوكيل المحلي قبل أن يغادر شبكته المحلية. يسمع المضيف المتنقل إعلانًا من وكيلٍ خارجي عندما يتصل بشبكةٍ خارجية ويسجِّل لدى الوكيل، مع توفير عنوان وكيله المحلي. يتصل الوكيل الخارجي بعد ذلك بالوكيل المحلي، ويزوده بعنوان الرعاية care-of address. عادة ما يكون هذا هو عنوان IP الخاص بالوكيل الخارجي.
يمكننا أن نرى في هذه المرحلة أن أي مضيف يحاول إرسال رزمة إلى المضيف المتنقل سيرسلها بعنوان وجهة يساوي العنوان المحلي لتلك العقدة. سيؤدي تمرير IP العادي إلى وصول تلك الرزمة إلى الشبكة المحلية للعقدة المتنقلة التي يقع عليها الوكيل المحلي، وبالتالي يمكننا تقسيم مشكلة توصيل الرزمة إلى العقدة المتنقلة إلى ثلاثة أجزاء:
- كيف يعترض الوكيلُ المحلي رزمة مخصَّصة للعقدةِ المتنقلة؟
- كيف يسلّم الوكيل المحلي بعد ذلك الرزمة إلى الوكيل الخارجي؟
- كيف يسلّم الوكيل الخارجي الرزمة إلى العقدة المتنقلة؟
قد تبدو المشكلة الأولى سهلة إذا نظرت إلى الشكل السابق، حيث يكون الوكيل المحلي بوضوح هو المسار الوحيد بين المضيف المرسل والشبكة المحلية، وبالتالي يجب أن يتلقى الرزم الموجَّهة إلى العقدة المتنقلة. ولكن ماذا لو كانت عقدة الإرسال (المقابلة) على الشبكة 18، أو ماذا لو حاول موجهٌ آخر متصل بالشبكة 18 توصيلَ الرزمة دون مرورها عبر الوكيل المحلي؟ لمعالجة هذه المشكلة، ينتحل الوكيل المحلي فعليًا صفة العقدة المتنقلة، باستخدام تقنية تسمى proxy ARP. تعمل هذه التقنية تمامًا مثل بروتوكول تحليل العناوين Address Resolution Protocol أو اختصارًا ARP، باستثناء أن الوكيل المحلي يُدرج عنوان IP الخاص بالعقدة المتنقلة، بدلًا من عنوانه الخاص، في رسائل ARP، فيستخدم عنوان الجهاز الخاص به، بحيث تتعلم جميع العقد الموجودة على نفس الشبكة ربط عنوان الجهاز الخاص بالوكيل المحلي بعنوان IP الخاص بالعقدة المتنقلة. أحد الجوانب الدقيقة لهذه العملية هو حقيقة أن معلومات ARP يمكن تخزينها مؤقتًا في عقد أخرى على الشبكة. يصدر الوكيل المحلي رسالة ARP بمجرد تسجيل العقدة المتنقلة مع وكيلٍ خارجي، للتأكد من إبطال ذاكرات التخزين المؤقت هذه في الوقت المناسب. نظرًا لأن رسالة ARP ليست استجابة لطلب ARP عادي، فقد يطلق عليها اسم ARP مجاني gratuitous ARP.
المشكلة الثانية هي تسليم الرزمة المُعترَضة إلى الوكيل الخارجي. هنا نستخدم تقنية الأنفاق الموضحة سابقًا. يلف الوكيل المحلي ببساطة الرزمة داخل ترويسة IP المخصصة للوكيل الخارجي وينقلها إلى الشبكة المتشابكة. ترى جميع الموجّهات المتداخلة فقط رزمة IP مخصصة لعنوان IP الخاص بالوكيل الخارجي. هناك طريقة أخرى للنظر إلى ذلك وهي أن نفق IP يُنشَأ بين الوكيل المحلي والوكيل الخارجي، ويسقط الوكيل المحلي الرزم المخصَّصة للعقدة المتنقلة في هذا النفق.
يجرِّد الوكيل الخارجي ترويسة IP الإضافية للرزمة الواصلة إليه ويجد بالداخل رزمة IP المخصّصة لِعنوان العقدة المتنقلة المحلي. من الواضح أن الوكيل الخارجي لا يمكنه التعامل مع هذا مثل أية رزمة IP قديمة لأن هذا قد يتسبب في إعادته إلى الشبكة المحلية. فبدلًا من ذلك، يجب أن يتعرف على العنوان على أنه عنوان عقدة متنقلة مسجلة، ثم يسلّم الرزمة إلى عنوان الجهاز الخاص بالعقدة المتنقلة (عنوان Ethernet على سبيل المثال)، والذي يمكن التعرف عليه كجزء من عملية التسجيل registration.
إحدى الملاحظات الممكن أخذها حول هذه الإجراءات هي أنه من الممكن أن يكون الوكيل الخارجي والعقدة المتنقلة في نفس الصندوق، أي يمكن للعقدة المتنقلة أداء وظيفة الوكيل الخارجي نفسها. لإنجاح هذا العمل، يجب أن تكون العقدة المتنقلة قادرة على الحصول ديناميكيًا على عنوان IP الموجود في حيز عناوين الشبكة الخارجية باستخدام DHCP مثلًا. سيُستخدَم بعد ذلك هذا العنوان كعنوان رعاية. سيكون لهذا العنوان رقم شبكة هو 12 في مثالنا. يملك هذا الأسلوب الميزة المرغوبة المتمثلة في السماح للعقد المتنقلة بالاتصال بالشبكات التي ليس لديها وكلاء خارجيين، وبالتالي يمكن تحقيق التنقل من خلال إضافة وكيل محلي وبعض البرامج الجديدة فقط على العقدة المتنقلة (بافتراض استخدام DHCP على الشبكة الخارجية).
ماذا عن حركة المرور في الاتجاه الآخر (من العقدة المتنقلة إلى العقدة الثابتة على سبيل المثال)؟ تبين أن هذا أسهل بكثير. تضع العقدة المتنقلة فقط عنوان IP الخاص بالعقدة الثابتة في حقل الوجهة لرزم IP الخاصة بها بينما تضع عنوانها الدائم في حقل المصدر، وتُمرر الرزم إلى العقدة الثابتة باستخدام الوسائل العادية. إذا كانت كلتا العقدتين في المحادثة متحركتين، فستُستخدَم الإجراءات الموضحة أعلاه في كل اتجاه.
تحسين المسار في بروتوكول Mobile IP
هناك عيب كبير في النهج السابق: يمكن أن يكون المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة دون المستوى الأمثل على نحوٍ ملحوظ. أحد الأمثلة هو عندما تكون العقدة المتنقلة والعقدة المقابلة على نفس الشبكة، لكن الشبكة المحلية للعقدة المتنقلة تقع على الجانب الآخر من الإنترنت. تعالج العقدة المقابلة المرسِلة جميع الرزم إلى الشبكة المحلية، أي تجتاز الرزم الإنترنت للوصول إلى الوكيل المحلي، الذي ينقلها بعد ذلك عبر الإنترنت للوصول إلى الوكيل الخارجي. من الواضح أنه سيكون من الجيد أن تكتشف عقدة التراسل المقابلة أن العقدة المتنقلة موجودة بالفعل على نفس الشبكة وتسلّم الرزمة مباشرة. يتمثل الهدف في الحالة الأعم في توصيل الرزم مباشرةً قدر الإمكان من العقدة المرسلة المقابلة إلى العقدة المتنقلة دون المرور عبر وكيلٍ محلي. يشار إلى هذا أحيانًا بمشكلة توجيه المثلث triangle routing problem نظرًا لأن المسار من عقدة التراسل المقابلة إلى العقدة المتنقلة عبر الوكيل المحلي يأخذ جانبين من المثلث، بدلًا من الجانب الثالث وهو المسار المباشر.
الفكرة الأساسية وراء حل توجيه المثلث هي السماح للعقدة المقابلة بمعرفة عنوان الرعاية للعقدة المتنقلة. يمكن للعقدة المقابلة بعد ذلك إنشاء نفقٍ خاص بها للوكيل الخارجي. يحدث التعامل مع هذا على أنه تحسين للعملية الموضحة للتو. إذا جُهِّز المرسل بالبرمجيات اللازمة لتعلم عنوان الرعاية مع إنشاء نفقٍ خاص به، فيمكن حينئذٍ تحسين المسار. إذا لم يكن الأمر كذلك، فإن الرزم تتبع المسار دون المستوى الأمثل.
إذا رأى وكيلٌ محلي رزمةً مخصصة لإحدى العقد المتنقلة التي يدعمها، يمكنه استنتاج أن المرسل لا يستخدم المسار الأمثل. لذلك فإنه يرسل رسالة "تحديث ربط" binding update إلى المصدر، بالإضافة إلى تمرير رزمة البيانات إلى الوكيل الخارجي. يستخدم المصدر، إذا كان قادرًا، هذا التحديث الملزم لإنشاء مدخلةٍ في ذاكرة الربط المخبئية binding cache، والتي تتكون من قائمة الروابط بين عناوين العقدة المتنقلة وعناوين الحماية. في المرة التالية التي يحتوي فيها هذا المصدر على رزمة بيانات لإرسالها إلى تلك العقدة المتنقلة، سيجد الرابط في الذاكرة المخبئية ويمكنه نقل الرزمة مباشرةً إلى الوكيل الخارجي عبر نفق.
هناك مشكلة واضحة في هذا المخطط، وهي أن الذاكرة المخبئية الملزمة قد تصبح قديمة إذا انتقل المضيف المتنقل إلى شبكةٍ جديدة. إذا اُستخدِمت مدخلةُ مخبئية قديمة، فسيتلقى الوكيلُ الخارجي الرزم المرسَلة عبر نفقٍ لعقدة متنقلة لم تعد مُسجَّلة على شبكتها. في هذه الحالة، يرسل الوكيل الخارجي رسالة تحذير بالربط إلى المرسل لإخباره بالتوقف عن استخدام مدخلة الذاكرة المخبئية. يعمل هذا المخطط فقط في الحالة التي لا يكون فيها الوكيل الخارجي هو العقدة المتنقلة نفسها. لذلك يجب حذف مدخلات الذاكرة المخبئية بعد فترة زمنية معينة، وتُحدد هذه المدة في رسالة تحديث الرابط.
يوفر التوجيهُ المتنقل بعضَ التحديات الأمنية المثيرة للاهتمام، والتي أصبحت أوضح الآن بعد أن رأينا كيف يعمل بروتوكول Mobile IP. يمكن للمهاجم الذي يرغب في اعتراض الرزم الموجهة إلى عقدة أخرى في الشبكة المتشابكة على سبيل المثال الاتصالَ بالوكيل المحلي لتلك العقدة والإعلان عن نفسه كوكيلٍ خارجي جديدٍ للعقدة، وبالتالي من الواضح أن بعض آليات المصادقة مطلوبة.
التنقل في بروتوكول IPv6
هناك عدد قليل من الاختلافات المهمة بين دعم التنقل في IPv4 و IPv6. والأهم من ذلك، أنه كان من الممكن بناء دعم التنقل في معايير IPv6 إلى حدٍ كبير منذ البداية، وبالتالي التخفيف من عددٍ من مشاكل النشر الإضافية. (قد يكون من الأصح القول أن IPv6 هو مشكلة نشر تزايدي كبيرة، والتي بمجرد حلها ستوفر دعمًا للتنقل كجزء من سلسلة إجراءات).
بما أن جميع المضيفين الذين لديهم إمكانية IPv6 يمكنهم الحصول على عنوان لحظة توصيلهم بشبكةٍ خارجية (باستخدام العديد من الآليات المحددة مثل جزء من مواصفات الإصدار السادس v6 الأساسية)، فإن Mobile IPv6 يلغي الوكيل الخارجي ويتضمن القدرات اللازمة للعمل كوكيلٍ خارجي في كل مضيف.
أحد الجوانب الأخرى المثيرة للاهتمام في IPv6 الذي يُشغَّل مع Mobile IP هو تضمينه لمجموعة مرنة من الترويسات المتوسعة. يُستخدَم هذا في سيناريو التوجيه الأمثل الموضح أعلاه. يمكن لعقدة IPv6 إرسال رزمة IP إلى عنوان الرعاية مع العنوان المحلي المضمَّن في ترويسة التوجيه بدلًا من تمرير رزمة عبر نفق إلى العقدة المتنقلة في عنوان العناية الخاص بها. تتجاهل جميع العقد الوسيطة هذه الترويسة، ولكنها تُمكّن العقدة المتنقلة من التعامل مع الرزمة كما لو أُرسِلت إلى العنوان المحلي، وبالتالي تمكينها من مواصلة تقديم بروتوكولات الطبقة العليا مع الوهم بأن عنوان IP الخاص بها ثابت. يُعد استخدام ترويسة التوسع بدلًا من نفقٍ أكثر كفاءة من منظور استهلاك حيز النطاق التراسلي ومعالجته.
أخيرًا، نلاحظ أن العديد من المشكلات المفتوحة لا تزال قائمة في الشبكات المتنقلة. تزداد أهمية إدارة استهلاك الطاقة للأجهزة المتنقلة، بحيث يمكن بناء أجهزة أصغر ذات طاقة بطارية محدودة. هناك أيضًا مشكلة الشبكات المتنقلة المخصصة، أي تمكين مجموعة من العقد المتنقلة من تشكيل شبكة في غياب أي عقدٍ ثابتة، والتي تواجه بعض التحديات الخاصة. فئةٌ صعبة خاصة من الشبكات المتنقلة هي شبكات المستشعرات sensor networks. عادةً ما تكون المستشعرات صغيرة وغير مكلفة وغالبًا ما تعمل على البطارية، مما يعني أنه يجب أيضًا مراعاة مشكلات انخفاض استهلاك الطاقة وقدرة المعالجة المحدودة. وبما أن الاتصالات اللاسلكية والتنقل يسيران جنبًا إلى جنب، ستستمر التطورات المستمرة في التقنيات اللاسلكية في إنتاج تحديات وفرص جديدة للشبكات المتنقلة.
التهام السحابة للإنترنت
السحابة والإنترنت أنظمة تكافلية. لقد كانا مختلفين تاريخيًا، لكن الخط الفاصل بينهما أصبح غامضًا بشكل متزايد اليوم. يوفّر الإنترنت اتصالًا شاملًا بين أي مضيفين (حاسوب محمول للعميل وجهاز خادم بعيد على سبيل المثال)، وتدعم السحابة عدة مراكز بيانات بحجم المستودع، يوفر كلٌّ منها تكلفةً فعالة لتبريد وتشغيل عددٍ كبير من أجهزة الخادم. يتصل المستخدمون النهائيون بأقرب مركز بيانات عبر الإنترنت بنفس الطريقة التي يتصلون بها بخادم في غرفة آلةٍ بعيدة.
هذا وصف دقيق للعلاقة بين الإنترنت والسحابة في الأيام الأولى لمزودي خدمات السحابة التجارية، مثل: Amazon، وMicrosoft، وGoogle. كان لسحابة Amazon مثلًا في عام 2009 مركزان للبيانات، أحدهما على الساحل الشرقي للولايات المتحدة والآخر على الساحل الغربي. يشغّل كل من مزودي الخدمات السحابية الرئيسيين عشرات من مراكز البيانات المنتشرة في جميع أنحاء العالم اليوم، ولا ينبغي أن يكون مفاجئًا أنهم يقعون في موقع استراتيجي بالقرب من نقاط تبادل الإنترنت Internet Exchange Points أو اختصارًا IXP، والتي توفر كل واحدة منها اتصالًا غنيًا ببقية الإنترنت. يوجد أكثر من 150 نقطة IXP في جميع أنحاء العالم، وعلى الرغم من عدم قيام كل مزود خدمة سحابية بتكرار مركز بيانات كامل بالقرب من كل واحد (العديد من هذه المواقع عبارة عن مرافق مشتركة في الموقع)، فمن العدل أن نقول إنه من المحتمل أن يُوزَّع المحتوى السحابي الأكثر استخدامًا (أفلام نتفليكس Netflix، مثلًا، الأكثر شهرة ومقاطع فيديو يوتيوب YouTube وصور فيسبوك Facebook على العديد من المواقع.
هناك نتيجتان لهذا التشتت الواسع للسحابة. الأول هو أن المسار من طرف إلى طرف من عميل إلى خادم لا يمر بالضرورة عبر الإنترنت بالكامل. من المحتمل أن يجد المستخدم المحتوى الذي يريد الوصول إليه قد نُسِخ في نقطة اتصالٍ قريبة، والتي عادة ما تكون مجرد قفزة نظام AS واحدة بدلًا من أن تكون في الجانب البعيد من الكرة الأرضية. النتيجة الثانية هي أن مزودي الخدمات السحابية الرئيسيين لا يستخدمون الإنترنت العام لربط مراكز البيانات الموزعة الخاصة بهم. من الشائع لمزودي الخدمات السحابية الحفاظ على المحتوى الخاص بهم متزامنًا عبر مراكز البيانات الموزعة، لكنهم يفعلون ذلك عادةً عبر شبكة رئيسية backbone خاصة. هذا يسمح لهم بالاستفادة من أي تحسينات يريدونها دون الحاجة إلى التفاعل الكامل مع أي شخص آخر.
يتيح بروتوكول BGP إمكانية توصيل أي زوجٍ من المضيفين، ويتفاعل معظم المستخدمين عمليًا مع التطبيقات التي تعمل في السحابة، والتي تبدو أشبه بالشكل التالي. (أحد التفاصيل المهمة التي لا ينقلها الشكل هي أن مزودي الخدمات السحابية لا يقومون عادةً ببناء شبكة WAN من خلال وضع الألياف الخاصة بهم، ولكنهم بدلًا من ذلك يستأجرون الألياف من مزودي الخدمة، مما يعني أن الشبكة الرئيسية للسحابة الخاصة والشبكة الرئيسية لمزود الخدمة غالبًا ما تشتركان في نفس البنية التحتية المادية).
لاحظ أنه على الرغم من إمكانية نسخ المحتوى عبر العديد من مواقع السحابة، إلا أننا لا نمتلك التقنية اللازمة لنسخ الأشخاص حتى الآن. هذا يعني أنه عندما يرغب المستخدمون المنتشرون على نطاق واسع في التحدث مع بعضهم البعض، كجزء من مكالمة جماعية عبر الفيديو على سبيل المثال، فإن شجرة البث المتعدد تُوزَّع عبر السحابة. لا يُشغَّل البث المتعدد عادةً في الموجهات الخاصة بالشبكة الرئيسية لمزود الخدمة، ولكنه يعمل بدلًا من ذلك في عمليات الخادم الموزَّعة عبر مجموعةٍ فرعية من أكثر من 150 موقعًا تعمل كنقاط اتصال الإنترنت الرئيسية. تسمى شجرة البث المتعدد المُنشأَة بهذه الطريقة باسم التراكب overlay.
اقتباسنوصي بما يلي لمعرفة المزيد حول التحول الذي يحدث في شبكات الوصول: How the Internet Travels Across theOcean, New York Times, March 2019
ترجمة -وبتصرّف- للقسم Routing Among Mobile Devices من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.