# Jak działa przesyłanie plików przez WebRTC

Source: https://help.strongfolder.com/pl/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> Przesyłanie plików przez WebRTC przebiega w trzech fazach. Serwer sygnalizacyjny przedstawia sobie dwie przeglądarki; STUN i ICE znajdują ścieżkę sieciową przez domowe routery (NAT), a gdy bezpośrednia ścieżka nie istnieje, używają serwera pośredniczącego TURN; potem przeglądarki otwierają kanał danych szyfrowany DTLS i przesyłają plik fragmentami, bezpośrednio lub przez serwer pośredniczący, bez przechowywania go.

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.

**Key facts**

- **WebRTC** to standard przeglądarek do bezpośrednich, szyfrowanych połączeń między dwoma urządzeniami; narzędzia do plików korzystają z jego **kanałów danych**.
- **Sygnalizacja** przedstawia sobie przeglądarki; **STUN** i **ICE** znajdują ścieżkę przez routery (**NAT**); **serwer pośredniczący TURN** przekazuje ruch, gdy nie ma bezpośredniej ścieżki.
- **Szyfrowanie:** każdy kanał danych używa **DTLS** — WebRTC nie ma trybu bez szyfrowania.
- StrongFolder używa PeerJS na bazie WebRTC, serwera sygnalizacyjnego StrongFolder, publicznych serwerów STUN (w tym Google) i własnych serwerów TURN. Pliki nigdy nie są wysyłane ani przechowywane na serwerze StrongFolder.
- Plik płynie fragmentami z dysku nadawcy na dysk odbiorcy; nadawca pozostaje online.

## Czym jest WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/).

## 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](https://help.strongfolder.com/en/glossary/#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:

1. Nie wiedzą, **jak się nawzajem znaleźć** — żadna nie wie, że druga istnieje.
2. Nie znają **własnego publicznego adresu** — tylko prywatny, na przykład 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

## 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.

[Wyślij pliki teraz](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/) i na stronie
[Bezpieczeństwo i prywatność](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) i
[Jak działa StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Czym jest kanał danych WebRTC?

Kanał danych to część WebRTC, która przenosi między dwiema przeglądarkami dowolne bajty zamiast dźwięku czy obrazu. Działa w oparciu o SCTP przez DTLS przez UDP, więc jest szyfrowany i można go skonfigurować jako niezawodny i uporządkowany — a tego właśnie potrzebuje przesyłanie plików.

### Czym różni się STUN od TURN?

Serwer STUN tylko mówi przeglądarce, jak wygląda jej publiczny adres, aby dwie przeglądarki mogły spróbować połączyć się bezpośrednio; nie przechodzą przez niego żadne dane plików. Serwer TURN jest pośrednikiem: gdy żadna bezpośrednia ścieżka nie działa, zaszyfrowany strumień idzie przez niego. StrongFolder utrzymuje własne serwery TURN, które przekazują dane i ich nie przechowują.

### Czy serwer sygnalizacyjny widzi moje pliki?

Nie. Serwer sygnalizacyjny przekazuje między przeglądarkami tylko komunikaty o połączeniu — opisy sesji i kandydatów sieciowych. Dane plików płyną kanałem danych, bezpośrednio lub przez serwer TURN.

### Czy przesyłanie plików przez WebRTC jest szyfrowane?

WebRTC szyfruje każdy kanał danych za pomocą DTLS, więc strumień plików jest szyfrowany podczas przesyłania przy każdym połączeniu. WebRTC nie pozwala na nieszyfrowane kanały danych. Klucze negocjują dwie przeglądarki; ich odciski (fingerprints) przechodzą przez sygnalizację, dlatego jest to szyfrowanie podczas przesyłania, a nie szyfrowanie end-to-end kluczami, którymi sam zarządzasz.

### Dlaczego transfer WebRTC czasem się nie udaje lub jest wolny?

Zwykle z powodu ścieżki sieciowej: restrykcyjna zapora lub VPN blokuje bezpośredni UDP, więc połączenie przechodzi na serwer TURN przez TCP albo w ogóle się nie nawiązuje. Spróbuj innej sieci (na przykład hotspotu w telefonie), wyłącz VPN lub poproś dział IT o odblokowanie WebRTC.

### Czy serwer TURN może odczytać moje pliki?

Serwer pośredniczący przekazuje między dwiema przeglądarkami pakiety zaszyfrowane DTLS. Widzi zaszyfrowany ruch, rozmiary i czas, ale nie zawartość plików, a serwer pośredniczący StrongFolder nie przechowuje tego, co przekazuje.