Grundlagen Computernetze Prof. Jürgen Plate

Höhere Protokolle

DHCP

• Anschluß über einen Ethernet-Switch
• Zugang durch drahtlose Netze (und evtl. einen Router zum drahtlosen Subnetz)
• Zugang vom Internet über eine Firewall
• Modemzugang über einen Modemserver

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

• automatisiert, d. h. ohne manuellen Eingriff
• authentifiziert, d. h. nur zugelassene Systeme erhalten Zugriff
• vollständig (Netz-, System- und Anwendungskonfiguration)
• standardisiert, d. h. für alle Systeme in einheitlicher Form

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:

• Automatic Allocation: Fordert ein Client eine IP-Nummer an, wird sie ihm auf unbegrenzte Zeit zugeteilt, solange noch Adressen zur Verfügung stehen. Sind alle Adressen verbraucht, kann kein neuer Client mehr konfiguriert werden, auch wenn ein Teil der zuvor bedienten Rechner im Moment gar nicht eingeschaltet ist.
• Manual Allocation: In dieser Betriebsart geht es nur darum, Verwaltungsaufwand zu minimieren. In der Konfigurationsdatei ist für jeden Client im Netzwerk eine IP-Nummer fest zugeordnet. Der Server ist lediglich für die Auslieferung der Adresse an den Client verantwortlich.
• Dynamic Allocation: Jeder Client bekommt auf Anfrage eine IP-Nummer, solange im definierten Pool noch Einträge frei sind. Der Unterschied gegenüber der Automatic Allocation besteht darin, daß die IP-Nummer nur für eine bestimmte, maximale Zeitspanne (Lease-Time) gültig ist und vom Client innerhalb dieser Zeit zurückgegeben werden kann, wenn sie nicht mehr benötigt wird. Als einzige der drei Betriebsarten erlaubt Dynamic Allocation, kleine IP-Nummern-Pools mit einer großen Anzahl von Rechnern zu teilen. Einzige Voraussetzung: nicht alle Maschinen dürfen gleichzeitg laufen. Damit lassen sich auch Computer, die eher selten ins Netzwerk integriert werden, wie Laptops, zuverlässig mit einer IP-Nummer versorgen. Wird der Rechner vom Netz getrennt, kann die Adresse für eine andere Station verwendet werden. In dieser Betriebsart werden die meisten DHCP-Server betrieben.

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.

• Der DHCP-Client, der eine IP-Adresse braucht, sendet ein DHCPDISCOVER-Paket an einen DHCP-Server. Da die Adresse des Servers noch nicht bekannt ist, wird dieses IP-Paket an die Broadcast-Adresse 255.255.255.255 mit der Absender-Adresse 0.0.0.0 geschickt (Phase 1).
• Anhand der Identifikation des Client im Paket können sich einige (oder ein einzelner) DHCP-Server entscheiden, dem Client die gewünschte IP-Adresse sowie andere Konfigurationsinformation in Form eines DHCPOFFER-Pakets zuzuteilen. (Vor der Vergabe können und sollten die Server die Konfliktfreiheit bzgl. der Adresse mittels ICMP-Ping oder ARP prüfen.) Der DHCP-Server antwortet ebenfalls mittels Broadcast. In diesem Angebot werden dem Client eine gültige IP-Adresse und weitere IP-Netzinformationen mitgeteilt (Phase 2).
• Der Client kann sich nun aus den Antworten eine für ihn geeignete aussuchen und bestätigt dies gegenüber dem Server durch ein DHCPREQUEST-Paket (Phase 3). Entscheidungsparameter können z. B. die Leasedauer (t_l) oder die Menge der angebotenen Konfigurationsinformation.
• Bei korrekter Information im DHCPREQUEST bestätigt der Server die Lease durch ein DHCPACK-Paket (Acknowledge), womit die Konfiguration abgeschlossen ist (Phase 4).

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 * t_l) 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 * t_l) 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

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

• Die für den Empfänger bestimmten E-Mails landen beim Provider im Spool-Verzeichnis und müssen dort vom Empfänger abgeholt werden.
• Der Provider stellt einen POP-Server zur Verfügung, welcher die Schnittstelle des POP-Clients auf dem Empfänger-Rechner darstellt. Der lokale POP-Client kommuniziert mit dem POP-Server beim Provider. Über ihn werden die vorhandenen E-Mails angeboten.

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:

• Positiv: +OK
• Negativ: -ERR

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

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)

Client: USER plato
Server: -ERR sorry, no mailbox for plato here

Client: USER plate
Server: +OK name is a valid mailbox 
Client: PASS tralala
Server: -ERR invalid password

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:

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

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

• OK (Kommando erfolgreich ausgeführt),
• NO (Fehler beim Ausführen) oder
• BAD (Protokoll-Fehler: Kommando unbekannt oder Syntax-Fehler).

• Non-Authenticated State: Unmittelbar nach dem Aufbau der Verbindung. Der User muß sich gegenüber dem Server identifizieren.
• Authenticated State: Der User hat sich erfolgreich identifiziert und muß nun eine Mailbox auswählen.
• Selected State: Eine Mailbox wurde ausgewählt. Mailbox und Mails lassen sich bearbeiten.
• Logout State: Die Verbindung wird beendet; der Server führt noch anstehende Tätigkeiten aus.

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

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:

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:

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:

• Domainname des POP- bzw. IMAP-Servers, d.h. Systems, auf dem die eigentliche Mailbox liegt.
• Benutzernummer auf diesem System
• Paßwort für diese Benutzernummer
• für den Versand: Angabe des SMTP-Mail-Relayhosts

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

• Benutzerspezifisches FTP
• Anonymous-FTP

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.

• help [ kommando ]
  zeigt kurze Informationen zu dem angegebenen Kommando. Wird das Kommando weggelassen, zeigt dieser Aufruf eine Liste der zulässigen Kommandos.
• open host
  Öffne einer Verbindung zu einem fernen Host. Je nach angewähltem System werden Benutzerkennung und Passwort abgefragt.
• user user-name [ password ]
  Eingabe von Benutzerkennung und Passwort.
• !
  Aufruf einer (eingeschränkten) Shell auf dem lokalen System. Für Dateiübertragung relevante Kommandos wie mkdir, mv, cp, etc sind absetzbar. Verlassen wird diese Shell mit "exit".
• lcd [directory ]
  Wahl des lokalen Directories für die Dateiübertragung.
• pwd
  Anzeige des aktuellen Directories auf dem entfernten System.
• cd remote-directory
  Wahl des aktuellen Directories auf dem entfernten System.
• cdup
  Wechsel in das nächsthöhere Directory auf dem entfernten System.
• dir [ remote-directory [ local-file ] ]
  ls [ remote-directory [ local-file ] ]
  Ohne Optionen erfolgt eine Anzeige der Einträge des entfernten aktuellen Directories. Dabei liefert dir ausführliche und ls eine knappe Information bezüglich des Directory-Inhalts.
  Bei Angabe des remote-directory erfolgt die Anzeige der Einträge des entfernten Directories. Wird local-file angegeben, erfolgt eine Umlenkung der Directory-Anzeige in die Datei local-file auf dem lokalen System.
• mdir remote-files [ local-file ]
  mls remote-files [ local-file ]
  Anzeige von Dateien aus dem entfernten aktuellen Directory und Abspeicherung in eine lokale Datei.
• mkdir directory-name
  Einrichten eines neuen Directories directory-name auf dem entfernten System.
• rmdir directory-name
  löscht das Directory directory-name auf dem entfernten System.
• rename [ from ] [ to ]
  Umbenennen einer Datei auf dem entfernten System von from nach to.
• delete remote-file
  Löschen der Datei remote-file auf dem entfernten System.
• mdelete remote-files
  Löschen mehrerer Dateien remote-files auf dem entfernten System.
• put local-file [ remote-file ]
  send local-file [ remote-file ]
  Dateiübertragung der Datei local-file vom lokalen zum entfernten System. Wird remote-file nicht angegeben, so wird auch auf dem Zielsystem der Dateiname local-file verwendet.
• append local-file [ remote-file ]
  überträgt die Datei local-file vom lokalen System an das entfernte System und hängt diese am Ende der Datei remote-file an. Wurde remote-file nicht angegeben, wird die Datei ans Ende der Datei local-file auf dem entfernten System angehängt.
• mput local-files
  Dateiübertragung einer Dateigruppe namensgleich vom lokalen zum entfernten System.
• get remote-file [ local-file ]
  recv remote-file [ local-file ]
  Dateiübertragung einer Datei remote-file vom entfernten System zum lokalen System. Wird local-file nicht mitangegeben, so erhält die Datei auch auf dem lokalen System den Dateiname remote-file.
• mget remote-files
  Dateiübertragung einer Dateigruppe namensgleich vom entfernten zum lokalen System.
• ascii
  type ascii
  Die Dateiübertragung findet im ASCII-Code statt. Gegebenfalls werden bei Binärdateien Zeichen verändert (z. B. die Zeilenendedarstellung ans Zielsystem angepaßt) oder Zeichen verfälscht.
• binary
  type image
  type binary
  Die Dateiübertragung findet transparent statt.
• case
  Mit diesem Schalter läßt sich einstellen, ob Dateinamen beim Empfangen (get, recv, mget) von Großbuchstaben nach Kleinbuchstaben übersetzt werden sollen.
• glob
  Mit diesem Schalter läßt sich einstellen, ob bei den Kommandos mdelete, mget und mput bei Dateinamen, die Metazeichen (*?[]~{}) enthalten, diese Metazeichen übertragen werden oder nicht. ("off" = keine Metazeichenbehandlung).
• ntrans [ inchars [ outchars ] ]
  Definition und Aktivierung einer Übersetzungstabelle für Dateinamen, wenn beim Dateiübertragungsauftrag (Senden und Empfangen) keine Zieldateinamen angegeben werden. Zeichen eines Dateinamens, die in inchars zu finden sind, werden durch das positionsgleiche Zeichen in outchars übersetzt. Ist inchars länger als outchars, so werden die korrespondenzlosen Zeichen von inchars aus dem Zieldateinamen entfernt.
• prompt
  Mit diesem Zeichen wird bei Mehrdateienübertragung gesteuert, ob jede zu übertragende Datei extra quittiert werden muß oder nicht.
• verbose
  Wenn der "verbose"-Modus eingeschaltet ist, erhält man für jede übertragene Datei den Dateinamen auf dem lokalen und entfernten Rechner, sowie die Datenmenge und die dafür benötigte Übertragungszeit angezeigt.
• bell
  Dieser Schalter bewirkt, daß je nach Stellung am Ende jedes Dateiübertragungsauftrages ein akustisches Signal ertönt oder nicht.
• status
  Anzeige der aktuellen logischen Schalterstellungen sowie des Verbindungszustandes.
• close
  disconnect
  Beendigung einer aktiven Verbindung.
• quit
  Beendigung des Programmes ftp.
• bye
  Beendigung einer aktiven Sitzung und des Programmes ftp.

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

• -v verbose-Schalter einschalten.
• -d debug-Schalter einschalten.
• -i interactive-Modus für Mehrdateiübertragung einschalten.
• -n verhindert, daß FTP zum Beginn der Sitzung einen Login-Versuch unternimmt.
• -g glob-Schalter einschalten.

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:

• Der * steht für eine beliebige Anzahl (auch Null) von Zeichen.
• Das ?steht für ein einziges beliebiges Zeichen.
• Wird im Dateinamen eine Zeichenfolge angetroffen, die zwischen eckigen Klammern oder zwischen geschweiften Klammern steht, so sind alle Dateinamen zutreffend, die an dieser Stelle ein einziges beliebiges Zeichen aus der Zeichenfolge innerhalb der Klammern enthalten.
• Steht die Zeichenfolge ~/ (Tilde, Schrägstrich) am Beginn des Dateinamens, so wird sie durch den Home-Directory-Pfad ersetzt. Das Zeichen ~, dem eine Benutzerkennung folgt, wird durch den Home-Directory-Pfad dieser Benutzerkennung ersetzt.

Kommandos und Protokoll-Anweisungen:

Beispiel

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

• FTP Serverport 21 von allen Ports ausserhalb (Client initiert die Verbindung)
• FTP Serverport 21 an Ports > 1023 (Server-Antwort auf Kommandos)
• FTP Serverport 20 an Ports > 1023 (Datenverbindung, Aufbau von Serverseite)
• FTP Serverport 20 von Ports > 1023 (Datenverbindung, Bestätigung vom Client)

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:

• FTP Serverport 21 von allen Ports ausserhalb (Client initiert die Verbindung)
• FTP Serverport 21 an Ports > 1023 (Server-Antwort auf Kommandos)
• FTP Serverport > 1023 von überall (Datenverbindung, Aufbau von Clientseite)
• FTP Serverport > 1023 an Ports > 1023 (Datenverbindung, Bestätigung vom Server)

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

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

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

Allgemeinfelder des Botschaftskopfes

Anfragen

     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

• Anfragezeile (Request-Line)
  Informationsanfrage wie oben geschildert. Die zugehörigen Methoden folgen im nächsten Abschnitt.
• Allgemeiner Kopf (General-Header)
  Im allgemeinen Kopf werden allgemeine Informationen über die Nachricht übermittelt.
• Anfragekopf (Request-Header)
  In diesen Feldern kann der Browser weitere Informationen über die Anfrage und über den Browser selbst absetzen. Diese Felder sind optional und müssen nicht erscheinen.
• Gegenstandskopf (Entity-Header)
  In diesem Feld werden Einträge übermittelt, welche den Inhalt der Nachricht näher beschreiben.
• Gegenstand der Nachricht (Entity-Body)
  Vor dem eigentlichen Inhalt muß definitionsgemäß eine Leerzeile stehen. Der Inhalt ist dann in dem Format codiert, das in den Gegenstandsfeldern definiert wurde (meist HTML).

Fragemethoden

• GET
  Diese Methode gibt an, daß alle Informationen, die mit der nachfolgenden URL beschrieben werden, zum rufenden Client geholt werden sollen. Zeigt die URL auf ein Programm (CGI-Script), dann soll dieses Programm gestartet werden und die produzierten Daten liefern. Handelt es sich bei dem referenzierten Datum um eine Datei, dann soll diese übertragen werden. Beispiel:

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

• HEAD
  Diese Methode ist identisch zur Methode GET. Die Antworten unterscheiden sich nur darin, daß bei der Methode GET ein komplettes Dokument übertragen wird und bei HEAD nur die Meta-Informationen gesendet werden. Dies ist nützlich, um Links auszuprobieren oder um die Erreichbarkeit von Dokumenten zu testen. Bei Anwendung der Methode HEAD wird der Kopf des referenzierten HTML-Dokuments nach 'link' und 'meta' Elementen durchsucht.

• POST
  Diese Methode wird hauptsächlich für größere Datenmengen verwandt. Man stelle sich vor, ein HTML-Dokument enthält ein komplexes Formular. Per POST wird dem Server angezeigt, daß er auch die Daten im Körper der Botschaft bearbeiten soll.
  Verwendet, wird es hauptsächlich bei Datenblöcken, die zu einem verarbeitenden Programm übertragen werden. Die wirkliche Funktion, die durch POST auf dem adressierten Rechner angestoßen wird, wird durch die URL bestimmt. Meist, sind es CGI-Scripte, die den Inhalt der Nachricht verarbeiten.

• PUT
  Die mit der Methode PUT übertragenen Daten sollen unter der angegeben URL gespeichert werden. Das soll ermöglichen, daß WWW-Seiten auch ohne direkten Zugriff auf den anbietenden Rechner erstellt und angeboten werden können. Wird ein Dokument mit der Methode PUT übertragen, dann wird unter dieser Adresse ein Dokument mit dem übertragenen Inhalt angelegt. War die Aktion erfolgreich, wird die Meldung '200 created' zurückgegeben. Existiert unter dieser Adresse schon ein Dokument, dann wird dieses überschrieben. War auch diese Aktion erfolgreich, dann wird nur '200 OK' zurückgemeldet.
  Der Hauptunterschied zwischen POST und PUT besteht darin, daß bei POST die URL eine Adresse eines Programmes referenziert, das mit den Daten umgehen kann. Bei PUT hingegen wird die URL als neue Adresse des Dokumentes gesehen, das gerade übertragen wurde. Meist jedoch ist die Methode PUT ausgeschaltet, weil Server-Betreiber befürchten, daß die Sicherheit, des Systems dadurch nicht mehr gewährleistet ist.

• DELETE
  Mit dieser Methode kann der Inhalt einer URI (Unified Resource Identifier) gelöscht werden. Diese Methode ist neben der Methode PUT eine der gefährlichsten. Wenn Server nicht richtig konfiguriert wurden, dann kann es mitunter vorkommen, daß alle Welt die Berechtigung zum Löschen von Ressourcen hat.

• LINK
  Mit dieser Methode können eine oder mehrere Verbindungen zwischen verschiedenen Dokumenten erzeugt werden. Es werden dabei keine Dokumente erstellt, sondern nur schon bestehende miteinander verbunden.

• UNLINK
  entfernt Verbindungen zwischen verschieden Ressourcen. Dabei wird nur die Verbindung gelöscht. Die Dokumente existieren trotzdem weiter. Mit diesen Methoden kann man alle möglichen Ressourcen erreichen, welche die verschiedenen Server zur Verfügung stellen. Die folgenden Felder beschreiben nun die Fragen etwas genauer. Es kann zum Beispiel verhindert werden, daß ungewollt umfangreiche Bilder übermittelt werden, wenn dies nicht gewünscht wird.

Beispiel einer Konversation

 
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.

Zum vorhergehenden Abschnitt

Zum Inhaltsverzeichnis

Zum nächsten Abschnitt

Copyright © Hochschule München, FK 04, Prof. Jürgen Plate
Letzte Aktualisierung: