Internet-Protokolle. Axel-Tobias Schreiner Fachbereich Mathematik-Informatik Universität Osnabrück

Transkript

1 1 Internet-Protokolle Axel-Tobias Schreiner Fachbereich Mathematik-Informatik Universität Osnabrück Dieser Band enthält Kopien der OH-Folien, die in der Vorlesung verwendet werden. Diese Information steht außerdem im World-Wide-Web online zur Verfügung; sie ist in sich und mit Teilen der Systemdokumentation über Hypertext-Links verbunden. Die Beispielprogramme werden maschinell in diesen Text eingefügt. Zur Betrachtung auf anderen Systemen gibt es den Text auch als PDF-Dokument. Mit dem Acrobat Reader von Adobe kann der Text damit auf Windows-Systemen ausgedruckt werden. Der Band stellt kein komplettes Manuskript der Vorlesung dar. Zum Selbststudium müßten zusätzlich Bücher über Programmiersprachen wie C und Java, über die Protokoll-Familie TCP/ IP sowie einige Requests for Comments konsultiert werden. Inhalt 0 Einführung 1 1 Schichten 3 2 Pakete und Protokolle 15 3 Service-Design 29

2 Literatur Dieser Text wird in der Blue Box mit Adobe Framemaker, Illustrator, PhotoShop und Distiller sowie mit ConceptDraw unter MacOS X entwickelt. Er befindet sich im Web. 2 Es gibt heute sehr viele Bücher über UNIX, das Internet, TCP/IP und Client-Server Programmierung. Manche behandeln die Protokolle, andere die Programmierung von Verbindungsmechanismen und wieder andere den Umgang mit Klienten. Die folgenden Bücher sind nützlich. Soweit vorhanden, befinden sie sich in der Lehrsammlung. Comer Internetworking with TCP/IP Comer/Stevens Design, Implementation, and Internals Comer/Stevens X... Client-Server Programming and Applications Flanagan Java in a Nutshell (3rd Edition) Flanagan et al Java Enterprise in a Nutshell Flanagan Java Examples in a Nutshell Flanagan Java Foundation Classes in a Nutshell Hein TCP/IP im professionellen Einsatz (5. Auflage) Kerninghan/Ritchie Programmieren in C Scheller et al Internet: Werkzeuge und Dienste Stevens UNIX Network Programming Stevens TCP/IP Illustrated, Vol. 1: The Protocols Tanenbaum Computer-Netzwerke Einige meiner Beispiele habe ich in Artikeln in unix/mail und in den Blauen Blättern behandelt.

3 3 1 Schichten Letztlich sollen Applikationen zusammenarbeiten. Die dazu nötige Software wird in Schichten aufgebaut, die von den elektrischen Aspekten bis zu den Anwendungsprogrammen reichen. Das sogenannte OSI-Modell hat sieben Schichten, bei der TCP/IP-Protokollfamilie unterscheidet man vier Schichten, die zum Teil mit OSI übereinstimmen: 1.1 Physical Layer Diese Schicht regelt den mechanischen und elektrischen Aufbau der Verbindungen und den Austausch von Information in Form von unregelmäßigen Bit-Strömen. Für Ethernet gibt es zum Beispiel gelbe und blaue dicke Koaxial-Kabel sowie dünne schwarze Koaxial-Kabel, an denen mehrere Geräte hängen und die mehr oder weniger große Distanzen überbrücken, sowie Twisted-Pair-Kabel, die jeweils ein Gerät mit einem Verteiler verbinden.

4 4 1.2 Data Link Layer Diese Schicht regelt Aufbau und Zustellung von Informationspaketen auf der Basis der Bitströme. Ein Ethernet-Paket enthält zum Beispiel folgende Information: Das Paket muß zwischen 64 und 1518 Bytes lang sein. Bei der Übertragung versucht ein Gerät zu senden, wenn auf der Leitung gerade Ruhe herrscht. Entdeckt das Gerät dabei eine Kollision mit einem anderen Gerät, wird zufällig lange gewartet, bevor der Sendeversuch wiederholt wird. Pakete enthalten 6-Byte-Adressen von Absender und Empfänger, die weltweit eindeutig sind; außerdem gibt es Broadcast-Adressen (alle Bits sind 1). Ein 2-Byte-Typ-Feld identifiziert eine Protokollfamilie wie zum Beispiel IP. Über ein Ethernet können folglich mehrere Protokolle (IP, Novell, Apple-Talk etc.) gleichzeitig betrieben werden. Ein Gerät muß eigene und Broadcast-Pakete akzeptieren, sieht aber alle Pakete. Dies nützt man für Analyseprogramme aus: Der LanExplorer kann rohe Pakete oder Protokolle untersuchen, tcpdump beschäftigt sich speziell mit der Analyse des IP-Verkehrs. Wegen der Möglichkeit von Kollisionen kann Ethernet keine Übertragungsrate garantieren. Eine Alternative ist zum Beispiel ein Token-Ring, bei dem Geräte als Ring verbunden sind und ständig einen Nachrichtenrahmen weiterleiten. Ein Gerät darf seine Nachricht in den leeren Rahmen einfügen oder einen ankommenden Rahmen leeren. Die Übertragungsrate ist letztlich durch den Ring bestimmt und garantierbar.

5 1.3 Network Layer Das Network-Layer vermittelt zwischen Rechnern, die irgendwie im Data-Link-Layer erreichbar sind. Dazu muß es ein Adreßsystem geben, mit dem man zwischen lokalen Netzen vermitteln kann. 5 Das Internet-Protocol (IP) verwendet (noch) 4-Byte-Adressen, die dezentral verwaltet werden. Unser Rechenzentrum verwaltet zum Beispiel eine Gruppe von Class-B-Adressen, die mit beginnen, und hat der Informatik zum Beispiel die Untergruppen zugeteilt, die mit , und beginnen. Manche Adressen und Bits sind reserviert: 127.x.x.x gilt dem eigenen Gerät (loopback), 224.x.x.x bis 239.x.x.x dienen zum Multicasting, x.0 bezeichnet ein Netz und x.255 ist eine Broadcast-Adresse. Mit der Netzmaske berechnet man aus einer Adresse das Netz, in dem sich das Gerät befindet: Zur Adreßklasse gehört eine Default-Maske, aber zum Beispiel bei uns benötigt man Subnetz- Masken: $ ifconfig usage: ifconfig interface [ af [ address [ dest_addr ] ] [ up ] [ down ][ netmask mask ] ] [ metric n ] [ arp -arp ] [ link0 -link0 ] [ link1 -link1 ] [ link2 -link2 ] # ifconfig en0 en0: flags=c863<up,broadcast,notrailers,running,simplex,link2,multicast> inet netmask 0xfffffff8 broadcast

6 6 Address Resolution Protocol ARP dient dazu, korrespondierende Data-Link- und Network-Adressen festzustellen. Ein IP- System unterhält ein ARP-Cache: $ arp usage: arp hostname arp -a [kernel] [kernel_memory] arp -d hostname arp -s hostname ether_addr [temp] [pub] arp -f filename $ arp -a venus ( ) at 0:20:cb:0:20:c1 mecky ( ) at 0:5:2:5:76:31 permanent turbo ( ) at 0:0:c0:17:82:c4 penny ( ) at 0:a0:cc:20:bb:2f? ( ) at (incomplete)? ( ) at (incomplete) ARP-Pakete sind keine IP-Pakete: Man verschickt seine eigene Adreßabbildung und erfragt eine andere. Bei Broadcast hören alle zu und korrigieren ihre Caches. Die Antwort erfolgt gezielt. Reverse Address Resolution Protocol RARP verwendet die gleichen Pakete, wobei der Sender sich selbst als Empfänger einträgt und Broadcast verwendet. Ein RARP-Server darf aus seinem Cache oder einer Tabelle antworten. RARP ist eine Technik, mit der sich vor allem eine diskless workstation in ein Netz einklinkt.

7 Internet Protocol Das Network-Layer, also IP, vermittelt zwischen Data-Link-Verbindungen, also lokalen Netzen: 7 Protokoll bezieht sich darauf, wie die Daten innerhalb der IP-Familie interpretiert werden sollen. Pakete sollen sich mehr oder weniger ihren eigenen Weg im Netz suchen (man darf Adreßfolgen mitgeben), aber ein Paket sollte nicht unbegrenzt herumirren. Die time to live (TTL) wird per Rechner um 1 reduziert und außerdem um 1 für jede Sekunde, die ein Paket auf einem Rechner verweilt. Ist sie 0, verschwindet das Paket. Ein IP-Paket kann 64k Bytes Daten enthalten, kann also über viele Data-Link-Pakete verteilt sein. Das Transport-Layer, zum Teil auch in IP, muß das Paket assemblieren können. Länge bezieht sich auf die kompletten IP-Daten, die Id identifiziert alle zusammengehörigen Pakete und Offset definiert, wohin der Datenblock in den kompletten Daten gehört. Ein IP-Paket hat noch mehr und auch optionale Felder. Ping Mit einem Echo-Mechanismus im Internet Control Message Protocol (ICMP) kann man untersuchen, ob und wie schnell man einen Rechner erreicht: $ ping turbo PING turbo ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=255 time= ms 64 bytes from : icmp_seq=1 ttl=255 time=0.815 ms ^C --- turbo ping statistics packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.815/5.84/ ms traceroute manipuliert TTL so, daß Pakete nur jeweils einen Rechner weit(er) kommen und zeigt, auf welchem Weg ein Rechner erreicht wird: $ traceroute rzserv traceroute to rzserv ( ), 30 hops max, 38 byte packets 1 rzrouter ( ) 9 ms 3 ms 3 ms 2 neptun ( ) 5 ms 4 ms 4 ms 3 rzserv ( ) 7 ms 6 ms 6 ms

8 8 Routing Wie ein Paket vom eigenen Data-Link-Verbund zu einem anderen kommt, entscheidet die Netzmaske in Verbindung mit der Routing-Tabelle, die der Rechner unterhält: Hier soll ein IP-Paket von portos/ an beamer/ geschickt werden [die Adressen sind fiktiv und verkürzt gezeichnet]. IP-Adressen sind hierarchisch vergeben. Wenn ein Paket an eine bestimmte Adresse geschickt werden soll, zeigen die Route-Tabellen, wie man vorgehen muß. $ netstat -rn Routing tables Destination Gateway Flags Refs Use Interface UH lo0 default UG en0 Auf einem einfachen Rechner paßt die IP-Zieladresse entweder insgesamt oder im Netz-Teil (von links her) zu einer Destination; dann wird das Paket an die Data-Link-Adresse des zugehörigen Gateway geschickt; die IP-Adresse im Paket zeigt auf den endgültigen Empfänger. Normalerweise gibt es noch einen Eintrag default, an den die übrigen Pakete geschickt werden; bei uns ist das nach Konvention in jedem Netz die Adresse x.254. Wir setzen die Route-Tabelle statisch beim Start. Verbindungsrechner haben mehrere IP-Adressen und aufwendigere Route-Tabellen, die normalerweise dynamisch verwaltet werden, zum Beispiel mit routed und dem Router Information Protocol (RIP). Repeater, Bridges, Router, Hubs und Switches Kabellängen sind begrenzt, es gibt aber Geräte, die je nach Layer verbinden. Ein Repeater operiert im Data-Link-Layer und kopiert alle Pakete von einem Kabel auf ein anderes. Er dient schlicht zur Verlängerung von Kabeln, reduziert aber den Verkehr nicht, das heißt, beide Kabel hören alle Pakete und sind an Kollisionen beteiligt. Eine Bridge operiert im Data-Link-Layer wie ein Repeater, lernt aber die Adressen auf jedem Kabel und kopiert nur Broadcast-Pakete und Pakete, die wirklich auf der anderen Seite sind. Ein Router operiert im Network-Layer mit einer Router-Tabelle. Intelligente Router können auch noch Protokolle filtern, operieren also im Transport-Layer und darüber und agieren als Schutzmechanismen (Firewalls). Ein Hub ist ein Repeater für vorwiegend sternförmige Verbindungen mit Twisted-Pair-Ethernet- Kabeln. Ein Switch ist eine Bridge als Hub, wobei auch noch virtuelle Netze abgetrennt werden können. Wir verwenden einen sehr großen Switch für alle drei IP-Netze zusammen.

9 1.4 Transport Layer Das Transport-Layer kümmert sich um Verbindungen zwischen Prozessen und verwaltet den Datenfluß, regelt also Größe und Durchsatz der Pakete. IP ist für die Fragmentierung und Assemblierung von Paketen zuständig. Das Transmission Control Protocol (TCP) realisiert sichere Bytestrom-Verbindungen zwischen Prozessen mit Verbindungs-Auf- und Abbau. Das User Datagram Protocol (UDP) realisiert unsichere Nachrichten zwischen Prozessen, ohne daß eine Verbindung aufgebaut wird. Nachrichten können mehrfach oder auch gar nicht ankommen. Zur IP-Adresse kommt für TCP und UDP unabhängig voneinander bei Sender und Empfänger je eine 16-Bit Port-Nummer hinzu, von denen einige für bestimmte Dienste (Protokolle) verabredet sind, siehe /etc/services. Ein UDP-Ziel ist durch Port und IP-Adresse charakterisiert. Eine TCP-Verbindung ist erst durch beide Ports und beide IP-Adressen definiert. In BSD-ähnlichen Systemen ist inetd dafür verantwortlich, daß Server für bestimmte Dienste erreichbar sind, siehe /etc/inetd.conf. Als Klient für viele TCP-Dienste kann man zunächst telnet verwenden, denn damit kann man eine einigermaßen transparente, zeichenorientierte Verbindung zwischen einem Terminal und einem TCP-Port einrichten. Viele TCP-Dienste sind zeilenorientiert. $ telnet linux daytime 2>/dev/null Connected to linux. Escape character is '^]'. Sat Apr 9 15:51: Mit telnet wird hier eine Verbindung zum Rechner linux und dort zum Port des daytime-service aufgebaut. Dieser Service liefert eine Zeile mit einem Datumstempel, die telnet dann ausgibt. $ telnet turbo ftp 220 turbo FTP server (Version 5.1 (NeXT 1.0) Tue Jan 26, 1999) ready. help 214- The following commands are recognized (* =>'s unimplemented). USER PORT STOR MSAM* RNTO NLST MKD CDUP PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE REIN* MODE MSND* REST XCWD HELP PWD MDTM QUIT RETR MSOM* RNFR LIST NOOP XPWD 214 Direct comments to ftp-bugs@turbo. quit $ telnet turbo smtp help 214-Commands: 214- HELO MAIL RCPT DATA RSET 214- NOOP QUIT HELP VRFY EXPN 214-For more info use "HELP <topic>". 214 End of HELP info Oft enthalten die Antworten führende Nummern, die standardisiert sind. - bedeutet, daß noch eine Zeile folgt. 9

10 1.5 Höhere Schichten Das Session-Layer ist für die Verwaltung von Sitzungen zuständig, regelt also zum Beispiel den Dialogfluß, wenn eine Verbindung nur in einer Richtung benützt werden kann. Dazu gehört auch Checkpointing, damit eine unterbrochene Sitzung fortgesetzt werden kann. Das Presentation-Layer beschäftigt sich mit der Repräsentierung von Information auf verschiedenen Plattformen, also zum Beispiel mit verschiedenen Zeichensätzen oder verschiedenen Zahlendarstellungen. Das Application-Layer soll Leistungen wie zum Beispiel ein abstraktes Netzwerk-Terminal zur Verfügung stellen, damit die eigentlichen Applikationen von der konkreten Plattform abgetrennt sind. RPC In der IP-Familie kann man die Trennung dieser Schichten am ehesten noch im Bereich der Remote Procedure Calls (RPC) entdecken. Die External Data Representation (XDR) ist eine Beschreibungssprache, ähnlich wie IDL, und Funktionsbibliothek für Datentypen, auf die sich die Parameter und Resultate bei RPC stützen. RPC erweitert XDR um Funktions- und Programm-Deklarationen. rpcinfo beschreibt, welche Programme beim portmapper angemeldet sind, und zeigt, auf welchem Port sie RPC empfangen. Außerdem kann man die Prozedur 0 der Programme anrufen, um zu sehen, ob die Programme überhaupt antworten: $ rpcinfo Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ] rpcinfo [ -n portnum ] -t host prognum [ versnum ] rpcinfo -p [ host ] rpcinfo -b prognum versnum rpcinfo -d prognum versnum $ rpcinfo -p turbo program vers proto port tcp 111 portmapper udp 111 portmapper udp 723 netinfobind tcp 726 netinfobind udp 2049 nfs udp 763 mountd tcp 766 mountd udp 772 bootparam udp 2585 rquotad udp 2586 rstat_svc udp 2586 rstat_svc udp 2586 rstat_svc udp 2587 rusersd udp 2587 rusersd udp 2589 sprayd $ rpcinfo -u turbo rpcinfo: RPC: Program/version mismatch; low version = 2, high version = 2 program version 3 is not available $ rpcinfo -b turbo mecky 10

11 11 Mit spray kann man Erreichbarkeit und Antwortverhalten für RPC untersuchen: NFS $ spray turbo sending 1162 packets of lnth 86 to turbo... in 5.11 seconds elapsed time 1080 packets (92.94%) dropped Sent: 227 packets/sec, 19.1K bytes/sec Rcvd: 16 packets/sec, 1.3K bytes/sec Das Netzwerk File System (NFS) ist sicher die wichtigste Anwendung von RPC. Es wird normalerweise durch fiktive Prozesse im Betriebssystem selbst implementiert: biod lokal zur Verbesserung der Geschwindigkeit, nfsd als Server und mountd, um Zugriffe anzumelden. nfsstat zeigt speziell die Statistik der Remote Procedure Calls für NFS: NIS $ nfsstat -w 5 Getattr Lookup Readlink Read Write Rename Access Readdir Client: Server: Client: Server: Die Yellow Pages (Network Information System, NIS) verteilen Hash-Tabellen per RPC. Sie dienen oft zur Systemverwaltung, denn man verteilt Tabellen für Dateien wie /etc/passwd. $ domainname applied $ ypcat -x Use "passwd" for "passwd.byname" Use "group" for "group.byname" Use "networks" for "networks.byaddr" Use "hosts" for "hosts.byaddr" Use "protocols" for "protocols.bynumber" Use "services" for "services.byname" Use "aliases" for "mail.aliases" Use "ethers" for "ethers.byname" $ ypwhich -m category.byname thor auto.direct thor auto.master thor auto.home thor timezone.byname thor netmasks.byaddr thor netid.byname thor publickey.byname thor category.byhost thor netgroup.byhost thor... Funktionen wie getpwuid() greifen je nach Systemkonfiguration transparent auf NIS zu. OPENSTEP und Rhapsody verwenden statt dessen NetInfo, eine verteilte, hierarchische Datenbank.

12 DNS Der Domain Name Service (DNS) operiert normalerweise über UDP. Es ist eine verteilte Datenbank, mit der vor allem Rechnernamen und IP-Adressen zugeordnet werden. Außerdem findet man Mail-Server für Rechner (MX-Records). $ nslookup Default Server: turbo Address: > help $Id: nslookup.help,v /12/15 06:24:31 vixie Exp $ Commands: (identifiers are shown in uppercase, [] means optional) NAME - print info about the host/domain NAME using default server NAME1 NAME2 - as above, but use NAME2 as server help or? - print info on common commands; see nslookup(1) for details set OPTION - set an option all - print options, current server and host [no]debug - print debugging information [no]d2 - print exhaustive debugging information [no]defname - append domain name to each query [no]recurse - ask for recursive answer to query [no]vc - always use a virtual circuit domain=name - set default domain name to NAME srchlist=n1[/n2/.../n6] - set domain to N1 and search list to N1,N2, etc. root=name - set root server to NAME retry=x - set number of retries to X timeout=x - set initial time-out interval to X seconds querytype=x - set query type, e.g.,a,any,cname,hinfo,mx,px,ns,ptr,soa,txt type=x - synonym for querytype class=x - set query class to one of IN (Internet), CHAOS, HESIOD or ANY server NAME - set default server to NAME, using current default server lserver NAME - set default server to NAME, using initial server finger [USER] - finger the optional NAME at the current default host root - set current default server to the root ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE) -a - list canonical names and aliases -h - list HINFO (CPU type and operating system) -s - list well-known services -d - list all records -t TYPE - list records of the given type (e.g., A,CNAME,MX, etc.) view FILE - sort an 'ls' output file and view it with more exit - exit the program, ^D also exits Mit nslookup kann man DNS-Anfragen stellen. Dazu muß aber das System Zugriff auf einen Name-Server haben, siehe /etc/resolve.conf. 12

13 13 SNMP Das Simple Network Management Protocol (SNMP) operiert normalerweise binär über UDP. Es enthält ziemlich einfache Befehle zur Manipulation von Werten in einer Baumstruktur, der Management Information Base (MIB), deren Grundlagen standardisiert sind. NeXT verwendet PD-Software, um wenigstens die Netzaspekte abfragen zu lassen. Bei NeXT- STEP 3.2 kann man in NetInfo etwa folgendes eintragen: locations/snmp/ enabled yes communities/ public/ networks Jetzt wird beim Systemstart von /etc/rc aus das Programm /usr/etc/snmpd erfolgreich gestartet und folgende Anfragen sind möglich: $ snmp status localhost localhost (NeXT.1.1), Uptime: 0:13:03 NeXT Mach 3.2: Mon Oct 18 21:57:41 PDT 1993; root(rcbuilder):mk obj~2/rc_m68k/release_m68k Name Speed Type Stat Ibyte Obyte Ierr Oerr Physical Address en0 other up 88KB 87KB <.1% <.1% 00:00:0F:00:B3:36 lo0 other up 1.6MB 1.6MB <.1% <.1% en0 10Mb ethernet up 88KB 87KB <.1% <.1% $ snmp localhost snmp> walk system system.sysdescr.0 NeXT Mach 3.2: Mon Oct 18 21:57:41 PDT 1993; root(rcbuilder):mk obj~2/rc_m68k/release_m68k (OCTET STRING) system.sysobjectid.0.iso.org.dod.internet.private.enterprises.next.1.1 (OBJECT IDENTIFIER) system.sysuptime.0 0:02:41 (Timeticks, 16165) snmp> ^D $ snmpnetstat localhost Active Internet Connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 next.time esix.2413 TIMEWAIT tcp 0 0 next.700 next.703 ESTABLISHED tcp 0 0 next.700 next.761 ESTABLISHED tcp 0 0 next.703 next.700 ESTABLISHED tcp 0 0 next.761 next.700 ESTABLISHED Allgemein kann man in /etc/snmp.mib erahnen, welche Anfragen beantwortet werden: system interfaces at ip icmp tcp udp egp

14 netstat netstat ist ein lokales Kommando und zeigt verschiedene Netz-Datenstrukturen und Statistiken: $ netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 next.time esix.1304 TIME_WAIT tcp 0 0 next.1023 esix.login ESTABLISHED tcp next.799 next.802 ESTABLISHED tcp 0 0 next.802 next.799 ESTABLISHED $ netstat 5 input (en0) output input (Total) output packets errs packets errs colls packets errs packets errs colls ^C $ netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en next lo loopback localhost en0* 1500 none none $ netstat -m 76/256 mbufs in use: 4 mbufs allocated to packet headers... $ netstat -s ip interrupt queue:... ip: total packets received 0 bad header checksums... icmp: 0 calls to icmp_error... tcp: 5571 packets sent 2398 data packets ( bytes) 10 data packets (9744 bytes) retransmitted packets received 3128 acks (for bytes) 988 duplicate acks... udp: 0 incomplete headers 0 bad data length fields 0 bad checksums 14

15 15 2 Pakete und Protokolle In diesem Kapitel werden die unteren Schichten der IP-Familie im Detail betrachtet. 2.1 Ethernet und IEEE Ethernet-Pakete haben 64 bis 1518 Bytes (ohne preamble). Am protocol wird der Inhalt unterschieden. Die Adresse ff:ff:ff:ff:ff:ff dient als Broadcast, wird also von allen Netzkarten erkannt. IEEE enthält die Länge an Stelle der Protokoll-Nummer und muß daher noch ein logical link control-paket enthalten. Gebräuchliche Protokoll-Nummern sind groß, damit man sie nicht mit Längen verwechseln kann.

16 ARP ARP (RFC 826) setzt Ethernet Protocol 0x8086, Broadcast ff:ff:ff:ff:ff:ff und die gesuchte IP-Adresse. Wenn ein Rechner seine IP-Adresse erkennt, füllt er seine Hardware- Adresse aus. Es gibt Probleme, wenn zwei Rechner die gleiche IP-Adresse haben, weil sie sich im Lauf der Zeit immer wieder widersprechen. 2.3 RARP RARP (RFC 903) setzt Ethernet Protocol 0x8035, Broadcast und die gesuchte Hardware- Adresse. Wenn ein Server(!) die Hardware-Adresse kennt, füllt er die IP-Adresse aus. 2.4 IP IP (RFC 791) verwendet einige type of service Bits, die die Priorität von Nachrichten festlegen, sowie Hinweise an die Router: D low delay T high throughput R high reliablity C low cost IP kann Pakete fragmentieren, um sie durch Netze mit geringen MTU-Werten (maximum transfer units) zu bringen. Sie müssen dann auch wieder rekombiniert werden: N don't fragment M more to come Wenn N gesetzt ist und ein Paket nicht in ein Netz paßt, wird es verworfen. Die Fragmente werden anhand ihrer id erkannt und anhand von offset zusammengesetzt, bis M nicht mehr gesetzt ist. time to live wird in jedem Router um 1 reduziert, bis ein Paket verworfen wird dann erfolgt eine ICMP-Meldung. options sind Bytes, die zur Diagnose dienen.

17 2.5 ICMP ICMP (RFC 792) sind Meldungen, die in IP-Paketen als Daten mit protocol 1 verschickt werden. Sie bestehen mindestens aus 4 Bytes: Typ, Code und 2 Bytes mit einer Prüfsumme. ping schickt als Typ 8, als Code 0, und fügt zwei Bytes mit einer id, zwei Bytes mit einer Sequenznummer und einige Datenbytes hinzu. Die Antwort erhält den Typ 0. Mit ICMP-Fehlermeldungen, zum Beispiel Typ 3 (destination unreachable), Typ 4 (source quench) oder Typ 11 (ttl exceeded) kann man Netzprobleme untersuchen. traceroute sendet Pakete mit fortschreitend größerer time to live und bestimmt aus den ICMP- Meldungen die wahrscheinliche Route zum Ziel. 2.6 UDP 17 UDP (RFC 768) ist ein verbindungsloses, unsicheres Datagram-Protokoll auf Benutzer- (Prozeß-) Ebene. Zum IP-Paket kommen Port-Nummern für Sender und Empfänger sowie eine Daten-Prüfsumme hinzu, die allerdings die IP-Adressen auch berücksichtigt: UDP hat verschiedene, wichtige Anwendungen: TFTP RFC 1350 trivial file transfer protocol Start von Rechnern ohne Platte DNS RFC 1034 domain name service IP-Adressen für Namen SNMP RFC 1157 simple network management protocol Rechnerbetrieb via Datenbank RPC RFC 1831 remote procedure call auch über TCP NFS RFC 1813 network file system wesentlichste RPC-Anwendung

18 TCP TCP (RFC 793) ist ein verbindungsorientiertes, sicheres Byte-Strom-Protokoll auf Benutzer- (Prozeß-) Ebene. Zum IP-Paket kommen Port-Nummern für Sender und Empfänger, Informationen zur Absicherung der Übertragung und für vorrangige Daten sowie eine Daten-Prüfsumme hinzu, die allerdings die IP-Adressen auch berücksichtigt: Man bezeichnet ein TCP-Paket als Segment. Vorrangige Informationen liegen vor, wenn URG gesetzt ist. Sie befinden sich dann am Anfang der Datenfläche und urgent pointer ist die Anzahl der vorrangigen Bytes. sequence number ist ein vom Sender über Verbindungen hinweg fortlaufender Byte-Zähler, der die Position des ersten, nicht-vorrangigen Bytes im Datenstrom bezeichnet. acknowledgment number ist gültig, wenn ACK gesetzt ist, und ist dann die nächste sequence number, die vom Sender erwartet wird, bezeichnet also die Position des ersten Bytes im Strom, das noch nicht empfangen wurde. PUSH wird gesetzt, damit der Empfänger die Daten nicht puffert, sondern sofort der Applikation liefert. RESET wird im Notfall gesetzt, um eine Verbindung brutal abzubrechen. SYN wird in Segmenten gesetzt, die zur Verbindungsaufnahme dienen. FIN wird in Segmenten gesetzt, die zum Abbau der Verbindung dienen. window teilt mit, wieviel Bytes maximal zwischen sequence und acknowledgment liegen können. Diese Größe wird zur Flußkontrolle variiert. Es gibt eine einzige option, mit der die maximale Größe für ein Segment mitgeteilt wird.

19 Verbindungen Das Quadrupel aus Sender- und Empfänger-Adresse und -Port-Nummer ist per Verbindung eindeutig (und deshalb Teil der Prüfsumme). Das heißt, zwei verschiedene Verbindungen können auf einem Rechner durchaus die gleiche Port-Nummer verwenden. TCP- und UDP-Port-Nummern bilden voneinander verschiedene Adreßräume. Aufbau und Abbau einer Verbindung werden durch das folgende (bezüglich Fehlern und Abbrüchen nicht vollständige) Zustandsdiagramm beschrieben: 19 Die Pfeile sind Zustandsänderungen, die durch Anforderungen an die Transportschicht (fett) oder durch Empfang von ACK-, SYN- oder FIN-Segmenten (rot) ausgelöst werden. In der Regel werden dann entsprechende Segmente (blau) verschickt. ACK wird anhand der acknowledgment number zugeordnet. ACK darf nur sequentiell verschickt werden ein fehlendes Segment unterbindet weitere ACK. Gehen ACK verloren, können deshalb Löcher akzeptiert werden.

20 20 Verbindungsaufbau Beim Aufbau einer Verbindung müssen Sender und Empfänger ihre nächste sequence number bekanntgeben. Dies geschieht mit insgesamt zwei SYN- und einem ACK-Segment: Bleiben Antworten mit ACK-Segmenten zu lange aus, muß erneut übertragen werden. Der three way handshake dient dazu, vielfaches Hin und Her zu vermeiden: Ein einfaches SYN/ACK könnte sehr leicht zu unendlich vielen Wiederholungen führen. Dies wird unter anderem durch die Nummern vermieden.

21 21 Übertragung Im Zustand established werden dann (bei Bedarf in beiden Richtungen!) Daten und ACK übertragen: ACK muß innerhalb einer Zeitschranke empfangen werden. Zu deren dynamischer, variabler Bestimmung gibt es komplizierte Algorithmen, unter anderem von Phil Karn (KA9Q). Bis zu window Bytes können ohne Empfang von ACK geschickt werden. Jedes ACK schiebt dann dieses Fenster weiter (sliding window), wobei innere ACK nicht gesendet werden brauchen. Der Empfänger teilt bei ACK das verbleibende Fenster mit, damit der Sender entsprechend weniger schickt dies gilt allerdings nur, wenn gültige Daten übertragen wurden. Hat der Empfänger wieder Platz, schickt er ein ACK mit einer neuen Fenstergröße allerdings erst, wenn der Puffer zu 25% leer ist oder wenigstens ein maximales Segment empfangen kann (silly window algorithm). Beim Start einer Verbindung wird das Fenster langsam vergrößert (slow start algorithm) und später wird das Fenster bei zu vielen Wiederholungen verkleinert, um Netzüberlastung zu vermeiden (congestion avoidance). Kleine Datenpakete werden nach Möglichkeit beim Sender gepuffert, um die weiteren Schichten weniger zu belasten (Nagle algorithm). Echo Eine wichtige Anwendung ist das Netz-Terminal-Protokoll TELNET. Dabei muß inbesondere ein zeichenweises Echo möglichst effizient verschickt werden: Je nach Geschwindigkeit des Servers (rechts) benötigt man für ein Echo drei oder vier Segmente.

22 22 Verbindungsabbau Zum ordentlichen Abbau der Verbindung muß jede Seite ein FIN-Segment verschicken und ein ACK dafür empfangen. Je nach Zustand wird dann noch die doppelte maximale Segment- Lebensdauer (MSL) abgewartet. Mit netstat kann man relativ häufig unvermittelt abgebrochene Verbindungen im Zustand time wait entdecken. Fazit TCP hat sehr viele wichtige Anwendungen: FTP RFC 959 file transfer protocol Datei-Übertragung HTTP RFC 2616 hypertext transfer protocol World Wide Web SMTP RFC 821 simple mail transfer protocol elektronische Post TELNET RFC 854 network terminal remote login X11 RFC 1013 X Window System protocol Fenster-System Die einzige Fehlerkorrektur erfolgt end to end, ist aber wegen relativ verläßlicher Übertragungen trotzdem recht effizient insbesondere wegen der dynamisch änderbaren Fenster.

23 2.8 tcpdump tcpdump erlaubt der Netzkarte, alle Pakete einzulesen, und läßt sich vom Kern ausgewählte Pakete liefern, die dann dargestellt werden. Aus Sicherheitsgründen ist tcpdump nur für den Super-User verfügbar. tcpdump optionen filter-expression Wesentliche Optionen kontrollieren die Art der Ausgabe: -dd filter-expression darstellen; sonst nichts -e Ethernet- (statt IP-) bezogen -s len Paketlänge -t kein Zeitstempel -v mehr Information -x Hex-Dump der Paketdaten Ohne filter-expression wird alles berichtet. Eine filter-expression wird als Pseudo- Code in den Kern geladen und dort bezüglich eines Pakets interpretiert: $ tcpdump -dtxv host molly and udp port domain (000) ldh [12] 12: ethernet type code (001) jeq #0x800 jt 2 jf 160x800: IP (002) ld [26] 26: ip sender (003) jeq #0x83ad0dd1 jt 6 jf molly (004) ld [30] 30: ip destination (005) jeq #0x83ad0dd1 jt 6 jf 16 (006) ldb [23] 23: ip protocol (007) jeq #0x11 jt 8 jf 160x11: udp (008) ldh [20] 20: ip flags (fragmenting) (009) jset #0x1fff jt 16 jf 10fragmented? (010) ldxb 4*([14]&0xf)14: ip header length (wds) (011) ldh [x + 14] udp 0: sender port (012) jeq #0x35 jt 15 jf 130x35: DNS (013) ldh [x + 16] udp 2: receiver port (014) jeq #0x35 jt 15 jf 16 (015) ret #68 (016) ret #0 filter-expression kann sich also auf die Felder der verschiedenen Header beziehen und diese und/oder/nicht verknüpfen und auch arithmetisch prüfen. Dies ist hinter einer Vielzahl von symbolischen Namen und relativ verwirrenden Abkürzungen versteckt: term: C-constant Literal PROTOCOL [ offset : size ] ether ip icmp arp rarp udp tcp 1, 2, oder 4 Bytes len Paketlänge product: term * term... term / term... sum: product + product... product - product... bit-and: sum & sum... bit-or: bit-and bit-and... primitive: bit-or RELOP bit-or < <= > >=!= = Bis hierher kann man mit einer C-ähnlichen Syntax Bytes in den Protokoll-Schichten bit-weise untersuchen. 23

24 Als Abkürzungen, die syntaktisch ebenfalls als primitive gelten, kann man die interessanten Felder symbolisch abfragen, zum Beispiel: primitive: ether proto NAME \ip \arp \rarp ip proto NAME \icmp \tcp \udp ether src NAME Ethernet-Host ether dst NAME ether host NAME ether broadcast Ethernet Broadcast src host NAME IP-Host dst host NAME host NAME ip broadcast IP Broadcast (0 oder 1) PROTOCOL dst port NUMMBER \udp \tcp Port-Nummer PROTOCOL src port NUMMBER PROTOCOL port NUMMBER Man kann viel weglassen, denn Angaben werden auch von primitive zu primitive kopiert. Es gibt auch Tests für Pakete, die das lokale Netz verlassen. primitive schließlich werden verknüpft, wobei fehlende Angaben zu Feldern immer als Wildcard interpretiert werden: negation: not primitive primitive ( union ) intersection: negation and negation... union: intersection or intersection... Beispiele clark 0:a:27:e2:ef: molly 0:30:65:b0:15:da penny 0:a0:cc:20:bb:2f venus 0:60:8:26:17: Assigned Numbers findet man zum Beispiel im RFC ARP: Beim Start von venus versucht penny, venus zu finden; venus antwortet selbst. Außerdem versucht venus, den (nicht-existenten) Router zu finden: $ tcpdump -tev host and arp tcpdump: listening on en0 0:a0:cc:20:bb:2f Broadcast arp 64: arp who-has venus tell :60:8:26:17:79 0:a0:cc:20:bb:2f arp 64: arp reply venus is-at 0:60:8:26:17:79 0:60:8:26:17:79 Broadcast arp 64: arp who-has tell venus 24

25 25 Führt man auf venus $ ping clark aus, muß venus clark finden: $ tcpdump -texv host and arp tcpdump: listening on en0 0:60:8:26:17:79 Broadcast arp 64: arp who-has tell venus ad 0dd ad 0dc8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 44d4 0d39 0:a:27:e2:ef:46 0:60:8:26:17:79 arp 68: arp reply is-at 0:a:27:e2:ef: a 27e2 ef46 83ad 0dc ad 0dd2 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 44d4 0d e14 ping selbst findet in IP-Paketen statt (ist aber ICMP): $ tcpdump -txv host and icmp tcpdump: listening on en0 venus > : icmp: echo request (ttl 32, id 37376) c e5cc 83ad 0dd2 83ad 0dc c a 6b6c 6d6e 6f > venus: icmp: echo reply (ttl 255, id 14654) c 393e 0000 ff01 5f8e 83ad 0dc8 83ad 0dd c a 6b6c 6d6e 6f Auf molly kann man mit nslookup direkt DNS-Anfragen bearbeiten. Der DNS-Server muß erreichbar sein, sonst finden ARP-Anfragen zwecks Routing statt: $ tcpdump -txv host molly and udp port domain tcpdump: listening on en0 molly.1055 > venus.53: A? foo. (21) (ttl 64, id 2536) e dd7 83ad 0dd1 83ad 0dd2 041f d 256f 3d1d f6f Macht man das auf venus, muß man völlig anders filtern: $ tcpdump -txv host and ip broadcast tcpdump: listening on en0 venus.137 > : udp 50 (ttl 128, id 60160) e eb c73 83ad 0dd2 83ad 0dff a c Hier wird UDP auf Port 137 verwendet -- das ist Windows' Netbios.

26 SYN- und FIN-Pakete beim TCP-Verbindungsauf- und -abbau kann man beobachten, indem man die relevanten Flaggen filtert und zum Beispiel einen TELNET-Anruf (rot) tätigt: $ tcpdump -t 'host venus and tcp[13:1] & 3!= 0' & tcpdump: listening on en0 $ telnet venus molly.1143 > venus.telnet: S : (0) win <mss 1460,nop,wscale 0,nop,nop,timestamp[ tcp]> (DF) [tos 0x10] venus.telnet > molly.1143: S : (0) ack win <mss 1460,nop,nop,timestamp [ tcp]> (DF) venus.1032 > molly.auth: S : (0) win <mss 1460,sackOK,timestamp [ tcp]> (DF) telnet> q molly.1143 > venus.telnet: F 75:75(0) ack 122 win <nop,nop,timestamp > (DF) [tos 0x10] venus.telnet > molly.1143: F 122:122(0) ack 76 win <nop,nop,timestamp > (DF) Man sieht, daß eine Reihe von Optionen übermittelt werden und daß der TELNET-Server ohne Erfolg versucht, eine Verbindung zurück zu einem Authentication-Server (RFC 931) aufzubauen, der ihm die Benutzer-Identität mitteilen soll. Das abschließende ACK des three way handshake wird durch die Filterung unterdrückt. 26

27 2.9 ethereal ethereal ist ein grafisches Frontend für tcpdump, das zum Beispiel unter Linux verfügbar ist: 27 Unter Capture kann man in einem Panel einen Filterausdruck eintragen und dann Pakete sammeln: Im Hauptfenster wählt man oben ein Paket. In der Mitte kann man mehr Informationen zu den einzelnen Schichten aufklappen und unten sieht man die Rohdaten.

28 28

29 29 3 Service-Design Services beruhen zumeist auf Dateitransfer, der allerdings auch im Dialog erfolgen kann. Dateien kann man mit vielen Protokollen übertragen. Sie unterscheiden sich zum Beispiel in Authentifizierung, Adressierung und Codierung. 3.1 Dateitransfer Kann man Bytes sicher übertragen, muß man sich überlegen, was man mit den Bytes anfangen will. UUCP (durch Pakete und Prüfsummen abgesicherte Übertragung auf seriellen Vrbindungen, normalerweise über Modems) hat seinerzeit vorgeführt, daß man eine Vielzahl von Leistungen schlicht auf Dateitransfer zurückführen kann: uucp Dateikopie Datei an beliebigen Punkt kopieren mail Nachricht: einer an einen Datei an Mailbox-Datei anhängen news Nachricht: einer an alle Datei in Katalog anlegen lpr drucken Datei in Drucker-Bereich anlegen; Dämon bearbeitet sie später uux Auftrag abwickeln Datei in Katalog anlegen, Dämon bearbeitet sie später Rückmeldungen können wesentlich später per mail erfolgen, also wieder per Dateitransfer. Abgesehen davon, daß die Pakete quittiert werden, ist dies halb-duplex Betrieb, kein Dialog. Problematisch sind die Zugriffsrechte auf das Dateisystem des Zielrechners (eine Universität soll sich so die UNIX-Quellen beschafft haben) und die Codierung der Datei-Inhalte. 3.2 Dialog Andersartige Leistungen ergeben sich, wenn man synchrone Auftragsabwicklung wünscht, also zum Beispiel Anfragen an die Warteschlange des Drucker-Subsystems. In diesem Fall muß man auf dem Zielsystem ein Kommando so ablaufen lassen können, daß dessen Ausgabe direkt als Antwort auf die Anfrage geschickt wird. inetd bewacht TCP- (und UDP-)Ports nach Anweisung seiner Konfigurationsdatei /etc/ inetd.conf. Kommt ein Anruf, erhält ein Kommando die Verbindung für Standard-Ein- und - Ausgabe. Plan 9 verwendet zur Konfiguration einen Katalog mit rc-skripten, abgelegt unter Port-Nummern als Dateinamen. Super-Server wie inetd dienen eigentlich dazu, die Anzahl Prozesse relativ zu den angebotenen Services zu verringern, aber man kann damit fast beliebige Kommandos als Service anbieten. Dies ist zwar voll-duplex Betrieb, aber je nach Kommando ist der Dialog gepuffert. Problematisch ist, daß inetd selbst keine Authentifizierung verlangt, sondern nur eine lokale Identität für die Ausführung eines Kommandos vorgibt. Kommandos wie fingerd lesen eine Anfragezeile als Standard-Eingabe und konstruieren daraus einen mehr oder weniger sicheren Aufruf eines lokalen Kommandos ein sehr primitives Protokoll.

30 Beispiel /etc/inetd.conf ats stream tcp nowait nobody /bin/dd dd ibs=1 obs=32 /etc/services ats 12345/tcp In diesem Fall entsteht auf TCP-Port ein Echo-Service, der aber 32 Bytes zusammenkommen läßt: # ps ax grep inetd 215?? Ss 0:00.01 inetd # kill # neu konfigurieren $ telnet localhost ats Trying Connected to localhost. Escape character is '^]'. axel was here and he liked this program axel was here and he liked this^] telnet> q Connection closed. telnet dient einfach als Brücke zwischen einem Benutzer-Terminal und einer TCP-Verbindung zum Service und kann verschieden gepuffert arbeiten: /etc/inetd.conf telnet> Effekt cat -u axel axel mode character aaxxeell dd bs=32 axel axel mode character aaxxeell vi ex/vi: Vi's standard input and output must be a terminal ed a? Abgesehen davon, daß vi und selbst ed viel zu mächtige Kommandos sind, sieht man zwei Probleme: ein Kommando kann eine TCP-Verbindung von einem Terminal unterscheiden, und telnet schickt grundsätzlich \r\n für einen Zeilentrenner, was zu Syntaxfehlern in ed führt. Letzteres kann man mit tcp.client umgehen. 30

31 3.3 Pseudo-Terminal Server wie inetd oder rshd verwenden die TCP-Verbindung mehr oder weniger direkt als Standard-Ein- und -Ausgabe von normalen Kommandos. Damit ist nur eine begrenzte Form von remote login möglich. Problematisch sind die jeweiligen Zeichensätze und die Tatsache, daß die Authentifizierung letztlich lokal auf dem Server erfolgt Paßwörter könnten abgehört werden. Server wie telnetd, rlogind und sshd verwenden server-seitig sogenannte Pseudo-Terminals, um auf der Server-Seite einer TCP-Verbindung für Kommandos wie vi einen Terminal-Treiber zu simulieren. Ein Terminal-Treiber kümmert sich vor allem um Signale und Zeilenpufferung und -editierung: 31 Hinter einer Netzverbindung wird ein Pseudo-Terminal wie eine Art bidirektionale Pipeline zwischen Netz-Server auf der Master-Seite des Pseudo-Terminals und einem Service-Prozeß auf der Slave-Seite des Pseudo-Terminals eingeschaltet: Klient und Server können dann zum Beispiel mit TCP-out-of-band-Daten Signale übertragen, die der Slave als solche zugestellt bekommt. Fragt ein Slave-Prozeß wie vi, kann er ein Pseudo-Terminal nicht unbedingt von einem echten unterscheiden. Problematisch bleibt nach wie vor die Authentifizierung, da die Netzverbindung abgehört werden kann und Slave-Kommandos dies eigentlich nicht berücksichtigen müßten. Eine Kombination wie ssh/sshd verschlüsselt die Netzverbindung und sorgt je nach Konfiguration für sicherere Authentifizierungen. Dies muß nicht unbedingt für remote login verwendet werden.

32 3.4 FTP FTP (RFC 959) ist ein sehr altes Protokoll zur Übertragung von Dateien zwischen heterogenen Systemen. Es setzt eigentlich voraus, daß sich der Benutzer bei dem Server anmelden kann allerdings gibt es eine anonyme Anmeldung mit entsprechend eingeschränktem Zugriff. 32 Das Protokoll wird über eine TELNET control-verbindung zu Port 21 abgewickelt. Zur Übertragung von Daten wird eine TCP data-verbindung mit Port 20 oder einem explizit vereinbarten Port verwendet. Zur Anpassung zwischen den Systemen können Datentypen (ASCII, IMAGE und LOCAL) und Druckformate (NONPRINT, TELNET und ASA), Dateistrukturen (FILE, RECORD und PAGE) sowie Übertragungsarten (STREAM, BLOCK und COMPRESSED) vereinbart werden, wobei bei den beiden letzteren eine Übertragung auch fortgesetzt werden kann. Praktisch spielt im UNIXund Windows-Bereich nur der Unterschied zwischen ASCII NONPRINT und IMAGE eine Rolle und übertragen wird ein FILE STREAM. Zwar ist das Protokoll dafür entworfen, daß es zwischen Programmen wie ftp/ftpd verwendet wird, aber es enthält keinen portablen Mechanismus, auf dem man die Übertragung von Hierarchien aufbauen kann. Dafür gibt es heute Alternativen wie mirror, rcp, scp und rsync. Die Authentifizierung erfolgt unverschlüsselt durch eine Benutzeridentifikation auf dem Server-System. Zur Adressierung werden Dateinamen verwendet, die der Server verstehen muß. Ein ftp- Klient sorgt normalerweise für eine gewisse Zuordnung von lokalen Namen zu Server-Namen. Prinzipiell könnte der Server Namen abbilden, um virtuelle Hierarchien vorzutäuschen.

33 33 Wesentliche Kommandos und Protokoll-Anweisungen: ftp-klient FTP-Protokoll login USER username anmelden PASS password help HELP Hilfe help command HELP command SYST Server-Identifikation status 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) binary TYPE I Datenübertragung PORT h,h,h,h,p,p Port des Klienten für data-verbindung [proxy] PASV Server erzeugt Port für data- Verbindung get remote-path RETR path Datei zum Klienten übertragen put local-path STOR path Datei zum Server übertragen append local-path APPE path an Datei auf Server anfügen [sunique] STOU path Server konstruiert eindeutigen Namen interrupt ABOR Übertragung abbrechen quit QUIT Verbindung beenden Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das normalerweise aus return und linefeed besteht; im TELNET-Protokoll können andere Repräsentierungen verhandelt werden.

34 34 $ telnet localhost ftp 220 next FTP server (Version 5.1 (NeXT 1.0) Thu Nov 3, 1994) ready. help 214- The following commands are recognized (* =>'s unimplemented). USER PORT STOR MSAM* RNTO NLST MKD CDUP PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE REIN* MODE MSND* REST XCWD HELP PWD MDTM QUIT RETR MSOM* RNFR LIST NOOP XPWD 214 Direct comments to ftp-bugs@next. syst 215 UNIX Type: L8 Version: BSD-43 stat 211- next FTP server status: Version 5.1 (NeXT 1.0) Thu Nov 3, 1994 Connected to localhost Waiting for user name TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream No data connection 211 End of status type i 200 Type set to I. user ftp 331 Guest login ok, send ident as password. pass axel 230 Guest login ok, access restrictions apply. pwd 257 "/" is current directory. stat status of.: total 5 -rw-r--r wheel 379 Feb 26 07:28 README -rw-r--r wheel 0 Oct TIMESTAMP drwxr-xr-x wheel 1024 Sep bin lrwxrwxrwx wheel 3 Nov dev -> etc drwxr-xr-x wheel 1024 Nov etc drwxr-xr-x wheel 1024 Apr 12 06:35 pub drwxr-xr-x wheel 1024 Sep usr 211 End of Status pasv 227 Entering Passive Mode (127,0,0,1,10,249) retr README 150 Opening ASCII mode data connection for README (379 bytes). 226 Transfer complete. quit 221 Goodbye. Der Empfang kann in einer zweiten telnet-session erfolgen: $ telnet localhost `expr 10 \* ` / root directory of axel's ftp server bin/ support programs etc/ support files pub/ things that can be downloaded usr/ support programs

35 3.5 SMTP Im Prinzip ist elektronische Post trivial und uralt: mymail () { # to < body if [ "$1" ]; then { echo From "`whoami` `date '+%a %b %e %H:%M:%S %Y'`" cat echo } >> /var/mail/$1 else echo >&2 usage: mymail to < body return 1 fi } Diese Funktion hängt eine Kopfzeile (signifikant ist From mit einem Leerzeichen und neuerdings das Format des Datums), den Brieftext und eine Leerzeile an eine Datei an, aus der der Empfänger seine Post liest. /usr/bin/mail wird sowohl zum Lesen als auch zum lokalen Schreiben der Briefe verwendet: -r-xr-sr-x 1 root mail Aug 25 18:05 /usr/bin/mail drwxrwxr-x 4 root mail 92 Jan 9 07:05 /var/mail -rw axel mail 0 Jan 9 07:10 /var/mail/axel Das setgid-bit ist nötig, damit ein Benutzer mit mail seine leere Mailbox löschen kann. Zum Schreiben muß mail durch den Empfänger ausgeführt werden; dazu wird ein privilegierteres Programm wie sendmail oder qmail eingeschaltet, das auch zur Verteilung im Netz dient: 35 Schreiber mail Absender konstruiert Sendung, liefert per IPC an Sender. Sender sendmail root überträgt. Empfänger sendmail root übernimmt vom Netz, stellt zu oder vermittelt weiter. Zusteller mail Empfänger liefert Sendung lokal ab. Leser mail Empfänger verwaltet empfangene Sendungen. Die Zustellung ist ein Routing-Problem mit altersbedingt sehr komplizierten Adreßformaten, die in sendmail mit sehr eigenwilligen Techniken analysiert und umformuliert werden. SMTP dient nur zum Dateitransfer zwischen Sender und Empfänger, nicht zum Mail-Routing.

36 36 Wesentliche Protokoll-Anweisungen (RFC 821 und /usr/share/sendmail/helpfile): HELP topic HELO hostname MAIL FROM:<sender> RCPT TO:<empfaenger> DATA RSET QUIT VRFY <adresse> EXPN <adresse> gibt Hilfestellung beschreibt Absender definiert (einen!) Sender definiert je einen Empfänger gefolgt von Text bis Zeile mit Punkt initialisiert neu baut Verbindung ab verifiziert eine Adresse expandiert Adresse, zum Beispiel als Liste Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das aus return und linefeed besteht. Der mit DATA übermittelte ASCII-Text unterliegt prinzipiell keinen Regeln, kann aber nach RFC 822 aus einem Umschlag mit Systeminformationen und dem eigentlichen Text bestehen, der dann weiter codiert sein kann (RFC 2045 und folgende). Der Umschlag besteht aus einer Folge von Textzeilen am Anfang, die mit der ersten leeren Zeile abgeschlossen wird. Der Umschlag enthält mindestens Absender und Ziel. Typisch sind: Date: Sende-Datum Return-path: Route zum Absender Received: from Sender by Receiver... ; Datum From: Absender Reply-to: vorrangige Antwort-Adresse To: Ziel-Adresse Subject: Titel Zeilen können durch Einrücken fortgesetzt werden; Kommentare stehen in verschachtelten runden Klammern. SMTP kümmert sich nicht um Authentifizierung diese ist Aufgabe der verbundenen Systeme. SMTP sorgt für eine problemorientierte Adressierung die jedoch erst durch viele zusätzliche Protokolle spezifiziert wird. SMTP kümmert sich selbst nicht um Codierung der Inhalte dies ist eine wichtige Aufgabe für den Umschlag. DATA eignet sich zunächst nur zur Übertragung von Textzeilen. Dabei wird ein führender Punkt vom Klienten verdoppelt, damit der Server das Ende des Kommandos eindeutig erkennen kann.

37 3.6 POP3 Mit dem Post Office Protocol POP (RFC 1939) soll ein Klient Briefe von einem Server abholen: 37 Die Architektur geht von einem einzigen Briefkasten pro Benutzer auf dem Server aus und erlaubt nur eine synchrone Verwaltung der Briefe (abholen, löschen), die insbesondere nicht vorsieht, daß neu ankommende Briefe entdeckt werden. Ähnlich wie FTP hat das Protokoll Zustände: Es gibt folgende Kommandos: Zustand +OK -ERR USER name A,A1 A1 A wählt Briefkasten PASS password A1 T A authentifiziert APOP name string A T A wählt Briefkasten und authentifiziert STAT T T - liefert Anzahl Briefe und Anzahl Zeichen LIST T T T liefert Briefnummer und Zeichen per Brief LIST m T T T liefert Briefnummer m und Anzahl Zeichen UIDL [m] T T T ähnlich, liefert persistente unique id RETR m T T T liefert Brief m DELE m T T T markiert Brief als gelöscht (nicht mehrfach!) NOOP T T - keine Operation, unterbricht Zeitschranke RSET T T - markiert alle Briefe als ungelöscht QUIT A,A1 exit - beendet Zugriff QUIT T U,exit U,exit beendet Zugriff, löscht wenn möglich TOP m n T T T liefert Header plus n Zeilen Bei den Kommandos wird Groß- und Kleinschreibung nur in den String-Argumenten unterschieden. Die Strings beginnen nach einem Leerzeichen und reichen bis zum Zeilenende, das aus return und linefeed besteht. POP3 kümmert sich um Authentifizierung diese kann auch verschlüsselt erfolgen. POP3 realisiert benutzerfreundliche Namen für die Briefkästen und sorgt für eine triviale, eigentlich nicht persistente Adressierung der Briefe. POP3 kümmert sich wie SMTP selbst nicht um Codierung der Inhalte. RETR und andere Kommandos mit multi-line Antworten eignen sich zunächst nur zur Übertragung von Textzeilen. Dabei wird ein führender Punkt vom Server verdoppelt, damit der Klient das Ende der Antwort eine Zeile mit einem Punkt eindeutig erkennen kann. POP3 eignet sich für interaktive Leseprogramme ebenso wie für reine Modem-Transfers. Der wesentliche Haken ist die Einschränkung, daß neu ankommende Briefe nicht eingeschleust werden können und daß bei Abbruch der Verbindung mindestens 10 Minuten gewartet wird, bevor der Biefkasten erneut für POP3 zugänglich ist.