Сигнальні і транспортні протоколи WebRTC: зриваємо покрови

Наша платформа VoxImplant складається з декількох частин: хмара, API, SDK для різних платформ. SDK для браузера підключається до хмари по WebSocket і дозволяє телефонувати (і приймати дзвінки) як іншим користувачам VoxImplant, так і на звичайні телефони. Раніше це працювало з допомогою flash, але в сучасних браузерах використовується спеціально створена для роботи з голосом і відео технологія WebRTC. Штука хороша, але досить складна у використанні: можливість peer-to-peer комунікацій-одна з ключових «фішок» технології, управляється повністю вручну. Щоб два браузера могли організувати голосової або відеочат один з одним, розробнику потрібно зібрати інформація про IP-адреси комп'ютерів, як передати цю інформацію між браузерами, запустити NAT Traversal і згодувати це все WebRTC. А якщо обійти NAT не вийшло, то ще й надати Relay-сервер для передачі даних.

Нещодавно ми знайшли на просторах інтернету цікаву статтю, яка розповідає технічні подробиці «передачі інформації» між браузерами. Адаптований для Хабра переклад – під катом.

Де тут сигнальний, а де транспортний рівень?
WebRTC як протокол не включає в себе механізми «сигналізації». Це означає, що вам, як розробнику, потрібно буде потурбуватися про них самостійно.

Перший крок – це вибрати протокол. А якщо бути більш точним, то два протоколи – транспортний і сигнальний. У більшості випадків ми не бачимо різницю (або не хочемо її бачити), але іноді вона дуже важлива. Нещодавно я отримав запитання до одного з постів, і це підштовхнуло мене написати пояснення.

Веб-браузери та транспортні протоколи WebRTC
Транспортний протокол необхідний нам, щоб відправляти повідомлення з одного пристрою на інший. В даному випадку не має значення, що знаходиться всередині повідомлення або повідомлення структуровано – тільки те, що воно може бути надіслано. А потім отримано.

HTTP/1.1
П'ять років тому браузери були прості, якщо ми говоримо про протоколах. По суті, у нас був HTTP/1.1 і все хакі поверх нього, відомі як XHR, SSE, BOSH, Comet. Якщо вам цікаво дізнатися більше про механіків, залиште коментар, і я постараюся пояснити в наступних статтях – хоча ви легко зможете знайти пояснення самі, якщо трохи погуглите.

Я називаю групу рішень на ряду з HTTP/1.1 – милицями. Ці рішення використовують HTTP/1.1, бо в той час просто не було альтернативи, але вони роблять це спосіб, який не має ніякого технічного сенсу.

Так, ви можете використовувати REST. Але, знову ж таки, це другорядна деталь по відношенню до HTTP/1.1.

Після цього з'явилися три технології: WebSocket, WebRTC і, зовсім недавно, HTTP/2.

WebSocket
WebSocket був доданий, щоб робити те, що HTTP/1.1 робити не може. Забезпечити двонаправлений механізм, де обидва – клієнт і веб-сервер – можуть надсилати один одному повідомлення. Що це за повідомлення, що вони означають, який тип формату вони підтримують – вирішує розробник веб-сторінки.

Також є socket.io або менш популярний SockJS. Обидва пропонують механіку на стороні клієнта, яка емулює WebSocket у випадках, коли він не може бути використаний.

Коли ваш WebSocket працює чудово, socket.io і SockJS теж прекрасні. Але іноді він не працює чудово (більше про це-нижче, під частиною HTTP/2).

WebRTC Data Channel
В деякій мірі, Data Channel використовується в WebRTC для сигналирования.

Так. Вам буде потрібно домовитися про IP-адресах, а перед цим використовувати ICE. А для цього вам буде потрібний додатковий сигнальний і транспортний рівень (список ось в цьому пості). Після встановлення з'єднання, ви можете використовувати data channel в якості сигнального рівня.

Data Channel можна використовувати для сигналирования безпосередньо між двома пристроями, або через посередників (в залежності від завдань).

Навіщо використовувати Data Channel в якості транспортного протоколу?

  1. Зменшити затримку у вашому сигналировании. Data Channel, теоретично, найшвидше, що ви можете зробити.
  2. Знизити навантаження на сервер. Тепер він не буде одержувати всі повідомлення тільки щоб перенаправити їх куди-небудь – ви будете відправляти йому те, що призначене саме йому.
  3. Збільшити рівень конфіденційності/безпеки особистих даних – коли ви не відправляєте повідомлення через сервер, це означає, що він не буде підглядати в те, що відправляється – або навіть не буде помічати, що якийсь обмін повідомленнями йде.
Але, по правді кажучи, такий варіант використовується рідко. У світі WebRTC транспортний рівень важливий ДО встановлення з'єднання, коли DataChannel ще недоступний. А використовувати DataChannel одного з'єднання як транспортний рівень для сигналирования іншого — це дивно.

HTTP/2
Я вже писав про HTTP/2 раніше. Але з тих пір HTTP/2 поширився ще більше і став ще популярнішим.

HTTP/2 усуває багато обмежень, які присутні в HTTP/1.1. Тому він може стати хорошим претендентом для протоколів сигнального рівня на все найближчим часом.

Як HTTP/2 може впливати на потреби в WebSocket, добре описав Алан Денис.

WebRTC Signaling Protocols
«Сигналирование» – це те, де ви висловлюєте себе. Чи ваш сервіс. Ви хочете, щоб один користувач зміг встановити зв'язок з іншим. Або з групою людей, які приєднуються до віртуальній кімнаті. Ви вирішуєте, які типи повідомлень вам потрібні, що вони значать, на що вони схожі і так далі.

Це ваш сигнальний протокол.

На відміну від транспортного протоколу, що ви не обмежені тим, що дозволяє браузер, а тим, чого ви намагаєтеся досягти.

Розглянемо три головних сигнальних протоколу, які часто використовуються з WebRTC.

SIP
Я ненавиджу SIP. Ніколи по-справжньому не цікавився.

У нього є сфера застосування, особливо коли справа стосується телефонії, класичних голосових та відео-сервісів. Тим не менше я знаходжу SIP занадто роздутим, складним і непотрібним – принаймні, для більшості випадків, з якими до мене звертаються люди.

SIP прийшов зі світу телефонії. Його основний транспорт був UPD. Потім для нього були додані TCP і TLS як транспортні протоколи. Потім і SCTP підтягнувся. Розбиратися в них не має сенсу, оскільки ви не можете використовувати їх через браузер. Тому WebSocket додали як SIP-транспорт і просто назвали це «SIP через WebSocket». SIP через WebSocket стандартизували раніше, ніж WebRTC (який все ще не стандартизували), і, крім іншого, він вже має своє власне RFC. Чому все вищесказане важливо? Тому що використовувати SIP через WebSocket можна тільки разом з WebRTC.

Це про SIP. І якщо ви знаєте SIP, любите його або маєте потребу в ньому, ви можете використовувати його як протокол сигнального рівня для WebRTC.

XMPP
Я ненавиджу XMPP.

Але не зовсім розумію, чому. Можливо, тому що коли я що-небудь кажу про нього погане, все затяті фанати/фолловери/фанатики протоколу XMPP кидаються захищати його в коментарях. А мене це смішить.

XMPP весь зосереджений навколо інформації про статус користувача і швидких повідомлень. Якщо це єдині вимоги, то XMPP дійсно виграє – особливо, коли розробник вже знає, що можна зробити за допомогою XMPP.

Якщо ви любите XMPP, не забудьте відповісти в коментарях, – це внизу.

Проприетарщина
Я ненавиджу NIH. Незважаючи на це, власний сигнальний протокол має багато переваг.

Дуже часто все, що ви хочете, це просто посадити двох користувачів на «одну сторінку». Не більше. Я знаю, що спрощую, але якщо не спрощувати, то ви будете тягати з собою усю надмірність протоколу загального призначення, яка вам ніколи не знадобиться.

У багатьох інших випадках ви дійсно не хочете додавати ще один веб-сервер тільки для роботи з сигналированием. Ви хочете, щоб один сервер обслуговував вашу веб додаток. Так ви приходите до свого власного протоколу сигнального рівня. Хоча ви можете його так не називати. Чи не думати про нього як про протоколі сигнального рівня.

Як зробити вибір?
Завжди починайте з протоколу сигнального рівня.

SIP потрібно використовувати, якщо є якась інфраструктура або є зовнішні сервіси, до яких ви хочете підключитися. Якщо потреби немає, тоді пропустіть.

Якщо ви любите XMPP, або потребуєте функціях інформації про статус користувача і швидких повідомлень, тоді використовуйте його.

Якщо сервіс, який ви додаєте WebRTC, має власну логіку, можливо, у нього вже є сигналирование. Тому ви просто додаєте необхідні повідомлення до проприетарному сигналированию.

У всіх інших випадках моя порада – використовувати пропрієтарне рішення для сигналирования, який точно відповідає вашим вимогам. Можна навіть використовувати для цього SaaS-рішення.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.