چت تصویری همتا به همتا بر اساس WebRTC. چت تصویری P2P بر اساس نصب WebRTC Webrtc

کاربران اروپایی اینترنت به دو بخش تقسیم می‌شوند: طبق نظرسنجی موسسه تحلیل افکار عمومی در آلنباخ (آلمان)، اسکایپ، سیستم‌های چت و پیام‌رسانی فوری بخشی جدایی‌ناپذیر از زندگی روزمرهبرای 16.5 میلیون بزرگسال و کودک، 9 میلیون گهگاه از این خدمات استفاده می کنند و 28 میلیون نفر آنها را لمس نمی کنند.

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

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

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

بلافاصله پس از این، کروم و فایرفاکس موتورهای WebRTC خود را دریافت کردند. در حال حاضر نسخه های موبایل آنها هم به این فناوری و هم به موتور WebView 3.6 نصب شده با اندروید 5.0 مجهز است که توسط اپلیکیشن ها استفاده می شود.

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

به موازات ادغام در مرورگر، گروه کاری کنسرسیوم شبکه جهانی وب(W3C) روند استانداردسازی WebRTC را تسریع کرده است. باید در سال 2015 تکمیل شود.

WebRTC به اندکی راضی است

استفاده از سرویس WebRTC به منابع زیادی نیاز ندارد، زیرا سرور فقط مخاطبین را به هم متصل می کند. ایجاد ارتباط نیز چندان دشوار نیست. ابتدا مرورگر به سرور WebRTC سیگنال می دهد که قصد دارد یک تماس را آغاز کند. یک پیوند HTTPS از سرور دریافت می کند - ارتباط رمزگذاری شده است. کاربر این لینک را برای همکار خود ارسال می کند. سپس مرورگر برای دسترسی به وب کم و میکروفون از کاربر اجازه می خواهد.

برای برقراری ارتباط مستقیم جریان با مخاطب، مرورگر آدرس IP و داده های پیکربندی خود را از سرویس WebRTC دریافت می کند. نمایشگر وب طرف مقابل نیز همین کار را می کند.

برای اینکه اتصال استریم روان و با کیفیت خوب کار کند، سه موتور در مرورگر کار می کنند. دو مورد از آنها داده های صوتی و تصویری را بهینه و فشرده می کنند، سومی وظیفه حمل و نقل آنها را بر عهده دارد. داده ها را از طریق ارسال می کند پروتکل SRTP(پروتکل امن حمل و نقل بلادرنگ)، که امکان پخش همزمان رمزگذاری شده را فراهم می کند.

اگر اتصال مستقیم برقرار نشد، WebRTC به دنبال مسیر دیگری می گردد. به عنوان مثال، این اتفاق می افتد زمانی که تنظیمات شبکهاز گزارش دادن آدرس IP سرور STUN جلوگیری کنید. استاندارد WebRTC تصریح می کند که در این حالت مکالمه انجام می شود، اما با فعال سازی میانی سرور TURN (Traversal Using Relays around NAT). بنابراین، در وب سایت netscan.co می توانید بررسی کنید که آیا WebRTC بر روی رایانه شما و با دسترسی شما به شبکه پیاده سازی شده است یا خیر.

نحوه اتصال

ابتدا باید مکالمه را ثبت کنید (1). سرویس WebRTC پیوندی را ارائه می دهد که باید برای مخاطب ارسال شود. مرورگر با استفاده از سرور STUN، آدرس IP خود (2) را پیدا می کند، آن را به سرویس ارسال می کند و IP شریک را برای برقراری ارتباط مستقیم دریافت می کند (3). اگر STUN ناموفق باشد، مکالمه با استفاده از سرور TURN (4) هدایت می شود.

ارتباط با استفاده از فناوری WebRTC در مرورگر با استفاده از کد جاوا اسکریپت راه اندازی می شود. پس از آن، سه موتور مسئول ارتباط هستند: موتورهای صوتی و تصویری داده های چند رسانه ای را از وب کم و میکروفون جمع آوری می کنند و موتور حمل و نقل اطلاعات را ترکیب می کند و جریان را به شکل رمزگذاری شده با استفاده از SRTP (پروتکل امن زمان واقعی) ارسال می کند.

کدام مرورگرها با WebRTC کار می کنند

کروم و فایرفاکس یک موتور WebRTC دارند که از خدماتی مانند talky.io استفاده می کند. مرورگر موزیلا می تواند مستقیماً با مشتری خود کار کند.

گوگل و موزیلا به توسعه ایده ارتباطات بلادرنگ ادامه می‌دهند: کروم می‌تواند میزبان کنفرانس WebRTC با چندین شرکت‌کننده باشد، و کلاینت جدید Hello در فایرفاکس با همکاری یکی از شرکت‌های تابعه غول مخابراتی Telefonica توسعه داده شد. اپل در حال حاضر در حاشیه مانده است؛ هنوز نباید انتظار WebRTC را در سافاری داشته باشید. با این حال، بسیاری وجود دارد برنامه های کاربردی جایگزینبرای iOS و پلاگین برای سافاری.

مایکروسافت مسیر کمی متفاوت را طی می کند. به عنوان صاحب یک رقابت سرویس اسکایپاین شرکت قرار نیست به این راحتی تسلیم WebRTC شود. در عوض، مایکروسافت در حال توسعه فناوری به نام ORTC (ارتباطات بلادرنگ شی) برای اینترنت اکسپلورر.

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

عکس:شرکت های تولیدی؛ goodluz/Fotolia.com

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

WebRTC

معرفی

WebRTC یک فناوری مرورگر محور است که به شما امکان می دهد دو کلاینت را برای انتقال داده های ویدیویی متصل کنید. ویژگی های اصلی: پشتیبانی از مرورگر داخلی (بدون نیاز به فناوری های پیاده سازی شده شخص ثالث مانند فلش ادوبی ) و امکان اتصال مشتریان بدون استفاده از سرورهای اضافی - اتصال نظیر به نظیر(به علاوه، p2p).

ارتباط برقرار کنید p2p- کار نسبتاً دشواری است ، زیرا رایانه ها همیشه عمومی ندارند IPآدرس ها، یعنی آدرس های موجود در اینترنت. به دلیل کم بودن IPv4آدرس ها (و برای اهداف امنیتی)، مکانیزمی توسعه داده شد NAT، که به شما امکان می دهد شبکه های خصوصی را برای مثال برای استفاده خانگی ایجاد کنید. بسیاری از روترهای خانگی اکنون پشتیبانی می کنند NATو به لطف این، همه دستگاه های خانگی به اینترنت دسترسی دارند، اگرچه ارائه دهندگان اینترنت معمولاً یک آن را ارائه می دهند IPنشانی. عمومی IPآدرس ها در اینترنت منحصر به فرد هستند، اما آدرس های خصوصی این گونه نیستند. بنابراین متصل شوید p2p- دشوار.

برای درک بهتر این موضوع، سه موقعیت را در نظر بگیرید: هر دو گره در یک شبکه هستند (تصویر 1)، هر دو گره در شبکه های مختلف هستند (یکی خصوصی است، دیگری عمومی است) (شکل 2)و هر دو گره در شبکه های خصوصی مختلف با یکسان هستند IPآدرس ها (شکل 3).

شکل 1: هر دو گره در یک شبکه

شکل 2: گره ها در شبکه های مختلف (یکی در خصوصی، یکی در عمومی)

شکل 3: گره ها در شبکه های خصوصی مختلف، اما با آدرس های عددی برابر

در شکل های بالا، حرف اول در نماد دو کاراکتری، نوع گره را نشان می دهد (p = همتا، r = روتر). در شکل اول، وضعیت مطلوب است: گره ها در شبکه آنها به طور کامل توسط شبکه شناسایی می شوند IPآدرس ها و بنابراین می توانند مستقیماً به یکدیگر متصل شوند. در شکل دوم دو شبکه متفاوت با شماره گره مشابه داریم. اینجاست که روترها (روترها) ظاهر می شوند که دارای دو هستند رابط شبکه- در داخل شبکه و خارج از شبکه شما. به همین دلیل دوتا دارند IPآدرس ها. گره های معمولی تنها یک رابط دارند که از طریق آن فقط در داخل شبکه خود می توانند ارتباط برقرار کنند. اگر آنها داده ها را به فردی خارج از شبکه خود منتقل می کنند، فقط با استفاده از NATدر داخل روتر (روتر) و بنابراین برای دیگران قابل مشاهده است IPآدرس روتر مال آنهاست خارجی IPنشانی. بنابراین، در گره p1وجود دارد داخلی IP = 192.168.0.200 و خارجی IP = 10.50.200.5 و آخرین آدرس نیز برای تمام گره های دیگر در شبکه آن خارجی خواهد بود. وضعیت مشابه برای گره p2. بنابراین، اتصال آنها غیرممکن است اگر فقط از داخلی آنها استفاده کنید (خود) IPآدرس ها. شما می توانید از آدرس های خارجی، یعنی آدرس های روتر استفاده کنید، اما از آنجایی که همه گره ها در یک شبکه خصوصی یک آدرس خارجی دارند، این کار بسیار دشوار است. این مشکل با استفاده از مکانیزم حل می شود NAT

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

WebRTCبا استفاده از پروتکل با چنین مشکلاتی با موفقیت کنار می آید یخ، که با این حال نیاز به استفاده از سرورهای اضافی دارد ( STUN, دور زدن). اطلاعات بیشتر در مورد همه اینها در زیر.

دو فاز WebRTC

برای اتصال دو گره از طریق یک پروتکل WebRTC(یا به سادگی RTC، اگر دو نفر با هم ارتباط برقرار کنند آیفونالف) برای برقراری ارتباط باید اقدامات اولیه انجام شود. این مرحله اول است - ایجاد یک ارتباط. مرحله دوم انتقال داده های تصویری است.

ارزش این را دارد که بلافاصله بگوییم که اگرچه فناوری WebRTCاز بسیاری در کار خود استفاده می کند به طرق مختلفارتباطات ( TCPو UDP) و دارای سوئیچینگ انعطاف پذیر بین آنها، این فناوری است پروتکلی برای انتقال داده های اتصال ندارد. جای تعجب نیست، زیرا دو گره را به هم متصل کنید p2pنه چندان آسان بنابراین داشتن مقداری ضروری است اضافیروشی برای انتقال داده که به هیچ وجه به آن مرتبط نیست WebRTC. این می تواند یک انتقال سوکت، پروتکل باشد HTTP، حتی می تواند یک پروتکل باشد SMTPیا پست روسیه این مکانیزم انتقال اولیهداده نامیده می شود علامت. نیازی به انتقال اطلاعات زیادی نیست. تمام داده ها به صورت متن منتقل می شوند و به دو نوع تقسیم می شوند - SDPو کاندیدای یخی. نوع اول برای ایجاد ارتباط منطقی و نوع دوم برای اتصال فیزیکی استفاده می شود. بعداً در مورد همه این موارد بیشتر، اما در حال حاضر فقط مهم است که آن را به خاطر بسپارید WebRTCاطلاعاتی را به ما می دهد که باید به گره دیگری منتقل شود. به محض انتقال تمام اطلاعات لازم، گره ها قادر به اتصال خواهند بود و دیگر نیازی به کمک ما نخواهد بود. بنابراین مکانیسم سیگنال دهی که باید پیاده سازی کنیم این است بصورت جداگانه، استفاده خواهد شد فقط در صورت اتصال، اما هنگام انتقال داده های ویدیویی استفاده نخواهد شد.

بنابراین، بیایید فاز اول را در نظر بگیریم - مرحله ایجاد اتصال. از چند نکته تشکیل شده است. بیایید ابتدا به این مرحله برای گره ای که اتصال را آغاز می کند و سپس برای گرهی که در انتظار است نگاه کنیم.

• آغازگر (تماس گیرنده - تماس گیرنده):
  1. پیشنهاد شروع انتقال داده ویدیویی (createOffer)
  2. گرفتن مال شما SDP SDP)
  3. گرفتن مال شما کاندیدای یخ کاندیدای یخ)
• انتظار تماس ( تماس گیرنده):
  1. دریافت یک جریان رسانه محلی (شما) و تنظیم آن برای انتقال (getUserMediaStream)
  2. دریافت پیشنهاد برای شروع انتقال داده های ویدئویی و ایجاد پاسخ (createAnswer)
  3. گرفتن مال شما SDPشی و انتقال آن از طریق مکانیزم سیگنالینگ ( SDP)
  4. گرفتن مال شما کاندیدای یخاشیاء و انتقال آنها از طریق مکانیزم سیگنالینگ ( کاندیدای یخ)
  5. دریافت یک جریان رسانه از راه دور (خارجی) و نمایش آن بر روی صفحه (onAddStream)

تنها تفاوت در نکته دوم است.

علیرغم پیچیدگی ظاهری مراحل، در واقع سه مورد از آنها وجود دارد: ارسال جریان رسانه خود (مورد 1)، تنظیم پارامترهای اتصال (موارد 2-4)، دریافت جریان رسانه شخص دیگری (مورد 5). دشوارترین مرحله مرحله دوم است، زیرا از دو بخش تشکیل شده است: استقرار فیزیکیو منطقیاتصالات اولی نشان می دهد مسیر، که بسته ها باید در طول آن حرکت کنند تا از یک گره شبکه به گره دیگر برسند. دومی نشان می دهد پارامترهای ویدئویی/صوتی– از چه کیفیتی استفاده کنید، از چه کدک هایی استفاده کنید.

مرحله ذهنی ایجاد پیشنهادیا ایجاد پاسخباید به مراحل انتقال متصل شود SDPو کاندیدای یخاشیاء.

نهادهای اصلی

جریان های رسانه ای (MediaStream)

موجودیت اصلی جریان رسانه است، یعنی جریان داده های تصویری و صوتی، تصویر و صدا. دو نوع جریان رسانه وجود دارد - محلی و راه دور. محلی داده ها را از دستگاه های ورودی (دوربین، میکروفون) و از راه دور از طریق شبکه دریافت می کند. بنابراین، هر گره هم یک رشته محلی و هم یک رشته راه دور دارد. که در WebRTCیک رابط برای موضوعات وجود دارد MediaStreamو همچنین یک رابط فرعی نیز وجود دارد LocalMediaStreamبه طور خاص برای موضوع محلی که در جاوا اسکریپتشما فقط می توانید با اولین مورد روبرو شوید و اگر استفاده کنید لیجینگ، سپس ممکن است با دومی روبرو شوید.

که در WebRTCیک سلسله مراتب گیج کننده در داخل موضوع وجود دارد. هر جریان می تواند از چندین آهنگ رسانه تشکیل شده باشد ( MediaTrack، که به نوبه خود می تواند از چندین کانال رسانه ای تشکیل شود ( MediaChannel). و همچنین ممکن است خود چندین جریان رسانه ای وجود داشته باشد.

بیایید همه چیز را به ترتیب نگاه کنیم. برای انجام این کار، اجازه دهید چند مثال را در ذهن داشته باشیم. بیایید بگوییم که ما می‌خواهیم نه تنها ویدیویی از خود، بلکه یک ویدیو از میزمان را نیز منتقل کنیم، که روی آن یک تکه کاغذ قرار دارد که قرار است چیزی روی آن بنویسیم. ما به دو ویدیو (ما + جدول) و یک صدا (ما) نیاز داریم. واضح است که ما و جدول باید به رشته های مختلف تقسیم شود، زیرا این داده ها احتمالاً به طور ضعیفی به یکدیگر وابسته هستند. بنابراین ما دو خواهیم داشت MediaStreamالف - یکی برای ما و یکی برای میز. اولی حاوی داده های صوتی و تصویری است و دومی فقط حاوی ویدیو خواهد بود (شکل 4).

شکل 4: دو جریان رسانه ای مختلف. یکی برای ما، یکی برای سفره ما

بلافاصله مشخص می‌شود که حداقل یک جریان رسانه‌ای باید دارای قابلیت حاوی داده باشد انواع متفاوت- تصویری و صوتی این در فناوری در نظر گرفته می شود و بنابراین هر نوع داده از طریق یک مسیر رسانه ای پیاده سازی می شود MediaTrack. تراک های رسانه خاصیت خاصی دارند نوع، که تعیین می کند چه چیزی در مقابل خود داریم - ویدئو یا صدا (شکل 5)

شکل 5: جریان های رسانه ای از تراک های رسانه ای تشکیل شده اند

چگونه همه چیز در برنامه اتفاق می افتد؟ ما دو جریان رسانه ای ایجاد خواهیم کرد. سپس دو تراک ویدیویی و یک تراک صوتی ایجاد خواهیم کرد. بیایید به دوربین ها و میکروفون دسترسی پیدا کنیم. بیایید به هر آهنگ بگوییم از کدام دستگاه استفاده کنیم. بیایید یک آهنگ ویدیویی و صوتی را به اولین جریان رسانه و یک آهنگ ویدیویی از یک دوربین دیگر به جریان رسانه دوم اضافه کنیم.

اما چگونه جریان های رسانه ای را در انتهای دیگر اتصال تشخیص دهیم؟ برای انجام این کار، هر جریان رسانه ای دارای ویژگی است برچسب– برچسب جریان، نام آن (شکل 6). تراک های رسانه نیز همین ویژگی را دارند. اگرچه در نگاه اول به نظر می رسد که ویدیو را می توان از جهات دیگری از صدا تشخیص داد.

شکل 6: جریان های رسانه ای و آهنگ ها با برچسب ها مشخص می شوند

بنابراین، اگر می‌توان آهنگ‌های رسانه را از طریق یک برچسب شناسایی کرد، پس چرا باید به جای یک جریان از دو جریان رسانه برای مثال خود استفاده کنیم؟ پس از همه، شما می توانید یک جریان رسانه را انتقال دهید، اما از آهنگ های مختلف در آن استفاده کنید. ما به یک ویژگی مهم جریان های رسانه ای رسیده ایم - آنها همگام سازیآهنگ های رسانه ای جریان‌های رسانه‌های مختلف با یکدیگر همگام‌سازی نمی‌شوند، اما در هر جریان رسانه، همه آهنگ‌ها همگام‌سازی می‌شوند به طور همزمان پخش می شوند.

بنابراین، اگر می‌خواهیم کلمات، احساسات چهره و تکه کاغذ ما به طور همزمان پخش شوند، ارزش دارد که از یک جریان رسانه‌ای استفاده کنیم. اگر این خیلی مهم نیست، استفاده از جریان های مختلف سودآورتر است - تصویر صاف تر خواهد بود.

اگر برخی از مسیرها باید در حین انتقال خاموش شوند، می توانید از ویژگی استفاده کنید فعال شدآهنگ های رسانه ای

در نهایت، ارزش دارد به صدای استریو فکر کنید. همانطور که می دانید صدای استریو دو صدای متفاوت است. و همچنین باید جداگانه منتقل شوند. برای این کار از کانال ها استفاده می شود MediaChannel. یک تراک صوتی رسانه ای می تواند کانال های زیادی داشته باشد (مثلاً 6 کانال اگر به صدای 5+1 نیاز دارید). البته کانال هایی در داخل تراک های رسانه ای نیز وجود دارد. هماهنگ شده. برای ویدیو، معمولاً فقط از یک کانال استفاده می شود، اما می توان از چندین کانال استفاده کرد، به عنوان مثال، برای تبلیغات همپوشانی.

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

در ساده ترین حالت چت تصویری، یک جریان رسانه محلی خواهیم داشت که از دو تراک تشکیل شده است - یک تراک ویدیویی و یک تراک صوتی که هر کدام از یک کانال اصلی تشکیل شده است. تراک ویدئو مسئول دوربین، تراک صوتی برای میکروفون است و جریان رسانه محفظه هر دوی آنهاست.

توصیف جلسه (SDP)

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

برای این کار از هر مکانیزم سیگنالینگ استفاده می شود. SDPمی تواند از طریق سوکت یا توسط شخص (از طریق تلفن به گره دیگری بگویید) یا توسط پست روسیه منتقل شود. این بسیار ساده است - آنها به شما یک محصول آماده می دهند SDPو باید ارسال بشه و پس از دریافت از طرف دیگر - انتقال به بخش WebRTC. توصیفگر جلسه به صورت متن ذخیره می شود و می تواند در برنامه های شما تغییر یابد، اما این معمولاً ضروری نیست. به عنوان مثال، هنگام اتصال تلفن دسکتاپ ↔، گاهی اوقات لازم است کدک صوتی مورد نظر را انتخاب کنید.

معمولاً هنگام برقراری ارتباط، به عنوان مثال باید نوعی آدرس را مشخص کنید URL. این در اینجا ضروری نیست، زیرا از طریق مکانیسم سیگنالینگ شما خودتان داده ها را به مقصد ارسال خواهید کرد. برای نشان دادن WebRTCچیزی که میخواهیم نصب کنیم p2pاتصال شما باید تابع createOffer را فراخوانی کنید. پس از فراخوانی این تابع و دادن یک ویژگی خاص پاسخ به تماسیک اراده ایجاد می شود SDPشیء و به همان منتقل می شود پاسخ به تماس. تنها چیزی که از شما خواسته می شود این است که این شی را از طریق شبکه به گره دیگری (همکار) منتقل کنید. پس از این، داده ها از طریق مکانیسم سیگنالینگ، یعنی این، به انتهای دیگر می رسند SDPیک شی این توصیفگر جلسه با این گره بیگانه است و بنابراین حاوی اطلاعات مفیدی است. دریافت این شی سیگنالی برای شروع اتصال است. بنابراین، شما باید با این موافقت کنید و تابع createAnswer را فراخوانی کنید. این یک آنالوگ کامل از createOffer است. برگشت به مال شما پاسخ به تماستوصیفگر جلسه محلی را منتقل می کند و باید از طریق مکانیسم سیگنالینگ بازگردانده شود.

شایان ذکر است که می توانید تابع createAnswer را فقط پس از دریافت شخص دیگری فراخوانی کنید SDPهدف - شی. چرا؟ چون محلی SDPشیئی که هنگام فراخوانی createAnswer ایجاد می شود باید به کنترل از راه دور متکی باشد SDPیک شی فقط در این صورت می توان تنظیمات ویدیوی خود را با تنظیمات همکار خود هماهنگ کرد. همچنین، نباید قبل از دریافت جریان رسانه محلی CreAnswer و createOffer تماس بگیرید - آنها چیزی برای نوشتن نخواهند داشت. SDPیک شی .

از آنجایی که در WebRTCامکان ویرایش وجود دارد SDPشی، پس از دریافت دسته محلی باید نصب شود. این ممکن است کمی عجیب به نظر برسد WebRTCآنچه او خودش به ما داد، اما این پروتکل است. هنگامی که یک دسته از راه دور دریافت می شود، باید آن را نیز نصب کنید. بنابراین، شما باید دو توصیفگر را روی یک گره نصب کنید - مال شما و شخص دیگری (یعنی محلی و راه دور).

بعد از این دست دادنگره ها از خواسته های یکدیگر اطلاع دارند. به عنوان مثال، اگر گره 1 از کدک ها پشتیبانی می کند آو ب، و گره 2 از کدک ها پشتیبانی می کند بو سی، از آنجایی که هر گره توصیفگرهای خود و دیگران را می شناسد، هر دو گره کدک را انتخاب می کنند ب(شکل 7). منطق اتصال اکنون برقرار شده است و جریان های رسانه می توانند منتقل شوند، اما مشکل دیگری وجود دارد - گره ها هنوز فقط با یک مکانیسم سیگنالینگ متصل هستند.

شکل 7: مذاکره کدک

کاندیدای یخ

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

بنابراین، اتصال قبلا برقرار شده است (اتصال منطقی)، اما هنوز هیچ مسیری وجود ندارد که گره های شبکه بتوانند داده ها را در طول آن انتقال دهند. همه چیز به این سادگی نیست، اما بیایید ساده شروع کنیم. بگذارید گره ها در همان شبکه خصوصی باشند. همانطور که می دانیم، آنها به راحتی می توانند با توجه به درونی خود با یکدیگر ارتباط برقرار کنند IPآدرس ها (یا شاید به آدرس های دیگر، در صورت عدم استفاده TCP/IP).

بعد از چند پاسخ به تماسو WebRTCبه ما می گوید کاندیدای یخاشیاء. آنها همچنین به صورت متنی هستند و مانند توصیفگرهای جلسه، فقط باید از طریق مکانیزم سیگنالینگ ارسال شوند. اگر توصیفگر جلسه حاوی اطلاعاتی درباره تنظیمات ما در سطح دوربین و میکروفون بود، نامزدها حاوی اطلاعاتی درباره موقعیت مکانی ما در شبکه هستند. آنها را به گره دیگری منتقل کنید، و آن می‌تواند به صورت فیزیکی به ما متصل شود، و از آنجایی که قبلاً یک توصیفگر جلسه دارد، منطقاً قادر به اتصال خواهد بود و داده‌ها «جریان می‌شوند». اگر او به یاد آورد که شیء کاندید خود را برای ما بفرستد، یعنی اطلاعاتی در مورد جایی که خودش در شبکه است، آنگاه می توانیم با او ارتباط برقرار کنیم. اجازه دهید در اینجا یک تفاوت دیگر با تعامل کلاسیک مشتری و سرور را یادآور شویم. ارتباط با سرور HTTP بر اساس طرح درخواست-پاسخ صورت می‌گیرد، مشتری داده‌ها را به سرور ارسال می‌کند، سرور آن‌ها را پردازش کرده و از طریق ارسال می‌کند. آدرس مشخص شده در بسته درخواست. که در WebRTCنیاز به دانستن دو آدرسو آنها را از دو طرف وصل کنید.

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

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

بنابراین، دو گره در یک شبکه قرار دارند (شکل 8). چگونه آنها را شناسایی کنیم؟ با استفاده از IPآدرس ها. راه دیگری نیست. درست است، شما هنوز هم می توانید از حمل و نقل های مختلف استفاده کنید ( TCPو UDP) و پورت های مختلف. این اطلاعات موجود در شی کاندید است - IP, بندر, حمل و نقلو یکی دیگر اجازه دهید، برای مثال، استفاده کنید UDPحمل و نقل و 531 بندر.

شکل 8: دو گره در یک شبکه قرار دارند

سپس اگر در گره باشیم p1، آن WebRTCچنین شی نامزدی را به ما می دهد - . این یک قالب دقیق نیست، فقط یک نمودار است. اگر در یک گره هستیم p2، سپس نامزد این است - . از طریق یک مکانیسم سیگنالینگ p1یک نامزد دریافت خواهد کرد p2(یعنی مکان گره p2، یعنی او IPو بندر). سپس p1می تواند با p2به طور مستقیم. درست تر، p1داده ها را به آدرس ارسال می کند 10.50.150.3:531 به امید اینکه برسند p2. مهم نیست که آدرس متعلق به گره باشد p2یا یک واسطه تنها نکته مهم این است که داده ها از طریق این آدرس ارسال می شوند و قابل دسترسی هستند p2.

تا زمانی که گره ها در یک شبکه هستند، همه چیز ساده و آسان است - هر گره فقط یک شی کاندید دارد (همیشه به معنای متعلق به خودش، یعنی مکانش در شبکه است). اما زمانی که گره ها وارد شوند، نامزدهای بیشتری وجود خواهند داشت ناهمسانشبکه های.

بیایید به یک مورد پیچیده تر برویم. یک گره در پشت روتر (به طور دقیق تر، پشت NAT) و گره دوم در همان شبکه با این روتر (به عنوان مثال، در اینترنت) قرار خواهد گرفت (شکل 9).

شکل 9: یک گره پشت NAT است، دیگری نه

این مورد راه حل خاصی برای مشکل دارد که اکنون به بررسی آن می پردازیم. روتر خانگیمعمولا شامل یک جدول است NAT. این یک مکانیسم ویژه است که به گره‌های داخل شبکه خصوصی روتر اجازه می‌دهد تا مثلاً به وب‌سایت‌ها دسترسی داشته باشند.

فرض کنید وب سرور مستقیماً به اینترنت متصل است، یعنی دارای یک عمومی است IP* نشانی. بگذارید این یک گره باشد p2. گره p1(مشتری وب) درخواستی را به آدرس ارسال می کند 10.50.200.10 . ابتدا اطلاعات به روتر می رود r1، یا بهتر است بگوییم روی او داخلیرابط 192.168.0.1 . پس از آن، روتر آدرس منبع (آدرس p1) و آن را در جدول مخصوص وارد می کند NAT، سپس آدرس منبع را به آدرس شما تغییر می دهد ( p1 → r1). علاوه بر این، به روش خودم خارجیرابط، روتر داده ها را مستقیماً به وب سرور ارسال می کند p2. وب سرور داده ها را پردازش می کند، یک پاسخ تولید می کند و آن را پس می فرستد. ارسال به روتر r1، زیرا این اوست که در آدرس برگشتی قرار دارد (روتر آدرس را با آدرس خود جایگزین کرد). روتر داده ها را دریافت می کند و به جدول نگاه می کند NATو داده ها را به گره ارسال می کند p1. روتر در اینجا به عنوان یک واسطه عمل می کند.

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

بیایید به فناوری برگردیم WebRTC، یا بهتر است بگوییم، به بخشی از آن که استفاده می کند یخپروتکل (از این رو یخنامزدهای). گره p2یک نامزد دارد (موقعیت آن در شبکه - 10.50.200.10 ) و گره p1، که در پشت یک روتر با NAT قرار دارد، دو نامزد خواهد داشت - محلی ( 192.168.0.200 ) و نامزد روتر ( 10.50.200.5 ). مورد اول مفید نیست، اما با این وجود، از آنجایی که تولید می شود WebRTCهنوز چیزی در مورد گره راه دور نمی داند - ممکن است در همان شبکه باشد یا نباشد. نامزد دوم مفید خواهد بود، و همانطور که قبلاً می دانیم، بندر نقش مهمی ایفا خواهد کرد (گذر از آن NAT).

ورودی جدول NATتنها زمانی تولید می شود که داده ها از شبکه داخلی خارج شوند. بنابراین گره p1ابتدا باید داده ها را منتقل کند و تنها پس از آن داده های گره را ارسال کند p2قادر خواهد بود به گره برسد p1.

در تمرین هر دو گرهعقب خواهد بود NAT. برای ایجاد یک رکورد در یک جدول NATاز هر روتر، گره ها باید چیزی را به گره راه دور ارسال کنند، اما این بار نه اولی می تواند به دومی برسد و نه برعکس. این به این دلیل است که گره ها خارجی خود را نمی دانند IPآدرس ها و ارسال داده ها به آدرس های داخلی بی معنی است.

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

مشکل این است که به منظور شناسایی خارجی شما IPآدرس، به یک گره مستقر در آن نیاز دارید شبکه مشترک. برای حل این مشکل از سرورهای اضافی استفاده می شود که مستقیماً به اینترنت متصل هستند. با کمک آنها، ورودی های ارزشمند در جدول نیز ایجاد می شود NAT.

STUN و TURN سرورها

در مقداردهی اولیه WebRTCشما باید موجود را مشخص کنید STUNو دور زدنسرورهایی که در ادامه با آنها تماس خواهیم گرفت یخسرورها اگر سرورها مشخص نشده باشند، فقط گره ها در همان شبکه (به آن متصل هستند بدون NAT). بلافاصله شایان ذکر است که برای 3 گرم-شبکه ها باید استفاده شوند دور زدنسرورها

STUN سرورصرفاً یک سرور در اینترنت است که آدرس برگشتی، یعنی آدرس گره فرستنده را برمی گرداند. گره واقع در پشت روتر دسترسی دارد STUNسروری که باید از آن عبور کرد NAT. بسته رسید STUNسرور، حاوی آدرس منبع - آدرس روتر، یعنی آدرس خارجی گره ما است. این آدرس STUNسرور و آن را پس می فرستد. بنابراین، گره خارجی خود را دریافت می کند IPآدرس و پورتی که از طریق آن از طریق شبکه قابل دسترسی است. به علاوه، WebRTCاستفاده از این آدرس یک نامزد اضافی (آدرس روتر خارجی و پورت) ایجاد می کند. اکنون در جدول NATروتر ورودی دارد که به بسته های ارسال شده به روتر در پورت مورد نیاز اجازه می دهد تا به گره ما منتقل شوند.

بیایید با یک مثال به این روند نگاه کنیم.

مثال (عملکرد سرور STUN)

STUNما سرور را با علامت گذاری می کنیم s1. روتر، مانند قبل، از طریق r1، و گره - از طریق p1. همچنین باید جدول را دنبال کنید NAT- بیایید آن را به عنوان نشان دهیم r1_nat. علاوه بر این، این جدول معمولا حاوی رکوردهای زیادی از گره های مختلف زیرشبکه است - آنها داده نمی شوند.

بنابراین، در ابتدا یک جدول خالی داریم r1_nat.

جدول 2: سرصفحه بسته

گره p1این بسته را به روتر ارسال می کند r1(مهم نیست چگونه، آنها را می توان در زیر شبکه های مختلف استفاده کرد فن آوری های مختلف). روتر باید آدرس منبع را تغییر دهد Src IP، از آنجایی که آدرس مشخص شده در بسته بدیهی است که برای یک زیرشبکه خارجی مناسب نیست، علاوه بر این، آدرس هایی از چنین محدوده ای رزرو شده اند و هیچ آدرسی در اینترنت چنین آدرسی ندارد. روتر یک جایگزین در بسته ایجاد می کند و ایجاد می کند ورودی جدیددر میز شما r1_nat. برای انجام این کار، او باید یک شماره پورت پیدا کند. به یاد بیاوریم که از آنجایی که چندین گره در یک زیرشبکه می توانند به شبکه خارجی دسترسی داشته باشند، پس در جدول NATباید نگه داشته شود اطلاعات تکمیلی، به طوری که روتر می تواند تعیین کند که کدام یک از این چندین گره برای بسته برگشتی از سرور است. اجازه دهید روتر با یک پورت بیاید 888 .

هدر بسته تغییر کرد:

جدول 4: جدول NAT با یک ورودی جدید به روز شده است

اینجا IPآدرس و پورت برای زیر شبکه دقیقاً مشابه بسته اصلی است. در واقع هنگام پست بکینگ باید راهی برای بازیابی کامل آنها داشته باشیم. IPآدرس شبکه خارجی آدرس روتر است و پورت به آدرسی که روتر اختراع کرده است تغییر کرده است.

پورت واقعی که گره به آن می رود p1اتصال را می پذیرد - البته این 35777 ، اما سرور داده ها را به ساختگیبندر 888 ، که توسط روتر به واقعی تغییر می کند 35777 .

بنابراین، روتر آدرس منبع و پورت را در هدر بسته جایگزین کرد و یک ورودی به جدول اضافه کرد NAT. اکنون بسته از طریق شبکه به سرور، یعنی گره ارسال می شود s1. در ورودی، s1دارای این پکیج:

Src IP	Src PORT	IP مقصد	بندر مقصد
10.50.200.5	888	12.62.100.200	6000

جدول 5: بسته دریافتی سرور STUN

جمع STUNسرور می داند که یک بسته از آدرس دریافت کرده است 10.50.200.5:888 . حالا سرور این آدرس را پس می فرستد. ارزش این را دارد که در اینجا توقف کنیم و نگاهی دیگر به آنچه که اخیراً نگاه کردیم بیاندازیم. جداول بالا گزیده ای از آن هستند سرتیتربسته، اصلا از آن نیست محتوا. ما در مورد محتوا صحبت نکردیم، زیرا آنقدر مهم نیست - به نوعی در پروتکل توضیح داده شده است STUN. اکنون علاوه بر عنوان، محتوا را نیز در نظر خواهیم گرفت. ساده خواهد بود و حاوی آدرس روتر است - 10.50.200.5:888 ، اگرچه ما آن را از آن گرفتیم سرتیتربسته بندی این اغلب انجام نمی شود؛ پروتکل ها معمولاً به اطلاعات مربوط به آدرس گره ها اهمیت نمی دهند؛ فقط مهم است که بسته ها به مقصد مورد نظر خود تحویل داده شوند. در اینجا ما به پروتکلی نگاه می کنیم که مسیری را بین دو گره ایجاد می کند.

بنابراین اکنون یک بسته دوم داریم که در جهت مخالف حرکت می کند:

جدول 7: سرور STUN یک بسته با این محتوا ارسال می کند

در مرحله بعد، بسته در سراسر شبکه حرکت می کند تا زمانی که به رابط خارجی روتر برسد r1. روتر متوجه می شود که بسته برای آن در نظر گرفته نشده است. او چگونه این را می فهمد؟ این فقط توسط پورت قابل تعیین است. بندر 888 او از آن برای اهداف شخصی خود استفاده نمی کند، بلکه از آن برای مکانیسم استفاده می کند NAT. بنابراین، روتر به این جدول نگاه می کند. به ستون نگاه می کند پورت خارجیو به دنبال رشته ای می گردد که مطابقت داشته باشد بندر مقصداز بسته دریافتی، یعنی 888 .

IP داخلی	پورت داخلی	IP خارجی	پورت خارجی
192.168.0.200	35777	10.50.200.5	888

جدول 8: جدول NAT

ما خوش شانسیم، چنین خطی وجود دارد. اگر ما بدشانس بودیم، بسته به سادگی دور انداخته می شد. اکنون باید بدانید که کدام گره در زیرشبکه باید این بسته را ارسال کند. نیازی به عجله نیست، بیایید بار دیگر اهمیت پورت ها را در این مکانیسم یادآوری کنیم. در همان زمان، دو گره در زیر شبکه می توانند درخواست ها را به شبکه خارجی ارسال کنند. سپس، اگر برای اولین گره، روتر با یک پورت آمد 888 ، سپس برای دومین بار با یک بندر می آمد 889 . فرض کنیم این اتفاق افتاده است، یعنی جدول r1_natبه نظر می رسد که:

جدول 10: روتر جایگزین آدرس گیرنده می شود

Src IP	Src PORT	IP مقصد	بندر مقصد
12.62.100.200	6000	192.168.0.200	35777

جدول 11: روتر آدرس گیرنده را تغییر داد

بسته با موفقیت به گره می رسد p1و با مشاهده محتویات بسته، گره از خارجی آن مطلع می شود IPآدرس، یعنی آدرس روتر در شبکه خارجی. او همچنین پورتی که روتر از آن عبور می کند را می شناسد NAT.

بعدش چی؟ فایده این همه چیست؟ سود یک ورودی در جدول است r1_nat. اگر الان کسی به روتر بفرستد r1بسته با پورت 888 ، سپس روتر این بسته را به گره ارسال می کند p1. بنابراین، یک گذرگاه باریک کوچک به گره پنهان ایجاد شد p1.

از مثال بالا می توانید ایده ای در مورد نحوه کار آن بدست آورید NATو جوهر STUNسرور به طور کلی، مکانیسم یخو STUN / چرخشسرورها دقیقاً در جهت غلبه بر محدودیت ها هستند NAT.

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

دور زدنسرور بهبود یافته است STUNسرور از اینجا بلافاصله باید یاد گرفت که هر دور زدنسرور می تواند کار کند و چگونه STUNسرور با این حال، مزایایی نیز وجود دارد. اگر p2pارتباط غیرممکن است (مانند در 3 گرمشبکه ها)، سپس سرور به حالت تکرار کننده سوئیچ می کند ( رله) یعنی به عنوان واسطه عمل می کند. البته در مورد هیچی p2pپس هیچ سوالی وجود ندارد، اما خارج از چارچوب مکانیسم یخگره ها فکر می کنند که مستقیماً در حال ارتباط هستند.

در چه مواردی لازم است دور زدنسرور؟ چرا کافی نیست STUNسرورها؟ واقعیت این است که انواع مختلفی وجود دارد NAT. آنها به طور مساوی جایگزین می کنند IPآدرس و پورت، اما برخی از آنها دارای حفاظت اضافی در برابر "جعل" هستند. به عنوان مثال، در متقارنجدول NAT 2 پارامتر دیگر ذخیره می شود - IPو پورت گره راه دور. یک بسته از شبکه خارجی عبور می کند NATفقط در صورتی که آدرس منبع و پورت با موارد ثبت شده در جدول مطابقت داشته باشد به شبکه داخلی. بنابراین، تمرکز STUNسرور از کار می افتد - جدول NATآدرس و پورت فروشگاه STUNسرور و زمانی که روتر یک بسته را از آن دریافت می کند WebRTCگفت‌وگو، او آن را کنار می‌گذارد زیرا «جعل» است. او از آنجا نیامده است STUNسرور

بدین ترتیب دور زدنیک سرور زمانی مورد نیاز است که هر دو طرف گفتگو قرار داشته باشند متقارن NAT(هر کدام به خود).

خلاصه ای مختصر

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

• جریان رسانه ای
  • داده های ویدیویی و صوتی در جریان های رسانه ای بسته بندی می شوند
  • جریان‌های رسانه، آهنگ‌های رسانه‌ای را که تشکیل می‌دهند همگام‌سازی می‌کنند
  • جریان های رسانه های مختلف با یکدیگر همگام نیستند
  • جریان‌های رسانه‌ای می‌توانند محلی و از راه دور باشند، محلی معمولاً به دوربین و میکروفون متصل می‌شود، جریان‌های راه دور داده‌ها را به صورت رمزگذاری شده از شبکه دریافت می‌کنند.
  • دو نوع آهنگ رسانه وجود دارد - برای ویدیو و برای صدا.
  • آهنگ های رسانه ای قابلیت روشن/خاموش شدن را دارند
  • آهنگ های رسانه از کانال های رسانه ای تشکیل شده است
  • آهنگ‌های رسانه کانال‌های رسانه‌ای را که تشکیل می‌دهند همگام‌سازی می‌کنند
  • جریان های رسانه ای و تراک های رسانه ای دارای برچسب هایی هستند که می توان آنها را از هم تشخیص داد
• دسته جلسه
  • توصیفگر جلسه برای اتصال منطقی دو گره شبکه استفاده می شود
  • توصیفگر جلسه اطلاعات مربوط به آن را ذخیره می کند راه های موجودرمزگذاری داده های صوتی و تصویری
  • WebRTCاز مکانیزم سیگنال دهی خارجی استفاده می کند - وظیفه ارسال توصیفگرهای جلسه ( sdp) روی برنامه می افتد
  • مکانیسم اتصال منطقی شامل دو مرحله است - جمله ( پیشنهاد) و پاسخ ( پاسخ)
  • ایجاد یک توصیفگر جلسه بدون استفاده از جریان رسانه محلی در مورد یک پروپوزال امکان پذیر نیست ( پیشنهاد) و بدون استفاده از کنترل جلسه از راه دور در صورت پاسخ امکان پذیر نیست ( پاسخ)
  • توصیفگر حاصل باید به اجرا داده شود WebRTC، و فرقی نمی کند که این توصیفگر از راه دور یا محلی از همان پیاده سازی به دست آمده باشد WebRTC
  • امکان ویرایش جزئی توصیفگر جلسه وجود دارد
• نامزدهای
  • نامزد ( کاندیدای یخ) آدرس گره در شبکه است
  • آدرس گره می تواند متعلق به شما باشد یا می تواند آدرس یک روتر یا دور زدنسرورها
  • همیشه نامزدهای زیادی وجود دارد
  • نامزد متشکل از IPآدرس، بندر و نوع حمل و نقل ( TCPیا UDP)
  • از کاندیداها برای ایجاد ارتباط فیزیکی بین دو گره در یک شبکه استفاده می شود
  • نامزدها همچنین باید از طریق مکانیسم سیگنالینگ ارسال شوند
  • نامزدها نیز باید به اجراها منتقل شوند WebRTC، اما فقط از راه دور
  • در برخی از اجراها WebRTCنامزدها فقط پس از تنظیم توصیف جلسه قابل انتقال هستند
• STUN/TURN/ICE/NAT
  • NAT- مکانیزم برای دسترسی به شبکه خارجی
  • روترهای خانگی از یک جدول ویژه پشتیبانی می کنند NAT
  • روتر آدرس‌های موجود در بسته‌ها را جایگزین می‌کند - اگر بسته به یک شبکه خارجی می‌رود، آدرس منبع را با آدرس خود و آدرس گیرنده را با آدرس میزبان در شبکه داخلی، اگر بسته از یک شبکه خارجی آمده است، جایگزین می‌کند.
  • برای ارائه دسترسی چند کاناله به شبکه خارجی NATاز پورت ها استفاده می کند
  • یخ- مکانیسم دور زدن NAT
  • STUNو دور زدنسرورها - سرورهای کمکی برای دور زدن NAT
  • STUNسرور به شما اجازه می دهد تا رکوردهای لازم را در جدول ایجاد کنید NAT، و همچنین آدرس خارجی گره را برمی گرداند
  • دور زدنسرور تعمیم می دهد STUNمکانیسم و ​​باعث می شود که همیشه کار کند
  • در بدترین موارد دور زدنسرور به عنوان یک واسطه استفاده می شود ( رله)، به این معنا که p2pتبدیل به ارتباط مشتری-سرور-مشتری می شود.

WebRTC (Web Real Time Communications) استانداردی است که انتقال جریان داده های صوتی، داده های ویدئویی و محتوا از و به مرورگر را به صورت بلادرنگ بدون نصب افزونه ها یا برنامه های افزودنی دیگر توصیف می کند. این استاندارد به شما امکان می دهد مرورگر خود را به ترمینال کنفرانس ویدیویی تبدیل کنید؛ فقط باید یک صفحه وب را برای شروع ارتباط باز کنید.

WebRTC چیست؟

در این مقاله ما به هر چیزی که باید در مورد فناوری WebRTC بدانید نگاه خواهیم کرد کاربر معمولی. بیایید به مزایا و معایب پروژه نگاهی بیندازیم، برخی از اسرار را فاش کنیم، به شما بگوییم که چگونه کار می کند، کجا و برای چه چیزی از WebRTC استفاده می شود.

آنچه باید در مورد WebRTC بدانید؟

تکامل استانداردها و فناوری های ارتباط تصویری

سرگئی یوتسایتیس، سیسکو، ویدئو + کنفرانس 2016

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

سمت مشتری

• کاربر صفحه ای حاوی تگ HTML5 را باز می کند
• مرورگر درخواست دسترسی به وب کم و میکروفون کاربر را دارد.
• کد جاوا اسکریپت در صفحه کاربر، پارامترهای اتصال (آدرس های IP و پورت های سرور WebRTC یا سایر مشتریان WebRTC) را برای دور زدن NAT و فایروال کنترل می کند.
• هنگام دریافت اطلاعات در مورد مخاطب یا جریان از کنفرانس مخلوط شده در سرور، مرورگر شروع به مذاکره در مورد کدک های صوتی و تصویری مورد استفاده می کند.
• فرآیند رمزگذاری آغاز می شود و انتقال داده های جریانی بین مشتریان WebRTC (در مورد ما بین مرورگر و سرور) آغاز می شود.

در سمت سرور WebRTC

برای تبادل داده بین دو شرکت کننده نیازی به یک سرور ویدئو نیست، اما اگر نیاز به ترکیب چند شرکت کننده در یک کنفرانس دارید، به سرور نیاز است.

سرور ویدیو ترافیک رسانه را از منابع مختلف دریافت می کند، آن را تبدیل می کند و برای کاربرانی که از WebRTC به عنوان ترمینال استفاده می کنند ارسال می کند.

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

مزایای استاندارد

• بدون نیاز به نصب نرم افزار
• کیفیت ارتباط بسیار بالا، به لطف:
  • استفاده از ویدئوهای مدرن (VP8, H.264) و کدک های صوتی (Opus).
  • تنظیم خودکار کیفیت جریان با شرایط اتصال.
  • دارای سیستم کاهش صدا و اکو داخلی
  • تنظیم خودکار سطح حساسیت میکروفون های شرکت کننده (AGC).
• سطح بالایی از امنیت: تمام اتصالات با استفاده از پروتکل های TLS و SRTP محافظت و رمزگذاری می شوند.
• یک مکانیسم داخلی برای ضبط محتوا وجود دارد، به عنوان مثال، دسکتاپ.
• امکان پیاده سازی هر رابط مدیریتی بر اساس HTML5 و جاوا اسکریپت.
• توانایی ادغام رابط با هر سیستم پشتیبان با استفاده از WebSockets.
• پروژه با باز کد منبع- می تواند در محصول یا خدمات شما پیاده سازی شود.
• چند پلت فرم واقعی: همان برنامه WebRTC روی هر کدام به همان اندازه خوب کار می کند سیستم عامل، دسکتاپ یا موبایل، مشروط بر اینکه مرورگر از WebRTC پشتیبانی کند. این امر باعث صرفه جویی قابل توجهی در منابع در توسعه نرم افزار می شود.

معایب استاندارد

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

اسرار WebRTC: چگونه فروشندگان از فناوری وب پیشرو سود می برند

Tzachi Levent-Levi، Bloggeek.me، ویدئو + کنفرانس 2015

WebRTC برای بازار ویدئو کنفرانس

افزایش تعداد پایانه های ویدئو کنفرانس

فناوری WebRTC تأثیر زیادی بر توسعه بازار ویدئو کنفرانس داشته است. پس از عرضه اولین مرورگرهای با پشتیبانی WebRTC در سال 2013، تعداد بالقوه پایانه های کنفرانس ویدیویی در سراسر جهان بلافاصله 1 میلیارد دستگاه افزایش یافت. در واقع، هر مرورگر به یک ترمینال ویدئو کنفرانس تبدیل شده است که از نظر کیفیت ارتباطی از همتایان سخت افزاری خود کم نیست.

استفاده در راه حل های تخصصی

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

کاربران سابق اسکایپ برای لینوکس

در سال 2014، مایکروسافت پایان پشتیبانی از پروژه اسکایپ برای لینوکس را اعلام کرد که باعث عصبانیت شدید متخصصان فناوری اطلاعات شد. فناوری WebRTC به سیستم عامل گره خورده نیست، بلکه در سطح مرورگر پیاده سازی می شود، یعنی. کاربران لینوکسقادر خواهد بود محصولات و خدمات مبتنی بر WebRTC را به عنوان یک جایگزین کامل برای Skype مشاهده کند.

رقابت با فلش

WebRTC و HTML5 ضربه مهلکی برای فناوری فلش بودند که بدترین سال های خود را سپری می کرد. از سال 2017، مرورگرهای پیشرو رسماً پشتیبانی از فلش را متوقف کردند و این فناوری به طور کامل از بازار ناپدید شد. اما ما باید حق فلش را بدهیم، زیرا او بود که بازار کنفرانس وب را ایجاد کرد و ارائه داد قابلیت های فنیبرای ارتباط زنده در مرورگرها

ارائه های ویدئویی WebRTC

دیمیتری اودینتسف، TrueConf، ویدئو + کنفرانس اکتبر 2017

کدک ها در WebRTC

کدک های صوتی

WebRTC از کدک های Opus و G.711 برای فشرده سازی ترافیک صوتی استفاده می کند.

G.711- قدیمی ترین کدک صوتی با نرخ بیت بالا (64 کیلوبیت در ثانیه) که بیشتر در سیستم های تلفن سنتی استفاده می شود. مزیت اصلی حداقل بار محاسباتی به دلیل استفاده از الگوریتم های فشرده سازی سبک وزن است. این کدک از فشرده سازی سیگنال های صوتی پایینی برخوردار است و تاخیر صوتی اضافی را در هنگام ارتباط بین کاربران ایجاد نمی کند.

G.711 توسط تعداد زیادی دستگاه پشتیبانی می شود. استفاده از سیستم‌هایی که از این کدک استفاده می‌کنند نسبت به سیستم‌هایی که مبتنی بر کدک‌های صوتی دیگر هستند (G.723، G.726، G.728، و غیره) راحت‌تر است. از نظر کیفیت، G.711 در تست MOS امتیاز 4.2 را دریافت کرد (امتیاز بین 4-5 بالاترین و میانگین است. کیفیت خوب، مشابه کیفیت انتقال ترافیک صوتی در ISDN و حتی بالاتر).

اپوسیک کدک با تأخیر کدگذاری کم (از 2.5 میلی‌ثانیه تا 60 میلی‌ثانیه)، پشتیبانی از نرخ بیت متغیر و سطوح فشرده‌سازی بالا، که برای انتقال سیگنال‌های صوتی جریانی در شبکه‌های با متغیر ایده‌آل است. توان عملیاتی. Opus یک راه حل ترکیبی است که بهترین ویژگی های کدک های SILK (فشرده سازی صدا، حذف تحریف گفتار انسان) و CELT (کدگذاری داده های صوتی) را ترکیب می کند. کدک به صورت رایگان در دسترس است؛ توسعه دهندگانی که از آن استفاده می کنند نیازی به پرداخت حق امتیاز به دارندگان حق چاپ ندارند. در مقایسه با سایر کدک های صوتی، Opus بدون شک از بسیاری جهات برنده است. این کدک های بسیار محبوب با نرخ بیت کم مانند MP3، Vorbis، AAC LC را تحت الشعاع قرار داده است. Opus صدای "تصویر" را نزدیک تر از AMR-WB و Speex به صدای اصلی بازیابی می کند. این کدک آینده است، به همین دلیل است که سازندگان فناوری WebRTC آن را در محدوده اجباری استانداردهای صوتی پشتیبانی شده قرار داده اند.

کدک های ویدیویی

مسائل انتخاب کدک ویدیویی برای WebRTC چندین سال طول کشید و در نهایت تصمیم گرفتند از H.264 و VP8 استفاده کنند. تقریباً تمام مرورگرهای مدرن از هر دو کدک پشتیبانی می کنند. سرورهای کنفرانس ویدئویی برای کار با WebRTC فقط باید از یکی پشتیبانی کنند.

VP8- یک کدک ویدیویی رایگان با مجوز باز، که با سرعت رمزگشایی جریان ویدیویی بالا و افزایش مقاومت در برابر از دست دادن فریم مشخص می شود. کدک جهانی است و به راحتی در پلتفرم های سخت افزاری پیاده سازی می شود، به همین دلیل است که توسعه دهندگان سیستم های کنفرانس ویدئویی اغلب از آن در محصولات خود استفاده می کنند.

کدک ویدیویی پولی H.264خیلی زودتر از برادرش معروف شد. این یک کدک با درجه بالایی از فشرده سازی جریان ویدیو هنگام ذخیره است کیفیت بالاویدئو شیوع بالای این کدک در بین سیستم های ویدئو کنفرانس سخت افزاری استفاده از آن در استاندارد WebRTC را نشان می دهد.

گوگل و موزیلا به طور فعال کدک VP8 را تبلیغ می کنند و مایکروسافت، اپل و سیسکو فعالانه H.264 را (برای اطمینان از سازگاری با سیستم های کنفرانس ویدیویی سنتی) تبلیغ می کنند. و در اینجا یک مشکل بسیار بزرگ برای توسعه دهندگان راه حل های WebRTC ابری ایجاد می شود، زیرا اگر همه شرکت کنندگان در یک کنفرانس از یک مرورگر استفاده کنند، کافی است کنفرانس را یک بار با یک کدک مخلوط کنید، و اگر مرورگرها متفاوت هستند و Safari / Edge هستند. در میان آنها، کنفرانس باید دو بار کدک های مختلف کدگذاری شود، که دو برابر خواهد شد سیستم مورد نیازبه سرور رسانه و در نتیجه هزینه اشتراک خدمات WebRTC.

WebRTC API

فناوری WebRTC بر اساس سه API اصلی است:

• (مسئول دریافت سیگنال های صوتی و تصویری از دوربین ها یا دسکتاپ کاربر توسط مرورگر وب است).
• RTCPeer Connection(مسئول ارتباط بین مرورگرها برای «تبادل» داده‌های رسانه‌ای دریافتی از دوربین، میکروفون و دسکتاپ است. همچنین «مسئولیت‌های» این API شامل پردازش سیگنال (پاکسازی آن از نویزهای اضافی، تنظیم صدای میکروفون) و کنترل بر روی کدک های صوتی و تصویری استفاده می شود).
• کانال RTCData(انتقال داده دو طرفه را از طریق یک اتصال برقرار شده فراهم می کند).

قبل از دسترسی به میکروفون و دوربین کاربر، مرورگر برای این کار اجازه درخواست می کند. که در گوگل کروممی‌توانید دسترسی را از قبل در بخش «تنظیمات» پیکربندی کنید؛ در اپرا و فایرفاکس، دستگاه‌ها مستقیماً در زمان دسترسی، از یک لیست کشویی انتخاب می‌شوند. درخواست مجوز همیشه هنگام استفاده از پروتکل HTTP و فقط یک بار در صورت استفاده از HTTPS ظاهر می شود:

RTCPeer Connection. هر مرورگر شرکت کننده در کنفرانس WebRTC باید به آن دسترسی داشته باشد این شی. به لطف استفاده از RTCPeerConnection، داده های رسانه از یک مرورگر به مرورگر دیگر حتی می توانند از طریق NAT و فایروال ها. برای انتقال موفقیت‌آمیز جریان‌های رسانه، شرکت‌کنندگان باید داده‌های زیر را با استفاده از یک وسیله نقلیه مانند سوکت‌های وب مبادله کنند:

• شرکت کننده آغازگر یک پیشنهاد-SDP (ساختار داده با ویژگی های جریان رسانه ای که ارسال خواهد کرد) برای شرکت کننده دوم ارسال می کند.
• شرکت کننده دوم یک "پاسخ" ایجاد می کند - Answer-SDP و آن را برای آغازگر ارسال می کند.
• سپس مبادله نامزدهای ICE بین شرکت‌کنندگان سازماندهی می‌شود، در صورت شناسایی (اگر شرکت‌کنندگان پشت NAT یا فایروال‌ها باشند).

پس از اتمام موفقیت آمیز این تبادل، انتقال مستقیم جریان های رسانه ای (صوتی و تصویری) بین شرکت کنندگان سازماندهی می شود.

کانال RTCData. پشتیبانی از پروتکل Data Channel نسبتاً اخیراً در مرورگرها ظاهر شده است، بنابراین این API فقط در موارد استفاده از WebRTC در مرورگرها قابل بررسی است. موزیلا فایرفاکس 22+ و Google Chrome 26+. با کمک آن، شرکت کنندگان می توانند تبادل کنند پیام های متنیدر مرورگر

اتصال از طریق WebRTC

مرورگرهای دسکتاپ پشتیبانی شده

• Google Chrome (17+) و همه مرورگرهای مبتنی بر موتور Chromium.
• Mozilla FireFox (18+)؛
• اپرا (12+)؛
• سافاری (11+);

مرورگرهای موبایل پشتیبانی شده برای اندروید

• Google Chrome (28+)؛
• موزیلا فایرفاکس (24+)؛
• Opera Mobile (12+);
• سافاری (11+).

WebRTC، مایکروسافت و اینترنت اکسپلورر

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

به گفته توسعه دهندگان، ORTC توسعه استاندارد WebRTC با مجموعه ای از API های بهبود یافته مبتنی بر جاوا اسکریپت و HTML5 است، که به زبان عادی ترجمه شده است، به این معنی که همه چیز یکسان خواهد بود، فقط مایکروسافت، نه گوگل، استاندارد را کنترل خواهد کرد. و توسعه آن مجموعه کدک ها با پشتیبانی از H.264 و برخی از کدک های صوتی سری G.7ХХ که در سیستم های تلفنی و سخت افزاری ویدئو کنفرانس استفاده می شود، گسترش یافته است. ممکن است پشتیبانی داخلی برای RDP (برای انتقال محتوا) و پیام رسانی وجود داشته باشد. به هر حال، کاربران اینترنت اکسپلورر شانسی ندارند؛ پشتیبانی ORTC فقط در Edge در دسترس خواهد بود. و البته، این مجموعه از پروتکل‌ها و کدک‌ها به راحتی با Skype for Business ارتباط برقرار می‌کنند، که حتی برنامه‌های تجاری بیشتری را برای WebRTC باز می‌کند.

هدف از این مقاله استفاده از نمونه آزمایشی چت تصویری همتا به همتا (چت تصویری p2p) است تا با ساختار و اصل عملکرد آن آشنا شوید. برای این منظور از نسخه ی نمایشی چت ویدیویی چند کاربره همتا به همتا webrtc.io-demo استفاده خواهیم کرد. از لینک زیر قابل دانلود است: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

لازم به ذکر است که گیت هاب یک سایت یا وب سرویس برای توسعه مشارکتی پروژه های وب است. در آن، توسعه دهندگان می توانند کدهای پیشرفت های خود را پست کنند، در مورد آنها بحث کنند و با یکدیگر ارتباط برقرار کنند. علاوه بر این، برخی از شرکت های بزرگ فناوری اطلاعات، مخازن رسمی خود را در این سایت قرار می دهند. این سرویس برای پروژه های منبع باز رایگان است. GitHub یک مخزن برای کتابخانه های کد منبع باز و رایگان است.

بنابراین، نمونه آزمایشی چت ویدیویی نظیر به نظیر دانلود شده از GitHub را در درایو C قرار می دهیم. کامپیوتر شخصیدر دایرکتوری ایجاد شده برای برنامه ما "webrtc_demo".

برنج. 1

همانطور که از ساختار (شکل 1) نشان داده شده است، چت ویدیویی نظیر به نظیر شامل اسکریپت های Client script.js و server server.js است که در زبان برنامه نویسی جاوا اسکریپت پیاده سازی شده اند. اسکریپت (کتابخانه) webrtc.io.js (CLIENT) - سازماندهی ارتباطات بلادرنگ بین مرورگرها را با استفاده از طرح همتا به همتا فراهم می کند: "مشتری-مشتری" و webrtc.io.js (CLIENT) و webrtc. io.js (SERVER)، با استفاده از پروتکل WebSocket، آنها ارتباط دوطرفه بین مرورگر و وب سرور را با استفاده از معماری سرویس گیرنده-سرور فراهم می کنند.

اسکریپت webrtc.io.js (SERVER) در کتابخانه webrtc.io موجود است و در دایرکتوری node_modules\webrtc.io\lib قرار دارد. رابط چت ویدیویی index.html در HTML5 و CSS3 پیاده سازی شده است. محتویات فایل های برنامه webrtc_demo را می توان با استفاده از یکی از ویرایشگرهای html، به عنوان مثال "Notepad++" مشاهده کرد.

ما اصل کار چت تصویری را بررسی خواهیم کرد سیستم فایلکامپیوتر برای اجرای سرور (server.js) در رایانه شخصی، باید محیط اجرا node.js را نصب کنید. Node.js به شما امکان می دهد کدهای جاوا اسکریپت را خارج از مرورگر اجرا کنید. می توانید node.js را از لینک زیر دانلود کنید: http://nodejs.org/ (نسخه v0.10.13 از تاریخ 07/15/13). در صفحه اصلی وب سایت node.org بر روی دکمه دانلود کلیک کرده و به آدرس http://nodejs.org/download/ بروید. برای کاربران ویندوز، ابتدا win.installer (.msi) را دانلود کنید، سپس win.installer (.msi) را در رایانه شخصی اجرا کنید، و nodejs و "npm package manager" را در دایرکتوری Program Files نصب کنید.

برنج. 2

بنابراین، node.js شامل یک محیط برای توسعه و اجرای کد جاوا اسکریپت، و همچنین مجموعه‌ای از ماژول‌های داخلی است که می‌توانند با استفاده از مدیر بسته مدیریت یا npm نصب شوند.

برای نصب ماژول ها باید خط فرماناز دایرکتوری برنامه (به عنوان مثال، "webrtc_demo") دستور را اجرا کنید: npm module_name را نصب کنید. در حین نصب ماژول ها، مدیر npm یک پوشه node_modules در دایرکتوری که نصب از آن انجام شده است ایجاد می کند. در طول عملیات، nodejs به طور خودکار ماژول ها را از دایرکتوری node_modules متصل می کند.

بنابراین، پس از نصب node.js، خط فرمان را باز کنید و ماژول express را در پوشه node_modules پوشه webrtc_demo با استفاده از مدیر بسته npm به روز کنید:

C:\webrtc_demo>npm express را نصب کنید

ماژول express یک چارچوب وب برای node.js یا یک پلتفرم وب برای توسعه برنامه است. برای دسترسی جهانی به Express، می توانید آن را به این صورت نصب کنید: npm نصب -g express.

سپس ماژول webrtc.io را به روز کنید:

C:\webrtc_demo>npm webrtc.io را نصب کنید

سپس در خط فرمان سرور را راه اندازی می کنیم: server.js:

C:\webrtc_demo>node server.js

برنج. 3

تمام است، سرور با موفقیت در حال اجرا است (شکل 3). اکنون، با استفاده از یک مرورگر وب، می توانید با آدرس IP با سرور تماس بگیرید و صفحه وب index.html را بارگیری کنید، که مرورگر وب کد اسکریپت مشتری - script.js و کد اسکریپت webrtc.io.js را از آن استخراج می کند. آنها را اجرا کنند. برای انجام چت ویدیویی همتا به همتا (برای برقراری ارتباط بین دو مرورگر)، باید با سرور سیگنالی که روی node.js اجرا می‌شود از دو مرورگر که از webrtc پشتیبانی می‌کنند، تماس بگیرید.

در نتیجه، رابط بخش مشتری برنامه ارتباطی (چت تصویری) با درخواست مجوز برای دسترسی به دوربین و میکروفون باز می شود (شکل 4).

برنج. 4

پس از کلیک بر روی دکمه "Allow"، دوربین و میکروفون برای ارتباط چند رسانه ای متصل می شوند. علاوه بر این، می توانید از طریق داده های متنی از طریق رابط چت ویدیویی ارتباط برقرار کنید (شکل 5).

برنج. 5

لازم به ذکر است که. سرور یک سرور سیگنالینگ است و عمدتا برای ایجاد ارتباط بین مرورگرهای کاربر طراحی شده است. Node.js برای کارکرد اسکریپت سرور server.js که سیگنالینگ WebRTC را ارائه می دهد استفاده می شود.