FTP vs transfer webowy: dlaczego przeglądarka wygrywa w 2026

Webowy transfer przeglądarkowy wyparł FTP z niemal każdego nowoczesnego zastosowania. FTP, zdefiniowany w RFC 959 (1985), domyślnie przesyła dane uwierzytelniające i zawartość pliku jako czysty tekst przez TCP port 21. Nowoczesny transfer webowy działa przez HTTPS z TLS 1.3, szyfruje payload po stronie klienta za pomocą AES-256-GCM i nie wymaga od odbiorcy niczego poza przeglądarką. Licznik pobrań FileZilli wciąż rośnie, ale nowe wdrożenia plain FTP w przedsiębiorstwach praktycznie zniknęły. SFTP i FTPS przetrwały w automatyzacji serwer-do-serwera; interaktywne transfery dla ludzi przeniosły się do internetu.

Do czego FTP zostało zaprojektowane

FTP zakładał istnienie zaufanej sieci. Specyfikacja RFC 959 z kwietnia 1985 roku powstała, zanim pojawił się komercyjny internet — NSFNET nie był publiczny do 1988 roku. Port 21 przenosił kanał poleceń, port 20 — dane, a całość płynęła w trybie ASCII lub binarnym bez żadnej ochrony kryptograficznej. Translacja NAT była rozwiązana dopóź, co wymusiło pojawienie się trybu pasywnego dekadę później.

Wiek protokołu widać w jego osobliwościach. Zamieszanie między trybem aktywnym a pasywnym, oddzielne połączenia sterujące i danych, których firewalle nie lubią, login i hasło przesyłane jako czysty tekst, brak natywnej weryfikacji integralności. Jeden wadliwy router może po cichu uszkodzić archiwum .zip podczas transferu bez żadnego komunikatu o błędzie.

Dlaczego plain FTP jest faktycznie wycofany

Przeglądarki stopniowo porzucały obsługę FTP. Chrome usunął ją w wersji 95 (październik 2021). Firefox zrezygnował z niej w wersji 90 (lipiec 2021). Safari nigdy nie obsługiwał FTP interaktywnie. Link w stylu ftp://pliki.example.com/raport.zip nie działa już dla większości użytkowników — musieliby zainstalować FileZillę, Cyberduck lub WinSCP tylko po to, żeby pobrać jeden plik.

Ramy compliance dopełniły dzieła. PCI DSS 4.0, sekcja 4.2.1, wymaga silnej kryptografii dla każdej transmisji danych posiadaczy kart przez sieci publiczne. Zabezpieczenia techniczne HIPAA zgodnie z 45 CFR 164.312(e)(1) wymagają szyfrowanej transmisji danych ePHI. Plain FTP nie spełnia żadnego z tych wymogów. Audytorzy wskazują to natychmiast.

SFTP i FTPS to nie to samo

Są one stale mylone. SFTP (SSH File Transfer Protocol) działa przez SSH na porcie 22, używa uwierzytelniania SSH i nie ma żadnego związku protokołowego z FTP pomimo nazwy. FTPS to FTP opakowane w TLS na porcie 990 (niejawny) lub porcie 21 z AUTH TLS (jawny). To różne protokoły z różnymi trybami awaryjnymi.

SFTP jest lepszym wyborem do zautomatyzowanych transferów serwer-do-serwera — jedno połączenie, działa z firewallami, integruje się z zarządzaniem kluczami SSH, których zespoły używają już do infrastruktury. FTPS dodaje TLS do protokołu wciąż obarczonego dwoma połączeniami i komplikacjami NAT.

Co webowy transfer zastępuje

Nowoczesna usługa transferu webowego obsługuje przypadki użycia, które historycznie należały do FTP:

• Jednorazowe dostarczanie plików klientom (wcześniej: współdzielone konto FTP)
• Przesyłanie plików od dostawców (wcześniej: anonimowy FTP z folderem tylko do zapisu)
• Wymiana dużych plików między firmami partnerskimi (wcześniej: VPN plus FTP)
• Dystrybucja oprogramowania do użytkowników końcowych (wcześniej: publiczne lustro FTP)

Różnica: brak zakładania kont, brak reguł firewalla, brak instalacji oprogramowania klienckiego i szyfrowanie end-to-end domyślnie.

Porównanie architektur

| Wymiar | FTP (plain) | FTPS | SFTP | Transfer webowy | |---|---|---|---|---| | Port(y) | 21, 20 | 990 lub 21 | 22 | 443 | | Szyfrowanie | Brak | TLS | SSH | TLS 1.3 + AES-256-GCM po stronie klienta | | Wymagany klient | FileZilla/WinSCP | FileZilla/WinSCP | OpenSSH/WinSCP | Tylko przeglądarka | | Kompatybilność z firewallami | Słaba (dwa kanały) | Słaba | Dobra | Dobra | | Obsługa wznawiania | Różna | Różna | Tak | Tak (tus/chunked) | | Model uwierzytelniania | Login/hasło | Login/hasło + certyfikat | Klucze SSH | Link + opcjonalne hasło | | Najlepsze zastosowanie w 2026 | Wycofany | Starsze integracje | Automatyzacja serwerów | Udostępnianie plików przez ludzi |

Historia opóźnień, o której większość zapomina

FTP w niektórych klientach otwiera połączenie TCP dla każdego pobieranego pliku. Transfer 10 000 małych plików przez FTP oznacza 10 000 uzgodnień TCP. Dlatego kopia repozytorium .git przez FTP wlecze się, a te same dane przez multipleksowanie HTTP/2 kończą się w ułamku czasu.

HTTPS z HTTP/2 lub HTTP/3 (QUIC) multipleksuje wiele pobrań plików przez jedno połączenie, drastycznie redukując narzut round-trip. Usługi transferu webowego używające protokołów chunked upload, takich jak tus.io, wznawiają transfer dokładnie od miejsca przerwania po zerwaniu połączenia — coś, czego plain FTP obsługuje niespójnie między serwerami.

Gdzie FTP uparcie przeżywa

Systemy automatyzacji broadcastu wciąż przesyłają treści do stacji afiliowanych przez FTP, ponieważ urządzenia playout od producentów takich jak Grass Valley czy Ross Video były projektowane w epoce FTP. Starsze systemy retail-owe przesyłają nocne zrzuty .csv zapasów do centrali przez FTPS. Instytucje akademickie prowadzą anonimowe lustra FTP dla archiwów oprogramowania (choć większość migrowała do odpowiedników opartych na HTTPS).

Automatyzacja serwer-do-serwera korzysta konkretnie z SFTP. Zaplanowane zadanie zrzucające nocne kopie zapasowe do zabezpieczonego SFTP z uwierzytelnianiem kluczami SSH to wciąż dobra architektura w 2026 roku. Umiera FTP obsługiwany przez człowieka.

Kiedy transfer webowy wyraźnie wygrywa

Zawsze, gdy odbiorcą jest osoba niezdolna technicznie. Klienci nie zainstalują FileZilli. Zewnętrzni audytorzy nie skonfigurują ustawień FTPS. Regulatorzy chcą potwierdzeń i dostarczania opartego na linku. Dla agencji PR wysyłającej press kity, kancelarii wymieniającej materiały discovery lub studia projektowego przesyłającego pliki .psd klientowi — link w przeglądarce jest jedyną metodą dostarczenia, która działa bez zgłoszenia do działu IT.

HexaTransfer reprezentuje tę zmianę — wgraj plik do 10 GB, udostępnij link, odbiorca pobiera przez przeglądarkę. Bez danych uwierzytelniających FTP do zakładania i odwoływania.

Profil bezpieczeństwa

Plain FTP ujawnia dane uwierzytelniające każdemu obserwatorowi sieci — lotniskowe Wi-Fi, hotele, wspólna infrastruktura biurowa. FTPS i SFTP naprawiają transport, ale nadal dają operatorowi serwera dostęp do treści pliku po odszyfrowaniu po stronie serwera.

Usługa transferu webowego z szyfrowaniem zero-knowledge szyfruje po stronie klienta, zanim plik opuści przeglądarkę. Serwer przechowuje wyłącznie zaszyfrowany tekst. Nawet pełne naruszenie serwera nie ujawnia nic przydatnego bez kluczy per plik przechowywanych w fragmentach URL. To materialne zabezpieczenie przekraczające to, co może zaoferować FTPS.

Ścieżka migracji

Jeśli wciąż używasz FTP do zewnętrznego dostarczania plików, migracja jest zazwyczaj prosta. Zidentyfikuj przepływy pracy (dostarczanie klientom, przyjmowanie od dostawców, wymiana z partnerami), wybierz usługę transferu webowego odpowiadającą profilowi rozmiaru i zgodności, a następnie wycofaj serwer FTP gdy ruch wyschnie. Zautomatyzowane zadania serwerowe przejdą do SFTP z uwierzytelnianiem kluczami SSH — to przeżyje tę transformację.

Ocena końcowa

FTP miało 40-letni okres świetności. Przegrało, ponieważ stos protokołów webowych rozwiązał każdy problem, który FTP rozwiązywało, a następnie dodał szyfrowanie, przyjazność dla firewalli i powszechną obsługę klienta przez przeglądarki dostępne na każdym urządzeniu. Do nowego interaktywnego udostępniania plików — sieć. Do automatycznych potoków serwerowych — SFTP. Plain FTP odkładamy na półkę obok faksu.

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