لماذا يظهر IPv4 في تطبيق بينما يستخدم تطبيق آخر IPv6؟ لفهم الإجابة يجب فصل DNS وترتيب الوجهات ومحاولات الاتصال ونجاح HTTPS. يقدم هذا الدليل تفسيرًا قائمًا على RFC 8305، وتجربة قابلة للتكرار لا تتطلب تعطيل بروتوكولات الشبكة.
المشكلة التي تحلها الآلية
عند كتابة عنوان موقع في المتصفح قد يحصل الجهاز على عنوان IPv4 من سجل A وعلى عنوان IPv6 من سجل AAAA. وجود العنوانين لا يعني أن كلا الطريقين قابل للوصول أو أن زمن الاتصال متساوٍ؛ فقد تكون شبكة المنزل تدعم IPv6 ظاهريًا لكن التوجيه الخارجي متعثر، أو يكون مسار IPv4 مزدحمًا. لو انتظر التطبيق انتهاء مهلة الاتصال الأولى بالكامل قبل تجربة الأخرى، يمكن أن تتأخر الصفحة رغم وجود مسار سليم. خوارزمية Happy Eyeballs تقلل هذا الأثر بمحاولات منظمة ومتداخلة زمنيًا. هدفها ليس تفضيل عنوان أسرع دائمًا بأي ثمن، بل إنشاء اتصال صالح بسرعة مع تجنب إطلاق عدد غير محدود من الاتصالات المتزامنة. وهذا يفسر لماذا قد يفتح المتصفح موقعًا سريعًا بينما تتأخر أداة أخرى على الجهاز نفسه.
الفرق بين حل الاسم واختيار الاتصال
يتعامل DNS مع الاسم والعناوين المتاحة، لكنه لا يخبر التطبيق تلقائيًا أي مسار سيعمل من جهاز المستخدم في هذه اللحظة. في بيئة ثنائية المكدس تُرسل استعلامات AAAA و A عادةً بصورة متقاربة، وقد تصل إحدى الإجابتين قبل الأخرى. توصي RFC 8305 بألا يتوقف إنشاء الاتصال على انتظار الإجابتين معًا؛ فلو تأخر أحدهما يمكن الاستفادة من الآخر. بعد وصول العناوين تأتي مرحلة ترتيب الوجهات ومحاولات الاتصال. هنا لا يكفي النظر إلى عنوان IP المعروض في أداة فحص، لأن العنوان الذي اختاره اتصال سابق ربما جاء من ذاكرة DNS أو من اتصال مفتوح أُعيد استخدامه. لاختبار السلوك يجب فصل زمن الاستعلام عن زمن المصافحة، وإجراء تجربة باردة مع تسجيل العنوان الفعلي لكل محاولة.
ماذا تقول RFC 8305 تحديدًا؟
تصف مواصفة Happy Eyeballs الإصدار الثاني آلية بدء محاولات اتصال متتابعة بفواصل زمنية تسمح بتداخل المحاولات غير المنتهية. تذكر المواصفة 250 ميلي ثانية قيمة افتراضية موصى بها لفاصل المحاولة عندما لا تتوافر بيانات تاريخية، لكنها ليست وعدًا بأن كل متصفح يستخدم الرقم نفسه. كذلك توصي بألا تُبدأ المحاولات كلها دفعة واحدة حتى لا يتضاعف الحمل على الشبكة. عند نجاح اتصال تُلغى المحاولات التي لم تنجح بحسب تصميم العميل. وقد تختلف تفاصيل التنفيذ في مكتبات النظام والتطبيقات الحديثة والبروكسيات. لذلك ينبغي عرض القيم على أنها توصيات في وثيقة معيارية لا إعدادات مؤكدة لكل نظام تشغيل. تغييرها عشوائيًا لا يحل مسار IPv6 معطلًا؛ بل قد يخفي العطل مؤقتًا.
مثال زمني يوضح القرار
تخيل جهازًا تلقى عنوان IPv6 سريعًا لكنه لم يستطع إكمال مصافحة TCP عبره. بدل انتظار مهلة طويلة، يبدأ العميل محاولة أخرى عبر IPv4 بعد فترة مناسبة إذا كانت لديه وجهة جاهزة. إذا اكتملت مصافحة IPv4 أولًا فقد يعتمدها، بينما يترك IPv6 لمحاولة لاحقة عند تغير ظروف الشبكة. وفي حالة أخرى ينجح IPv6 فورًا فلا داعي للانتقال إلى IPv4. هذه الأمثلة توضيحية وليست تسجيلًا من شبكة حقيقية. يجب التمييز بين اكتمال TCP وبين اكتمال TLS واستلام محتوى الصفحة؛ فقد ينجح الاتصال على أحد المسارين ثم يتعطل طلب HTTPS لسبب مختلف. عند قياس زمن تحميل الصفحة، ضع حدودًا واضحة لما تسميه نجاح الاتصال وما تسميه نجاح الطلب الكامل.
أسباب اختلاف النتيجة بين تطبيقين
قد يستخدم المتصفح مكتبة شبكة مستقلة بينما تعتمد أداة سطر الأوامر على محلل النظام، وقد يمر تطبيق آخر عبر VPN أو SOCKS5 أو Proxy HTTP. أحيانًا يحل البروكسي اسم الوجهة بنفسه، فتنتقل عملية اختيار IPv4 أو IPv6 إلى الخادم الوسيط بدل جهازك. وتؤثر كذلك إعادة استخدام الاتصالات و DNS-over-HTTPS وسياسات الشبكات المؤسسية في التوقيت والنتيجة. لذلك لا يمكن استنتاج أن برنامجًا لا يدعم IPv6 من مجرد اختلاف عنوان الاتصال النهائي. دوّن إصدار التطبيق وطريقة الاتصال وإعدادات البروكسي وحالة التخزين المؤقت، ثم كرر الاختبار تحت شروط متطابقة. إن كانت المشكلة في تطبيق واحد فقط، ابدأ بفحص إعداداته قبل تعطيل بروتوكول كامل على مستوى النظام.
تجربة تشخيص لا تتطلب تغيير النظام
اختر نطاقًا لديك إذن لاختباره، ثم تحقق من وجود سجلي A و AAAA. نفّذ طلب HTTPS عبر IPv4 وحده ثم عبر IPv6 وحده إن كان العميل يدعم التقييد، وسجل وقت حل الاسم ووقت الاتصال ووقت المصافحة ووقت أول بايت. أعد التجربة عدة مرات على اتصال سلكي ثم شبكة أخرى إن أمكن، مع ملاحظة أن نتائج الخادم البعيد تتغير بمرور الوقت. عند نجاح المسارين لكن تفاوت الزمن، راقب الوسيط والمئين 95 بدل أفضل نتيجة. وإذا فشل أحدهما، ابحث في سجلات الراوتر وإعلانات IPv6 ومسار مزود الخدمة. لا تستخدم اختبارات كثيفة أو حزم عشوائية تجاه أنظمة لا تملكها، ولا تغير إعدادات الشبكة الإنتاجية قبل الاحتفاظ بنسخة من القيم القديمة.
IPv6 يعمل جزئيًا: ماذا يعني ذلك؟
من الأخطاء الشائعة أن ينجح اختبار ping إلى وجهة IPv6 ثم يُفترض أن HTTPS سيعمل حتمًا. بروتوكول ICMP ليس بديلًا عن اختبار TCP أو QUIC، وقد توجد سياسة جدار ناري أو مشكلة في DNS أو TLS أو المسار الخاص بالخدمة. والعكس صحيح: قد يمنع الخادم الرد على ping رغم أن صفحات HTTPS تعمل بلا مشكلة. راجع أيضًا إعدادات DNS64/NAT64 إذا كانت الشبكة من هذا النوع، لأن توليد العناوين وترجمة البروتوكولات يضيفان طبقة أخرى للتشخيص. المطلوب بناء سلسلة أدلة تبدأ من حل الاسم وتنتهي باستجابة التطبيق، مع توضيح المرحلة التي تتعثر. هكذا يصبح طلب الدعم لمزود الخدمة محددًا بدل الاكتفاء بعبارة «IPv6 لا يعمل».
جدول قرار بين ثلاثة أعطال
إذا تأخر AAAA فقط بينما A سريع، فاختبر محلل DNS ووقت وصول الإجابتين ولا تفترض أن المسار IPv6 نفسه بطيء. إذا وصل العنوانان بسرعة لكن مصافحة IPv6 تفشل، فافحص التوجيه والجدار الناري وإعلانات الشبكة. وإذا نجحت المصافحتان لكن TTFB مرتفع، فانتقل إلى الخادم أو التطبيق أو شبكة CDN بدل تغيير ترتيب العناوين. وفي حالة عمل المتصفح وفشل عميل API، قارن إعدادات البروكسي وإعادة استخدام الاتصال ونسخة مكتبة الشبكة. هذه الحالات ليست حصرًا لكل الأسباب؛ إنها طريقة لتحديد التجربة التالية دون الوقوع في استنتاج مبكر. حافظ على سجل يحوي وقت القياس وعنوان الوجهة والنتيجة حتى تقارن الحالات لاحقًا.
متى يكون تعديل تفضيل البروتوكول مبررًا؟
قد يحتاج مسؤول الشبكة إلى إجراء مؤقت حين يكون مسار معين متعطلًا ويؤثر في المستخدمين، لكن تعطيل IPv6 بالكامل قرار واسع الأثر قد يضر خدمات أخرى ويخفي المشكلة. الأفضل إصلاح التوجيه أو DNS أو سياسات الجدار الناري أولًا، ثم إعادة اختبار العميل. إذا كان تطبيق معين لا يطبق Happy Eyeballs بصورة مناسبة، فراجع إعداداته أو حدّث مكتبة الاتصال بعد اختبار توافقها. لا تغيّر قيم الفواصل الزمنية اعتمادًا على مثال من منتدى دون معرفة كيفية تعامل التنفيذ مع الحمل والمهل. بعد أي تعديل، اختبر زمن الاتصال ونسبة الفشل واستهلاك الاتصالات على أكثر من شبكة، لا على جهاز واحد فقط.
منهج مقارنة قبل الإصلاح وبعده
أنشئ جدولًا لعدد من المحاولات موزعة على أوقات مختلفة، مع تسجيل DNS و TCP و TLS و TTFB والعنوان الذي نجح. قارن نسبة الفشل والوسيط والمئين 95، ثم راجع إن كان التحسن مرتبطًا فعلاً باختيار المسار أو بعامل آخر مثل تغيير CDN أو انتهاء ازدحام مؤقت. حافظ على نفس اسم النطاق ونوع الطلب بقدر الإمكان. إذا تغير إصدار المتصفح أو شبكة الاتصال أثناء التجربة، سجّل ذلك كمتغير إضافي. النجاح الحقيقي يعني اتصالًا أسرع وأكثر استقرارًا دون زيادة غير مبررة في المحاولات أو تعطل IPv6 في الخدمات الأخرى. يمكن الاستفادة من مقال إيجي تاج عن <a href='/ar/articles/packet-loss-dns-tls-network-diagnostics'>فقد الحزم وتأخر DNS و TLS</a> لاستكمال تحليل المراحل.
أسئلة شائعة وخلاصة عملية
هل يعني ظهور IPv4 أن IPv6 فشل؟ ليس بالضرورة؛ فقد يكون اختيارًا ناجحًا وفق ترتيب الوجهات أو بيانات العميل أو إعداد البروكسي. هل تحسن سرعة DNS يضمن سرعة فتح الموقع؟ لا، لأن المصافحة واستجابة الخادم وتحميل الموارد مراحل مستقلة. هل يمكن الاعتماد على اختبار واحد؟ لا، لأن المسارات والذاكرة المؤقتة وحالة الشبكة تتغير. الخلاصة: ابدأ بقياس مساري العناوين، وافصل DNS عن الاتصال الفعلي، ثم حدد المرحلة التي تسبب التأخر قبل تغيير أي إعداد. المصدر الأساسي هو RFC 8305 الصادرة عن IETF: https://www.rfc-editor.org/info/rfc8305/، وهي مرجع لتصميم الخوارزمية وليست شهادة أداء لتطبيق أو مزود بعينه.
الجدول إرشادي ولا يغني عن سجل القياسات
| AAAA متأخر | حل أسماء | قياس DNS منفصلًا |
| IPv6 يفشل عند TCP | توجيه أو جدار ناري | مراجعة المسار |
| TLS متأخر في العائلتين | مصافحة أو خادم | تحليل TLS و TTFB |
| تطبيق يختلف عن آخر | إعدادات العميل أو البروكسي | مقارنة مسارات الاتصال |
قائمة اختبار مختصرة
- تحقق من A و AAAA
- سجل زمن DNS
- اختبر IPv4 وحده
- اختبر IPv6 وحده
- قارن TCP و TLS و TTFB
- كرر القياس على أكثر من شبكة
- اختبر أي تعديل مع مراقبة التراجع
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…