orm@doc-tcpip.org

Erstellt: April 1998 - Letzte Modifikation: Februar 2012

[ Main | Local ]


Wie FTP funktioniert

Die FTP-Kommandos und wie man Performance testet

Die RFCs zum Thema

RFC 959
Es gibt einen IP-Trace zu diesem Thema.

Wie es funktioniert

Das FTP (File Transfer Protocol) setzt auf TCP als Transportprotokoll auf. Es dient ausschließlich zur Datenübertragung, auch wenn man, je nach Implementation, auch Files löschen, Direktories anlegen etc. kann. Es wird kein virtuelles Terminal (so wie bei Telnet) aufgebaut - das bedeutet, daß die Daten entsprechend aufgearbeitet werden. Es werden auch keine Absprachen zwischen den Rechnern getroffen. Das Format der Daten (ASCII, EBCDIC, Binär) sowie die Struktur, das Format der Namen, Block- oder Zeilenorientierung müssen bei der Aufarbeitung berücksichtigt werden.

Das FTP ist als Client/Server Dienst aufgebaut und funktioniert über zwei Ports: die Steuerleitung (Port 21) und die Datenleitung (Port 20). Über die Steuerleitung werden alle Befehle und Rückgaben ausgetauscht, die Datenleitung wird nur bei Datenübertragungen aufgebaut. Das kann allerdings bei langen Dateilisten nach einem "ls" auch passieren. Hier ein bisschen ASCII-Art, um es klarer zu machen:

.                SERVER                                     CLIENT
.                                                       _______________
.                                                      |               |
.                                                      |    Benutzer   |
.            _______________                           | Schnittstelle |
.           |               |      Steuerleitung       |---------------|
.           |  Protokoll -  | <--------------------->  |  Protokoll -  |
.           |  Interpreter  | Port 21          Port X  |  Interpreter  |
.           |---------------|                          |---------------|
.           |     DTP       |      Datenleitung        |               |
.           | Data Transfer | <--------------------->  |       DTP     |
.           |    Process    | Port 20          Port X  |               |
.           |_______________|                          |_______________|
.                                                             _______
.                _______                                     | DATEN |
.               | DATEN |                                    |   FS  |
.               |  FS   |                                    |_______|
.               |_______|
Wie schon erwähnt gegen über die Steuerleitung alle Befehle und es kommen die definierten Antworten zurück. Definiert sind die Zahlenwerte der Antworten, aber nicht der Wortlaut, der ausgegeben wird. Die Datenleitung wird nur für die Dauer eines Datentransfers aufgebaut und nach Ende sofort abgebaut.

Einige nützliche FTP-Subkommandos

Es gibt eine ganze Reihe Kommandos, die aber nicht immer alle implementiert sind. Selbst wenn mit dem help-Subkommando einzele Kommandos angezeigt werden, ist das noch keine Garantie für die Funktion....
Generell muß man immer daran denken, das die Maschine, an der man sitzt der Client ist, und die Maschine, die man kontaktiert, der Server. Die Kommandos beziehen sich Defaultmäßig immer auf den Server, also ein "ls" oder "pwd" greift auf das Dateisystem des Servers, der entfernten Maschine zu. Zugriff auf das lokale Dateisystem erhält man, indem man den Kommandos ein "l" oder ein "!" vorstellt, also "!ls" oder "lcd". Hier eine Liste brauchbarer FTP-Subkommandos; auf die grundlegenden Kommandos ls, dir, get, put, cd, ascii, bin, bye gehe ich nicht ein:

Zugangskontrollen, die der ftpd und das ftp-Kommando ausführen

Man kann das Einloggen beim ftp etwas vereinfachen, wenn man in seinem Homeverzeichnisch das File $HOME/.netrc anlegt. Darin spezifiert man die Maschine, zu der man sich verbinden möchte, den Login-Namen, den man benutzen möchte sowei das damit verbundene Passwort. Ruft man dann den ftp auf, so wird nach dem Maschinennamen im File gesucht, und dann die Verbindung mit Usernamen und Passwort aufgebaut. Spart tipperei. Hier ein Beispiel:
machine remote_sys login doctcp password ein_passwd
Das File .netrc wird übrigens auch vom rexec-Kommando benutzt und es steht das Passwort im Klartext drin - also Vorsicht.

Der ftp-Deamon auf dem Server seinerseits prüft eingehende Anfragen mit Hilfe folgender Files: /etc/ftpaccess, /etc/ftpusers und dem Passwort-File (der eben PAM, Kerberos, was auch immer).
Im File /etc/ftpaccess kann man je nach Implementation eine ganze Reihe Dinge einstellen, wer reindarf, wer welche Kommandos benutzen darf etc. Ein Blick in die man-Page lohnt sich...
Im File /etc/ftpusers darf ein User nur dann auftauchen, wenn er kein FTP zu dieser Maschine machen darf. Auf sicheren Systemen sind alle Systemuser defaultmäßig in diesem File.

Die Kommandos, die der FTP-Server versteht

Der FTP-Server versteht andere Kommandos im Vergleich zum Klient. Damit man nicht durcheinander kommt, werden Server-Kommandos großgeschrieben. Mit diesen Kommandos hat man nichts zu tun, aber man sieht sie natürlich in einem IP-Trace. Spezielles Interesse hat dabei das PORT-Kommando, das dazu dient, den Port auszuhandeln, auf dem die Datenleitung geöffnet werden soll bzw. kann. Über diesen Port geht dann die eigentliche Datenübertragung. Ein Beispiel:

TCP: 00000000     0101080a 3a436905 d3b3efc1 504f5254     |....:Ci.....PORT|
TCP: 00000010     2031302c 32302c31 302c372c 3133382c     | 10,20,10,7,138,|
TCP: 00000020     3131360d 0a                             |116..           |
6 Dezimalstellen in ASCII, zb. PORT 10,20,10,7,138,116
Die ersten 4: IP Adresse, hier 10.20.10.7.
Die letzten 2 sind die Portnummer in einer 16bit Darstellung, "Byte2,Byte1".
Man muss also das Byte2 mit 256 malnehmen und das Byte1 dazuaddieren:
138 * 256 + 116 = 35444

Der Port, über den die Datenverbindung aufgemacht wird, ist also 35444, ein "ephemeral port" also ein dynamischer, flüchtiger Port.

FTP zur Performace Analyse im Netz

Durch eine Kombination des ftp-Kommandos und des dd-Kommandos kann man den TCP Durchsatz einer Verbindung seht gut testen. Dabei kann man beliebig große Files aus /dev/zero generieren und nach /dev/null pumpen, ohne Platten oder Memory zum Puffern zu benutzen.

Dazu muß man im ftp-Menu mit dd Daten auf /dev/null der Zielmaschine kopieren:

ftp> bin
ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null

(Auf meiner Lokalen Maschine baue ich eine ftp-Verbindung
zum Zielrechner auf. Dann setze ich einen put-Befehl ab,
der mit dd einen Strom von Nullen (aus /dev/zero) in 
10000 * 32 Kb Blöcken über das Netz schiebt. Damit die 
Platten auf dem Zielrechner nichts zu tun haben, geht es 
nach /dev/null.)

Hier ein Beispiel. Zwei Maschinen an einem 100 MBit Netz, und sie haben das Netz für sich:

ftp> bin
200 Type set to I.
ftp> put "|dd if=/dev/zero bs=32k count=10000" /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
10000+0 records in
10000+0 records out
226 Transfer complete.
327680000 bytes sent in 27.65 seconds (1.157e+04 Kbytes/s)
local: |dd if=/dev/zero bs=32k count=10000 remote: /dev/null
Freundlicherweise wird gleich der Durchsatz angegeben: 11570 KB/sec, das sind 11.3 MB/sec (94.7 Mbps). Mit einem Gigabyte Adapter würde man rund das zehnfache erwarten:
...
327680000 bytes sent in 2.789 seconds (1.147e+05 Kbytes/s)
...
(Das sind 112 MB/s bzw. 940 Mbps)
(Zwei Gigabit Ethernet Adapter, 1500 Byte MTU)

Jetzt mit Jumbo-Frames:
...
327680000 bytes sent in 2.652 seconds (1.207e+05 Kbytes/s)
...
(Das sind 117.87 MB/s bzw. 989 Mbps)
(Zwei Gigabit Ethernet Adapter, 9000 Byte MTU)

Bei diesen Beispielen hatten die Maschinen das Netz für sich und waren über zwei Switches und einen Backbone zusammengeschaltet. Das sind also Spitzenwerte, die den oberen Anschlag darstellen. Im wahren Leben kann das beliebig langsam sein, und man muß alle beteiligten Komponenten im Auge behalten: Verkabelung, Switche/Router, Firewall und den Verkehr, den die anderen Maschinen im Netz verursachen.


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )