Techniki równoległego uploadu: maksymalizacja przepustowości

Równoległe uploady dzielą plik na fragmenty (zwykle 5–100 MB każdy) i wypychają je przez wiele równoczesnych połączeń TCP, omijając pułap przepustowości, jaki pojedynczy strumień osiąga na łączach o dużym opóźnieniu. Amazon S3 multipart upload, Google Cloud Storage resumable uploads oraz tus.io — wszystkie to implementują. Na łączu 1 Gbps z 80 ms opóźnienia do serwera docelowego pojedynczy HTTP PUT zwykle wysyca się przy 150 Mbps, podczas gdy 8 równoległych strumieni przekracza 900 Mbps. Zysk jest realny i przewidywalny, gdy zrozumiesz dlaczego.

Dlaczego jeden strumień nie wystarcza

Kontrola przeciążenia TCP używa przesuwnego okna do decydowania, ile niepotwierdzonych danych trzymać w locie. Na szybkim łączu z dużym opóźnieniem domyślny rozmiar okna (około 16 MB na Linux 5.x, mniej na starszych jądrach) zapełnia się, zanim wrócą ACK, a nadawca siedzi bezczynnie czekając. To problem „iloczynu przepustowości i opóźnienia" — właśnie dlatego pojedynczy transfer FTP do serwera w Singapurze z Paryża osiąga limit około 30 Mbps nawet na łączu gigabitowym.

Uruchomienie wielu równoległych połączeń omija problem, bo każde połączenie dostaje własne okno. Osiem strumieni po 30 Mbps sumuje się do 240 Mbps — a to przed uwzględnieniem wyboru węzła CDN, który często kieruje różne połączenia przez różne punkty wejścia.

Rozmiar i liczba fragmentów

Złoty środek zależy od opóźnienia i utraty pakietów. Dla transferów w obrębie tego samego kontynentu poniżej 50 ms RTT, fragmenty 10 MB z 4 równoległymi workerami wysycają większość konsumenckich łączy. Dla łączy międzykontynentalnych lub stratnych mobilnych (ponad 100 ms RTT, ponad 0,5% utraty pakietów) lepiej zejść do fragmentów 5 MB z 8–16 workerami.

API multipart S3 wymaga minimum 5 MB na część (z wyjątkiem ostatniej), maksimum 5 GB na część i do 10 000 części na upload. To stawia teoretyczny pułap około 48,8 TB na obiekt. Google Cloud Storage pozwala na 32 części na composite i obsługuje resumable session URIs trwające do jednego tygodnia. Azure Blob block blobs akceptują do 50 000 bloków po 4000 MiB każdy.

Dla transferów w przeglądarce fragmenty powyżej 100 MB zaczynają obciążać RAM w kartach, więc większość UI webowych pozostaje w przedziale 5–20 MB.

Jak robią to nowoczesne usługi transferowe

Webowy uploader WeTransfer dzieli pliki na fragmenty 6 MB i uruchamia 3–5 równoległych żądań XHR. Smash fragmentuje bardziej agresywnie, z fragmentami 4 MB przez do 8 workerów. SwissTransfer używa fragmentów 50 MB z 4 równoległymi strumieniami, co sprzyja przepustowości na szwajcarskich łączach światłowodowych, ale gorzej działa na niestabilnych łączach — jeden nieudany fragment oznacza retransmisję 50 MB. Dropbox Transfer polega na swoim API fragmentowego uploadu z fragmentami 8 MB.

Różnice widać w testach praktycznych: plik 5 GB na uploadzie 500 Mbps do WeTransfer kończy się w około 95 sekund; SwissTransfer przy podobnej przepustowości działa około 105 sekund z powodu okazjonalnego narzutu ponownych prób.

Wznawiane uploady: cicha supermoc

Fragmentowe uploady odblokowują wznawianie. Jeśli Wi-Fi spadnie przy fragmencie 47 ze 120, nie zaczynasz od zera — wznawiasz od fragmentu 48. Protokół tus.io (otwarty standard w wersji 2.0) formalizuje to żądaniami HEAD do odpytania przesunięcia uploadu i żądaniami PATCH do dołączania, używając nagłówków Upload-Offset i Upload-Length.

API resumable upload Google Drive używa session URIs trwających 7 dni. Możesz zawiesić laptopa, zrestartować, ponownie otworzyć kartę i podjąć upload dokładnie tam, gdzie skończyłeś. To różnica między użytecznym transferem 10 GB a rzutem monetą.

Szyfrowanie po stronie klienta zmienia matematykę

Usługi z szyfrowaniem end-to-end muszą zaszyfrować każdy fragment po stronie klienta przed wysłaniem. AES-256-GCM z prędkością 500 MB/s na nowoczesnym procesorze nie jest wąskim gardłem, ale kolejność ma znaczenie: zaszyfruj fragment, wyślij fragment, zaszyfruj następny. Pipelining z pulą workerów ma tu kluczowe znaczenie. Naiwne implementacje szeregują szyfrowanie i upload, tnąc efektywną przepustowość o połowę. Poprawne implementacje trzymają 2–4 workerów szyfrowania karmiących 4–8 workerów uploadu przez ograniczoną kolejkę.

Dlatego HexaTransfer uruchamia szyfrowanie AES-256-GCM w Web Workers obok równoległej puli XHR, by pułap 10 GB był faktycznie osiągalny w przeglądarce bez zatykania się na kryptografii.

Backpressure i limity po stronie serwera

Więcej równoległości nie zawsze oznacza szybciej. Jeśli odbierająca usługa ogranicza ruch per IP (częste w CloudFront z limitem 25 000 żądań na sekundę na dystrybucję), wypychanie 32 równoczesnych fragmentów może wywołać odpowiedzi 503 Slow Down. HTTP/2 pomaga, bo multipleksuje po pojedynczym połączeniu TCP, ale wiele CDN nadal kończy HTTP/2 na krawędzi i rozdziela HTTP/1.1 do origin — efektywna równoległość zależy od konfiguracji krawędzi.

Testuj przed nadmierną równoleglizacją. 8 workerów jest niemal zawsze bezpieczne; 16 to górna granica akceptowana przez magazyny obiektów; 32 zaczyna produkować ponowne próby kosztujące więcej niż oszczędzają.

Limity przeglądarek, o których warto wiedzieć

Chrome i Firefox ograniczają równoczesne połączenia per origin do 6 przez HTTP/1.1 i efektywnie bez limitu przez HTTP/2. Jeśli usługa transferowa działa na HTTP/1.1, pułap równoległości to 6 niezależnie od liczby uruchomionych workerów. Sprawdź w DevTools: kolumna „Waterfall" w panelu Network pokazuje kolejkujące się żądania.

Safari na iOS 17 i nowszych czysto obsługuje 6 równoległych XHR, ale zaczyna zwalniać karty w tle przy około 1,5 GB nacisku RAM, co ma znaczenie dla buforów uploadów fragmentowych.

Kiedy równoległe uploady nie pomagają

Na asymetrycznych łączach domowych (typowo: 1 Gbps w dół, 40 Mbps w górę) upload jest wąskim gardłem, a nie ingest serwera. Wypychanie 8 równoległych strumieni po 5 MB przez łącze 40 Mbps nie idzie szybciej niż 1 strumień przy 40 Mbps. Równoległość pomaga, gdy pułap pojedynczego strumienia jest poniżej pojemności łącza — nie gdy łącze jest już wysycone.

Ta sama zasada obowiązuje na komórkowym: przy jednym pasku LTE dodatkowi workerzy głównie produkują retransmisje.

Czego szukać w usłudze transferowej

Wybierając narzędzie do częstych dużych transferów, sprawdź trzy rzeczy: czy obsługuje wznawiane uploady fragmentowe, ilu równoległych workerów uruchamia webowe UI i czy używa HTTP/2 lub HTTP/3 do węzła brzegowego. Usługi spełniające wszystkie trzy warunki przeniosą plik 10 GB w minutach na przyzwoitym łączu.

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