خادم TURN: ما هو، كيف يعمل وأين يُستخدم

ما هو خادم TURN

خادم TURN (Traversal Using Relays around NAT) هي خدمة شبكة مُعرّفة في RFC 5766 ومُحدّثة في RFC 8656، تعيد توجيه حركة مرور UDP و TCP بين عميلين عندما يكون الاتصال المباشر P2P مستحيلاً بسبب قيود NAT أو جدران الحماية. في بنية WebRTC، يعمل خادم TURN كآلية احتياطية نهائية، تضمن الاتصال في أي ظروف شبكة.

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

بروتوكول TURN

TURN هو امتداد لبروتوكول STUN. تستخدم رسائل TURN نفس رأس 20 بايت وآلية السمات. الفرق الرئيسي هو أن TURN يُعرِّف أنواع رسائل جديدة (Allocate، Refresh، Send، Data، CreatePermission، ChannelBind) وسمات ضرورية لإدارة تخصيصات الترحيل. يُنشئ العميل تخصيصاً على خادم TURN عبر رسالة Allocate، ويتلقى عنوان نقل مرحّل (relayed transport address) ويستخدمه لإرسال واستقبال البيانات عبر الخادم.

كيف يعمل خادم TURN

يعمل خادم TURN وفق التسلسل التالي من الخطوات. يرسل العميل طلب Allocate مع المصادقة (اسم المستخدم، بيانات الاعتماد). يتحقق الخادم من بيانات الاعتماد ويُنشئ تخصيصاً — ربطاً مؤقتاً لعنوان مرحّل (IP:منفذ على خادم TURN) بالعميل. يعيد الخادم استجابة Allocate مع عنوان نقل مرحّل — وهو العنوان الذي سيستخدمه النظيرون الآخرون لإرسال البيانات إلى هذا العميل عبر خادم TURN.

بعد إنشاء التخصيص، يمكن للعميل إرسال البيانات عبر خادم TURN باستخدام رسائل Send Indication أو عبر القنوات (ChannelBind). عند استلام البيانات من العميل، يتحقق خادم TURN من الأذونات (التفويض بإرسال البيانات إلى نظيرين محددين) ويعيد توجيه البيانات إلى النظير المستهدف. لاستقبال البيانات الواردة، يجب على العميل أولاً إنشاء إذن للنظير الذي يتوقع منه بيانات؛ وإلا فإن خادم TURN سيتجاهل الحزمة الواردة. يُنشأ الإذن عبر رسالة CreatePermission مع تحديد عنوان IP للنظير.

التخصيص ومدة البقاء

التخصيص على خادم TURN له مدة بقاء محدودة — 10 دقائق افتراضياً. يجب على العميل إرسال طلب Refresh بشكل دوري لتمديد التخصيص. تُحدد مدة البقاء بالثواني في السمة LIFETIME. في حالة عدم استلام Refresh، يحذف الخادم التخصيص ويحرر العنوان المُرحّل. الفاصل الزمني الموصى به للتحديث — 5 دقائق (300 ثانية) للحماية من فقدان حزم Refresh.

تكوين خادم TURN في WebRTC

في WebRTC، يُكوّن خادم TURN من خلال إعدادات RTCPeerConnection في مصفوفة iceServers. يمكن لخوادم TURN استخدام نقل UDP أو TCP أو TLS. تستخدم المصادقة عادةً بيانات اعتماد محددة المدة (بيانات اعتماد TURN) يتم إنشاؤها على خادم التطبيق بفترة صلاحية محدودة.

لنأخذ مثالاً على تكوين خادم TURN في JavaScript مع مصادقة بواسطة رمز HMAC-SHA1.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

في هذا المثال، يتم تحديد خادم TURN مع خادم STUN في تكوين ICE واحد. عملية ICE تحاول أولاً استخدام مرشحات host ومرشحات srflx التي تم الحصول عليها من STUN. إذا فشل الاتصال المباشر، يتحول ICE تلقائياً إلى مرشح relay الذي تم الحصول عليه من خادم TURN. المعامل iceTransportPolicy: "all" يُمكّن مرشحات relay — القيمة البديلة "relay" تُعطل جميع المرشحات باستثناء TURN، وهو مفيد للاختبار.

مصادقة خادم TURN

لمنع الاستخدام غير المصرح به، يتطلب خادم TURN المصادقة. النهج القياسي هو بيانات اعتماد محددة المدة يتم إنشاؤها على خادم التطبيق باستخدام HMAC-SHA1. يقوم خادم التطبيق بتشفير اسم المستخدم باستخدام المفتاح السري لخادم TURN ويعيد اسم المستخدم وبيانات الاعتماد إلى العميل. يقوم العميل بتمريرها إلى إعدادات RTCPeerConnection، ويستخدمها المتصفح عند إنشاء تخصيص على خادم TURN. عندما تنتهي صلاحية بيانات الاعتماد، يحصل العميل على بيانات جديدة من خادم التطبيق.

TURN مقابل STUN: مقارنة

TURN و STUN يحلان مهاماً متقاربة لاختراق NAT، لكنهما يختلفان جوهرياً في الآلية والتكلفة. TURN يعيد توجيه حركة المرور، ليعمل كوسيط، بينما STUN يساعد فقط في تحديد العنوان الخارجي للاتصال المباشر P2P. يعتمد الاختيار بينهما على نوع NAT للنظيرين ومتطلبات الأداء.

من الناحية العملية، يُستخدم خادم TURN فقط للاتصالات حيث يكون P2P مستحيلاً. وفقاً لبيانات Google (إحصائيات WebRTC، 2023)، حوالي 15–20% من جميع اتصالات WebRTC تتطلب ترحيل TURN. أما النسبة المتبقية 80–85% فتُنشئ اتصالاً عبر STUN أو مرشحات host المحلية. عند تصميم تطبيق، يجب تخصيص ميزانية لحركة مرور TURN بنسبة 15–20% من إجمالي حجم الوسائط إذا كان الجمهور يشمل مستخدمين من الشبكات المؤسسية والمناطق ذات قيود NAT الصارمة.

تكلفة وأداء خادم TURN

يستهلك خادم TURN موارد كبيرة حيث تمر كل حركة مرور الوسائط عبره. تستخدم كل مكالمة نشطة مع ترحيل TURN عرض النطاق الترددي للخادم المساوي لإجمالي إنتاجية حركة مرور الوسائط (التدفق الوارد + الصادر). بالنسبة لمكالمة فيديو عالية الدقة (720p)، يمكن أن يكون هذا 1.5–2.5 ميجابت في الثانية لكل اتصال في كل اتجاه، ليصبح المجموع 3–5 ميجابت في الثانية من إجمالي حركة المرور عبر خادم TURN.

هناك عدة خيارات لنشر البنية التحتية TURN. لا يُنصح بخوادم TURN العامة المجانية للإنتاج بسبب عدم وجود ضمانات الجودة والأمان. يقدم المزودون التجاريون (Twilio Network Traversal Service، Xirsys، Metered) TURN كخدمة بسعر لكل جيجابايت — التكلفة النموذجية هي 0.005–0.02 دولار لكل جيجابايت. يتطلب الاستضافة الذاتية باستخدام coturn (خادم TURN مفتوح المصدر) خادماً بسعة عرض نطاق كافية وإعداد مراقبة.

• coturn — خادم TURN مفتوح المصدر الأكثر شيوعاً، المستخدم في معظم أنظمة الإنتاج، يدعم نقل UDP و TCP و TLS و DTLS.
• Twilio — خدمة تجارية توفر TURN + STUN بسعر يعتمد على حركة المرور مع مصادقة عبر رموز محددة المدة.
• Xirsys — مزود TURN متخصص بشبكة خوادم عالمية وتحليلات استخدام مفصلة.
• Metered.ca — خدمة TURN بحد مجاني يصل إلى 50 جيجابايت شهرياً ودفع حسب الاستخدام بعد ذلك.
• coturn مستضاف ذاتياً — تحكم كامل في التكوين، لكنه يتطلب إدارة الخادم وإعداد المراقبة.

عند اختيار حل خادم TURN، ضع في اعتبارك جغرافية المستخدمين وتكلفة حركة المرور ومتطلبات الأمان. للتطبيقات التي تضم آلاف المكالمات المتزامنة، قد يكون coturn المستضاف ذاتياً على خوادم بقناة واسعة (1+ جيجابت في الثانية) أكثر فعالية من حيث التكلفة من المزودين التجاريين. للمشاريع الصغيرة التي تضم عشرات المستخدمين، تُفضل خدمات TURN التجارية نظراً لعدم وجود أعباء إدارة ومراقبة.