من هم نمی‌دانستم، تجربه استفاده از WebRTC برای ارتباط یک به یک را داشتم، بنابراین انجام آن با شرکت‌کنندگان بیشتر برایم آسان به نظر می‌رسید، اما نمی‌دانستم وارد چه چیزی هستم، زیرا چندین مفهوم وجود داشت که من نمی دانستم و باید قبلاً می فهمیدم تا بتوانم شروع کنم.
بیایید با اصول اولیه What is شروع کنیم WebRTC?
Web Real-Time Communication (WebRTC) یک پروژه متن باز است که توسط گوگل، موزیلا و اپرا در میان دیگران پشتیبانی می شود، و گروهی از API ها و پروتکل های توسعه یافته در کنسرسیوم وب جهانی (W3C) و گروه ویژه مهندسی اینترنت (IETF) ) که به ما امکان می دهد با یکپارچه سازی ویدیو، صدا و داده ها به صورت بومی از طریق مرورگر، حتی در دستگاه های تلفن همراه، ارتباط بی درنگ داشته باشیم.
چگونه کار می کند؟
کلمه کلیدی در اینجا “بومی” است، به این معنی که برای کار کردن آن نیازی به نصب هیچ پلاگین یا نرم افزاری ندارید، همه اینها به لطف مجموعه ای از API هایی است که این کار را ممکن می کند، که عبارتند از:
-
getUserMedia (gUM): مسئولیت به دست آوردن ایمن دستگاه های صوتی و تصویری با درخواست مجوزهای لازم برای اشتراک گذاری از کاربر می باشد. این API فقط در صفحاتی که از طریق HTTPS ارائه می‌شوند کار می‌کند تا از امنیت و ویژگی‌هایی که ارائه می‌کند استفاده کند، بنابراین اتصال امن است.
-
اتصال RTCPeer: اجازه می دهد تا ارتباط بین peers *(کاربران)، اتصال با استفاده از SRTP، که یک نوع امن از RTP است، انجام می شود. لازم به ذکر است که RTP پروتکل شبکه ای است که برای ارائه صدا و تصویر از طریق شبکه های IP طراحی شده است. بنابراین، RTCPeerConnection انتقال رسانه بین *همتاها را مدیریت می کند و خدمات تحویل سرتاسری برای داده های بلادرنگ را به شیوه ای امن ارائه می دهد. پروتکل دیگری که استفاده می شود RTCP است که اطلاعاتی در مورد کیفیت خدمات ارائه شده توسط RTP ارائه می دهد.
-
DataChannel: این به ما کمک می کند تا هر نوع داده ای مانند چت متنی یا انتقال فایل را ارسال کنیم.
سیگنالینگ
WebRTC به تنهایی نمی تواند اتصالات ایجاد کند، یک کانال ارتباطی برای تبادل اطلاعات قبل از برقراری اتصال مورد نیاز است، به این کانال سیگنال یا سرویس سیگنالینگ می گویند. شایان ذکر است که جزء استاندارد WebRTC نیست، اما یک قطعه اساسی است.
اطلاعاتی که مبادله می شود “پیشنهاد و پاسخ” با استفاده از SDP (پروتکل شرح جلسه) است که حاوی کدک، آدرس منبع و اطلاعات زمان صوتی و تصویری است.
همتا A اتصال را آغاز می کند و یک نوع پیام به نام پیشنهاد ایجاد می کند. سپس این پیشنهاد را به همتا B با استفاده از کانال سیگنال. همتا B پیشنهاد را در کانال سیگنال دریافت می کند و یک پاسخ ایجاد می کند. در نهایت آن را به عقب می فرستد همتا A با استفاده از همان کانال سیگنال.
همچنین همسالان باید اطلاعات مربوط به اتصال شبکه را مبادله کنند. این به عنوان کاندیدای ICE شناخته می شود (کاندیدای ICE) و اطلاعاتی را برای اتصال مانند آدرس IP و پورت هر هاست به ما می دهد.
هر کدام یکبار همتا می داند دیگری کجاست، ارتباط مستقیما برقرار می شود. پس از شروع اتصال، سرور دیگر مورد نیاز نیست، اما می توان از آن برای احراز هویت شرکت کنندگان و کنترل جلسه استفاده کرد.
به طرز مشکوکی ساده درست است؟ اما چیزی درست نیست.
WebRTC استفاده می کند نظیر به نظیر اتصالات، که در آن اتصالات صوتی، تصویری و داده مستقیماً بین مرورگرها برقرار می شود. متأسفانه، فایروال‌ها و NAT این کار را دشوار می‌کنند، زیرا سرورهای STUN و TURN وجود دارند.
STUN و TURN سرورها
یک سرور STUN (Session Traversal Utilities for NAT) به این اجازه می دهد همتا اطلاعات شبکه عمومی آن و نحوه دسترسی به آن از طریق اینترنت را بدانید.
اگر ارتباط مستقیم بین همسالان خراب می شود، یا ممکن نیست، یک سرور TURN (پیمایش با استفاده از رله در اطراف NAT) می تواند ترافیک را به دیگری ارسال کند. همتا، اما این منجر به مصرف بیشتر منابع می شود.
با این، ما جریان کاملی از نحوه عملکرد WebRTC داریم، در این مورد، ارتباط یک به یک است، اما وقتی به شرکت کنندگان بیشتری نیاز داریم چه اتفاقی می افتد؟
خوب، ما می دانیم که برای اتصال امکان پذیر است همتا باید یک آبجکت اتصال ایجاد کند، این شیء حاوی تمام اطلاعات صوتی، تصویری و داده و همچنین اطلاعات شبکه عمومی سرورهای STUN و TURN است.
هنگامی که این روند تکرار می شود، در هر همتا برای هر کدام یک شی اضافی ایجاد می شود همتا متصل، به این توپولوژی مش می گویند.
اگر تعداد همسالان افزایش می یابد، مرورگر باید با هر یک از آنها ارتباط برقرار کند همسالان، که به نوبه خود مصرف منابع را افزایش می دهد و می تواند برای دستگاه های ارزان قیمت یا تلفن همراه مشکل ساز باشد. این ساده‌ترین راه‌حل است زیرا نیازی به تغییر چیزی در زیرساخت ندارید زیرا تمام کارها در مرورگر انجام می‌شود، اما اگر نیاز به پشتیبانی از کاربران بیشتری دارید، باید استراتژی دیگری را انتخاب کنید.
واحد کنترل چند نقطه (MCU)
ایده پشت این کار داشتن یک مرکز است سرور رسانه، که وظیفه دریافت، رمزگشایی، پردازش، رمزگذاری و ارسال مجدد جریان ها را به عهده دارد. همسالان. بنابراین، همسالان فقط یک ارتباط واحد با سرور رسانه، به جای داشتن یکی برای هر همتا. بنابراین اگر تعداد همسالان افزایش می یابد، مصرف منابع دستگاه تحت تأثیر قرار نخواهد گرفت.
با این استراتژی، مشکلات توپولوژی مش حل می شود، اما به سروری با منابع کافی نیاز است، زیرا پردازش، کدگذاری و رمزگشایی تمام جریان ها، CPU زیادی مصرف می کنند و این به طور مستقیم بر بودجه تأثیر می گذارد.
واحد حمل و نقل انتخابی (SFU)
SFU شبیه MCU است، از سرور رسانه ای نیز استفاده می کند، تفاوت این است که سرور به جای انجام تمام پردازش ها، جریان ها را به سمت سرور هدایت می کند. همسالان به طوری که آنها پردازش های لازم را انجام می دهند حتی سرور نیز می تواند انتخاب کند که آیا یک جریان خاص ارسال شود یا نه همتا که قرار است آن را دریافت کند، به عنوان مثال، کیفیت ویدیو بسته به سرعت اتصال می تواند تغییر کند همتا، به این ترتیب نیازی نیست سرور آنقدر قدرتمند باشد. بنابراین، این گزینه بهتری است زیرا از مشکلات توپولوژی مش جلوگیری می شود و در عین حال از مزایای MCU بدون هزینه های بالای مرتبط استفاده می شود.
اکنون می دانیم که WebRTC به صورت بومی در مرورگر کار می کند، از API ها و پروتکل های باز برای ایجاد امنیت استفاده می کند همتا-به-همتا اتصالات از طریق سرورهای STUN و TURN و قبلاً توسط a سرور سیگنالینگو همچنین استراتژی ها و توپولوژی های مختلفی که می توان استفاده کرد.
همانطور که می بینید، ایجاد یک پلت فرم ویدئو کنفرانس ممکن است ساده به نظر برسد، اما زمانی که آن را در دنیای واقعی به کار می برید، جالب می شود، زیرا باید جنبه ها و مفاهیم مختلف و همچنین مزایا یا معایب توپولوژی های خاص را در نظر بگیرید. برای استفاده ای که می خواهید از آن استفاده کنید، بدون اینکه هزینه ها را کنار بگذارید.
امیدوارم این پست به عنوان نقطه شروعی برای سرمایه گذاری در توسعه برنامه های کاربردی با WebRTC باشد.
