WebRTC

Co to jest WebRTC i do czego służy?

WebRTC (Web Real-Time Communication) to otwarty standard i zestaw APIs który umożliwia real-time komunikację peer-to-peer (P2P) bezpośrednio w przeglądarce — bez potrzeby pluginów, zewnętrznych aplikacji ani serwera pośredniczącego dla mediów. Główne możliwości WebRTC: Audio i wideo streaming — video calls, video conferencing. Data channels — peer-to-peer transfer danych (pliki, wiadomości, game state). Screen sharing — udostępnianie ekranu (getDisplayMedia). Kto używa WebRTC: Google Meet, Microsoft Teams (hybryda), Discord, Twitch (low-latency mode), Zoom (w części), Jitsi Meet (open-source), Daily.co, Whereby. Kluczowe APIs przeglądarki: getUserMedia() — dostęp do kamery i mikrofonu. getDisplayMedia() — screen sharing. RTCPeerConnection — główne API do zarządzania połączeniem P2P. RTCDataChannel — data channel dla dowolnych danych. Techniczne filary: ICE (Interactive Connectivity Establishment) — mechanizm przebijania przez NAT/firewall. STUN — odkrywa publiczne IP urządzenia. TURN — relay server gdy bezpośrednie P2P niemożliwe. SDP (Session Description Protocol) — opisuje możliwości i parametry połączenia. Kodeki: dla video: VP8, VP9, H.264 (AV1 emerging). Dla audio: Opus (dominujący, adaptacyjny bitrate).

Jak działa WebRTC — ICE, STUN, TURN i SDP?

WebRTC Signaling i ICE: Podstawowy problem: jak dwa urządzenia za różnymi NAT-ami i firewallami mogą bezpośrednio komunikować się? Odpowiedź: ICE (Interactive Connectivity Establishment) + STUN + TURN. STUN (Session Traversal Utilities for NAT): klient wysyła request do STUN server → otrzymuje swój publiczny IP i port. Tak oba peers mogą poznać swoje publiczne adresy. Publiczne STUN serwery: stun.l.google.com:19302. TURN (Traversal Using Relays around NAT): gdy bezpośrednie P2P jest zablokowane (symmetric NAT, corporate firewall) — TURN server relayuje ruch. Droższe (bandwidth cost) ale zawsze działa. Coturn — popularny open-source TURN server. SDP (Session Description Protocol): opisuje co peer oferuje — kodeki, rozdzielczość, bitrate, SRTP klucze. Offer/Answer model: Alice tworzy Offer SDP → wysyła do Bob przez Signaling Server → Bob tworzy Answer SDP → wysyła z powrotem. Signaling Server: WebRTC nie definiuje jak wymienić SDP i ICE candidates — to zależy od aplikacji. Najczęściej: WebSocket server, lub XMPP/SIP. Tylko do wymiany metadanych — media flow jest P2P. ICE Candidates: STUN i TURN serwery dostarczają 'candidates' (adresy IP:port). ICE agent testuje wszystkie candidates i wybiera najlepsze bezpośrednie połączenie. DTLS + SRTP: WebRTC wymaga szyfrowania — DTLS do key exchange, SRTP do encrypted media.

WebRTC Topologie — Mesh, SFU, MCU?

Topologie WebRTC dla multi-party calls: Mesh (P2P Mesh): każdy uczestnik łączy się bezpośrednio z każdym innym. N uczestników = N*(N-1) połączeń na każdym kliencie. Zalety: brak serwera media. Wady: exponential bandwidth i CPU growth. Skaluje do ~4-6 uczestników (powyżej klient ma problem). SFU (Selective Forwarding Unit): centralny serwer który otrzymuje media od każdego uczestnika i selektywnie forward-uje do innych. Serwer NIE przetwarza mediów — tylko routuje. Zalety: dobry balans CPU/bandwidth. Klient wysyła 1 stream (do SFU), odbiera N streams (od SFU per participant). Skaluje do dziesiątek/setek uczestników. Narzędzia SFU: mediasoup (Node.js, open-source), LiveKit (Go, open-source, CNCF), ion-sfu (Go, Pion), Janus Gateway, Jitsi Videobridge. MCU (Multipoint Control Unit): centralny serwer który decode'uje, mix-uje i re-encode'uje wszystkie strumienie w jeden. Klient wysyła 1 stream i odbiera 1 mix'owany stream. Zalety: minimalne wymagania klienta (legacy devices). Wady: serwer musi procesować wszystkie media — drogie w CPU. Wybór: małe grupy (2-6): Mesh. Standardowe video conferencing: SFU. Legacy devices, słabe sieci: MCU. Komercyjne SaaS SFU: Twilio Video, Daily.co, Agora, Vonage Video API.

Jak zbudować aplikację WebRTC — praktyczny przewodnik?

Budowanie aplikacji WebRTC: Minimalny stos: Signaling Server (Node.js + Socket.io lub WebSocket). STUN server (Google lub własny). TURN server (coturn lub usługa jak Twilio TURN). Frontend WebRTC API. Krok 1 — Signaling Server: prosty WebSocket server który relay-uje SDP offers/answers i ICE candidates między peers. Krok 2 — Frontend (przeglądarka): getUserMedia() → lokalny stream. createPeerConnection() z ice servers config. addTrack() → dodaj lokalny stream do RTCPeerConnection. createOffer() → wyślij przez signaling server. setRemoteDescription() → ustaw answer od remote peer. onicecandidate → wysyłaj ICE candidates przez signaling. ontrack → odbierz remote stream → wyświetl w video element. Krok 3 — ICE servers config: iceServers: [{urls: 'stun:stun.l.google.com:19302'}, {urls: 'turn:your-turn-server', username: '...', credential: '...'}]. Gotowe SDK i serwisy: LiveKit SDK — open-source, self-hostable SFU. Simple Peer — uproszczone WebRTC API. Daily.co SDK — komercyjne, managed. Twilio Video SDK — komercyjne. Pion (Go) — WebRTC implementacja w Go dla serwerów. Testowanie: getStats() API — aktualna jakość (packet loss, jitter, bitrate). Wierszyk simulating bad network: Chrome Network throttling. WebRTC Internals: chrome://webrtc-internals — debug połączeń.

WebRTC a WebSockets — kiedy używać czego?

WebRTC vs. WebSockets: WebSockets: dwukierunkowe połączenie klient-serwer. Serwer jest w środku każdej komunikacji. Niskie latency vs. HTTP, ale wyższe niż P2P. Use case: chat, live updates, collaborative editing, game state sync przez serwer. WebRTC Data Channels: P2P (serwer nie jest w środku). Ultra-niskie latency gdy directConnection. Niezawodne lub unreliable mode (jak TCP lub UDP). Use case: P2P file transfer, real-time multiplayer gaming, collaborative editing P2P. Porównanie latency: WebSocket przez serwer: 50-200ms (zależy od lokalizacji serwera). WebRTC P2P (bezpośrednie): 10-50ms (zależy od dystansu peer-to-peer). WebRTC przez TURN relay: podobne do WebSocket. Praktyczne wskazówki: WebRTC = złożone (ICE, STUN, TURN, SDP — dużo do zarządzania). WebSocket = proste i przewidywalne. Hybrydowe podejście: WebSocket dla signaling i non-realtime komunikacji + WebRTC dla media/low-latency data. Nowe trendy: WebTransport — nowoczesna alternatywa do WebSockets oparta na QUIC/HTTP3. Niższe latency niż WebSocket, multiplexing. Wciąż emerging. WHIP/WHEP — nowe protokoły WebRTC dla live streaming (WebRTC Ingest). Używają WebRTC jako transport dla live streams (ultra-low-latency live streaming).

Wyślij zapytanie