Просто про webrtc
Більшість матеріалу по WebRTC зосереджено на прикладному рівні написання коду і не сприяє розумінню технології. Спробуємо заглибитися і дізнатися як відбувається з'єднання, що таке дескриптор сесії і кандидати, для чого потрібні STUN і TURN сервера.
WebRTC успішно справляється з такими проблемами, використовуючи протокол ICE. який, правда, вимагає використання додаткових серверів (STUN. TURN). Про все це нижче.
Дві фази WebRTC
Отже, розглянемо першу фазу - фазу встановлення з'єднання. Вона складається з декількох пунктів. Розглянемо цю фазу спочатку для вузла, який ініціює з'єднання, а потім для очікує.
Відмінність лише в другому пункті.
Подумки етап createOffer або createAnswer слід з'єднати з етапами передачі SDP і Ice candidate об'єктів.
Далі будуть розглянуті деякі сутності докладніше, а саме - медіапотоків (MediaStream), дескриптор сесії (SDP) і кандидати (Ice candidate).
Основні сутності
Медіа потоки (MediaStream)
В WebRTC існує досить заплутана ієрархія всередині потоку. Кожен потік може складатися з декількох медіа доріжок (MediaTrack), які в свою чергу можуть складатися з декількох медіа каналів (MediaChannel). Та й самих медіа потоків може бути теж декілька.
Так, а якщо медіа доріжки можна ідентифікувати через мітку, то навіщо нам для нашого прикладу використовувати два медіа потоку, замість одного? Адже можна передавати один медіа потік, а доріжки використовувати в ньому різні. Ми дійшли до важливого властивості медіа потоків - вони синхронізують медіа доріжки. Різні медіа потоки не синхронізуються між собою, але всередині кожного медіа потоку все доріжки відтворюються одночасно.
Таким чином, якщо ми хочемо, щоб наші слова, наші емоції на обличчі і наш листочок паперу відтворювалися одночасно, то варто використовувати один медіа потік. Якщо це не так важливо, то вигідніше використовувати різні потоки - картинка буде більш гладкою 4.
Якщо якусь доріжку необхідно відключати під час передачі, то можна скористатися властивістю enabled медіа доріжки.
Дескриптор сесії (SDP)
Так як в WebRTC є можливість редагування SDP об'єкта, то після отримання локального дескриптора його потрібно встановити. Це може здатися трохи дивним, що потрібно передавати WebRTC те, що вона сама нам дала, але такий протокол. Коли переходите дескриптора його потрібно теж встановити. Тому Ви повинні на одному вузлі встановити два дескриптора - свій і чужий (тобто локальний і віддалений).
Після такого рукостискання вузли знають про побажання один одного. Наприклад, якщо вузол 1 підтримує кодеки A і B. а вузол 2 підтримує кодеки B і C. то, так як кожен вузол знає свій і чужий дескриптори, обидва вузла виберуть кодек B (Малюнок 7). Логіка з'єднання тепер встановлена, і можна передавати медіа потоки, але є інша проблема - вузли і раніше пов'язані лише сигнальним механізмом.
Кандидати (Ice candidate)
Різниця від дескрипторів сесії полягає в тому, що встановлювати потрібно тільки віддалених кандидатів. Редагування тут заборонено і не може принести ніякої користі. У деяких реалізаціях WebRTC кандидатів необхідно встановлювати тільки після установки дескрипторів сесії 9.
Поки вузли в одній мережі - все просто і легко - кожен вузол має тільки один об'єкт кандидата (завжди мається на увазі свій, тобто своє розташування в мережі). Але кандидатів стане набагато більше, коли вузли будуть знаходиться в різних мережах.
Перейдемо до більш складному випадку. Один вузол буде знаходитися за роутером (точніше, за NAT), а другий вузол буде знаходитися в одній мережі з цим роутером (наприклад, в інтернеті) (Малюнок 9).
Цей випадок має приватне рішення проблеми, яке ми зараз і розглянемо. Домашній роутер зазвичай містить таблицю NAT. Це спеціальних механізм, розроблений для того, щоб вузли усередині приватній мережі роутера змогли звертатися, наприклад, до веб-сайтам.
Повернемося до технології WebRTC. а точніше, до її частини, яка використовує ICE протокол (звідси і Ice кандидати). Вузол p2 має одного кандидата (своє розташування в мережі - 10.50.200.10), а вузол p1. який знаходиться за роутером з NAT, матиме двох кандидатів - локального (192.168.0.200) і кандидата роутера (10.50.200.5). Перший не знадобиться, але він, тим не менш, генерується, так як WebRTC ще нічого не знає про віддалений хост - він може перебувати в тій же мережі, а може і ні. Другий кандидат стане в нагоді, і, як ми вже знаємо, важливу роль буде грати порт (щоб пройти через NAT).
Запис в таблиці NAT генерується тільки коли дані виходять з внутрішньої мережі. Тому вузол p1 повинен першим передати дані і тільки після цього дані вузла p2 зможуть дістатися до вузла p1.
STUN і TURN сервера
При ініціалізації WebRTC необхідно вказати доступні STUN і TURN сервера, які ми в подальшому будемо називати ICE серверами. Якщо серверу не будуть вказані, то з'єднатися зможуть тільки вузли в одній мережі (підключення до неї без NAT). Відразу варто відзначити, що для 3g-мереж обов'язково використання TURN серверів.
Розглянемо цей процес на прикладі.
Приклад (робота STUN сервера)
STUN сервер будемо позначати через s1. Роутер, як і раніше, через r1. а вузол - через p1. Також необхідно буде стежити за таблицею NAT - її позначимо як r1_nat. Причому в цій таблиці зазвичай міститься багато записів від різний вузлів підмережі - вони приводитися не будуть.
Отже, на початку маємо порожню таблицю r1_nat.
Що ж далі? Яка від цього всього користь? Користь - це запис в таблиці r1_nat. Якщо тепер хто завгодно буде відправляти на роутер r1 пакет з портом 888. то роутер перенаправляє цей пакет вузлу p1. Таким чином, створився невеликий вузький прохід до захованих вузлу p1.
З прикладу вище можна отримати деяке уявлення про роботу NAT і суті STUN сервера. Взагалі, механізм ICE і STUN / TURN сервера якраз і спрямовані на подолання обмежень NAT.
TURN сервер - це покращений STUN сервер. Звідси відразу слід витягти, що будь-який TURN сервер може працювати і як STUN сервер. Однак, є і переваги. Якщо p2p комунікація неможлива (як наприклад, в 3g мережах), то сервер переходить в режим ретранслятора (relay), тобто працює як посередник. Зрозуміло, ні про яке p2p тоді мова не йде, але за рамками механізму ICE вузли думають, що спілкуються безпосередньо.
Таким чином TURN сервер потрібен в тому випадку, коли обидва співрозмовники знаходяться за сімметрічнимNAT (кожен за своїм).
Коротке зведення
Нижче наведено деякі твердження про сутності WebRTC. які необхідно завжди пам'ятати. Детально вони описані вище. Якщо якісь з тверджень Вам здадуться не до кінця ясними, перечитайте відповідні параграфи.
Так як у всіх вузлів в цій мережі один і той же роутер. # 8617;
Цей жартівливий приклад завжди корисно пам'ятати, щоб розрізняти комунікацію в технології WebRTC від сигнальної комунікації # 8617;
Дуже спрощено. На ділі SDP - це єдині дані які передаються, а кандидати це його частина. # 8617;
На синхронізацію завжди витрачається додатковий час. # 8617;
За часів Vanilla Ice кандидати передавалися всередині SDP. тому зв'язок вже є. # 8617;
Можна тільки погодитися, відмовитися не можна. У разі відмови потрібно просто ігнорувати запит на з'єднання. # 8617;
Наприклад, при з'єднанні ftp-клієнт з ftp-сервер спочатку встановлюється TCP-з'єднання (для протоколу прикладного рівня протокол транспортного рівня можна вважати фізичним), а тільки потім передаються дані по протоколу FTP (тобто логіка протоколу). # 8617;
Така реалізація libjingle і деяких браузерів. Це так, тому що кандидати є частиною SDP об'єкта і записуються в нього. # 8617;