Real-time комуникации в мобилната разработка: какво е, какви протоколи и как работи

Real-time комуникации: протоколи WebSocket, SSE и Long Polling

Real-time комуникациите са технологии, които позволяват обмен на данни между клиент и сървър с минимално закъснение. Основните протоколи: WebSocket, SSE (Server-Sent Events), Long Polling и Short Polling. Всеки има своя ниша: WebSocket за двупосочна комуникация, SSE за известия, Long Polling като резервен вариант за стари браузъри. Реалното време в мобилната разработка е особено важно: потребителите очакват незабавна доставка на съобщения и известия. Комуникациите в мобилната разработка се изграждат именно на тези протоколи.

WebSocket vs SSE

WebSocket е пълно-дуплексен протокол (клиент ↔ сървър). След ръкостискането (HTTP Upgrade) връзката остава отворена. Заглавията са минимални (2 байта срещу HTTP заглавия). Използва се в чатове (WhatsApp, Telegram), игри, real-time търговия. SSE е еднопосочен протокол (сървър → клиент). Клиентът се абонира за събития и ги получава чрез една HTTP връзка. SSE е по-прост, по-лесен за мащабиране (обикновен HTTP), идеален за Twitter емисии, валутни курсове, push известия.

Long Polling е техника, при която клиентът прави HTTP заявка и я държи отворена, докато сървърът изпрати данни или настъпи таймаут (30–60 сек). След получаване на данни клиентът незабавно отваря нова заявка. Long Polling е резервен вариант за WebSocket. Short Polling — клиентът пита сървъра на всеки N секунди. Най-простият, но неефективен (повечето заявки връщат празни отговори).

Сигнален сървър

Преди установяване на P2P връзка устройствата се нуждаят от Сигнален сървър — посреднически сървър за обмен на SDP предложения и ICE кандидати между пировете. Сигнализацията може да бъде реализирана чрез WebSocket, SSE или всеки друг протокол. След установяване на връзката сигнализацията вече не участва в предаването на медийния трафик.

WebRTC: real-time комуникации с аудио и видео разговори

WebRTC (Web Real-Time Communication) е отворена технология за P2P аудио/видео/данни. Работи в браузъри и родни приложения (iOS, Android). WebRTC включва: getUserMedia (достъп до камера/микрофон), RTCPeerConnection (P2P връзка), RTCDataChannel (прехвърляне на данни). WebRTC осигурява real-time комуникации в мобилните приложения — комуникациите в мобилните приложения работят без допълнителни плъгини.

WebRTC поток

Пир A създава RTCPeerConnection и Offer SDP. Стъпка 2: Offer се изпраща чрез Сигналния сървър до пир B. Стъпка 3: Пир B получава Offer, създава Answer SDP и го изпраща обратно. Стъпка 4: И двата пира събират ICE кандидати (адреси за връзка) и ги обменят чрез Сигнализация. Стъпка 5: ICE рамката избира най-добрия път (P2P или чрез TURN). След връзката — медийният трафик тече директно.

SDP (Session Description Protocol) е текстов протокол, описващ параметрите на връзката: кодеци, IP адреси, портове. ICE Candidate е предложение от STUN/TURN: "Може да бъдете намерени на този адрес". Колкото повече кандидати, толкова по-голям е шансът за P2P.

Socket.IO е лидер за стартъпи: вие контролирате сървъра, без ограничения. Pusher и Ably са за продукти, където не искате да управлявате инфраструктура. PubNub е за IoT и глобална аудитория. IT Sectr препоръчва Socket.IO за проекти със собствен backend, Pusher за бързи прототипи, Ably за предприятия с изисквания за надеждност.

Платформи: Socket.IO, Pusher, Ably, PubNub

Real-time платформите предоставят готова сървърна инфраструктура за WebSocket и SSE. Те елиминират необходимостта от писане на собствен real-time сървър, балансиране на WebSocket връзки и мащабирането им. Изборът на платформа зависи от бюджета, изискванията за надеждност и готовността за управление на сървър. За real-time в мобилната разработка платформите предлагат готови клиентски SDK и инфраструктура.

Socket.IO

Socket.IO е библиотека за Node.js и клиенти (iOS, Android, уеб). Базирана на WebSocket, но използва HTTP polling като резерва. Поддържа стаи, именни пространства, ACK потвърждения. За разработка — socket.io-client-java (Android) и socket.io-client-swift (iOS). Комуникациите в мобилните приложения на Socket.IO се обработват надеждно благодарение на автоматичното повторно свързване.

Pusher и Ably

Pusher е real-time SaaS платформа. Проста интеграция: създайте канал и се абонирайте за събития. Pusher Channels за известия, Pusher Beams за push известия. Ably е на корпоративно ниво с глобална репликация в 7 центъра за данни. Гарантира exactly-once доставка. Поддържа SSE, WebSocket, MQTT за IoT. И двете платформи решават задачите за комуникация в мобилната разработка без писане на сървърен код.

Инфраструктура за real-time: STUN, TURN, Signaling в WebRTC

STUN (Session Traversal Utilities for NAT) е сървър, който помага на устройството да открие своя външен IP и порт зад NAT. Устройството изпраща STUN заявка, сървърът отговаря: "Виждате се като 203.0.113.5:45678". STUN се използва безплатно (Google STUN: stun.l.google.com:19302). В контекста на real-time инфраструктурата, STUN е първата стъпка към установяване на P2P канал.

STUN vs TURN

TURN (Traversal Using Relays around NAT) е релеен сървър, който препредава медийния трафик, ако P2P връзката е невъзможна (напр. и двете устройства зад симетричен NAT). TURN консумира честотна лента на сървъра, затова е скъп. В WebRTC ICE рамката първо опитва P2P, след това TURN като последен вариант. Real-time в разработката изисква TURN за комуникации в мобилни приложения при свързване чрез корпоративни мрежи.

ICE (Interactive Connectivity Establishment) е рамка, която събира всички възможни пътища за връзка (локален IP, външен IP чрез STUN, TURN релета) и избира най-добрия. ICE Candidate е всеки възможен път. Колкото повече кандидати, толкова по-голяма е вероятността за успешен P2P.

Peer-to-Peer

P2P е директна връзка между две устройства без посреднически сървър за медийния трафик. P2P намалява закъснението (< 100 ms) и сървърните разходи. Недостатъци: слаба защита срещу NAT, необходимост от STUN/TURN. WebRTC използва P2P по подразбиране.

P2P и ICE

Peer-to-Peer (P2P) е архитектура, при която данните се прехвърлят директно между устройствата. В контекста на real-time комуникациите, P2P се използва в WebRTC за минимизиране на закъснението. ICE (Interactive Connectivity Establishment) е механизмът, който намира най-добрия път за P2P връзка. За разработка P2P е оптималният начин за организиране на комуникации в мобилни приложения в реално време.

Как работи ICE

ICE събира ICE Candidate от три типа: 1) host (локален IP), 2) srflx (чрез STUN), 3) relay (чрез TURN). Всички кандидати се сортират и ICE се опитва да се свърже с всеки по приоритет. Първата успешна връзка се използва. Ако P2P е невъзможно, се използва TURN (но е скъпо).