في المقال السابق عن «بروتوكولات الإنترنت ونموذج الطبقات» رأيتَ أن طبقتين في القلب تقومان بأثقل العمل: واحدة تعنون وتوجّه، وأخرى تضمن الوصول. وهاتان هما IP وTCP، البروتوكولان اللذان أعطيا الإنترنت اسمه: TCP/IP. هذا المقال يفتحهما من الداخل.
والسؤال الذي يجيب عنه دقيق: كيف تُبنى مكالمة موثوقة لا يضيع منها حرف ولا يختلّ ترتيبها، فوق شبكة لا تضمن وصول شيء أصلًا؟ سترى كيف يتقاسم البروتوكولان العمل: IP يوصّل بأفضل جهد دون وعد، وTCP يبني الضمان فوقه بآليات ذكية. ثمّ يأتي دور UDP السريع الذي يتخلّى عن الضمان عمدًا، وQUIC الذي يعيد رسم هذا كلّه للويب الحديث.
وقبل فتحهما، تذكّر قرارا تصميميّا قديمًا: حين وضع فينت سيرف وبوب كان أساس هذا النظام سنة 1974، لم يجعلاه بروتوكولا واحدا، بل فصلا العنونة والتوصيل (IP) عن الموثوقية (TCP) عمدًا. وهذا الفصل هو ما أتاح لاحقًا أن يولد UDP بجوار TCP، وأن يظهر QUIC بعد عقود، دون أن يُمَسّ IP تحتهما. فبنيةُ «بروتوكولين لا واحد» كانت بذرة المرونة كلّها.
IP: العنوان والتوصيل بأفضل جهد
وظيفة بروتوكول الإنترنت (IP) شيئان: أن يمنح كل جهاز عنوانا فريدا، وأن يوصّل «الحِزَم» من المصدر إلى الوجهة عبر الشبكات والموجِّهات. لكنّه يفعل ذلك بفلسفة «أفضل جهد» (Best-Effort): يدفع الحزمة نحو وجهتها، دون أن يَعِد بأنها ستصل، ولا بأنها ستصل بالترتيب، ولا بأنها لن تتكرّر.[2] هو كساعي بريد يُلقي الرسالة في الطريق الصحيح ويمضي، لا يعود ليتأكّد أنها وصلت.
وقد يبدو هذا عيبا، لكنه قرار تصميميّ عبقريّ: إبقاء طبقة الإنترنت بسيطة وسريعة، وترك الضمان لمن يحتاجه في الطبقة الأعلى. فالشبكة الوسطى لا تحمل عبء التذكّر والتأكّد، وهذا ما جعلها تتوسّع إلى حجم الكوكب.
تشريح العنوان: الشبكة والمضيف
عنوان IPv4 رقم من 32 خانة ثنائية، يُكتب أربعة أعداد مثل 192.168.1.10. وليس العنوان كتلة واحدة، بل ينقسم قسمين: جزء يحدّد «الشبكة»، وجزء يحدّد «المضيف» داخلها، تمامًا كعنوان بريديّ فيه اسم الحيّ ورقم المنزل. ويفصل بينهما «قناع الشبكة» الذي يُكتب اختصارا بصيغة مثل /24 (تُسمّى CIDR)، تعني أن أول 24 خانة هي الشبكة والباقي للمضيفين.
وهذا التقسيم هو ما يجعل التوجيه ممكنا: لا يحتاج الموجِّه أن يعرف مكان كل جهاز في العالم، بل يكفيه أن يعرف اتجاه «الشبكة»، فيدفع الحزمة نحوها، وتتكفّل الشبكة المحلّية بإيصالها إلى المضيف الصحيح. ولولا هذا الاختصار لانهار التوجيه تحت عدد الأجهزة.
وبعض العناوين «خاصّة» محجوزة للشبكات الداخلية (مثل ما يبدأ بـ192.168 أو 10.)، لا تظهر على الإنترنت العامّ، بل يترجمها موجِّهك إلى عنوانه العامّ عبر آلية NAT التي سبق ذكرها. وحين لم تكفِ عناوين IPv4 الأربعة مليارات، جاء IPv6 بعنوان من 128 خانة يتّسع لعدد يفوق الحصر، وقد فصّلتُ ذلك في مقال URL.
ولم يكن IPv6 ترفا: فعناوين IPv4 نفدت رسميّا من المخزون المركزيّ، وما أبقى الإنترنت يعمل عليها هو حِيَل مثل NAT التي تُخفي شبكة كاملة خلف عنوان عامّ واحد. أمّا الحلّ الجذريّ فهو IPv6، وتبنّيه يتقدّم ببطء: بلغ نصيبه في قياس جوجل نصفَ المستخدمين، إذ تجاوز 50% لأوّل مرّة في أبريل 2026، على أنّ قياس APNIC لقدرة العالم على IPv6 كان 42% في اليوم نفسه. والفرق بين الرقمين هو الفرق بين ما يعدّه كلّ منهما: الأوّل نسبة من يصل إلى خدمات جوجل عبر IPv6 فعلًا، والثاني نسبة من يقدر على ذلك[5]. وتعمل أكثر الأنظمة بنمط «المكدّس المزدوج» الذي يحمل العنوانين معا، فتختار لكل اتصال ما هو متاح. ولهذا قد يكون لجهازك عنوانان في وقت واحد دون أن تشعر.
وهذا الاختيار ليس متروكا للحظّ، وله اسم ومواصفة: «العيون السعيدة» (Happy Eyeballs). يبدأ جهازك محاولته على IPv6، فإن لم تُجب في نحو 250 مِلّي ثانية، بدأ محاولة ثانية على IPv4 بالتوازي وأخذ بأوّل ما استجاب، مع تفضيل معلن لـIPv6 عند التساوي.[6] وقيمة هذا التدبير تظهر عند الخلل: لو انتظر جهازك مهلة IPv6 وحدها حتى تنقضي، لجلستَ أمام صفحة فارغة 20 إلى 30 ثانية قبل أن يجرّب IPv4.[6] فربع ثانية بدل نصف دقيقة، وأنت لا تشعر أنّ شيئا جرى.
وثمّة طبقة ثانية من ترجمة العناوين، فوق موجّهك، لا تملك أنت التحكّم بها: «الترجمة على مستوى المزوّد» (CGNAT). فمزوّد خدمة الإنترنت نفسه يضع آلاف المشتركين خلف حزمة صغيرة من العناوين العامّة، لأنّ المخزون المركزيّ نفد ولم يبقَ سبيل رخيص إلى عنوان عامّ لكلّ بيت.[7] ولهذا أثران تلمسهما بيدك. الأوّل أنّ عنوانك العامّ يشاركك فيه غرباء، فقد يمنعك موقع أو يطلب منك إثباتا بسبب فعل أحدهم. والثاني أنّ أحدا من الخارج لا يستطيع أن يبدأ اتصالا بجهازك، فتتعذّر عليك استضافة خادم في بيتك أو لعبة تستضيفها بنفسك، إذ ليس لك عنوان يُقصَد أصلًا.
وسؤال يسأله كثيرون ولا تجد جوابه في أكثر الشروح: لماذا يتغيّر عنواني؟ لأنّ العنوان في الغالب ليس ملكا لك، وإنّما مُستأجَر لمدّة. فحين يتّصل جهازك بالشبكة يطلب عنوانا من خادم DHCP عند موجّهك، فيمنحه واحدا مع مدّة محدّدة، ويجدّدها الجهاز قبل انتهائها.[8] فإن أطفأت الجهاز طويلا، أو أعدت تشغيل الموجّه، جاز أن تُمنَح غيره.
وينطبق الأمر على عنوانك العامّ أيضًا: أكثر المزوّدين المنزليّين يمنحون عنوانا متغيّرا، والعنوان الثابت خدمة تُطلب وتُدفَع، ولهذا تحتاج من يستضيف شيئا في بيته إلى «اسم ديناميكيّ» يتتبّع تغيّر عنوانه. فمن أراد أن يُعتمَد عليه، احتاج عنوانا يُعتمَد عليه.
وكيف تجد الحزمة طريقها؟ يحمل كل موجِّه «جدول توجيه» يربط الشبكات باتجاهاتها، فينظر إلى الجزء الشبكيّ من عنوان الوجهة، ويختار أطول تطابق يعرفه، ويدفع الحزمة قفزة واحدة نحوه، ثمّ يفعل الموجِّه التالي مثله، حتى تصل. ولأن لكل قفزة احتمالَ ازدحام أو خطأ، قد تضيع حزمة أو تتأخّر أو تصل تالفة، وهذا عين معنى «أفضل الجهد»: IP يحاول ولا يَعِد. ولاكتشاف التلف تحمل الحزمة «مجموع تحقّق» (Checksum) يحسبه المرسِل ويعيد المستقبِل حسابه، فإن اختلف عُرف أن البيانات تشوّهت فتُهمَل، لكنّ IP يكتفي بالاكتشاف، وأمّا معالجة الضياع فمتروكة لمن فوقه.
TCP: كيف يُصنَع الضمان فوق شبكة لا تضمن
إن كان IP لا يضمن شيئا، فمن أين تأتي الموثوقية التي تنقل بها ملفّا كاملا دون أن يفسد بايت واحد؟ من بروتوكول التحكّم بالنقل (TCP)، الذي يجلس فوق IP ويبني عليه قناة موثوقة مرتّبة.[1] وهو يفعل ذلك بسلسلة آليات متضافرة، تستحقّ أن تراها واحدة واحدة، فهي قلب البروتوكول.
أولا: المصافحة، فتح القناة
قبل أيّ بيانات، يفتح الطرفان قناة عبر «المصافحة الثلاثية»: يرسل العميل طلب فتح (SYN)، فيردّ الخادم بقبول وطلب مقابل (SYN-ACK)، فيؤكّد العميل (ACK). بهذه الرسائل الثلاث يتّفقان على أرقام البدء ويتأكّدان أن كلّا منهما قادر على الإرسال والاستقبال. ولماذا ثلاث لا اثنتان؟ لأن رسالتين تُثبتان اتجاها واحدا فقط؛ تحتاج كل جهة أن تُرسل رقم بدئها وأن تتلقّى إقرارا به، فلا يكتمل التزامن في الاتجاهين إلا بثلاث. وعند انتهاء المحادثة، تُغلَق القناة برسائل وداع منظّمة (FIN). فـTCP «موجّه بالاتصال»: له بداية ونهاية، لا مجرّد رسائل متناثرة.
وتحمل ترويسة كل مقطع TCP أدوات هذا العمل كلّها في حقول صغيرة: رقمَي منفذ المصدر والوجهة (ليعرف النظام أيّ تطبيق يخصّ المقطع)، ورقم التسلسل، ورقم الإقرار، ورايات التحكّم (SYN وACK وFIN وRST)، وحجم النافذة المتاح، ومجموع تحقّق للسلامة. هذه الحقول الصغيرة هي اللغة التي يتفاهم بها الطرفان لإدارة القناة من فتحها إلى إغلاقها.
ثانيًا: الترقيم والإقرار وإعادة الإرسال
هنا سرّ الموثوقية. يقطّع TCP بياناتك ويعطي كل جزء «رقم تسلسل»، فيعرف الطرف الآخر ترتيبها الصحيح ولو وصلت مبعثرة، ويكتشف أيّ جزء ناقص. ومع كل ما يستقبله، يرسل المستقبِل «إقرارا» (ACK) يقول: «وصلني حتى هنا». فإن لم يصل المرسِلَ إقرار خلال مهلة معيّنة، أو وصلته إقرارات مكرّرة تدلّ على فجوة، أعاد إرسال المفقود.[1] بهذه الحلقة، البيانات التي تضيع في شبكة «بأفضل جهد» تُكتشَف وتُعاد، حتى تكتمل سليمة مرتّبة.
ولنرَ ذلك في مثال: أرسلتَ الأجزاء 1 و2 و3 و4، فوصلت 1 و2 و4 وضاع 3. لا يبني المستقبِل على ما بعد الفجوة، بل يحتفظ بـ4 جانبا ويظلّ يقرّ أنه ما زال ينتظر 3. وحين تتكرّر هذه الإشارة، يفهم المرسِل أن 3 ضاع فيعيده وحده دون إعادة الباقي، فيُسدّ النقص فيلتئم التيار. هذا الانضباط الدقيق هو ما يجعلك تنزّل ملفّا بحجم غيغابايت عبر نصف الكوكب فيصل سليما بايتا بايتا.
ثالثًا: النافذة المنزلقة، السرعة دون فوضى
لو انتظر المرسِل إقرارا بعد كل جزء قبل إرسال التالي، لكان النقل بطيئا مؤلما. لذا يستعمل TCP «النافذة المنزلقة» (Sliding Window): يرسل عدّة أجزاء متتالية قبل أن ينتظر إقرارها، فتسير البيانات تيارا متّصلا لا قطرة قطرة. وحجم هذه النافذة ليس ثابتا، بل يضبطه أمران: حال المستقبِل، وحال الشبكة.
ولحجم النافذة أثر كبير على السرعة، خاصة عبر المسافات الطويلة. كلّما بعُدت الوجهة، طال زمن عودة الإقرار؛ فإن كانت النافذة صغيرة، بقي المرسِل عاطلا ينتظر، وضاعت سعة متاحة. لهذا تكبر النوافذ في TCP الحديث لتملأ «جداء السعة في زمن الذهاب والإياب»، فتستغلّ عرض النطاق كاملا حتى لو كان الخادم في قارّة أخرى. كما يتّفق الطرفان عند الفتح على أكبر حجم مقطع (MSS) يناسب أكبر إطار تحتمله الشبكة (MTU)، فلا تُجزّأ الحِزَم في الطريق ويُحسَن استغلال المسار.
رابعًا: التحكّم بالتدفّق والازدحام
المشكلة الأولى ألّا يُغرِق المرسِلُ السريع مستقبِلا بطيئا. يحلّها «التحكّم بالتدفّق» (Flow Control): يُعلن المستقبِل في كل إقرار كم يتّسع له، فيضبط المرسِل سرعته على قدر ما يستوعبه الطرف الآخر.
والمشكلة الثانية أعمق: ألّا يُغرِق المرسِلون الشبكةَ نفسها فتختنق. يحلّها «التحكّم بالازدحام» (Congestion Control): يبدأ TCP بإرسال متحفّظ ثمّ يضاعف معدّله سريعًا في طور يُسمّى «البدء البطيء» (Slow Start)، فإذا اقترب من حدّ الشبكة انتقل إلى زيادة خطّيّة حذرة، فإذا لمح ضياعا (إشارةَ ازدحام) خفض معدّله بشدّة ثمّ عاد يزيد بحذر. هذا النمط (الزيادة الخطّية مع التراجع المضاعَف) هو ما يجعل الاتصالات تتقاسم الشبكة بإنصاف نسبيّ. هذا «التحسّس» المستمرّ هو ما يجعل ملايين الاتصالات تتقاسم الشبكة دون أن تنهار، وهو ما تراه حين يتسارع تنزيل تدريجيا ثمّ يستقرّ. باجتماع هذه الآليات، يصنع TCP من شبكة فوضويّة لا تضمن شيئا قناة موثوقة مرتّبة ومنضبطة السرعة.
والجميل أن هذا التعقيد كلّه مخفيّ عن التطبيق. فالبرنامج الذي يستعمل TCP لا يرى مقاطعَ ولا أرقام تسلسل ولا نوافذ، بل «تيار بايتات» موثوق: يكتب من طرف فيُقرأ من الطرف الآخر بالترتيب نفسه وكاملا، كأنبوب مفتوح بينهما. كل ما مرّ بك يجري تحت هذا السطح البسيط، وهذا تمامًا ما يفعله التجريد الجيّد: يحمل ثقل العمل ويترك للمستعمل واجهة نظيفة.
UDP: حين تكون السرعة أهمّ من الكمال
ليس كل شيء يستحقّ كلفة TCP. فبروتوكول مخطّط بيانات المستخدم (UDP) هو النقيض: لا مصافحة، ولا أرقام تسلسل، ولا إقرارات، ولا إعادة إرسال، ولا تحكّم بالازدحام.[3] يرسل الرسالة ويمضي، كبطاقة بريدية تُلقى دون إيصال بالاستلام. فهو «عديم اتصال»، وترويسته لا تتجاوز 8 بايتات (مقابل 20 فأكثر في TCP)، وزمن بدئه شبه معدوم إذ لا مصافحة قبل الإرسال.
وهذه البساطة تفتح بابا لا يفتحه TCP: يقدر UDP على الإرسال إلى مجموعة من المستقبِلين دفعة واحدة (Multicast) أو إلى الشبكة كلّها (Broadcast)، وهو ما يصعب على قناة TCP الثنائية. لذا يُستعمل في البثّ الجماعيّ واكتشاف الأجهزة في الشبكة المحلّية.
ولماذا يختار أحد شبكة لا تضمن؟ لأن في كثير من الحالات يكون «المتأخّر» أسوأ من «المفقود». في مكالمة فيديو، إعادةُ إرسال إطار ضاع تأتي متأخّرة بلا فائدة، والأفضل تجاهله والمضيّ. وكذلك الألعاب اللحظية والبثّ المباشر. ويستعمله DNS أيضًا لأن استعلامه صغير سريع يُعاد ببساطة إن لم يصل. فالقاعدة: حين تكون الفورية أهمّ من الكمال، فUDP أنسب.
ولا يعني هذا أن مستعمل UDP يتخلّى عن الموثوقية كلّها، بل يبنيها بنفسه على قدر حاجته. فمحرّك لعبة قد يعيد إرسال موقع اللاعب المهمّ فقط ويُهمل ما تجاوزه الزمن، وتطبيق صوت قد يضيف ترقيما خفيفا ليرتّب الحُزَم دون انتظار طويل. وهذا بالضبط ما فعله QUIC على نطاق واسع: أخذ UDP العاري وبنى فوقه موثوقية وتحكّما بالازدحام مفصّلين للويب، فجمع مرونة UDP إلى ضمانات TCP.
TCP مقابل UDP: متى تختار أيّهما
الفرق في جملة: TCP يختار الدقّة، وUDP يختار السرعة. اختر TCP حين لا يُحتمَل فقدان بايت: صفحات الويب، والبريد، ونقل الملفّات، والمعاملات المالية. واختر UDP حين يُحتمَل الفقد ولا يُحتمَل التأخّر: الصوت، والفيديو، والألعاب، واستعلامات DNS. والسؤال ليس «أيّهما أفضل» وإنّما «أيّهما أنسب لهذه المهمّة».
والفرق يظهر بأوضح صوره في الزمن. مكالمة على TCP قد تتجمّد لحظة كلّما ضاعت حزمة فانتظر ما خلفها إعادتها، فتسمع صمتا ثمّ دفعة متأخّرة؛ أمّا على UDP فتفقد جزءا يسيرا من الصوت دون أن ينقطع التدفّق، وهذا أهون على الأذن. وبالمقابل، تنزيلُ ملفّ على UDP بلا ضمانات قد يصلك ناقصا فاسدا، بينما TCP يضمن أن كل بايت في مكانه. فكلّ منهما يضحّي بشيء ليربح ما يهمّ مهمّته.
QUIC: إعادة تصوّر المحرّك للويب الحديث
خدم TCP الإنترنت 40 سنة، لكن له عيوبا ظهرت مع الويب الحديث: مصافحته تكلّف جولاتِ ذهاب وإياب قبل أيّ بيانات (ومعها مصافحة TLS فوقها)، وضياع حزمة واحدة يوقف كل ما خلفها في القناة («انسداد رأس الطابور»)، وهو محفور في أنظمة التشغيل وأجهزة الشبكة فيصعب تطويره.
فجاء QUIC: بروتوكول حديث يُبنى فوق UDP لا TCP، ويعيد بناء الموثوقية والتحكّم بالازدحام بنفسه، ويدمج معها التشفير (TLS) في مصافحة واحدة أسرع، ويعالج انسداد رأس الطابور بفصل التدفّقات.[4] ولأنه يعمل في فضاء التطبيق لا في نظام التشغيل، يسهل تطويره دون انتظار تحديث الأنظمة. وهو الناقل الذي يقوم عليه HTTP/3، وتعتمده اليوم المتصفّحات والمواقع الكبرى. فالمحرّك نفسه يتطوّر: من TCP نحو نموذج أرشق، دون أن يتغيّر ما فوقه أو تحته، تطبيقا لمبدأ الطبقات الذي مرّ بك.
ولـQUIC ميزتان تلمسهما عمليًّا. الأولى البدء شبه الفوريّ: حين تكون قد زرت موقعا من قبل، يمكنه استئناف الاتصال دون جولة كاملة للمصافحة، فتبدأ الصفحة بالتحميل أسرع. والثانية «هجرة الاتصال»: إذ يميّز QUIC الاتصال بمعرِّف مستقلّ عن عنوان IP، فحين تنتقل من شبكة الواي فاي إلى بيانات الهاتف لا ينقطع التنزيل ولا المكالمة، بل يكمل عبر الشبكة الجديدة، وهذا ما يعجز عنه TCP المربوط بزوج العناوين والمنافذ.
ما الذي تراه من هذا كلّه
وأعراض هذه الآليات تلمسها كلّ يوم. حين يتوقّف تنزيل لحظة ثمّ يستأنف، فغالبًا لأن TCP اكتشف ضياعا وأعاد إرسال المفقود قبل أن يكمل. وحين تبطئ شبكة مزدحمة فجأة، فلأن التحكّم بالازدحام خفّض النوافذ استجابة للضياع. ورسالة «أُعيد ضبط الاتصال» (Connection Reset) تعني أن أحد الطرفين أغلق القناة فجأة براية RST بدل وداع منظّم. وحين تنقطع مكالمة فيديو إطارا أو إطارين دون أن تتوقّف، فتلك طبيعة UDP يمضي ولا يعيد. معرفة ما تحت الغطاء تحوّل هذه الأعراض من ألغاز إلى علامات مفهومة، وتجعل تشخيص الأعطال أقرب.
جرّبه بنفسك: قِس الوصول
مفاهيم التوصيل الموثوق والفقد والتأخّر تراها بأمر بسيط اسمه ping. افتح الطرفية واكتبه متبوعا باسم موقع:
ping google.comيرسل جهازك حزما صغيرة إلى الوجهة وينتظر ردّها، فيعرض لك «زمن الذهاب والإياب» بالميلي ثانية لكل حزمة، وكم حزمة ضاعت في الطريق. الزمن المنخفض يعني وجهة قريبة أو شبكة سريعة، والفقد المرتفع يفسّر التقطّع الذي تشعر به في المكالمات والألعاب. هكذا تتحوّل «الموثوقية» و«التأخّر» من كلمات في مقال إلى أرقام تقيسها بنفسك في ثوان.
وأضف إليه تجربة ثانية تكشف لك عنوانيك معا. نفّذ ipconfig في ويندوز أو ifconfig في ماك، وسجّل العنوان الذي يعطيك، وستجده في الغالب يبدأ بـ192.168 أو 10.، أي عنوانا خاصّا لا يعرفه الإنترنت. ثمّ افتح أيّ موقع يقول لك «ما عنواني»، وسجّل ما يظهر. العنوانان مختلفان، والثاني هو ما يراه العالم عنك. وإن جرّبتَه على هاتفك عبر شبكة المشغّل، فقد تجد العنوان الظاهر مشتركا مع غيرك، وذلك أثر الترجمة على مستوى المزوّد الذي مرّ بك.
من المحرّك إلى الطريق
هذا هو المحرّك في قلب الإنترنت: IP يعنون ويوصّل بأفضل جهد، وفوقه TCP يصنع الموثوقية بالترقيم والإقرار وإعادة الإرسال والنوافذ والتحكّم بالازدحام، وإلى جانبه UDP يقدّم السرعة لمن يؤثرها، وQUIC يجمع الأفضل للويب الحديث. وكلّ ما مرّ بك من URL وDNS وHTTP وTLS وكوكيز، إنما يجري فوق هذا المحرّك ضمن الصورة الكاملة لكيفية عمل الإنترنت.
لكنّ هذا كلّه برمجيات تجري على أسلاك وموجات حقيقية. فأين تبدأ هذه الأسلاك؟ من أصغر شبكة تلمسها: بيتك. وهذا موضوع المقال التالي، حيث ننزل من المحرّك إلى الطريق الذي يسير عليه: «الشبكة المحلّية (LAN)».
المصادر
- IETF: RFC 9293: Transmission Control Protocol (TCP). المصافحة، والترقيم والإقرار وإعادة الإرسال، والنوافذ والتحكّم بالازدحام.
- IETF: RFC 791: Internet Protocol (IP). العنونة، والتوصيل بأفضل جهد.
- IETF: RFC 768: User Datagram Protocol (UDP). النقل عديم الاتصال دون ضمان.
- IETF: RFC 9000: QUIC. النقل الحديث فوق UDP، أساس HTTP/3.
- APNIC: Google hits 50% IPv6. قياس جوجل لنسبة من يصل إلى خدماته عبر IPv6 يتجاوز 50% في أبريل 2026، وقياس APNIC للقدرة العالمية 42% في اليوم نفسه.
- IETF: RFC 8305: Happy Eyeballs Version 2. مهلة نحو 250 مِلّي ثانية بين محاولتي IPv6 وIPv4، وتفضيل IPv6، وكلفة انتظار المهلة كاملة لو لم يوجد التدبير.
- IETF: RFC 6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. الترجمة على مستوى المزوّد: مشاركة العنوان العامّ بين المشتركين، ولماذا لجأ المزوّدون إليها بعد نفاد المخزون.
- IETF: RFC 2131: Dynamic Host Configuration Protocol. منح العنوان لمدّة محدّدة وتجديدها، وهو سبب تغيّر عنوان جهازك.