Protokol přenosu souborů - File Transfer Protocol
Komunikační protokol | |
Účel | Přenos souboru |
---|---|
Vývojáři | Abhay Bhushan pro RFC 959 |
Představeno | 16. dubna 1971 |
OSI vrstva | Aplikační vrstva |
Port (y) | 21 pro ovládání, 20 pro přenos dat |
RFC | RFC 959 |
Sada internetových protokolů |
---|
Aplikační vrstva |
Transportní vrstva |
Internetová vrstva |
Odkazová vrstva |
File Transfer Protocol ( FTP ) je standardní komunikační protokol použitý pro přenos počítačových souborů ze serveru na klienta na počítačové síti . FTP je postaveno na architektuře modelu klient -server pomocí samostatného řízení a datových spojení mezi klientem a serverem. Uživatelé FTP se mohou autentizovat pomocí přihlašovacího protokolu prostého textu , obvykle ve formě uživatelského jména a hesla, ale mohou se připojit anonymně, pokud je server nakonfigurován tak, aby to umožňoval. Pro zabezpečený přenos, který chrání uživatelské jméno a heslo a šifruje obsah, je FTP často zabezpečen pomocí SSL/TLS ( FTPS ) nebo nahrazen protokolem SSTP File Transfer Protocol (SFTP).
První klientské aplikace FTP byly programy příkazového řádku vyvinuté před tím, než operační systémy měly grafické uživatelské rozhraní , a stále jsou dodávány s většinou operačních systémů Windows , Unix a Linux . Od té doby bylo vyvinuto mnoho klientů FTP a automatizačních nástrojů pro stolní počítače , servery, mobilní zařízení a hardware a FTP bylo začleněno do produktivních aplikací, jako jsou editory HTML .
V lednu 2021 byla podpora protokolu FTP deaktivována v prohlížeči Google Chrome 88 a deaktivována ve Firefoxu 88.0. V červenci 2021 Firefox 90 úplně zrušil FTP. V říjnu 2021 má Google Chrome 95 zcela odebrat podporu FTP.
Historie serverů FTP
Původní specifikaci protokolu pro přenos souborů sepsal Abhay Bhushan a publikovala ji jako RFC 114 16. dubna 1971. Do roku 1980 běžel FTP na NCP , předchůdci TCP/IP . Protokol byl později nahrazen verzí TCP/IP, RFC 765 (červen 1980) a RFC 959 (říjen 1985), aktuální specifikace. Několik navrhovaných standardů mění RFC 959 , například RFC 1579 (únor 1994) umožňuje firewall přátelský FTP (pasivní režim), RFC 2228 (červen 1997) navrhuje rozšíření zabezpečení, RFC 2428 (září 1998) přidává podporu IPv6 a definuje nový typ pasivního režimu.
Přehled protokolu
Komunikace a přenos dat
FTP může běžet v aktivním nebo pasivním režimu, který určuje, jak se naváže datové připojení. (Tento smysl pro „režim“ je odlišný od příkazu MODE v protokolu FTP a odpovídá místo toho příkazům PORT/PASV/EPSV/atd.) V obou případech klient vytvoří ovládací připojení TCP z náhodného, obvykle neprivilegované , přístav N na FTP serveru příkazovém portu 21.
- V aktivním režimu klient začne poslouchat příchozí datová připojení ze serveru na portu M. Odesílá příkaz FTP PORT M, aby informoval server, na kterém portu naslouchá. Server poté zahájí datový kanál klientovi z jeho portu 20, datového portu serveru FTP.
- V situacích, kdy je klient za bránou firewall a nemůže přijímat příchozí připojení TCP, lze použít pasivní režim . V tomto režimu klient používá řídicí připojení k odeslání příkazu PASV na server a poté ze serveru obdrží IP adresu serveru a číslo portu serveru, které klient poté použije k otevření datového připojení z libovolného klientského portu na server. byla přijata IP adresa serveru a číslo portu serveru.
Oba režimy byly aktualizovány v září 1998, aby podporovaly IPv6 . V té době byly do pasivního režimu zavedeny další změny, které jej aktualizovaly na rozšířený pasivní režim .
Server odpovídá přes ovládací připojení pomocí třímístných stavových kódů v ASCII volitelnou textovou zprávou. Například „200“ (nebo „200 OK“) znamená, že poslední příkaz byl úspěšný. Čísla představují kód odpovědi a volitelný text představuje vysvětlení nebo požadavek čitelný pro člověka (např. <Potřebujete účet pro uložení souboru>). Probíhající přenos dat souborů přes datové připojení lze přerušit pomocí zprávy o přerušení odeslané přes řídicí připojení.
FTP potřebuje dva porty (jeden pro odesílání a jeden pro příjem), protože byl původně navržen pro provoz v programu Network Control Program (NCP), což byl simplexní protokol, který využíval dvě adresy portů , vytvářející dvě připojení, pro obousměrnou komunikaci. Pro každou aplikaci nebo protokol aplikační vrstvy byl vyhrazen lichý a sudý port . Standardizace TCP a UDP snížila potřebu použití dvou simplexních portů pro každou aplikaci až na jeden duplexní port, ale protokol FTP nebyl nikdy upraven tak, aby používal pouze jeden port, a nadále používal dva pro zpětnou kompatibilitu.
Procházení NAT a firewallu
FTP obvykle přenáší data tak, že se server připojí zpět ke klientovi poté, co klient odešle příkaz PORT. To je problematické jak pro NAT, tak pro brány firewall, které neumožňují připojení z internetu k interním hostitelům. U NAT je další komplikací to, že reprezentace IP adres a čísla portu v příkazu PORT odkazuje na IP adresu a port interního hostitele, nikoli na veřejnou IP adresu a port NAT.
K vyřešení tohoto problému existují dva přístupy. Jedním z nich je, že klient FTP a server FTP používají příkaz PASV, což způsobí, že bude navázáno datové připojení z klienta FTP na server. Toto je široce používáno moderními FTP klienty. Dalším přístupem je, aby NAT změnil hodnoty příkazu PORT pomocí brány na úrovni aplikace .
Typy dat
Při přenosu dat po síti jsou definovány čtyři datové typy:
- ASCII (TYP A): Používá se pro text. Data jsou v případě potřeby převedena ze znakové reprezentace odesílajícího hostitele na „8bitový ASCII“ před přenosem a (opět, je-li to nutné) na reprezentaci znaku přijímajícího hostitele. V důsledku toho je tento režim nevhodný pro soubory, které obsahují jiná data než prostý text.
- Obrázek (TYP I, běžně nazývaný binární režim): Odesílající počítač odešle každý soubor bajt po bajtu a příjemce uloží bytestream tak, jak jej přijme. (Pro všechny implementace FTP byla doporučena podpora režimu obrazu).
- EBCDIC (TYPE E): Používá se pro prostý text mezi hostiteli pomocí znakové sady EBCDIC.
- Místní (TYP L n ): Navrženo pro podporu přenosu souborů mezi počítači, které nepoužívají 8bitové bajty, např. 36bitové systémy, jako je DEC PDP-10s . Například „TYP L 9“ by byl použit pro přenos dat v 9bitových bajtech, nebo „TYPE L 36“ pro přenos 36bitových slov. Většina současných FTP klientů/serverů podporuje pouze L 8, což je ekvivalent I.
Internetový koncept, jehož platnost skončila, definoval TYP U pro přenos textových souborů Unicode pomocí UTF-8 ; přestože se koncept nikdy nestal RFC, byl implementován několika klienty/servery FTP.
Všimněte si, že tyto datové typy se běžně nazývají „režimy“, i když toto slovo se také nejednoznačně používá k označení režimu komunikace aktivní-pasivní (viz výše) a režimů nastavených příkazem FTP protokol MODE (viz níže).
Pro textové soubory (TYP A a TYPE E) jsou k dispozici tři různé možnosti ovládání formátu, které určují, jak bude soubor vytištěn:
- Non-print (TYPE AN a TYPE EN)-soubor neobsahuje žádné znaky pro ovládání vozíku určené pro tiskárnu
- Telnet (TYPE AT a TYPE ET) - soubor obsahuje řídicí znaky vozíku Telnet (nebo jinými slovy ASCII C0) (CR, LF atd.)
- ASA (TYPE AA a TYPE EA) - soubor obsahuje řídicí znaky ASA carriage
Tyto formáty byly hlavně relevantní pro řádkové tiskárny ; většina současných FTP klientů/serverů podporuje pouze výchozí nastavení formátu N.
Struktury souborů
Organizace souborů je určena pomocí příkazu STRU. V části 3.1.1 dokumentu RFC959 jsou definovány následující struktury souborů:
- Struktura F nebo FILE (orientovaná na proud). Soubory jsou považovány za libovolnou posloupnost bajtů, znaků nebo slov. Toto je obvyklá struktura souborů v systémech Unix a dalších systémech, jako jsou CP/M, MS-DOS a Microsoft Windows. (Oddíl 3.1.1.1)
- Struktura R nebo RECORD (orientovaná na záznam). Soubory jsou považovány za rozdělené do záznamů, které mohou mít pevnou nebo proměnnou délku. Tato organizace souborů je běžná na sálových a středních systémech, jako jsou MVS, VM/CMS, OS/400 a VMS, které podporují souborově orientované systémy záznamů .
- Struktura P nebo PAGE (orientovaná na stránku). Soubory jsou rozděleny na stránky, které mohou obsahovat data nebo metadata; každá stránka může mít také záhlaví s různými atributy. Tato struktura souborů byla speciálně navržena pro systémy TENEX a obecně není podporována na jiných platformách. RFC1123 část 4.1.2.3 doporučuje, aby tato struktura nebyla implementována.
Většina současných FTP klientů a serverů podporuje pouze STRU F. STRU R je stále používán v sálových a minipočítačových aplikacích pro přenos souborů.
Režimy přenosu dat
Přenos dat lze provést v kterémkoli ze tří režimů:
- Režim streamování (MODE S): Data jsou odesílána jako souvislý stream, což FTP zbavuje jakéhokoli zpracování. Veškeré zpracování je spíše ponecháno na TCP . Není-li data rozdělena do záznamů , není potřeba žádný indikátor konce souboru .
- Blokový režim (MODE B): Navržen primárně pro přenos souborů orientovaných na záznam (STRU R), i když jej lze také použít k přenosu textových souborů orientovaných na proud (STRU F). FTP umístí každý záznam (nebo řádek) dat do několika bloků (záhlaví bloku, počet bajtů a datové pole) a poté je předá TCP.
- Komprimovaný režim (MODE C): Rozšiřuje MODE B o kompresi dat pomocí kódování běhu .
Většina současných FTP klientů a serverů neimplementuje MODE B nebo MODE C; FTP klienti a servery pro operační systémy mainframe a minipočítače jsou výjimkou.
Některý software FTP také implementuje komprimovaný režim založený na DEFLATE , někdy nazývaný "Mode Z" po příkazu, který to umožňuje. Tento režim byl popsán v internetovém konceptu , ale nebyl standardizován.
GridFTP definuje další režimy, MODE E a MODE X, jako rozšíření MODE B.
Další příkazy
Novější implementace FTP podporují příkaz Modify Fact: Modification Time (MFMT), který umožňuje klientovi vzdáleně upravit tento atribut souboru , což umožňuje zachování tohoto atributu při odesílání souborů.
Chcete -li načíst vzdálené časové razítko souboru, použijte příkaz MDTM . Některé servery (a klienti) podporují nestandardní syntaxi příkazu MDTM se dvěma argumenty, které fungují stejně jako MFMT
Přihlásit se
Přihlášení k FTP používá pro udělení přístupu normální schéma uživatelského jména a hesla. Uživatelské jméno je odesláno na server pomocí příkazu USER a heslo je odesláno pomocí příkazu PASS. Tato sekvence je nešifrovaná „na drátě“, takže může být náchylná k útoku čicháním do sítě . Pokud server přijme informace poskytnuté klientem, server odešle klientovi pozdrav a relace začne. Pokud to server podporuje, uživatelé se mohou přihlásit bez zadání přihlašovacích údajů, ale stejný server může autorizovat pouze omezený přístup pro takové relace.
Anonymní FTP
Hostitel, který poskytuje službu FTP, může poskytovat anonymní přístup na FTP. Když se zobrazí výzva k zadání uživatelského jména, uživatelé se do služby obvykle přihlašují pomocí účtu s anonymním účtem (na některých serverech FTP se rozlišují malá a velká písmena). Přestože jsou uživatelé běžně vyzváni, aby místo hesla poslali svou e -mailovou adresu, u dodaných údajů se ve skutečnosti neprovádí žádné ověřování. Mnoho hostitelů FTP, jejichž účelem je poskytovat aktualizace softwaru, umožní anonymní přihlášení.
Rozdíly oproti HTTP
Protokol HTTP v zásadě opravuje chyby ve FTP, díky nimž bylo nepohodlné použití pro mnoho malých dočasných přenosů, které jsou typické pro webové stránky.
FTP má připojení ke stavovému řízení, které udržuje aktuální pracovní adresář a další příznaky, a každý přenos vyžaduje sekundární připojení, přes které jsou data přenášena. V „pasivním“ režimu je toto sekundární připojení z klienta na server, zatímco ve výchozím „aktivním“ režimu je toto připojení ze serveru na klienta. Toto zjevné obrácení rolí v aktivním režimu a náhodná čísla portů pro všechny přenosy jsou důvodem, proč brány firewall a brány NAT mají s FTP tak těžké časy. HTTP je bezstavová a řídí multiplexy a data přes jediné připojení z klienta na server na dobře známých číslech portů, které triviálně prochází branami NAT a snadno se spravuje pomocí firewallů.
Nastavení ovládacího připojení FTP je poměrně pomalé kvůli zpoždění při odesílání všech požadovaných příkazů a čekání na odezvu, takže je obvyklé vyvolat ovládací připojení a ponechat jej otevřené pro více přenosů souborů, než upustit a znovu -pokaždé znovu vytvořte relaci. Naproti tomu HTTP původně přerušilo připojení po každém přenosu, protože to bylo tak levné. Zatímco HTTP následně získal možnost znovu použít připojení TCP pro vícenásobné přenosy, koncepční model je stále spíše nezávislými požadavky než relací.
Při přenosu FTP přes datové připojení je ovládací připojení nečinné. Pokud přenos trvá příliš dlouho, může se brána firewall nebo NAT rozhodnout, že je ovládací připojení nefunkční, a přestat jej sledovat, čímž se připojení skutečně přeruší a způsobí zmatení stahování. Jediné připojení HTTP je pouze nečinné mezi požadavky a je normální a očekává se, že taková připojení budou po uplynutí časového limitu zrušena.
Softwarová podpora
webový prohlížeč
Většina běžných webových prohlížečů může načítat soubory hostované na serverech FTP, i když nemusí podporovat rozšíření protokolů, jako je FTPS . Když je zadána adresa URL FTP - nikoli HTTP - , bude dostupný obsah na vzdáleném serveru prezentován způsobem, který je podobný tomu, který se používá pro jiný webový obsah. FireFTP je rozšíření prohlížeče navržené jako plnohodnotný FTP klient, v minulosti jej bylo možné spustit ve Firefoxu , ale nyní doporučujeme pracovat s Waterfoxem .
Google Chrome zcela odstranil podporu FTP v prohlížeči Chrome 88. V roce 2019 Mozilla projednávala návrhy, včetně pouze odstranění podpory pro staré implementace FTP, které se již nepoužívají ke zjednodušení jejich kódu. V dubnu 2021 vydala Mozilla Firefox 88.0, který ve výchozím nastavení deaktivoval podporu FTP. V červenci 2021 Firefox 90 úplně zrušil podporu FTP.
Syntax
Syntaxe adresy URL FTP je popsána v dokumentu RFC 1738 ve tvaru: ftp://[user[:password]@]host[:port]/url-path
(závorkové části jsou volitelné).
Adresa URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt například představuje soubor myfile.txt z adresáře mydirectory na serveru public.ftp-servers.example.com jako prostředek FTP . Adresa URL ftp: // user001: secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt přidává specifikaci uživatelského jména a hesla, která musí být použita pro přístup k tomuto zdroji.
Další podrobnosti o zadání uživatelského jména a hesla lze nalézt v dokumentaci k prohlížečům (např. Firefox a Internet Explorer ). Ve výchozím nastavení používá většina webových prohlížečů pasivní režim (PASV), který snáze prochází brány firewall koncových uživatelů.
Existovaly určité variace v tom, jak různé prohlížeče zacházejí s rozlišením cesty v případech, kdy pro uživatele existuje domovský adresář bez oprávnění root.
Správce stahování
Většina běžných správců stahování může přijímat soubory hostované na serverech FTP, zatímco některé z nich také poskytují rozhraní pro načítání souborů hostovaných na serverech FTP. DownloadStudio umožňuje nejen stáhnout soubor ze serveru FTP, ale také zobrazit seznam souborů na serveru FTP pomocí Průzkumníka webu.
Bezpečnostní
FTP nebyl navržen jako zabezpečený protokol a má mnoho slabých míst v zabezpečení. V květnu 1999 uvedli autoři RFC 2577 zranitelnost následujících problémů:
- Útok hrubou silou
- Odrazový útok FTP
- Zachycování paketů
- Krádež portů (hádání dalšího otevřeného portu a uzurpování legitimního připojení)
- Falešný útok
- Výčet uživatelských jmen
- DoS nebo DDoS
FTP nešifruje svůj provoz; všechny přenosy jsou v čistém textu a uživatelská jména, hesla, příkazy a data si může přečíst kdokoli, kdo může v síti provádět zachycování paketů ( čichání ). Tento problém je společný mnoha specifikacím internetového protokolu (například SMTP , Telnet , POP a IMAP ), které byly navrženy před vytvořením šifrovacích mechanismů, jako je TLS nebo SSL.
Mezi běžná řešení tohoto problému patří:
- Používání zabezpečených verzí nezabezpečených protokolů, např. FTPS místo FTP a TelnetS místo Telnetu.
- Použití jiného, bezpečnějšího protokolu, který úlohu zvládne, např. SSH File Transfer Protocol nebo Secure Copy Protocol .
- Pomocí zabezpečeného tunelu, jako je Secure Shell (SSH) nebo virtuální privátní síť (VPN).
FTP přes SSH
FTP přes SSH je postup tunelování normální relace FTP přes připojení Secure Shell. Protože FTP používá více připojení TCP (neobvyklé pro stále používaný protokol TCP/IP), je obzvláště obtížné tunelovat přes SSH. U mnoha klientů SSH bude pokus o nastavení tunelu pro řídicí kanál (počáteční připojení klient-server na portu 21) chránit pouze tento kanál; při přenosu dat software FTP na obou koncích nastavuje nová připojení TCP (datové kanály), a proto nemají žádnou ochranu důvěrnosti ani integrity .
V opačném případě je nutné, aby klientský software SSH měl specifické znalosti o protokolu FTP, aby monitoroval a přepisoval zprávy řídicího kanálu FTP a samostatně otevíral nová předávání paketů pro datové kanály FTP. Softwarové balíčky, které podporují tento režim, zahrnují:
- Tectia ConnectSecure (Win/Linux/Unix) softwarové sady SSH Communications Security
Deriváty
FTPS
Explicitní FTPS je rozšíření standardu FTP, které umožňuje klientům požadovat šifrování relací FTP. To se provádí odesláním příkazu „AUTH TLS“. Server má možnost povolit nebo zakázat připojení, která nevyžadují TLS. Toto rozšíření protokolu je definováno v RFC 4217 . Implicitní FTPS je zastaralý standard pro FTP, který vyžadoval použití připojení SSL nebo TLS. Bylo specifikováno používat jiné porty než prostý FTP.
Protokol přenosu souborů SSH
Protokol přenosu souborů SSH (chronologicky druhý ze dvou protokolů zkráceně SFTP) přenáší soubory a má podobnou sadu příkazů pro uživatele, ale k přenosu souborů používá protokol SSH ( Secure Shell ). Na rozdíl od FTP šifruje jak příkazy, tak data, čímž zabraňuje otevřenému přenosu hesel a citlivých informací po síti. Nelze spolupracovat se softwarem FTP.
Triviální protokol pro přenos souborů
Trivial File Transfer Protocol (TFTP) je jednoduchý FTP v uzamčeném kroku, který umožňuje klientovi získat soubor ze vzdáleného hostitele nebo jej umístit na vzdálený počítač. Jedno z jeho primárních použití je v raných fázích spouštění z lokální sítě , protože implementace TFTP je velmi jednoduchá. TFTP postrádá zabezpečení a většina pokročilých funkcí, které nabízejí robustnější protokoly pro přenos souborů, jako je File Transfer Protocol. TFTP byl poprvé standardizován v roce 1981 a aktuální specifikaci pro protokol lze nalézt v RFC 1350 .
Jednoduchý protokol pro přenos souborů
Simple File Transfer Protocol (první protokol zkráceně SFTP), jak jej definuje RFC 913 , byl navržen jako (nezabezpečený) protokol pro přenos souborů s úrovní komplexnosti mezi TFTP a FTP. To bylo nikdy široce přijímaný na internetu , a je nyní přidělena historický stav podle IETF . Běží přes port 115 a často dostává inicializaci SFTP . Má sadu příkazů 11 příkazů a podporuje tři typy přenosu dat: ASCII , binární a kontinuální. U systémů s velikostí slova, která je násobkem 8 bitů, je implementace binárních a spojitých stejná. Protokol také podporuje přihlášení pomocí ID uživatele a hesla, hierarchické složky a správu souborů (včetně přejmenování , mazání , nahrávání , stahování , stahování s přepsáním a stahování s připojením ).
FTP příkazy
Kódy odpovědí FTP
Níže je souhrn kódů odpovědí FTP, které mohou být vráceny serverem FTP . Tyto kódy byly standardizovány v RFC 959 IETF. Kód odpovědi je třímístná hodnota. První číslice se používá k označení jednoho ze tří možných výsledků - úspěchu, neúspěchu nebo k označení chyby nebo neúplné odpovědi:
- 2yz - Úspěšná odpověď
- 4yz nebo 5yz - Neúspěšná odpověď
- 1yz nebo 3yz - chyba nebo neúplná odpověď
Druhá číslice definuje druh chyby:
- x0z - Syntaxe. Tyto odpovědi odkazují na chyby syntaxe.
- x1z - Informace. Odpovědi na žádosti o informace.
- x2z - Připojení. Odpovědi odkazující na ovládací a datová připojení.
- x3z - Ověřování a účetnictví. Odpovědi na proces přihlášení a účetní postupy.
- x4z - Není definováno.
- x5z - souborový systém. Tyto odpovědi přenášejí stavové kódy ze systému souborů serveru.
Třetí číslice kódu odpovědi slouží k poskytnutí dalších podrobností pro každou z kategorií definovaných druhou číslicí.
Viz také
- Porovnání klientského softwaru FTP
- Porovnání softwarových balíků serveru FTP
- Porovnání protokolů pro přenos souborů
- Curl-loader -FTP/S načítání/testování open-source softwaru
- File eXchange Protocol (FXP)
- Protokol souborové služby (FSP)
- FTAM
- FTPFS
- Seznam příkazů FTP
- Seznam návratových kódů serveru FTP
- Spravovaný přenos souborů
- OBEX
- Přístup ke sdíleným souborům
- TCP Wrapper
Reference
Další čtení
- RFC 697 - CWD Příkaz FTP. Července 1975.
- RFC 959 - (standardní) protokol pro přenos souborů (FTP). J. Postel, J. Reynolds. Říjen 1985.
- RFC 1579- (informační) FTP podporující firewall. Únor 1994.
- RFC 1635 - (Informační) Jak používat anonymní FTP. Květen 1994.
- RFC 1639 - FTP operace přes velké záznamy adres (FOOBAR). Červen 1994.
- RFC 1738 - Uniform Resource Locators (URL). Prosinec 1994.
- RFC 2228 - (navrhovaný standard) FTP rozšíření zabezpečení. Říjen 1997.
- RFC 2389 - (navrhovaný standard) Mechanismus vyjednávání funkcí pro protokol přenosu souborů. Srpna 1998.
- RFC 2428 - (Navrhovaný standard) Rozšíření pro IPv6, NAT a rozšířený pasivní režim. Září 1998.
- RFC 2577 - (Informační) Bezpečnostní aspekty FTP. Květen 1999.
- RFC 2640 - (Navrhovaný standard) Internacionalizace protokolu pro přenos souborů. Července 1999.
- RFC 3659 - (Navrhovaný standard) Rozšíření na FTP. P. Hethmon. Března 2007.
- RFC 5797 - (navrhovaný standard) registr příkazů a rozšíření FTP. Březen 2010.
- RFC 7151 - (doporučený standard) Příkaz HOST pro přenos souborů pro virtuální hostitele. Březen 2014.
- IANA registr příkazů a rozšíření FTP - oficiální registr příkazů a rozšíření FTP
externí odkazy
- Komunikační sítě/Protokol pro přenos souborů na Wikibooks
- Online tester FTP serveru Ověření, šifrování, režim a konektivita.
- Anonymní FTP servery podle kódu země TLD (2012): „Offbeat Internet - Public Access - FTP“ . www.jumpjet.info . 2012 . Citováno 16. ledna 2020 .