ملاحظات سمت سرور برای زیرساخت WebRTC شما

امروزه کاربران اینترنت انتظار تجربه‌ای بی‌نقص از خدمات آنلاین دارند—چه در حال مرور اینستاگرام باشند، چه پخش موسیقی BTS یا بحث درباره انیمه‌ها. این انتظار شامل تماس‌های ویدیویی نیز می‌شود.

برای پاسخ‌گویی به این سطح از انتظار، تماس‌های ویدیویی باید دارای تأخیر زیر یک ثانیه و کیفیت بالای صوت و تصویر باشند. اغلب توسعه‌دهندگان برای ساخت چنین تجربه‌هایی از WebRTC استفاده می‌کنند.

شاید شنیده باشید که WebRTC پروتکلی است که عمدتاً سمت کاربر (کلاینت) عمل می‌کند و نیاز چندانی به سرور ندارد. اما این تمام ماجرا نیست.

سرور در WebRTC

درست است که برخی تماس‌های WebRTC بدون نیاز به سرور خارجی ممکن هستند. اما حتی در این موارد نیز، یک سرور سیگنالینگ برای برقراری اتصال اولیه ضروری است.

در اغلب موارد، اتصال مستقیم بین کاربران شکست می‌خورد یا در صورت موفقیت، با افزایش تعداد کاربران مشکلاتی ایجاد می‌شود—که در ادامه مقاله به آن‌ها خواهیم پرداخت. برای حل این چالش‌ها، استفاده از انواع مختلف سرورها در معماری WebRTC توصیه می‌شود.

در این مقاله به بررسی عناصر مختلف سمت سرور در هنگام ساخت یک راهکار WebRTC خواهیم پرداخت: از انواع سرورها گرفته تا معماری‌های چندکاربره WebRTC و نحوه عملکرد آن‌ها—تا بتوانید تصمیم‌های معماری درستی برای اپلیکیشن خود اتخاذ کنید.

انواع سرورها در WebRTC

برخی از این سرورها اجباری هستند، در حالی که وجود برخی دیگر به معماری انتخاب‌شده بستگی دارد:

• سرور سیگنالینگ (اجباری)
• سرورهای STUN/TURN (در معماری مش)
• سرورهای رسانه WebRTC
  • سرور MCU (معماری میکس)
  • سرور SFU (معماری مسیریابی)
  • SFU Relay (مسیریابی توزیع‌شده)

سرور سیگنالینگ

سیگنالینگ به تبادل اطلاعات میان کاربران در یک شبکه اشاره دارد. این فرآیند برای آغاز، کنترل و پایان دادن به تماس WebRTC ضروری است. WebRTC شیوه مشخص و سخت‌گیرانه‌ای برای سیگنالینگ ندارد، و همین امر به توسعه‌دهندگان آزادی عمل می‌دهد.

در عمل، برای اجرای سیگنالینگ خارج از باند، معمولاً از یک سرور اختصاصی استفاده می‌شود. این سرور برای شروع تماس ضروری است، اما به این معنا نیست که پس از برقراری تماس دیگر به آن نیاز نداریم. در سناریوهایی مانند قطع اتصال شبکه، سرور سیگنالینگ باید همچنان در دسترس باشد تا اتصال مجدد برقرار شود.

معماری چندکاربره WebRTC

در WebRTC معماری‌های مختلفی برای اتصال کاربران به یکدیگر وجود دارد. انتخاب نوع معماری، سرورهای موردنیاز را نیز تعیین می‌کند:

• معماری مش (Mesh)
• معماری میکس (Mixing)
• معماری مسیریابی (Routing)

در ادامه، هر معماری و سرورهای موردنیاز آن را بررسی می‌کنیم.

معماری مش (Mesh) – سرورهای STUN/TURN

در این معماری، هر کاربر به‌صورت مستقیم با تمام کاربران دیگر تماس برقرار می‌کند. مثلاً در تماسی با ۴ کاربر، هر نفر باید تصویر خود را به ۳ نفر دیگر ارسال کند و از آن‌ها نیز تصویر دریافت کند.

این روش برای تماس‌های با تعداد محدود کاربران مناسب است، اما با افزایش کاربران به مشکلاتی برمی‌خوریم.

چالش‌های NAT و فایروال:

• در شبکه‌هایی که کاربران پشت NAT هستند، آدرس IP خصوصی آن‌ها در اینترنت قابل استفاده نیست. در این موارد، سرور STUN برای شناسایی IP عمومی استفاده می‌شود.
• اگر کاربران پشت NAT متقارن (Symmetric NAT) باشند، اتصال مستقیم عملاً غیرممکن است. در این حالت، باید از سرور TURN برای رله داده‌ها استفاده کرد.
• فایروال سیستم کاربران ممکن است اجازه اتصال مستقیم را ندهد.

تعریف سرورها:

• STUN (Session Traversal Utilities for NAT): برای شناسایی IP عمومی کاربرد دارد و حدود ۸۰٪ اتصال‌ها را ممکن می‌سازد.
• TURN (Traversal Using Relays around NAT): برای رله رسانه زمانی که اتصال مستقیم ممکن نیست، استفاده می‌شود. این سرور گران‌تر از STUN است و معمولاً شامل STUN نیز می‌شود.

مزایا و معایب معماری مش

مزایا:

• اتصال مستقیم بین کاربران نیاز به سرور رسانه‌ای مرکزی ندارد و هزینه سرور را کاهش می‌دهد.
• پیاده‌سازی ساده.

معایب:

• نیاز به چندین uplink/downlink برای هر کاربر.
• کنترل کیفیت رسانه محدود.

سرورهای رسانه WebRTC

با افزایش کاربران به بیش از ۴ نفر، مصرف پهنای باند به‌شدت بالا می‌رود. برای این موارد، استفاده از سرور رسانه‌ای توصیه می‌شود.

سرورهای رسانه‌ای WebRTC به‌عنوان «میان‌افزار چندرسانه‌ای» عمل می‌کنند و قابلیت‌هایی از جمله شبیه‌سازی، ضبط تماس، تغییر کدک (Transcoding)، و بهینه‌سازی رسانه را ارائه می‌دهند.

ویژگی‌های مطلوب سرور رسانه‌ای:

• Simulcast: ارسال ویدیو با چند کیفیت مختلف بر اساس شرایط شبکه.
• Recording: امکان ضبط تماس.
• Transcoding: سازگاری بین کدک‌های مختلف.
• Audio/Video Optimization: ارسال فقط صدای فعال، اولویت دادن به صفحه‌نمایش، بی‌صدا کردن شرکت‌کنندگان و غیره.

معماری میکس (Mixing) – سرور MCU

در این معماری، همه کاربران رسانه خود را به یک سرور مرکزی (MCU) ارسال می‌کنند. سرور پس از پردازش، یک استریم ترکیبی برای هر کاربر ارسال می‌کند.

MCU چگونه عمل می‌کند:

• دریافت رسانه از کاربران.
• Decode و Rescale بر اساس شرایط شبکه.
• ترکیب رسانه‌ها (Compose).
• Encode برای ارسال به کاربران.

مزایا و معایب معماری میکس

مزایا:

• پهنای باند کم برای کاربران.
• مناسب برای دستگاه‌های ضعیف.
• ضبط تماس سرور-محور امکان‌پذیر است.

معایب:

• بار پردازشی بالا روی سرور.
• تأخیر به‌خاطر پردازش رسانه.
• مقیاس‌پذیری پایین‌تر (معمولاً تا ۳۰ کاربر).

معماری مسیریابی (Routing) – سرور SFU

در این معماری، هر کاربر فقط یک رسانه به سرور SFU ارسال می‌کند و N-1 رسانه از سایر کاربران دریافت می‌کند. برخلاف MCU، سرور هیچ پردازشی روی رسانه انجام نمی‌دهد و فقط آن را مسیردهی می‌کند.

ویژگی‌های SFU:

• پشتیبانی از simulcast.
• مسیردهی هوشمند رسانه.
• امکان توسعه به SFU Relay (ساختار توزیع‌شده).

مزایا و معایب معماری مسیریابی

مزایا:

• مصرف کمتر منابع سرور نسبت به MCU.
• مناسب برای شبکه‌های با آپلود محدود.
• امکان simulcast.

معایب:

• ضبط تماس سمت سرور ممکن نیست.
• دستگاه کاربر باید توانایی پردازش چند رسانه دریافتی را داشته باشد.
• پیاده‌سازی سمت سرور پیچیده‌تر است.

جمع‌بندی پایانی

امکان تغییر دینامیک بین این معماری‌ها نیز وجود دارد تا میان عملکرد برنامه و هزینه سرور تعادل برقرار شود.

ملاحظات تکمیلی

انتخاب معماری سمت سرور فقط نیمی از مسیر است. باید موارد زیر را نیز در نظر بگیرید:

• مدیریت کاربران با اتصال ضعیف.
• پشتیبانی از کدک‌های ناسازگار.
• مدیریت ورود/خروج کاربران در طول تماس.
• الگوریتم‌های تخمین پهنای باند.

به‌طور خلاصه، حتی با انتخاب معماری درست، چالش‌های فنی WebRTC ادامه خواهند داشت و نیازمند طراحی دقیق و مهندسی‌شده هستند.

«پلتفرم ویدیوکنفرانس سازمانی همایند» به صورت پیش‌فرض مبتنی بر معماری SFU سرویس‌دهی می‌کند.