Wznawianie przerwanych transferów: nigdy od zera

Wznawiane transfery dzielą plik na fragmenty i śledzą, które z nich zostały pomyślnie odebrane; gdy połączenie pada, klient podnosi od następnego niewysłanego fragmentu zamiast zaczynać od bajtu zero. Standardem webowym dla tego jest tus.io (otwarty protokół wznawialnych uploadów), zaimplementowany przez SwissTransfer, HexaTransfer, Vimeo, Cloudinary i wiele nowoczesnych usług transferowych. Dla pobierań żądania HTTP Range (RFC 7233) pozwalają przeglądarkom i narzędziom takim jak curl czy aria2 wznawiać przerwane pobierania. Bez możliwości wznawiania upload 9,8 GB, który pada przy 9,5 GB, kosztuje Cię całość — z możliwością wznawiania tracisz może 50 MB.

Problem z uploadami bez wznawiania

Naiwny upload pliku wysyła cały plik jako jedno żądanie HTTP POST. Jeśli cokolwiek przerwie połączenie — spadek Wi-Fi, timeout VPN, uśpienie laptopa, chwilowy problem dostawcy internetu — połączenie TCP się zamyka, a serwer odrzuca wszystkie częściowe dane. Klient zaczyna od bajtu zero.

Dla uploadu 5 GB na łączu 50 Mbps to 13 minut pracy wyrzuconych w eter. Dla uploadu 50 GB to ponad dwie godziny. Wskaźnik niepowodzeń uploadów bez wznawiania na połączeniach mobilnych jest brutalny — 30-minutowy upload na 4G rzadko udaje się za pierwszym razem.

Jak działają protokoły wznawiania

Nowoczesne wznawiane uploady działają następująco:

Utwórz: Klient wysyła POST do serwera z całkowitym rozmiarem pliku i metadanymi. Serwer zwraca unikalny URL dla tego uploadu i rezerwuje miejsce na serwerze.
Dziel na fragmenty: Klient kroi plik na fragmenty (często 5–64 MB każdy).
Wyślij: Klient wysyła każdy fragment jako żądanie PATCH z nagłówkiem Content-Range lub Upload-Offset wskazującym pozycję fragmentu.
Potwierdź: Serwer zapisuje fragment i potwierdza nowe przesunięcie.
Wznów: Jeśli połączenie padnie, klient wysyła żądanie HEAD do URL-a uploadu. Serwer odpowiada bieżącym przesunięciem (ile bajtów odebrał). Klient wznawia od tego miejsca.
Zakończ: Gdy ostatni fragment jest potwierdzony, upload jest gotowy.

Ten model definiuje specyfikacja tus.io (wersja 1.0.0 jest szeroko wdrożona). Inne warianty to S3 Multipart Upload (dla bezpośrednich uploadów S3) i Google Cloud Storage Resumable Uploads.

Tus.io: otwarty standard

Tus („transloadit upload server") to bezpłatny, otwarty protokół utrzymywany przez Transloadit. Specyfikacja dostępna jest na tus.io i implementują ją:

Biblioteki klienckie: tus-js-client (przeglądarka + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
Implementacje serwerowe: tusd (referencyjny serwer Go), tus-node-server i wiele integracji z frameworkami
Usługi komercyjne: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, serwery companion Uppy

Protokół jest celowo minimalny: cztery czasowniki HTTP (POST, HEAD, PATCH, OPTIONS), garść nagłówków (Upload-Offset, Upload-Length, Tus-Resumable). Dzięki temu implementacje są proste i interoperacyjne.

Decyzje dotyczące rozmiaru fragmentu

Rozmiar fragmentu to kompromis między ziarnistością wznawiania a narzutem HTTP:

| Rozmiar fragmentu | Koszt odzyskania po awarii | Narzut | |---|---|---| | 1 MB | Utrata ≤ 1 MB | Wysoki (wiele żądań) | | 5 MB | Utrata ≤ 5 MB | Umiarkowany | | 16 MB | Utrata ≤ 16 MB | Niski | | 64 MB | Utrata ≤ 64 MB | Minimalny | | 256 MB | Utrata ≤ 256 MB | Pomijalny narzut, bolesny przy awarii |

Dla stabilnych łączy fragmenty 32–64 MB maksymalizują przepustowość. Dla połączeń mobilnych lub niestabilnych Wi-Fi fragmenty 2–5 MB szybciej odzyskują się po każdej awarii. Usługi zwykle wybierają domyślny rozmiar 5–10 MB jako kompromis.

Co faktycznie przerywa transfery

Zrozumienie trybów awarii pomaga ocenić, czy implementacja wznawiania danej usługi jest odporna:

Spadki Wi-Fi: zmiana sieci, utrata sygnału, restart routera. Bardzo częste.
Uśpienie laptopa: zamknięcie pokrywy na macOS/Windows. System pauzuje sieć; po przebudzeniu połączenia często wymagają ponownego ustanowienia.
Zawieszenie karty przeglądarki: nowoczesne przeglądarki zawieszają karty w tle, by oszczędzać pamięć. Uploady w zawieszonej karcie mogą się zatrzymać.
Problemy dostawcy internetu: chwilowe zmiany routingu, wymagany ponowny handshake TLS.
Ponowne łączenie VPN: klienty VPN okresowo renegocjują; połączenie TCP umiera.
Restarty po stronie serwera: usługa transferowa wdraża nową wersję; żądania w locie padają.
Korporacyjne zapory sieciowe: inspekcja ruchu czasami zabija długotrwałe połączenia.

Odporna implementacja wznawiania obsługuje wszystko to tym samym mechanizmem: połącz ponownie, wyślij HEAD do sprawdzenia przesunięcia, wznów od tego miejsca.

Wznawianie pobierania

Żądania HTTP Range (RFC 7233) umożliwiają wznawiane pobieranie. Serwer ogłaszający Accept-Ranges: bytes w nagłówkach odpowiedzi obsługuje żądania zakresu. Klienci mogą wtedy wysyłać Range: bytes=1000000-, aby pobrać tylko bajty od przesunięcia 1 000 000 w górę.

Przeglądarki używają tego automatycznie, gdy klikniesz „Wznów" w menedżerze pobierań. Chrome, Firefox i Safari obsługują wznawianie pobierania z kompatybilnych serwerów. Większość CDN (Cloudflare, Fastly, CloudFront) obsługuje żądania zakresowe.

Narzędzia wiersza poleceń oferują więcej kontroli:

curl -C - -O url wznawia pobieranie od miejsca, gdzie się zatrzymało.
wget -c url robi to samo.
aria2c -c -s 16 url pobiera z 16 równoległymi strumieniami żądań zakresowych dla szybkości.

Usługi obsługujące wznawianie

Nowoczesne usługi transferowe w większości obsługują wznawianie uploadu:

| Usługa | Wznawianie uploadu | Wznawianie pobierania | |---|---|---| | SwissTransfer | Tak (oparte na tus) | Tak (zakresy HTTP) | | HexaTransfer | Tak (fragmentowe + kompatybilne z tus) | Tak | | WeTransfer | Tak (uploady fragmentowe) | Tak | | Dropbox Transfer | Tak | Tak | | Google Drive | Tak (API resumable upload) | Tak | | OneDrive | Tak | Tak | | Box | Tak | Tak |

Plany darmowe czasem wyłączają wznawianie, by zachęcić do płatnych planów, ale w 2026 roku jest to rzadkie. Starsze usługi bez wsparcia wznawiania znikają z list rekomendacji, gdy użytkownicy tracą cierpliwość do awarii.

Co nie wznawia się automatycznie

Zwykłe uploady HTTP POST w prostych aplikacjach nie wznawiają się. Transfery FTP historycznie są niejednorodne — niektórzy klienci i serwery obsługują polecenia REST (restart), inni nie. Załączników e-mail nie da się wznowić — jeśli wysyłka pada przy 90%, zaczynasz od nowa.

Transfery oparte na torrentach z natury się wznawiają, bo protokół torrent śledzi, które kawałki zostały zweryfikowane. To część powodu, dla którego BitTorrent pozostał użyteczny dla bardzo dużych dystrybucji nawet gdy web nadrobił inne metryki.

Wznawianie przy szyfrowaniu end-to-end

Wznawiane uploady połączone z szyfrowaniem po stronie klienta wymagają starannego dzielenia na fragmenty. Plik jest dzielony na fragmenty, każdy z nich szyfrowany AES-256-GCM z unikalnym IV (wektorem inicjalizującym), a następnie wysyłany. Przy wznowieniu klient musi wiedzieć, które fragmenty się zakończyły, i kontynuować od następnego.

Ponieważ każdy fragment jest niezależnie szyfrowany i uwierzytelniony (tryb AEAD GCM), częściowe uploady nie mogą być modyfikowane. Złośliwy serwer wstawiający śmieci przy przesunięciu 5 GB nie przeszedłby weryfikacji, gdy odbiorca odszyfrowuje — niezgodność tagu GCM zostałaby wyłapana.

Implementacje takie jak HexaTransfer używają IV per fragment wyprowadzanych deterministycznie z klucza głównego i indeksu fragmentu, więc wznawianie nie wymaga osobnego przechowywania IV — strona deszyfrująca rekonstruuje je z tej samej derywacji.

Najlepsze praktyki po stronie klienta

Aby zmaksymalizować szanse powodzenia wznawiania:

Utrzymuj kartę aktywną podczas uploadu. Zawieszenie karty przeglądarki przerywa uploady. Ostrzeżenie „nie zamykaj tej karty" to standard w interfejsach usług transferowych.
Podłącz się do sieci przewodowej, gdy to możliwe. Spadki Wi-Fi powodują większość awarii.
Wyłącz oszczędzanie energii i uśpienie podczas długich uploadów. macOS: caffeinate -i. Windows: narzędzie Awake z Powertoys lub zmiany planu zasilania.
Nie przełączaj sieci Wi-Fi w środku uploadu. Połączenie TCP zmienia adres IP i umiera.
Pozwól uploadowi zakończyć się przed zamknięciem pokrywy laptopa. Nowoczesny macOS czasami zachowuje uploady przez krótkie uśpienie, ale nie jest to niezawodne.

Weryfikacja po stronie serwera

Niektóre usługi pokazują niepełne paski postępu nieodzwierciedlające rzeczywistego stanu serwera. Po uploadzie, który przetrwał jedno lub dwa przerwania, odśwież stronę i zweryfikuj, że link działa — otwórz go w trybie incognito i pobierz małą część. Jeśli wznawianie zadziałało, cały plik pobierze się poprawnie.

Dla scenariuszy wymagających pewności oblicz hash SHA-256 po stronie klienta, wyślij plik i zweryfikuj, hashując pobrany plik i porównując. Kryptograficzna kontrola integralności zajmuje około 10 sekund CPU na gigabajt i daje absolutną pewność.

Werdykt

Wznawiane transfery to podstawowa funkcja w 2026 roku — każda usługa bez niej jest natychmiastowym no-go dla plików powyżej kilkuset megabajtów. Szukaj zgodności z tus.io lub równoważnego zachowania uploadu fragmentowego. Sprawdź, czy wybrana usługa gracznie obsługuje przerwania — przetestuj z celowym wyłączeniem sieci na małym pliku przed angażowaniem się w duży transfer.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.