Höhere Protokolle
Werbung
Quelle: http://www.netzmafia.de/skripten/netze/netz9.html Grundlagen Computernetze Prof. Jürgen Plate 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 und RADIUS 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: Anschluß über einen Ethernet-Hub oder -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. 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 IPNummer 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. Beim Start des Systems schickt der Client ein DHCPDISCOVER-Paket in Form eines Broadcasts an 255.255.255.255 (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 Client kann sich in Phase 2 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 (tl) oder die Menge der angebotenen Konfigurationsinformation. Bei korrekter Information im DHCPREQUEST bestätigt der Server die Lease durch ein DHCPACK-Paket, womit die Konfiguration abgeschlossen ist 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. 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 LeaseDauer (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übergange im Client sind in folgender Abbildung zusammengefaßt. Die Komplexität hat in der Vergangenheit zu einigen Fehlimplementierungen mancher ClientSoftware 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. Es darf natürlich nicht jeder beliebige Rechner Zugang zum LAN erhalten. Deshalb kann der DHCP-Server auch eingeschränkt werden - bis hin zu einer Liste von "erlaubten" MACAdressen. 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. Remote-Zugang mit RADIUS Der Zugang zum Netz über Wählleitungen (analoges Telefon, ISDN, xDSL) erfolgt normalerweise über einen oder mehrere Remote Access Server (RAS), in Einzelfällen auch über einen Rechner mit angeschlossenem Modem, ISDN-Karte oder xDSL-Anschluß. Deren Aufgabe ist es, ankommende digitale oder analoge Anrufe entgegenzunehmen, eine Benutzerauthorisierung durchzuführen und, falls diese erfolgreich war, die Verbindung des anrufenden Rechners mit dem internen Datennetz freizugeben. Der ferne Rechner verhält sich dann so, als ob er direkt am Datennetz angeschlossen wäre. Als Übertragungsprotokoll wird in der Regel PPP (Point to Point Protokoll, erlaubt IP- und IPX-Verbindungen), SLIP (Serial Line Internet Protokoll, veraltet, nur für IP-Verbindungen) und ggf. ARAv2 (Apple Remote Access Version 2) angeboten. Ein spezieller Terminalserver-Modus gestattet es, sich mit einem normalen Terminalprogramm (z.B. Hyperterminal, Kermit, usw.) auf dem Access-Server anzumelden und von dort aus Telnetverbindungen aufzubauen. IP-Adressen werden normalerweise aus einem IP-Adresspool vergeben. Oft werden auch "virtuelle Verbindungen" unterstützt. Diese erlauben den physikalischen Abbau von Verbindungen, wenn gerade keine Daten übertragen werden, ohne daß die logische Verbindung verloren geht. Die Verbindung wird automatisch mit den gleichen Parametern wie vorher wieder aufgebaut, wenn Daten wieder übertragen werden müssen. Für die standardisierte Authentifizierung am Modem- und Internetzugang setzt sich zunehmend das RADIUS-Protokoll (Remote Authentication and Dial-In User Service) durch. Seine Client-Proxy-Server-Architektur erlaubt die flexible Positionierung an Netzzugangspunkten und wird von fast allen Herstellern von Modemservern unterstützt. In Kombination mit DHCP und PPP ist die Aufgabe der Konfiguration der anwählenden Endsysteme in automatisierter Weise gelöst. Der Radius-Server ist ein zentraler Authentifizierungs-Server, an den sich alle RA-Server wenden. Auf diese Weise lassen sich unabhängig von der Netz-Infrastruktur alle Remote-User zentral verwalten und Benutzerprofile mit Zugangsrestriktionen definieren, aber auch zusätzliche Sicherheitsverfahren vorsehen. Beispielsweise kann festgelegt werden, dass der Nutzer nur nach einem Rückruf durch den Einwahlknoten an eine zuvor vereinbarte Rufnummer Zugriff auf das Unternehmensnetzwerk bekommen darf. Diese Informationen übergibt der RadiusServer an den RA-Server, der das weitere Login entsprechend koordiniert. Der Vorteil dieses Verfahrens liegt in den einmalig generierten Zugangsdaten der Nutzer, die auch in verteilten Netzwerken jederzeit aktuell verfügbar sind und mit einfachen administrativen Eingriffen an zentraler Stelle definiert und verändert werden können. Darüber hinaus ist die innerbetriebliche Abrechnung der Nutzung des Systems durch ein entsprechendes Accounting möglich. Das Radius-Protokoll setzt auf UDP auf. Die Struktur eines Radius-Pakets ist ausgesprochen einfach. Es besteht aus fünf grundlegenden Elementen: einem Radius-Code, einem Identifier, einer Angabe zur Paketlänge, einem Authenticator und gegebenenfalls aus einer Reihe von Attributen. Der Radius-Code beschreibt die Aufgabe des Datenpakets. Aufbau des Radius-Pakets Die Codes 1, 2 und 3 verwalten den reinen Access vom Request bis zur Bestätigung oder Abweisung. Die Codes 4 und 5 dienen dem Accounting. Der Identifier ist acht Bit lang und dient der Zuordnung von Anfragen und Antworten. Das sicherheitstechnisch wichtigste Feld eines Radius-Rahmens ist der Authenticator, der eine Länge von 16 Oktetts beziehungsweise vier 32-Bit-Worten hat. Dabei wird zwischen dem Request Authenticator und dem Response Authenticator unterschieden. Inhalt des Request Authenticators ist eine Zufallszahl, die das gesamte Feld ausfüllt. Die Länge dieser Zufallszahl gewährleistet mit einer sehr hohen Wahrscheinlichkeit die Einmaligkeit dieses Wertes. Damit bietet das System einen gewissen Schutz vor Hackerattacken. Mit dem Versand des Request Authenticators werden die Zugangsdaten des Nutzers, der sich im gesicherten Netzwerk anmelden möchte, als Attribute übergeben. Der Radius-Server wird diese Anfrage entweder mit einer Access-Accept-, Access-Reject- oder Access-Challenge-Nachricht beantworten, die ihrerseits mit einem 16 Oktett langen Response Authenticator versehen ist. Dieser ist ein MD5-Hash-Fingerprint setzt sich zusammen aus dem empfangenen Radius-Paket einschließlich der Attribute sowie den geheimen Zugangsdaten, die auf dem Server abgelegt sind, zusammensetzt. Die Attribute eines Radius-Pakets beinhalten alle wichtigen Informationen, die zwischen dem RAS und dem Radius-Server ausgetauscht werden müssen. Attribute sind sehr einfach aufgebaut Attribute werden in einer Liste mit variabler Länge im Anschluss an den Authenticator übertragen. In den Attributen können natürlich Nutzernamen und Passwörter, aber auch IPAdresse, Service-Typen, Status-Meldungen, Filter-IDs und - wichtig beim CHAP - ein entsprechender Challenge-Wert übergeben werden. Attribute werden in Datensätzen variabler Länge übertragen, die jeweils aus drei Feldern bestehen. Das erste aus acht Bit bestehende Feld benennt die Art des Attributes. Da nicht nur die Liste aller Attribute, sondern auch jeder einzelne Datensatz selbst in der Länge variabel ist, gibt das zweite Oktett die Länge des Attributes an. Erst ab dem dritten Oktett werden die eigentlichen Informationen übertragen. Im einfachsten Fall wird ein Radius-Request mit einer Legitimierung des Nutzers oder dessen Abweisung beantwortet. Dazu folgt auf dem Access-Request eine Access-Accept- oder eine Access-Reject-Nachricht vom Radius-Server. Die Art der Antwort wird mit dem Radius-Code angezeigt. Das Verfahren harmonisiert mit PAP und CHAP. 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: Kommando Argument Beschreibung HELO Systemname Beginn, Name des sendenden Systems MAIL From: Absenderadresse Beginn der Übermittlung RCPT To: Empfängeradresse Adressat der E-Mail DATA Brieftext, Ende durch eine Zeile mit "." HELP Topic Hilfestellung VRFY Mailadresse Mailadresse verifizieren EXPN Mailadresse 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: [email protected] 250 ... Sender Okay rcpt to: [email protected] 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 EMail 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 PCUmgebung 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: Die für den Empfänger bestimmten E-Mails landen beim Provider im SpoolVerzeichnis 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 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" Kommando Argument Beschreibung USER Name Das Argument identifiziert eine Mailbox. PASS String 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: Server: Client: Server: USER plate +OK name is a valid mailbox PASS YXZ1230 +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: Server: Client: Server: USER plate +OK name is a valid mailbox PASS tralala -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" Kommando Argument Beschreibung STAT - Liefert die Anzahl der gespeicherten Mails und die Größe der Mailbox zurück (in Byte). LIST Nummer Liefert die Nummer und Größe (in Bytes) aller Mails zurück. Wird als Argument eine MailNummer angegeben, wird nur die Größe dieser Mail ausgegeben. RETR Nummer Gibt die Mail mit der als Argument übergebenen Nummer aus. DELE Nummer 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: Client: Server: Client: Server: Client: Server: Server: Server: Server: Server: Client: Server: Server: Server: Client: Server: Client: Server: Server: Server: Client: Server: Client: Server: Client: Server: +OK POP3 server ready user plate +OK pass xyz1230 +OK LIST +OK 3 messages (520 octets) 1 120 2 190 3 210 . RETR 1 +OK 120 octets <... sendet Nachricht 1> . DELE 1 +OK message 1 deleted RETR 2 +OK 190 octets <... sendet Nachricht 2> . DELE 2 +OK message 2 deleted RETR 4 -ERR no such message QUIT +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 IMAPVerfahrens. 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: OK (Kommando erfolgreich ausgeführt), NO (Fehler beim Ausführen) oder BAD (Protokoll-Fehler: Kommando unbekannt oder Syntax-Fehler). 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: 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: Kommandos im "Non-Authenticated State" Kommando Argument AUTHENTICATE AuthentifizierungsMechanismus Beschreibung Das Kommando bestimmt den AuthentifizierungsMechanismus, zum Beispiel "Kerberos" oder "S/Key". Details zu den Authentifizierungs- Mechanismen finden Sie in RFC1731. LOGIN Name/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" Kommando Argument Beschreibung SELECT Mailbox-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. EXAMINE Mailbox-Name Identisch mit dem Kommando SELECT. Jedoch wird die Mailbox als "read-only" ausgewählt, es sind keine dauerhaften Änderungen möglich. CREATE Mailbox-Name Erstellt eine Mailbox mit dem als Argument übergebenen Namen. DELETE Mailbox-Name Löscht die als Argument übergebene Mailbox. RENAME Bestehender Mailbox-Name / Neuer MailboxName Ä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" Kommando Argument Beschreibung 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. SEARCH ein oder mehrere Suchkriterien Erlaubt die Suche nach bestimmten Nachrichten in der aktuellen Mailbox. Das Kommando unterstützt logische Verknüpfungen. FETCH Gewü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: Client: Server: Client: Server: Server: Server: Server: Server: Server: Client: Server: Server: Server: Server: Server: Server: Server: Server: Server: Server: Client: Server: Server: * OK IMAP4 Service Ready X001 login plate XYZ1230 X001 OK LOGIN completed X002 select inbox * 12 EXISTS * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * 2 RECENT * OK [UNSEEN 11] Message 11 is first new message * OK [UIDVALIDITY 2905753845] is first new message X002 OK [READ-WRITE] SELECT completed X003 fetch 9 rfc822.header * 9 FETCH (RFC822.HEADER {346} Date: mon, 11 Mar 2002 09:23:25 -0100 (MET) From: plate <[email protected]> Subject: Schulung Netzwerke am Donnerstag To: <[email protected]> Message-Id: <[email protected]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 ) X003 OK FETCH completed X004 LOGOUT * BYE IMAP4 server terminating connection 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 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: Benutzerspezifisches FTP Anonymous-FTP 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. 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 pwd Anzeige des aktuellen Directories auf dem entfernten System. cd remote-directory Wahl des aktuellen Directories auf dem entfernten System. cdup [directory ] Wahl des lokalen Directories für die Dateiübertragung. 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 DirectoryAnzeige 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 ascii type ascii remote-files Dateiübertragung einer Dateigruppe namensgleich vom entfernten zum lokalen System. 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 ftpProgrammlauf. Im Kommandomodus sind die Einstellungen jederzeit wieder änderbar. -v -d -i verbose-Schalter einschalten. debug-Schalter einschalten. interactive-Modus für Mehrdateiübertragung einschalten. -n -g verhindert, daß FTP zum Beginn der Sitzung einen Login-Versuch unternimmt. 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: ftp-Client FTP-Protokoll Aufgabe login USER username anmelden PASS password help help command HELP Hilfe HELP command SYST Server-Identifikation STAT Transfer-Status STAT path wie LIST, über control-Verbindung dir path LIST path Kataloginhalt zeigen, ausführlich ls path NLST path Dateinamen zeigen delete path DELE path Datei löschen rename from to RNFR from-path Datei umbenennen RNTO to-path pwd PWD Arbeitskatalog zeigen cd path CWD path Katalog wechseln mkdir path MKD path Katalog erzeugen rmdir path RMD path Katalog löschen ascii TYPE A N Textübertragung (Voreinstellung) status binary TYPE I Datenübertragung PORT h,h,h,h,p,p Port des Klienten für dataVerbindung get remote-path RETR path Datei zum Klienten übertragen put local-path STOR path Datei zum Server übertragen append localpath APPE path an Datei auf Server anfügen interrupt ABOR _bertragung abbrechen quit QUIT Verbindung 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 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.0' verwendet. Heutige Informationssysteme benötigen weit mehr Funktionen als das einfache Senden und Empfangen von Nachrichten. Die Entwicklung von HTTP/1.0 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 MailTransport verwandt werden. Dabei kommt oft MIME zum Einsatz. HTTP/1.0 ist auch für den Zugriff auf Server mit anderen Protokollen geeignet. So ist es WWW-Clients möglich, mit Servern und Gateways per SMTP, NNTP, FTP, Gopher und WAIS zu kommunizieren. 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. 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 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. 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 ServerBetreiber befürchten, daß die Sicherheit, des Systems dadurch nicht mehr gewährleistet ist. DELETE Mit dieser Methode kann der Inhalt einer URI 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 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. Zum vorhergehenden Abschnitt Copyright © FH München, FB 04, Prof. Jürgen Plate Letzte Aktualisierung: 02. Mar 2005 Zum Inhaltsverzeichnis Zum nächsten Abschnitt
