الخلاصة

  • يقدّم سجلا A وAAAA عناوين مرشحة، ولا يثبتان أن المسار المقابل قابل للوصول من ذلك العميل في تلك اللحظة.
  • جعل RFC 6555 أفضلية IPv6 مهلة تقدم محدودة، ثم نظّم RFC 8305 العملية عبر استعلامات DNS غير متزامنة، وترتيب RFC 6724، ومداخلة العائلتين، ومحاولات تبدأ بفواصل محسوبة.
  • يفوز أول اتصال يكتمل بهذه الجلسة فقط. يحمي الرجوع السريع المستخدم، لكنه قد يخفي عن المشغّل عائلة بروتوكول معطلة على نحو دائم.

كان العنوان صحيحاً لكن الطريق غائباً

صاغ RFC 1671 المشكلة عام 1994، قبل ظهور الاسم اللطيف بسنوات. يستطيع DNS إعادة IPv4 وIPv6 معاً، لكنه لا يرى موجّهاً وسيطاً يسقط IPv6، ولا نفقاً متوقفاً، ولا خدمة لم تعد تستجيب على عنوان AAAA في اللحظة الحالية.

لا يكذب سجل الاسم بالضرورة؛ فهو يعلن مرشحاً. الخطأ هو اعتباره شهادة على الوصول.

كانت التطبيقات تجرب القائمة بالتتابع. تبدأ بعنوان IPv6 المفضل، تنتظر إعادة إرسال SYN مرات عدة، ثم تنتقل إلى IPv4 العامل. وهكذا بدا الجهاز ذو المكدسين أبطأ من جهاز IPv4 القديم. إيقاف IPv6 يزيل التأخير، فيتحول عيب الانتقال إلى حافز عملي ضد الانتقال نفسه.

إنشاء اسم منفصل لـIPv6 يقسم الاسم الذي يتبادله الناس. والقوائم الثابتة لا تلحق بالأعطال المتقطعة ولا باختلاف المسارات بين العملاء. الدليل الناقص لا يظهر إلا عند محاولة الاتصال من الحافة.

الأولوية تمنح البداية لا حق التعطيل

وحّد RFC 6555 Happy Eyeballs عام 2012. لم يجعل IPv4 وIPv6 متساويين في سباق أعمى. بقيت سياسة اختيار العنوان، وغالباً ما وضعت IPv6 أولاً. لكن عندما لا يكتمل الخيار المفضل بسرعة، تبدأ محاولة في العائلة الأخرى فيما قد تبقى الأولى جارية.

تختار السياسة من يبدأ، ويختار الاختبار الفعلي من يحمل هذا الاتصال. بهذا الفصل يمكن دعم وجهة الانتقال البعيدة من دون إجبار المستخدم على تحمل كل عطل قريب.

المحاولة الثانية لها كلفة. فهي تنشئ حالة في الخادم والجدار الناري وNAT، وتستهلك منفذاً وحركة إضافية. لذلك تُباعد المحاولات ويُلغى الخاسر بعد نجاح واحد. لو كان الأسرع يفوز دائماً بلا ميل أولي، لاستمر الحمل غير الضروري على IPv4 المشترك؛ ولو احتكر IPv6 زمن الانتظار، لدفع المستخدم ثمن فشل لا يسيطر عليه.

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

النسخة الثانية أدخلت DNS في التجربة

حل RFC 8305 محل الوصف الأول عام 2017 بعد خبرة في التنفيذ والقياس. قسّم الإعداد إلى بدء استعلامات DNS بصورة غير متزامنة، وترتيب الوجهات، وبدء محاولات متداخلة، ثم الاحتفاظ باتصال واحد وإلغاء البقية.

يرسل العميل استعلامي AAAA وA واحداً بعد الآخر تقريباً، ويبدأ بـAAAA. إذا وصل A أولاً ينتظر زمناً قصيراً موصى به مقداره 50 ملي ثانية، حتى يحظى جواب IPv6 المتأخر قليلاً بفرصة الحفاظ على الأفضلية. بعدها يستطيع استخدام IPv4 الموجود من دون انتظار الجوابين معاً.

تُرتب العناوين المتاحة وفق RFC 6724. تؤثر عناوين المصدر الصالحة والنطاق والوسوم وسياسة الجهاز في الترتيب. لكنها تصنع قائمة معقولة، لا ضمان وصول.

ثم تتداخل العائلتان. إذا كان IPv6 أولاً، ينتقل أفضل عنوان IPv4 عادة إلى المركز الثاني. لا يضطر العميل إلى استنفاد سلسلة طويلة من عناوين AAAA المعطلة قبل إعطاء أول A فرصة.

تبدأ المحاولات واحدة بعد أخرى مع بقاء السابق جارياً. يوصي RFC 8305 بفاصل افتراضي 250 ملي ثانية، ويحظر بدء التالية خلال أقل من 10 ملي ثانية، ويوصي بحد أدنى 100 ملي ثانية وحد أقصى ثانيتين. إنها إعدادات تجريبية قابلة للتغيير وليست ثوابت كونية.

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

الفوز بالمصافحة لا يمنح حقيقة أوسع

يعالج Happy Eyeballs فشل إنشاء الاتصال الأولي. نجاح مصافحة TCP لا يضمن صلاحية TLS، ولا اتساق HTTP، ولا مرور الرزم الكبيرة. يذكر RFC 8305 صراحة أن عطل MTU قد يظهر بعد المصافحة، خارج نافذة الاختيار.

ولا يوثق عنوان IP الفائز هوية الخدمة. تتغير نتائج DNS وقد تستخدم اتصالات متعاقبة إلى الاسم نفسه عناوين مختلفة. يجب أن يأتي إثبات الهوية من الطبقة التي تعرف من تتوقعه.

أما المفارقة التشغيلية فهي أن النجاح يخفي الفشل. إذا تعطل IPv6 كل يوم وتولى IPv4 بعد ربع ثانية، فلن يشتكي المستخدم غالباً. أصلح العميل التجربة ولم يصلح الشبكة. لذلك يوصي RFC 8305 بمراقبة مستقلة لكل عائلة.

المصادر والحدود

المجموعة المغلقة هي RFC 1671، وRFC 6555، وRFC 6724، وRFC 8305. لا تقيس الانتشار الحالي، ولا تحدد زمناً مثالياً لكل شبكة، ولا تثبت تفوق عائلة عالمياً.