A brief description of the ftp protocol

xiaoxiao2021-03-06  63

The FTP protocol require two programs, a server program, and a client program. Normally the server program offer files to the client program. But in some cases, the server will also allow the client to upload files.

A Simple FTP Session

The Client Program Connects To A FTP Sever on The Net. Once Connected, The FTP Server Sends a Welcome Message To The Client over The Open Socket (NetWork) Connection.

Server: 220 Sample FTP Server Ready. Please Give User-Name

Client: User Anonymous

Server: 331 User Name OK. Please Give your email address as password

Client: pass joe@nowhere.comm

Server: 230 User Logged in

As you can see, the client and server are communicating in plain text. The digits in the server replies are 'relpy-codes' defined by the FTP protocol. The uppercase words in the beginning of the client commands, are command verbs that also are defined by the RFC. The protocol is designed in a way that makes it easy for machines and humans to understand the dialog. in most cases, the client program do not have to interperate the text after the reply code.

NOW, The User Want's To See The Available Files and Dirs, And Issues A Dir Command in The Client Program.

Client: Type A

Server: 200 Type set to a

Client: PASV

Server: 227 Entering Passive Mode (193,91,161,12,28,46)

Client: List

Server: 150 Opening ASCII Mode Data Connection for / Bin / LS

Server: 226 TRANSFER COMPLETE

......................

The PASV command tells the server to prepere for a new socket connection by creating a new socket and listen for a connection from the client. And now, as you see, things are getting a little more complicated. The server reply includes a IP address and a port number, encoded as 6 digits, seperated ny commas. The client must find and understand this address in order to receive the listing.The LIST command tells the server to give a directory / file listing. and now the server replies with two reply lines ... What is happening is that the firts line tells the client that the listing is ready, and that the client can go on and make a new connection to the server. The client connects to the IP address given by the PASV reply, and receives data until there is no more data to get. Then it close the temporary data connaction and switch back to the control connection to get's the second reply line, which tells if the server transfered the whole listing.

In order to receive a directory listing, the client and server use two socket connections, one for the control flow (server sends commands, the server replies in plain text) and one for the data connection (which is continious and goes in one direction only .).

The User Finds An Interesting File, And Give The FTP Client The Command To Get It.

Client: Type I

Server: 200 Type Set To I

Client: PASV

Server: 227 Entering Passive Mode (193,91,161,12,28,46)

Client: Retr Test.zip

Server: 150 Opening Binary Mode Data Connection for Test.zip

Server: 226 TRANSFER COMPLETE

As you see, the server and client use the exact same method to get a file, as they do to get a directory listing. The only change is that the RETR command is used in stead of the LIST command. In this case the file was a .zip archive, and since such files can not be translated to text-files (at least not in a safe manner), the FTP client switched to binary mode (TYPE I). Files and directory listings can be transfered in both binary and text-mode. Since different operating systems use different means to seperate lines in text-files, it is generally a good idea to let the FTP server and FTP client do the conversion. Both know the rules for a ASCII (text) transfer, and the client always knows the rules for the local storage of text-files.You can easily connect to a FTP server with a Telnet client and give commands, but due to the fact that the file-trasfers use a seperate socket connection, you can NOT (EASILY) Transfer Files WITHOUT A FTP Client.

By Jarle Aase

转载请注明原文地址:https://www.9cbs.com/read-85747.html

New Post(0)