Czym różnią się te dwie usługi? Pozornie, niczym. I jedno i drugie to protokół i usługa do przesyłania danych. Tylko jedna jest zorientowana na pliki, i systemy uniksowe a druga nie.
W tamtych czasach, żeby ściągnąć plik ze zdalnego archiwum (najczęściej program, albo dokument tekstowy) używało się protokołu FTP i programu (polecenia linii poleceń) o tej samej nazwie.
ftp sunsite.icm.edu.pl
[ tu zdalny serwer wypisywał informacje lokalne,
tak zwaną wiadomość dnia (message of the day),
po czym następowało pytanie o login i hasło ]
login: anonymous
password: <jakiekolwiek> [zwyczajowo to powinien być adres e-mail]
[tu znowu jakieś informacje, po czym w końcu dostajemy znak
zachęty do wpisywania poleceń]
>Zdalna linię poleceń była podobna do unksowej ale ograniczona do kilku komend, można było chodzić po podkatalogach poleceniem cd, listować je za pomocą ls łącznie ze stosowaniem znaków specjalnych typu *, no i pobierać pliki poleceniem get <nazwa pliku>. Ale tylko po jednym, jak się chciało pobrać więcej niż jeden plik to trzeba było użyć polecenia mget <nazwa>* z wykorzystaniem wzorców powłoki. Konwencja mówiła, że pliki i katalogi z plikami do ściągania są w katalogu /pub a jeśli serwer pozwala zostawiać swoje pliki to należy to robić w katalogu /incoming skąd właściciel serwera przeniesie je we właściwe miejsce po sprawdzeniu.
Do tego protokół FTP miał osobne tryby do przesyłania plików tekstowych i binarnych, oraz używał dwóch połączeń sieciowych i czasem nie działał bez ręcznego przestawienia w tryb pasywny. I protokół i program był narzędziem przeznaczonym dla człowieka. Tryb do plików tekstowych zapewniał konwersję między systemami IBM (kodowanie EBCDIC) a uniksowymi (kodowanie ASCII) i mógł psuć polskie znaki — transmisja mogła być tylko siedmiobitowa. Pliki z polskimi znakami należało przesyłać w trybie binarnym.
Z kolei współczesny protokół HTTP robi w zasadzie to samo, ale używając klienta (i serwera) samego protokołu możemy tylko zasoby pobierać, nie da się ich znaleźć bo trzeba znać ścieżkę no a udostępnienie opcji wysyłania danych na serwer wymaga dostawienia tam całej aplikacji obsługującej takie żądania. Za to zazwyczaj nie trzeba się logować w żaden sposób. HTTP jest protokołem technicznym przeznaczonym do użycia przez inne programy (przy ładowaniu jednej strony WWW przeglądarka może wykonać parędziesiąt albo i paręset żądań HTTP) i to głównie do pobierania danych do użytkownika. Są programy (np lftp) które pozwalają w ten sam sposób korzystać z FTP i HTTP i radzą sobie z brakami tego czego HTTP nie udostępnia, no ale same z siebie wysyłania plików na serwer nie zrobią.
Może gdyby HTTP udostępniało możliwość łatwego wysyłania, a nie tylko ściągania, nie istniałby dziś wielki przemysł serwisów do dzielenia się plikami, bo ostatnią niszą gdzie FTP jeszcze się trzyma to tam gdzie trzeba prywatnie udostępniać wielkie pliki, których nie da się puścić w załączniku do emaila.