Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
File Transfer Protocol
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Protocol overview== ===Communication and data transfer=== [[File:Passive FTP Verbindung.svg|thumb|Illustration of starting a passive connection using port 21]] FTP may run in ''active'' or ''passive'' mode, which determines how the data connection is established.<ref name="slack">{{cite web |title=Active FTP vs. Passive FTP, a Definitive Explanation |url=http://slacksite.com/other/ftp.html |publisher=Slacksite.com}}</ref> (This sense of "mode" is different from that of the MODE command in the FTP protocol.) * In active mode, the client starts listening for incoming data connections from the server on port M. It sends the FTP command PORT M to inform the server on which port it is listening. The server then initiates a data channel to the client from its port 20, the FTP server data port. * In situations where the client is behind a [[Firewall (computing)|firewall]] and unable to accept incoming TCP connections, ''passive mode'' may be used. In this mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the server,<ref name="slack"/> which the client then uses to open a data connection from an arbitrary client port to the server IP address and server port number received.<ref name="postel">{{IETF RFC|959}} (Standard) File Transfer Protocol (FTP). Postel, J. & Reynolds, J. (October 1985).</ref> Both modes were updated in September 1998 to support [[IPv6]]. Further changes were introduced to the passive mode at that time, updating it to ''extended passive mode''.<ref>{{IETF RFC|2428}} (Proposed Standard) Extensions for IPv6, NAT, and Extended Passive Mode. Allman, M. & Metz, C. & Ostermann, S. (September 1998).</ref> The server responds over the control connection with [[List of FTP server return codes|three-digit status codes]] in ASCII with an optional text message. For example, "200" (or "200 OK") means that the last command was successful. The numbers represent the code for the response and the optional text represents a human-readable explanation or request (e.g. <Need account for storing file>).<ref name="for" /> An ongoing transfer of file data over the data connection can be aborted using an interrupt message sent over the control connection. FTP needs two ports (one for sending and one for receiving) because it was originally designed to operate on top of [[Network Control Protocol (ARPANET)|Network Control Protocol]] (NCP), which was a [[Simplex communication|simplex protocol]] that utilized two [[List of TCP and UDP port numbers|port addresses]], establishing two connections, for two-way communications. An odd and an even port were reserved for each [[application layer]] application or protocol. The standardization of TCP and UDP reduced the need for the use of two simplex ports for each application down to one duplex port,<ref name="stevens1994v1">{{cite book | last = Stevens | first = W. Richard | title = TCP/IP Illustrated Volume I | location = Reading, Massachusetts, USA | publisher= Addison-Wesley Publishing Company | year = 1994 | isbn = 0-201-63346-9 | volume = 1 }}</ref>{{Rp|15}} but the FTP protocol was never altered to only use one port, and continued using two for backwards compatibility. ===NAT and firewall traversal=== FTP normally transfers data by having the server connect back to the client, after the PORT command is sent by the client. This is problematic for both [[Network address translation|NATs]] and firewalls, which do not allow connections from the Internet towards internal hosts.<ref name="ncftp">{{cite web |last=Gleason |first=Mike |year=2005 |title=The File Transfer Protocol and Your Firewall/NAT |url=https://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html |publisher=Ncftp.com}}</ref> For NATs, an additional complication is that the representation of the IP addresses and port number in the PORT command refer to the internal host's IP address and port, rather than the public IP address and port of the NAT. There are two approaches to solve this problem. One is that the FTP client and FTP server use the PASV command, which causes the data connection to be established from the FTP client to the server.<ref name="ncftp" /> This is widely used by modern FTP clients. Another approach is for the NAT to alter the values of the PORT command, using an [[application-level gateway]] for this purpose.<ref name="ncftp" /> [[File:FTP model.png|thumb|A model chart of how FTP works]] ===Data types=== While transferring data over the network, five data types are defined:<ref name="tcpip" /><ref name="net+" /><ref name="clark" /> * [[ASCII]] (TYPE A): Used for text. Data is converted, if needed, from the sending host's character representation to [[Extended ASCII|"8-bit ASCII"]] before transmission, and (again, if necessary) to the receiving host's character representation, including [[newline]]s. As a consequence, this mode is inappropriate for files that contain data other than ASCII. * Image (TYPE I, commonly called [[Binary data|Binary]] mode): The sending machine sends each file [[byte]] by byte, and the recipient stores the [[bytestream]] as it receives it. (Image mode support has been recommended for all implementations of FTP). * [[EBCDIC]] (TYPE E): Used for plain text between hosts using the EBCDIC character set. * Local (TYPE L ''n''): Designed to support file transfer between machines which do not use 8-bit bytes, e.g. [[36-bit computing|36-bit systems]] such as DEC [[PDP-10]]s. For example, "TYPE L 9" would be used to transfer data in 9-bit bytes, or "TYPE L 36" to transfer 36-bit words. Most contemporary FTP clients/servers only support L 8, which is equivalent to I. * [[Unicode]] text files using [[UTF-8]] (TYPE U): defined in an expired [[Internet Draft]]<ref>{{Cite IETF|last=Klensin|first=John|title=FTP TYPE Extension for Internationalized Text|draft=draft-klensin-ftpext-typeu-00|access-date=2020-06-09}}</ref> which never became an RFC, though it has been implemented by several FTP clients/servers. Note these data types are commonly called "modes", although ambiguously that word is also used to refer to active-vs-passive communication mode (see above), and the modes set by the FTP protocol MODE command (see below). For text files (TYPE A and TYPE E), three different format control options are provided, to control how the file would be printed: * Non-print (TYPE A N and TYPE E N) β the file does not contain any carriage control characters intended for a printer * [[Telnet]] (TYPE A T and TYPE E T) β the file contains Telnet (or in other words, ASCII C0) carriage control characters (CR, LF, etc) * [[ASA carriage control characters|ASA]] (TYPE A A and TYPE E A) β the file contains ASA carriage control characters These formats were mainly relevant to [[line printer]]s; most contemporary FTP clients/servers only support the default format control of N. ===File structures=== File organization is specified using the STRU command. The following file structures are defined in section 3.1.1 of RFC959: * '''F''' or FILE structure (stream-oriented). Files are viewed as an arbitrary sequence of bytes, characters or words. This is the usual file structure on Unix systems and other systems such as CP/M, MS-DOS and Microsoft Windows. (Section 3.1.1.1) * '''R''' or RECORD structure (record-oriented). Files are viewed as divided into records, which may be fixed or variable length. This file organization is common on mainframe and midrange systems, such as MVS, VM/CMS, OS/400 and VMS, which support [[record-oriented filesystem]]s. * '''P''' or PAGE structure (page-oriented). Files are divided into pages, which may either contain data or metadata; each page may also have a header giving various attributes. This file structure was specifically designed for [[TENEX (operating system)|TENEX]] systems, and is generally not supported on other platforms. RFC1123 section 4.1.2.3 recommends that this structure not be implemented. Most contemporary FTP clients and servers only support STRU F. STRU R is still in use in mainframe and minicomputer file transfer applications. ===Data transfer modes=== Data transfer can be done in any of three modes:<ref name="for" /><ref name="tcpip" /> * Stream mode (MODE S): Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all processing is left up to [[Transmission Control Protocol|TCP]]. No End-of-file indicator is needed, unless the data is divided into [[Record (computer science)|records]]. * Block mode (MODE B): Designed primarily for transferring record-oriented files (STRU R), although can also be used to transfer stream-oriented (STRU F) text files. FTP puts each record (or line) of data into several blocks (block header, byte count, and data field) and then passes it on to TCP.<ref name="clark" /> * Compressed mode (MODE C): Extends MODE B with data compression using [[run-length encoding]]. Most contemporary FTP clients and servers do not implement MODE B or MODE C; FTP clients and servers for mainframe and minicomputer operating systems are the exception to that. Some FTP software also implements a [[DEFLATE]]-based compressed mode, sometimes called "Mode Z" after the command that enables it. This mode was described in an [[Internet Draft]], but not standardized.<ref>{{cite IETF |title=Deflate transmission mode for FTP |draft=draft-preston-ftpext-deflate-03 |first=J. |last=Preston |date=January 2005 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=27 January 2016}}</ref> [[GridFTP]] defines additional modes, MODE E<ref>{{Cite web|last=Allcock|first=W.|date=April 2003|title=GridFTP: Protocol Extensions to FTP for the Grid|url=https://ogf.org/documents/GFD.20.pdf}}</ref> and MODE X,<ref>{{Cite web|last=Mandrichenko|first=I.|date=May 4, 2005|title=GridFTP v2 Protocol Description|url=https://ogf.org/documents/GFD.47.pdf}}</ref> as extensions of MODE B. ===Additional commands=== More recent implementations of FTP support the ''Modify Fact: Modification Time'' (MFMT) command, which allows a client to adjust that [[file attribute]] remotely, enabling the preservation of that attribute when uploading files.<ref>{{cite web |title=MFMT FTP command |url=https://support.solarwinds.com/SuccessCenter/s/article/MFMT-FTP-command |website=support.solarwinds.com |date=2018-10-11}}</ref><ref>{{cite web |title=FTP Commands: DSIZ, MFCT, MFMT, AVBL, PASS, XPWD, XMKD {{!}} Serv-U |url=https://www.serv-u.com/resources/tutorial/dsiz-mfct-mfmt-avbl-pass-xpwd-xmkd-ftp-command |website=www.serv-u.com |language=en}}</ref> To retrieve a remote file timestamp, there's ''MDTM'' command. Some servers (and clients) support nonstandard syntax of the ''MDTM'' command with two arguments, that works the same way as ''MFMT''<ref>{{cite web |title=MDTM FTP command |url=https://support.solarwinds.com/SuccessCenter/s/article/MDTM-FTP-command |website=support.solarwinds.com |date=2018-10-11}}</ref>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)