Przesyłanie plików przez WebRTC pozwala dwóm przeglądarkom wysłać sobie plik bez uploadu do chmury. Brzmi prosto, ale internet nie został zbudowany tak, aby dwa domowe komputery mogły łączyć się ze sobą bezpośrednio. Ten poradnik prostym językiem opisuje, co się naprawdę dzieje — sygnalizacja, NAT, STUN, ICE, TURN, DTLS i kanały danych — na przykładzie StrongFolder.
Czym jest WebRTC?
WebRTC (Web Real-Time Communication) to zestaw interfejsów API przeglądarek i protokołów sieciowych, standaryzowany przez W3C i IETF, do połączeń w czasie rzeczywistym między przeglądarkami. Obsługują go Chrome, Edge, Firefox, Safari i Opera. Powstał z myślą o rozmowach wideo i głosowych, ale ma też kanały danych, które przenoszą dowolne dane binarne — a plik to właśnie takie dane.
Kluczowa cecha: po zestawieniu połączenia WebRTC dane płyną między dwoma punktami końcowymi, a nie do pamięci serwera. To właśnie umożliwia przesyłanie plików P2P w przeglądarce.
Dlaczego dwie przeglądarki nie mogą po prostu się połączyć?
Bo prawie żadne urządzenie nie ma własnego publicznego adresu. Twój laptop stoi za domowym routerem, firmową zaporą lub siecią operatora komórkowego. Router wykonuje NAT (Network Address Translation): wiele prywatnych urządzeń dzieli jeden publiczny adres IP, a router wpuszcza tylko ruch, który jest odpowiedzią na coś wysłanego z wewnątrz.
Dlatego, zanim popłyną jakiekolwiek dane plików, dwie przeglądarki mają trzy problemy:
- Nie wiedzą, jak się nawzajem znaleźć — żadna nie wie, że druga istnieje.
- Nie znają własnego publicznego adresu — tylko prywatny, na przykład 192.168.1.20.
- Ich routery mogą blokować niezamówiony ruch przychodzący.
WebRTC rozwiązuje każdy z tych problemów osobnym mechanizmem.
Jak krok po kroku działa przesyłanie plików przez WebRTC?
Oto pełny przebieg, od kliknięcia „udostępnij” do ostatniego bajtu:
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Kroki 1–2 — sygnalizacja. Nadawca wybiera pliki; usługa zapisuje metadane potrzebne do utworzenia linku. Gdy odbiorca otwiera link, obie przeglądarki są połączone z serwerem sygnalizacyjnym. WebRTC nie określa, jak działa sygnalizacja; StrongFolder używa PeerJS z własnym serwerem sygnalizacyjnym.
Krok 3 — oferta i odpowiedź. Jedna przeglądarka tworzy ofertę w SDP (Session Description Protocol): „Chcę kanał danych, oto mój odcisk szyfrowania i możliwości”. Druga odpowiada odpowiedzią (answer). Obie przechodzą przez serwer sygnalizacyjny.
Krok 4 — STUN. Każda przeglądarka pyta serwer STUN: „z jakiego adresu i portu mnie widzisz?”. Odpowiedzią jest jej publiczny adres w postaci nadanej przez router. Serwery STUN obsługują maleńkie zapytanie i żadnych danych plików; StrongFolder używa publicznych serwerów STUN, w tym Google, oraz własnych.
Krok 5 — kandydaci ICE. Każda przeglądarka zbiera kandydatów — możliwe sposoby dotarcia do niej: adres w sieci lokalnej (host), publiczny adres z STUN (server-reflexive) i adres na serwerze TURN (relayed). Wymieniają się kandydatami przez sygnalizację.
Krok 6 — testy łączności. ICE (Interactive Connectivity Establishment) testuje pary kandydatów i wybiera najlepszą działającą. Jeśli oba urządzenia są w tej samej sieci Wi-Fi, wygrywa ścieżka lokalna. Jeśli routery na to pozwalają, wygrywa bezpośrednia ścieżka przez internet („hole punching”). Jeśli nic bezpośredniego nie działa, używana jest ścieżka przez serwer pośredniczący.
Krok 7 — DTLS. Zanim popłyną jakiekolwiek dane, przeglądarki wykonują uzgadnianie DTLS (TLS dostosowany do UDP) i sprawdzają, czy odciski certyfikatów zgadzają się z tymi z oferty i odpowiedzi. Od tej chwili wszystko jest szyfrowane.
Krok 8 — kanał danych. Na DTLS działa SCTP, który zapewnia kanałowi danych niezawodne, uporządkowane dostarczanie. W StrongFolder przeglądarka odbiorcy prosi o plik, przeglądarka nadawcy odczytuje go z dysku fragmentami i je wysyła, a odbiorca zapisuje każdy fragment na dysku zaraz po jego nadejściu — dzięki temu nawet bardzo duże pliki nigdy nie muszą mieścić się w pamięci.
Co oznaczają STUN, TURN, ICE i inne pojęcia?
| Pojęcie | Co robi | Widzi dane plików? | Standard |
|---|---|---|---|
| Sygnalizacja | Przekazuje oferty, odpowiedzi i kandydatów między przeglądarkami | Nie | Niestandaryzowana (zależy od aplikacji) |
| NAT | Funkcja routera, która dzieli jeden publiczny IP między wiele urządzeń | — | — |
| STUN | Podaje przeglądarce jej publiczny adres i port | Nie | IETF RFC 8489 |
| ICE | Zbiera kandydatów i wybiera działającą ścieżkę | Nie | IETF RFC 8445 |
| TURN | Przekazuje ruch, gdy żadna bezpośrednia ścieżka nie działa | Tylko zaszyfrowane pakiety | IETF RFC 8656 |
| DTLS | Szyfruje połączenie (TLS dla UDP) | Szyfruje je | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Kanał danych SCTP | Niezawodne, uporządkowane dostarczanie fragmentów | Przenosi je (zaszyfrowane) | IETF RFC 8831 |
Wszystkie te pojęcia krótko wyjaśnia słowniczek.
Kiedy używany jest serwer TURN i co widzi?
Serwer pośredniczący to rozwiązanie zapasowe, a nie domyślne. ICE używa go tylko wtedy, gdy żadna bezpośrednia para kandydatów się nie łączy — zwykle w sieciach z symetrycznym NAT (niektórzy operatorzy komórkowi), za firmowymi zaporami, które blokują wychodzący UDP, lub przy niektórych VPN.
Jeśli bezpośrednie połączenie jest niemożliwe (restrykcyjna zapora firmowa, niektóre sieci komórkowe), zaszyfrowany strumień przechodzi przez serwer pośredniczący (TURN) StrongFolder. Serwer pośredniczący przekazuje dane dalej i ich nie przechowuje.
Serwer pośredniczący odbiera pakiety zaszyfrowane DTLS i przekazuje je dalej. Widzi, że ruch płynie, ile go jest i kiedy — ale nie to, co jest w środku. Transfer przez serwer pośredniczący może być wolniejszy niż bezpośredni, bo każdy bajt odbywa dodatkową podróż. Jeśli transfer jest wyjątkowo wolny, spróbuj innej sieci: hotspot w telefonie lub domowe Wi-Fi często łączą się bezpośrednio tam, gdzie sieć biurowa tego nie potrafi.
Za darmo · w przeglądarce · bez rejestracji
Jak bezpieczne jest szyfrowanie WebRTC?
WebRTC wymusza szyfrowanie: nie da się otworzyć nieszyfrowanego kanału danych. DTLS używa nowoczesnych szyfrów negocjowanych przez dwie przeglądarki, a dla każdego połączenia tworzone są nowe klucze.
Jest jedno uczciwe zastrzeżenie, które dotyczy każdej usługi WebRTC. Dwie przeglądarki weryfikują się nawzajem za pomocą odcisków certyfikatów, wymienianych przez serwer sygnalizacyjny. Ufasz więc, że sygnalizacja usługi ich nie zmieni. Dlatego StrongFolder opisuje swoją ochronę jako szyfrowanie podczas przesyłania — a nie jako szyfrowanie end-to-end kluczami, które posiadasz, i nie jako „zero-knowledge”. Szersze spojrzenie na to, co znaczy „bezpieczne”, znajdziesz w poradniku Bezpieczne udostępnianie plików i na stronie Bezpieczeństwo i prywatność.
Dlaczego przeglądarka nadawcy musi pozostać otwarta?
Bo przeglądarka nadawcy jest źródłem. Nie ma kopii na serwerze, do której można by sięgnąć: kanał danych odczytuje fragmenty z dysku nadawcy tylko wtedy, gdy karta jest otwarta, a urządzenie nie śpi. Karta przeglądarki nadawcy musi pozostać otwarta i online, dopóki odbiorca nie skończy pobierania — pliki pochodzą z urządzenia nadawcy, a nie z serwera. Jak to zaplanować, opisuje poradnik Dlaczego nadawca musi pozostać online.
Jak szybkie jest przesyłanie plików przez WebRTC?
Nie ma stałej prędkości. Górną granicą jest najwolniejsze ogniwo na ścieżce: zwykle prędkość wysyłania nadawcy. W przybliżeniu 1 GB zajmuje około 2,7 minuty przy 50 Mbit/s, około 80 sekund przy 100 Mbit/s i znacznie poniżej minuty w szybkiej sieci lokalnej. Rzeczywiste transfery są nieco wolniejsze z powodu narzutu protokołu, szybkości dysku i — przy serwerze pośredniczącym — dodatkowego przeskoku. Jeden link może otworzyć kilku odbiorców; każdy pobiera pliki bezpośrednio od nadawcy. Kilka równoczesnych pobierań dzieli przepustowość wysyłania nadawcy.
Podsumowanie
Przesyłanie plików przez WebRTC to krótka negocjacja, po której następuje długi, szyfrowany strumień: sygnalizacja przedstawia sobie przeglądarki, STUN i ICE znajdują ścieżkę przez NAT, TURN pośredniczy w ostateczności, a kanały danych szyfrowane DTLS przenoszą plik z dysku na dysk. Praktyczną stronę — co to oznacza dla ciebie jako nadawcy — zacznij od poradników Przesyłanie plików P2P w przeglądarce i Jak działa StrongFolder.