Protokół Przesyłania Plików - File Transfer Protocol

Z Wikipedii, wolnej encyklopedii

Protokół Przesyłania Plików
Protokół komunikacyjny
Cel, powód Transfer plików
Deweloper (y) Abhay Bhushan dla RFC 959
Wprowadzono 16 kwietnia 1971 ; 50 lat temu  ( 16.04.1971 )
Warstwa OSI Warstwa aplikacji
Porty 21 do sterowania, 20 do przesyłania danych
RFC (y) RFC 959

File Transfer Protocol ( FTP ) to standardowy protokół komunikacyjny wykorzystywany do transferu plików komputerowych z serwera do klienta na sieci komputerowej . FTP jest zbudowany na architekturze klient-serwer z wykorzystaniem oddzielnych połączeń sterowania i danych między klientem a serwerem. Użytkownicy FTP mogą uwierzytelniać się za pomocą protokołu logowania zwykłego tekstu , zwykle w postaci nazwy użytkownika i hasła, ale mogą łączyć się anonimowo, jeśli serwer jest skonfigurowany tak, aby na to zezwalać. Do bezpiecznej transmisji, który chroni użytkownika i hasło, a następnie szyfruje zawartość, FTP jest często zabezpieczone z SSL / TLS ( FTPS ) lub zastąpione Transferu SSH File Transfer Protocol (SFTP).

Pierwsze aplikacje klienckie FTP były programami wiersza poleceń opracowanymi zanim systemy operacyjne miały graficzny interfejs użytkownika i nadal są dostarczane z większością systemów operacyjnych Windows , Unix i Linux . Od tego czasu opracowano wiele klientów FTP i narzędzi do automatyzacji dla komputerów stacjonarnych , serwerów, urządzeń mobilnych i sprzętu, a protokół FTP został włączony do aplikacji zwiększających wydajność, takich jak edytory HTML .

W styczniu 2021 r. Obsługa protokołu FTP została wyłączona w Google Chrome (od wersji 88), a także w innych głównych przeglądarkach, takich jak Firefox (od wersji 88.0).

Historia serwerów FTP

Oryginalna specyfikacja protokołu przesyłania plików została napisana przez Abhaya Bhushana i opublikowana jako RFC   114 w dniu 16 kwietnia 1971 r. Do 1980 r. FTP działał na NCP , poprzedniku TCP / IP . Protokół został później zastąpiony wersją TCP / IP, RFC   765 (czerwiec 1980) i RFC   959 (październik 1985), aktualną specyfikacją. Kilka proponowanych standardów zmienia RFC   959 , na przykład RFC   1579 (luty 1994) włącza protokół FTP przyjazny dla zapory (tryb pasywny), RFC   2228 (czerwiec 1997) proponuje rozszerzenia bezpieczeństwa, RFC   2428 (wrzesień 1998) dodaje obsługę IPv6 i definiuje nowy typ trybu pasywnego.

Przegląd protokołów

Komunikacja i transfer danych

Ilustracja rozpoczynania pasywnego połączenia przy użyciu portu 21

FTP może działać w trybie aktywnym lub pasywnym , który określa sposób nawiązywania połączenia danych. (To znaczenie „trybu” różni się od znaczenia polecenia MODE w protokole FTP i odpowiada zamiast tego poleceniom PORT / PASV / EPSV / itp.) W obu przypadkach klient tworzy połączenie sterujące TCP z losowego, zwykle nieuprzywilejowanych , portem N z portem poleceń serwera FTP 21.

  • W trybie aktywnym klient rozpoczyna nasłuchiwanie nadchodzących połączeń danych z serwera na porcie M. Wysyła polecenie FTP PORT M, aby poinformować serwer, na którym porcie nasłuchuje. Następnie serwer inicjuje kanał danych do klienta ze swojego portu 20, portu danych serwera FTP.
  • W sytuacjach, gdy klient znajduje się za firewallem i nie może przyjąć przychodzących połączeń TCP, można użyć trybu pasywnego . W tym trybie klient używa połączenia sterującego, aby wysłać polecenie PASV do serwera, a następnie otrzymuje adres IP serwera i numer portu serwera z serwera, których klient następnie używa do otwarcia połączenia danych z dowolnego portu klienta do otrzymano adres IP serwera i numer portu serwera.

Oba tryby zostały zaktualizowane we wrześniu 1998 r., Aby obsługiwały IPv6 . W tym czasie wprowadzono dalsze zmiany w trybie pasywnym, aktualizując go do rozszerzonego trybu pasywnego .

Serwer odpowiada przez połączenie sterujące trzycyfrowymi kodami stanu w ASCII z opcjonalną wiadomością tekstową. Na przykład „200” (lub „200 OK”) oznacza, że ​​ostatnie polecenie powiodło się. Liczby reprezentują kod odpowiedzi, a opcjonalny tekst przedstawia zrozumiałe dla człowieka wyjaśnienie lub prośbę (np. <Potrzebujesz konta do przechowywania pliku>). Trwający transfer danych pliku przez połączenie danych można przerwać za pomocą komunikatu przerwania wysłanego przez połączenie sterujące.

Protokół FTP wymaga dwóch portów (jednego do wysyłania i jednego do odbierania), ponieważ został pierwotnie zaprojektowany do działania w programie kontroli sieci (NCP), który był protokołem simplex, który wykorzystywał dwa adresy portów , ustanawiając dwa połączenia, do komunikacji dwukierunkowej. Dla każdej aplikacji lub protokołu warstwy aplikacji zarezerwowano nieparzysty i parzysty port . Standaryzacja protokołów TCP i UDP ograniczyła potrzebę stosowania dwóch portów simplex dla każdej aplikacji do jednego portu dupleksowego, ale protokół FTP nigdy nie został zmieniony tak, aby używał tylko jednego portu i nadal korzystał z dwóch w celu zapewnienia zgodności wstecznej.

Przechodzenie przez NAT i firewall

FTP zwykle przesyła dane poprzez ponowne połączenie serwera z klientem po wysłaniu przez klienta polecenia PORT. Jest to problematyczne zarówno w przypadku NAT, jak i zapór ogniowych, które nie pozwalają na połączenia z Internetu do hostów wewnętrznych. W przypadku NAT dodatkową komplikacją jest to, że reprezentacja adresów IP i numeru portu w poleceniu PORT odnosi się do adresu IP i portu wewnętrznego hosta, a nie do publicznego adresu IP i portu NAT.

Istnieją dwa podejścia do rozwiązania tego problemu. Jednym z nich jest to, że klient FTP i serwer FTP używają polecenia PASV, które powoduje ustanowienie połączenia danych z klienta FTP do serwera. Jest to szeroko stosowane przez współczesnych klientów FTP. Innym podejściem jest to, że NAT zmienia wartości polecenia PORT, używając do tego celu bramy na poziomie aplikacji .

Typy danych

Podczas przesyłania danych przez sieć zdefiniowane są cztery typy danych:

  • ASCII (TYPE A): Używany w przypadku tekstu. W razie potrzeby dane są konwertowane z reprezentacji znakowej hosta wysyłającego do „8-bitowego ASCII” przed transmisją i (ponownie, jeśli to konieczne) do reprezentacji znakowej hosta odbierającego. W konsekwencji ten tryb jest nieodpowiedni dla plików zawierających dane inne niż zwykły tekst.
  • Obraz (TYP I, powszechnie nazywany trybem binarnym ): Maszyna wysyłająca wysyła każdy plik bajt po bajcie, a odbiorca zapisuje strumień bajtowy w momencie jego otrzymania. (Obsługa trybu obrazu jest zalecana dla wszystkich implementacji protokołu FTP).
  • EBCDIC (TYPE E): Używany do zwykłego tekstu między hostami przy użyciu zestawu znaków EBCDIC.
  • Lokalny (TYPE L n ): Zaprojektowany do obsługi przesyłania plików między maszynami, które nie używają 8-bitowych bajtów, np. Systemy 36-bitowe, takie jak DEC PDP-10 . Na przykład „TYPE L 9” będzie używany do przesyłania danych w 9-bitowych bajtach lub „TYPE L 36” do przesyłania słów 36-bitowych. Większość współczesnych klientów / serwerów FTP obsługuje tylko L 8, co jest odpowiednikiem I.

Wygasła wersja robocza Internetu zdefiniowała TYPE U do przesyłania plików tekstowych Unicode przy użyciu UTF-8 ; chociaż wersja robocza nigdy nie stała się RFC, została zaimplementowana przez kilku klientów / serwery FTP.

Należy zauważyć, że te typy danych są powszechnie nazywane „trybami”, chociaż niejednoznacznie słowo to jest również używane w odniesieniu do trybu komunikacji aktywny kontra pasywny (patrz powyżej) oraz trybów ustawianych przez polecenie MODE protokołu FTP (patrz poniżej).

W przypadku plików tekstowych (TYPE A i TYPE E) dostępne są trzy różne opcje sterowania formatem, które pozwalają kontrolować sposób drukowania pliku:

  • Niedrukowalne (TYPE AN i TYPE EN) - plik nie zawiera żadnych znaków sterujących karetką przeznaczonych dla drukarki
  • Telnet (TYPE AT i TYPE ET) - plik zawiera znaki sterujące karetką Telnet (czyli innymi słowy ASCII C0) (CR, LF itp.)
  • ASA (TYPE AA i TYPE EA) - plik zawiera znaki sterujące karetki ASA

Te formaty dotyczyły głównie drukarek liniowych ; większość współczesnych klientów / serwerów FTP obsługuje tylko domyślną kontrolę formatu N.

Struktury plików

Organizację plików określa się za pomocą polecenia STRU. Następujące struktury plików są zdefiniowane w sekcji 3.1.1 dokumentu RFC959:

  • Struktura F lub FILE (zorientowana strumieniowo). Pliki są postrzegane jako dowolna sekwencja bajtów, znaków lub słów. Jest to typowa struktura plików w systemach Unix i innych systemach, takich jak CP / M, MSDOS i Microsoft Windows. (Sekcja 3.1.1.1)
  • Struktura R lub RECORD (zorientowana na rekord). Pliki są wyświetlane jako podzielone na rekordy, które mogą mieć stałą lub zmienną długość. Taka organizacja plików jest powszechna w systemach mainframe i midrange, takich jak MVS, VM / CMS, OS / 400 i VMS, które obsługują systemy plików zorientowane na rekordy .
  • Struktura P lub PAGE (zorientowana na stronę). Pliki są podzielone na strony, które mogą zawierać dane lub metadane; każda strona może mieć również nagłówek z różnymi atrybutami. Ta struktura plików została specjalnie zaprojektowana dla systemów TENEX i generalnie nie jest obsługiwana na innych platformach. RFC1123 sekcja 4.1.2.3 zaleca, aby ta struktura nie była implementowana.

Większość współczesnych klientów i serwerów FTP obsługuje tylko STRU F. STRU R jest nadal używany w aplikacjach do przesyłania plików na komputerach mainframe i minikomputerach.

Tryby przesyłania danych

Przesyłanie danych może odbywać się w jednym z trzech trybów:

  • Tryb strumieniowy (TRYB S): Dane są przesyłane jako ciągły strumień, co uwalnia FTP od wykonywania jakiegokolwiek przetwarzania. Raczej całe przetwarzanie jest pozostawione TCP . Żaden wskaźnik końca pliku nie jest potrzebny, chyba że dane są podzielone na rekordy .
  • Tryb blokowy (TRYB B): Przeznaczony głównie do przesyłania plików zorientowanych na nagrania (STRU R), chociaż może być również używany do przesyłania plików tekstowych zorientowanych strumieniowo (STRU F). FTP umieszcza każdy rekord (lub wiersz) danych w kilku blokach (nagłówek bloku, liczba bajtów i pole danych), a następnie przekazuje je do protokołu TCP.
  • Tryb skompresowany (TRYB C): rozszerza TRYB B o kompresję danych przy użyciu kodowania długości przebiegu .

Większość współczesnych klientów i serwerów FTP nie obsługuje TRYBU B ani TRYBU C; Wyjątkiem są klienci i serwery FTP dla systemów operacyjnych mainframe i minikomputerów.

Niektóre programy FTP implementują również tryb skompresowany oparty na DEFLATE , czasami nazywany „trybem Z” po poleceniu, które go włącza. Ten tryb został opisany w wersji roboczej w Internecie , ale nie został znormalizowany.

GridFTP definiuje dodatkowe tryby, TRYB E i TRYB X, jako rozszerzenia TRYBU B.

Dodatkowe polecenia

Nowsze implementacje protokołu FTP obsługują polecenie Modify Fact: Modification Time (MFMT), które umożliwia klientowi zdalne dostosowanie tego atrybutu pliku , umożliwiając zachowanie tego atrybutu podczas przesyłania plików.

Aby pobrać znacznik czasu zdalnego pliku, istnieje polecenie MDTM . Niektóre serwery (i klienci) obsługują niestandardową składnię polecenia MDTM z dwoma argumentami, która działa tak samo jak MFMT

Zaloguj sie

Logowanie FTP wykorzystuje normalną nazwę użytkownika i schemat hasła do przyznania dostępu. Nazwa użytkownika jest wysyłana do serwera za pomocą polecenia USER, a hasło jest wysyłane za pomocą polecenia PASS. Ta sekwencja jest nieszyfrowana „w sieci”, więc może być podatna na atak podsłuchiwania sieci . Jeżeli podane przez klienta informacje zostaną zaakceptowane przez serwer, serwer wyśle ​​do klienta pozdrowienie i rozpocznie się sesja. Jeśli serwer to obsługuje, użytkownicy mogą logować się bez podawania danych logowania, ale ten sam serwer może autoryzować tylko ograniczony dostęp dla takich sesji.

Anonimowy FTP

Host udostępniający usługę FTP może zapewniać anonimowy dostęp do FTP. Użytkownicy zwykle logują się do usługi za pomocą konta „anonimowego” (na niektórych serwerach FTP rozróżniana jest wielkość liter i małe litery) po wyświetleniu monitu o nazwę użytkownika. Chociaż użytkownicy są często proszeni o wysłanie swojego adresu e - mail zamiast hasła, w rzeczywistości nie przeprowadza się weryfikacji dostarczonych danych. Wiele hostów FTP, których celem jest dostarczanie aktualizacji oprogramowania, umożliwia anonimowe logowanie.

Różnice w stosunku do protokołu HTTP

Protokół HTTP zasadniczo naprawia błędy w FTP, które sprawiały, że korzystanie z niego było niewygodne w przypadku wielu małych transferów efemerycznych, co jest typowe dla stron internetowych.

FTP ma połączenie kontrolne stanowe, które utrzymuje bieżący katalog roboczy i inne flagi, a każdy transfer wymaga dodatkowego połączenia, przez które przesyłane są dane. W trybie „pasywnym” to drugie połączenie jest od klienta do serwera, podczas gdy w domyślnym trybie „aktywnym” jest to połączenie od serwera do klienta. To pozorne odwrócenie ról w trybie aktywnym i losowe numery portów dla wszystkich transferów są powodem, dla którego zapory ogniowe i bramy NAT mają takie trudności z FTP. Protokół HTTP jest bezstanowy i umożliwia sterowanie multipleksami i przesyłanie danych w ramach pojedynczego połączenia od klienta do serwera na dobrze znanych numerach portów, które w trywialny sposób przechodzi przez bramy NAT i jest łatwe w zarządzaniu przez zapory ogniowe.

Konfigurowanie połączenia sterującego FTP jest dość powolne z powodu opóźnień w obie strony wysyłania wszystkich wymaganych poleceń i oczekiwania na odpowiedzi, dlatego zwyczajowo jest wywoływać połączenie sterujące i utrzymywać je otwarte dla wielu transferów plików, a nie upuszczać i ponownie -Ustanów sesję od nowa za każdym razem. W przeciwieństwie do tego HTTP pierwotnie przerywał połączenie po każdym transferze, ponieważ było to tak tanie. Chociaż protokół HTTP uzyskał później możliwość ponownego wykorzystania połączenia TCP do wielu transferów, model koncepcyjny nadal opiera się na niezależnych żądaniach, a nie na sesji.

Gdy FTP przesyła dane przez połączenie danych, połączenie sterujące jest bezczynne. Jeśli transfer trwa zbyt długo, zapora lub NAT mogą zdecydować, że połączenie sterujące jest martwe i przestać je śledzić, skutecznie przerywając połączenie i myląc pobieranie. Pojedyncze połączenie HTTP jest bezczynne tylko między żądaniami i jest normalne i oczekuje się, że takie połączenia zostaną zerwane po upływie limitu czasu.

Obsługa przeglądarki internetowej

Większość popularnych przeglądarek internetowych może pobierać pliki hostowane na serwerach FTP, chociaż mogą nie obsługiwać rozszerzeń protokołów, takich jak FTPS . W przypadku podania adresu URL FTP, a nie adresu HTTP , dostępna zawartość na serwerze zdalnym jest prezentowana w sposób podobny do używanego w przypadku innych treści internetowych. W pełni funkcjonalny klient FTP można uruchomić w przeglądarce Firefox w postaci rozszerzenia o nazwie FireFTP .

Od 2019 r. Główne przeglądarki, takie jak Chrome i Firefox, w różnym stopniu wycofują obsługę FTP. Google usunęło go całkowicie w Chrome 88. Od 2019 roku Mozilla omawiała propozycje, w tym usunięcie obsługi starych implementacji FTP, które nie są już używane, aby uprościć ich kod. Od kwietnia 2021 r. I Firefox w wersji 88.0 Mozilla wyłączyła obsługę FTP dla Firefoksa i planowała całkowicie usunąć ją w późniejszym wydaniu.

Składnia

Składnia adresu URL protokołu FTP jest opisana w dokumencie RFC   1738 i ma postać: ftp://[user[:password]@]host[:port]/url-path (części w nawiasach są opcjonalne).

Na przykład adres URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt reprezentuje plik myfile.txt z katalogu mydirectory na serwerze public.ftp-servers.example.com jako zasób FTP . Adres URL ftp: // user001: secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt dodaje specyfikację nazwy użytkownika i hasła, których należy użyć, aby uzyskać dostęp do tego zasobu.

Więcej szczegółów na temat określania nazwy użytkownika i hasła można znaleźć w dokumentacji przeglądarek (np. Firefox i Internet Explorer ). Domyślnie większość przeglądarek internetowych korzysta z trybu pasywnego (PASV), który łatwiej przechodzi przez zapory ogniowe użytkowników końcowych.

Istnieją pewne różnice w sposobie, w jaki różne przeglądarki traktują rozpoznawanie ścieżek w przypadkach, gdy istnieje katalog osobisty użytkownika inny niż główny.

Bezpieczeństwo

FTP nie został zaprojektowany jako bezpieczny protokół i ma wiele słabych punktów bezpieczeństwa. W maju 1999 r. Autorzy RFC   2577 wymienili lukę w zabezpieczeniach następujących problemów:

FTP nie szyfruje swojego ruchu; wszystkie transmisje są w postaci zwykłego tekstu, a nazwy użytkowników, hasła, polecenia i dane mogą być odczytane przez każdego, kto jest w stanie przechwytywać pakiety ( sniffing ) w sieci. Ten problem jest wspólny dla wielu specyfikacji protokołów internetowych (takich jak SMTP , Telnet , POP i IMAP ), które zostały zaprojektowane przed utworzeniem mechanizmów szyfrowania, takich jak TLS lub SSL.

Typowe rozwiązania tego problemu obejmują:

  1. Używanie bezpiecznych wersji niezabezpieczonych protokołów, np. FTPS zamiast FTP i TelnetS zamiast Telnet.
  2. Korzystanie z innego, bezpieczniejszego protokołu, który może obsłużyć zadanie, np. SSH File Transfer Protocol lub Secure Copy Protocol .
  3. Korzystanie z bezpiecznego tunelu, takiego jak Secure Shell (SSH) lub wirtualna sieć prywatna (VPN).

FTP przez SSH

FTP przez SSH to praktyka polegająca na tunelowaniu normalnej sesji FTP przez połączenie Secure Shell. Ponieważ FTP używa wielu połączeń TCP (nietypowe dla protokołu TCP / IP, który jest nadal w użyciu), tunelowanie przez SSH jest szczególnie trudne. W przypadku wielu klientów SSH próba skonfigurowania tunelu dla kanału sterującego (początkowe połączenie klient-serwer na porcie 21) będzie chronić tylko ten kanał; kiedy dane są przesyłane, oprogramowanie FTP na każdym końcu ustanawia nowe połączenia TCP (kanały danych), a tym samym nie ma ochrony poufności ani integralności .

W przeciwnym razie konieczne jest, aby oprogramowanie klienckie SSH miało określoną wiedzę na temat protokołu FTP, aby monitorować i przepisywać komunikaty kanału sterującego FTP oraz samodzielnie otwierać nowe przekazywanie pakietów dla kanałów danych FTP. Pakiety oprogramowania obsługujące ten tryb obejmują:

Pochodne

FTPS

Jawny FTPS to rozszerzenie standardu FTP, które umożliwia klientom żądanie szyfrowania sesji FTP. Odbywa się to poprzez wysłanie polecenia „AUTH TLS”. Serwer ma możliwość zezwalania lub odrzucania połączeń, które nie żądają TLS. To rozszerzenie protokołu jest zdefiniowane w dokumencie RFC   4217 . Niejawny FTPS to przestarzały standard FTP, który wymagał użycia połączenia SSL lub TLS. Określono używanie innych portów niż zwykły protokół FTP.

Protokół transferu plików SSH

Protokół transferu plików SSH (chronologicznie drugi z dwóch protokołów w skrócie SFTP) przesyła pliki i ma podobny zestaw poleceń dla użytkowników, ale używa protokołu Secure Shell (SSH) do przesyłania plików. W przeciwieństwie do protokołu FTP szyfruje zarówno polecenia, jak i dane, zapobiegając otwartemu przesyłaniu haseł i poufnych informacji w sieci. Nie może współpracować z oprogramowaniem FTP.

Trivial File Transfer Protocol

Trivial File Transfer Protocol (TFTP) to prosty protokół FTP z blokadą, który umożliwia klientowi pobranie lub umieszczenie pliku na zdalnym hoście. Jednym z jego głównych zastosowań jest wczesne uruchamianie systemu z sieci lokalnej , ponieważ protokół TFTP jest bardzo prosty w implementacji. W protokole TFTP brakuje zabezpieczeń i większości zaawansowanych funkcji oferowanych przez bardziej niezawodne protokoły przesyłania plików, takie jak protokół przesyłania plików. Protokół TFTP został po raz pierwszy znormalizowany w 1981 roku, a aktualną specyfikację protokołu można znaleźć w dokumencie RFC   1350 .

Prosty protokół przesyłania plików

Simple File Transfer Protocol (pierwszy protokół w skrócie SFTP), zgodnie z definicją zawartą w RFC   913 , został zaproponowany jako (niezabezpieczony) protokół przesyłania plików z poziomem złożoności pośrednim między TFTP i FTP. Nigdy nie był szeroko akceptowany w Internecie , a obecnie IETF przyznaje mu status Historyczny . Działa przez port 115 i często otrzymuje inicjalizację SFTP . Posiada zestaw poleceń składający się z 11 poleceń i obsługuje trzy typy transmisji danych: ASCII , binarne i ciągłe. W systemach o rozmiarze słowa będącym wielokrotnością 8 bitów implementacja binarna i ciągła jest taka sama. Protokół obsługuje również logowanie za pomocą identyfikatora użytkownika i hasła, hierarchiczne foldery i zarządzanie plikami (w tym zmiana nazwy , usuwanie , przesyłanie , pobieranie , pobieranie z nadpisywaniem i pobieranie z dołączaniem ).

Polecenia FTP

Kody odpowiedzi FTP

Poniżej znajduje się podsumowanie kodów odpowiedzi FTP, które mogą być zwracane przez serwer FTP . Kody te zostały znormalizowane w RFC   959 przez IETF. Kod odpowiedzi to trzycyfrowa wartość. Pierwsza cyfra służy do wskazania jednego z trzech możliwych wyników - sukcesu, niepowodzenia lub do wskazania błędu lub niepełnej odpowiedzi:

  • 2yz - odpowiedź pomyślna
  • 4yz lub 5yz - odpowiedź niepowodzenia
  • 1yz lub 3yz - błąd lub niepełna odpowiedź

Druga cyfra określa rodzaj błędu:

  • x0z - Składnia. Te odpowiedzi odnoszą się do błędów składniowych.
  • x1z - Informacje. Odpowiedzi na zapytania o informacje.
  • x2z - Połączenia. Odpowiedzi dotyczące połączeń sterujących i transmisji danych.
  • x3z - Uwierzytelnianie i rozliczanie. Odpowiedzi na proces logowania i procedury księgowe.
  • x4z - Nie określono.
  • x5z - system plików. Te odpowiedzi na kody stanu przekazywania z systemu plików serwera.

Trzecia cyfra kodu odpowiedzi służy do podania dodatkowych szczegółów dla każdej z kategorii określonych przez drugą cyfrę.

Zobacz też

Bibliografia

Dalsza lektura

  • RFC   697 - CWD Polecenie FTP. Lipiec 1975.
  • RFC   959 - (standardowy) protokół przesyłania plików (FTP). J. Postel, J. Reynolds. Październik 1985.
  • RFC   1579 - (informacyjny) protokół FTP z obsługą zapory. Luty 1994.
  • RFC   1635 - (informacyjny) How to Use Anonymous FTP. Maj 1994.
  • RFC   1639 - FTP Operation Over Big Address Records (FOOBAR). Czerwiec 1994.
  • RFC   1738 - Uniform Resource Locators (URL). Grudzień 1994.
  • RFC   2228 - (Proposed Standard) FTP Security Extensions. Październik 1997.
  • RFC   2389 - (Proposed Standard) Mechanizm negocjacji funkcji dla protokołu przesyłania plików. Sierpień 1998.
  • RFC   2428 - (Proposed Standard) Extensions for IPv6, NAT i Extended pasywnego trybu. Wrzesień 1998.
  • RFC   2577 - (informacyjne) względy bezpieczeństwa FTP. Maj 1999.
  • RFC   2640 - (Proposed Standard) Internationalization of the File Transfer Protocol. Lipiec 1999.
  • RFC   3659 - (Proposed Standard) Extensions to FTP. P. Hethmon. Marzec 2007.
  • RFC   5797 - (Proposed Standard) FTP Command and Extension Registry. Marzec 2010.
  • RFC   7151 - (Proposed Standard) File Transfer Protocol HOST Command for Virtual Hosts. Marzec 2014.
  • Rejestr poleceń i rozszerzeń FTP IANA - oficjalny rejestr poleceń i rozszerzeń FTP

Linki zewnętrzne