Höhere Protokolle

In diesem Abschnitt werden beispielhaft einige höhere Protokolle für Internet-Dienste skizziert. Bemerkenswert ist, daß viele dieser Protokolle aus wenigen Anweisungen in lesbarem Klartext bestehen. Der Grund hierfür ist unter anderem, daß man diese Protokolle zum Testen einer Verbindung durch eine Telnet-Verbindung auf einem bestimmten Port (z. B. 80 für HTTP) von Hand nachvollziehen kann. Durch den Klartext ist auch die Fehlersuche bei einer Verbindung ohne großen Aufwand und ohne spezielle Tools möglich. Die vorgestellten Protokolle werden hier nicht bis ins Detail ausgebreitet, es soll Ihnen nur eine Vorstellung über die Arbeitsweise der Internet-Protokolle vermittelt werden.

DHCP

Um in einem IP-basierten Netzwerk Kontakt mit anderen Rechnern aufnehmen zu können, benötigt jeder Computer eine eigene, eindeutige IP-Nummer. Je größer das Netzwerk wird und je mehr verschiedene Rechnerplattformen darin vereint sind, desto höher ist der Aufwand für den Administrator: Wann immer ein neuer Rechner in das Netzwerk integriert wird, muß er zuerst konfiguriert werden. Ändert einer der zentralen Server seine Adresse oder wird er auf eine andere Maschine verlegt, müssen alle Netzwerk-Client umkonfiguriert werden. Einen zweiter Aspekt bringen sogenannte "nomadische" Systeme, z. B. Laptops, die irgendwo ins Netz eingebunden werden sollen. Dabei bieten sich verschiedene Zugangsmöglichkeiten für Rechner in das Intranet:

Günstig wäre es, wenn der Zugang eines Rechners zum Netz folgenden Anforderungen genügen würde:

Eine Lösung für dieses Problem bietet DHCP (Dynamic Host Configuration Protocol). Dieser Dienst ermöglicht es, einem Client dynamisch eine IP-Nummer und andere Netzwerkparameter, wie den Netzwerknamen, die Gatewayadresse, etc., zuzuweisen, ohne daß der Administrator den Rechner überhaupt zu Gesicht bekommt. DHCP ist dabei völlig unabhängig von der eingesetzten Plattform. Das heißt, es kann sowohl Windows-Maschinen wie auch zum Beispiel Unix-Rechner mit den Netzwerkeinstellungen versorgen. Um ein Mindestmaß an Verfügbarkeitsanforderungen zu erfüllen, sollte natürlich mehr als nur ein DHCP-Server vorhanden sein, da sonst dessen Ausfall die Funktion sämtlicher Clienten beeinträchtigt. Im Heimnetzwerk übernimmt in der Regel schon der DSL-ROuter die Funktionen eine DHCP-Servers. Auch WLAN-Accesspoints können als DHCP-Server arbeiten.

Hinweis: Die Adressverteilung mittels DHCP wird nur für Endgeräte empfohlen. Hosts, die das Netz eigentlich bilden, wie Router, Switches, Server etc. sollten unbedingt feste IP-Adressen erhalten.

Das in RFC 2131 definierte Protokoll DHCP arbeitet nach dem Client-Server-Modell. Als Server wird ein Programm bezeichnet, das den Pool der zu vergebenden Nummern verwaltet und sich darum kümmert, daß eine Nummer nicht zweimal vergeben wird. Der Client ist ein Programm auf dem lokalen Rechner, das zunächst den Server selbsttätig im Netz suchen muß und ihn anschließend darum bittet, eine IP-Nummer zuzuteilen. Die Grundfunktion des Servers ist recht einfach aufgebaut: über eine Konfigurationsdatei teilt der Administrator ihm mit, welche Adreßbereiche er für die Weitergabe an Client zur Verfügung hat. Fragt ein Client nach einer IP-Adresse, dann muß der Server zunächst nachsehen, ob noch eine Adresse frei ist. Diese freie IP-Nummer liefert er an den Client aus. Gleichzeitig muß er eine Datei (Leases-File) führen, in der er protokolliert, welche Adresse bereits an wen vergeben ist. Bei der Adreßvergabe sind drei verschiedene Modi einstellbar:

DHCP ist eine Erweiterung des BOOTP-Protokolls und konkurriert in seiner Basisfunktionalität mit RARP. Gegenüber BOOTP zeichnet es sich vor allem durch die Flexibilität bezüglich der abfragbaren Konfigurationsparameter und durch das Konzept der Lease aus, d. h. die Möglichkeit eine Information dem Client gegenüber als nur begrenzt gültig zu markieren. Damit wird die Flexibilität bei Veränderungen der Netztopologie und weiterer Konfigurationsparameter gewahrt. Ferner ist die Unterstützung von großen Netzen, in denen nichts stets alle Systeme zugleich aktiv sind, mit limitierten Pools von Adressen möglich. Durch die Rückwärtskompatibilität zum PDU-Format von BOOTP ist die Verwendung existierender BOOTP-Relay-Agents in Subnetzen ohne DHCP-Server gewahrt.

Neben den Adressinformationen wird auch noch ein "Transaction Identifier" übertragen. Diese zufällig erstellte ID ist eine Art Bearbeitungsnummer, die eine bestimmte Transaktion (d. h. DHCP-Adressvergabe) eindeutig kennzeichnet. Insbesondere, wenn viele Clients gleichzeitig eine IP-Adresse anfordern, müssen diese Anfragen unterschieden werden können. Da noch gar keine individuellen Adressen bekannt sind, ist zu diesem Zeitpunkt eine Unterscheidung nur mittels dieser Bearbeitungsnummer möglich. Auch können neben der IP-Adresse weitere Informationen übermittelt werden, beispielsweise die Subnetzmaske, der Name der eigenen Domain, die Adresse eines Routers (Default Gateway) und die Adresse eiens Nameservers.

Bevor die IP-Adresse verwendet wird, sollte der Client ihre Einzigartigkeit durch ein Gratuitious ARP prüfen. Sollte der Client die angebotene Adresse ablehnen wollen, teilt er dies durch DHCPDECLINE-Paket dem Server und beginnt nach einer kurzen Wartefrist erneut mit Phase 1. Sobald der Client die Bestätigung durch DHCPACK erhalten hat, ist er für die Überwachung der Lease-Dauer selbst verantwortlich. Insbesondere kennt das Protokoll auch keine Methode, einem Client die Lease zu entziehen.

Nach welchen Kriterien (IP-Adressbereich, Subnetzmaske) die DHCP-Clients Adressen erhalten, muss der Netzwerkadministrator festlegen und im DHCP-Server konfigurieren. Die Adressinformationen sind zudem nicht unbegrenzt gültig, sondern müssen in regelmäßigen Abständen erneuert oder bestätigt werden. Die durch die Administratoren festgelegte Zeitdauer der Gültigkeit wird als "Lease Time" bezeichnet. Sie beträgt mehrere Stunden bis mehrere Tage.

Vor Ablauf der Lease-Dauer (meist nach der Hälfte der Zeit = 0,5 * tl) sollte der Client durch einen erneuten Durchgang durch Phase 3 versuchen, die Lease vom selben DHCP-Server verlängert zu bekommen. Gelingt ihm das nicht, kann er vor endgültigem Ablauf der Lease-Dauer (meist nach ca. 0,8 * tl) die Phase 1 nochmals durchlaufen, um eine Verlängerung bzw. Neuausstellung der Lease (eventuell von einem anderen Server) zu erhalten. Die vorzeitige Aufgabe einer Lease sollte der Client dem Server durch ein DHCPRELEASE mitteilen, um den Pool freier Adressen möglichst groß und den Vergabestand im Server möglichst akkurat zu halten. Alle Zustandsübergänge im Client sind in folgender Abbildung zusammengefaßt. Die Komplexität hat in der Vergangenheit zu einigen Fehlimplementierungen mancher Client-Software geführt, die jedoch aufgrund der großen "Toleranz" im Protokoll meist keine kritischen Auswirkungen hatten.

Der Vorgang "Lease erneuen" kann beliebig oft wiederholt werden, solange der Client die Adresse noch braucht und der Server nichts dagegen hat. Unter Umständen verweigert der DHCP-Server die Erneuerung. Falls die gewünschte Adresse für den DHCP-Server inakzeptabel ist, schickt er dem Client ein ablehnendes DHCPNAK. Der Client beginnt dann von Neuem.

Was passiert, wenn der Client den DHCP-Server nicht mehr erreichen kann, der ihm seine IP-Adresse zugeteilt hat? Bevor sein Lease verfällt, soll der Client den DHCPREQUEST nicht mehr direkt an den DHCP-Server schicken, sondern es broadcasten. Somit hören alle DHCP-Server wieder mit. Wenn Failover richtig funktioniert, wird der Backup-Server jetzt das Lease erneuen. Kommt hingegen keine Antwort oder nur ein DHCPNAK, muß der Client wieder von vorne beginnen, und ein DHCPDISCOVER broadcasten usw. Das ist insofern schlecht, als er nun höchstwahrscheinlich eine ganz andere IP-Adresse bekommt. Bestehende Verbindungen, die noch die alte IP-Adresse verwenden, müssen abgebaut werden.

Beim Einsatz spezieller IP-Geräte, z. B. f+r KNX, für Kopplung mit SPS-Systemen, für das Ansprechen von Sensoren/Messinterfaces oder für VoIP-Systeme ist jedoch die manuelle Konfiguration des DHCP-Servers oft unvermeidbar. Hier gilt es, sicher die Adressinformationen zu managen, einzuteilen und den Geräten zuzuweisen. Daher sind diese grundlegenden Kenntnisse Voraussetzung für die sichere Arbeit im IP-Netz. Deshalb kann der DHCP-Server auch eingeschränkt werden - bis hin zu einer Liste von "erlaubten" MAC-Adressen. Man kann auch eine gemischte Versorgung der Rechner im Netz vorsehen, teils mit festen IP-Adresse (z. B. Server mit "Außenwirkung"), teils mit dynamisch zugewiesenen Adressen. Teilweise sind viele der o. g. Geräte auch standardmäßig auf DHCP konfiguriert und nicht immer ist der Bediener vor Ort in der Lage, eine IP-Adresse nebst Netzmaske usw. zu konfigurieren. In solchen Fällen ist es sinnvoll, die Konfiguration auf den DHCP-Server zu verlagern.

SMTP - Simple Mail Transfer Protocol

Der urspüngliche Standard für SMTP - niedergelegt im RFC 821 - stammt aus dem Jahr 1982 und gilt, abgesehen von einigen Erweiterungen, nach wie vor. Dieser RFC 821 legte ein Minimum an Schlüsselworten fest, die jede Implementation von SMTP (d. h. die Verkörperung von SMTP in einem Programm) beherrschen muß. Dies sind:

KommandoArgumentBeschreibung
HELOSystemname Beginn, Name des sendenden Systems
MAILFrom: Absenderadresse Beginn der Übermittlung
RCPTTo: Empfängeradresse Adressat der E-Mail
DATA  Brieftext, Ende durch eine Zeile mit "."
HELPTopic Hilfestellung
VRFYMailadresse Mailadresse verifizieren
EXPNMailadresse Mailadresse expandieren (z. B. Liste)
RSET  Senden abbrechen, Zurücksetzen
NOOP  nichts tun
QUIT  Verbindung beenden

Die Verbindung eines MTA zu einem anderen läßt sich nachstellen: 

	telnet lx-lbs.e-technik.fh-muenchen.de smtp
	Trying 129.187.106.196...
	Connected to lx-lbs.e-technik.fh-muenchen.de.
	Escape character is '^]'.
	220 lx-lbs.e-technik.fh-muenchen.de Smail3.1.28.1 #1 ready at Sun, 25 Feb 96 23:15 MET
	helo www.netzmafia.de
	250 lx-lbs.e-technik.fh-muenchen.de Hello www.netzmafia.de
	mail from: paulsen@fitug.de
	250  ... Sender Okay
	rcpt to: holm@lx-lbs.e-technik.fh-muenchen.de
	250  ... Recipient Okay
	data
	354 Enter mail, end with "." on a line by itself
	Hallo Holm,
	
	zu Deiner Frage bezeglich der Reinigung von Morgensternen
	wollte ich Dir nur den Tip geben, dazu reine Kernseife zu
	verwenden.
	Damit ist die Drecksarbeit im Handumdrehen erledigt.
	
	Beste Gruesse, Paulsen
	.
	250 Mail accepted
	quit
	221 lx-lbs.e-technik.fh-muenchen.de closing connection
	Connection closed by foreign host.

Beim Verbindungsaufbau meldet sich der lokale MTA mit einer "Begrüßungszeile". Der lokale empfangende MTA wird mit "HELO" angesprochen und als sendender MTA der des Systems www.netzmafia.de angegeben. Der lokale MTA antwortet mit einem Zahlencode, der dem Sender-MTA signalisiert, daß seine geforderte Aktion in Ordnung geht. Die Klarschrift nach dem Zahlencode dient nur der besseren Lesbarkeit für den Menschen (z. B. für den, der Fehler suchen muß). Auf "MAIL FROM:" folgt die Adresse des Absenders, und auf "RCPT TO:" die des Empfängers. Auf das Schlüsselwort "DATA" folgt schließlich der ganze Brief, also sowohl die Kopfzeilen, als auch der Text. Der Empfänger-MTA wird solange Text erwarten, bis ihm der Sender-MTA über eine Zeile, die nur einen Punkt enthält, signalisiert, daß der Brief zu Ende ist. Nach der letzten Bestätigung des Empfänger-MTAs könnte der Sender den nächsten Brief übermitteln, wiederum beginnend mit "MAIL FROM:". Nach dem Empfang des Briefes kopiert der lokale MTA den Brief in die Postfach-Datei des Empfängers.

Der RFC 821 legte noch einige weitere Schlüsselworte fest, z. B. "EXPN" für expand, welches eine Unterstützung von Mailing-Listen erlaubt, oder "VRFY" für verify, mittels dessen eine Bestätigung der Empfänger-Adresse gefordert werden kann. Eine ganze Reihe von RFCs haben den Standard für SMTP erweitert. Die erweiterte Version heißt nun offiziell ESMTP (für Extended SMTP). Hinzugekommen sind beispielsweise Schlüsselworte für die Unterstützung von 8bit-Briefen (z. B. solche mit Umlauten), und die Möglichkeit eine maximale Größe für Briefe, die empfangen werden, festzulegen.

Auf Arbeitsplatzrechnern, die normalerweise nicht ständig eingeschaltet sind, erfordert E-Mail spezielle Betriebsweisen. Falls der Rechner in ein lokales Netz integriert ist, bietet sich eine Lösung über den Netzwerkserver oder einen speziellen Mail-Server an. Es gibt auch die Möglichkeit, direkt vom PC-Kompatiblen oder Macintosh auf eine Unix-Mailbox zuzugreifen. Voraussetzung dafür ist, daß der Arbeitsplatzrechner direkt mit TCP/IP am Ethernet angeschlossen ist oder über eine Modem-Verbindung per PPP-Protokoll angebunden ist. Die Mailer sind lokale Programme am PC oder Mac. Der Vorteil ist, daß man in der PC-Umgebung bleibt, und Dateien direkt aus dem PC-Directory-System versandt werden können. Die Mailbox des Benutzers liegt dabei selbst auf einem Mail-Server (Postfach). Der Zugriff vom PC auf das Mailsystem des Servers wird über den Client/Server-Mechanismus realisiert. Protokolle, die dieses erlaubt, sind POP ('Post Office Protocol') und IMAP ('Internet Message Access Protocol').

POP

POP, genauer POP 3, ist die bisher noch gebräuchlichste Methode, um E-Mails von einem Provider zu empfangen, wenn der eigene Rechner nicht ständig mit dem Internet verbunden ist. Das Prinzip und der Funktionsumfang von POP sind einfach:

Eine Kommunikation zwischen dem POP-Client und dem POP-Server beim Provider kann schematisch beispielsweise so aussehen :

Client: Hast Du neue E-Mails für mich?
Server: Ja, insgesamt fünf Stück!
Client: Liste mir die Absender auf!
Server: Meier, Mueller, Huber, Schulze
Client: Zeige die E-Mails an!
Server: ((Zeigt E-Mails an))
Client: ((Speichert E-Mails ab))
Client: Lösche alle angezeigten E-Mails
Server: ((Löscht alle angezeigten E-Mails))

Wenn ein Client über POP3 Nachrichten abrufen möchte, baut er eine TCP-Verbindung über Port 110 auf. Ist die Verbindung zustande gekommen, sendet der Server eine Begrüßungsmeldung. Die weitere Kommunikation zwischen beiden Rechnern erfolgt über Kommandos, die aus drei oder vier Zeichen langen Wörtern (mit einem oder mehreren Argumenten mit bis zu je 40 Zeichen) bestehen. Antworten enthalten einen Status-Indikator und ein Statuswort sowie optionale Informationen. Es gibt zwei Status-Indikatoren:

Eine POP3-Verbindung durchläuft mehrere Stufen. Nach der Server-Begrüßung beginnt der "Authorization State". Der Client muß sich gegenüber dem Server identifizieren. Nach erfolgreicher Authorisierung beginnt der "Transaction State". Es werden alle Operationen zum Bearbeiten von Mails ausgeführt. Sendet der Client das Kommando QUIT, beginnt der "Update State". Der Server beendet die TCP-Verbindung und führt die vom Client im "Transaction State" angeforderten Änderungen durch.

Viele POP3-Server haben zusätzlich einen Inaktivitäts-Timer. Laut Spezifikation muß dieser auf mindestens zehn Minuten eingestellt sein. Jedes Kommando des Clients setzt den Timer zurück. Ist der Timer abgelaufen, wird die TCP-Verbindung beendet, ohne in den "Update State" zu wechseln - eventuelle Änderungen werden auf dem Server nicht gespeichert.

Nachdem der POP3-Client eine Verbindung zum Server aufgebaut hat, sendet dieser eine einzeilige Begrüßungsmeldung beliebigenInhalts, z. B.: 

Server: +OK POPEL-3 server ready
Dabei handelt es sich bereits um eine Antwort des Servers, daher beginnt die Meldung immer mit einer positiven Bestätigung (+OK). Die Verbindung befindet sich nun im Zustand "Authorization". Der Client muß sich jetzt gegenüber dem Server identifizieren. Dies erfolgt über die beiden Kommandos USER und PASS.

Kommandos im "Authorization State"
KommandoArgumentBeschreibung
USERName Das Argument identifiziert eine Mailbox.
PASSString Der String enthält ein Mailbox-spezifisches Passwort.
QUIT- Beendet die Verbindung.

Die Kombination aus den Kommandos USER und PASS ist am gebräuchlichsten. Dabei werden die jeweiligen Parameter im Klartext an den Server gesendet. Ein Beispiel: Der Username für das Postfach soll "plate", das Passwort "XYZ1230" heißen. In diesem Fall wird folgender Authentifizierungsdialog ablaufen: 

Client: USER plate
Server: +OK name is a valid mailbox 
Client: PASS YXZ1230
Server: +OK plates's maildrop has 9 messages (1600 octets)
Bei falschen Angaben verweigert der Server den Zugang und gibt eine Fehlermeldung aus. Mögliche Dialoge bei falschem Usernamen: 
Client: USER plato
Server: -ERR sorry, no mailbox for plato here
Oder bei einem falschen Passwort: 
Client: USER plate
Server: +OK name is a valid mailbox 
Client: PASS tralala
Server: -ERR invalid password
Die Tatsache, daß alle Dialoge im Klartext über das Netz abgewickelt werden, birgt ein hohes Sicherheitsrisiko. Mit dem Kommando APOP sieht die aktuelle POP3-Definition eine wesentlich sicherere Option zur Authentifizierung vor. Diese beschreibt in einem Kommando den User und identifiziert ihn mit einer Einweg-Hash-Funktion.

Hat sich der Client beim Server identifiziert, wechselt die Verbindung in den "Transaction State". Dem Client stehen nun eine Reihe von Kommandos zur Behandlung der Mails zur Verfügung:

Kommandos im "Transaction State"
KommandoArgumentBeschreibung
STAT- Liefert die Anzahl der gespeicherten Mails und die Größe der Mailbox zurück (in Byte).
LISTNummer Liefert die Nummer und Größe (in Bytes) aller Mails zurück. Wird als Argument eine Mail-Nummer angegeben, wird nur die Größe dieser Mail ausgegeben.
RETRNummer Gibt die Mail mit der als Argument übergebenen Nummer aus.
DELENummer Löscht die Mail mit der übergebenen Nummer.
NOOP- Bewirkt die Antwort "+OK". Dient zur Aufrechterhaltung der Verbindung, ohne daß ein Time-Out auftritt.
RSET- Setzt die aktive Verbindung zurück. Noch nicht ausgeführte Änderungen werden verworfen.
QUIT- Beendet die Verbindung und führt alle gespeicherten Änderungen aus.

Der Server führt das Kommando DELE nicht unmittelbar aus. Die entsprechenden E-Mails werden als gelöscht markiert und erst bei Beenden der Verbindung endgültig vom Server gelöscht. Hat man eine Nachricht zum Löschen gekennzeichnet, möchte dies jedoch rückgängig machen, führt man das Kommando RSET aus. Der Server verwirft alle noch nicht ausgeführten Operationen.
Sendet der Client das QUIT-Kommando, wechselt die Verbindung in den "Update State". Der Server trennt die TCP-Verbindung und führt alle gespeicherten Änderungen aus.

Neben den hier vorgestellten, für eine minimale Implementation ausreichenden Kommandos gibt es noch weitere, die von den meisten Clients und Servern unterstützt werden. Details hierzu finden Sie in RFC1725.

Im folgenden Beispiel sehen Sie den Ablauf einer POP3-Verbindung. Der Client identifiziert sich gegenüber dem Server und ruft eine Liste der gespeicherten E-Mails ab. Danach werden die Nachrichten einzeln heruntergeladen, auf dem Server zum Löschen gekennzeichnet, und die Verbindung wird beendet. 

Server: +OK POP3 server ready
Client: user plate
Server: +OK
Client: pass xyz1230
Server: +OK
Client: LIST
Server: +OK 3 messages (520 octets)
Server: 1 120
Server: 2 190
Server: 3 210
Server: .
Client: RETR 1
Server: +OK 120 octets
Server: <... sendet Nachricht 1>
Server: .
Client: DELE 1
Server: +OK message 1 deleted
Client: RETR 2
Server: +OK 190 octets
Server: <... sendet Nachricht 2>
Server: .
Client: DELE 2
Server: +OK message 2 deleted
Client: RETR 4
Server: -ERR no such message
Client: QUIT
Server: +OK

IMAP: Internet Message Access Protocol

IMAP (genauer: IMAP, Version 4) löst das POP-Verfahren zunehmend ab und wird zum neuen Standard. Der Unterschied liegt unter anderem in der Funktionalität des IMAP-Verfahrens. Das Prinzip ist dem POP-Verfahren jedoch sehr ähnlich. Die E-Mails werden wie beim POP-Verfahren beim Provider zwischengespeichert und können mit einem IMAP-Client auf den eigenen Rechner kopiert werden. IMAP bietet jedoch zusätzliche Funktionalitäten, die von POP noch nicht angeboten werden, z. B. kann der Mail-Body getrennt geladen werden, und auch die Attachments lassen sich getrennt abrufen.
E-Mail-Client und Server tauschen bei IMAP ihre Daten über den TCP-Port 143 aus. Im Gegensatz zu den Protokollen SMTP und POP muß der Client bei IMAP nicht nach jedem gesendeten Kommando auf die unmittelbare Antwort des Servers warten. Es können mehrere Befehle hintereinander versendet werden, die jeweilige Rückmeldung vom Server kann später erfolgen. Dazu wird jedem Kommando seitens des Client eine Kennung vorangestellt, auch "Tag" genannt, zum Beispiel "X001" für den ersten Befehl und "X002" für den zweiten. Der Server kann dem Client auf mehrere Arten antworten: Mit einem Plus-Zeichen am Anfang der Zeile antwortet der Server, wenn er weitere Informationen zu dem vorangegangenen Kommando erwartet. Er signalisiert dem Client gleichzeitig seine Empfangsbereitschaft. Steht dagegen ein Sternchen am Anfang der Zeile, sendet der Server weitere Informationen an den Client zurück.

Die Antwort eines Servers kennzeichnet den Erfolg oder Fehler eines Kommandos:

Die Antwort enthält denselben Tag wie das zugehörige Kommando, damit der Client erkennt, welcher Response welchem Befehl gilt. Wie bei POP durchläuft eine IMAP-Verbindung mehrere Sitzungsstufen:

Der "Non-Authenticated State" stellt mehrere Möglichkeiten zur Identifizierung des Anwenders zur Verfügung. Es gibt in diesem Zusatand folgende Kommandos:

Kommandos im "Non-Authenticated State"
KommandoArgumentBeschreibung
AUTHENTICATEAuthentifizierungs-Mechanismus Das Kommando bestimmt den Authentifizierungs-Mechanismus, zum Beispiel "Kerberos" oder "S/Key". Details zu den Authentifizierungs-Mechanismen finden Sie in RFC1731.
LOGINName/Passwort Identifiziert den Anwender über Benutzername und Passwort.

Beispiel für eine Authentifizierung mit dem LOGIN-Kommando: 

Client: X001 LOGIN PLATE XYZ1230
Server: X001 OK LOGIN completed

Im "Authenticated State" hat sich der User authentifiziert und muß nun eine Mailbox auswählen, welche in dieser Sitzung bearbeitet werden soll. Dazu stehen unter anderem folgende Kommandos zur Verfügung:

Wichtige Kommandos im "Authenticated State"
KommandoArgumentBeschreibung
SELECTMailbox-Name Wählt eine Mailbox zur weiteren Bearbeitung aus. Als erfolgreiche Antwort sendet der Client Informationen zur gewählten Mailbox, wie beispielweise die Anzahl der gespeicherten Nachrichten.
EXAMINEMailbox-Name Identisch mit dem Kommando SELECT. Jedoch wird die Mailbox als "read-only" ausgewählt, es sind keine dauerhaften Änderungen möglich.
CREATEMailbox-Name Erstellt eine Mailbox mit dem als Argument übergebenen Namen.
DELETEMailbox-Name Löscht die als Argument übergebene Mailbox.
RENAMEBestehender Mailbox-Name / Neuer Mailbox-Name Ändert den Namen einer Mailbox.

Beispiel: Löschen einer Mailbox: 

Client: X324 DELETE TRALALA
Server: X234 OK DELETE completed

Im "Selected State" gibt es viele Kommandos zum Bearbeiten einer Mailbox:

Wichtige Kommandos im "Selected State"
KommandoArgumentBeschreibung
CLOSE- Entfernt alle zum Löschen gekennzeichneten Mails und setzt die Verbindung in den Authenticated State zurück.
EXPUNGE- Entfernt alle zum Löschen gekennzeichneten Mails, die Verbindung bleibt im Selected State.
SEARCHein oder mehrere Suchkriterien Erlaubt die Suche nach bestimmten Nachrichten in der aktuellen Mailbox. Das Kommando unterstützt logische Verknüpfungen.
FETCHGewünschte Daten einer Nachricht Bewirkt das Senden von Daten einer Nachricht vom Server zum Client.

Beispiel: Suchen einer Nachricht. Ergebnis sind die Nummern der entsprechenden Mails: 

Client: X246 SEARCH SINCE 1-NOV-2001 FROM "ADAM"
Server: * SEARCH 2 84 882
Server: X246 OK SEARCH completed

Beendet der Client mit dem Kommando LOGOUT die Verbindung, wechselt der Server in den "Update State" und führt noch anstehende Arbeiten aus.
Es gibt eine Reihe weiterer Befehle im "Authenticated State" und "Selected State", die in RFC2060 nachzulesen sind.

Im abschließenden Beispiel sehen Sie den Ablauf einer IMAP4-Verbindung. Der Client identifiziert sich gegenüber dem Server, wählt eine Mailbox aus und lädt den Header einer Nachricht herunter. 

Server: * OK IMAP4 Service Ready
Client: X001 login plate XYZ1230
Server: X001 OK LOGIN completed
Client: X002 select inbox
Server: * 12 EXISTS
Server: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
Server: * 2 RECENT
Server: * OK [UNSEEN 11] Message 11 is first new message
Server: * OK [UIDVALIDITY 2905753845] is first new message
Server: X002 OK [READ-WRITE] SELECT completed
Client: X003 fetch 9 rfc822.header
Server: * 9 FETCH (RFC822.HEADER {346}
Server: Date: mon, 11 Mar 2002 09:23:25 -0100 (MET)
Server: From: plate <plate@netzmafia.de>
Server: Subject: Schulung Netzwerke am Donnerstag
Server: To:  <schulung@ee.fhm.edu>
Server: Message-Id: <20020311104452.GH1474.plate@netzmafia.de>
Server: Mime-Version: 1.0
Server: Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Server: )
Server: X003 OK FETCH completed
Client: X004 LOGOUT
Server: * BYE IMAP4 server terminating connection
Server: X004 OK LOGOUT completed

Nachdem der Mail-Client über TCP eine Verbindung zum SMTP-Server aufgebaut hat, wartet er auf einen Begrüßungstext des Servers. Im nächsten Schritt identifiziert sich der Client mit dem Kommando LOGIN, als Argument übergibt er den Benutzernamen und das Passwort. Nach dem Auswählen der Mailbox sendet der Server einige Informationen, z. B. die Anzahl der ungelesenen Nachrichten. Mit dem Kommando FETCH fordert der Client den Header der Nachricht 9 an. LOGOUT beendet die Verbindung.

Bei Inbetriebnahme eines POP- bzw. IMAP-Clients (Outlook, Pegasus Mail, Netscape) muß dieser zunächst konfiguriert werden. Wichtige Angaben sind:

POP/IMAP dient nur zum Abholen der Post vom Mail-Server. Der Versand von E-Mail vom PC oder Mac aus geschieht ganz normal mit SMTP (Simple Mail Transfer Protocol).

FTP

Ein weiterer zentraler Dienst in einem Intranet, der besonders dem Transport von Dateien auf andere Systeme dient, ist das File-Transfer-Protokoll. Die Besonderheit des Protokolls liegt in den getrennten Kanälen für die Daten und die Steuerung. Im RFC 959 ist für FTP TCP-Port 20 als Steuerungskanal und TCP-Port 21 als Datenkanal festgelegt. FTP verwendet als Transportprotokoll immer TCP, da dieses bereits einen sicheren Datentransfer garantiert und die FTP-Software sich nicht darum zu kümmern braucht. FTP besitzt eine eigene Kommandooberfläche, die interaktiv bedient wird. Der Aufruf dieses Filetransferprogrammes erfolgt durch das Kommando ftp.
Die Vorteile von FTP liegen in den effizienten Verfahren zur Übertragung von Dateien beliebigen Formats und der Tatsache, daß der Zugriff seitens beliebiger Internet-Teilnehmern möglich ist. Andererseits kann bei größeren Archiven schnell die übersicht verlorengehen, wenn die Datenbestände nicht vernünftig sortiert sind. Bei umfangreichen Dateibäumen ist hingegen die Navigation durch die Verzeichnisse eine zeitraubende Angelegenheit. Es werden weiterhin zwei Betriebsmodi unterschieden: In beiden Fällen ist es möglich, Verzeichnisse einzusehen und zu wechseln, sowie Dateien zu empfangen und zu senden. Der Unterschied liegt in den Privilegien, die ein Benutzer besitzt. Während im ersten Fall der User eine Zugangsberechtigung zum System benötigt, so verfügt ein Gastzugang nur über eine eingeschränkte Sicht auf den Datenbereich des Servers, was als einfacher Sicherheitsmechanismus anzusehen ist.

Der Kommandoaufruf des FTP-Kommandos lautet

ftp [ -v ] [ -d ] [ -i ] [ -n ] [ -g ] [ host ]

Wird beim Programmaufruf der gewünschte Kommunikationspartner (host) mit angegeben, so wird sofort versucht, eine Verbindung zu diesem Rechensystem aufzubauen. Ist der Versuch erfolglos, so wird in den Kommandomodus umgeschaltet. Der Prompt "ftp>" erscheint immer auf dem Bildschirm, wenn ftp-Kommandos eingegeben werden können. ftp verfügt über einen help-Mechanismus, über den sämtliche auf dem jeweiligen System verfügbare Kommandos mit Kurzerklärungen abfragbar sind.
Nachfolgend werden wesentliche Kommandos nach Funktionalität gruppiert vorgestellt. Kommandos können soweit verkürzt eingegeben werden, als sie noch eindeutig erkennbar sind. Enthalten Kommandoargumente "Blanks", so sind die Argumente beidseitig mit Hochkommas eingeschlossen einzugeben. Nicht alle ftp-Implementierungen unterstützen alle ftp-Kommandos.

Die optionalen Parameter beim ftp-Kommando setzen logische Schalter für den ftp-Programmlauf. Im Kommandomodus sind die Einstellungen jederzeit wieder änderbar.

Die Datei-Übertragung wird durch die Terminal "interrupt"-Taste (üblicherweise Ctrl-C) abgebrochen, was einen sofortigen Abbruch zur Folge haben soll. Nicht alle Kommunikationspartner verstehen die Abbruchaufforderung, wodurch dennoch die gesamte Datei übertragen wird.

Dateinamen, die als Argumente von FTP-Kommandos Verwendung finden, werden wie folgt bearbeitet: Ist "file globbing" eingeschaltet, werden bei den Kommandos mget, mput und mdelete die Namen lokaler Dateien folgendermaß behandelt:

Kommandos und Protokoll-Anweisungen:

ftp-ClientFTP-ProtokollAufgabe
loginUSER username
PASS password		anmelden
help
help command		HELP
HELP command		Hilfe
 SYSTServer-Identifikation
statusSTATTransfer-Status
 STAT pathwie LIST, über control-Verbindung
dir pathLIST pathKataloginhalt zeigen, ausführlich
ls pathNLST pathDateinamen zeigen
delete pathDELE pathDatei löschen
rename from toRNFR from-path
RNTO to-path		Datei umbenennen
pwdPWDArbeitskatalog zeigen
cd pathCWD pathKatalog wechseln
mkdir pathMKD pathKatalog erzeugen
rmdir pathRMD pathKatalog löschen
asciiTYPE A NTextübertragung (Voreinstellung)
binaryTYPE IDatenübertragung
 PORT h,h,h,h,p,pPort des Klienten für data-Verbindung
get remote-pathRETR pathDatei zum Klienten übertragen
put local-pathSTOR pathDatei zum Server übertragen
append local-pathAPPE pathan Datei auf Server anfügen
interruptABOR_bertragung abbrechen
quitQUITVerbindung beenden

Beispiel

Benutzereingaben sind fett gedruckt. 
ftp multimedia.ee.fhm.edu
Verbindung mit multimedia.ee.fhm.edu.
220 ProFTPD 1.2.2rc2 Server [multimedia.e-technik.fh-muenchen.de]
Benutzer (multimedia.ee.fhm.edu:(none)): plate
331 Password required for plate.
Kennwort:
230 User plate logged in.
Ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
tmp
Mail
bin
226 Transfer complete.
Ftp: 36 Bytes empfangen in 0.00Sekunden 36000.00KB/Sek.
Ftp> cd tmp
250 CWD command successful.
Ftp> lcd E:\www-netzmafia\skripten\perl
Lokales Verzeichnis jetzt E:\www-netzmafia\skripten\perl.
Ftp> cd /opt/www/skripten/perl
250 CWD command successful.
Ftp> put perl3.html
200 PORT command successful.
150 Opening ASCII mode data connection for perl3.html.
226 Transfer complete.
Ftp: 77604 Bytes gesendet in 9.17Sekunden 8.46KB/Sek.
Ftp> put perl4.html
200 PORT command successful.
150 Opening ASCII mode data connection for perl4.html.
226 Transfer complete.
Ftp: 30930 Bytes gesendet in 3.24Sekunden 9.55KB/Sek.
Ftp> quit

Active und Passive FTP

Beim FTP-Zugriff werden zwei Modi unterschieden, active und passive FTP. Beim active mode FTP öffnet der Client eine Verbindung von einem unprivilegierten Port (Portnummer N > 1023) zum Kommandoport 21 des FTP-Servers. Dann spezifiziert der Client den Port N+1 als Datenport (PORT-Kommando). Der Server schickt seine Daten an den spezifizierten Port des Client von seinem Port 20 aus. Aus Sicht eines vorgeschalteten Firewall-Systems müssen demnach folgende Ports offen sein: Sperrt ein Firewall im Netz des Client den Verbindungsaufbau von außen, ist keine Datenübertragung möglich (wohl aber die Kommandoverbindung).

Zur Lösung dieses Problems kann der FTP-Client mit dem Befehl PASV in das passive mode FTP umgeschaltet werden. Der Client initiert nun Kommando- und Datenverbindung. Nach dem Umschalten in den passiven Modus, bietet der Server einen unprivilegierten Port > 1023 an, den der Client dann für den Datentransfer ansprechen kann. Aus Sicht eines vorgeschalteten Firewall-Systems müssen demnach folgende Ports offen sein:

Wenn auch nun die Probleme auf der Cleintseite gelöst sind, sind sie nun auf der Serverseite vorhanden. Der FTP-Server muß im Passivmodus alle Verbindungen von anderen Systemen auf Ports > 1023 zulassen. Um hier die Sicherheit zu verbessern, kann man bei etlichen Serverprogrammen den Portbereich per Konfiguration einschränken.

Manche FTP-Clients können nicht in den Passivmodus schalten, es bleibt dann nur die Wahl eines anderen Programms. Dagegen können die Webbrowser im Passivmodus arbeiten (und tun dies meist per Default).

HTTP - Hypertext Transfer Protocol

HTTP ist ein Protokoll der Applikationsschicht, das alle Möglichkeiten der Übertragung von Hypermedia-Informationen bietet. HTTP ist nicht Hardware- oder Betriebssystemabhängig. Seit 1990 ist dieses Protokoll im Einsatz und wird derzeit meist in der Version 'HTTP/1.1' (seltener 1.0) verwendet.

Heutige Informationssysteme benötigen weit mehr Funktionen als das einfache Senden und Empfangen von Nachrichten. Die Entwicklung von HTTP ist nicht abgeschlossen. Es bietet die Möglichkeit, weitere Funktionalität zu entwickeln. Die Adressierung von Ressourcen erfolgt dabei mittels URls, die zum einen Orte (URL) oder Bezeichner (URN) sein können. Diese zeigen gleichzeitig den gewünschten Übertragungsmechanismus an. Nachrichten werden in der gleichen Form übertragen, wie sie auch bei normalem Mail-Transport verwandt werden. Dabei kommt oft MIME zum Einsatz. HTTP/1.1 ist auch für den Zugriff auf Server mit anderen Protokollen geeignet.

Hauptfunktionen des HTTP

Die grundlegende Funktionsweise des HTTP folgt dem alten Frage-Antwort-Spiel. Ein fragendes Programm (WWW-Browser) öffnet eine Verbindung zu einem Programm, welches auf Fragen wartet (WWW-Server) und sendet ihm die Anfrage zu. Die Anfrage enthält, die Fragemethode, die URL, die Protokollversion, Informationen über den Dienst und möglicherweise etwas Inhalt in Form einer Nachricht. Der Server antwortet auf diese Frage mit einer Statusmeldung, auf die eine MIME-artige Nachricht folgt, die Informationen über den Server und eventuell schon das gefragte Dokument enthält.

Direkt nach Beantwortung der Frage wird die Verbindung wieder abgebaut. So soll erreicht werden, daß die Leitungskapazitäten geschont werden. Derzeit finden HTTP-Verbindungen meist per TCP/IP statt. Das soll aber nicht heißen, daß HTTP nicht auch auf anderen Netzwerkprotokollen aufsetzen kann. Beide Seiten müssen auch dazu in der Lage sein, auf den vorzeitigen Abbruch der Kommunikation durch die andere Seite zu reagieren. Vorzeitiger Abbruch kann durch Aktionen von Benutzern, Programmfehler oder Überschreiten der Antwortzeiten ausgelöst werden. Durch den Abbruch der Verbindung durch eine der beiden Seiten wird der gesamte Vorgang abgebrochen.

Struktur der HTTP-Botschaften

Jede Kommunikation zwischen zwei WWW-Programmen besteht aus HTTP-Botschaften, die in Form von Anfragen und Antworten zwischen Client und Server ausgetauscht werden. Eine HTTP-Botschaft (HTTP-Message) kann entweder ein Simple-Request, eine Simple-Response, ein Full-Request oder eine Full-Response sein. Die beiden zuerst genannten Botschaftstypen gehören zum HTTP/0.9-Standard. Die beiden letzten Typen gehören schon zum HTTP/1.0.

Allgemeinfelder des Botschaftskopfes

Jedes der Felder eines HTTP-Botschaftenkopfes weist die gleiche Struktur auf. Im RFC 822 wurde definiert, daß jedes Feld mit einem Feldnamen und dem Feldinhalt erscheint. Auf den Feldnamen muß unbedingt ein Doppelpunkt folgen. Der Feldname kann alle Zeichen außer dem Doppelpunkt und der Escape-Sequenzen enthalten. Allgemeinfelder enthalten Informationen wie das Datum, die Message-ID, die verwendete MIME-Version und ein 'forwarded'-Feld, das angibt, ob das Dokument eigentlich von einer anderen Adresse stammt.

Anfragen

Bei Anfragen wird zwischen einfachen und komplexen Anfragen unterschieden. Eine einfache Anfrage besteht nur aus einer Zeile, die angibt, welche Information gewünscht wird. Ein Beispiel: 

     GET http://www.netzmafia.de/index.html

Dabei wird nur die Methode (GET) und die URL des Dokumentes angegeben. Es werden keine weiteren Felder erwartet und vom adressierten Server wird auch nur ein ganz einfacher Antwortkopf zurückgesendet. Es kann aber auch eine komplexere Anfrage erzeugt werden. Dabei muß die Zeile aus dem obigen Beispiel noch die Version des HTT-Protokolls angehängt werden. In einem Beispiel würde das folgendermaßen aussehen: 

     GET http://www.netzmafia.de/index.html HTTP/1.0

Die Anfügung der HTTP-Version ist also der ganze Unterschied zwischen einer einfachen und einer komplexen HTTP-Anfrage. Der Unterschied zwischen einfacher und komplexer Anfrage wird aus Gründen der Kompatibilität gemacht. Ein Browser, der noch das alte HTTP/0.9 implementiert hat, wird nur eine einfache Anfrage losschicken können. Ein neuer Server muß dann eine Antwort, auch im Format des HTTP/0.9 zurücksenden.

Felder einer komplexen Anfrage

Um die Anfrage näher zu spezifizieren, wurden weitere Felder eingeführt. In den Anfragefeldern stellen z. B. Informationen über den Server und den benutzten Browser. Weiterhin kann man dort Informationen über den Gegenstand der Übertragung bekommen. In der folgenden kurzen Übersicht sind alle möglichen Felder einer Anfrage aufgeführt.

Fragemethoden

Das an erster Stelle in einer Anfragezeile (Request-Line) stehende Wort beschreibt die Methode, die mit der nachfolgenden URL angewendet werden soll. Die Methodennamen müssen dabei immer groß geschrieben werden. Der Entwurf des HTTP-Standards erlaubt leicht eine Erweiterung. Kommen wir nun zur Bedeutung der einzelnen Methoden.

Beispiel einer Konversation

Benutzereingaben werden kursiv geschrieben. Das lokale System ist eine Windows-Kiste. 

 
plate@lx3-lbs:~ > telnet www.netzmafia.de 80
Trying 141.39.253.210...
Connected to www.netzmafia.de.
Escape character is '^]'.
GET /index.html HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 18 Sep 2000 13:59:58 GMT
Server: Apache/1.3.6 (Unix)  (SuSE/Linux)
Last-Modified: Tue, 29 Aug 2000 08:08:58 GMT
ETag: "134015-8e8-39ab6f9a"
Accept-Ranges: bytes
Content-Length: 2280
Connection: close
Content-Type: text/html

<HTML>
<HEAD>
<TITLE>Netzmafia</TITLE>
</HEAD>

<body bgcolor="#000000" text="#FFFFCC" link="#FFCC00" 
       alink="#FF0000" vlink="#FF9900">

       ...


</BODY>
</HTML>
Connection closed by foreign host.