ما هو اجتياز NAT؟

اجتياز NAT هو مجموعة التقنيات التي يستخدمها تطبيق من نظير إلى نظير لإقامة اتصال مباشر بين جهازين يقف كل منهما خلف موجّه منزلي أو مكتبي. ولأن الموجّهات تترجم عناوين IP خاصة كثيرة إلى عنوان IP عام واحد (ترجمة عناوين الشبكة، أو NAT)، تُحجب الاتصالات الواردة افتراضيًا. ويقوم اجتياز NAT — وأساسًا ICE وSTUN وTURN — باكتشاف عنوان كل جهاز المواجه للعموم، وفتح مسار مؤقت عبر الموجّهين، ثم يلجأ إلى خادم مرحِّل فقط إن فشل ثقب الجدار المباشر.

كيف يعمل STUN؟

STUN (Session Traversal Utilities for NAT) بروتوكول صغير من طلب واستجابة. يرسل العميل حزمة UDP إلى خادم STUN عام، فيرد الخادم بعنوان IP المصدر والمنفذ اللذين رآهما فعلًا على السلك — وهو عنوان العميل بعد ترجمة NAT كما يراه الإنترنت العام. ثم يعلن العميل ذلك العنوان لنظيره عبر قناة إشارات، فيعرف النظير أين يرسل الحزم. ويضيف STUN نفسه نحو رحلة ذهاب وإياب واحدة من زمن الاستجابة أثناء إعداد الاتصال ولا عبء بعدها.

ما الفرق بين STUN وTURN؟

يخبر STUN كل نظير بعنوانه العام فقط ليحاولا إقامة اتصال مباشر. أما TURN فيُمرّر الوسائط فعليًا عبر خادم في السحابة حين يتعذر إقامة الاتصال المباشر. لا يضيف STUN فعليًا أي زمن استجابة أو كلفة نطاق ترددي؛ أما TURN فيضيف قفزة تكلّف نحو 30 إلى 80 مللي ثانية من زمن الاستجابة لمرحِّل إقليمي ويستهلك نطاقًا تردديًا على الخادم. والتطبيق المصمم جيدًا من نظير إلى نظير يستخدم STUN أولًا ويلجأ إلى TURN عند الضرورة فقط.

لماذا يلجأ سطح المكتب البعيد لدي إلى مرحِّل؟

يفشل ثقب الجدار المباشر من نظير إلى نظير حين يكون أحد الطرفين أو كلاهما خلف NAT متماثل، أو NAT على مستوى المشغّل (شائع في شبكات الجوال)، أو جدار حماية شركة صارم يحجب تدفق UDP المطلوب. وفي هذه الحالات يلجأ التطبيق إلى مرحِّل TURN ليظل الاتصال يعمل. وتبقى الجلسة مشفّرة من طرف إلى طرف — فالمرحِّل لا يرى إلا كتلًا مشفّرة غير مقروءة — لكنه يضيف من 30 إلى 80 مللي ثانية من زمن الاستجابة لمرحِّل إقليمي وحتى 200 مللي ثانية عبر الأقاليم.

ما هو ICE في WebRTC؟

ICE (Interactive Connectivity Establishment) هو الإطار الذي يجمع كل تقنيات اكتشاف العناوين ويجربها بالتوازي. يجمع كل نظير قائمة عناوين مرشّحة — الشبكة المحلية (host) والعام عبر STUN (server-reflexive) والمُمرَّر عبر TURN — ثم يتبادل القائمة مع الطرف الآخر. ويرسل المكدّسان حزم اختبار على كل زوج مرشّحين في آنٍ واحد، ويفوز أول زوج ينجح. وتُفضَّل المرشّحات الأعلى أولوية (host ثم server-reflexive ثم relay)، فيُختار المسار الأقل زمن استجابة متى توفر.

هل يلغي IPv6 الحاجة إلى اجتياز NAT؟

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

شرح اجتياز NAT: اتصال P2P عبر الموجّه

لديك عنوان IP عام واحد ودزينة من الأجهزة خلف موجّهك. وجهاز iPad لديك على شبكة الجوال، على بعد ثلاث شبكات. ومع ذلك يفتح تطبيق سطح مكتب بعيد اتصالًا مباشرًا بين أحدهما والآخر في أقل من ثانية — وغالبًا دون أي مرحِّل في المنتصف. هذه هي الكيفية التي يعمل بها هذا السحر فعلًا: ICE وSTUN وTURN وثقب الجدار، والحقيقة المحرجة عن NAT المتماثل.

لماذا يهم هذا

تخيّل صباح يوم ثلاثاء. جهاز Mac mini في المنزل خلف موجّه بعنوان IPv4 عام واحد. وiPad في القطار، على شبكة جوال لمشغّل لها طبقاتها الخاصة من ترجمة العناوين. يقف بين الجهازين NAT واحد على الأقل، وربما ثلاثة. ولا يمكن الوصول إلى أي من الجهازين من الإنترنت الخارجي افتراضيًا.

ومع ذلك تفتح Remio على iPad وتنقر على Mac، وبعد ثانية ترى سطح مكتبك. يتدفق الفيديو والإدخال مباشرة بين الجهازين — بلا مرحِّل سحابي، وبلا وسيط في المنتصف يعيد ترميز شاشتك.

للتقنية التي تتيح ذلك اسم — اجتياز NAT — وتقف خلفها عائلة من البروتوكولات المحددة جيدًا: STUN وTURN وICE. وهذه هي البروتوكولات نفسها التي يستخدمها WebRTC في مكالمات الفيديو عبر المتصفح، ولهذا يستطيع أي سطح مكتب بعيد حديث من نظير إلى نظير تجنّب إجبار إطارات شاشتك على المرور عبر مركز بيانات طرف ثالث. يشرح هذا المقال ما يفعله كل منها ولماذا وُجد وكيف تتضافر لإيجاد المسار الأقل زمن استجابة بين جهازين يختبئان خلف موجّهين.

مشكلة NAT في 60 ثانية

صُمّم الإنترنت بحيث يملك كل جهاز عنوانه العام القابل للتوجيه. وفي كل الفضاء نحو 4.3 مليار عنوان IPv4 — كان ذلك وفيرًا عام 1981، وواضح أنه غير كافٍ بحلول أواخر التسعينيات.

كان الحل البديل هو ترجمة عناوين الشبكة. يحصل موجّهك على عنوان IPv4 عام واحد من مزود الإنترنت. وداخل منزلك يحصل كل جهاز على عنوان خاص من نطاق محجوز (عادةً 192.168.x.x أو 10.x.x.x). حين يرسل حاسوبك المحمول حزمة إلى الخارج، يعيد الموجّه كتابة عنوان المصدر بعنوانه العام، ويتذكر الربط، ثم يمرّر الحزمة. وحين يعود الرد يبحث الموجّه عن الربط ويعيد كتابة الوجهة إلى حاسوبك المحمول.

وهذا بالضبط سبب عدم عمل الاتصالات الواردة افتراضيًا. فمن الخارج، لا عنوان لحاسوبك المحمول؛ للموجّه وحده عنوان. وحزمة من غريب إلى your-router-public-ip:5060 تصل إلى موجّه لا ربط له بها فتُسقَط.

بالنسبة لتطبيق من نظير إلى نظير، هذا هو اللعبة كلها. فكلا النظيرين خلف موجّهين لا يمرّران الحزم إلا إن تذكّرا أنهما أرسلا شيئًا إلى الخارج أولًا. ولا يستطيع أي طرف ببساطة «الاتصال» بالآخر — بل عليهما التعاون مع موجّهيهما لفتح مسار مؤقت.

ثقب الجدار: جعل جدار الحماية يسمح لك بالعودة

هذه هي الحيلة. يُفهرس جدول NAT في موجّهك بمجموعة خماسية: عنوان IP المصدر ومنفذ المصدر وعنوان IP الوجهة ومنفذ الوجهة والبروتوكول. حين يرسل جهازك حزمة UDP صادرة إلى 1.2.3.4:5678، ينشئ الموجّه مدخلًا مؤقتًا يقول: «إن عادت أي حزمة UDP من 1.2.3.4:5678 إلى عنواني العام على المنفذ X، فمرّرها إلى هذا الجهاز على المنفذ Y».

يبقى هذا المدخل لفترة زمنية — عادةً من 30 إلى 60 ثانية — ثم ينتهي ما لم يُجدَّد. وخلال هذه الفترة تُقبل أي حزمة من عنوان الوجهة.

هذا هو ثقب المفتاح الذي تستخدمه تطبيقات من نظير إلى نظير. فإذا عرف النظيران عنوان بعضهما العام، يستطيع كل منهما إرسال حزمة UDP صادرة واحدة إلى الآخر في الوقت نفسه. فيفتح موجّه كل طرف ربطًا صادرًا. وقد تُسقَط أول حزمة من كل جانب — فموجّه الآخر لم يفتح ربطه بعد — لكن للحزمة الثانية مكانًا تذهب إليه. ومن تلك اللحظة يظن الموجّهان أنهما يمرّران محادثة صادرة عادية، ويتحدث الجهازان مباشرة.

يُسمى هذا ثقب جدار UDP. إنه إعجازي بعض الشيء، وموثّق جيدًا (RFC 5128)، ويعمل مع الغالبية العظمى من أجهزة NAT الاستهلاكية. أما الحالات المتبقية — NAT المتماثل وCGNAT وجدران حماية الشركات — فهي سبب وجود TURN أصلًا.

ثقب الجدار ليس حيلة التفافية. إنه العقد الصريح الذي صُمّم NAT حوله: الحزمة الصادرة تُنشئ إذنًا واردًا. وتطبيقات من نظير إلى نظير تُرسل الحزمة الصادرة عمدًا فحسب.

STUN: «ما عنواني العام؟»

يحتاج ثقب الجدار إلى شرط مسبق واحد: أن يعرف كل نظير عنوانه المواجه للعموم ليخبر الطرف الآخر أين يرسل الحزم. وهذا العنوان غير مرئي من داخل الجهاز. يرى iPad عنوان Wi-Fi المحلي (192.168.1.42). أما ما يراه بقية الإنترنت بعد أن يعيد الموجّه كتابة الحزمة فشيء مختلف تمامًا.

STUN — Session Traversal Utilities for NAT، RFC 5389 — هو البروتوكول الصغير الذي يحل هذا. والتدفق بسيط إلى حد الإحراج:

يرسل النظير حزمة UDP إلى خادم STUN عام. (يستخدم Remio خادمي STUN العامين لدى Cloudflare وGoogle معًا للاحتياط.)
يقرأ خادم STUN عنوان IP المصدر والمنفذ من السلك — وهو، بحكم التعريف، عنوان النظير العام بعد ترجمة NAT.
يرد خادم STUN بذلك العنوان كحمولة: «بقدر ما أرى، أنت 203.0.113.42:48291.»
الآن يعرف النظير أي عنوان يعلنه للطرف الآخر.

يُسمى هذا العنوان المواجه للعموم في مصطلحات ICE مرشّح الانعكاس عبر الخادم. وتكلفته شبه معدومة — رحلة ذهاب وإياب واحدة أثناء إعداد الاتصال، ولا عبء على النطاق الترددي أو زمن الاستجابة بعد إقامة الاتصال. مهمة STUN الوحيدة هي تعريف نظيرين ببعضهما؛ وبمجرد أن يتحدثا لا دور آخر لخادم STUN.

TURN: حين يفشل ثقب الجدار

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

أبرز الأشرار:

NAT المتماثل. جهاز NAT يعيّن منفذًا عامًا مختلفًا لكل وجهة متميزة. يخبر STUN نظيرك بأنك على المنفذ 48291 (لأنه المنفذ الذي رآه خادم STUN)، لكن حين ترسل حزمة إلى عنوان نظيرك يختار موجّهك منفذًا مختلفًا — لنقل 48317. فيرفض موجّه نظيرك الحزمة لأنها قادمة من منفذ غير متوقع. وينكسر ثقب الجدار.
NAT على مستوى المشغّل (CGNAT). تضع شبكات الجوال وكثير من مزودي الإنترنت NAT ثانيًا على مستوى المشغّل. وقد تكون خلف اثنين من NAT دون أن تعلم، وعلى كليهما أن يتعاونا. وكثيرًا ما يكون CGNAT متماثلًا، ولا صلاحية لك عليه.
جدران حماية الشركات المتشددة. تحجب بعض شبكات المؤسسات كل UDP الصادر، أو تسمح به لوجهات محددة فقط. يحتاج ثقب الجدار إلى مسار UDP؛ فإن لم يوجد فلا فرصة له.

في هذه الحالات يكون الاحتياط هو TURN — Traversal Using Relays around NAT، RFC 5766. خادم TURN مرحِّل يستطيع النظيران الوصول إليه لأن له عنوانًا عامًا يقبل دائمًا الحركة الواردة. يقيم كل نظير اتصال TLS صادرًا عاديًا بخادم TURN (وهو ما يسمح به أي NAT)، ويمرّر الخادم البايتات بين الطرفين.

TURN كلفة حقيقية. فكل حزمة فيديو يجب أن تعبر قفزة شبكية إضافية. وعلى مرحِّل TURN إقليمي يضيف ذلك نحو 30 إلى 80 مللي ثانية من زمن الذهاب والإياب. وعبر الأقاليم — مثل مرحِّل في فرانكفورت لنظير في طوكيو ونظير في ساو باولو — قد يبلغ 80 إلى 200 مللي ثانية. كما يدفع مشغّل TURN تكلفة النطاق الترددي: كل بت من بثك يمر عبر أنابيبه.

ولهذا يستخدم التطبيق المصمم جيدًا TURN فقط حين يثبت فشل ثقب الجدار. ويتولى ICE هذا القرار تلقائيًا.

ICE: تجربة كل مرشّح بالتوازي

Interactive Connectivity Establishment، RFC 8445، هو التنسيق الذي يربط هذا كله. لا يختار ICE استراتيجية مسبقًا. بل يجمع كل عنوان مرشّح ممكن لكل نظير، ويتبادل القائمة الكاملة مع الطرف الآخر، ثم يجعل كلا المكدّسين يختبران كل زوج مرشّحين بالتوازي — في سباق لإيجاد أول زوج يعمل.

لكل نظير، يجمع ICE عادةً:

مرشّحي المضيف — كل عنوان IP محلي على كل واجهة شبكة (Ethernet وWi-Fi والواجهات الافتراضية، بـ IPv4 وIPv6).
مرشّحي الانعكاس عبر الخادم — عناوين عامة مُكتسبة من خوادم STUN.
مرشّحي المرحِّل — عناوين مخصصة على خادم TURN.

يتبادل النظيران هذه القوائم عبر قناة إشارات — وفي Remio هي اتصال WebSocket صغير بـ relay.remio.net يحمل مرشّحي ICE ووصف جلسة WebRTC (SDP)، ثم لا يبقى له ما يفعله حين يبدأ تدفق الوسائط.

وحين تصبح القائمتان في اليد يبدأ ICE فحوص الاتصال. يرسل كل نظير حزمة STUN-binding-request على كل زوج مرشّحين بحسب الأولوية. وصُممت الأولويات لتفضيل المسار الأقل زمن استجابة:

من مضيف إلى مضيف — النظيران على الشبكة المحلية نفسها. هذه الحالة المثالية: بضع مئات من الميكروثواني من زمن الاستجابة، ودون موجّه.
من مضيف إلى انعكاس عبر الخادم، أو من انعكاس إلى انعكاس — نظيران على شبكتين مختلفتين، ثُقب الجدار عبر جهازي NAT لديهما. وهذا ما يعنيه «من نظير إلى نظير عبر الإنترنت» عادةً في الواقع.
أي شيء يتضمن مرحِّلًا — الملاذ الأخير، ولا يُستخدم إلا حين تفشل المسارات الأعلى أولوية في فحوص الاتصال.

أول زوج مرشّحين ينجح فيه الاتجاهان معًا يُرشَّح فائزًا، وتبدأ الوسائط بالتدفق عبر ذلك المسار. وتكتمل العملية كلها عادةً في أقل بكثير من ثانية.

ويجمع ICE المرشّحين باستمرار أيضًا. فإذا ظهر مسار أفضل أثناء الجلسة — مثلًا يغادر هاتفك شبكة الجوال وينضم إلى Wi-Fi — يستطيع ICE إعادة الترشيح إلى المسار الجديد دون إسقاط المكالمة.

لماذا يفضّل Remio P2P بشدة

Remio تطبيق سطح مكتب بعيد، لا مكالمة فيديو. وميزانية زمن الاستجابة قاسية. فلكي تبدو الجلسة كأنك جالس أمام جهاز المضيف، يجب أن يكون المسار كله — الالتقاط والترميز والشبكة وفك الترميز والعرض — ضئيلًا: على الشبكة المحلية يكلّف نحو 8 مللي ثانية، والباقي هو إيقاع تحديث شاشتك الخاص بتردد 60 هرتز (نحو 16.7 مللي ثانية للإطار). وكل قفزة إضافية خطيئة.

في اتصال P2P مباشر على الشبكة المحلية، يبلغ الجزء الشبكي من هذه الميزانية نحو 1 إلى 5 مللي ثانية ذهابًا وإيابًا. لا مرحِّل؛ تنتقل البايتات مباشرة من جهاز إلى آخر. ومع مسار Remio يصل المجموع إلى نحو 8 مللي ثانية من المعالجة على الشبكة المحلية (بحسب قياساتنا الداخلية؛ والباقي هو إيقاع تحديث شاشتك الخاص بتردد 60 هرتز) — فيصل إدخالك قبل رسم الإطار التالي. ويبدو الجهاز البعيد لا يختلف عن جهاز محلي.

وفي اتصال عبر مرحِّل TURN — حتى لو إقليميًا — يقفز الجزء الشبكي إلى 30 إلى 80 مللي ثانية. فيصبح إجمالي زمن الاستجابة الذي يشعر به المستخدم من 40 إلى 100 مللي ثانية. وهو لا يزال صالحًا لمعظم الأعمال، لكنك تشعر به عند سحب سريع أو نقرات متتابعة. فلا تبدو لوحة التتبع لوحتك تمامًا.

هذا الفرق هو سبب عنائنا الكبير في إبقاء الجلسات على P2P. تجمع حزمة WebRTC في Remio مرشّحي IPv4 وIPv6 معًا، وتتحدث إلى عدة خوادم STUN بالتوازي، وتفضّل المسارات المباشرة بقوة عند اختيار أزواج المرشّحين في ICE. وداخليًا نستخدم حتى زمن الذهاب والإياب المقاس للاتصال في تصنيف الشبكة — فدون 15 مللي ثانية نعرف أنها شبكة محلية، فيبدأ المرمّز عاليًا ويُسمح له باستخدام نطاق ترددي أكبر بكثير. وأي شيء أبطأ يُعامل كشبكة واسعة ويُضبط بتحفظ أكبر.

وفوق ذلك — وهو الجزء الذي كثيرًا ما يغفله المنافسون بهدوء — الاتصال مشفّر من طرف إلى طرف أيًّا كان المسار. شاشتك لا تلمس خوادمنا أبدًا، وحتى مرحِّل TURN لا يرى إلا نصًا مشفّرًا: تُتفاوض المفاتيح مباشرة بين النظيرين أثناء المصافحة، قبل أن يتحرك أي بكسل. وسواء تدفقت البايتات من نظير إلى نظير أو عبر TURN، لا يستطيع خادم الإشارات في Remio ولا مشغّل TURN قراءتها. فمعنى P2P ببساطة أنه لا يوجد طرف ثالث على مسار البيانات إطلاقًا.

حين يكون المرحِّل لا مفر منه (وهذا مقبول)

أحيانًا تقول آلهة الشبكات لا. NAT متماثل في الطرفين، أو CGNAT مزدوج على مشغّل جوال مع مزود إنترنت صارم، أو جدار حماية شركة لا يسمح إلا بـ TLS الصادر إلى مزودي سحابة معروفين — هذه تهيئات حقيقية وشائعة. وفي هذه الحالات يجب أن تمر الجلسة عبر مرحِّل وإلا فلن تحدث أصلًا.

الواجهة الخلفية لـ TURN في Remio هي Cloudflare Calls، وهي تمنحنا شبكة عالمية من المرحِّلات قريبة من معظم المستخدمين. وحين يختار ICE مسار مرحِّل، تتراجع التجربة من «تبدو محلية» إلى «تبدو مثل Splashtop» — لا تزال صالحة جدًا، لكنك تلاحظ الفرق. ويبلغ زمن الاستجابة المضاف من 30 إلى 80 مللي ثانية لمرحِّل إقليمي؛ وعبر الأقاليم قد يصل إلى 200 مللي ثانية.

والجزء المهم: البيانات لا تزال مشفّرة من طرف إلى طرف. ترى Cloudflare حزم UDP مشفّرة تذهب في اتجاه وحزم UDP مشفّرة تعود في الاتجاه الآخر. وتستطيع عدّ البايتات للفوترة. ولا تستطيع رؤية شاشتك أو ضغطات مفاتيحك أو أي من محتوى جلستك. ولا توجد نقطة فك تشفير من جانب Remio أيضًا، لأنه لا توجد سحابة Remio في المسار — فنحن نشغّل خدمة TURN عبر Cloudflare ولا نلمس الحمولات أبدًا.

هذه هي البنية التي تصفها الورقة البيضاء للأمان لدينا بمزيد من التفصيل. والخلاصة: P2P أو مرحِّل، نموذج التهديد هو نفسه.

مخرج الطوارئ: IPv6

لدى IPv6 نحو 340 سكستليون عنوان (3.4 × 10³⁸) — يكفي لمنح كل حبة رمل على الأرض عنوان IP عامًا خاصًا بها، مع بضعة تريليونات فائضة. وفي عالم IPv6 فقط يصبح NAT غير ضروري إلى حد كبير. يستطيع جهازان يدعمان IPv6 إرسال الحزم إلى عنوان بعضهما مباشرة، والعائق الوحيد هو جدار حماية المضيف في أي من الطرفين.

إن كان لديك IPv6 في المنزل وعند مشغّل الجوال، فربما لاحظت أن بعض التطبيقات تتصل أسرع حين يكون الطرفان IPv6 — فرقصة «اجمع المرشّحين واختبر الأزواج» كلها تواجه عقبات أقل. لا ترجمة NAT لاكتشافها، ولا رحلة STUN مطلوبة، فقط عناوين مباشرة.

لكن إليك المشكلة: في 2026 لا يزال الانتشار العالمي غير مكتمل. فكثير من موجّهات المنازل تتعامل مع IPv6 بشكل سيئ أو لا تتعامل معه أصلًا. وكثير من شبكات الشركات تحجب IPv6 الوارد افتراضيًا. وبعض المشغّلين يقدمون IPv6 على جانب الراديو ثم يجسّرون إلى IPv4 في مكان آخر. ومسارات IPv6 إلى IPv6 الخالصة موجودة لكن لا يمكن الاعتماد عليها آلية وحيدة.

لذلك يجمع Remio — كأي حزمة جادة من نظير إلى نظير — مرشّحي IPv4 وIPv6 معًا، ويدع ICE يتسابق بينهما. فإن وُجد مسار IPv6 مباشر وعمل، فعادةً ما يفوز في زمن الاستجابة. وإلا تولى IPv4 مع ثقب الجدار. وإن فشلا معًا، فالمرحِّل. ولا يرى المستخدم شيئًا من هذا؛ فالاتصال يُقام ببساطة.

كيف تعرف أي مسار تستخدمه جلستك

هل أنت فضولي لمعرفة أي مسار انتهت إليه جلستك؟ يعرض مؤشر الاتصال في Remio النوع بلغة واضحة — «مباشر» لـ P2P، و«مرحِّل» لـ TURN. ويكشف لوحة إحصاءات المطورين حالة WebRTC كاملة، بما فيها أنواع مرشّحي الزوج المُرشَّح (host وsrflx وrelay) وزمن الذهاب والإياب المقاس.

بعض التفسيرات السريعة:

زمن ذهاب وإياب دون 5 مللي ثانية، مباشر — أنت على الشبكة المحلية نفسها مع المضيف. أفضل حالة. يمكن بلوغ نحو 8 مللي ثانية من المعالجة (والباقي هو إيقاع تحديث شاشتك الخاص بتردد 60 هرتز).
زمن ذهاب وإياب من 5 إلى 15 مللي ثانية، مباشر — شبكة Wi-Fi نفسها لكن مع قفزة إضافية عبر نقطة وصول أو شبكة شبكية. لا يزال ممتازًا.
زمن ذهاب وإياب من 15 إلى 80 مللي ثانية، مباشر — أنت على شبكة مختلفة عن المضيف، ونجح ثقب الجدار. P2P عبر الإنترنت يعمل.
زمن ذهاب وإياب من 30 إلى 80 مللي ثانية، مرحِّل (إقليمي) — هزم NAT متماثل أو NAT على مستوى المشغّل ثقب الجدار. وتولى TURN القريب من Cloudflare الأمر.
زمن ذهاب وإياب من 80 إلى 200 مللي ثانية، مرحِّل — TURN عبر مسافة جغرافية أطول، أو أنت والمضيف في إقليمين مختلفين جدًا.

إن عدت دائمًا إلى المرحِّل حتى في المنزل، فالمشتبه بهم المعتادون هم مودم مزود الإنترنت الذي يطبّق NAT متماثلًا، أو CGNAT بـ IPv4 على اتصالك المنزلي (وهو أشيع مما تظن لدى مُعيدي بيع الألياف)، أو جدار حماية مفرط الحماس يحجب UDP الوارد. يستعرض دليلنا لتقليل التأخر في سطح المكتب البعيد الأسباب الشائعة، وصفحة الاتصال المباشر عبر الشبكة المحلية هي الطريق السريع إن كان الجهازان على شبكتك.

أرقام الأداء في الواقع

بجمع كل ذلك، إليك أرقام زمن الاستجابة التي نقيسها في الإنتاج عبر المسارات المختلفة التي قد تسلكها جلسة Remio:

P2P مباشر على الشبكة المحلية: 1–5 مللي ثانية زمن ذهاب وإياب شبكي. من طرف إلى طرف (من حدث الإدخال إلى تحديث البكسل): نحو 8 مللي ثانية من المعالجة (والباقي هو إيقاع تحديث شاشتك الخاص بتردد 60 هرتز) مع تعاون بقية المسار.
Wi-Fi على الشبكة نفسها مع قفزات إضافية: 5–10 مللي ثانية زمن ذهاب وإياب شبكي.
مرحِّل TURN، إقليمي: 30–80 مللي ثانية زمن ذهاب وإياب شبكي.
مرحِّل TURN، عبر الأقاليم: 80–200 مللي ثانية زمن ذهاب وإياب شبكي.
جوال 4G/5G، P2P بثقب الجدار: 40–100 مللي ثانية زمن ذهاب وإياب شبكي.

وتتطابق هذه مع الأرقام في اختبارات الأداء لدى Remio وتفسّر لماذا ضبطنا عتبة الشبكة المحلية مقابل الواسعة عند 15 مللي ثانية من زمن الذهاب والإياب — فهي تفصل بوضوح بين المسارات المباشرة وأي مرحِّل (30 مللي ثانية كحد أدنى) أو مسار جوال (40 مللي ثانية كحد أدنى)، مع قلة قليلة جدًا من الإيجابيات الكاذبة.

اجتياز NAT من الموضوعات التي تكون فيها البروتوكولات بسيطة كل على حدة لكن توافيقها معقدة. ومعظم المستخدمين لن يحتاجوا يومًا إلى معرفة وجود ICE وSTUN وTURN — سيختبرون فقط تطبيقًا يتصل بسرعة من أي مكان إلى أي مكان. وتؤدي البروتوكولات عملها حين لا تلاحظها. وحين تلاحظ — جلسة تستغرق لحظة أطول من اللازم، أو «مباشر» يتحول إلى «مرحِّل» — يكون لديك الآن النموذج الذهني.

لمزيد عن مسار Remio الأصلي والخيارات التي تحوّل 1–5 مللي ثانية من زمن الاستجابة الشبكي إلى نحو 8 مللي ثانية من المعالجة (والباقي هو إيقاع تحديث شاشتك الخاص بتردد 60 هرتز)، راجع لماذا تهم التطبيقات الأصلية. ولنموذج التهديد على مسارات المرحِّل، راجع الورقة البيضاء للأمان. أو تصفّح الميزات ونزّل Remio لتشعر به يعمل.

شرح اجتياز NAT: كيف يصل سطح المكتب البعيد من نظير إلى نظير عبر موجّهك.