Porównanie HTTP i FTP do przesyłania plików


125

Jakie są zalety (lub ograniczenia) jednego w stosunku do drugiego w przypadku przesyłania plików przez Internet?

(Znam bezpieczne formy obu protokołów. Chciałbym usłyszeć porównania na podstawie osobistych doświadczeń pod względem wydajności, niezawodności, ograniczeń rozmiaru plików itp.)

Odpowiedzi:


99

Oto porównanie wydajności tych dwóch. Protokół HTTP jest bardziej responsywny w przypadku żądania odpowiedzi małych plików, ale protokół FTP może być lepszy w przypadku dużych plików, jeśli jest odpowiednio dostrojony. FTP był powszechnie uważany za szybszy. Protokół FTP wymaga utrzymania kanału sterującego i stanu poza stanem TCP, ale protokół HTTP tego nie robi. Przed rozpoczęciem przesyłania danych przez FTP jest 6 transferów pakietów, ale tylko 4 w HTTP.

Myślę, że odpowiednio dostrojona warstwa TCP miałaby większy wpływ na szybkość niż różnica między protokołami warstwy aplikacji. Szczegóły w Sun Blueprint Understanding Tuning TCP .

Oto kolejne dobre porównanie indywidualnych cech każdego protokołu.


22
+1 dobra odpowiedź. Myślę, że dzień FTP minął i minął, nie ma już znaczenia. To także absolutna świnia do wdrożenia.
skaffman

7
Jaki rozmiar należy rozumieć przez „małe” lub „duże” pliki?
Urbycoz,

Do porównania wydajność dowiązanie do analizy oczekiwanych korzyści z wdrożenia P-HTTP, T / TCP, oraz S-TCB. Nigdzie nie wspomina o FTP. Ponadto prawidłowo dostrojony link jest uszkodzony.
Trisped

@Trisped czy przeczytałeś link do porównania wydajności? Istnieje 12 odniesień do FTP, a pierwsza sekcja mówi: „Protokół HTTP został pierwotnie opracowany w celu zmniejszenia nieefektywności FTP…”, a następnie wyjaśnia. Zaktualizowałem również łącze „Understanding Tuning TCP” ... wygląda na to, że Oracle wyrzuciło wszystkie stare oficjalne dokumenty Sun Blueprints.
John Ellinwood

2
16 sierpnia 1996 ... naprawdę? Nawet w odpowiedzi z 2009 roku nie można było oczekiwać, że będzie to reprezentatywne dla obecnego stanu rzeczy. -1
użytkownik541686

29

Właśnie przetestowałem transfer plików przez FTP i HTTP:

  • ponad dwa bardzo dobre połączenia z serwerem
  • używając tego samego pliku ZIP o pojemności 1 GB
  • w tych samych warunkach sieciowych (testowane jeden po drugim)

Wynik:

  • przy użyciu FTP: 6 minut
  • przy użyciu protokołu HTTP: 4 minuty
  • przy użyciu równoległego programu do pobierania plików http ( fdm): 1 minuta

Tak więc w zasadzie w sytuacji „prawdziwego życia”:

1) HTTP jest szybsze niż FTP podczas pobierania jednego dużego pliku.

2) HTTP może używać równoległego pobierania porcji, co czyni je 6x razy szybszym niż FTP, w zależności od warunków sieciowych.


18
Wydaje się to bardzo anegdotyczne.
spenibus

5
@anecdotal podał liczby (fakty z badań), które są mniej anegdotyczne niż jakakolwiek inna dotychczasowa odpowiedź.
user1133275

Czy czasy są powtarzalne, przynajmniej w przybliżeniu?
masterxilo

kilka dni temu próbowałem pobrać pliki 90 MB za pomocą protokołu http, sieć nie powiodła się przy 2 MB. Ale z ftp (ten sam serwer, ten sam plik, ta sama sieć przez mobilny hotspot), pobieranie zakończyło się sukcesem. Nie wiem dlaczego.
Rahmat Ihsan

1
ftp jest szybszy dla pojedynczych plików ze względu na mniejsze obciążenie. Jeśli twoje testy dały inną odpowiedź, wypróbuj innego klienta (lub, co mniej prawdopodobne, inny serwer). http nie może pobierać szybciej niż maksymalna przepływność, a każda opcja równoległa używana do próby przekroczenia spowoduje wprowadzenie narzutu protokołu. Vs. Wiele plików można przesyłać z powrotem do tyłu z prędkością linii przez FTP bez narzutu protokołu. Opcja równoległa FTP wykorzystuje wiele połączeń TCP, które zwykle przewyższają połączenia jednopunktowe (np. SMB3.1 vSMB2.1, 3.x może korzystać z wielu połączeń).
Astara

27

Wiele zapór ogniowych przerywa połączenia wychodzące, które nie są kierowane do portów 80 lub 443 (http & https); niektórzy nawet porzucają połączenia do tych portów, które nie są HTTP (S). FTP może być dozwolone lub nie, nie mówiąc o trybach aktywnych / PASV.

Ponadto protokół HTTP / 1.1 umożliwia znacznie lepsze żądania częściowe („wysyłaj tylko z bajtu 123456 do końca pliku”), żądania warunkowe i buforowanie („wysyłaj tylko w przypadku zmiany treści / zmiany daty ostatniej modyfikacji”) oraz kompresję treści (gzip).

Protokół HTTP jest znacznie łatwiejszy w użyciu za pośrednictwem serwera proxy.

Z moich anegdot wynika, że ​​HTTP jest łatwiejsze do pracy z porzuconymi / wolnymi / niestabilnymi połączeniami; np. nie jest konieczne (ponowne) ustanawianie sesji logowania przed (ponownym) zainicjowaniem transferu.

OTOH, HTTP jest bezstanowe, więc trzeba by było przeprowadzić uwierzytelnianie i zbudować ścieżkę „kto co robił kiedy”.

Jedyną różnicą w szybkości, jaką zauważyłem, jest przesyłanie wielu małych plików: HTTP z potokowaniem jest szybsze (zmniejsza liczbę obiegów, szczególnie zauważalne w sieciach o dużym opóźnieniu).

Zwróć uwagę, że HTTP / 2 oferuje jeszcze więcej optymalizacji, podczas gdy protokół FTP nie widział żadnych aktualizacji od dziesięcioleci (a nawet rozszerzenia FTP są nieznacznie przyjmowane przez użytkowników). Tak więc, chyba że przesyłasz pliki przez maszynę czasu, wygrywa HTTP.

(Stycznie: istnieją protokoły, które lepiej nadają się do przesyłania plików, takie jak rsynclub BitTorrent, ale te nie wymagają tak dużej wymiany myśli, podczas gdy HTTP jest Everywhere ™)


13

Jedną z kwestii jest to, że FTP może używać niestandardowych portów, co może utrudniać przechodzenie przez zapory ogniowe (szczególnie jeśli używasz SSL). Protokół HTTP zwykle znajduje się na znanym porcie, więc rzadko stanowi to problem.

Jeśli zdecydujesz się na korzystanie z FTP, przeczytaj o aktywnym i pasywnym FTP .

Jeśli chodzi o wydajność, na koniec dnia oba wyrzucają pliki bezpośrednio do połączeń TCP, więc powinno być mniej więcej tak samo.


-5

Oba używają TCP jako protokołu transportowego, ale HTTP używa trwałego połączenia, co poprawia wydajność TCP.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.