WebRTC مجموعة واجهات برمجية في المتصفح للصوت والفيديو والبيانات الفورية بين الأطراف. وهو توصية من W3C منذ يناير 2021، ونُشرت طبعته الحالية في أكتوبر 2024.
ثلاثة أجزاء، ويجدر إبقاؤها منفصلة في ذهنك.
الحصول على الوسائط#
يستطيع المتصفح طلب كاميرا وميكروفون وتسليمك تدفقاً. والإذن للمستخدم، يُمنح لكل أصل، وقابل للسحب. ولا شيء في هذا الجزء يحتاج خادماً.
الاتصال بطرف آخر#
هنا تعيش الاختصارات.
ICE هو إجراء إيجاد مسار بين جهازين كلاهما على الأرجح خلف موجّهات تترجم العناوين. يجمع مسارات مرشحة ويجربها.
STUN خدمة عامة صغيرة يسألها الجهاز "كيف يبدو عنواني من الخارج؟". رخيصة التشغيل والاستخدام.
TURN مُرحِّل لحين انعدام المسار المباشر. وهو ينقل وسائط فعلية، فيكلّف نطاقاً، وهو الجزء الذي يُنسى في الميزانية. وتحتاجه نسبة معتبرة من الاتصالات، وتكبر تلك النسبة كثيراً على الشبكات المؤسسية المقيّدة.
تبدو المكالمة لحظية وهي خمس مفاوضات منفصلة. ومعرفة أيها أخفق هي معظم التنقيح، ومعرفة أيها يشغّله مورّد نيابةً عنك هي معظم الشراء.
من ضغط زر الاتصال إلى سماع صوت
- 01الإشارة
يتبادل الطرفان ما يدعمانه وأين هما. وليست جزءاً من WebRTC — تبنيها أو تشتريها.
- 02الاكتشاف
يخبر STUN كل طرف بعنوانه العام. رخيص وبلا حالة ويعمل لمعظم الشبكات.
- 03الاجتياز
حيث تمنع ترجمة عناوين متماثلة أو جدار حماية صارم مساراً مباشراً، يحمل مُرحِّل TURN الوسائط بدلاً منه.
- 04التفاوض
يُتفق على المرمّزات والدقات ومفاتيح التشفير. وهنا يظهر تباين القدرات.
- 05جريان الوسائط
ندّاً لندّ حيث أمكن، وعبر المُرحِّل حيث لا. ومشفّرة في الحالتين دائماً.
نقل البيانات#
إلى جانب الصوت والفيديو، يحمل WebRTC قناة بيانات حرة — مباشرة بين الأطراف، بزمن استجابة منخفض، وبلا خادم في الوسط. وهي غير مستغلة بما يكفي. فمواضع المؤشرات وحالة الألعاب وتحرير المستندات الحي ونقل الملفات كلها تناسبها.
ما ليس هو WebRTC#
ليس منتجاً. بل مجموعة بدائيات. وكل ما يحتاجه اجتماع بعد الاتصال الواحد — غرفة، وقائمة مشاركين، وصلاحيات، وتسجيل، وردهة انتظار — تبنيه أو تشتريه.
ليس إشارة. فالمعيار لا يحدد عمداً كيف يتبادل الطرفان تفاصيل الاتصال. وهذا متروك لك، ولهذا يقضي كل درس عن WebRTC معظم وقته على WebSocket.
لا يتوسع إلى حشد بذاته. فبعد حفنة مشاركين تحتاج خادم وسائط. وليس ذلك عيباً؛ بل هي النقطة التي تتغير عندها البنية.
هذا التمييز يحدد ما تشتريه فعلاً من مورّد فيديو.
| في WebRTC | ليس في WebRTC | |
|---|---|---|
| نقل الوسائط | صوت وفيديو وبيانات مشفّرة ندّاً لندّ | الخوادم حين يستحيل الندّ للندّ |
| المرمّزات والتفاوض | آلية الاتفاق عليها | أيها تحتاجه جودة مكالمتك فعلاً |
| التشفير | إلزامي، طرفاً لطرف على مسار الوسائط | إدارة المفاتيح لأكثر من مشاركَين |
| الإشارة | لا شيء إطلاقاً | كيف يجد الطرفان بعضهما — وهذا لك كاملاً |
| تعدد الأطراف | لا شيء | وحدة توجيه انتقائي لأكثر من حفنة مشاركين |
| التسجيل | لا شيء | التخزين والموافقة والاحتفاظ والولاية القضائية |
لماذا يهم تجارياً#
لأنه يضع حداً أدنى لما ينبغي أن يكلّفه الفيديو. فأي مزوّد يسعّر مكالمة بين شخصين إنما يسعّر شيئاً سيفعله المتصفح مجاناً، زائد العمل التشغيلي للإشارة والترحيل.
ولا يجعل ذلك الفيديو المستضاف سيئ القيمة — فالعمل التشغيلي حقيقي، والتسجيل والتوسع صعبان فعلاً. لكنه يعني أن عليك معرفة ما كان سيمنحك المسار المجاني قبل أن تدفع مقابل الآخر.
ما الذي ستقضي وقتك في تصحيحه فعلاً#
ثلاثة أمور تفسّر معظم تذاكر دعم WebRTC، وليس أي منها الجزء الذي يبدو صعباً.
الأذونات. رفض المستخدم طلب الكاميرا مرة قبل أشهر، والمتصفح يتذكر. فيرى تطبيقك وعداً مرفوضاً ويعرض "فشل الاتصال"، وهو خطأ وغير قابل للتصرف معاً. اكشف الخطأ المحدد وقُل "متصفحك يحجب الكاميرا — وإليك كيفية السماح".
اختيار الجهاز. فحاسوب محمول بشاشة مرصوفة وسماعة رأس وميكروفون مدمج له عدة مدخلات محتملة، والافتراضي كثيراً ما يكون الخطأ. ومنتقي الأجهزة ليس ميزة كمالية؛ بل الفرق بين مكالمة تعمل ومستخدم يستنتج أن منتجك معطّل.
شبكات تفشل في المنتصف. ينجح ICE وتتدفق الوسائط ثم يُسقطها تغيّر شبكة — من الواي فاي إلى الخلوي، أو اتصال شبكة افتراضية. عالج مسار إعادة الاتصال عمداً، لأن الافتراضي صورة مجمّدة بلا تفسير.
إشارات الجودة الجديرة بالعرض#
يعرض الاتصال إحصاءات باستمرار، ومجموعة صغيرة منها تتنبأ بمكالمة سيئة قبل شكوى المستخدم: زمن الذهاب والإياب، وفقد الحزم، وهل الاتصال مُرحَّل.
وعرض مؤشر بسيط منها — والأهم، إخبار المستخدم أي طرف لديه المشكلة — يحوّل تجربة سيئة غير مفسَّرة إلى أخرى قابلة للحل. فـ"اتصالك غير مستقر" قابل للتصرف. أما الفيديو المجمّد فلا.
أين تقع الكلفة فعلاً#
الندّ للندّ مجاني ويعمل لمعظم المكالمات الثنائية على شبكات عادية. وتصل الكلفة في موضعين، وكلاهما تشغيلي لا ترخيصي.
المُرحِّلات. فبعض المكالمات — العُشر رقم شائع، وهو أعلى بكثير على شبكات الشركات — لا تستطيع الاتصال مباشرة وتحتاج مُرحِّل TURN. والوسائط المُرحَّلة نطاق ترددي تدفع ثمنه بالدقيقة على خادم تشغّله أو تستأجره.
التوجيه. فبعد نحو أربعة مشاركين، تكفّ الشبكة المتشابكة حيث يرسل الكل إلى الكل عن التوسع. وتحتاج وحدة توجيه انتقائي، وهي خادم يتلقى كل تدفق ويمرّر ما يحتاجه كل مشارك. وذلك بنية تحتية حقيقية بتخطيط سعة حقيقي.
ومكالمات الدعم الثنائية تتفادى الاثنين في معظم الوقت. أما المكالمات الجماعية فلا تتفادى أياً منهما.
لماذا يهم هذا لمقر البيانات#
وسائط WebRTC مشفّرة، لكنها تسافر إلى مكان ما، وأين يقع المُرحِّل سؤال ولاية قضائية سيطرحه مشترٍ خاضع للتنظيم.
فحزمة تطوير مورّد بمسار وسائط سحابي أسرع دمجاً وتضع وسائط عملائك على بنية لا تتحكم بها في منطقة قد لا تكون اخترتها. والمُرحِّل المُشغَّل ذاتياً يبقيها داخل حد تستطيع تسميته، بكلفة تشغيل مُرحِّلات.
وكلاهما قابل للدفاع. وواحد فقط ينجو من بند مقر البيانات، والفرق غير مرئي في مقارنة ميزات — وهذا تحديداً سبب وجوب كونه السؤال الأول لا الأخير.
الخلاصة#
WebRTC هو مسار الوسائط ولا شيء غيره. والإشارة والمُرحِّلات وتوجيه تعدد الأطراف والتسجيل كلها لك تبنيها أو تشتريها، وهي المنتج كله. اسأل أي مورّد فيديو أين تسافر الوسائط ومن يشغّل المُرحِّل، فذلك الجواب يحدد كلفتك وموقفك الامتثالي معاً.
المصادر
كل ادعاء يستحق التحقق، مع مكان للتحقق منه.
- WebRTC: Real-Time Communication in BrowsersW3C Recommendation · 8 October 2024