ايف على الانترنت هي لعبة ممتعة. هذا واحد من MMOs القليلة التي يوجد فيها "خادم" واحد فقط للدخول ، مما يعني أن كل شخص يلعب في نفس العالم المنطقي. لديها أيضًا مجموعة مثيرة من الأحداث التي حدثت داخل اللعبة ، كما أنها لا تزال لعبة جذابة للغاية:
هناك أيضًا خريطة عالمية شاملة يمكن لجميع اللاعبين تلبيتها. في ذروتها ، كان لدى EvE 63000 لاعب عبر الإنترنت في عالم واحد مع 500000 اشتراك مدفوع مسجل في ذروة الشعبية ، وعلى الرغم من أن هذا العدد يتناقص كل عام ، إلا أن العالم لا يزال كبيرًا بشكل لا يصدق. هذا يعني أن الانتقال من جانب إلى آخر هو مقدار كبير من الوقت (بالإضافة إلى المخاطرة بسبب اعتماد اللاعب على الكسر).
تم دعم الترجمة بواسطة شركة EDISON Software ، وهي شركة أمنية محترفة ، وتقوم أيضًا بتطوير أنظمة التحقق الطبي الإلكترونية .أنت تسافر إلى مناطق مختلفة باستخدام وضع الالتواء (داخل نفس النظام) ، أو الانتقال إلى أنظمة مختلفة باستخدام بوابات التنقل:
وتجتمع كل هذه الأنظمة لإنشاء خريطة للجمال والتعقيد:
لطالما اعتبرت هذه البطاقة بمثابة شبكة ، فهي شبكة كبيرة من الأنظمة التي تتصل ببعضها البعض حتى يتمكن الأشخاص من المرور بها ، ومعظم الأنظمة بها أكثر من بوابتين للتنقل. لقد جعلني أفكر في ما يمكن أن يحدث إذا أخذت حرفيًا فكرة الخريطة كشبكة؟ كيف سيبدو نظام EvE Internet؟
للقيام بذلك ، نحتاج إلى فهم كيفية عمل الإنترنت الحقيقي. الإنترنت عبارة عن مجموعة كبيرة من موفري الإنترنت الذين تم تحديدهم رقميًا باستخدام رقم موفر إنترنت قياسي وفريد ، يسمى رقم نظام الحكم الذاتي أو ASN (أو AS للإصدار الأقصر). تحتاج ملفات ASS هذه إلى طريقة لتبادل الطرق مع بعضها البعض ، لأنهم سيمتلكون نطاقات من عناوين IP ، ويحتاجون إلى وسيلة لإخبار مقدمي خدمات الإنترنت الآخرين بأن أجهزة التوجيه الخاصة بهم يمكنها توجيه عناوين IP هذه. للقيام بذلك ، توقف العالم على بروتوكول بوابة الحدود أو BGP.
تعمل BGP من خلال "إخبار" AS AS (المعروفة باسم المضيف) بطرقها:
السلوك القياسي لـ BGP عندما يستقبل مسارًا من مضيف هو إعادة توجيهه إلى جميع المضيفين الآخرين المتصلين به أيضًا. هذا يعني أن العقد ستقوم تلقائيًا بمشاركة جداول التوجيه الخاصة بها مع بعضها البعض.
ومع ذلك ، يكون هذا السلوك مفيدًا فقط إذا كنت تستخدم BGP لإرسال مسارات إلى أجهزة التوجيه الداخلية ، نظرًا لأن الإنترنت الحديث له علاقات منطقية مختلفة مع بعضها البعض. بدلاً من الشبكة ، يبدو الإنترنت الحديث مثل هذا:
ومع ذلك ، يتم تثبيت EvE عبر الإنترنت في المستقبل. من يعرف ما إذا كانت الإنترنت تعتمد على نظام التوجيه هذا لتحقيق الربح. دعنا نتخيل أن هذا ليس صحيحًا حتى نتمكن من معرفة كيفية تحجيم BGP في الشبكات الأكبر حجمًا.
للقيام بذلك ، نحتاج إلى محاكاة السلوك الفعلي لجهاز التوجيه BGP والاتصال. بالنظر إلى أن EvE لديه عدد منخفض نسبيا 8000 ~ من النظم ، و 13.8 ألف الروابط بينهما. اقترحت أنه سيكون من المستحيل في الواقع تشغيل 8000 ~ أجهزة افتراضية باستخدام BGP حقيقي وشبكة لمعرفة كيف تبدو هذه الأنظمة الحقيقية عندما تعمل معًا كشبكة.
ومع ذلك ، ليس لدينا موارد غير محدودة ، لذلك سنحتاج إلى إيجاد طريقة لجعل أصغر صورة Linux عند استخدام مساحة القرص واستخدام الذاكرة. ولهذا ، لفتت الانتباه إلى الأنظمة المدمجة ، نظرًا لأن الأنظمة المدمجة غالبًا ما تعمل في بيئات ذات مستوى موارد منخفض للغاية. صادفت
Buildroot ، وبعد بضع ساعات كان لدي صورة Linux صغيرة تحتوي فقط على ما أحتاجه لكي يعمل هذا المشروع.
$ ls -alh total 17M drwxrwxr-x 2 ben ben 4.0K Jan 22 22:46 . drwxrwxr-x 6 ben ben 4.0K Jan 22 22:45 .. -rw-r--r-- 1 ben ben 7.0M Jan 22 22:46 bzImage -rw-r--r-- 1 ben ben 10M Jan 22 22:46 rootfs.ext2
تحتوي هذه الصورة على نظام تشغيل لينوكس ، والذي يحتوي أيضًا على: *
Bird 2 BGP Daemon *
tcpdump و My Traceroute (mtr) لتصحيح أخطاء الشبكة * صندوق البريد
للغطاء الأساسي وأدوات النظام المساعدة
يمكن تشغيل هذه الصورة بسهولة في qemu مع بعض الخيارات:
qemu-system-i386 -kernel ../bzImage \ -hda rootfs.ext2 \ -hdb fat:./30045343/ \ -append "root=/dev/sda rw" \ -m 64
للعمل على الشبكة ، قررت استخدام وظيفة غير موثقة من qemu (في الإصدار الخاص بي) ، حيث يمكنك توجيه عمليتي qemu لبعضهما البعض واستخدام مآخذ UDP لنقل البيانات بينهما. هذا مناسب ، نظرًا لأننا نخطط لتوفير عدد كبير من الروابط ، لذا فإن استخدام طريقة محول
TUN / TAP المعتادة يمكن أن يؤدي سريعًا إلى التشويش.
نظرًا لأن هذه الميزة غير موثقة جزئيًا ، فقد حدثت بعض المشكلات في تشغيلها. استغرق الأمر وقتًا طويلاً لفهم أن اسم الشبكة على سطر الأوامر يجب أن يكون هو نفسه لكلا وجهي الاتصال. تبين فيما بعد أن هذه الوظيفة موثقة جيدًا بالفعل ، كما يحدث عادة. تستغرق التغييرات وقتًا للوصول إلى الإصدارات الأقدم من التوزيع.
بمجرد أن نجح ذلك ، حصلنا على اثنين من الأجهزة الافتراضية التي يمكنها إرسال حزم إلى بعضها البعض ، ويرسلها برنامج hypervisor في صورة مخططات بيانات UDP. نظرًا لأننا سنطلق عددًا كبيرًا من هذه الأنظمة ، فسوف نحتاج إلى طريقة سريعة لتكوينها باستخدام تكوين تم إنشاؤه مسبقًا. للقيام بذلك ، يمكننا استخدام وظيفة qemu المريحة ، والتي تتيح لك أخذ دليل على برنامج hypervisor وتحويله إلى نظام ملفات افتراضي FAT32. هذا مفيد لأنه يسمح لنا بإنشاء دليل لكل نظام نخطط لبدء تشغيله ، وكل عملية qemu تشير إلى هذا الدليل ، مما يعني أنه يمكننا استخدام نفس صورة التمهيد لجميع الأجهزة الافتراضية في المجموعة.
نظرًا لأن كل نظام يحتوي على 64 ميغابايت من ذاكرة الوصول العشوائي ، ونخطط لاستخدام 8000 ~ VMs ، فسنحتاج بالتأكيد إلى قدر مناسب من ذاكرة الوصول العشوائي. لهذا ، استخدمت 3 m2.xlarge.x86 مع packet.net ، لأنها توفر 256 جيجابايت من ذاكرة الوصول العشوائي مع 2x Xeon Gold 5120 ، مما يعني أن لديهم قدرًا كبيرًا من الدعم.
لقد استخدمت
مشروعًا آخر مفتوح المصدر لإنشاء خريطة EvE في شكل JSON ، ثم قمت بإنشاء برنامج تهيئة مخصص يستند إلى هذه البيانات. بعد إجراء عدة تجارب تشغيل لعدد قليل من الأنظمة ، أثبتت أنها يمكن أن تأخذ التكوين من VFAT وإنشاء جلسات BGP مع بعضها البعض حول هذا.
لذلك ، اتخذت خطوة حاسمة نحو تحميل الكون:
في البداية ، حاولت تشغيل جميع الأنظمة في حدث واحد كبير ، لكن ، لسوء الحظ ، أدى ذلك إلى انفجار كبير من حيث تحميل النظام ، لذلك بعد ذلك تحولت إلى بدء تشغيل النظام كل 2.5 ثانية ، وتولى 48 مركز النظام هذا في النهاية.
أثناء عملية التمهيد ، اكتشفت أنك سترى "انفجارات" كبيرة لاستخدام وحدة المعالجة المركزية على جميع الأجهزة الظاهرية ، فيما بعد اكتشفت أن هذه الأجزاء كبيرة من الكون تتصل ببعضها البعض ، مما تسبب في حدوث كميات كبيرة من حركة مرور BGP على جانبي الشبكة الافتراضية المتصلة حديثًا السيارات.
root@evehyper1:~/147.75.81.189# ifstat -i bond0,lo bond0 lo KB/s in KB/s out KB/s in KB/s out 690.46 157.37 11568.95 11568.95 352.62 392.74 20413.64 20413.64 468.95 424.58 21983.50 21983.50
في النهاية ، رأينا بعض مسارات BGP المذهلة ، حيث أن كل نظام يعلن / 48 عنوان IPv6 ، يمكنك رؤية الطرق المؤدية إلى كل نظام وإلى جميع الأنظمة الأخرى التي سيتعين عليها المرور للوصول إلى هناك.
$ birdc6 s ro all 2a07:1500:b4f::/48 unicast [session0 18:13:15.471] * (100) [AS2895i] via 2a07:1500:d45::2215 on eth0 Type: BGP univ BGP.origin: IGP BGP.as_path: 3397 3396 3394 3385 3386 3387 2049 2051 2721 2720 2719 2692 2645 2644 2643 145 144 146 2755 1381 1385 1386 1446 1448 849 847 862 867 863 854 861 859 1262 1263 1264 1266 1267 2890 2892 2895 BGP.next_hop: 2a07:1500:d45::2215 fe80::5054:ff:fe6e:5068 BGP.local_pref: 100
لقد التقطت لقطة لجدول التوجيه على كل جهاز توجيه في الكون ، ثم صورت الأنظمة المستخدمة بشكل شائع للوصول إلى الأنظمة الأخرى ، ولكن هذه الصورة ضخمة. إليك نسخة صغيرة من ذلك في المنشور ، إذا قمت بالنقر فوق صورة ، ضع في اعتبارك
أن هذه الصورة ستؤدي على الأرجح إلى نفاد ذاكرة جهازك
بعد ذلك ، حسب اعتقادي ، ماذا يمكنك تعيين شبكات BGP الموجهة؟ هل يمكنك استخدام نموذج أصغر لاختبار كيفية عمل تكوين التوجيه على الشبكات الكبيرة؟
قمت بإعداد ملف يعرض نظام London Underground للتحقق من ذلك :
نظام TFL أصغر بكثير وله العديد من القفزات التي لها اتجاه واحد فقط ، لأن معظم المحطات لديها "خط" واحد للنقل ، ومع ذلك يمكننا تعلم شيء واحد من هذا ، يمكننا استخدام هذا للعب بأمان مع
BGP MED .
ومع ذلك ، هناك مشكلة عندما ننظر إلى بطاقة TFL كشبكة BGP ، في الوقت الفعلي ، لا يكون الوقت / التأخير بين كل محطة هو نفسه ، وبالتالي ، إذا قمنا بمحاكاة هذا التأخير ، فلن ندور حول النظام بأسرع ما يمكن ، ونحن ننظر فقط إلى أصغر عدد من المحطات للذهاب في الطريق.
ومع ذلك ، بفضل قانون حرية المعلومات (FOIA) ، فإن الطلب الذي تم إرساله إلى
TFL زودنا بالوقت اللازم للانتقال من محطة إلى أخرى. تم إنشاؤها في تكوين جهاز توجيه BGP ، على سبيل المثال:
protocol bgp session1 { neighbor 2a07:1500:34::62 as 1337; source address 2a07:1500:34::63; local as 1337; enable extended messages; enable route refresh; ipv6 { import filter{ bgp_med = bgp_med + 162; accept; }; export all; }; } protocol bgp session2 { neighbor 2a07:1500:1a::b3 as 1337; source address 2a07:1500:1a::b2; local as 1337; enable extended messages; enable route refresh; ipv6 { import filter{ bgp_med = bgp_med + 486; accept; }; export all; }; }
في
session1 الفاصل الزمني بين محطتين هو 1.6 دقيقة ، والعكس الآخر من هذه المحطة هو 4.86 دقيقة. تتم إضافة هذا الرقم إلى المسار لكل محطة / جهاز توجيه يمر عبره. هذا يعني أن كل جهاز توجيه / محطة على الشبكة يعلم أن الوقت قد حان للوصول إلى كل محطة عبر كل مسار:
هذا يعني أن التتبع يحدد بالضبط كيف يمكنك السفر في جميع أنحاء لندن ، على سبيل المثال ، إلى محطة Paddington الخاصة بي:
يمكننا أيضًا الاستمتاع ب BGP من خلال محاكاة الصيانة أو وقوع حادث في محطة Waterloo:
وبما أن الشبكة بالكامل تختار على الفور المسار الأسرع التالي ، وليس المسار الذي يحتوي على أقل عدد من محطات المرور.
وهذا هو سحر BGP MED في التوجيه!
رمز كل هذا متاح بالفعل. يمكنك إنشاء هياكل الشبكة الخاصة بك باستخدام نظام JSON بسيط إلى حد ما أو مجرد استخدام EvE عبر الإنترنت أو TFL ، حيث إنها موجودة بالفعل في المستودع.
يمكنك العثور على كل رمز لهذا هنا