«Happy Eyeballs» وصفقة ربع الثانية بين IPv6 وIPv4

الخلاصة

• قدّم RFC 6555 عام 2012 سباقاً قصيراً بين عائلتي العناوين، ثم استبدله RFC 8305 عام 2017 بجدولة متكاملة تبدأ من DNS وتنتهي بإلغاء المحاولات الخاسرة.
• التأخير الافتراضي الموصى به، 250 ملي ثانية، يوزع الكلفة بين انتظار المستخدم والحمل الناتج عن اتصالات استباقية متوازية.
• تعالج الآلية فشل الاتصال الأولي على مستوى TCP/IP، لكنها لا تصلح التطبيق أو المسار الخاسر، وقد تجعل الأعطال أقل وضوحاً للمشغلين.

بدأت مشكلة Happy Eyeballs من فجوة بين التفضيل الهندسي والنتيجة التي يراها الإنسان. يحصل الجهاز مزدوج المكدس على وجهات IPv6 وIPv4، ويفضل IPv6 كما تقضي بنية الانتقال، ثم ينتظر إذا كان ذلك المسار بطيئاً أو معطلاً، مع أن IPv4 قد يكون صالحاً. نشر RFC 6555 بصفة Proposed Standard في أبريل 2012، وحوّل ثمن هذا الانتظار من المستخدم إلى قرار داخل العميل.

كان المثال بسيطاً عن قصد. يحتفظ العميل بترتيب تفضيل العناوين، ويبدأ الاتصال الأول، ثم ينتظر مدة قصيرة قبل تشغيل أول عنوان من العائلة الأخرى. كان Firefox وChrome يستخدمان 300 ملي ثانية. يحتفظ العميل بأول اتصال يكتمل ويلغي الآخر. وعند غياب التاريخ يبقى IPv6 هو المفضل، مع تحذير من توليد حمل IPv4 غير ضروري خلال انتقال طويل.

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

أثبت الانتشار والقياس أن الواقع لا يقتصر على عنوانين ومؤقت واحد. نشر RFC 8305 بصفة Proposed Standard في ديسمبر 2017 وأبطل RFC 6555. وقسم العملية إلى أربع مراحل مترابطة: استعلامات DNS غير متزامنة، وترتيب جميع عناوين الوجهة، ومحاولات اتصال غير متزامنة ومتباعدة زمنياً، ثم إبقاء اتصال ناجح واحد وإلغاء الباقي.

يبدأ السباق في DNS. يوصي RFC 8305 بإرسال استعلام AAAA أولاً ثم A فوراً، من دون انتظار نتيجة الأول. إذا وصلت إجابة A قبل غيرها، يمنح Resolution Delay الموصى به، وهو 50 ملي ثانية، إجابة AAAA فرصة قصيرة. ليست القاعدة انتظار الإجابتين دائماً، ولا ترك أسرع إجابة DNS تحسم العائلة آلياً. ويمكن إدخال إجابات جديدة تصل أثناء إنشاء الاتصال إلى قائمة المرشحين.

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

يوصي RFC 8305 بأن يكون Connection Attempt Delay الافتراضي 250 ملي ثانية. ويوصي بحد أدنى 100 ملي ثانية، ويفرض ألا يقل أبداً عن 10 ملي ثانية، ويوصي بحد أقصى ثانيتين. والقيمة الموصى بها لـFirst Address Family Count هي واحد. هذه قيم تجريبية قابلة للتعديل مع تطور الشبكات. تقليل التأخير يحسن زمن التراجع لكنه يزيد التوازي، وزيادته توفر الحمل لكنها تكشف خطأ التفضيل للمستخدم مدة أطول.

يشمل التصميم تعدد العناوين، وتغير إجابات DNS أثناء الإعداد، والمعلومات التاريخية، وشبكات IPv6-only التي تستخدم NAT64/DNS64. لكن حدوده واضحة: إنه يعالج فشل إنشاء اتصال TCP/IP الأولي. نجاح طبقة النقل لا يعني أن التطبيق سيعمل، والسباق لا يصلح المسار الذي خسر.

هنا تظهر مفارقة الرصد. أقر RFC 6555 بأن السباق يزيد صعوبة تشخيص الأعطال حسب عائلة العنوان. ويحتفظ RFC 8305 بالتحذير، بما في ذلك احتمال إخفاء مشكلات تشغيلية مثل MTU للمسار خلف مسار آخر ناجح. يرى المستخدم خدمة تعمل، بينما قد لا يتلقى المشغل المسؤول عن الخلل إشارة قوية تدفعه إلى التحقيق.

لذلك تمثل Happy Eyeballs صفقة توافق. يتحمل برنامج العميل قدراً صغيراً من العمل الاستباقي كي يحافظ على تفضيل IPv6 من دون تحويل المستخدم إلى مختبر لأعطال الانتقال. ويبقى IPv4 بوليصة تأمين، بما تحمله من ندرة وكلفة. وحين تنجح البوليصة بسرعة، تقل الشكاوى من IPv6 المتعطل ويترسخ سبب الاحتفاظ بـIPv4. تدير الخوارزمية الاتصال، لكنها لا تستطيع أن تقرر متى ينتهي الاعتماد.