设为首页 收藏本站
查看: 928|回复: 0

FILE TRANSFER PROTOCOL (FTP) [RFC 959]

[复制链接]

尚未签到

发表于 2015-5-27 11:45:00 | 显示全部楼层 |阅读模式
  
                                                                        
Network Working Group                                          J. Postel
Request for Comments: 959                                    J. Reynolds
                                                                     ISI
Obsoletes RFC: 765 (IEN 149)                                October 1985
  FILE TRANSFER PROTOCOL (FTP)
  
Status of this Memo
  This memo is the official specification of the File Transfer
   Protocol (FTP).  Distribution of this memo is unlimited.
  The following new optional commands are included in this edition of
   the specification:
  CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
      (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
      (Print Directory), and SYST (System).
  Note that this specification is compatible with the previous edition.
  1.  INTRODUCTION
  The objectives of FTP are 1) to promote sharing of files (computer
   programs and/or data), 2) to encourage indirect or implicit (via
   programs) use of remote computers, 3) to shield a user from
   variations in file storage systems among hosts, and 4) to transfer
   data reliably and efficiently.  FTP, though usable directly by a user
   at a terminal, is designed mainly for use by programs.
  The attempt in this specification is to satisfy the diverse needs of
   users of maxi-hosts, mini-hosts, personal workstations, and TACs,
   with a simple, and easily implemented protocol design.
  This paper assumes knowledge of the Transmission Control Protocol
   (TCP) [2] and the Telnet Protocol [3].  These documents are contained
   in the ARPA-Internet protocol handbook [1].
  2.  OVERVIEW
  In this section, the history, the terminology, and the FTP model are
   discussed.  The terms defined in this section are only those that
   have special significance in FTP.  Some of the terminology is very
   specific to the FTP model; some readers may wish to turn to the
   section on the FTP model while reviewing the terminology.
  
  
  
  Postel & Reynolds                                               [Page 1]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
   2.1.  HISTORY
  FTP has had a long evolution over the years.  Appendix III is a
      chronological compilation of Request for Comments documents
      relating to FTP.  These include the first proposed file transfer
      mechanisms in 1971 that were developed for implementation on hosts
      at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
  RFC 172 provided a user-level oriented protocol for file transfer
      between host computers (including terminal IMPs).  A revision of
      this as RFC 265, restated FTP for additional review, while RFC 281
      suggested further changes.  The use of a "Set Data Type"
      transaction was proposed in RFC 294 in January 1982.
  RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
      was now defined as a protocol for file transfer between HOSTs on
      the ARPANET, with the primary function of FTP defined as
      transfering files efficiently and reliably among hosts and
      allowing the convenient use of remote file storage capabilities.
      RFC 385 further commented on errors, emphasis points, and
      additions to the protocol, while RFC 414 provided a status report
      on the working server and user FTPs.  RFC 430, issued in 1973,
      (among other RFCs too numerous to mention) presented further
      comments on FTP.  Finally, an "official" FTP document was
      published as RFC 454.
  By July 1973, considerable changes from the last versions of FTP
      were made, but the general structure remained the same.  RFC 542
      was published as a new "official" specification to reflect these
      changes.  However, many implementations based on the older
      specification were not updated.
  In 1974, RFCs 607 and 614 continued comments on FTP.  RFC 624
      proposed further design changes and minor modifications.  In 1975,
      RFC 686 entitled, "Leaving Well Enough Alone", discussed the
      differences between all of the early and later versions of FTP.
      RFC 691 presented a minor revision of RFC 686, regarding the
      subject of print files.
  Motivated by the transition from the NCP to the TCP as the
      underlying protocol, a phoenix was born out of all of the above
      efforts in RFC 765 as the specification of FTP for use on TCP.
  This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, and to add some new
      optional commands.
  
Postel & Reynolds                                               [Page 2]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      In particular, the following new optional commands are included in
      this edition of the specification:
  CDUP - Change to Parent Directory
  SMNT - Structure Mount
  STOU - Store Unique
  RMD - Remove Directory
  MKD - Make Directory
  PWD - Print Directory
  SYST - System
  This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification.
  2.2.  TERMINOLOGY
  ASCII
  The ASCII character set is as defined in the ARPA-Internet
         Protocol Handbook.  In FTP, ASCII characters are defined to be
         the lower half of an eight-bit code set (i.e., the most
         significant bit is zero).
  access controls
  Access controls define users' access privileges to the use of a
         system, and to the files in that system.  Access controls are
         necessary to prevent unauthorized or accidental use of files.
         It is the prerogative of a server-FTP process to invoke access
         controls.
  byte size
  There are two byte sizes of interest in FTP:  the logical byte
         size of the file, and the transfer byte size used for the
         transmission of the data.  The transfer byte size is always 8
         bits.  The transfer byte size is not necessarily the byte size
         in which data is to be stored in a system, nor the logical byte
         size for interpretation of the structure of the data.
  
  Postel & Reynolds                                               [Page 3]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      control connection
  The communication path between the USER-PI and SERVER-PI for
         the exchange of commands and replies.  This connection follows
         the Telnet Protocol.
  data connection
  A full duplex connection over which data is transferred, in a
         specified mode and type. The data transferred may be a part of
         a file, an entire file or a number of files.  The path may be
         between a server-DTP and a user-DTP, or between two
         server-DTPs.
  data port
  The passive data transfer process "listens" on the data port
         for a connection from the active transfer process in order to
         open the data connection.
  DTP
  The data transfer process establishes and manages the data
         connection.  The DTP can be passive or active.
  End-of-Line
  The end-of-line sequence defines the separation of printing
         lines.  The sequence is Carriage Return, followed by Line Feed.
  EOF
  The end-of-file condition that defines the end of a file being
         transferred.
  EOR
  The end-of-record condition that defines the end of a record
         being transferred.
  error recovery
  A procedure that allows a user to recover from certain errors
         such as failure of either host system or transfer process.  In
         FTP, error recovery may involve restarting a file transfer at a
         given checkpoint.
  
  Postel & Reynolds                                               [Page 4]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      FTP commands
  A set of commands that comprise the control information flowing
         from the user-FTP to the server-FTP process.
  file
  An ordered set of computer data (including programs), of
         arbitrary length, uniquely identified by a pathname.
  mode
  The mode in which data is to be transferred via the data
         connection.  The mode defines the data format during transfer
         including EOR and EOF.  The transfer modes defined in FTP are
         described in the Section on Transmission Modes.
  NVT
  The Network Virtual Terminal as defined in the Telnet Protocol.
  NVFS
  The Network Virtual File System.  A concept which defines a
         standard network file system with standard commands and
         pathname conventions.
  page
  A file may be structured as a set of independent parts called
         pages.  FTP supports the transmission of discontinuous files as
         independent indexed pages.
  pathname
  Pathname is defined to be the character string which must be
         input to a file system by a user in order to identify a file.
         Pathname normally contains device and/or directory names, and
         file name specification.  FTP does not yet specify a standard
         pathname convention.  Each user must follow the file naming
         conventions of the file systems involved in the transfer.
  PI
  The protocol interpreter.  The user and server sides of the
         protocol have distinct roles implemented in a user-PI and a
         server-PI.
  
Postel & Reynolds                                               [Page 5]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      record
  A sequential file may be structured as a number of contiguous
         parts called records.  Record structures are supported by FTP
         but a file need not have record structure.
  reply
  A reply is an acknowledgment (positive or negative) sent from
         server to user via the control connection in response to FTP
         commands.  The general form of a reply is a completion code
         (including error codes) followed by a text string.  The codes
         are for use by programs and the text is usually intended for
         human users.
  server-DTP
  The data transfer process, in its normal "active" state,
         establishes the data connection with the "listening" data port.
         It sets up parameters for transfer and storage, and transfers
         data on command from its PI.  The DTP can be placed in a
         "passive" state to listen for, rather than initiate a
         connection on the data port.
  server-FTP process
  A process or set of processes which perform the function of
         file transfer in cooperation with a user-FTP process and,
         possibly, another server.  The functions consist of a protocol
         interpreter (PI) and a data transfer process (DTP).
  server-PI
  The server protocol interpreter "listens" on Port L for a
         connection from a user-PI and establishes a control
         communication connection.  It receives standard FTP commands
         from the user-PI, sends replies, and governs the server-DTP.
  type
  The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Establishing
         Data Connections.
  
  
Postel & Reynolds                                               [Page 6]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      user
  A person or a process on behalf of a person wishing to obtain
         file transfer service.  The human user may interact directly
         with a server-FTP process, but use of a user-FTP process is
         preferred since the protocol design is weighted towards
         automata.
  user-DTP
  The data transfer process "listens" on the data port for a
         connection from a server-FTP process.  If two servers are
         transferring data between them, the user-DTP is inactive.
  user-FTP process
  A set of functions including a protocol interpreter, a data
         transfer process and a user interface which together perform
         the function of file transfer in cooperation with one or more
         server-FTP processes.  The user interface allows a local
         language to be used in the command-reply dialogue with the
         user.
  user-PI
  The user protocol interpreter initiates the control connection
         from its port U to the server-FTP process, initiates FTP
         commands, and governs the user-DTP if that process is part of
         the file transfer.
  
  
  
  
  
  
  
  
  
  
Postel & Reynolds                                               [Page 7]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
   2.3.  THE FTP MODEL
  With the above definitions in mind, the following model (shown in
      Figure 1) may be diagrammed for an FTP service.
  -------------
                                            |/---------\|
                                            ||   User  ||    --------
                                            ||Interface|| User |
                                            |\----^----/|    --------
                  ----------                |     |     |
                  |/------\|  FTP Commands  |/----V----\|
                  ||Server||   User  ||
                  ||  PI  ||   FTP Replies  ||    PI   ||
                  |\--^---/|                |\----^----/|
                  |   |    |                |     |     |
      --------    |/--V---\|      Data      |/----V----\|    --------
      | File ||Server||  User   || File |
      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
      --------    |\------/|                |\---------/|    --------
                  ----------                -------------
  Server-FTP                   USER-FTP
  NOTES: 1. The data connection may be used in either direction.
             2. The data connection need not exist all of the time.
  Figure 1  Model for FTP Use
  In the model described in Figure 1, the user-protocol interpreter
      initiates the control connection.  The control connection follows
      the Telnet protocol.  At the initiation of the user, standard FTP
      commands are generated by the user-PI and transmitted to the
      server process via the control connection.  (The user may
      establish a direct control connection to the server-FTP, from a
      TAC terminal for example, and generate standard FTP commands
      independently, bypassing the user-FTP process.) Standard replies
      are sent from the server-PI to the user-PI over the control
      connection in response to the commands.
  The FTP commands specify the parameters for the data connection
      (data port, transfer mode, representation type, and structure) and
      the nature of file system operation (store, retrieve, append,
      delete, etc.).  The user-DTP or its designate should "listen" on
      the specified data port, and the server initiate the data
      connection and data transfer in accordance with the specified
      parameters.  It should be noted that the data port need not be in
  
Postel & Reynolds                                               [Page 8]

  
RFC 959                                                     October 1985
File Transfer Protocol
  
      the same host that initiates the FTP commands via the control
      connection, but the user or the user-FTP process must ensure a
      "listen" on the specified data port.  It ought to also be noted
      that the data connection may be used for simultaneous sending and
      receiving.
  In another situation a user might wish to transfer files between
      two hosts, neither of which is a local host. The user sets up
      control connections to the two servers and then arranges for a
      data connection between them.  In this manner, control information
      is passed to the user-PI but data is transferred between the
      server data transfer processes.  Following is a model of this
      server-server interaction.
  
                    Control     ------------   Control
                    ---------->| User-FTP |' represents
   commands from host U to host S, and '

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-71211-1-1.html 上篇帖子: Ftp 文件上传下载类 下篇帖子: linux中配置ftp-vsftp
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表