آزاده رادکیان‌پور
آزاده رادکیان‌پور
خواندن ۶ دقیقه·۵ سال پیش

تماس صوتی و ویدیوئی با WebRTC


مقدمه: WebRTC چیست؟

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


تاریخچه‌ی WebRTC چیست؟

شرکت GIPS در سال ۱۹۹۹ در راستای ارائه‌ی راه‌حل‌هایی برای برطرف‌کردن مشکلات موجود در استفاده از VoIP، تأسیس شد. VoIP پروتکلی برای انتقال صدا در بستر اینترنت است که تا پیش از آن با مصائبی همچون تأخیر در انتقال و از دست‌رفتن بسته‌ها همراه بود. در سال ۲۰۱۰، GIPS توسط شرکت گوگل به مبلغی حدود ۶۸ میلیون دلار خریداری شد و در سال ۲۰۱۱، گوگل از WebRTC رونمایی کرد. هدف از این تکنولوژی، ارائه‌ی راه‌حلی برای ارتباط زنده‌ی صوتی‌تصویری بین مرورگرها بدون نیاز به افزونه بود.


چه مرورگرهایی از WebRTC پشتیبانی می‌کنند؟

در زیر فهرست مرورگرهایی که از WebRTC پشتیبانی می‌کنند، آورده شده است.

مرورگرهایی که از WebRTC پشتیبانی می‌کنند
مرورگرهایی که از WebRTC پشتیبانی می‌کنند

ا WebRTC چگونه کار می‌کند؟

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

ارتباط بین سرور و کلاینت‌ها در WebSocket
ارتباط بین سرور و کلاینت‌ها در WebSocket

اکنون حالتی را تصور کنید که یکی از کلاینت‌ها توسط درخواستی که به سرور می‌دهد، باعث تغییراتی می‌شود (مثلاً به سرور درخواست می‌دهد داده‌ای را در پایگاه داده وارد کند) و سرور تصمیم دارد این تغییرات را از طریق WebSocket به اطلاع سایر کلاینت‌ها برساند. در این حالت کلاینت‌ها با تأخیر این تغییرات را دریافت می‌کنند. در بسیاری از برنامه‌های‌های کاربردی، این تأخیر، اختلالی به وجود نمی‌آورد. ولی در برخی برنامه‌ها که هدف ارتباط زنده، مانند ارتباط صوتی‌تصویری است، کوچک‌ترین تأخیر، موجب اختلال در انجام عملیات می‌گردد.

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

ارتباط بین دو کلاینت از طریق WebRTC
ارتباط بین دو کلاینت از طریق WebRTC


دو کلاینت چگونه از درخواست یکدیگر با خبر می‌شوند؟

پاسخ این است: سیگنالینگ.

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

کلاینت (آ) به سرور: سلام سرور. می‌خوام با کلاینت (ب) صبحت کنم. اطلاعات خودم هم اینه...

سرور به کلاینت (ب): سلام. یکی می‌خواد باهات صحبت کنه. این هم اطلاعاتشه... قبول می‌کنی؟

کلاینت (ب) به سرور: آره. چرا که نه! پس این هم اطلاعات من...

سرور به کلاینت (آ): خبر خوب اینکه کلاینت (آ) قبول کرده با تو صحبت کنه. این هم اطلاعاتش...

کلاینت‌ها پس از اینکه از طریق سرور اطلاعات یکدیگر را دریافت کردند، سرور را کنار گذاشته و به‌طور مستقیم با هم مشغول به صحبت می‌شوند.

به این مکالمه و ردوبدل‌کردن اطلاعات، سیگنالینگ گفته می‌شود.

به سرور در اینجا Signal Server گفته می‌شود.

پس از انجام سیگنالینگ از طریق Signal Server، به ارتباط مستقیم دو کلاینت با یکدیگر، peer-to-peer گفته می‌شود.

در پشت صحنه‌ی WebRTC چه می‌گذرد؟

می‌توان گفت WebRTC از پروتکل UDP استفاده می‌کند. این پروتکل برخلاف TCP برای انتقال داده‌های حساس مناسب نیست. زیرا چک نمی‌کند که بسته‌های داده به دست دریافت‌کننده رسیده است یا نه. ولی مزیت آن در سرعت انتقال داده است. درنتیجه می‌توان گفت UDP پروتکل مناسبی برای مثلاً تماس ویدیویی و صوتی است. به‌عنوان مثال، در استریم ویدیویی (مثلاً هنگام تماشای یوتوب)، چنانچه چند فریم از ویدیو منتقل نشود، اتفاق فاجعه‌آمیزی نمی‌افتد. ولی فرض کنید چند بایت از یک فایل منتقل نشود؛ کل فایل ممکن است غیرقابل استفاده باشد.


آیا دو کلاینت همیشه امکان برقراری ارتباط مستقیم را دارند؟

خیر.

در WebRTC، برای ارتباط مستقیم بین دو کلاینت مسائل و مشکلاتی وجود دارد. اولین مسئله، NAT است. در سیستم‌های رایج وب، کلاینت‌ها می‌توانند با سرورها صحبت کنند. یعنی مادامی که کلاینت به اینترنت متصل باشد، بدون نیاز به تغییر در شبکه می‌تواند از طریق HTTP با سرورها ارتباط برقرار کند. ولی WebRTC این قاعده را زیر پا گذاشته است. در WebRTC دو کلاینت قصد دارند بدون وجود سرور با یکدیگر صحبت کنند.

مشکلات ارتباط مستقیم دو کلاینت
مشکلات ارتباط مستقیم دو کلاینت

ولی این میان مشکلاتی وجود دارد:

۱: دو کلاینت برای ارتباط با یکدیگر، نیاز دارند که آی‌پی بیرونی هم را داشته باشند. چگونه باید آن را به دست بیاورند؟ هر کلاینت از کجا بداند که آی‌پی بیرونی‌اش چیست؟

۲: ارتباط UDP از طریق پورت‌های مشخصی صورت می‌گیرد. اگر فایروال این پورت‌ها را بسته باشند، کلاینت باید چه‌کار کند؟

در ادامه به سؤال‌های بالا جواب می‌دهیم.

یکی از مزیت‌های وب‌.آی.تی.سی، ICE یا Interactive Connectivity Establishment است. ICE پروتکلی است که مشکلات NAT و فایروال را برای ارتباط peer-to-peer از میان برمی‌دارد.

دو نوع سرور برای ICE می‌توان در نظر گرفت. STUN و TURN.

ا STUN Server: این سرور به کلاینت‌ها کمک می‌کند که آدرس خارجی خود را به دست آورند.

ا TURN Server: به آن Relay Server هم گفته می‌شود. این سرور هم مانند TURN Server به کلاینت‌ها کمک می‌کند که آی‌پی خارجی خود را به دست آورند. علاوه بر آن، مدیا را از کلاینت‌ها به یکدیگر منتقل می‌کند.

TURN Server و STUN Server
TURN Server و STUN Server


ا WebRTC چه مزیت‌هایی دارد؟

در زیر مهم‌ترین ویژگی‌های WebRTC آورده شده است:

  • انتقال داده از WebRTC از طریق پروتکل UDP است و این پروتکل کمترین میزان تأخیر در انتقال بسته‌ها را دارد.
  • استفاده از WebRTC نیاز به پلاگین یا برنامه‌ی جانبی ندارد و امروزه توسط اکثر مرورگرهای استاندارد، پشتیبانی می‌شود.
  • ا WebRTC، تنها در کانال امن قابل استفاده است. استفاده از Encryption در WebRTC اجباری است و از آن‌جایی که وابسته به پلاگین و یا برنامه‌ی جانبی‌ای نیست و داخل Sandbox مرورگر اجرا می‌شود، در نتیجه برنامه‌های مخرب از طریق آن وارد سیستم کاربران نمی‌شود.
  • دسترسی میکروفون و دوربین از طریق مرورگر و به‌صورت دستی از کاربران گرفته می‌شود و امکان اینکه تصویر یا صدای کاربر بدون بدون اجازه انتقال پیدا کند، وجود ندارد.


منابع

Wikipedia

https://webrtc.org

https://www.fullstackacademy.com

youtube/googleChromeDevelopers

برنامه‌نویسیwebrtcvoip
شاید از این پست‌ها خوشتان بیاید