Seminarband "TCP/IP" Illustrated - Fakultät für Mathematik und

Berichte zur Rechnerarchitektur
Band 12
ISSN 0949-3042
Nr. 1 (2006)
$
'
Technischer Bericht
&
%
Seminarband
„TCP/IP Illustrated“
Friedrich-Schiller-Universität Jena
Institut für Informatik
Lehrstuhl für Rechnerarchitektur
und -kommunikation
Hrsg.:
Prof. Dr.-Ing. W. Erhard
Christian Kauhaus (Hrsg.)
Christian Kauhaus (Hrsg.)
Seminarband „TCP/IP Illustrated“
Berichte zur Rechnerarchitektur
Seminarband
TCP/IP Illustrated
Christian Kauhaus (Hrsg.)
Sommersemester 2006
Herausgeber der Reihe:
Prof. Dr.-Ing. Werner Erhard
Lehrstuhl für Rechnerarchitektur und -kommunikation
Institut für Informatik
Ernst-Abbe-Platz 1–2
07743 Jena, Deutschland
ISSN 0949-3042
23. Dezember 2006
c Friedrich-Schiller-Universität Jena
Inhaltsverzeichnis
0. Vorwort
1
I.
3
Internetschicht
1. Internet Protocol (IP)
1.1. Einleitung . . . . . . . . . . . . . . . .
1.1.1. Das TCP/IP-Referenzmodell . .
1.1.2. Einordnung des IP . . . . . . .
1.2. Aufgaben des IP . . . . . . . . . . . . .
1.3. Eigenschaften des IP . . . . . . . . . .
1.4. Das IP-Datagramm . . . . . . . . . . .
1.4.1. Aufbau . . . . . . . . . . . . .
1.4.2. Der IP-Header . . . . . . . . .
1.5. IP-Adressierung . . . . . . . . . . . . .
1.5.1. Die Transportprotokollnummer
1.5.2. Die Internet-Adresse . . . . . .
1.5.3. Classful Addressing . . . . . .
1.5.4. Subnet Addressing . . . . . . .
1.5.5. Classless Inter-Domain Routing
1.6. IP-Routing . . . . . . . . . . . . . . . .
1.7. IP Version 6 . . . . . . . . . . . . . . .
1.7.1. Adressierung . . . . . . . . . .
1.7.2. Der IPv6-Header . . . . . . . .
1.7.3. IPv6-Neuerungen . . . . . . . .
1.7.4. Ausblick . . . . . . . . . . . .
1.8. Fazit . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
5
6
7
7
7
9
10
10
11
11
12
13
14
14
14
15
16
16
2. Internet Control Message Protocol (ICMP)
2.1. Einführung . . . . . . . . . . . . . . . . .
2.2. Einordnung des ICMP . . . . . . . . . . .
2.3. Aufbau . . . . . . . . . . . . . . . . . . .
2.4. Aufgaben . . . . . . . . . . . . . . . . . .
2.4.1. Fehlermeldungen . . . . . . . . . .
2.4.2. Anfragen . . . . . . . . . . . . . .
2.5. Kleiner Exkurs: Mobile IP . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
18
18
23
27
3. IP – Routing und Traceroute
3.1. Einführung . . . . . . . . . . . . . . . . .
3.2. Grundlagen des IP-Routing . . . . . . . . .
3.2.1. Optimale Wege in Netzwerken . . .
3.3. Statisches (Next-Hop-)Routing . . . . . . .
3.3.1. Versenden von Daten im Netzwerk .
3.3.2. IP-Routing-Algorithmus . . . . . .
3.3.3. Routing-Tabelle . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
30
31
31
33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
Inhaltsverzeichnis
3.3.4. Aufbau und Modifikation der Routing-Tabelle .
3.4. Traceroute . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1. Funktionsweise von Traceroute . . . . . . . .
3.4.2. Ausgabe von Traceroute . . . . . . . . . . . .
3.4.3. Anwendungsmöglichkeiten von Traceroute . .
3.5. Zusammenfassung . . . . . . . . . . . . . . . . . . .
4. Dynamic Routing: RIP, OSPF, BGP
4.1. Einführung . . . . . . . . . . . . . . . . . . . . . .
4.2. Dynamic Routing . . . . . . . . . . . . . . . . . . .
4.3. Routing Information Protocol (RIP) . . . . . . . . .
4.3.1. Nachrichtenformat . . . . . . . . . . . . . .
4.3.2. Standard-Operationen . . . . . . . . . . . .
4.3.3. Metrics . . . . . . . . . . . . . . . . . . . .
4.3.4. Nachteile . . . . . . . . . . . . . . . . . . .
4.4. Open Shortest Path First (OSPF) . . . . . . . . . . .
4.5. Autonome Systeme und das Border Gateway Protocol
4.6. Zusammenfassung . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
35
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
39
39
40
41
41
41
42
43
II. Transportschicht
5. User Datagram Protocol (UDP)
5.1. Einleitung . . . . . . . . . . . . . . . . . . . . . .
5.2. UDP im Detail . . . . . . . . . . . . . . . . . . .
5.2.1. Eigenschaften . . . . . . . . . . . . . . . .
5.2.2. Header . . . . . . . . . . . . . . . . . . .
5.3. Experimente . . . . . . . . . . . . . . . . . . . . .
5.3.1. Vorüberlegungen . . . . . . . . . . . . . .
5.3.2. Experiment: Input-Queue . . . . . . . . . .
5.3.3. Experiment: Restricting Local IP Address .
5.3.4. Experiment: Restricting Foreign IP Address
5.4. Zusammenfassung . . . . . . . . . . . . . . . . .
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
47
47
47
48
48
48
49
49
50
6. Transmission Control Protocol (TCP) – Interactive Data Flow
6.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Eigenschaften von TCP . . . . . . . . . . . . . . . . . . . . . . .
6.3. TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2. TCP-Pseudoheader . . . . . . . . . . . . . . . . . . . . .
6.4. Datentransfer mittels TCP . . . . . . . . . . . . . . . . . . . . .
6.4.1. Experiment: Interaktiver Datenaustausch . . . . . . . . .
6.4.2. Experiment: Delayed Acknowledgement . . . . . . . . .
6.4.3. Experimente: Nagle-Algorithmus . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
51
53
53
54
54
55
56
57
7. TCP – Verbindungsaufbau und -abbau
7.1. Verbindungsaufbau . . . . . . . . . . . . . . . . . . . .
7.1.1. Drei-Wege-Verbindungsaufbau . . . . . . . . . .
7.1.2. Wiederholte Übermittlung von SYN-Segmenten
7.2. Verbindungsabbau . . . . . . . . . . . . . . . . . . . . .
7.2.1. Allgemeiner Vier-Wege-Verbindungsabbau . . .
7.2.2. Half-Close . . . . . . . . . . . . . . . . . . . .
7.3. Zustandsdiagramm . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
61
62
62
63
64
VI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
7.3.1. Der Zustand TIME_WAIT . . . . . . . . . . .
7.4. Resetsegmente . . . . . . . . . . . . . . . . . . . . .
7.4.1. Verbindungsaufbau zu einem unbesetzten Port
7.4.2. Verbindungsabbruch . . . . . . . . . . . . . .
7.5. Zusammenfassung . . . . . . . . . . . . . . . . . . .
8. TCP Bulk Data Flow
8.1. Einführung . . . . . . . . . . .
8.1.1. Grundlagen . . . . . . .
8.1.2. Sliding Window . . . .
8.1.3. Window Scaling . . . .
8.2. Congestion Control . . . . . . .
8.2.1. Slow Start . . . . . . . .
8.2.2. Congestion Avoidance .
8.3. Experiment . . . . . . . . . . .
8.3.1. Idee . . . . . . . . . . .
8.3.2. Durchführung . . . . . .
8.3.3. Beobachtungen . . . . .
8.4. Weitere Probleme . . . . . . . .
8.4.1. Long Fat Pipe Networks
8.4.2. Silly Window Syndrome
8.5. Abschließendes . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
67
67
67
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
69
70
71
72
72
73
73
73
73
73
77
77
77
78
9. TCP – Timeout und Retransmission
9.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . .
9.2. TCP Timer . . . . . . . . . . . . . . . . . . . . . .
9.2.1. Connection Establishment Timer . . . . . . .
9.2.2. Delayed Acknowledgement Timer . . . . . .
9.2.3. Keep Alive Timer und Idle Timer . . . . . .
9.2.4. TCP Persist Timer . . . . . . . . . . . . . .
9.2.5. Maximum Segment Life Wait Timer . . . . .
9.2.6. Retransmission Timer . . . . . . . . . . . .
9.3. TCP Retransmission . . . . . . . . . . . . . . . . .
9.3.1. Retransmission via Timeout . . . . . . . . .
9.3.2. Fast Retransmit . . . . . . . . . . . . . . . .
9.4. Verbesserungen für WLAN-Netzwerke . . . . . . . .
9.4.1. NewReno-Modifikation des Fast Recovery .
9.4.2. Erweiterung der SACK-Option . . . . . . . .
9.4.3. SACK-basierter Loss-Recovery-Algorithmus
9.4.4. Forward RTO-Recovery (F-RTO) . . . . . .
9.5. SYN-Flood-Angriff . . . . . . . . . . . . . . . . . .
9.6. Zusammenfassung . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
79
79
79
80
80
80
80
81
81
82
84
84
84
84
84
84
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III. Anwendungsschicht
10. Domain Name System (DNS)
10.1. Einführung . . . . . . . . . . . . . . . . .
10.1.1. Motivation . . . . . . . . . . . . .
10.1.2. Was ist das DNS? . . . . . . . . . .
10.1.3. Entstehung des DNS . . . . . . . .
10.2. Konzepte . . . . . . . . . . . . . . . . . .
10.2.1. Lexikalischer Aufbau eines Namens
87
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
89
89
89
90
90
VII
Inhaltsverzeichnis
10.2.2. Namensraum . . . . . . . . . . . . . . . .
10.2.3. Zonen . . . . . . . . . . . . . . . . . . . .
10.2.4. Resource Records . . . . . . . . . . . . . .
10.2.5. Inverssuche . . . . . . . . . . . . . . . . .
10.3. DNS-Protokoll . . . . . . . . . . . . . . . . . . .
10.3.1. Header . . . . . . . . . . . . . . . . . . .
10.3.2. Question Section . . . . . . . . . . . . . .
10.3.3. Answer, Authority und Additional Section .
10.3.4. Kompressionsschema . . . . . . . . . . . .
10.4. DNS-Software . . . . . . . . . . . . . . . . . . . .
10.4.1. Resolver . . . . . . . . . . . . . . . . . .
10.4.2. Nameserver . . . . . . . . . . . . . . . . .
10.4.3. Caching . . . . . . . . . . . . . . . . . . .
10.4.4. Beispiel für eine DNS-Anfrage . . . . . . .
10.5. Erweiterungen, Wirtschaft und Politik . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
90
92
93
93
93
94
94
95
95
95
95
96
96
97
11. File Transfer Protocol (FTP)
11.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2. FTP-Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.1. Die Steuerverbindung . . . . . . . . . . . . . . . . . . .
11.2.2. Die Datenverbindung . . . . . . . . . . . . . . . . . . . .
11.3. Verbindungs-Management . . . . . . . . . . . . . . . . . . . . .
11.3.1. Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . .
11.3.2. Datenübertragung und Übertragungsmodi . . . . . . . . .
11.3.3. Verbindungsabbau und Wiederaufnahme der Übertragung
11.4. Das File eXchange Protocol . . . . . . . . . . . . . . . . . . . .
11.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
99
100
102
102
102
106
107
108
110
12. Simple Mail Transfer Protocol (SMTP)
12.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . .
12.2. Funktionsweise . . . . . . . . . . . . . . . . . . . .
12.3. SMTP-Befehle und SMTP-Status-Code . . . . . . .
12.3.1. SMTP-Befehle . . . . . . . . . . . . . . . .
12.3.2. SMTP-Status-Code . . . . . . . . . . . . . .
12.4. Extended SMTP (ESMTP) . . . . . . . . . . . . . .
12.4.1. AUTH . . . . . . . . . . . . . . . . . . . . .
12.4.2. STARTTLS . . . . . . . . . . . . . . . . . .
12.4.3. ESMTP-Beispiel . . . . . . . . . . . . . . .
12.5. Mail-Relaying . . . . . . . . . . . . . . . . . . . . .
12.5.1. Offenes Mail-Relay . . . . . . . . . . . . . .
12.5.2. SMTP-Relay-Server . . . . . . . . . . . . .
12.5.3. Beispiele . . . . . . . . . . . . . . . . . . .
12.6. E-Mail-Routing über SMTP und DNS . . . . . . . .
12.6.1. Beispiel: MX-Record . . . . . . . . . . . . .
12.6.2. Beispiel: Zielhost nicht erreichbar . . . . . .
12.7. Aufbau einer E-Mail . . . . . . . . . . . . . . . . .
12.7.1. Header . . . . . . . . . . . . . . . . . . . .
12.7.2. Multimedia Internet Mail Extensions (MIME)
12.8. Zusammenfassung . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
111
111
112
112
112
112
114
114
114
115
115
115
115
116
116
117
118
118
119
120
VIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
13. Network File System (NFS)
13.1. Allgemeine Informationen zu NFS . . . . . . . . . . . . . . . . . . . .
13.2. Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.1. Funktionsweise von RPC . . . . . . . . . . . . . . . . . . . . .
13.2.2. Aufbau von SunRPC-Nachrichten . . . . . . . . . . . . . . . .
13.2.3. External Data Representation (XDR) . . . . . . . . . . . . . .
13.2.4. Portmapper und Daemons . . . . . . . . . . . . . . . . . . . .
13.3. Das NFS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1. Ablauf eines NFS-Zugriffs . . . . . . . . . . . . . . . . . . . .
13.3.2. Dateizugriff via File Handles . . . . . . . . . . . . . . . . . . .
13.3.3. Einbinden von NFS auf dem Client . . . . . . . . . . . . . . .
13.3.4. Die NFS-Prozeduren . . . . . . . . . . . . . . . . . . . . . . .
13.3.5. Zustandslosigkeit und Idempotenz . . . . . . . . . . . . . . . .
13.4. Experimente rund um NFS . . . . . . . . . . . . . . . . . . . . . . . .
13.4.1. Experiment: Einfache NFS-Zugriffe . . . . . . . . . . . . . . .
13.4.2. Experiment: NFS-Zugriffe während eines Verbindungsabbruchs
13.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
121
121
121
121
122
123
123
124
124
124
124
126
126
127
127
127
129
131
IX
Abbildungsverzeichnis
1.1.
1.2.
1.3.
1.4.
1.5.
Vergleich von ISO/OSI- und TCP/IP-Referenzmodell.
Header eines IP-Datagramms. . . . . . . . . . . . . .
Übersicht über die Netzklassen. . . . . . . . . . . . .
Klasse-B-Netz mit 32 Subnets. . . . . . . . . . . . .
Format des IPv6-Headers. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
. 8
. 12
. 12
. 15
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
2.10.
2.11.
2.12.
2.13.
2.14.
ICMP im TCP/IP-Schichtenmodell. . . . . . . . . . . . . .
Aufbau des ICMP-Headers. . . . . . . . . . . . . . . . . .
Lebenszeit überschritten. . . . . . . . . . . . . . . . . . .
ICMP-Pakete von verschiedenen Fehlermeldungen. . . . .
Ungültige Parameter. . . . . . . . . . . . . . . . . . . . . .
Source Quench. . . . . . . . . . . . . . . . . . . . . . . .
Redirect. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Destination Unreachable. . . . . . . . . . . . . . . . . . .
Synchronisation zweier Uhren durch ICMP Timestamps. . .
ICMP-Pakete für verschiedene Anfragen. . . . . . . . . . .
Router Discovery. . . . . . . . . . . . . . . . . . . . . . .
Pfad-MTU. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mobile IP mit Hilfe von ICMP. . . . . . . . . . . . . . . .
Erweiterter ICMP-Header mit Daten zum Erhalt der Router.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
19
20
20
22
22
22
24
24
25
26
26
27
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
3.9.
Schema des Internet. . . . . . . . . . . . . . . .
Graphenbeschreibung einer Netzwerktopologie.
Minimum Spanning Tree. . . . . . . . . . . . .
Direkte und indirekte Zustellung. . . . . . . . .
Beispielnetzwerk. . . . . . . . . . . . . . . . .
IP-Routing-Algorithmus. . . . . . . . . . . . .
Routing-Tabelle. . . . . . . . . . . . . . . . . .
Funktionsweise von Traceroute. . . . . . . . . .
Ausgabe von Traceroute. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
30
32
32
33
36
36
4.1.
4.2.
4.3.
4.4.
4.5.
Übersicht des Routing-Vorgangs.
RIP-Einkapselung. . . . . . . . .
RIP-Header. . . . . . . . . . . .
RIP-Metrics. . . . . . . . . . . .
OSPF-Header. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
41
42
5.1.
5.2.
UDP-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
UDP-Pseudoheader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.
6.2.
6.3.
6.4.
6.5.
Verbindungsorientierte Kommunikation.
TCP-Header. . . . . . . . . . . . . . . .
TCP-Pseudoheader. . . . . . . . . . . .
TCP-Traffic-Analyse . . . . . . . . . . .
Aufbau Experiment 1. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
53
54
55
55
XI
Abbildungsverzeichnis
6.6.
6.7.
6.8.
6.9.
6.10.
6.11.
6.12.
6.13.
Variante 1 der Übertragung eines Zeichens an ein Remote-System.
Variante 2 der Übertragung eines Zeichens an ein Remote-System.
Delayed Acknowledgement auf Client-Seite. . . . . . . . . . . . .
Aufbau Experiment 2. . . . . . . . . . . . . . . . . . . . . . . . .
Datenstrom Experiment 2. . . . . . . . . . . . . . . . . . . . . . .
Aufbau Experiment 3. . . . . . . . . . . . . . . . . . . . . . . . .
Betätigen einer Funktionstaste. . . . . . . . . . . . . . . . . . . .
Datenstrom Experiment 3. . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
56
57
57
58
58
58
7.1.
7.2.
7.3.
7.4.
Der Drei-Wege-Verbindungsaufbau. . . . . . . . . . . . . . .
(a) Der 500ms-Timer und (b) Vier-Wege-Verbindungsabbau. .
Half-Close. . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP-Zustandsüberführungsdiagramm. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
62
64
65
8.1.
8.2.
8.3.
8.4.
8.5.
8.6.
8.7.
8.8.
8.9.
8.10.
Sliding Window. . . . . . . . . . . . . . . . . . . . . . . . . . .
Zyklisches Verhalten der Sequenznummern. . . . . . . . . . . .
Verlauf des Congestion Window. . . . . . . . . . . . . . . . . . .
Verlauf des CWND und Slow Start Threshold bei Paketverlusten.
Slow Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Start mit kleinem Receive Window. . . . . . . . . . . . . . . . .
Slow Start nach schwerem Paketverlust. . . . . . . . . . . . . .
Congestion Avoidance nach leichtem Paketverlust. . . . . . . . .
Überblick des Datenstroms vom ersten Rechner. . . . . . . . . .
Überblick des Datenstroms vom zweiten Rechner. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
71
72
73
74
74
75
75
76
76
9.1.
9.2.
Prinzipieller Ablauf des Retransmission via Timeout. . . . . . . . . . . . . . . . . . . . . . . . 81
Fast Retransmit in der Praxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.1.
10.2.
10.3.
10.4.
10.5.
10.6.
10.7.
DNS-Protokoll im TCP/IP-Protokollstapel.
Namensbaum und ein paar Begriffe. . . . .
Namensbaum mit Zonenmarkierungen. . .
DNS-Protokoll – allgemeines Paketformat.
DNS-Protokoll – Flags. . . . . . . . . . .
DNS-Protokoll – Question Section. . . . .
DNS-Protokoll – Nonquestion Section. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
91
91
93
93
94
94
11.1. FTP im TCP/IP-Schichtenmodell. . . . . . . . . . . . . . . . . . . . . . . . . .
11.2. Eine Client-Server-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3. Darstellung einer Client-Server-Verbindung des File Transfer Protocols. . . . .
11.4. Aufbau der Steuerverbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5. Befehlsabfolge zur Anmeldung am Server. . . . . . . . . . . . . . . . . . . . .
11.6. Aufbau der Datenverbindung im Standard-Modus. . . . . . . . . . . . . . . . .
11.7. Aufbau der Datenverbindung im Port-Modus. . . . . . . . . . . . . . . . . . .
11.8. Aufbau der Datenverbindung im Passive-Modus. . . . . . . . . . . . . . . . . .
11.9. Übertragung der Daten beim File Transfer Protocol. . . . . . . . . . . . . . . .
11.10. Abbau der Steuerverbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.11. Befehlsabfolge bei der Wiederaufnahme der Datenübertragung. . . . . . . . . .
11.12. Darstellung einer FXP-Verbindung zwischen einem Client und zwei Servern. . .
11.13. Befehlsabfolge zum Aufbau der Datenverbindung beim File eXchange Protocol.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
101
103
103
104
105
105
106
107
108
109
109
12.1.
12.2.
12.3.
12.4.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
116
118
119
XII
.
.
.
.
.
.
.
SMTP-Kommunikationsmodell. . . . . . . .
Ein Relay-System von zwei Organisationen.
E-Mail-Routing über SMTP und DNS. . . .
Typischer E-Mail-Header. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungsverzeichnis
12.5. Eine einfache Multipart-Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
13.1.
13.2.
13.3.
13.4.
13.5.
13.6.
13.7.
13.8.
NFS im OSI-Schichtenmodell. . . . . . . . . . . . . . . . . . . . . . . .
Aufruf eines RPC und Rückgabe eines RPC. . . . . . . . . . . . . . . . .
Aufbau eines aufrufenden RPC und Antwort unter Verwendung von UDP.
Aufbau eines NFS-Systems. . . . . . . . . . . . . . . . . . . . . . . . . .
Ablauf eines Aufruf des mount-Befehls. . . . . . . . . . . . . . . . . . .
Verzeichnisstruktur aus Sicht des Clients. . . . . . . . . . . . . . . . . . .
Struktureller Aufbau und Ablauf des 1. Experiments . . . . . . . . . . . .
Struktureller Aufbau und Ablauf des 2. Experiments. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
121
122
123
125
125
126
128
128
XIII
Tabellenverzeichnis
1.1. Ausgewählte Transportprotokollnummern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Netzmasken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Nachrichtentypen bei ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Typische Werte von TCP-Timern in der Praxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.1. Eine Auswahl verschiedener FTP-Befehle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
11.2. Bedeutung des 3-stelligen Antwortcodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.1. SMTP im TCP/IP-Protokollstapel.
12.2. Grundlegende SMTP-Befehle. . .
12.3. Übersicht der SMTP-Status-Codes.
12.4. ESMTP-Befehle. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
113
113
114
XV
0. Vorwort
Christian Kauhaus
Der vorliegende Band ist entstanden aus den
Arbeiten zum Rechnerarchitektur-Hauptseminar
„TCP/IP Illustrated“ im Sommersemester 2006
an der Friedrich-Schiller-Universität Jena. In dem
Seminar ging es darum, sich auf die Spuren von
W. Richard Stevens’ gleichnamigem Netzwerkklassiker [Ste94] zu begeben. Obwohl das Werk für
Informatik-Verhältnisse schon sehr alt ist, besticht es
durch den bemerkenswerten didaktischen Ansatz, die
Grundlagen der Netzwerktechnik durch eine Reihe
von einfachen Versuchen dem Leser nahezubringen.
Das wollten wir im Seminar nachvollziehen.
Freilich hat sich in den vergangen 12 Jahren vieles
verändert, und nicht alles von dem, was Stevens vermittelt, ist noch aktuell. Daher war ein weiteres Anliegen des Seminars, die Inhalte des Werks mit dem
aktuellen Stand der Netzwerktechnik in Beziehung zu
setzen. Es ist interessant zu sehen, welche der damals angesprochenen „aktuellen Probleme“ auch heute noch Bestand haben und über welche man nur noch
schmunzeln kann. Die Beiträge im vorliegenden Band
beziehen aktuelle Entwicklungen so weit wie möglich
mit ein.
Da Stevens’ Werk dick und das Semester kurz ist,
musste eine Stoffauswahl getroffen werden. Das Seminar gliederte sich in drei Hauptteile, die den Ebenen 2 bis 4 des TCP/IP-Referenzmodells entsprechen: Internet-, Transport- und Anwendungsschicht.
Auch der vorliegende Band entspricht dieser Grobgliederung. Aus jeder dieser drei Ebenen wurden repräsentative Einzelthemen herausgegriffen. Dennoch
sind Lücken zu verzeichnen; beispielsweise fehlt auf
der Anwendungsschicht das wichtige HTTP. Auch die
unterste Ebene des Referenzmodells war im Seminar
nicht umfangreich vertreten und konnte im Band gar
nicht berücksichtigt werden. Weiterhin werden viele der Experimente, die wir im Seminar durchgeführt
haben, aus Platzgründen hier nur angedeutet oder gar
nicht erwähnt. Dennoch hoffe ich, dass die angebotene Stoffauswahl trotz ihrer Lücken einen guten Einstieg in die Welt der TCP/IP-Netzwerke bietet und
Lust aufs Weiterlesen weckt. Als umfassendere Einführungen bieten sich z. B. die Werke von Comer oder
Tanenbaum [Com00, Tan02] an.
Danken möchte ich allen, die zum Gelingen dieses Bandes beigetragen haben. An erster Stelle sind
hier die Seminarteilnehmer zu nennen, die bei der
Vorbereitung der Vorträge und Zusammenstellung der
Ausarbeitungen einen großen Einsatz gezeigt haben.
Weiterhin danke ich auch allen Kollegen am Lehrstuhl für Rechnerarchitektur und -kommunikation, die
mich unterstützt haben.
Jena, im Dezember 2006
Christian Kauhaus
1
Teil I.
Internetschicht
1. Internet Protocol (IP)
Pascal Lenzner
1.1. Einleitung
1.1.1. Das TCP/IP-Referenzmodell
Das TCP/IP-Referenzmodell ist ein aus vier Ebenen
bestehendes Schichtenmodell für die Kommunikation in Netzwerken. Jede Schicht besteht aus mehreren
Protokollen, welche das genaue Verhalten für den Informationsaustausch festlegen. Die Schichten werden
dabei nach ihren Kernaufgaben abstrahiert und es gilt
das Prinzip, dass eine Schicht einerseits ihrem übergeordneten Nachbarn Dienste anbietet und andererseits die bereitgestellten Dienste der darunter liegenden Schicht nutzt. Die oberste Ebene bildet die Anwendungsschicht und enthält alle anwendungsnahen
Protokolle, wie zum Beispiel das Hypertext Transfer
Protocol (HTTP), das File Transfer Protocol (FTP)
oder das Simple Mail Transfer Protocol (SMTP). Danach folgt die Transportschicht, welche für den Aufbau einer Ende-zu-Ende-Verbindung zwischen Quellund Zielhost verantwortlich ist. Die Internetschicht
bildet die nächste Ebene und diese steuert die Paketzustellung im Netzwerk. Auf der untersten Ebene
des Modells befindet sich die Netzwerkschicht, welche die physikalische Übertragung der Nachrichtensignale organisiert.
Beim Übergang zwischen den Schichten findet eine Kapselung statt, d. h. jede Schicht versieht die behandelten Daten mit spezifischen Kontrollinformationen, welche aufgrund ihrer vorangestellten Position
als Header bezeichnet werden, und gibt das Gesamtpaket an die nächste Ebene weiter.
Obwohl das TCP/IP-Referenzmodell eigenständig
entwickelt wurde, ist es vom Aufbau her eng mit dem
ISO/OSI-Referenzmodell verwandt. Abbildung 1.1
zeigt einen direkten Vergleich zwischen beiden.
(IP), welches als Herzstück der Internetschicht im
TCP/IP-Referenzmodell zwischen der darüberliegenden Transportschicht und der Netzwerkschicht liegt.
Es nimmt die Segmente des Transmission Control
Protocol (TCP) und die Pakete des User Datagram
Protocol (UDP) entgegen und sendet diese in Form
von IP-Datagrammen weiter an das zugehörige Protokoll in der Netzwerkschicht.
Stevens [Ste94] bezeichnet IP als das Arbeitspferd
des gesamten Protokollstapels und in den folgenden
Ausführungen wird erklärt, warum dies eine sehr treffende Formulierung ist.
1.2. Aufgaben des IP
Die Aufgaben des Internet-Protokolls werden im zugehörigen RFC 791 [Pos81b] wie folgt zusammengefasst:
The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done
by passing the datagrams from one internet
module to another until the destination is
reached.
Doch was hier als Paketvermittlung in Netzwerken beschrieben ist, besteht vielmehr aus einer Menge
von Funktionalitäten, welche das Internet-Protokoll
bereitstellt.
Als Erstes werden im Protokoll IP-Datagramme als
Basiseinheit für die Übermittlung von Daten definiert.
Jede zu übertragende Information wird in ein oder
mehrere Datagramme aufgeteilt und mit der entsprechenden Kontrollinformation durchs Netzwerk geschickt. Diese Fragmentierung, welche eine weitere
Aufgabe des IP darstellt, ist keineswegs trivial, denn
es muss garantiert werden, dass die ankommenden
Daten ohne Verlust auf die erforderliche Anzahl an
1.1.2. Einordnung des IP
Datagrammen aufgeteilt und später beim Empfänger
Einer der Namensgeber dieser Protokollfamilie ist im korrekter Weise wieder zusammengesetzt werden
das in diesem Kapitel betrachtete Internet Protocol können. Die Eigenschaften des IP werden im Detail
5
1. Internet Protocol (IP)
ISO/OSI-Referenzmodell
TCP/IP-Referenzmodell
Anwendungsschicht
Präsentationsschicht
Anwendungsschicht
Sitzungsschicht
Transportschicht
Transportschicht
Vermittlungsschicht
Internetschicht
Sicherungsschicht
Netzwerkschicht
Übertragungsschicht
Abbildung 1.1.: Vergleich von ISO/OSI- und TCP/IP-Referenzmodell.
im Abschnitt „Eigenschaften des IP“ (1.3) besprochen.
Weiterhin leitet das IP die nun korrekt „verpackten“ Daten (zum Aufbau des Header vgl. Abschnitt
„Das IP-Datagramm“, 1.4) an das entsprechende Protokoll aus der Netzwerkschicht, welches für die physikalische Übertragung auf dem jeweils vorhandenen
Transportmedium zuständig ist, weiter. Ein Beispiel
für eine solche Vorschrift wäre das Ethernet-Protokoll
nach IEEE-Standard 802.3.
Doch damit ist die Vermittlung der Daten zwischen
Quell- und Zielhost noch nicht vollzogen. Eine weitere wichtige Aufgabe ergibt sich durch die Frage, wie
denn der Zielhost überhaupt ausfindig gemacht werden soll. Auch hier bietet das Internet-Protokoll die
Lösung an: ein Addressierungsschema, mittels dessen
alle Hosts im Netzwerk eindeutig identifiziert werden
können. Genauere Ausführungen zur dieser Thematik
finden sich im Abschnitt „IP-Adressierung“ (1.5).
Eine letzte Kernaufgabe des Internet-Protokolls
stellt das Routing dar. Damit Daten vom sendenden zum empfangenden Host gelangen, müssen die
Datagramme im Netzwerk korrekt weitergeleitet werden. Auch dies ist eine schwierige Aufgabe, denn
die Topologie des Netzwerks ist dem sendenden Host
im Normalfall nicht bekannt. Die Lösung hierfür ist
ein Routingalgorithmus, der die Pakete „hop-by-hop“
weitersendet, bis diese das spezifizierte Ziel erreicht
haben. Nähere Erläuterungen liefert der Abschnitt
„IP-Routing“ (1.6).
6
1.3. Eigenschaften des IP
Obwohl das Internet-Protokoll für solch grundlegende Aufgaben bei der Datenübertragung zuständig ist,
zeichnet es sich durch zwei vielleicht überraschende
Eigenschaften aus: Es ist unzuverlässig und zusammenhangslos.
Die Unzuverlässigkeit bezieht sich darauf, dass es
keine Garantie gibt, dass ein Datagramm auch wirklich sein designiertes Ziel im Netzwerk erreicht. IP
bietet lediglich Routing „nach bestem Bemühen“ an
und überlässt es den höher liegenden Protokollen,
für eine sichere Übertragung zu sorgen. Weiterhin
wird für die Paketübertragung keine Ende-zu-EndeVerbindung etabliert.
Auch die Fehlerbehandlung, sofern man diese als
solche bezeichnen kann, trägt zu dieser Eigenschaft
bei. Tritt bei der Übertragung eines Datagramms ein
Problem auf, so ist die Vorgehensweise des InternetProtokolls die Folgende: Zuerst wird das Datagramm
verworfen, danach wird versucht, eine InternetControl-Message-Protocol-(ICMP)-Nachricht an den
Sender zu verschicken (zu ICMP siehe Kapitel 2). Allerdings gibt es dabei keine Überprüfung, ob diese
Fehlermeldung auch wirklich bei der Quelle des Datagramms ankommt.
Ein weiterer Fakt, der die Einstufung als unzuverlässig rechtfertigt, ist die nicht vorhandene Möglichkeit zur Entdeckung von Datenfehlern. Im Head-
1.4. Das IP-Datagramm
er wird lediglich eine Prüfsumme des Headerinhalts
mitgeschickt, die Daten an sich werden durch keinerlei Maßnahmen überprüft. Auch hier verlässt sich das
Internet-Protokoll auf die Vorarbeit der Protokolle aus
der Anwendungs- und Transportschicht.
Die Eigenschaft zusammenhangslos steht dafür,
dass das IP keine Informationen über aufeinander folgende Datagramme verarbeitet. Sind die ankommenden Daten erst einmal in IP-Datagramme aufgeteilt,
so wird jedes von ihnen als eigenständig angesehen
und unabhängig von allen anderen Paketen behandelt.
So ist es möglich, dass die einzelnen Datagramme auf
jeweils unterschiedlichen Routen zum Zielhost gelangen und dass diese dort in einer anderen Reihenfolge
ankommen.
Noch zu erwähnen ist hier die Unabhängigkeit von
der vorliegenden Netzwerkstruktur, welche man auch
als Robustheit bezeichnen könnte. Die Paketzustellung erfolgt immer auf die gleiche Weise, egal ob der
Zielhost direkt mit dem Sender verbunden ist oder ob
dieser weit entfernt liegt und nur durch mehrere andere Netzwerke erreichbar ist. Diese Tatsache und zusätzlich die einfache Spezifikation des Protokolls sowie die Konzentration auf die Kernaufgaben der Paketübermittlung haben wohl zum großen Erfolg des
IP und seiner bis heute zentralen Stellung geführt.
1.4. Das IP-Datagramm
1.4.1. Aufbau
Der Aufbau wird in Abbildung 1.2 verdeutlicht.
Dabei gilt, dass das höchstwertige Bit das Bit 0 ganz
links und das niederwertigste Bit das Bit 31 am rechten Rand ist. Die einzelnen Bytes werden hierbei im
Modus big endian1 übermittelt.
Die einzelnen Felder haben folgende Bedeutung:
Version Dieses Feld gibt an welche Version des
Internet-Protokolls verwendet wird. Dabei gibt es
heute nur zwei Möglichkeiten: Version 4, auch IPv4
genannt und Version 6, welches als IPv6 oder IP next
generation (IPnG) bezeichnet wird. Erstere ist zur
Zeit noch der Standard.
IHL Die Abkürzung IHL steht für Internet Header Length und bezeichnet die Länge des Headers in
32 bit-Worten. Dabei ist das Minimum 5, also 20 B
und das Maximum 15, was 60 B entspricht. Dieser
Maximalwert der Headerlänge schränkt somit den
Platz für das Optionsfeld auf 40 B ein.
Type Of Service Wird auch mit TOS bezeichnet
und legt die Behandlung des Datagramms fest.
Die 8 bit dieses Felds setzen sich wie folgt zusammen: Bits 1–3 haben keine Bedeutung und werden
ignoriert, die Bits 4–7 sind die eigentlichen TOS-Bits
und Bit 8 hat keine Funktion, muss allerdings auf 0
gesetzt sein. Die vier TOS-Bits stehen für minimize
delay, maximize throughput, maximize reliability und
minimize monetary cost. Bei der Nutzung gilt, dass
nur jeweils eines der Bits den Wert 1 haben kann. Falls
kein TOS-Bit geschalten ist, so steht dies für Normalbetrieb.
Für viele verschiedene Applikationen gibt es
empfohlene TOS-Werte. Zum Beispiel für Telnet, FTP/Control- und UDP-Anfragen des DNSProtokolls wird eine Behandlung mit minimize delay vorgeschlagen. FTP/Data sollte mit maximize
throughput betrieben werden.
Die TOS-Einstellungen werden von heutigen
TCP/IP-Implementierungen allerdings meist nicht
mehr unterstützt und es wird standardmäßig im Normalbetrieb gearbeitet.
Ein IP-Datagramm besteht aus den zu übertragenden
Daten und den zugehörigen Kontrollinformationen,
dem Header.
Der Header ist mindestens 20 B groß, kann aber
noch einen optionalen Teil mit variabler Länge besitzen. Enthalten sind alle wichtigen Informationen
um ein Datagramm im Netzwerk korrekt zustellen zu
können.
Insgesamt kann ein IP-Datagramm theoretisch bis
zu 64 KiB einnehmen, in der Praxis wird die Größe aber meist auf die maximale Kapazität der Frames (Übertragungseinheiten) der Protokolle aus der
Netzwerkschicht beschränkt. Ein gängiger Wert ist
eine Gesamtgröße von 1500 B, welche der Maximum Transfer Unit (MTU) des Ethernetprotokolls ent- Total Length Hier wird die Gesamtgröße des IPDatagramms in Bytes angegeben. In Kombination mit
spricht.
dem IHL-Feld kann genau bestimmt werden, wo die
eigentlichen Daten beginnen und wie groß diese sind.
1.4.2. Der IP-Header
Der Inhalt des Headers wird in RFC 791 [Pos81b] exakt vorgegeben und ist Thema dieses Abschnitts.
1 Hierbei werden bei einem 32-Bit-Wert zunächst die Bits 0-7,
dann 8-15, danach 16-23 und zuletzt die niederwertigsten Bits
24-31 übertragen.
7
1. Internet Protocol (IP)
8
0
Version
IHL
Type of service
Total length
D M
F F
Identification
Time to live
24
16
Protocol
Fragment offset
Header checksum
Source address
Destination address
Options
Abbildung 1.2.: Header eines IP-Datagramms.
Da hier 16 bit zur Verfügung stehen, beträgt der Maximalwert 64 KiB.
Doch nicht jeder Host ist gezwungen, so große
Datagramme zu akzeptieren: Im RFC 791 wird vorgeschrieben, dass nur Datagramme bis 576 B Länge
angenommen werden müssen.
Die Gesamtlängenangabe wird noch aus einem
weiteren Grund benötigt. Manche Protokolle der
Netzwerkschicht füllen die ankommenden Daten bis
zu einer gewissen Mindestgröße auf. Um nun in einem solchen Frame noch zu erkennen, welche Daten
eigentlich zum IP-Datagramm gehören, wird der Wert
des Total-Length-Felds abgefragt.
Identification Der hier übermittelte Wert wird einerseits für die eindeutige Identifizierung der Pakete
und andererseits für die korrekte Zusammensetzung
von Datenfragmenten gebraucht.
Teilt das Internet-Protokoll ankommende Daten in
mehrere IP-Datagramme auf, so erhalten diese alle die
gleiche Nummer im Identification-Feld. Der Empfänger der Fragmente weiß somit, welche Pakete wieder
zusammengesetzt werden müssen. Pakete, die nicht
fragmentiert wurden, bekommen beim Versenden eine fortlaufend inkrementierte Nummer, um diese eindeutig zu kennzeichnen.
Flags Die folgenden drei Bits im IP-Header sind
für Flags reserviert. Das erste Bit hat keinerlei Ver-
8
wendung, das DF-Flag steht für Don’t Fragment und
das MF-Flag bedeutet More Fragments Follow.
Die Auswirkungen dieser Bits sind schon am Namen erkennbar. Ist das DF-Flag gesetzt, so wird verhindert, dass ein Datenpaket fragmentiert wird. Sollte
dadurch ein Paket nicht mehr weitertransportiert werden können, so wird dieses verworfen. Ein geschaltetes MF-Flag steht dafür, dass das Paket fragmentiert
wurde und noch weitere Fragmente folgen.
Fragment Offset Für die Zusammensetzung
mehrerer Fragmente ist noch eine weitere Angabe
nötig: Die Position des Fragments im Gesamtpaket.
Der Fragment Offset liefert diesen Wert relativ zum
Beginn des Originalpakets. Aufgrund der Feldgröße
von 13 bit können somit insgesamt 8192 Fragmente
pro Datagramm erstellt werden. Die elementare
Fragmenteinheit ist dabei 8 B und deshalb müssen
alle Offset-Werte Vielfache von 8 B sein.
Time To Live Dieses Feld, welches auch abgekürzt als TTL bezeichnet wird, beinhaltet einen Zähler, der die Lebensdauer eines Datagramms begrenzt.
Dieser Wert wird einerseits jede Sekunde und andererseits bei jedem Host, den das Datagramm passiert,
um 1 herabgesetzt. Somit gilt als Obergrenze eine Lebensdauer von 255 s. Erreicht der Zähler den Wert 0,
so wird das Paket sofort verworfen und es wird versucht, eine ICMP-Warnmeldung an den Sender zurück zu schicken. Mit diesem Vorgehen wird verhin-
1.5. IP-Adressierung
dert, dass Datagramme endlos im Netzwerk unterwegs sind.
Protocol Dieses Feld gibt eine Nummer des Protokolls an, an welches das Datagramm beim Empfänger weitergeleitet werden muss. Die Protokollnummern sind weltweit eindeutig festgelegt und werden
von der Internet Assigned Numbers Authority (IANA)
verwaltet. Die Funktionsweise der Protokollnummer
wird genauer in Abschnitt 1.5.1 beschrieben.
Header Checksum Hier wird eine Prüfsumme
des Headerinhalts mitgeführt. Wie bereits erwähnt,
gibt es keine Prüfsumme der eigentlichen Nutzdaten
des Datagramms.
Wichtig ist hierbei, dass diese Prüfsumme von jedem durchlaufenen Host im Netzwerk neu berechnet werden muss, da sich der TTL-Wert ändert. Es
wird aus diesem Grund ein sehr effizientes Verfahren genutzt: Es wird das 1-er Komplement aller 16 bitHalbwörter der Headerdaten verwendet. Als Voraussetzung dafür wird angenommen, dass die Prüfsumme
zu Beginn der Berechnung Null war.
Source address Dieses Feld enthält die 32 bit
lange Internetadresse des Quellhosts.
Destination address Hier wird die 32 bitAddresse des Empfängers festgehalten.
das Datagramm durchlaufen soll. Hierfür gibt es
zwei Varianten: Zum einen das Loose Source and
Record Route und zum anderen Strict Source and
Record Route. In beiden Fällen sollen die angegeben Hosts passiert werden und die genommene Route wird aufgezeichnet, doch beim letzteren Fall müssen die Hosts genau in der Reihenfolge und ohne Zwischenstationen passiert werden.
Allerdings ist diese Option durch den geringen
verfügbaren Platz stark eingeschränkt und heute
im Normalfall unbrauchbar.
• Record Route – diese Option weist alle durchlaufenen Hosts an, ihre Adresse an das Optionsfeld anzuhängen um somit eine Aufzeichnung
der im Netzwerk zurückgelegten Route zu erhalten. Doch auch diese Option ist durch den
geringen Platz für derartige Einträge stark eingeschränkt. Ohne andere Optionen können lediglich neun 32 bit-Adressen aufgenommen werden, heute werden aber meistens deutlich mehr
Hosts von Quelle zu Ziel passiert. Eine bessere Alternative bietet heute das Traceroute (Abschnitt 3.4).
• Timestamp – ähnlich wie Record Route, nur dass
hierbei zusätzlich noch die Zeit beim Passieren
der Netzwerkknoten aufgezeichnet wird.
1.5. IP-Adressierung
Options Dieses Feld variabler Länge bietet Zusatzinformation über das Datagramm und wurde aus
Erweiterungsgründen mit in den Header aufgenommen. Jede Option beginnt mit einem ein Byte langem
Code zur Identifizierung, bei manchen folgt noch ein
weiteres Byte für Optionen und danach kommen ein
oder mehrere zur Option gehörige Datenbytes. Das
Feld wird am Ende immer auf ein Vielfaches von 4 B
aufgefüllt und maximal kann es 40 B groß sein.
Folgende Optionen können verwendet werden:
• End of Option List kennzeichnet das Ende der
Liste der Optionen.
Aufgrund des schon dargestellten Kapselungsprinzips
der TCP/IP-Familie sind vier unterschiedliche Adressen notwendig, um mit einer Applikation auf einem
anderen Host im Netzwerk kommunizieren zu können:
• Für die Netzwerkschicht die Netzwerkadresse, welche eine physikalische Verbindung zum
Ziel ermöglicht. Ein Beispiel für eine solche Adresse wäre die Media-Access-Control(MAC)-Adresse.
• Für die Internetschicht die Internet-Adresse.
• No Option kann zum Auffüllen verwendet werden.
• Für die Transportschicht die Transportprotokollnummer.
• Security bezeichnet, wie geheim das Datagramm
ist. Allerdings wird diese Option in der Praxis
vernachlässigt.
• Für die Anwendungsschicht die Portnummer.
Die Internet-Adresse und die Transportprotokollnummer befinden sich im Header eines IP• Source Routing – bei dieser Option ist eine Datagramms und stehen somit im Mittelpunkt der BeListe von Internet-Adressen vorgegeben, welche trachtung dieses Abschnitts.
9
1. Internet Protocol (IP)
#
Keyword
Protocol
0
1
2
3
4
5
6
7
8
HOPOPT
ICMP
IGMP
GGP
IP
ST
TCP
CBT
EGP
IPv6 Hop-by-Hop Option
Internet Control Message
Internet Group Management
Gateway-to-Gateway
IP in IP (encapsulation)
Stream
Transmission Control
CBT
Exterior Gateway Protocol
Tabelle 1.1.: Ausgewählte Transportprotokollnummern.
1.5.1. Die Transportprotokollnummer
Damit die Adressierung in der Transportschicht immer korrekt erfolgen kann, werden die Nummern der
Protokolle in dieser Schicht von einer zentralen Organisation, der Internet Assigned Numbers Authority
(IANA), verwaltet und aktualisiert.
Als Beispiel soll in Tabelle 1.1 ein Auszug aus der
Liste der zugewiesenen Protokollnummern [Int06d]
dienen. Soll nun zum Beispiel das TCP adressiert werden, so muss im Protocol-Feld im IP-Header der Wert
6 eingetragen sein und IP wird das ankommende Paket dorthin weiterleiten.
1.5.2. Die Internet-Adresse
Die Internet-Adresse besteht beim IP Version 4 (IPv4)
aus 32 bit und die Adressen von Quell- und Zielhost
stehen in jedem IP-Datagramm im Header.
Wichtig ist, dass eine solche Adresse, welche oft
auch als IP-Adresse bezeichnet wird, für eine Verbindung (Interface) eines Hosts mit einem Netzwerk
steht. Jeder Rechner in einem Netzwerk hat somit
mindestens eine Internet-Adresse, falls dieser aber
über mehrere Verbindungen mit diesem Netz kommuniziert, so hat der Host für jede dieser Verbindungen
zum Netzwerk eine eigene Adressnummer.
1.5.2.1. Zuständigkeit
Ähnlich wie bei anderen Adressen muss auch die
IP-Adresse im Netzwerk eindeutig sein, denn sie ist
dafür verantwortlich, Datenpakete zum richtigen Bestimmungsort gelangen zu lassen. Für das größte
Netzwerk der Welt, das Internet, bedeutet dies natürlich, dass jeder angeschlossene Host eine eigene eindeutige Adresse benötigt, was bei einer geschätzten
Zahl von einer Milliarde Hosts [Int06e] eine schwie-
10
rig zu bewältigende Aufgabe ist. Die Lösung basiert
auch hier auf einer zentralen Organisation, die die
Vergabe der IP-Adressen regelt: Die Internet Cooperation for Assigned Names and Numbers (ICANN).
Zuständig für den europäischen Raum ist die Résseaux IP Européens (RIPE).
Als Grundlage für die Vergabe der InternetAdressen dient das RFC 2050 [HKC+ 96], welches die
„Internet Registry IP Allocation Guidelines“ festlegt.
Die vergebenen Adressen unterscheidet man in
Provider-Aggregated (PA) und Provider-Independent
(PI). Die PA-Adressen sind Eigentum einer Einrichtung oder eines Unternehmens, wie zum Beispiel ein
Internet Service Provider (ISP), der die IP-Adressen
eigenständig verwaltet. Die unabhängigen Adressen
hingegen sind direkt an einen Endnutzer gebunden.
1.5.2.2. Aufbau
Üblicherweise wird der 32 bit-Wert nicht binär, sondern durch eine gepunktete Dezimalschreibweise dargestellt, z. B. als
141.35.12.1 .
Dabei ist die niedrigste mögliche Adresse die 0.0.0.0
und die höchste Adresse die 255.255.255.255.
Jede Adresse besteht aus einer Netzadresse und einer Hostadresse, am Beispiel könnte der Netzanteil
die ersten 16 bit umfassen und somit 141.35 lauten,
der Hostanteil würde dann aus den letzten 16 bit bestehen und hätte den Wert 12.1.
Weiterhin gibt es noch ein paar spezielle IPAdressen:
• Besteht die Netzadresse aus lauter Nullen, so bezeichnet diese Adresse einen Host im eigenen
Netz.
• Hat die Adresse die Form 127.x.y.z, so steht dies
für die Loopback-Adresse und das Datagramm
wird lediglich intern verarbeitet und nicht ins
Netzwerk geschickt.
• Sind alle Bits der Hostadresse Nullen, so bezeichnet dies die Adresse des gesamten Netzes.
• Sind hingegen alle Hostadress-Bits geschalten,
so handelt es sich hierbei um einen Broadcast
und das Datagramm wird an alle Hosts im Netzwerk weitergeleitet.
• Die Adresse 255.255.255.255 ist für den lokalen Broadcast reserviert: Hierbei wird das Datagramm an alle Hosts im Netz geschickt, darf jedoch nicht weitergeleitet werden.
1.5. IP-Adressierung
Ein Beispiel für diese Fehlverteilung stellt folgende Situation dar: Angenommen es liegt ein physikalisches Netzwerk mit etwa 1000 angeschlossenen Hosts vor und dieses soll adressiert werden. Als
„angemessene“ Netzklasse kommt hierfür nur Klasse B in Frage, da man mit einem Klasse-C-Netz lediglich 254 Hosts adressieren kann. Doch mit einer solchen Klasse-B-Netzadresse ist es möglich,
65534 Netzwerkknoten anzusteuern und somit werden circa 64534 mögliche IP-Adressen verschwendet
und können nicht mehr an andere Netzwerke vergeben werden.
• 10.0.0.0: Privates Klasse A Netzwerk
Dieser Trend wurde noch dadurch verstärkt, dass
sich
zu Beginn des Internets große und einflussreiche
• 172.16.0.0 bis 172.31.0.0: Hier können maximal
Institutionen
ganze Klasse-A-Netzadressen sicherten
16 private Klasse B Netzwerke adressiert werund
somit
seither
einen beträchtlichen Teil des IPden.
Adressraums belegen.
Als Lösung der Adressknappheit schwenkte man
• 192.168.0.0 bis 192.168.255.0: Dieser Bereich
auf
das so genannte Subnet Addressing um.
kann maximal 254 Klasse C Netzwerke umfassen.
Die Gesamtanzahl der im Internet zu vergebenden
Adressen beläuft sich somit auf 4 294 967 296 Stück.
Neben diesen beiden Varianten gibt es noch spezielle Adressen für private Netzwerke, d. h. Netzwerke,
die in sich abgeschlossen und nicht direkt mit dem Internet verbunden sind. Diese Adressen dürfen im Internet nicht weitergeleitet werden, es bedarf bei der
Nutzung allerdings auch keiner Erlaubnis von Seiten
der ICANN.
Die vordefinierten Bereiche für private Netzwerke
sind:
1.5.4. Subnet Addressing
1.5.3. Classful Addressing
Nun stellt sich die Frage, wie denn bei einer InternetAdresse die Netzadresse und die Hostadresse ermittelt
wird.
Ein grundlegender Ansatz dafür war das so genannte Classful Addressing, welches jedem Netz eine eigene Netzadresse zugewiesen hat. Dabei gab es je nach
der Größe des zu adressierenden Netzwerks unterschiedliche Klassen von Netzen, welche anhand der
führenden Bits der IP-Adresse unterschieden wurden.
In Abbildung 1.3 sind die Netzwerkklassen dargestellt. Ersichtlich ist auch, welcher Adressraum für
Netzadressen und Hostadressen jeweils in den entsprechenden Klassen zur Verfügung gestellt wird.
Sonderfälle sind die Klassen D und E. Die Adressen der Klasse D sind so genannte Multicast-Adressen
und sind dafür bestimmt, Datagramme an mehrere
Hostadressen gleichzeitig zu schicken. Erreicht ein
Datagramm eine solche Adresse, so wird versucht,
dieses Paket an alle Mitglieder der adressierten Gruppe unter Benutzung des Internet Group Messaging
Protocol (IGMP) zu senden. Die Klasse E wird normalerweise nicht verwendet und ist für experimentelle Zwecke reserviert.
Problematisch beim Classful Addressing ist jedoch
die verschwenderische Adressverteilung. Mit dem
Grundprinzip der Zuweisung von je einer Netzadresse
pro physikalischem Netzwerk wurde der zur Verfügung stehende Adressraum sehr ineffizient vergeben
und die ICANN stand bereits nach wenigen Jahren
vor dem Problem, dass der Adressraum knapp wurde.
Die Idee dieses Ansatzes steckt schon im Name: Netze werden in kleinere Netze, die so genannten Subnets, unterteilt.
Alle Subnets, die zu einer Netzadresse gehören,
werden von der zugehörigen Einrichtung zentral verwaltet und somit erscheinen die Netze nach Außen hin
weiterhin wie ein großes Netzwerk.
Die Umsetzung dieses Prinzips, welches im
RFC 950 [MP85] festgelegt wurde, erfolgt meist
durch die Verwendung der höherwertigen Bits der
Hostadresse als Subnet-Adresse. Abhängig von der
Anzahl der gewünschten Subnets werden die Bits reserviert und mit der Subnet-ID belegt. Die übrigen
Bits der Hostadresse dienen weiterhin zur Adressierung der Hosts.
Die für das Subnet genutzten Bits werden in der
Subnet-Maske markiert. Die Subnet-Maske ist bei
IPv4 ein weiterer 32 bit-Wert, bei dem die einzelnen
Bits für die entsprechenden Bits der IP-Adresse stehen. Alle Bits der Netzadresse sowie alle Bits der
Subnet-Adresse haben hier den Wert 1. Die Hostadressbits müssen den Wert 0 zugewiesen bekommen.
Mit diesem Verfahren ist es also möglich, die SubnetBits zu identifizieren und die Adressierung der Teilnetze korrekt durchzuführen.
In Abbildung 1.4 ist ein Beispiel für eine solche Unterteilung zu sehen. Hier wurde ein Klasse-BNetzwerk in 32 Subnets mit jeweils 2046 möglichen
Hosts unterteilt. Die Zahl der Subnets ergibt sich aus
der Länge der Subnet-Adresse, welche hier 5 bit beträgt. Die Subnet-Maske hat hier den binären Wert:
11
1. Internet Protocol (IP)
0
8
Klasse A
0
Klasse B
1 0
Klasse C
1 1 0
Klasse D
1 1 1 0
Klasse E
1 1 1 1
24
16
Hostadresse
Netzadresse
Netzadresse
Hostadresse
Netzadresse
Hostadresse
Multicast
reserviert
Abbildung 1.3.: Übersicht über die Netzklassen.
0
8
Klasse B
1 0
Netzadresse
Klasse B mit
Subnetz-ID
1 0
Netzadresse
Subnetzmaske
24
16
Hostadresse
Subnetz
Hostadresse
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0
Abbildung 1.4.: Klasse-B-Netz mit 32 Subnets.
11111111 11111111 11111000 00000000 .
fristigen Lösung zu gewinnen, hat man eine weitere
Verbesserung eingesetzt: das Classless Inter-Domain
Dies entspricht 255.255.248.0 in gepunkteter Dezi- Routing (CIDR), das im RFC 1519 [FLYV93] bemaldarstellung.
schrieben wird. Der Grundgedanke ist, dass die ZuNoch ein weiterer Vorteil ergibt sich durch das Sub- ordnung von IP-Adresse zur Netzklasse und den Unnetting: Da externe Router den internen Netzaufbau terklassen vollkommen entfällt. Die Aufteilung von
nicht kennen, wird für jeden Host in solch einem auf- Netz- und Hostadresse geschieht hierbei durch eine
geteiltem Netz nur eine Route, nämlich die zum ge- Netzmaske. Diese Netzmaske, die vom Prinzip her
meinsamen Gateway, in der Routingtabelle benötigt. genau wie die Subnetzmaske funktioniert, wird meist
Im Gegensatz dazu wären bei 32 eigenständigen Netz- als Suffix bezeichnet. Der Begriff stammt von der neuwerken für jedes Netzwerk ein solcher Eintrag not- artigen Schreibweise der CIDR-Adressen: Angenomwendig.
men, bei der IP-Adresse 141.35.12.1 sind die ersten
16 bit die Netzadresse, dann wird das wie folgt geschrieben:
1.5.5. Classless Inter-Domain
Routing
Mit Subnet Addressing wurde schon ein Schritt in
die richtige Richtung getan, doch auch diese Methode
stieß bald an ihre Grenzen, denn die Routingtabellen
wurden immer größer und es bestand die Gefahr, dass
die zur Verfügung stehende Hardware den Routingaufwand nicht mehr bewältigen kann. Weiterhin hat
das Subnetting nicht die Adressknappheit wie erwartet gelöst. Um Zeit für die Entwicklung einer lang-
12
141.35.12.1/16 .
Das Suffix „/16“ gibt also an, wie viele Bits der Netzmaske, angefangen vom höchstwertigen, den Wert 1
haben.
Vorteilhaft an diesem Vorgehen ist, dass man nun
IP-Adressen verstärkt hierarchisch vergeben kann,
d. h. dass man die Adressierung der vorhandenen Infrastruktur anpasst. Wird der Verkehr eines kleineren Netzwerks über die Infrastruktur eines größeren
1.6. IP-Routing
Suffix
/8
/9
/10
/11
/12
/13
/14
/15
/16
/17
/18
/19
/20
/21
/22
/23
/24
/25
/26
/27
/28
/29
/30
Hosts
16777216
128 x 65536
64 x 65536
32 x 65536
16 x 65536
8 x 65536
4 x 65536
2 x 65536
65536
128 x 256
64 x 256
32 x 256
16 x 256
8 x 256
4 x 256
2 x 256
256
128
64
32
16
8
4
Netzmaske
255.0.0.0
255.128.0.0
255.192.0.0
255.224.0.0
255.240.0.0
255.248.0.0
255.252.0.0
255.254.0.0
255.255.0.0
255.255.128.0
255.255.192.0
255.255.224.0
255.255.240.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0
255.255.255.128
255.255.255.192
255.255.255.224
255.255.255.240
255.255.255.248
255.255.255.252
Tabelle 1.2.: Netzmasken.
ISPs abgewickelt, so bekommt dieses Netzwerk eine Adresse, die hierarchisch unter der des ISP liegt.
Zum Beispiel könnte der ISP ein /16-Netzwerk allokiert haben und das kleinere Netzwerk könnte ein
/28-Netzwerk im gleichen Adressbereich sein. Diese
Adressvergabe führt dazu, dass weniger Einträge in
den Routingtabellen benötigt werden.
Weiterhin trägt dieses Schema auch zu einer effektiveren Adressvergabe bei, da jetzt gezielt noch ungenutzte Adressbereiche allokiert werden können.
Allerdings kann man diese Adressvergabe nicht auf
alle Situationen anwenden. Ein Beispiel ist das Multihoming, d. h. dass es mehrere unabhängige Verbindungen eines Netzwerks mit dem Internet gibt, da hier
aufgrund der unterschiedlichen Routen die Routeneinträge in der Routingtabelle verbleiben müssen.
Eine Übersicht über die mögliche Anzahl von
Hosts pro Netzwerk gibt Tabelle 1.2. Diese Adressierungsart ist momentan aktuell, doch die schon beschriebene langfristige Lösung für das Problem der
Adressknappheit wurde schon entwickelt und ist bereits im Einsatz: IP Version 6. Mehr dazu findet sich
in Abschnitt 1.7.
1.6. IP-Routing
Eine weitere Hauptaufgabe des Internet-Protokolls
ist das Weiterleiten von Datagrammen im Netz: das
Routing. Dieser Abschnitt dient als Einführung, für
tiefer gehende Einblicke gibt es die beiden Kapitel 3
und 4 zu dieser Thematik.
Die zentrale Frage ist: Wie kommt ein Datagramm vom Sender zum Empfänger? Die Lösung ist
ein simpler Algorithmus, der für jedes ankommende Datagramm durchlaufen wird. Aus der Sicht eines Hosts kann man den Ablauf folgendermaßen beschreiben:
1. Prüfen, ob das Datagramm für meine IP-Adresse
bestimmt ist. Falls dies der Fall ist, dann wird das
Paket angenommen und verarbeitet.
2. Prüfen, ob das Datagramm für einen Host bestimmt ist, der direkt mit mir verbunden ist. Falls
ja, dann wird das Paket an diesen weitergeleitet.
3. Prüfen, ob das Datagramm für ein mit mir verbundenes Netzwerk bestimmt ist. Falls ja, dann
wird das Paket an den Next-Hop-Router dieses
Netzwerks weitergeleitet.
4. Falls keiner der Fälle 1–3 eingetreten ist, dann
wird das Paket an den Default-Router weitergeleitet.
Sollten alle Fälle scheitern, so wird versucht, eine
entsprechende ICMP-Fehlermeldung an den Sender
zu schicken.
Damit das IP die obigen Fälle unterscheiden kann,
ist es nötig zu wissen, welche Hosts direkt erreicht
werden können, welche Router von anderen Netzwerken angeschlossen sind und welche IP-Adresse
der Default-Router hat. Dies wird mit der schon öfters erwähnten Routingtabelle erreicht. In ihr stehen
die benötigten IP-Adressen, mit denen dann die Zieladresse des ankommenden Pakets verglichen wird.
In Schritt 2 wird dabei auf vollständige Übereinstimmung geprüft. Bei Schritt 3 ist lediglich die Netzadresse relevant, wird hier eine Übereinstimmung gefunden, d. h. es gibt einen bekannten Router, der sich
im gleichen Netz befindet, so wird das Datagramm an
diesen Router geschickt. Auf jeden Fall muss aber in
der Routingtabelle die Adresse des Default-Routers,
oft auch als „Next-Hop“ bezeichnet, eingetragen sein.
Prinzipiell gilt hierbei immer die Annahme, dass
der Next-Hop-Router „näher“ am Ziel liegt und über
eine umfangreichere Routingtabelle verfügt. Auf diese Weise gelangt ein Datagramm also „hop-by-hop“
durchs Netzwerk zu seinem Zielhost.
13
1. Internet Protocol (IP)
Weiterhin zu erwähnen ist die Tatsache, dass in der
Routingtabelle für jedes erreichbare Netzwerk nur eine Route eingetragen ist, nämlich die IP-Adresse des
entsprechenden Routers. Würden alle Hosts eines angeschlossenen Netzwerks einen eigenen Eintrag benötigen, so würde die Tabellengröße rasant anwachsen und die Routingvergleiche würden viel Zeit und
Hardwareaufwand benötigen.
1.7. IP Version 6
Der Nachfolger von IPv4 lautet IPv6. Er wird auch
als IP Next Generation bezeichnet und soll in diesem
Abschnitt kurz vorgestellt werden.
Aufgrund der früh erkannten Probleme der Adressknappheit und der immer stärker wachsenden
Routingtabellen wurde ab 1995 intensiv an der sechsten Version des Internet-Protokolls gearbeitet und
nach vielen Tests und einigen Änderungen 1998 die
Spezifikation im zugehörigen RFC 2460 [DH98] festgehalten. IPv6 ist bereits im Einsatz, doch es ist bisher
noch nicht stark verbreitet.
1.7.1. Adressierung
Die alten 32 bit-Adressen haben ausgedient und
werden durch 128 bit lange Adressen ausgetauscht.
Durch diese Maßnahme sollten zukünftig genug IPAdressen zur Verfügung stehen, denn es sind circa
340 Sextillionen (= 3.4 · 1038 ) Adressen möglich.
Auch die gepunktete Dezimalnotation wird nicht
mehr verwendet, die Adressen werden ab jetzt in
hexadezimaler Notation mit Doppelpunkten geschrieben. Eine Adresse besteht aus 8 Blöcken, wobei jeder
Block für 16 bit der Adresse steht. Hier ein Beispiel
einer IPv6-Adresse:
2001:cf8:84b3:3a3:1d49:8a2f:260:7144 .
Dabei können ein oder mehrere Gruppen von 0Blöcken durch zwei aufeinander folgende Doppelpunkte ersetzt werden. Jedoch darf die Adresse nur
an einer Stelle auf diese Weise abgekürzt werden, da
sie sonst nicht mehr eindeutig wäre. Auch dürfen führende Nullen in den Blöcken weggelassen werden.
Das Prinzip der Aufteilung in Netzadresse und
Hostadresse wurde beibehalten und wird ähnlich wie
bei CIDR geschrieben:
2001:cf8:84b3:3a3:1d49:8a2f:260:7144/64 .
Bei dieser Adresse sind folglich die ersten 64 bit die
Netzadresse, diese wäre also 2001:cf8:84b3:3a3::/64.
14
Auch wurde das Hierarchieprinzip hier weitergeführt, somit müsste das obige Netz ein Teilnetz von
2001:cf8:84b3::/48 sein.
Außerdem gibt es jetzt unterschiedliche Arten von
Adressen, die man an ihrem Präfix erkennt, d. h. an
der ersten 16 bit-Gruppe. Beim hier aufgeführten Beispiel mit dem Präfix 2001 handelt es sich um eine
Adresse, die an Provider vergeben wird, damit diese
sie an Endnutzer weitergeben.
Andere Adressarten und spezielle IP-Adressen
sowie weitere detaillierte Informationen zur IPv6Adressierung sind im zugehörigen RFC 3513 [HD03]
zu finden.
1.7.2. Der IPv6-Header
Im Gegensatz zum Version-4-Header hat der IPv6Header eine feste Länge von 40 B. Dieser kann allerdings durch das Anhängen von weiteren Headern
noch erweitert werden.
Der Aufbau ist dem von IPv4 sehr ähnlich, doch
man erkennt deutlich, dass der Header vereinfacht
wurde, um ihn schneller verarbeiten zu können. In
Abbildung 1.5 ist eine Darstellung des Headerinhalts
zusehen.
Es folgt eine kurze Beschreibung der einzelnen Felder:
Version Exakt wie bei IPv4 steht dieses Feld für die
Protokollversion und ist bei IPv6 mit dem Wert
6 belegt.
Traffic Class Dieses Feld steht für einen Prioritätswert, mit dem das Datagramm verarbeitet werden soll, und hat somit ähnliche Funktionalität
wie das TOS-Feld bei IPv4.
Flow label Hiermit können zusammengehörige Pakete speziell gekennzeichnet werden.
Payload Length Dies gibt die Länge des Gesamtpakets exklusive dem Header an. Erweiterungsheader sind hier allerdings mit inbegriffen.
Next Header In diesem Feld steckt die große Flexibilität von IPv6. Hier wird der Typ des als
nächstes folgenden Erweiterungsheaders angegeben, damit dieser auch korrekt verarbeitet werden kann. Beispiele für solche Erweiterungen
sind spezielle Header für Routingoptionen, Authentifikation, Datenintegrität und Datensicherheit. Zu bemerken ist, dass jeder Header den Typ
des ihm folgenden Headers enthält. Eine Ausnahme davon bildet der letzte Erweiterungshea-
1.7. IP Version 6
8
0
Version
24
16
Traffic class
Flow label
Payload length
Next header
Hop limit
Source address
Destination address
Abbildung 1.5.: Format des IPv6-Headers.
der, dieser enthält die Transportprotokollnummer, ähnlich wie im Protocol-Feld bei IPv4.
abläuft. Vom Grundprinzip her unterscheidet er sich
von den bisherigen Methoden, wie zum Beispiel die
Adressvergabe durch das Dynamic Host ConfiguratiHop Limit Dies ist ähnlich wie der TTL-Wert bei on Protocol (DHCP) [Dro97], dahingehend, dass hier
IPv4 ein Zähler für die bereits passierten Kno- keine zentrale Instanz über die vergebenen Adressen
ten im Netzwerk. Erreicht er den Wert Null, so Buch führen muss.
wird auch hier das Datagramm verworfen.
Auch ist bei IPv6 das Renumbering, welches bei
IPv4 keineswegs trivial ist und meist durch manuelles
Source Address Die 128 bit-Adresse des Quell- Eingreifen erfolgen muss, vereinfacht worden. Durch
hosts.
die Autokonfiguration und den vereinfachten Betrieb
von mehreren parallelen IP-Adressen ist es nun ohne
Destination Address Hier befindet sich die IPProbleme möglich, seine IP-Adresse, etwa bei einem
Adresse des Empfängers, allerdings kann dies
Providerwechsel, zu ändern.
auch nur eine Zwischenstation sein, falls ein ErEine später in die Spezifikation eingefügte Erweiweiterungsheader für das Routing vorhanden ist.
terung ist das so genannte Mobile IPv6. Der Kerngedanke bezieht sich darauf, dass ein Host überall unter
der selben IP-Adresse erreichbar ist, egal, ob er sich in
1.7.3. IPv6-Neuerungen
seinem Heimnetzwerk befindet oder mobil unterwegs
Viele neue Features wurden in IPv6 integriert und ein
ist. Dabei wird im Heimnetz ein Home Agent, welAuszug davon soll hier vorgestellt werden.
cher das Mobilgerät vertritt, betrieben. Gelangt das
Als erstes zu nennen wäre hier die Möglichkeit der
Mobilgerät in einen anderen Adressbereich, so erhält
Autokonfiguration von IPv6-Hosts. Allein anhand seies von dem für ihn zuständigen Router eine temporäner MAC-Adresse kann sich ein Host selbst eine lore Adresse, die Care-Of-Address (COA), welche das
kal gültige IP-Adresse berechnen und mit dieser per
Gerät dem Heimagent mitteilt. Dieser kann nun einMulticast auf einer speziellen Adresse mit den für
gehende Datagramme korrekt an den mobilen Host
ihn zuständigen Routern kommunizieren. Vom Rouzustellen. Diese Neuerung ist gerade in der heutigen
ter bekommt der Host dann einen Adressbereich zuZeit der aufkommenden internetfähigen mobilen Gegewiesen, aus welchem er sich eine Adresse ausräte von großem Nutzen.
wählen kann. Anschließend wird noch überprüft, ob
Bei IPv6 gibt es keine Fragmentierung der Pakediese Adresse bereits vergeben ist. Dabei ist zu bete mehr. Standardmässig muss jeder Host Pakete bis
merken, dass dieser gesamte Vorgang vollautomatisch
15
1. Internet Protocol (IP)
zu einer Größe von 1280 B akzeptieren, was bei einer
Ethernet-MTU von 1500 B kaum noch eine Aufteilung der Daten nötig macht. Sind dem Empfänger die
ankommenden Datagramme trotzdem zu groß, so teilt
er dies dem Sender via ICMP-Nachrichten mit und somit wird vor der Übertragung die maximal mögliche
Paketgröße ermittelt, was eine Steigerung der Effizienz zur Folge hat.
Weiterhin ist das neue Internet-Protokoll sicherer
und schneller als sein Vorgänger. Durch die bereits erwähnten Erweiterungsheader sind nun Mechanismen
zur sicheren Datenübertragung, wie Authentifikation
und Datenintegritätsschutz, möglich und durch den
vereinfachten Basis-Header und spezielle Routingerweiterungen gelangen Datagramme schneller zu ihrem Ziel.
Auffällig ist weiterhin, dass bei IPv6 keine HeaderPrüfsumme mehr gebildet wird. Dies wurde in Fachkreisen kontrovers diskutiert und man einigte sich
darauf, die beim Routing aufwändige Prüfsummenberechnung wegzulassen. Dies wurde damit begründet, dass bei höherschichtigen Protokollen ebenfalls eine Prüfsumme gebildet wird und man durch
den Verzicht das Weiterleiten von Datagrammen beschleunigt.
Als letzte Neuerung soll hier die einfache Erweiterbarkeit angeführt werden. Es ist auffällig, dass beim
Entwurf von IPv6 besonders darauf geachtet wurde,
zukünftige Neuerungen ohne große Änderungen einbauen zu können. Das Prinzip der Erweiterungsheader bietet hierfür die Basis. Bereits jetzt existieren viele solcher Erweiterungsformen, doch diese alle zu behandeln würde den Rahmen dieses Abschnitts sprengen. Sie sind in den jeweiligen RFCs gut dokumentiert.
1.7.4. Ausblick
Momentan gibt es noch keine weltweit verbreitete
Anwendung, die ohne IPv6 nicht funktionieren würde
und es wird wohl auch noch dauern, bis sich die neue
Version durchgesetzt hat. Doch aufgrund der Adressknappheit, vor allem im asiatischen Raum, wird wohl
kein Weg daran vorbeiführen. Außerdem werden erst
noch einige Probleme, wie zum Beispiel die schwierige Namensauflösung, die Gewährleistung der Kompatibilität zu IPv4 und den bestehenden höherschichtigen Protokollen oder auch die aufkommenden Datenschutzbedenken durch die „festen“ IP-Adressen, gelöst werden müssen, damit IPv6 global das Steuer im
Internet übernehmen kann.
16
1.8. Fazit
Das Internet-Protokoll ist von grundlegender Bedeutung für das heutige Internet oder Netzwerkkommunikation im Allgemeinen. Es organisiert die Fragmentierung, Adressierung und Zustellung von Datenpaketen auf eine sehr simple, aber dennoch erstaunlich
leistungsfähige und robuste Art und Weise. Diese ist
wohl auch der Grund für das relativ problemlose Anwachsen des Internets bis auf seine derzeitige Größe
und lässt hoffen, dass auch zukünftige Aufgaben erfüllt werden können.
Unsere Netzwerke wachsen und das InternetProtokoll ist sprichwörtlich der Leim, der alles zusammenhält.
2. Internet Control Message Protocol (ICMP)
Stephan Arenswald
2.1. Einführung
Layer
Protokolle
App.
Das Internet Control Message Protocol (ICMP) ist ein
Protokoll, welches wie TCP und UDP (Kapitel 5ff)
zur IP-Protokollfamilie gehört. Es bietet die Möglichkeit, in Netzwerken Fehlerinformationen und einfache Anfragen auszutauschen. Demzufolge ist es kein
weiteres Transportprotokoll, obwohl es direkt auf IP
aufbaut. Da TCP bereits eine verbindungsorientierte
Kommunikation bietet und durch UDP auch die verbindungslose Kommunikation abgedeckt ist, ist dies
auch nicht nötig.
Bei den genannten Transportprotokollen gibt es
einen entscheidenden Nachteil. Was passiert zum Beispiel, wenn ein Paket abgeschickt wurde? Vielleicht
kommt es an, aber vielleicht auch nicht. Jetzt könnte
man argumentieren, dass TCP verbindungsorientiert
ist und eine einwandfreie Übertragung garantiert. Im
Fehlerfall wird die Verbindung aber abgebrochen, ohne dass genau das Problem angegeben wird. Es wurde nicht dafür ausgelegt, den Grund zu ermitteln. Hier
kommt ICMP ins Spiel. Dieses Protokoll ist für genau
diese Aufgabe konzipiert.
Das Internet Control Message Protocol wurde 1981
von J. Postel im RFC 792 [Pos81a] spezifiziert. ICMP
setzt wie bereits erwähnt auf der IP-Protokoll-Familie
auf. Trotzdem ist es ein unerlässlicher Teil des IPProtokolls, weshalb jedes IP-Modul eine Implementierung von ICMP beinhalten muss. Es wurde 1985
durch RFC 950 [MP85] von J. Postel und J. Mogul erweitert. Darauf wird hier allerdings nicht näher eingegangen.
Wie zu Beginn angesprochen, dient das ICMPProtokoll zur Übermittlung von Fehlermeldungen,
z. B. falls eine Nachricht unterwegs verloren geht.
Auf einige dieser Fehlermeldungen wird in Abschnitt 2.4.1 näher eingegangen. Als Anwendungsgebiet gelten aber auch Informationsaustausch und Anfragen. Der berühmteste Vertreter in dieser Kategorie
ist Ping. Dieses kleine Programm sendet eine Nachricht an einen entfernten Computer und wartet, ob ei-
HTTP
FTP
Transp.
SMTP
POP3
IRC
UDP
TCP
IP (IPv4,IPv6), ICMP
Network
Ethernet
Link
⇐
WLAN
Abbildung
2.1.:
Schichtenmodell.
IP-Header
DNS
ICMP
im
TCP/IP-
IP-Datagramm
@
@
type
code
checksum
datagram
Abbildung 2.2.: Aufbau des ICMP-Headers.
ne Antwort kommt. Dieses und einige andere Beispiele werden in Abschnitt 2.4.2 behandelt. Des Weiteren
folgt ein kleiner Exkurs in das Gebiet Mobile IP. Auch
dort spielt ICMP eine wichtige Rolle. In Abschnitt 2.5
wird auf dieses Thema näher eingegangen.
2.2. Einordnung des ICMP
Obwohl das ICMP-Protokoll zu dem Network-Layer
gehört (siehe Abbildung 2.1), kann es nicht anstelle
des IP-Protokolls eingesetzt werden. Es ist eine Ergänzung zu diesem. Der Grund liegt darin, dass sich
ICMP nicht um den Transport selbst kümmert. D. h.
es verwaltet weder Absender, Empfänger noch andere zur Übertragung wichtige Informationen.
17
2. Internet Control Message Protocol (ICMP)
2.3. Aufbau
Der Aufbau ist im Vergleich zu anderen Protokollen
sehr einfach. In Abbildung 2.2 ist zu sehen, dass der
Header (Kopf des Paketes, grau umrandet) lediglich
aus 3 Feldern besteht:
LANs als auch WANs (Internet). Es werden allerdings
keine ICMP-Nachrichten aufgrund von MulticastNachrichten erzeugt. Diese könnten einen Host, welcher ein Paket an viele andere geschickt hat, völlig
überlasten, da er von jedem Empfänger eine Nachricht mit dem gleichen Problem erhalten könnte.
Type Dieses Feld ist 8 bit lang und gibt, dem Namen
2.4.1. Fehlermeldungen
nach, den Typ der ICMP-Nachricht an. Dazu gehören zum Beispiel 0=Echo Reply, 3=Destinati- Lifetime Exceeded Eine Fehlermeldung aufon Unreachable oder 11=Time Exceeded.
grund der Lebenszeitüberschreitung kann aus zwei
Gründen generiert werden. Der erste ist, dass die TTL
Code Durch dieses ebenfalls 8 bit lange Feld wird
(Time To Live) abgelaufen ist. Als zweites gibt es
der Typ näher spezifiziert. So kann Typ 11 (Time
einen Timeout beim Zusammensetzen von FragmenExceeded) zusätzlich durch Code 0=TTL Exceeten.
ded oder 1=Fragment Reassembly Timeout geSollte ein Router ein Paket erhalten, dessen TTL
nauer eingegrenzt werden. Dadurch ist eine gegleich 0 ist, muss es verworfen werden (siehe Abbilnauere Fehlerunterscheidung und demzufolge eidung 2.3). Jetzt kann der Host, welcher das Paket urne bessere Fehlerbehandlung möglich.
sprünglich versendet hat, darüber informiert werden.
Checksum Diese Prüfsumme dient dazu, festzu- Die Adresse zu diesem steht im IP-Header. Der Roustellen, ob die übertragene Nachricht so ange- ter schickt also eine ICMP-Nachricht an den Host und
kommen ist, wie sie abgesendet wurde. Soll- informiert ihn, dass die Lebenszeit abgelaufen ist. Der
te ein Bit bei der Übertragung umgekippt sein, Aufbau dieser Nachricht ist in Abbildung 2.4(a) zu sekann das damit erkannt werden. Die 16 bit lan- hen.
Wie bereits angesprochen, kann diese Fehlermelge Prüfsumme ergibt sich aus dem 16 bit-1erKomplement der Summe des 1er-Komplements dung auch gesendet werden, wenn beim Zusammender ICMP-Nachricht. Das ist der gleiche Algo- setzen von Fragmenten ein Timeout auftritt. Fehlt ein
rithmus, wie er bei dem IP-Protokoll verwendet Teil, wartet der empfangende Host eine gewisse Zeit.
Ist diese abgelaufen, wird eine ICMP-Nachricht an
wird.
den Absender geschickt. Der Rest des Datagramms
In Tabelle 2.1 sind alle Message Types aufgeführt, wird verworfen.
welche im ursprünglichen RFC eingeführt wurden.
Die aktuelle Liste (Juli 2006) umfasst mittlerweile Parameter Problem Angenommen, ein Host ver48 Typen und mehrere hinzugefügte Codes. Bei Typ 3 sendet ein Paket mit Hilfe von IP Version 4 (IPv4).
(Destination unreachable) zum Beispiel ist die An- Dafür wird im IP-Header das Feld „Version“ auf
zahl der Codes von 5 auf 15 gestiegen. Diese Liste 0100 = 4 gesetzt. Auf dem Weg zum Empfän2
10
wird von der IANA verwaltet [Int06b].
ger kippen nun 3 Bits um, so dass sich das Feld auf
Die Typen 9 und 10 aus Tabelle 2.1 gehören nicht 0011 = 3 ändert. Diese Version gibt es nicht. Der
2
10
zu RFC 792. Da sie jedoch in Abschnitt 2.4.2 behan- Empfänger kann das Paket nicht verarbeiten. Entspredelt werden, sind sie zur Vollständigkeit mit eingetra- chend wird der Absender informiert, das es ein Progen.
blem im IP-Header gibt. Abbildung 2.5 verdeutlicht
Das ICMP-Datagramm besteht aus den Nutzdaten, das Beispiel anhand einer Grafik.
welche zur zusätzlichen Information für die jeweiDie ICMP-Nachricht besitzt nach dem Header ein
ligen Typen und Codes dient. D. h. das Datagramm 8 bit langes Feld für einen Pointer. Dieser zeigt auf
wird in zusätzliche Felder mit spezifischen Daten un- das fehlerbehaftete Oktett im IP-Header. Für den beterteilt. Die Auswertung dieser Informationen erfolgt schriebenen Fehlerfall (Fehler im Versionsfeld) würdemzufolge in Abhängigkeit von Typ und Code.
de der Pointer auf 1, also das erste Oktett im IPHeader zeigen (siehe Abbildung 2.4(b)).
2.4. Aufgaben
Der Aufgabenbereich für ICMP erstreckt über alle Arten von Netzwerken. Dazu gehören sowohl
18
Source Quench Übersetzt heißt Source Quench
den „Absender dämpfen“. Diese Nachricht wird von
einem beliebigen Zielhost (Router sind damit nicht
2.4. Aufgaben
Type
Code
0
0
echo reply
792 [Pos81a]
destination unreachable:
network unreachable
host unreachable
protocol unreachable
port unreachable
fragmentation needed but don’t fragment bit set
source route failed
792 [Pos81a]
0
1
2
3
4
5
0
source quench
792 [Pos81a]
redirect
Redirect datagrams for the network
Redirect datagrams for the host
Redirect datagrams for the type of service and network
Redirect datagrams for the type of service and host
792 [Pos81a]
0
1
2
3
8
0
echo request
792 [Pos81a]
9
10
0
0
router advertisement
router solicitation
1256 [Dee91]
1256 [Dee91]
time exceeded
time to live exceeded in transit
fragment reassembly time exceeded
792 [Pos81a]
0
1
header problem
IP header problem
792 [Pos81a]
0
13
14
0
0
timestamp message
timestamp reply message
792 [Pos81a]
792 [Pos81a]
15
16
0
0
information request message
information reply message
792 [Pos81a]
792 [Pos81a]
3
4
5
11
12
Description
RFC
Tabelle 2.1.: Nachrichtentypen bei ICMP.
Abbildung 2.3.: Lebenszeit überschritten.
19
2. Internet Control Message Protocol (ICMP)
11
0 od. 1
checksum
12
00000001
unused
checksum
0 od. 1
unused
Internet Header + 64 bit des Original-Datagramms
Internet Header + 64 bit des Original-Datagramms
(a) Lifetime Exceeded
(b) Parameter Problem
4
0
checksum
5
0-1
checksum
unused
unused
Internet Header + 64 des Original-Datagramms
Internet Header + 64 des Original-Datagramms
(c) Source Quench
(d) Redirect
3
checksum
1
unused
Internet Header + 64 des Original-Datagramms
(e) Destination Unreachable
Abbildung 2.4.: ICMP-Pakete von verschiedenen Fehlermeldungen.
Abbildung 2.5.: Ungültige Parameter.
20
2.4. Aufgaben
ausgeschlossen) an den Absender eines Paketes geschickt. Dafür kann es zwei Gründe geben: entweder
eine zu hohe Auslastung der Serververbindung oder
dass der Server die Pakete nicht schnell genug abarbeiten kann.
Angenommen, ein Netzwerk besteht aus einem
Datenbankserver und zehn Clients (siehe Abbildung 2.6). Diese führen permanent sehr viele Anfragen auf dem Server aus. Dadurch entsteht eine hohe Netzwerkauslastung. Kommt nun ein elfter Client
hinzu, welcher ebenfalls einen hohen Datenverkehr
erzeugt, schickt der Server eine ICMP-Nachricht an
diesen, wenn der Pufferplatz nicht ausreichen sollte.
Das Format dieser Nachricht ist in Abbildung 2.4(c)
zu sehen.
Wie bereits erwähnt, ist es auch möglich, dass ein
Client zu schnell Nachrichten sendet. Der Server versucht darauf hin mit Source-Quench-Nachrichten die
Senderate des Absenders zu drosseln. Er schickt so
lange ICMP-Nachrichten, bis die Datenrate auf seinem gewünschten Niveau liegt. Durch ein langsames Herantasten an die Übertragungsgrenze kann der
Client eine bestmögliche Übertragungsrate erzielen.
Redirect Dieser Nachrichtentyp wird für das folgende Problem, welches in Abbildung 2.7 dargestellt
ist, verwendet. Ein Computer C1 möchte mit einem
zweiten (C2) kommunizieren. C1 schickt eine Nachricht ab. Diese kommt bei Router R1 an. Dieser sieht
nun in der eigenen Routing-Tabelle nach, wohin das
Paket weiter geschickt werden muss. Stellt R1 nun
fest, dass der nächste Router R2 im gleichen Netzwerk liegt wie C1, schickt er die Nachricht nicht nur
weiter, sondern sendet auch eine Redirect-Message an
den Absender zurück. C1 bekommt damit die Information, dass der Weg zu C2 über R2 kürzer ist. Das
erspart unnötigen Datenverkehr.
Es gibt insgesamt 4 Möglichkeiten, das Code-Feld
zu belegen:
• 0: Umleiten von Datagrammen für das Netzwerk. Jedes Paket, welches in das gleiche Zielnetzwerk N2 verschickt werden soll, soll über R2
umgeleitet werden.
• 3: Umleiten von Datagrammen für TOS und den
Host. Wie bei Code 1, jedoch muss zusätzlich der
TOS übereinstimmen.
In RFC 1812 [Bak95] werden die Codes 0 und 2
für überholt erklärt. Das Problem mit Weiterleitungen für komplette Netzwerke besteht darin, dass die
Netzwerk-Spezifikation einer Umgebung, in der Subnetting oder CIDR (vgl. 1.5.4 und 1.5.5) benutzt wird,
mehrdeutig sein kann.
Ein weiteres Problem ist, das ein Redirect nur für
den ersten Hop aus einem Netzwerk heraus funktioniert. Abbildung 2.7 zeigt das Problem. Wenn R2
seine Nachricht an R3 weiterschickt und diese von
dort aus zu R4 weiter gesendet wird, kann R3 keine Redirect-Message zurücksenden, obwohl der Weg
direkt über R4 kürzer wäre. Das liegt daran, dass R4
nicht im gleichen Netz liegt wie R2. Somit müssen die
Nachrichten nach Netzwerk N3 trotzdem einen Umweg gehen.
Destination Unreachable Erreicht ein Paket
nicht das Ziel, kann das mehrere Gründe haben. Entsprechend besitzt das Code-Feld auch mehrere Möglichkeiten.
• 0: Das Netzwerk ist nicht erreichbar. Das kann
unter anderem daran liegen, dass ein Routingproblem vorliegt.
• 1: Der Zielhost ist nicht erreichbar. Dieser Fehler tritt auf, wenn das Paket in das Netzwerk gelangt, wo die IP-Adresse hin gehört, dort jedoch
nicht zugestellt werden kann.
• 2: Das Protokoll ist nicht erreichbar.
• 3: Der Port ist nicht erreichbar. Wenn der Host
das Paket empfängt, dieses aber nicht an die Anwendung mit dem angegebenen Port weiter geleitet werden kann, tritt dieser Fehler auf.
• 5: Eine vorgegebene Route führt nicht zu dem
gewünschten Ziel.
Zu diesen gehören noch einige weitere die hier
nicht aufgeführt sind, weil sie erst nach der Einfüh• 1: Umleiten von Datagrammen für den Host. rung von ICMP hinzugekommen sind. Die einzige
Hierbei werden alle Pakete über R2 umgeleitet, Ausnahme bildet Code 4, welcher ebenfalls zu den
ersten gehört. Aufgrund seines hohen Informationsgedie für den gleichen Zielhost bestimmt sind.
haltes wird dieser jedoch erst in Abschnitt 2.4.2 unter
• 2: Umleiten von Datagrammen für Type of Ser- „Pfad-MTU-Ermittlung“ näher besprochen.
vice (TOS) und das Netzwerk. Wie bei Code 0,
Die Grafik aus Abbildung 2.8 spiegelt ein einfaches
jedoch muss zusätzlich der TOS übereinstim- Experiment wider. Es existieren zwei Netze: ein inmen.
ternes Cluster-Netz und ein externes Netz. Von einem
21
2. Internet Control Message Protocol (ICMP)
Abbildung 2.6.: Source Quench.
Abbildung 2.7.: Redirect.
Abbildung 2.8.: Destination Unreachable.
22
2.4. Aufgaben
PC aus dem Clusternetz soll eine Verbindung zu einer
nicht vorhandenen IP-Adresse im externen Netz aufgebaut werden. Dazwischen liegt der Router ipc654.
Auf ipc654 wird mittels tcpdump der Datenverkehr
sowohl auf dem internen als auch auf dem externen
Interface abgehört. Nun wird von PC1 aus versucht,
eine Telnet-Verbindung aufzubauen.
pc1$ telnet 141.35.15.230
Trying 141.35.15.230...
telnet: Unable to connect to remote
host: No route to host
In der tcpdump-Ausgabe erkennt man, dass der
Router auf dem externen Interface dreimal versucht,
per ARP-Request den unbekannten Zielhost ausfindig zu machen. Da dies nicht gelingt, wird vom Router auf dem internen Interface an PC1 eine ICMPNachricht mit Type 3 und Code 1 gesendet (Abbildung 2.4(e)), dass der Host nicht erreichbar ist.
2.4.2. Anfragen
ICMP ist nicht nur dazu geeignet, Fehlermeldungen
zu versenden, sondern wird auch dazu verwendet, Informationen abzufragen. Im Folgenden werden dazu
einige Beispiele erläutert.
Timestamp-Funktion Damit ist es möglich, die
Uhrzeit auf zwei Computern zu synchronisieren. Abbildung 2.9 verdeutlicht den Sachverhalt.
Ein Computer A möchte von Computer B die aktuelle Zeit wissen. Eine einfache Anfrage in der Form:
„Wie spät ist es?“ ist nicht möglich, denn durch die
unterschiedlich langen Laufzeiten der Daten im Netzwerk vergehen unter Umständen ein paar Sekunden,
bis die Antwort zu A kommt. Während A seine Zeit
mit der neuen aktualisiert, ist diese schon veraltet.
Es ist möglich, mit vier Zeitstempeln eine genauere
Zeit zu erhalten. Abbildung 2.10(a) zeigt den Header
der ICMP-Nachricht, die neben dem Standardkopf ein
paar zusätzliche Felder enthält.
• Identifier identifiziert die Anfrage mit einer Antwort. Bei mehreren Anfragen an verschiedene
Zeitgeber können diese somit auseinander gehalten werden. Er wird nur verwendet, wenn der
Code gleich 0 ist.
• Sequence Number hat die gleiche Funktion wie
der Identifier. Der Identifier besitzt allerdings
eine höhere Wertigkeit. Werden an zwei Computer je zehn Zeitanfragen geschickt, kann der
Identifier auf die Computer-ID und die Sequence
Number auf die Nachricht gesetzt werden. So ist
eine genaue Unterscheidung möglich.
• Timestamps – dazu gehören drei Zeitstempel, die
zur Berechnung einer genaueren Zeit dienen. Sie
sind je 32 bit lang.
Um eine Uhr mit den vier genannten Zeitstempeln
zu synchronisieren, sind die folgenden Schritte notwendig (siehe Abbildung 2.9):
1. A versendet eine ICMP-Nachricht (Type 13,
Code 0) an B. Dabei ist der Originalzeitstempel
(Originate Timestamp) auf die Versandzeit gesetzt.
2. B empfängt die Nachricht und trägt den Empfangszeitstempel (Receive Timestamp) ein.
3. B erstellt eine Antwort, welche ebenfalls eine ICMP-Nachricht (Type 14, Code 0) ist. In
diese trägt er die beiden Empfangszeitstempel
und setzt als Antwortzeitstempel (Transmit Timestamp) die Versandzeit ein.
4. A empfängt die Nachricht und merkt sich die
Empfangszeit.
Nach diesem Ablauf besitzt A vier Zeitstempel.
Dadurch ist er in der Lage, die empfangene Zeit um
die Datenübertragungszeiten zu korrigieren.
Allerdings funktioniert diese Methode der Uhrensynchronisation nicht immer zuverlässig. Für einen
möglichst genauen Abgleich von Zeiten zwischen
zwei Computern gibt es zum Beispiel das Network
Time Protocoll (NTP), welches in RFC 958 [Mil85]
oder das aktuellere Simple NTP (SNTP), welches in
RFC 4330 [Mil06] spezifiziert ist.
Router Discovery Wenn ein Host in ein Netzwerk eingebunden wird, muss dieser lernen, mit welchen Routern er Kontakt aufnehmen kann. Diese Information in einen Computer per Hand einzuspeichern funktioniert nur bei einer kleinen Anzahl von
Geräten. Muss ein ganzes Unternehmen mit mehreren tausend Computern eingebunden werden, ist diese Methode nicht mehr sinnvoll. Aus diesem Grund
gibt es das Router Discovery, eine automatische Beschaffung von wichtigen Routerinformationen (siehe
Abbildung 2.11).
Das Router Discovery ist auf zwei Arten möglich:
Zum einen kann ein Router sich in bestimmten Zeitintervallen bekannt machen. Das birgt aber das Problem, das neue Hosts unter Umständen sehr lange
auf den Router warten müssen. Und zum anderen
23
2. Internet Control Message Protocol (ICMP)
Abbildung 2.9.: Synchronisation zweier Uhren durch ICMP Timestamps.
13, 14
0
checksum
9
0
checksum
# Addr
AES
lifetime
sequence number
identifier
Routeradresse [1]
32 bit Originalzeitstempel
Routerpräferenz [1]
32 bit Empfangszeitstempel
Routeradresse [2]
32 bit Antwortzeitstempel
..
(a) Timestamp
(b) Router Advertisement
0, 8
10
0
checksum
0
checksum
sequence number
identifier
reserved
datagram
(c) Router Solicitation
(d) Echo Request & Reply
3
checksum
4
unused
Internet Header + 64 bit des Original-Datagramms
(e) Path-MTU
Abbildung 2.10.: ICMP-Pakete für verschiedene Anfragen.
24
2.4. Aufgaben
Abbildung 2.11.: Router Discovery.
schickt ein neuer Host eine Router Solicitation („Ansuchung“, Abbildung 2.10(c)), also eine Anfrage auf
Routerinformationen. Der empfangende Router kann
nun seine Antwort schicken. Darin sind, wie in Abbildung 2.10(b) zu sehen, folgende spezifische Informationen enthalten:
Advertisement Count Dieser Zähler gibt die Anzahl der in der Liste enthaltenen Router an.
Address Entry Size Der Wert gibt die Anzahl der
32 bit-Worte pro Routerinformation an. Dieser
Wert ist gewöhnlich 2, bestehend aus Routeradresse und Routerpräferenz.
Lifetime Dieser Wert gibt die Zeit an, für die diese
Routerliste als gültig angesehen werden kann.
Router Adress Entry Das ist eine Menge von Einträgen zu Informationen von Routern, bestehend
aus folgenden Feldern:
Dieses Programm wurde 1983 von Mike Muss programmiert und zum ersten Mal in 4.2aBSD veröffentlicht. Mittlerweile ist es in der Mehrheit der Betriebssysteme verankert. Mike Muss arbeitete damals
an Radar- und Sonaranlagen, woher auch der Name
„Ping“ stammt [pin06].
Ein Beispiel für die Ping-Ausgabe sieht wie folgt
aus:
ipc654$ ping www.google.de
PING www.l.google.com(66.249.85.104)
56(84) bytes of data.
64 bytes from 66.249.85.104:
icmp_seq=1 ttl=248 time=17.8 ms
64 bytes from 66.249.85.104:
icmp_seq=2 ttl=248 time=11.0 ms
64 bytes from 66.249.85.104:
icmp_seq=3 ttl=248 time=10.6 ms
64 bytes from 66.249.85.104:
icmp_seq=4 ttl=248 time=10.8 ms
Als erstes muss der Name des Ziels in eine IPAdresse umgewandelt werden. Das kann durch das
• Preference Level: Bewertung für diesen DNS geschehen. In der zweiten Zeile steht ein Reply
vom Zielhost. Die Sequenznummer ist 1, d. h. die
Router.
Antwort auf die erste Anfrage. Dann wird die TTL
Während für ein Router Advertisement der Type 9 aufgeführt. Im Beispiel hat die Nachricht 7 Hops beist, kann der Code zwei verschiedene Werte anneh- nötigt, um beim Zielhost anzukommen. Als letztes
men. Zum einen 0 für eine einfache Informationsver- steht in der Zeile die Zeit, die das Echo benötigt hat.
breitung und zum anderen 16 für Mobile IP. Auf den Dabei fällt auf, dass die Zeit der ersten Anfrage länger
letzteren Fall wird in Abschnitt 2.5 genauer eingegan- ist als die darauffolgenden, welche sehr nahe beieinander liegen.
gen.
Die Header für Echo Request und Echo Reply sind
Im Gegensatz zur Router-Advertisement-Nachricht
ist die Solicitation-Nachricht vergleichsweise einfach in Abbildung 2.10(d) dargestellt. Als spezifische Felund kurz aufgebaut. Der Type 10, der Code 0 und der gelten der Identifier und die Sequence Number,
die Checksum wird, wie bereits in Abschnitt 2.3 be- welche zur Identifikation von Anfrage und Antwort
schrieben, gebildet. Diese Nachricht dient ausschließ- dienen.
lich zur Anfrage für ein Advertisement.
Die hier beschriebene Form der Router Discovery Pfad-MTU-Ermittlung Es kommt häufig vor, dass
wird bei IPv4 nur selten verwendet.
in verschiedenen Netzen verschiedene MTU-Werte
• Router Adress: IP-Adresse eines Routers
Ping (Echo Request/Echo Reply) Ping dient
dazu, mit Hilfe von ICMP zu überprüfen, ob ein anderer Computer antwortet. Dabei nennt man eine Anfrage einen Echo Request und eine Antwort Echo Reply.
eingestellt sind. Die Maximum Transfer Unit (MTU)
gibt die maximale Paketgröße in einem Netzwerk an;
größere Pakete müssen fragmentiert werden. Beispiele für MTUs sind die Ethernet-MTU von 1500 B oder
die MTU bei X.25 von 576 B.
25
2. Internet Control Message Protocol (ICMP)
Abbildung 2.12.: Pfad-MTU.
Abbildung 2.13.: Mobile IP mit Hilfe von ICMP.
26
2.5. Kleiner Exkurs: Mobile IP
Die Pfad-MTU (Path MTU) ist die kleinste MTU
entlang eines Pfades vom Quell- zum Zielhost. Es
ist mit Hilfe von ICMP möglich, genau diese MTU
zu ermitteln. Das ist wegen des folgenden, in Abbildung 2.12 dargestellten Problems wichtig.
Wenn ein Paket mehrere Netze durchlaufen muss,
um vom Sender zum Empfänger zu gelangen, kann es
durchaus sein, das in diesen Netzen unterschiedliche
MTUs sind. Angenommen im Absendernetz herrscht
eine MTU von 1500 B. Im nächsten Netz liegt dieser Wert bei 1300 B. Dadurch müsste der Router zwischen Netz 1 und 2 das Paket fragmentieren. Das kostet erstens Zeit und zweitens wird durch den größeren
Datenverkehr wegen der Verdopplung der Header die
Belastung des zweiten Netzes erhöht. Es wäre besser, von vorneherein zu wissen, wie groß die kleinste
MTU auf dem Weg ist.
Die Pfad-MTU wie folgt bestimmt. Ein Computer C1 schickt ein Paket der Größe seiner Netz-MTU
an den Router R1. Liegt dieser zwischen zwei Netzen mit unterschiedlichen MTUs, muss er beide vergleichen. Hat das Netz, wohin die Nachricht weiter übertragen werden soll, einen kleineren MTUWert, so schickt der Router eine ICMP-Nachricht
an den Absender zurück, wenn im IP-Header das
Don’t-Fragment-Bit gesetzt ist. Abbildung 2.10(e)
zeigt den Aufbau der Nachricht. Der Type 3 gehört in die Destination-Unreachable-Kategorie (Abschnitt 2.4.1). Da als Code aber 4 gesetzt ist, welcher Fragmentation needed but Don’t Fragment bit
set bedeutet, zählt es hier zu den Anfragen. Im Datenteil der ICMP-Nachricht stehen zusätzlich die kleinere MTU, der IP-Header und die ersten 64 bit des
Original-Datagramms. Nach dem Erhalt einer solchen
ICMP-Nachricht kann der Absender die Paketgröße
entsprechend ändern und das Paket erneut abschicken.
Diese Prozedur geschieht so lange, bis ein kontinuierlicher Datenstrom entsteht.
2.5. Kleiner Exkurs: Mobile IP
In diesem Exkurs soll es um das aktuelle Thema
Mobile IP gehen. Abbildung 2.13 zeigt das Szenario.
Angenommen, man sitzt im Zug von Berlin nach
München. Da man eine Menge Zeit hat, nutzt man die
Gelegenheit und surft im Internet über WLAN. Da
ein WLAN-Access-Point nur eine begrenzte Sendereichweite besitzt, sind auf der Zugstrecke mehrere
dieser Sender aufgestellt. Die Frage ist nun, was passiert, wenn der Laptop von einem Access Point zum
nächsten wechseln muss. Bei jedem Wechsel ändert
sich die IP-Adresse des Notebooks, weil es sich bei
9
0
checksum
# addr
AES
lifetime
Routeradresse [1]
Routerpräferenz [1]
Routeradress[2]
...
type=16
length
sequence number
registration lifetime
code
reserved
Care-of-Adresse [1]
...
Abbildung 2.14.: Erweiterter ICMP-Header mit
Daten zum Erhalt der Router.
jedem Sender neu anmelden muss. Diese Änderung
unterbricht allerdings die Verbindung, was bei VoIP
(Internettelefonie) oder großen Downloads zu Problemen führen kann. Daraus folgt, dass eine ständige Adressänderung eigentlich nicht möglich ist. Stattdessen werden zwei IP-Adressen verwendet. Es gibt
eine primäre Adresse, die dem Heimatnetz des Laptops zugeordnet ist und fest bleibt, und eine sekundäre Adresse, die sich stetig ändert. Der sogenannte Homeserver empfängt an die primäre Adresse gerichtete Datagramme und leitet sie an die sekundäre
Adresse weiter. Der Server kümmert sich darum, immer zu wissen, wo der Laptop gerade ist.
Um sich in einem fremden Netz anmelden zu können, muss erst einmal in Erfahrung gebracht werden, wo man sich anmelden kann. Der Laptop aus
dem Szenario sendet also eine Router-SolicitationNachricht per Multicast, in welcher die TTL des IPHeaders auf 1 gesetzt ist, um sicher zu stellen, das der
erste Router antwortet. Der Aufbau des Router Advertisement ist in Abbildung 2.14 zu sehen. Dazu gehören folgende spezifische Felder:
Length Dieses Feld gibt die Länge der Nachricht
ohne Typ und Längenfeld an.
Sequence Number Diese Nummer dient zur Identifikation bei mehreren Anfragen und Antworten.
Registration Life Time Die RLT gibt die Anzahl
der Sekunden an, die ein Foreign Agent bereit ist,
eine IP-Adresse anzunehmen.
27
2. Internet Control Message Protocol (ICMP)
Code Dieses Feld informiert über den Zustand des
Agenten.
Hat sich der Laptop an einem Access Point neu angemeldet, schickt er seinem Homeserver darüber eine
Nachricht. Der Homeserver merkt sich diese Verbindung. Bei einer Anfrage aus dem Internet an den Laptop kommt diese zum Homeserver. Anstatt das Paket
direkt weiterzugeben, wird per IP-to-IP-Kapselung
ein neues Paket erzeugt, welches mit der sekundären
IP-Adresse ausgestattet ist.
Die Abwicklung des Pakettransportes geschieht
transparent, da die Anwendungen ausschließlich die
primäre Adresse kennen. Nur die Mobile-IP-Software
selbst verpackt und entpackt die Pakete.
28
3. IP – Routing und Traceroute
Norbert Hundeshagen
3.1. Einführung
Die Vorstellung, die die meisten Menschen heutzutage vom Internet haben, ist die, dass alle Rechner,
der eigene eingeschlossen, direkt mit allen Computern weltweit verbunden sind. Daraus folgt, dass sich
das Internet wie ein einziges großes Netzwerk verhält,
und somit das Kapitel „Routing“ mit wenigen Worten
beendet wäre.
In Wirklichkeit besteht das weltweite Netz aus vielen kleinen und großen Rechnerzusammenschlüssen,
die untereinander durch so genannte Router verbunden sind und Daten mit Hilfe dieser austauschen können (siehe Abbildung 3.1 [Wik06d]).1 Der gemeinsame Standard, den die Endgeräte und Router aus den
verschiedenen Netzwerken hierfür verwenden, ist die
TCP/IP-Protokollsuite.
In den vorausgegangenen Kapiteln wurde bereits
erläutert, wie die Übertragung von Daten auf IP-Basis
funktioniert. Die Frage ist nun, wie die Datagramme
ihren Weg durch das Netz von der Quelle zum Ziel
finden. Dazu möchte ich zu Beginn ein paar Grundlagen zum Thema Routing erklären und mich dann
näher mit dem statischen Routing befassen. Als Abschluss dieses Kapitels werde ich noch das Diagnoseprogramm Traceroute und dessen Funktionsweise
vorstellen.
3.2. Grundlagen des
IP-Routing
Wie bereits in der Einführung erwähnt, ist Routing
die Wegewahl von IP-Datagrammen vom Sender zum
Empfänger. Dabei wird das Ziel eindeutig durch seine IP-Adresse (Destination IP Address) identifiziert,
welche im IP-Header (siehe Abbildung 1.2) zu finden
ist. Dort sind auch noch andere Informationen enthalten, die für die Art des Weiterleitens der Pakete von
1 LAN: Local Area Network, MAN: Metropolitan Area Network,
WAN: Wide Area Network.
Abbildung 3.1.: Schema des Internet.
Bedeutung sind. In dem Feld Options können unter
anderem noch die Möglichkeiten Loose Source Routing, Strict Source Routing und Record Route gewählt
werden.
Die Frage ist nun, nachdem das Ziel bekannt ist, auf
welchem Weg die Datenpakete dort hin gelangen? In
den vergangen Jahren stieg das Verkehrsaufkommen
im Internet explosionsartig an, aus diesem Grund hat
die Wegewahl von Informationen durch das Netz eine zentrale Bedeutung. Pakete, die auf redundante Art
und Weise ihren Weg zum Ziel suchen, erhöhen die
Traffic noch zusätzlich. Also ist es unerlässlich, kürzeste Wege von der Quelle bis zum Ziel zu finden.
3.2.1. Optimale Wege in Netzwerken
Optimale Wege in Netzwerkstrukturen sind dadurch
gekennzeichnet, dass sie zum einen die wenigsten
„Kosten“ verursachen. Von Sender zu Empfänger
wird ein Weg gewählt, welcher sich durch hohe Bandbreite und möglichst direkte Verbindungen auszeichnet. Zum anderen ist es immens wichtig, das solche
Routen schleifenfrei sind. Ist dies nicht der Fall, könnte ein Paket lange Zeit einfach nur im Kreis laufen,
ohne sein Ziel zu erreichen.
29
3. IP – Routing und Traceroute
3. wiederhole 1 und 2, bis alle Knoten angeschlossen sind.
Abbildung 3.2.: Graphenbeschreibung einer
Netzwerktopologie.
In Abbildung 3.3 kann man das Ergebnis dieses Algorithmus sehen.
Anhand des erzeugten Baumes ist es nun möglich,
die Next Hops, also den jeweils nächsten Router, den
ein IP-Datagramm auf dem Weg vom Sender zum
Empfänger passiert, zu identifizieren. Somit kann ein
beliebiger Netzwerkteilnehmer ein Bild seiner Umgebung anfertigen und speichern. Dies geschieht in der
Routing-Tabelle, auf die ich später noch näher eingehen werde.
3.3. Statisches
(Next-Hop-)Routing
Abbildung 3.3.: Minimum Spanning Tree.
Um solche optimale Wege zu ermitteln, bedient
man sich der Graphentheorie. Zur Vereinfachung der
Netzwerktopologie und zur Entwicklung von Routingstrategien wird das Netzwerk als Graph beschrieben. Dabei repräsentieren die Knoten die Router und
die Kanten die direkte Verbindung zwischen ihnen.
Wie man in Abbildung 3.2 sieht, abstrahiert diese Art
der Beschreibung die Endgeräte, da sie für die Berechnung von Routen keine Rolle spielen [Mei05].
Der nächste Schritt ist es, den „kürzesten“ Weg in
einem solchen Graphen zu berechnen. Dies geschieht
mit Hilfe eines so genannten Minimum Spanning Tree
oder minimalem Spannbaum.
Definition Minimaler Spannbaum:
Der Unterschied zwischen statischem und dynamischen Routing, welches anhand von Protokollen relativ selbstständig Veränderungen in der Netzwerktopologie erkennt, besteht im Aufbau und der Wartung
der Routing-Tabelle, in der wie bereits erwähnt die
Next-Hops eingetragen sind.
Grundlage für beide Routingverfahren ist die Art
der Zustellung. Man unterscheidet zwischen indirekter und direkter Zustellung der IP-Datagramme zum
Empfänger.
Ein Beispiel für die zwei Übertragungsarten ist
in Abbildung 3.4 zu sehen. Um direkte Zustellung
handelt es sich, wenn Sender und Empfänger zum
gleichen Netzwerk gehören (Abbildung: Rechner A
Ein minimaler Spannbaum enthält die minimale Anzahl an Kanten, die alle Knoten des
Graphen verbinden.
Anhand der Definition kann man erkennen, dass
beide Bedingungen, kürzeste Wege zu den verschiedenen Routern und keine Kreise in den Graphen, erfüllt sind.
Um einen solchen minimalen Spannbaum zu erzeugen, gibt es mehrere Möglichkeiten. Einer der
schnellsten Algorithmen hierfür ist der Algorithmus
von Prim.
Verkürzter Pseudocode des Prim-Algorithmus:
1. starte mit Knoten A
2. wähle „billigste“ Kante, die erzeugten Baum mit
A verbindet
30
Abbildung 3.4.: Direkte und indirekte Zustellung.
3.3. Statisches (Next-Hop-)Routing
und B) und daher IP-Datagramme direkt übertragen
werden können. Ist dies nicht der Fall, wird das Datenpaket an den Next-Hop-Router geschickt, der in
der Routing-Tabelle eingetragen ist und somit die
Schnittstelle für das Quellnetzwerk darstellt.
3.3.1. Versenden von Daten im
Netzwerk
Bevor ich mich mit Einzelheiten zum Thema Routing auseinandersetzen will, möchte ich in diesem
Abschnitt anhand des Beispielnetzwerkes in Abbildung 3.5 einen kurzen Überblick über die Aufgaben,
die ein Router beim Weiterleiten von Datenpaketen
hat, geben.
In der Darstellung sind drei Netzwerke zu sehen,
die durch zwei Router verbunden sind. Diese besitzen
zu ihren lokalen Netzwerken jeweils eine Schnittstelle, sie sind also Mitglieder der Netzwerke, die sie verbinden. Des Weiteren werden drei Rechner (A, B, C)
samt ihrer IP-Adresse angezeigt.
Am Beispiel des sendenden Host A möchte ich die
zwei Möglichkeiten der Datenversendung, die bereits
in der Einleitung besprochen wurden, betrachten.
Router 1 erkennt, dass die Datenpakete nicht an ihn
gerichtet sind und weitergeleitet werden müssen. Ob
er die Daten dabei direkt ausliefern kann oder an ein
anderen Router schickt, entscheidet er wiederum anhand des Netzwerk-Präfixes. Im Beispiel stimmen die
Präfixe von Host C und den Netzen, an die Router 1
angeschlossen ist, nicht überein. Aus diesem Grund
muss ein weiterer Zwischenpunkt gefunden werden,
der mittels direkter Zustellung erreicht werden kann.
Dies ist in der Darstellung der Router 2, der eine
Schnittstelle mit Router 1 gemeinsam hat. Nun haben
die Datenpakete einen Router erreicht, bei dem das
Netzwerk-Präfix mit dem des Ziels übereinstimmt.
Router 2 kann nun die Daten direkt ausliefern.
Gibt es in dem Netz keinen Rechner mit der gesuchten IP-Adresse, sendet der Router eine Nachricht
zurück zur Quelle, die besagt das der Host nicht erreichbar ist.
Die vorangegangenen Absätze haben nur einen
sehr groben Überblick darüber gegeben, wie und auf
welcher Grundlage ein Router seine Entscheidungen
trifft, wie mit zu versendenden Daten weiter zu verfahren ist. Im weiteren Verlauf soll daher näher auf
diese Fragen eingegangen werden.
3.3.1.1. Direkte Zustellung
Wie bereits erwähnt, handelt es sich um direkte Zustellung, wenn Quelle und Ziel im selben Netzwerk
liegen. Zwei Rechner liegen im selben Netzwerk,
wenn sie die gleiche Netzwerk-Präfix besitzen. Da es
sich im Beispiel um ein Klasse-B-Netzwerk handelt,
bestimmen die ersten 16 bit der IP-Adresse den Netzwerkanteil.
Sendet Host A Daten an Host B, werden die Datagramme mit der Zieladresse versehen. A erkennt anhand des Präfixes von B (129.36), dass es einen direkten Weg zum Ziel gibt und schickt die Pakete ins
eigene Netz an den Empfänger.
3.3.1.2. Indirekte Zustellung
Um indirekte Zustellung handelt es sich, wenn Quelle
und Ziel nicht im selben Netzwerk liegen. Will, wie
im Beispiel zu sehen, Host A Daten an Host C senden,
ist dieser für ihn nicht direkt erreichbar, da Host C in
einem anderen Netzwerk liegt. Host A muss sich also
für einen Router in seinem Netz entscheiden, der die
Daten weiterleitet. In diesem Fall ist Router 1 direkt
an Netzwerk 1 angeschlossen. A sendet die Daten an
diesen Router. Dieser Vorgang funktioniert genauso
wie im Abschnitt 3.3.1.1 beschrieben.
3.3.2. IP-Routing-Algorithmus
Um welche Art der Übertragung es sich handelt,
entscheidet ein sendender Rechner anhand der IPZieladresse, die im Datagramm zu finden ist. Dabei
durchläuft jede Maschine, die IP-Pakete verschickt
oder weiterleitet, eine Verarbeitungsvorschrift, den so
genannten Routing-Algorithmus.
Wie man in Abbildung 3.6 sieht, wird zu Beginn
die Zieladresse bestimmt und überprüft, ob es einen
hostspezifischen Weg zum Empfänger gibt. Wenn ja,
wird das Paket verschickt. Ist dies nicht der Fall, richtet sich der Blick nun auf den Netzwerkanteil der
Adresse, mit der Frage, ob es sich um das eigene Netz
handelt oder ob es eine Schnittstelle zum gesuchten Ziel gibt. Können beide Möglichkeiten ausgeschlossen werden, wird zum Schluss in der RoutingTabelle überprüft, ob eine Default-Route definiert ist.
Wenn auch dies nicht zutrifft, erhält der Sender eine
ICMP-Nachricht Destination Unreachable (vgl. Abschnitt 2.3).
Anhand des Algorithmus lässt sich bereits erahnen, dass die Grundlage für sämtliche Entscheidungen über die Art und den Weg der Zustellung von IPDatenpaketen die Routing-Tabelle ist.
31
3. IP – Routing und Traceroute
Abbildung 3.5.: Beispielnetzwerk.
Abbildung 3.6.: IP-Routing-Algorithmus.
32
3.3. Statisches (Next-Hop-)Routing
Abbildung 3.7.: Routing-Tabelle.
3.3.3. Routing-Tabelle
Im weiteren Verlauf möchte ich näher auf den Inhalt
der Routing-Tabelle eingehen sowie deren Erstellung
und Modifikation. In der Abbildung 3.72 sieht man eine solche Tabelle, die mit dem Befehl netstat -r3
aufgerufen wird. Die erste Spalte zeigt das Ziel, an
welches die Pakete gesendet werden sollen, die zweite das Gateway (Router), über den sie laufen müssen.
Der erste Eintrag ist die Standardroute, also diejenige,
die gewählt wird, falls kein passender Eintrag für den
Empfänger existiert. Im Beispiel hat der Defaultrouter
die IP-Adresse 141.35.1.1, welcher, wie in der Abbildung zu sehen ist, auch für nahezu sämtliche Einträge
definiert ist. Dass diese Adresse ein Router ist, kann
man an dem gesetztem G-Flag in der nächsten Spalte
sehen.
Unter Flags können auch noch verschiedene andere
Attribute der Route festgelegt werden [Fre06]:
C Clone: Erzeugt eine neue Route, basierend auf der
Route für den Rechner, mit dem wir uns verbinden. Diese Routenart wird normalerweise für lokale Netzwerke verwendet.
W WasCloned: Eine Route, die automatisch konfiguriert wurde. Sie basiert auf einer lokalen Netzwerkroute (Clone).
Die Spalte Refs (References) gibt die Anzahl der
aktiven Verbindungen auf der Route an. Die nächste Spalte Use zeigt die Anzahl der gesendeten Pakete
und If bezeichnet das verwendete Interface.
Ich möchte jetzt noch ein paar Routen im einzelnen besprechen. Als erstes fällt die Route mit
der IP-Zieladresse 127/84 auf, die das lo0, also
das Loopback-Interface verwendet. Pakete an diese
Adresse werden innerhalb des Rechners behandelt
U Up: Die Route ist aktiv.
und verlassen diesen nicht. Das gleiche gilt auch für
H Host: Das Ziel der Route ist ein einzelner Rechner Datagramme, die an 141.35.1.41 (eigene IP-Adresse)
(Host).
geschickt werden.
In den Zeilen 4 und 7 sieht man die Zieladressen
G Gateway: Alle Daten, die an dieses Ziel gesendet für den Broadcast, 141.35.1.0 und 141.35.1.63, welwerden, werden von diesem System an ihr jewei- che sich aus der in Zeile 5 zu erkennenden Subnetzliges Ziel weitergeleitet.
maske ergeben. Pakete, die so adressiert sind, gehen
S Static: Diese Route wurde manuell konfiguriert, an alle direkt angeschlossenen Hosts. Rundrufe diedas heißt, sie wurde nicht automatisch vom Sys- nen zum Beispiel dem ARP-Protokoll dazu, dass sich
die Netzteilnehmer identifizieren. Die Frage ist nun,
tem erzeugt (siehe Abschnitt 3.3.4).
wie man solche Routing-Tabellen bei sich ändernder
2 Gekürzte Routing-Tabelle vom Server fsuj50.rz.uni-jena.de des Netztopologie wartet.
Universitätsrechenzentrums.
3 In der Abbildung wurde der Befehl netstat mit dem zusätzlichen Flag -n benutzt, um eine Auflösung der IP-Adressen in
Namen zu verhindern.
4 CIDR-Schreibweise, aufgelöst 127.0.0.1.
33
3. IP – Routing und Traceroute
3.3.4. Aufbau und Modifikation der
Routing-Tabelle
3.3.4.3. ICMP Router Discovery
Wie bereits beim ICMP Redirect gesehen, benöDa dieses Kapitel nur das statische Routing betrachtet tigt der Host auch für ICMP Router Discovery eine
und somit die Tabelle nicht dynamisch durch Proto- Defaultroute.
Zu Beginn setzt der Host eine ICMP-Routerkolle aufgebaut wird (dazu siehe Kapitel 4), gibt es
Solicitation-Nachricht
ab, was bedeutet, dass der Senprinzipiell nur drei Möglichkeiten sie zu modifizieder
um
Angabe
eines
Next-Hop-Routers
bittet. Wird
ren: manuell, mittels ICMP Redirect und ICMP Roudiese
Mitteilung
von
einem
Router
empfangen,
antter Discovery. Dabei muss man erwähnen, dass autowortet
dieser
mit
einem
ICMP
Router
Advertisement.
matisch bei der Initialisierung eines neuen Interfaces
die Loopback-Route sowie, falls vorhanden, die Rou- Er gibt damit dem Sender seine Adresse bekannt,
welche der Routing-Tabelle hinzugefügt wird. Dieser
te in das angeschlossene Netzwerk gesetzt wird.
Vorgang kann nun periodisch ablaufen, um mögliche
Veränderungen im Netz zu erkennen.
3.3.4.1. Manuell
Mit Hilfe der Befehle route add und route del 3.3.4.4. Vor- und Nachteile des statischen
lassen sich manuell Routen zur Routing-Tabelle hinAufbaus von Routing-Tabellen
zufügen oder löschen.
Aus dem vorangegangenen Abschnitt ist leicht zu erBeispiel:
kennen, dass sich das statische Routing besonders für
kleine, weitgehend veränderungsfreie Netzwerke eigroute add [-host|net] <dest-IP> [gw <gw-IP>]
net. Durch seine „Benutzerfreundlichkeit“ ist es daher
[netmask <mask>] dev <if>
noch nahezu in jedem Heimnetzwerk zu finden.
route del [-host|net] <dest-IP> [gw <gw-IP>]
Werden die Topologien größer (große LANs oder
[netmask <mask>] dev <if>
MANs), wäre es äußerst zeitaufwendig, eine manuelle
Parameter (das Aussehen der Befehlsfolge variiert Betreuung der Routing-Tabellen vorzunehmen, da die
Strukturen zu starken Änderungen unterworfen sind
je nach Betriebssystem):
und optimale Routen, wie in Abschnitt 3.2.1 gesehen,
-host|-net Direkte Route zum Host oder in ein an- teils „per Hand“ berechnet werden müssten.
Aus diesem Grund existiert mittlerweile eine Reideres Netz.
he von Möglichkeiten, die Routing-Tabellen mit Hilfe
von Protokollen dynamisch aufzubauen. Andernfalls
dest-IP Zieladresse.
hätte das Internet in den letzten Jahren nicht so ein
rasantes Wachstum erfahren.
gw-IP Adresse des Routers.
mask Subnetzmaske.
3.4. Traceroute
if Das verwendete Interface.
Das Programm Traceroute wurde 1988 von Van Jacobson entwickelt. Es dient seitdem als nützliches
3.3.4.2. ICMP Redirect
Werkzeug zu Ermittlung von Routen, die DatenpaDamit das „Routenfinden“ mittels ICMP Redirect kete vom sendenden zum empfangenden Host nehfunktioniert, ist es erforderlich, dass in der Routing- men können. Die Mehrzahl des Wortes „Routen“ wurTabelle wenigstens ein Standardweg manuell oder via de im vorangegangenen Satz nicht ohne Grund geifconfig eingetragen wurde.
braucht, da es keine Garantie dafür gibt, dass IPDer Quellhost sendet ein IP-Datagramm an Rou- Datagramme immer denselben Weg zum Empfänger
ter 1 (siehe Abbildung 2.7: R1). Dieser erkennt, dass nehmen. Und auch die Rückrichtung ist nicht garandas Paket über einen anderen Router (R2), der auch tiert: sendet Host A an Host B über eine bestimmte
direkt mit dem Sender verbunden ist, zum Ziel ge- Route ein Paket und schickt B dasselbe wieder zurück
langt und leitet es weiter. Dann schickt Router 1 ei- zu A, so ist es möglich, dass der Rückweg ein anderer
ne ICMP-Redirect-Nachricht an den Host, die besagt, als der Hinweg ist.
dass Router 2 ein günstigerer Weg zur EmpfängerDa das Programm Ping hinlänglich bekannt ist,
adresse ist. Der Host fügt die neue Route seiner Ta- könnte die Frage aufkommen, wieso man nicht diebelle hinzu.
ses mit der Record-Route-(RR-)Option (ping -r)
34
3.4. Traceroute
benutzt, um Wege aufzuzeichnen (vgl. dazu Abschnitt 1.4.2)? Ping geht dabei folgendermaßen vor:
Es sendet Echo-Request-Nachrichten an den Rechner,
der „angepingt“ wird. Auf dem Weg dorthin sind alle passierten Router durch die verwendete RecordRoute-Option angehalten, ihre IP-Adresse in das Paket einzutragen.
Der Nachteil dabei ist, dass nur Platz für neun
Adressen besteht. Dies war in den Anfangszeiten des
Internets völlig ausreichend, ist aber bei den heutigen Netzdimensionen nicht mehr zu gebrauchen.
Des Weiteren geht die aufgezeichnete Route verloren,
wenn der Zielrechner nicht zu erreichen ist, da in diesem Fall kein Paket zurück läuft. Ein weiterer Grund
gegen den Einsatz von Ping ist der, dass die Router,
die auf dem Weg von der Quelle zum Ziel liegen, die
Record-Route-Option unterstützen müssen. Andernfalls tragen diese ihre Adressen nicht in das gesendete
Paket ein.
3.4.1. Funktionsweise von
Traceroute
Traceroute basiert auf dem Versand von IPDatagrammen und macht sich dabei das Time-ToLive-Feld (TTL) im IP-Header (siehe Abbildung 1.2)
zunutze.
Das TTL-Feld wird üblicherweise dazu genutzt, IPPakete mit einer Lebensdauer zu versehen. Dazu initialisiert man den TTL der zu verschickenden Pakete
mit einem bestimmten Wert5 . Auf dem Weg vom Sender zum Empfänger verringert jeder passierte Router
diesen Wert um 1, bis das Paket am Ziel ankommt
oder der TTL-Wert 0 ist. In diesem Fall sendet der aktuelle Router eine Time-Exceeded-Nachricht an den
Sender und verwirft das Datagramm.
Dieses Verhalten der IP-Datagramme macht sich
nun Traceroute zunutze. Es verschickt Pakete mit
TTL=1 in Richtung Ziel. Erreichen diese Pakete den
ersten Router, dekrementiert dieser die TTL auf 0
und verwirft diese Datagramme. Dabei werden TimeExceeded-Nachrichten zurück zum Empfänger gesandt, in welchen der erste Router seine IP-Adresse
eingetragen und somit sich für den sendenden Host
identifiziert hat. Nun sendet Traceroute IP-Pakete mit
TTL=2. Diese passieren den bereits erkannten Router und erreichen den nächsten mit einer TTL von 1.
Dort geschieht dasselbe wie im ersten Fall: die Pakete
werden verworfen und eine ICMP-Nachricht mit der
gesuchten IP-Adresse zurückgeschickt. Daraus kann
5 Je nach Implementierung liegt dieser Wert üblicherweise zwischen 255 und 64.
man allgemein ableiten, dass das Programm Datagramme mit TTL=n verschickt, um den n-ten Router
auf dem Weg von der Quelle bis zum Empfänger zu
identifizieren.
Aber wie erkennt Traceroute, wann das Ziel
erreicht ist? Der Endrechner verringert zwar die
TTL auf 0, verschickt aber keine Time-ExceededNachricht, da das Paket ja „rechtzeitig“ angekommen
ist.
Um den empfangenden Host zu erkennen, macht
sich die Software den Fakt zu nutze, dass üblicherweise auf Rechnern Ports mit sehr hoher Nummer
nicht offen sind. Aus diesem Grund werden in den IPDatagramme UDP-Pakete an eine Portnummer größer 30000 verschickt. Erreichen diese das Ziel und
treffen auf einen geschlossenen Port, wird eine PortUnreachable-Nachricht an die Quelle gesendet.
Somit weiß Traceroute, dass die Routenverfolgung
beendet ist. In Abbildung 3.8 [Lin06] ist die Funktionsweisen noch einmal graphisch veranschaulicht.
3.4.2. Ausgabe von Traceroute
Abbildung 3.9 stellt beispielhaft die Ausgabe des Programms Traceroute unter Linux dar. Wie man erkennen kann, wird das Programm mit dem Befehl
traceroute <destination> aufgerufen.
Hier wurde eine Routenverfolgung vom Host
fsuj50.rz.uni-jena.de zu google.de aufgezeichnet. Die
vierte Zeile gibt den Namen des Ziels und den der
Quelle an, maximalen TTL-Wert (30 hops max) und
in der fünften Zeile die Paketgröße6 . Die nachfolgende Ausgabe zeigt in der ersten Spalte den TTL-Wert,
dann den Namen und/oder die IP-Adresse des Routers
und in den letzten drei Spalten stehen Zeitangaben in
Millisekunden.
Daraus folgt, dass Traceroute immer drei Datagramme je TTL-Wert Richtung Ziel verschickt. Durch
diese Redundanz soll vermieden werden, dass die
Identifizierung eines Routers allein von einem gesendeten Paket abhängt.
Hier sind die Round-Trip-Zeiten angegeben, also
die Zeiten vom Senden des Datagramms bis zum Eintreffen der ICMP-Nachricht. Erreicht diese Nachricht
nicht innerhalb von 5 s die Quelle, gilt das Paket als
verloren und das nächste wird gesendet7 . In der Ausgabe macht sich das durch ein (*) bemerkbar. Dies
6 Die Maximum Transfer Unit (MTU) gibt die maximale Paketgröße in Bytes an.
7 In der Abbildung 3.9 gibt es eine Besonderheit bei der TTL=17.
Nach dem ersten gesendeten und zurückgelaufenen Datagramm
wurden die letzten beiden über einen anderen Router gelenkt.
35
3. IP – Routing und Traceroute
Abbildung 3.8.: Funktionsweise von Traceroute.
Abbildung 3.9.: Ausgabe von Traceroute.
36
3.5. Zusammenfassung
geschieht solange, bis entweder das Ziel oder der maximale TTL-Wert erreicht ist.
3.4.3. Anwendungsmöglichkeiten
von Traceroute
Hauptsächlich wird Traceroute von Netzwerkadministratoren als Diagnosewerkzeug genutzt. Es dient
dort zur Überprüfung der eingesetzten Routingtabelle
und zum Aufspüren von Routingfehlern.
Als weiteres Beispiel sei hier eine Videokonferenzschaltung genannt, bei der die Teilnehmer starke Bildverzögerungen feststellen. Mit Hilfe von Traceroute
ist es möglich, anhand der Round-Trip-Zeiten zu ermitteln, welcher Router auf dem Weg zur anderen
Endstelle diese Probleme verursacht.
Als abschließende Möglichkeit, das Programm zu
verwenden, sei noch erwähnt, dass Traceroute auch
dazu eingesetzt werden kann, Firewalls zu identifizieren.
3.5. Zusammenfassung
Dieses Kapitel hat einen grundlegenden Überblick
über das IP Routing gegeben. Es soll ermöglichen,
sich mit dem Thema vertraut zu machen, ohne sich
in dessen Detailreichtum völlig zu verlieren. Aus diesem Grund wurden Einzelheiten ausgelassen oder nur
angerissen.
Des Weiteren möchte ich erwähnen, dass das statische Routing heutzutage seine Anwendung nur noch
in kleinen, leicht zu wartenden Netzwerken findet und
in größeren Topologien durch eine Vielzahl von dynamischen Routing-Algorithmen ersetzt wurde, von
denen einige im folgenden Kapitel beschrieben werden. Trotzdem eignet es sich im besonderen dazu, die
Entwicklung von Verfahren zum Routen von Paketen,
sowie die Erstellung von Routing-Tabellen zu erklären.
37
4. Dynamic Routing: RIP, OSPF, BGP
Marco Swiercy
4.1. Einführung
che er in die Routingtabelle einträgt. Stellt der Routing Daemon fest, dass eine Verbindung abgebrochen
Dynamic Routing bezeichnet die Wegewahl im Netz- ist (durch was auch immer: Leitungsdefekt, Routerwerk, bei der nicht am Startknoten der Weg zum Ziel- defekt, . . . ), dann kann er betroffene Routen aus der
knoten mit allen Zwischenstationen bekannt ist, son- Routingtabelle löschen und alternative Routen einfüdern jeder Knoten dynamisch entscheidet, zu wel- gen, um so das Problem zu umgehen.
In einem System wie dem Internet werden mehrere
chem Nachbarknoten er sein erhaltenes Paket weiterschickt. Sobald das Netzwerk größer wird oder Al- verschiedene Routing-Protokolle verwendet. Das Internativrouten entstehen, spielt Dynamic Routing eine ternet ist als eine Menge von Autonomen Systemen
(Autonomous System, AS) organisiert, wobei jedes
große Rolle.
Dafür sind in der TCP/IP-Protokoll-Familie ver- einzelne eine eigene administrative Verwaltung hat.
schiedene Protokolle implementiert: das Routing In- Große Organisationen wie Universitäten oder große
formation Protocol (RIP), Open Shortest Path First Firmen stellen meist ein solches AS dar.
Jedes AS kann ein Routing-Protokoll wählen, mit
(OSPF), oder das Border Gateway Protocol (BGP),
dem die Router innerhalb dieses AS kommunizieum nur einige zu nennen.
ren. Dieses Protokoll heißt Interior Gateway Protocol
(IGP) oder Intradomain Routing Protocol. Die bekanntesten IGPs sind RIP und OSPF.
4.2. Dynamic Routing
Verschiedene Routing-Protokolle, so genannte Exterior Gateway Protocols (EGP), werden für die
Dynamic Routing tritt immer dann auf, wenn RouKommunikation zwischen verschiedenen AS benutzt.
ter mit benachbarten Routern Informationen darüber
Ein neueres Exemplar dieser Protokollklasse ist das
austauschen, mit welchem Netzwerk jeder momentan
Border Gateway Protocol (BGP).
verbunden ist. Der Prozess, der auf dem Router läuft
und auf dem das Routing Protokoll läuft, welches mit
den benachbarten Routern kommuniziert, wird Routing Daemon genannt. Dieser Routing Daemon aktua- 4.3. Routing Information
lisiert die Routing-Tabelle des Kernels anhand von
Protocol (RIP)
Information, die er von den Nachbarroutern erhalten
hat.
Das etwas überholte RIP ist ein typisches
Die Verwendung von Dynamic Routing ändert Distanzvektor-Protokoll (Distance Vector Protocol),
nicht die Art und Weise, wie der Kernel das Routing welches im RFC 1058 [Hed88] spezifiziert wurde.
auf dem IP-Layer gestaltet. Der Kernel sucht nach wie
vor in seiner Routingtabelle, sucht nach Hostrouten,
Netzwerkrouten und Defaultrouten (Abbildung 4.1, 4.3.1. Nachrichtenformat
für Details siehe Abschnitt 3.3.2). Was sich ändert, ist
die Information, die in den Routingtabellen abgelegt RIP-Nachrichten werden in UDP-Datagrammen überwird – sie werden vom Routing Daemon dynamisch tragen. Die Kapselung erfolgt wie in Abbildung 4.2 zu
hinzugefügt und gelöscht, so wie sich die Routen über sehen.
die Zeit ändern. Findet der Routing Daemon mehrere
Abbildung 4.3 zeigt das Format der RIP-Nachricht.
verschiedene Routen zum gleichen Ziel, entscheidet Command ist eine Zahl zwischen 1 und 6. Ein Eintrag
der Routing Daemon, welche die beste ist und wel- von 1 im Command-Feld ist ein Request und 2 ein
39
4. Dynamic Routing: RIP, OSPF, BGP
routing
daemon
route
command
netstat
command
UDP
TCP
ICMP
MP s
IC irect
d
re
routing
table
JA
unser
packet ?
NEIN
IP output:
berechne
‚next hop‘
a
forw
rd
gram
data
source routing
process IP options
IP input queue
IP Layer
network interfaces
Abbildung 4.1.: Übersicht des Routing-Vorgangs.
Reply. 3 und 4 zählen als veraltet. 5 ist ein Poll und 6
den sind und schickt an jedes ein Request-Paket,
der entsprechende Poll-Reply.
in dem er jeden Nachbarrouter auffordert, seine
Der Version-Eintrag ist überlicherweise 1 oder 2
gesamte Routing Table zurückzusenden. Dieser
für RIP Version 1 bzw. RIP Version 2. Die folgenRequest wird per Broadcast gesendet, falls dies
den 20 Bytes spezifizieren die Address Family, die
das Netzwerk unterstützt. Dieses Request-Paket
für IPv4-Adressen immer auf 2 steht, eine IP-Adresse
ist ein spezielles Paket: Command ist 1, Address
und eine mit dieser Adresse assoziierten Metric.
Family ist 0 und Metric ist 16. So wird die geBis zu 25 Routen können in einer RIP-Nachricht
samte Tabelle abgefragt.
versendet (advertised) werden, die alle dieses 20 BFormat haben. Die Grenze von 25 Routen hält die Request erhalten Wenn der Request von der Art
ist wie oben beschrieben ist, wird die gesamGesamtgröße einer RIP-Nachricht (25 · 20 + 4 = 504)
te Routing-Tabelle an den nachfragenden Roukleiner als 512 B. Es ist möglich, dass diese 25 Plätze
ter gesendet. Ansonsten wird der Request verarnicht ausreichen, um die gesamte Routing-Tabelle zu
beitet: Wenn „wir“ eine Route zur nachgefragten
übertragen. Dann werden mehrere RIP-Nachrichten
Adresse haben, dann setzen wir die Metric auf
versendet.
unseren Wert, ansonsten auf 16 (16 ist ein spe-
Initialisierung Wenn der Daemon startet, stellt er
alle Interfaces zusammen, die mit ihm verbun-
command (1-6)
version (1)
address family (2)
(must be zero)
(must be zero)
32-bit IP address
(must be zero)
(must be zero)
IP datagram
Metric (1-16)
UDP datagram
(up to 24 more routes, with same format as previous 20 bytes)
IP Header
UDP Header
RIP message
Abbildung 4.2.: RIP-Einkapselung.
40
Abbildung 4.3.: RIP-Header.
20 bytes
4.3.2. Standard-Operationen
4.4. Open Shortest Path First (OSPF)
zieller Infinity-Wert und bedeutet, dass wir keine
Route zu der nachgefragten IP-Adresse haben).
Zum Schluss wird die Antwort zurückgesandt.
Reply erhalten Die Antwort wird ausgewertet und
darf die Routing-Tabelle aktualisieren. Neue
Einträge können hinzugefügt und gelöscht oder
bestehende Einträge modifiziert werden. Befindet sich in der Antwort eine Route zu einer IPAdresse, die wir auch kennen, ersetzen wir unsere alte Metric mit der aus der Antwort + 1, wenn
dieser Wert kleiner ist als die uns bekannte Metric. Routen aus der Nachricht, die wir nicht kennen, werden unserer Routingtabelle hinzugefügt.
Regelmäßige Updates Alle 30 s wird die gesamte
Routing-Tabelle zu jedem Nachbarrouter gesendet. Sie wird entweder per Broadcast (Ethernet)
oder via Punkt-zu-Punkt-Verbindung übertragen.
Ausgelöste Updates (Triggered Updates)
Diese treten auf, wenn sich die Metric für eine
Route ändert. Dann muss nicht die gesamte
Routingtabelle gesendet werden, sondern nur
die Einträge, die sich änderten.
Abbildung 4.4.: RIP-Metrics.
4.3.4. Nachteile
Jede Route hat weiterhin noch einen mit ihr assoziierten Timeout. Findet das System, auf dem RIP
läuft, eine Route, die 3 min kein Update erhielt, dann
wird die Metric dieser Route auf 16 gesetzt und somit fürs Löschen markiert. Das heißt also, dass wir 6
dieser oben erwähnten 30 s-Updates von dem Router,
der diese Route verkündet, nicht bekommen haben.
Die endgültige Löschung der Route wird dann noch
einmal um 60 s verzögert.
RIP kennt keine Subnetz-Adressierung. Wenn zum
Beispiel eine normal 16 bit lange Host-ID größer Null
ist, dann weiß RIP nicht, ob dieser Nicht-Null-Anteil
eine Subnet-ID ist oder ob die IP-Adresse die komplette Host-Adresse ist.
Ein weiterer Schwachpunkt von RIP ist die sehr
hohe Konvergenzzeit. Das ist die Zeit, die das Netzwerk benötigt, um sich nach einer Topologieänderung
(Disconnects, neue Knoten, . . . ) wieder zu stabilisieren. Der Zustand wird als stabil bezeichnet, wenn
alle Knoten wieder im Netzwerk einen homogenen
4.3.3. Metrics
„Wissensstand“ über das Gesamtnetzwerk haben. Bei
Die vom RIP verwendete Metric ist der Hop-Count. RIP verbreitet sich eine Information, beispielsweise
Der Hop-Count zu allen direkt verbundenen Inter- über den Ausfall eines Routers, sehr langsam. Bei eifaces beträgt 1.
nem RIP-basierten Netzwerk maximaler Größe, also
Beispiel (siehe Abbildung 4.4): B sendet A eine 15 Hops, kann die Konvergenzzeit bis zu 7.5 min beRoute nach D mit Metric 2, A trägt diese Route in tragen, wenn wir davon ausgehen, dass das reguläre
seine Routingtabelle ein mit einer Metric von 3.
Update alle 30 s erfolgt.
Dadurch, dass jeder Router seine Routingtabelle
an seine Nachbarn sendet, kann eine Route zu jedem
Netzwerk innerhalb des AS (Autonomes System, da4.4. Open Shortest Path First
zu später mehr) bestimmt werden. Gibt es mehrere
(OSPF)
mögliche Pfade in dem AS zu einem Zielrouter, dann
wählt der Startrouter den Pfad, der mit dem niedrigsten Hop-Count assoziiert ist und ignoriert alle übrigen Open Shortest Path First [Moy94] ist eine neueMöglichkeiten. Da der Hop-Count auf 15 limitiert ist, re IGP-Alternative zum RIP (Header siehe Abbildarf RIP nur in AS laufen, in denen keine zwei Router dung 4.5). Es räumt mit allen Nachteilen des RIP auf
und ist heute das dominierende Protokoll, während
mehr als 15 Hops voneinander entfernt sind.
41
4. Dynamic Routing: RIP, OSPF, BGP
Version
Type
Length
Router ID
Area ID
Checksum
AuType
Authentication
Schema zur Verfügung, das erlaubt, ein Passwort zu
spezifizieren. So wird gewährleistet, dass die eigene Routing-Tabelle nur von authentifizierten Routern
aktualisiert werden darf. Außerdem benutzt OSPF
Multicast statt Broadcast.
DATEN
Abbildung 4.5.: OSPF-Header.
RIP in der Praxis fast keine Verwendung mehr findet. Im Gegensatz zu RIP – ein Distanzvektorprotokoll (Distance Vector Protocol) – ist OSPF ein Verbindungszustandsprotokoll (Link State Protocol). Distanzvektorprotokoll bedeutet ja, dass die Nachrichten, die vom RIP versendet werden, einen Vektor
mit den Entfernungen (Hop-Counts) enthalten. Jeder
Router hält seine Routingtabelle anhand dieser Vektoren, die er von seinen Nachbarn bekommt, so auf den
neuesten Stand.
In einem Verbindungszustandsprotokoll tauschen
die Router keine Entfernungen ihrer Nachbarn miteinander aus. Stattdessen testet jeder Router aktiv
den Status seiner Verbindung zu jedem Nachbarn.
Diese Informationen, die er dann all seinen Nachbarn schickt, verbreiteten sich so durch das gesamte
AS. Jeder Router baut sich mit Hilfe der Link-StateInformationen eine komplette Routingtabelle auf, die
die Form eines Baums hat, an dessen Wurzel er selbst
steht (vgl. Algorithmus S HORTEST PATH F IRST von
Edsger W. Dijkstra). In praktischer Hinsicht haben
Verbindungszustandsprotokolle gegenüber Distanzvektorprotokollen den entscheidenden Vorteil, schneller zu konvergieren.
Davon abgesehen, dass OSPF ein Verbindungszustandsprotokoll und kein Distanzvektorprotokoll ist,
hat es noch einige entscheidende Vorteile gegenüber
dem RIP.
Der Router übermittelt nur Änderungen in seiner Routing-Tabelle per Multicast an Nachbarn.
Zur Verbreitung der Änderungen werden Link-StateAdvertisement-Nachrichten verwendet. Jedem Interface ist ein dimensionsloser Kostenwert zugewiesen.
Gibt es mehrere gleichkostende Routen zu einem Ziel,
verteilt OSPF den Datenverkehr gleichmäßig auf diese Routen (Load Balancing). Des Weiteren unterstützt OSPF Subnetting (vgl. Abschnitt 1.5.4). Mit jeder Route wird eine Subnetz-Maske assoziiert. Punktzu-Punkt-Verbindungen brauchen bei OSPF keine
IP-Adresse an jedem Ende. Dies kann IP-Adressen
sparen. OSPF stellt ein einfaches Authentifikations-
42
4.5. Autonome Systeme und
das Border Gateway
Protocol
Ein Autonomes System (AS) ist ein IP-Netz, das unter
einer gemeinsamen administrativen Verwaltung steht,
z. B. durch eine Firma, Universität oder InternetProvider, und selbst wiederum aus Teilnetzen bestehen kann. Jedes AS hat eindeutige AS-Nummer
(ASN, 16 bit Integer, geplant ist 32 bit). Verwaltet
wird diese durch die Internet Assigned Numbers Authority (IANA). Die weitere Zuteilung erfolgt durch
eine der Regional Internet Registries (RIR), für Europa ist das das RIPE NCC.
BGP ist ein Exterior Gateway Protocol zur Kommunikation zwischen Routern, die verschiedenen Autonomen Systemen angehören. BGP ist ein Ersatz des
älteren EGP, welches auf dem ARPANET benutzt
wurde.
Ein BGP-System tauscht Information über seine
Erreichbarkeit zu anderen Netzwerken mit anderen
BGP-Systemen aus. Diese Information schließt die
vollen Pfade der autonomen Systeme ein, also alle
AS, die die Daten auf dem Weg zu diesen Netzwerken
passieren müssen. Aus dieser Information lässt sich
ein Graph erzeugen, mit dem es zum Beispiel möglich ist, Schleifen zu verhindern (z. B.: Bin ich selbst
als Knoten in einem Pfad erhalten? Wenn ja? – Schleife!).
Ein IP-Datagramm lässt sich – bezogen auf autonome Systeme – zunächst danach klassifizieren, ob
es entweder lokalen Traffic oder Transit-Traffic hat.
Autonome Systeme können demnach folgendermaßen kategorisiert werden [Wik06a]:
Stub-AS sind an genau ein anderes AS geschlossen
(nur lokaler Traffic).
Multihomed-Stub-AS sind durch mehrere Links
mit einem anderen AS verbunden (nur lokaler
Traffic, höhere Ausfallsicherheit).
Multihomed-AS sind an mehrere andere AS
geschlossen (nur lokaler Traffic, verweigert
Transit-Traffic).
4.6. Zusammenfassung
Transit-AS sind an mehrere andere AS geschlossen
(lokaler Traffic und Transit-Traffic).
4.6. Zusammenfassung
Man kann Routingprotokolle grundsätzlich in zwei
verschiedene Protokolltypen einteilen, Interior Gateway Protocols (IGP) zur Kommunikation zwischen
Routern innerhalb eines einzelnen Autonomen Systems und Exterior Gateway Protocols (EGP) zur
Kommunikation zwischen Routern aus mindestens
zwei verschiedenen Autonomen Systemen. Das Routing Information Protocol, das zu der Zeit, in der
Stevens’ Buch [Ste94] entstand, das dominierende
IGP war, ist mittlerweile vom stärkeren Open Shortest Path First weitgehend abgelöst worden. OSPF
räumt mit den Nachteilen von RIP auf, wie der Beschränkung auf 15 Hops. Das dominierende EGP ist
das Border Gateway Protocol (BGP), welches durchschnittlich kleinere Konvergenzzeiten hat und Schleifen verhindert, da es komplette Routen vom Start zum
Ziel und nicht nur Verbindungsinformationen über die
Nachbarrouter überträgt.
43
Teil II.
Transportschicht
5. User Datagram Protocol (UDP)
Matthias Pischeli
5.1. Einleitung
nen kann, ob das vom Server gesendete Datenpaket
fehlerhaft ist oder nicht.
UDP verwendet zur Datenübermittlung vom QuellEinfach, aber sehr effektiv – so oder so ähnlich könnzum
Zielrechner Ports. Ports werden nummerisch anten 1977 die Überlegungen zum UDP, dem User Dagegeben
und können Werte zwischen 0 und 65535 antagram Protocol gelautet haben. In der Tat handelt es
nehmen.
Die Portnummern des Quell- und des Zielsich bei UDP nicht um das ideale und allumfassende
rechners
werden im Header des Datenpakets mitgeNetzwerkprotokoll, doch trotz seiner Einfachheit oder
sendet.
auch gerade deswegen findet es auch heute noch vielDie Spezifikation des Protokolls ist wie das Protofach Verwendung. Gerade in Bereichen, in denen es
koll
selbst recht dünn. Der RFC 768 [Pos80b] ist nur
um eine schnelle und effektive Datenübertragung an3
Seiten
stark.
kommt, bei der eine „gesicherte“ Übertragung der Daten zweitrangig ist, kommt UDP auch noch heute zum
Einsatz. Gerade im Bereich Mediastreaming (Audiound Video) oder bei VoIP ist UDP oftmals das geeig- 5.2.2. Header
nete Protokoll zu schnellen Datenübertragung. Hier
Ein UDP-Datenpaket (auch Datagramm genannt) begeht es meist darum, die Daten kontinuierlich vom
steht aus zwei Teilen, dem eigentlichen Datenteil,
Server zum Client zu schicken. Eine Fehlerbehandder die zu versendenden Daten enthält, sowie einem
lung wie bei TCP wäre hierbei nur hinderlich. Die EiHeader, dessen Aufbau in Bild 5.1 schematisch dargegenschaften, der Aufbau und die Funktionsweise von
stellt ist. Der Header besteht aus 4 Datenfeldern: EiUDP sollen im weiteren Verlauf dieses Kapitels benem 16 bit langen Quellport, dem gleichlangen Zielschrieben werden. Des Weiteren werden in einem geport, einer Längenangabe (ebenfalls 16 bit lang) und
sonderten Abschnitt Experimente vorgestellt, die im
der schon angesprochenen 16 bit-Prüfsumme.
zugehörigen Seminarvortrag besprochen wurden.
Der Quellport gibt an, von welcher Portnummer
aus der Hostrechner sein Datenpaket versendet hat.
Aufgrund der Tatsache, dass es sich bei UDP um ein
5.2. UDP im Detail
verbindungsloses Protokoll handelt, ist der Quellport
optional und kann auch den Wert 0 erhalten. Der Ziel5.2.1. Eigenschaften
port ist das Gegenstück zum Quellport. Er gibt an,
Wie in der Einleitung angedeutet, handelt es sich bei an welchen Prozess das Datenpaket gesendet werden
UDP um ein einfaches Protokoll zur Datenübertra- soll. Dieser Wert ist jedoch nicht optional. Das Längung in Netzwerken. Es ist ein verbindungsloses Pro- genfeld gibt die Länge des gesamten Datenpakets an.
tokoll, welches sich im TCP/IP-Referenzmodell in Dabei wird sowohl der Header als auch der Datender Transportschicht findet. Die Übertragung der Da- anteil gezählt. Das vierte Datenfeld, die Prüfsumme,
ten ist dabei ungesichert, das heißt, dass wenn ein ist wiederum ein optionales Datenfeld und kann den
Datenpaket bei der Datenübertragung verloren geht Wert 0 aufweisen. Wird eine Prüfsumme angegeben,
oder es fehlerhaft übertragen oder empfangen wur- wurde sie zuvor vom Host mittels des so genannten
de, gibt es keine Möglichkeit, dieses Paket fehlerfrei Pseudoheaders (Abbildung 5.2) und des Datenteils
noch mal zu erhalten oder es mittels möglichen „Re- gebildet.
paraturmaßnahmen“ wieder herzustellen. Einzig eine
Für die Datenübertragung eines UDP-Datenpakets
Fehlererkennung ist möglich. Das bedeutet, dass der wird das Internet-Protokoll (IP) verwendet. Dieses
Client mittels einer mitgesendeten Prüfsumme erken- setzt vor das UDP-Datenpaket seinen eigenen IP-
47
5. User Datagram Protocol (UDP)
Abbildung 5.1.: UDP-Header.
Abbildung 5.2.: UDP-Pseudoheader.
Header. Teile dieses IP-Headers werden nun für die
Erzeugung der Prüfsumme verwendet. Wie bereits gesagt, handelt es sich dabei um einen Pseudoheader,
der nicht übertragen wird. Die einzelnen Datenfelder
des Pseudoheaders sind: Quell- und Ziel-IP-Adresse,
ein so genanntes Nullfeld, das Protokollfeld und die
Länge. Die Quell- und Ziel-Adressen (jeweils 32 bit
lang) bezeichnen dabei die Host- und die Clientadresse der in Kommunikation befindlichen Rechner, das
Nullfeld (8 bit lang) bleibt leer, das 8 bit lange Protokollfeld gibt das Übertragungsprotokoll an (bei UDP
ist es die 17 [Int06d]) und hinter dem 16 bit langen Längenfeld verbirgt sich die Größe des UDPDatenpakets. Aus diesen Daten wird nun die Prüfsumme berechnet und in das entsprechende Feld eingetragen. Auf der Clientseite kann nun wiederum aus
diesen Daten die Prüfsumme berechnet werden und
mit der mitgesendeten Prüfsumme verglichen werden.
Bei einer korrekten Datenübertragung ist das Ergebnis der beiden Prüfsummewerte FFFF16 .
5.3. Experimente
5.3.1. Vorüberlegungen
Stevens beschreibt im Abschnitt „UDP“ seines Buches [Ste94] eine Vielzahl von Experimenten und Ver-
48
suchsaufbauten zum Testen und Erläutern der Funktionalitäten von UDP.
Insbesondere widmet er sich dem Thema des Severdesigns und eventuell auftauchenden Problemen,
die es zu beachten gilt. Stevens selbst schreibt, dass
es ihm nicht um das Programmieren des Servers geht,
sondern es sollen nur die Eigenheiten von UDP analysiert werden. Er verwendet in den Beispielen die
Programme wie sock, tcpdump oder netstat. Die
Quellen z. B. zu seinem sock-Programm sind im Anhang seines Buches abgedruckt. Weitere Experimente
und Versuche zu anderen Aspekten von UDP können
im entsprechenden Buchabschnitt nachgelesen und
leicht nachvollzogen werden. Ebenso sind die folgenden Versuche leicht verständlich und können bei entsprechender vorhandener Versuchsumgebung (wenn
auch in leicht abgewandelter Form) nachvollzogen
werden.
Zur Durchführung der Experimente und Beispiele
aus Stevens’ Buch wurden verschiedene Rechner des
Clusterverbundes RACL des Lehrstuhls für Rechnerarchitektur und -kommunikation verwendet. Hauptziel war dabei, die Netzwerkumgebung von Stevens
so gut wie möglich nachzubilden. Hauptrechner hierbei ist Kopfrechner der ipc654, der mehrere Interfaces
besitzt. Des Weiteren waren einige Client-Rechner
wie z. B. franzi oder inge involviert.
5.3.2. Experiment: Input-Queue
Das folgende Experiment soll auf eventuelle Probleme mit der Eingangswarteschlange (Input-Queue) eines UDP-Servers hinweisen. Zum Durchführen des
Experimentes wurde tcpdump auf ipc654 gestartet.
Dieser lauscht auf UDP-Pakete von beliebiger QuellIP-Adresse am Port 6666. Auf zwei weiteren Rechnern des Clusters (in diesem Falle franzi und inge)
wurde jeweils ein Client gestartet. Der Server (auf
ipc654 gestartet) wurde nach seinen Start in einen 30sekündigen Ruhezustand versetzt.
sock -s -u -v -E -R256 -r256 -P30 6666
Hierbei stehen „-s“ für Server, „-u“ für UDP, „-v“
zum Ausgeben der Client-IP-Adresse, „-E“ zum Ausgeben der Destination-IP-Adresse. Des Weiteren wird
mittels „-R256“ die Buffergröße, mit „-r256“ die
Read-Größe der Anwendung, mit „-P30“ die Zeit, die
der Server schläft, sowie die Portnummer angegeben.
In der Ruhephase des Servers wurden auf franzi
und inge die beiden entsprechenden Clients gestartet,
die nun abwechselnd jeweils 3 Pakete an den Server
auf ipc654 schicken.
5.3. Experimente
Server:
netstat -a -n -f inet
ipc654$ sock -s -u -v -E \
-R256 -r256 -P30 6666
liefert als Local Adress: *.7777. Der Stern hierbei
zeigt an, dass die lokale IP-Adresse eine Wildcard besitzt. Dies kann von Vorteil, aber auch von Nachteil
sein. Will man erreichen, dass der Port nur an einer
bestimmten IP-Adresse Daten annimmt, dann muss
dies beim Serverstart explizit angegeben werden.
Dazu wird der Server mit entsprechender IPAdresse gestartet:
Client 1:
franzi$ sock -u -v ipc654 6666
connected on 192.168.1.7.32869 to
192.168.1.1.6666
11111111111
222222222222
4444444444
Client 2:
inge$ sock -u -v ipc654 6666
connected on 192.168.1.10.32915 to
192.168.1.1.6666
3333333333
5555555555
6666666666
Ausgabe auf dem Server ipc654 :
SO_RCVBUF = 256
warning: IP_RECVDSTADDR not supported
by host
from 192.168.1.7: 11111111111
from 192.168.1.10: 3333333333333
from 192.168.1.7: 222222222222
tcpdump verzeichnet die entsprechenden Pakete
alle als gesendet. Nach der 30-sekündigen Ruhepause des Servers auf ipc654 werden dort die empfangenen Pakete angezeigt. Allerdings fällt auf, dass hierbei
nicht alle Paket vom Server empfangen wurden. Dies
ist so zu erklären, dass der Server zwar alle Pakete
empfangen hat, diese aber aufgrund der Ruhepause in
eine Warteschlange „geparkt“ hat. Das nun nicht alle Pakete als empfangen angegeben werden, liegt daran, dass die Warteschlange nur eine begrenzte Kapazität besitzt. Ist diese voll, werden weitere Pakete nicht
mehr angenommen und vom Server abgewiesen.
5.3.3. Experiment: Restricting Local
IP Address
Bei einem UDP-Server sind die IP-Adressen für die
zu öffnenden Ports mittels einer Wildcard gesetzt.
Dies bedeutet, dass der Server an jedem lokalen Interface ein an den Port adressiertes Paket annimmt. Im
folgenden Experiment starten wir einen UDP-Server
mit Portnummer 7777.
sock -u -s 7777
Der
Eintrag
netstat:
Local
Address
des
sock -u -s 192.168.1.1 7777
Netstat liefert nun für Local Adress: 192.168.1.1
7777. Dies bedeutet, dass jedes Paket, das an den Port
gesendet wird, nur dann angenommen wird, wenn
dies an die richtige IP-Adresse gesendet wird. Andernfalls wird das Paket mittels einer ICMP-PortUnreachable-Nachricht abgewiesen.
Sollen nun mehrere Server mit den gleichen
Portnummern, aber unterschiedlichen lokalen IPAdressen gestartet werden, muss dem sock-Programm
die Erlaubnis erteilt werden, dies zu tun. Dazu gibt es
den Schalter „-A“, der es erlaubt, den Port mehrfach
zu benutzen. Somit kann für verscheiden Dienste dieselbe Portnummer verwendet werden.
Beispiel: (aus Stevens)
sun$ sock -u -s 140.252.1.29 8888
# for SLIP link
sun$ sock -u -s -A 140.252.13.33 8888
# for Ethernet
sun$ sock -u -s -A 127.0.0.1 8888
# for loopback interface
sun$ sock -u -s -A 140.252.13.63 8888
# for Ethernet broadcasts
sun$ sock -u -s -A 8888
# für alle weiteren Dienste (Wildcard)
Entsprechende Pakete werden von den speziellen
an den angegebenen IP-Adressen empfangen. Wird,
wie beim letzten Server, keine IP-Adresse angegeben,
dann empfängt dieser Pakete an weitere, hier nicht explizit spezifizierte Interfaces.
5.3.4. Experiment: Restricting
Foreign IP Address
Ähnlich zum vorhergehenden Experiment kann auch
die sogenannte Foreign IP Address, also die IPAdresse des Senders, eingeschränkt werden. Wird
der Server ohne jedwede Restriktion der entfernten IP-Adresse gestartet, dann zeigt der Eintrag von
netstat Foreign IP Address: *.*. Dies bedeutet,
Programmes dass eingehende UDP-Pakete von jeder Adresse/PortKombination akzeptiert werden. Auch hier kann dies
49
5. User Datagram Protocol (UDP)
in der Praxis von Nachteil sein. Einem Fremdrechner
kann die Kommunikation mit dem Server untersagt
werden oder aber es sollen nur ganz bestimmte, bekannte Rechner auf den Port zugreifen können. Auch
hierfür bietet das sock-Programm eine Möglichkeit
an. Während des Serverstarts kann mittels des Schalters „-f“ und der Angabe einer IP-Adresse und Port
der Sender eingeschränkt werden:
Beispiel:
sock -u -s -f 192.168.1.10.4444 5555
Wird der Foreign-IP-Address-Wert auf diese Weise gesetzt, dann akzeptiert der Server nur noch Pakete
von der spezifizierten IP-Adresse und dem entsprechenden Port. Als Seiteneffekt hierbei fällt beim Aufruf von netstat auf, dass ebenso die Local IP Address
automatisch gesetzt wird.
5.4. Zusammenfassung
UDP ist ein simples, aber häufig verwendetes Protokoll zur Datenübertragung. Es wird trotz seines Alters weiterhin für viele Dienste eingesetzt. Das Protokoll selbst bietet keine Fehlerbehandlung, kann jedoch aufgrund einer meist mitgelieferten Prüfsumme
Fehlererkennung ermöglichen.
Innerhalb der Serverdesigns mittels UDP gibt es einige Probleme zu beachten, z. B. bezüglich der InputQueue-Länge. Des Weiteren bietet UDP einfache,
aber effektive Mittel zu Restriktion von eingehenden
Datenpaketen mittels der Angabe der Foreign bzw.
Local IP Address.
50
6. Transmission Control Protocol (TCP) –
Interactive Data Flow
Christiane Topp
6.1. Einleitung
Jon Postel führte das Transmission Control Protocol
(TCP) im RFC 793 [Pos81c], mit folgenden Worten
ein:
The Transmission Control Protocol (TCP)
is intended for use as a highly reliable host-to-host protocol between hosts in
packet-switched computer communication
networks, and in interconnected systems of
such networks.
Es handelt sich hierbei demnach um eine Vereinbahrung darüber, auf welche Art und Weise die Kommunikation zwischen zwei Endpunkten erfolgen soll.
Dabei findet eine Kontrolle des Kommunikationsprozesses statt, d. h. die Zuverlässigkeit der Verbindung
wird überwacht. TCP ist neben UDP (Kapitel 5) in der
vierten Schicht – der Transportschicht – des ISO/OSIReferenzmodells angesiedelt. Es setzt meistens auf
dem Internet Protocol (IP) auf.
Der von höheren Schichten „heruntergereichte“
Datenstrom wird von TCP in Stücke zerlegt, bestehend aus mehreren Daten-Oktetten. Eine dieser Übertragungseinheiten, die anschließend an IP weitergeben wird, heißt Segment. Im Gegensatz zu UDP, wo
die Segmentgröße immer gleich ist, wird diese beim
Transmission Control Protocol von der TCP-Software
selbst festgelegt.
Neben dem schon erwähnten RFC 793 können u. a.
RFC 1323, RFC 1122, RFC 2581 und RFC 896 genannt werden, in denen weitere Spezifikationen zu
TCP zu finden sind [JBB92, Bra89, APS99, Nag84].
In diesem Kapitel werden die wichtigsten Eigenschaften von TCP näher erläutert. Anschließend wird der Header des TCP-Protokolls vorgestellt. Die Begriffe, die in diesem Abschnitt eingeführt werden, sind für das spätere Verständnis des
Kommunikationsmanagements mittels TCP von es-
Abbildung 6.1.: Verbindungsorientierte Kommunikation.
sentieller Bedeutung. Nachfolgend geht es um den
Datentransfer mittels TCP, wobei in diesem Kapitel
nur auf den Austausch interaktiver Daten eingegangen wird. Den Transfer großer Datenmengen, so genannter Bulk-Daten, behandelt Kapitel 8. Mehrere angeführte Experimente sollen zu einem besseren Verständnis der theoretischen Aspekte beitragen.
6.2. Eigenschaften von TCP
Das Transmission Control Protocol ist sowohl verbindungsorientiert als auch zuverlässig. Dies sind die
beiden am häufigsten hervorgehobenen Eigenschaften von TCP und unterscheiden das Protokoll eindeutig von dem ebenfalls in der Transportschicht angesiedelten verbindungslosen User Datagram Protocol
(UDP).
Verbindungsorientiert Die verbindungsorientierte Kommunikation ist in Abbildung 6.1 [Wik06h]
dargestellt. Die beiden kommunizierenden Anwendungen (z. B. Client/Server) müssen erst eine
51
6. Transmission Control Protocol (TCP) – Interactive Data Flow
Verbindung etablieren, bevor Daten gesendet werden
können. Stevens vergleicht diesen Vorgang in seinem
Buch „TCP/IP Illustrated“ mit dem Wählen einer
Telefonnummer, bevor das Gespräch mit dem Partner
am anderen Ende der Leitung beginnen kann [Ste94]
(vgl. dazu Kapitel 7). Eine Verbindung bei TCP wird
mittels eines Socket-Paars eindeutig identifiziert. Ein
Socket setzt sich zusammen aus der eindeutig vergebenen IP-Adresse eines Kommunikationspartners
und einer Portnummer. TCP stellt auf jedem Host
eine Reihe von verschiedenen Ports zur Verfügung.
Die Ports 0 bis 1023 werden auch als Well Known
Ports bezeichnet und wurden von der Internet Assigned Numbers Authority (IANA) festgelegt. Von
diesen Ports aus kommunizieren Systemprozesse
oder Programme, die von privilegierten Nutzern
ausgeführt werden [Int06c]. Die Ports zwischen 1024
und 65535, d. h. die Registered Ports bzw. Private
Ports, werden von Programmen, die von normalen
Nutzern ausgeführt werden, genutzt.
Das in der Abbildung 6.1 dargestellte Beispiel zeigt
eine TCP-Verbindung zwischen einem Server und einem Client. Beide haben eine eindeutige IP-Adresse
und kommunizieren jeweils über einen definierten
Port. Der Server nutzt in diesem Fall den Port 80, der
für das Protokoll HTTP reserviert ist. Es handelt sich
hierbei folglich um einen Webserver, der dem Client
eine Webseite zur Verfügung stellt. Der Client nutzt
einen Port größer 1023. Für eine Server-Anwendung
ist es sinnvoll, dass diese mehrere Clients bedienen
kann. Auch im aufgeführten Beispiel bestünde theoretisch die Möglichkeit, weitere Verbindungen zu verschiedenen Clients aufzubauen. Aufgrund der sich
unterscheidenden IP-Adressen bzw. Portnummern der
zusätzlichen Clients könnten die einzelnen Verbindungen klar voneinander unterschieden werden. Aufgrund der Möglichkeit der eindeutigen Identifizierung
der beiden Endpunkte spielen Broadcast und Multicast bei TCP keine Rolle.
wird mitgeteilt, sondern der korrekte Empfang von
Daten wird bestätigt. Jedoch kann mit Hilfe dieses
positiven Acknowledgements auch der Verlust eines
Paketes oder der Empfang eines fehlerhaften Paketes signalisiert werden. Zu diesem Zweck läuft beim
Sender für jedes versandte Paket ein Timer mit. Die
TCP-Software des Senders wartet sozusagen auf eine Empfangsbestätigung. Ist ein Segment im vorgegeben Zeitraum nicht bestätigt worden, wird es erneut
gesendet (vgl. hierzu Abschnitt 9.2.6). Hierfür legt
TCP die Retransmission Queue, eine Warteschlange
für eventuell erneut zu sendende Segmente, an, in der
zunächst jedes verschickte Segment als Kopie gespeichert wird. Erhält der Sender die positive Bestätigung,
wird diese Kopie aus der Warteschlange gelöscht. Ansonsten wird sie als Vorlage für das wiederholte Senden genutzt.
Um Veränderungen der Daten während der Übertragung zu registrieren und die fehlerhaften Segmente ggf. verwerfen zu können, erzeugt TCP zum
anderen eine Prüfsumme. Diese wird über den IPPseudoheader, den TCP-Header und die Daten des
Segments gebildet. Der Pseudoheader enthält weniger Informationen als der eigentliche IP-Header und
ist somit für die Berechnung der Prüfsumme besser
geeignet. Der genaue Aufbau wird in Abschnitt 6.3.2
vorgestellt. Der Empfänger des Segments errechnet
die Prüfsumme ebenfalls. Weicht das Ergebnis von
Soll ab, wird das Paket verworfen. Für dieses Segment wird kein Acknowledgement an den Sender verschickt. Somit „spekuliert“ der Empfänger auf das Timeout des mitlaufenden Timers beim Sender und auf
ein daraus resultierendes erneutes Senden des Segments.
Da IP-Datagramme unsortiert beim Empfänger
eintreffen können, liegen die TCP-Segmente, im
ISO/OSI-Referenzmodell eine Schicht weiter oben
angesiedelt, folglich ebenfalls in beliebiger Reihenfolge vor. TCP bringt die Daten wieder in die korrekte
Reihenfolge und reicht sie an die Anwendungsschicht
weiter. Möglich wird dieser Sortiervorgang durch das
Zuverlässig Im RFC 793 ist unter der Überschrift Vergeben von Nummern für jedes Segment. Diese
„Reliability“, was übersetzt „Zuverlässigkeit“ bedeu- Nummern werden als Sequenznummern bezeichnet
tet, folgender Satz zu finden: The TCP must recover und im Abschnitt 6.3 näher erläutert.
Doppelt empfangene Segmente werden von TCP
from data that is damaged, lost, duplicated, or delivered out of order by the internet communication sys- einfach verworfen. Eine gesonderte Benachrichtigung
tem.
erfolgt nicht.
Ein weiterer Mechanismus, der für die ZuverlässigUm diesen Forderungen gerecht zu werden, verfügt
TCP über mehrere Mechanismen. Zum einen wird je- keit von TCP verantwortlich ist, ist die so genanndes erhaltene Segment vom Empfänger bestätigt. Es te Flusskontrolle (Flow Control). Dies ist ein Mitwird mit einem sogenannten Acknowledgement bestä- tel, dass dem Empfänger ermöglicht, mit der Mentigt. Dabei handelt es sich um ein positives Acknow- ge an Daten, die er vom Sender erhält, umzugehen.
ledgement, d. h. nicht der Verlust von Datenpaketen Dabei übermittelt der empfangende TCP-Teilnehmer
52
6.3. TCP-Header
Die nächsten 32 bit beinhalten die Sequenznummer,
die beispielsweise das Sortieren der TCP-Segmente
beim Empfänger ermöglicht. TCP nummeriert jedes
Byte mit einer Sequenznummer. Diese reicht von 0 bis
232 − 1 und wird kontinuierlich hochgezählt. Ist der
Maximalwert erreicht, springt die Nummer zurück
auf 0. Die im Header angegebene Sequenznummer
identifiziert das erste Datenbyte des TCP-Segments
und wird auch als Segment-Sequenznummer bezeichnet. Ist jedoch das SYN-Flag gesetzt, gehört das Segment zum Verfahren des Verbindungsaufbaus. In diesem Fall enthält das Sequenznummernfeld die Initial Sequence Number (ISN), welche keinen konkreten Daten zugeordnet ist, sondern der Synchronisation
der Sequenznummern beim Verbindungsaufbau dient.
Das ersten Datenbyte hat demzufolge die Sequenznummer ISN + 1. Der Verbindungsaufbau verbraucht
also eine Sequenznummer. Gleiches gilt für den VerAbbildung 6.2.: TCP-Header.
bindungsabbau, bei dem das FIN-Flag gesetzt ist. Da
TCP eine Vollduplex-Verbindung unterstützt, bei der
gleichzeitige Kommunikation in beide Richtungen erdem Sender die Menge an Daten, die er maximal entfolgen kann, muss jeder der beiden Kommunikationsgegennehmen kann (Window). Dieser Mechanismus
partner eine Sequenznummer für seine Senderichtung
verhindert, dass ein schneller Host den gesamten Pufgenerieren.
fer des langsamen Hosts belegt.
Das auf das Sequenznummernfeld folgende Datenwort von 32 bit enthält die Acknowledgement-Number,
d. h. die Nummer zur Bestätigung des Empfangs
6.3. TCP-Header
von Datenpaketen. Dieses Feld ist nur dann gülEin Header (engl.: head = Kopf) bildet die Kopfzei- tig, wenn das ACK-Flag gesetzt ist, was bei eile, die Einleitung oder den Vorspann am Anfang ei- ner etablierten Verbindung immer zutrifft. Aufgrund
ner Datei oder eines Datenblockes. Er enthält wich- der Durchnummerierung jedes ausgetauschten Bytes
tige Informationen für den Umgang mit den eigent- lässt sich die Acknowledgement-Number leicht aus
lichen Daten. Des Weiteren wird er zur Adressie- der Sequenznummer berechnen. Sie ergibt sich aus
rung von Daten benötigt, die über ein Netzwerk trans- der Sequenznummer des letzten empfangenen Bytes
portiert werden sollen. So findet man diverse Pro- plus eins. Das heißt, die Bestätigungsnummer ist
tokolle, der verschiedenen Schichten des ISO/OSI- die Sequenznummer, die der Sender der BestätiReferenzmodells, mit einem Header. Zu nennen wä- gung als nächstes von seinem Kommunikationspartren hier beispielhaft die Protokolle IP, UDP, HTTP ner erwartet. Hervorzuheben ist die Tatsache, dass
die Acknowledgment-Number (ACK-Number) den
und auch das Transmission Control Protocol.
erfolgreichen Empfang aller Bytes bis zum Byte vor
der ACK-Nummer bestätigt. Daraus folgt, dass es
6.3.1. Aufbau
nicht möglich ist, einzelne, ausgewählte Stücke des
Jedes TCP-Segment besteht aus einem Header Datenstroms zu bestätigen. Ein kleines Beispiel aus
und ggf. den zu übermittelnden Daten. In Abbil- Stevens’ Buch soll diesen Sachverhalt verdeutlichen:
dung 6.2 [Wik06h] ist der TCP-Header dargestellt. Der Empfänger hat zunächst ein Segment mit den
Die normale Größe beträgt 20 B. Bei Angabe zusätz- Bytes 1 bis 1024 korrekt empfangen. Er bestätigt den
licher Optionen kann die Größe des Headers auf ma- Empfang mit der ACK-Number 1025. Das nächste
von ihm empfangene Segment mit der Sequenznumximal 60 B ansteigen.
Die ersten 32 bit enthalten sowohl die 16 bit Quell- mer 2049 enthält die Bytes 2049 bis 3072. OffenPortnummer als auch die 16 bit Ziel-Portnummer. Zu- sichtlich fehlt ein Segment des Datenstroms, welches
sammen mit der Quell- und Ziel-IP-Adresse bilden sie theoretisch die Bytes 1025 bis 2048 enthalten müssdas Socket-Paar, welches jede TCP-Verbindung in ei- te. Dem Empfänger ist es nun nicht möglich, das
nem Netzwerk eindeutig identifiziert.
zweite von ihm empfangene Paket zu bestätigen. Ein
53
6. Transmission Control Protocol (TCP) – Interactive Data Flow
Acknowledgement mit der ACK-Number 3073 würde gleichzeitig den Empfang des fehlenden Pakets
bestätigen. Demzufolge kann der Empfänger höchstens ein weiteres Acknowledgement mit einer ACKNumber 1025 senden.
Die nächsten 4 bit sind für die Angabe der Headerlänge notwendig. Aufgrund der optionalen Felder am
Ende des Headers ist dessen Länge nicht konstant.
Dieses Feld ermöglicht demzufolge das Ausfindigmachen des ersten Datenbits innerhalb des Segments.
Auf die 6 reservierten Bits folgen nun die verschiedenen Flags. Ist das URG-Flag gesetzt, hat der
Urgent-Pointer Gültigkeit. Dasselbe gilt für das ACKFlag. Nur wenn dieses Flag den Wert 1 annimmt,
darf die Acknowledgement-Number als Bestätigung
für alle davor versendeten Bytes interpretiert werden. Das PSH-Flag steht für Push. Die Push-Funktion
wurde definiert, um dem Nutzer die Möglichkeit einzuräumen, sicherzustellen, dass alle an TCP übermittelten Daten auch an den Empfänger übertragen werden. Sonst könnte der Fall vorliegen, dass die entsprechenden Daten noch im Sende- oder Empfangspuffer
zurückgehalten würden. Das Zurückhalten von Daten
seitens der Sender-TCP-Software hat den Zweck, Daten solange zu sammeln, bis die maximale Segmentgröße erreicht wird. Die Daten können dann mit einem großen Segment verschickt werden anstelle mittels mehrerer kleiner. Damit kann Overhead reduziert werden. Beim Empfänger bewirkt das gesetzte PSH-Flag, dass dieser nicht auf weitere Daten
wartet, sondern die empfangenen Bytes unverzüglich
an die Empfänger-Anwendung hochreicht. Das RSTFlag bewirkt ein Reset der Verbindung. Das SYN-Flag
ist beim Verbindungsaufbau einer TCP-Verbindung,
dem sogenannten Three Way Handshake, gesetzt. Hat
der Sender das Senden von Daten abgeschlossen, setzt
er das FIN-Flag.
Das 16 bit-Feld Window übermittelt die Anzahl an
Bytes, die der Empfänger gewillt ist, zu akzeptieren.
Das Festlegen der Fenstergröße dient der Realisierung der Flusskontrolle. Aufgrund der Beschränkung
dieses Headerfeldes auf 16 bit können mittels TCP
Segmente mit einer Maximalgröße von 216 − 1, also
65535 B, übertragen werden (vgl. Abschnitt 8.1.3).
Die 16 bit Checksum dient der Sicherstellung der
Korrektheit der übertragenen Daten. Sie wird aus dem
Header, dem Pseudoheader und aus den Daten des
TCP-Segments berechnet. Der Empfänger errechnet
unter Einbeziehung des Wertes des Prüfsummenfeldes ebenfalls eine Summe. Diese hat bei fehlerfreien
Segmenten den Wert null. Weicht das durch den Empfänger ermittelte Ergebnis von diesem Wert ab, wird
das Paket als fehlerhaft deklariert und verworfen.
54
Abbildung 6.3.: TCP-Pseudoheader.
Der Urgent-Pointer wird heute nicht mehr verwendet. Ursprünglich ermöglichte er, Notfalldaten zu
übermitteln, indem deren Dringlichkeit mit dem Setzen des URG-Flags explizit vermerkt wurde. Der
Urgent-Pointer an sich ist eine positive Zahl, die addiert mit der Segment-Sequenznummer die Nummer
des letzten Bytes der dringlichen Daten liefert. Der
Urgent-Pointer ist somit ein positiver Offset.
Im Option-Feld können diverse zusätzliche Optionen angegeben werden. Sie vergrößern den Header
und werden bei der Prüfsummenberechnung mit einbezogen. Die am häufigsten angegeben Option ist die
Maximum Segment Size (MSS), die die maximale Segmentgröße, die der Sender empfangen möchte, spezifiziert. Jeder der beiden Kommunikationsendpunkte spezifiziert diese Option normalerweise im ersten
Segment, welches ausgetauscht wird. Jede in diesem
Feld angegeben Option muss einem 32 bit-Wort entsprechen. Benötigt die Option weniger Platz, wird der
Rest bis zum vollen Wort mit Nullen aufgefüllt.
6.3.2. TCP-Pseudoheader
Der Pseudoheader (siehe Abbildung 6.3 [Wik06h])
wird für die Prüfsummenberechnung dem eigentlichen TCP-Header vorangestellt gedacht. Er beinhaltet die Quell- und Zieladresse sowie die Angabe des
Protokolls über eine Nummer und die Länge des TCPSegments ohne die 12 B des Pseudoheaders.
6.4. Datentransfer mittels TCP
In diesem Abschnitt geht es um den Datentransfer
mittels TCP. Stevens führt in seinem Buch eine Analyse des mittels TCP transportierten Datenstroms an.
Die Abbildungen 6.4(a) und 6.4(b) illustrieren die Ergebnisse dieser Untersuchung. Dabei wird stets zwischen Bulk-Daten und interaktiven Daten unterschieden. Unter dem Transfer von Bulk-Daten versteht
6.4. Datentransfer mittels TCP
TCP-Traffik auf Basis der übertragenen
Segmente
60%
50%
40%
30%
20%
10%
0%
bulk
interactive
(a) Segmente.
TCP-Traffik auf Basis der übertragenen
Bytes
10%
zahl der übertragenen Bytes an interaktiven Daten
macht jedoch nur 10% der Gesamtdatenmenge aus. Es
drängt sich die Schlussfolgerung auf, dass die interaktiven Datensegmente um ein Vielfaches kleiner sein
müssen als die Bulk-Datensegmente. Dies wird auch
in der von Stevens herangezogenen Studie bestätigt,
laut der etwa 90% aller Telnet- und Rlogin-Pakete weniger als 10 B Nutzdaten mitführen. Die Leitung wird
mit einer großen Menge an Overhead belastet. Im Gegensatz dazu tendieren die Bulk-Datensegmente dazu,
die maximale Segmentgröße voll auszunutzen. Das
führt zu einem schnelleren Datentransfer, wobei der
Anteil der Nutzdaten dem der Headerdaten überwiegt.
Bei TCP kommen für beide Arten von Daten unterschiedliche Algorithmen zum Einsatz. Dieses Kapitel
setzt sich mit nur einer der beiden Übertragungsmöglichkeiten von Daten auseinander – dem interaktiven
Datentransfer. Dabei wird sowohl der normale Datenfluss betrachtet, als auch die Funktionsweise und der
Nutzen von Delayed Acknowledgement und NagleAlgorithmus erläutert. Die entsprechenden Sachverhalte werden immer anhand konkreter Experimente
dargelegt.
bulk
interactive
90%
(b) Bytes.
Abbildung 6.4.: TCP-Traffic-Analyse
man die ungestörte Übertragung großer Datenmengen. Bulk-Daten sind z. B. große Dateien, die via FTP
heruntergeladen werden. Auch beim E-Mail-Verkehr
fallen Bulk-Daten an. Interaktive Daten sind immer
dort zu verzeichnen, wo der Benutzer interaktiv Befehle über eine Konsole eingibt, diese dann zu einem Server transportiert werden, dort eine Auswertung erfahren und das Resultat zurück an das Terminal
gesendet wird. Die Anwendungen telnet oder ssh
sind hier beispielhafte Vertreter.
Abbildung 6.4(a) verdeutlicht, dass die Hälfte aller TCP-Segmente Bulk-Daten enthalten, die andere
Hälfte interaktive Daten. Ein völlige konträres Bild
zeigt allerdings die Abbildung 6.4(b). Daraus wird ersichtlich, dass bei Betrachtung desselben Fakts auf
Basis der übertragenen Bytes nicht mehr eine 50/50Situation vorliegt, sondern dass sich der Datenstrom
zu 90% aus Bulk-Daten zusammensetzt. Die An-
6.4.1. Experiment: Interaktiver
Datenaustausch
Zunächst betrachten wir den Datenfluss zwischen
zwei Rechnern, die über Telnet miteinander kommunizieren. Die Telnet-Verbindung geht vom Rechner
ipc654 aus. Dort wird das interaktive Kommando ls
eingegeben, um sich den Inhalt des aktuellen Verzeichnisses anzeigen zu lassen. Der Datenstrom wird
auf dem Rechner dana am Port 23 mittels tcpdump
mitgeschnitten und am Bildschirm ausgegeben. Der
Versuchsaufbau ist in Abbildung 6.5 dargestellt.
Das Erstaunliche am Austausch interaktiver Daten ist die Tatsache, dass normalerweise jeder Tastendruck ein separates Datenpaket erzeugt. Somit entstehen TCP-Segmente, die lediglich 1 Byte Nutzda-
Abbildung 6.5.: Aufbau Experiment 1.
55
6. Transmission Control Protocol (TCP) – Interactive Data Flow
Zeichen vier Segmente erzeugt. Anschließend liefert
die Serveranwendung die angeforderten Informationen an den Client.
Neben der eben beschriebenen Variante des Datentransportes zeigt Abbildung 6.7 noch eine weitere Möglichkeit auf. In diesem Fall werden Segment 2
und Segment 3 kombiniert, d. h. die Bestätigung des
Tastendrucks wird zusammen mit dem Echo an den
Client gesendet. Das hat den Vorteil, dass ein Segment
Abbildung 6.6.: Variante 1 der Übertragung ei- eingespart wird. Außerdem werden nicht unnötig Panes Zeichens an ein Remote-System.
kete ohne Nutzdaten versendet. Diese Technik trägt
den Namen Delayed Acknowledgement und wird im
nachfolgenden Abschnitt besprochen.
6.4.2. Experiment: Delayed
Acknowledgement
Der Begriff Delayed Acknowledgement kann ins
Deutsche mit verzögerte Bestätigung übersetzt werAbbildung 6.7.: Variante 2 der Übertragung ei- den. Diese Bezeichnung trägt der Tatsache Rechnung,
nes Zeichens an ein Remote-System.
dass TCP das Acknowledgement normalerweise nicht
in dem Moment sendet, in dem es Daten erhält. Stattdessen verzögert TCP die Bestätigung in der Hofften übertragen. Empfängt der Server, in diesem Fall nung, dass noch Daten in die gleiche Richtung wie das
der Rechner dana, das eingegebene Zeichen, sendet er Acknowledgement gesendet werden müssen. Somit
prompt ein Echo desselben zum Client zurück. Die- kann das ACK zusammen mit den Daten im selben
ses wird dann am Bildschirm des Clients angezeigt. Segment übertragen werden. Abbildung 6.8 veranAbbildung 6.6 zeigt eine Möglichkeit der Kommuni- schaulicht diesen Mechanismus. Hier sind auf Clientkation der beiden Endpunkte bei der Übertragung ei- Seite zwei Delayed Acknowledgements dargestellt.
nes Zeichens. Es werden insgesamt vier Segmente er- Nach dem Erhalt des Echos entsteht eine längere Warzeugt. Aufgrund der Betätigung der Taste „l“ auf der tepause, bevor das bestätigende Paket versendet wird.
Seite des Clients wird ein TCP-Segment kreiert. Die- Die meisten Implementierungen nutzen eine 200 msses transportiert das eine Byte Nutzdaten zur Server- Verzögerung, d. h. TCP verzögert das Acknowledgeseite. Dort wird es von der TCP-Software zur Server- ment bis zu 200 ms, um abzuwarten, ob noch weitere
Anwendung hochgereicht. Außerdem wird der Emp- Daten mit dem Acknowledgement mitgesendet werfang des Segments mit einem Acknowledgement be- den können. Im hier dargestellten Fall war der Nutstätigt. Das Bestätigungspaket besteht also zu 100% zer jedoch nicht schnell genug bei der Eingabe: Die
aus Header-Informationen. Die Server-Anwendung
erzeugt ihrerseits das schon erwähnte Echo des empfangenen Zeichens. Dieses wird in ein TCP-Segment
verpackt und zum Client transportiert. Wiederum passiert hier ein Segment mit nur einem Byte Nutzdaten die Leitung. Anschließend wird der Erhalt des
Echos seitens des Clients mittels eines Acknowledgement bestätigt. Das zweite getippte Zeichen des
Befehls „ls“ würde auf dieselbe Art und Weise mit
vier Segmenten übermittelt. Der Abschluss des Befehls geschieht mit der Betätigung der Return-Taste.
Dabei werden zwei Zeichen kreiert, ein Carriage Return (CR), was den Cursor zurück auf die linke Seite manövriert, und ein Linefeed (LF), welches einen
Zeilenvorschub bewirkt. Beide Zeichen werden ge- Abbildung 6.8.: Delayed Acknowledgement auf
Client-Seite.
trennt voneinander übertragen. Auch hier werden pro
56
6.4. Datentransfer mittels TCP
Abbildung 6.9.: Aufbau Experiment 2.
Abbildung 6.10.: Datenstrom Experiment 2.
200 ms verstrichen, ohne dass erneut Daten zum Versenden bereit standen. Folglich wurde das Segment
mit dem Acknowledgement versendet. Das nächste
Zeichen der Eingabe wurde mittels eines weiteren
TCP-Segments zum Server übertragen. Der Mechanismus hat also in diesem Fall seine Wirkung verfehlt.
Auf Serverseite jedoch bewirkt das Verzögern der Bestätigung, dass ein Segment eingespart werden kann.
Die Telnet-Anwendung liefert das Echo so schnell an
die TCP-Software zurück, dass der Timer unterschritten bleibt.
6.4.3. Experimente:
Nagle-Algorithmus
In den letzten beiden Abschnitten konnten wir sehen, dass während einer Remote-Login-Verbindung
normalerweise 1 Byte Nutzdaten vom Client zum
Server übertragen wird. Dabei werden 41 B große
Pakete generiert, die einen 20 B großen IP-Header,
einen 20 B großen TCP-Header und 1 B Daten enthalten. Diese kleinen Pakete führen in LANs meist
nicht zu Problemen, können aber in Weitverkehrsnetzen zu Datenstau führen. Um diesen Umstand zu
umgehen, wurde der Nagle-Algorithmus entwickelt.
John Nagle beschreibt seinen Lösungsvorschlag im
RFC 896 [Nag84]. Der Algorithmus sieht vor, dass eine TCP-Verbindung, die noch ausstehende Daten hat,
welche bisher nicht mit einem ACK bestätigt wurden,
solange keine neuen Segmente senden darf, bis die
Bestätigung der noch ausstehenden Daten eingetroffen ist. Während der Zeit des Wartens auf die noch
fehlenden Acknowledgements sammelt TCP die anfallenden kleinen Datenmengen und versendet sie zusammen in einem gemeinsamen Segment, sobald das
ACK eintrifft. Abbildung 6.9 veranschaulicht den zu
dieser Problematik gehörenden Versuchsaufbau.
In diesem Beispiel wird von dem Rechner ipc654
über das Fakultätsrechenzentrum (FRZ) der Fakultät für Mathematik und Informatik eine Verbindung
zu einem Rechner irgendwo im Internet aufgebaut.
Der Datentransfer wird wiederum mit Hilfe des Tools
tcpdump mitgeschnitten und am Bildschirm ausgegeben. Um das Wirksamwerden des Nagle-Algorithmus
verfolgen zu können, ist es nötig, dass der Nutzer
bei diesem Experiment sehr schnell tippt. Das schnelle Tippen bewirkt, dass sich Daten beim Sender ansammeln, solange er auf die eintreffenden Acknowledgements der bereits versendeten Segmente wartet.
Dieses Aufstauen von Daten ist nur in einem Versuchsaufbau möglich, in dem die Round Trip Time,
d. h. die Umlaufzeit des Paketes, relativ hoch ist. Die
Umlaufzeit des Paketes bezeichnet die Zeitspanne, die
vom Senden des Paketes bis zum Erhalt der Bestätigung des Empfangs benötigt wird. Da der Datentransfer hier durch das Internet geleitet wird, sollten die
erforderlichen Bedingungen gegeben sein.
Abbildung 6.10 veranschaulicht den von tcpdump
mitgeschnittenen Datenstrom. In der Abbildung ist jeder Sendevorgang mit einer Zahl versehen. Im Vorgang 1 verschickt der Client ein Datenpaket, welches 1 Byte Nutzdaten transportiert. Die Anzahl der
versendeten Bytes ist in Klammern angegeben. Dieses Segment hat die Sequenznummer 5 und die
Acknowledgement-Nummer 47. Das Push-Flag ist
gesetzt. Unter Punkt 2 sieht man die Bestätigung dieses Paketes. Da es sich bei der AcknowledgementNummer immer um die um 1 erhöhte Sequenznummer des letzten Datenpaketes handelt, hat die ACKNummer folglich den Wert 6. Im weiteren Verlauf der
Übertragung ist zu erkennen, dass zu mehreren Zeitpunkten mehr als 1 Byte versendet wird. Im Vorgang 5
werden 2 B und im Vorgang 9 sogar 3 B zum Server
übertragen. Dieser antwortet ebenfalls mit Segmenten, die mehr als 1 B Nutzdaten transportieren, und
57
6. Transmission Control Protocol (TCP) – Interactive Data Flow
Abbildung 6.11.: Aufbau Experiment 3.
Abbildung 6.12.: Betätigen einer Funktionstaste.
bestätigt gleichzeitig den Empfang der Daten. Daraus folgt, dass zum Versenden einer gewissen Datenmenge im Vergleich zu einer Verbindung ohne aktivierten Nagle-Algorithmus signifikant weniger Segmente transferiert werden müssen. Zusätzlich verringert sich der Anteil an Headerdaten im Vergleich zum
Anteil der Nutzdaten. Als weiterer Vorteil des NagleAlgorithmus ist seine selbstregulierende Eigenschaft
zu sehen. Je schneller die Acknowledgements ankommen, desto schneller werden die restlichen Daten gesendet. Gleichzeitig werden in einem langsamen WAN, wo es erwünscht ist, die Anzahl kleiner
Übertragungseinheiten zu reduzieren, auch weniger
Segmente versandt.
Eine noch hervorzuhebende Auffälligkeit dieses
Datenstroms ist das getrennte Versenden der Segmente in Vorgang 10 und 11. Bei Übertragung 10 schickt
der Server nur ein Acknowledgement an den Client,
ohne jedoch, wie in den vorangegangenen Übertragungen, das Echo mit Hilfe des gleichen Segments
zu transportieren. In diesem Fall wird das 3 B große
Echo mittels eines separaten TCP-Paketes versandt.
Dieses Abweichen vom normalen Schema ist ein Zeichen dafür, dass auf Serverseite der Mechanismus
Delayed Acknowledgement aktiviert ist. Die RemoteAnwendung des Servers war nicht schnell genug mit
der Verarbeitung der gesendeten Bytes und konnte das
Echo folglich erst nach Ablauf des Timers für das Delayed Acknowledgement erzeugen. Auf Clientseite ist
diesmal kein Verzögern der Bestätigung zu verzeichnen.
58
Trotz der Vorteile, die der Nagle-Algorithmus bietet, gibt es Momente, in denen der Algorithmus abgeschaltet werden sollte. Ein Beispiel für eine solche
Situation ist in Abbildung 6.11 dargestellt.
Der Nutzer hat eine Remote-Verbindung zu einem
Server aufgebaut. Anstelle von einzelnen Buchstaben,
wie in den vorangegangenen Experimenten, betätigt
er eine Funktionstaste. In diesem Fall möchte er sich
den zuletzt eingegeben Befehl nochmals anzeigen lassen und betätigt die Taste „Pfeil nach oben“. Funktionstasten erzeugen normalerweise mehrere Bytes.
Die Funktionstaste „Pfeil nach oben“ erzeugt den in
Abbildung 6.12 dargestellten Datenstrom.
Zur Übermittlung des Befehls müssen 3 B Nutzdaten übertragen werden. Bekommt TCP die Daten Byte
für Byte, ist es jedoch möglich, dass es bei aktiviertem Nagle-Algorithmus das erste Byte sendet und die
restlichen Bytes zurückhält, solange, bis das Acknowledgement für das erste Byte empfangen wurde. Der
Server auf der anderen Seite der TCP-Verbindung generiert nach Empfang dieses ersten Bytes aber kein
Echo, da der Befehl noch nicht komplett ist. Er wartet auf die restlichen Bytes. Dies löst den DelayedAcknowledgement-Algorithmus auf dem Server aus.
Daraus folgt, dass er das Acknowledgement des ersten Bytes bis zu 200 ms verzögert. Erst nach Erhalt der vom Server verzögerten Bestätigung sendet
der Client die restlichen Bytes des erzeugten Datenstroms. Dieses Verhalten kann zu spürbaren Verzögerungen für den Nutzer führen. Abbildung 6.13 veranschaulicht den mitgeschnittenen Datentransfer dieses
Experimentes.
Abbildung 6.13.: Datenstrom Experiment 3.
7. TCP – Verbindungsaufbau und -abbau
Sascha Brose
7.1. Verbindungsaufbau
Während des Verbindungsaufbaus wird von beiden Seiten eine Initial Sequence Number gewählt und
Bevor mittels des Transmission Control Protocol in einem SYN-Segment an die Gegenseite übermit(TCP) Daten zwischen zwei Endpunkten ausge- telt. Die ISN bildet dabei einen Startpunkt, an dem
tauscht werden können, muss zunächst eine (virtuelle) die Sequenznummern der nachfolgenden Segmente
Verbindung zwischen ihnen aufgebaut werden. Da- ausgerichtet werden. Die ISN entspricht einer gedurch wird eine zuverlässige Datenübertragung zwi- wöhnlichen 32 bit langen Sequenznummer, die aus
der Menge aller möglichen Sequenznummern ausgeschen beiden Punkten möglich.
wählt wird. Die Auswahl der ISN erfolgt heutzutage
nach komplizierten Algorithmen, die das Ziel haben,
die gewählte ISN unvorhersagbar zu machen.
7.1.1. Drei-Wege-Verbindungsaufbau
An dieser Stelle soll jedoch nur auf die Methode,
die im RFC 793 [Pos81c] spezifiziert wird, näher einZur Herstellung einer TCP-Verbindung werden insge- gegangen werden. Dort wird empfohlen, einen 32 bitsamt drei Segmente zwischen den TCP-Schichten der Zähler zu implementieren, der bei Systemstart mit 0
beiden Kommunikationspartner ausgetauscht. Des- initialisiert und anschließend alle 4 ms um 1 inkrehalb wird der Verbindungsaufbau in der Literatur mentiert wird. Nach Erreichen des größtmöglichen
oft auch als Drei-Wege-Handschlag bzw. Three-Way- Wertes soll der Zähler im folgenden Schritt auf 0 zuHandshake bezeichnet.
rückgesetzt werden und danach einen neuen Zyklus
Um eine Verbindung aufzubauen, wird zunächst durchlaufen. Die ISN soll nun so gewählt werden,
von der einleitenden Seite, normalerweise der Sei- dass sie dem aktuellen Zählerstand entspricht.
te des Clients, ein Segment mit gesetztem SYN-Flag
Die Implementierung von TCP in BSD und in den
an den gewünschten Kommunikationspartner über- meisten Derivaten lehnt sich an dieses Verfahren an.
mittelt. Dieses erste Segment besteht dabei, wie alle Dort wird bei Systemstart ein Zähler mit 1 initializum Verbindungsaufbau übertragenen Segmente, nur siert und im Anschluss jede 5 ms um 64 000 erhöht.
aus einem TCP-Header und enthält noch keine Nutz- D. h. nach jeweils ungefähr 9 Stunden und 30 Minudaten. Neben dem gesetzten SYN-Flag beinhaltet es ten wird mit einem neuen Zyklus begonnen. Dies entdie clientseitige Initial Sequence Number (ISN) im spricht grob der doppelten Zeitspanne, die für einen
Sequenznummernfeld. Geht das gesendete Segment Zyklus mit dem im RFC 793 angegebenen Verfahren
beim Kommunkationspartner ein, wird dort ebenfalls benötigt wird.
ein SYN-Segment mit der serverseitigen ISN erstellt
Abbildung 7.1(a) fasst den Inhalt der drei wähund an den initiierenden Endpunkt übertragen. In die- rend des Verbindungsaufbaus zwischen den TCPsem Segement ist zusätzlich das ACK-Flag gesetzt so- Schichten der beiden Endpunkte ausgetauschten Segwie die um Eins erhöhte, clientseitige ISN im Bestä- mente noch einmal zusammen. Es ist hierbei noch zu
tigungsnummernfeld enthalten. Dies dient zur Emp- bemerken, dass die den Verbindungsaufbau initiierenfangsbestätigung des erhaltenen Segments. Um ent- de Seite in der Literatur auch als Seite, die den active
sprechend der Serverseite den Empfang des zweiten open, sowie die Gegenseite als Seite, die den passive
Segments zu bestätigen, wird der Verbindungsaufbau open durchführt, bezeichnet wird.
durch die Übermittlung eines Segments mit gesetzZum Abschluss soll der Drei-Wege-Verbindungstem ACK-Flag (ein sogenanntes ACK-Segment) und aufbau noch einmal anhand eines praktischen Beider um Eins erhöhten serverseitigen ISN im Bestäti- spieles veranschaulicht werden. Um den Austausch
gungsnummernfeld abgeschlossen.
59
7. TCP – Verbindungsaufbau und -abbau
1. Senden eines SYN-Segmentes mit ISN (C)
und Nummer des Portes zu dem Verbindung hergestellt werden soll von Seite des
Clients an Seite des Servers. (active open)
2. Serverseite antwortet mit SYN-Segment,
das die eigene ISN (S) sowie gesetztes ACKFlag und C+1 als Empfangsbestätigung des
ersten SYN-Segmentes enthält.
(passive open)
3. Clientseite bestätigt Empfang des zweiten
SYN-Segmentes durch Segment mit gesetztem ACK-Flag und S+1.
(a)
dana
ipc654
Segment 1
SYN 195909
5730
Segment 2
0910
SYN 229185
095731
59
19
K
AC
Segment 3
ACK 229815
0911
...
(b)
Abbildung 7.1.: Der Drei-Wege-Verbindungsaufbau: (a) allgemein und (b) spezielles Beispiel.
der drei für den Aufbau einer Verbindung nötigen Segmente zwischen den beiden beteiligten TCPSchichten zu verfolgen, soll vom Clusterrechner dana eine Telnet-Verbindung zur Anwendung discard
auf dem Clusterrechner ipc654 hergestellt werden.
Die von beiden Seiten übermittelten Segmente sollen
von Host ipc654 aus mittels tcpdump abgehört werden. Bei discard handelt es sich um eine Anwendung,
die alle von der TCP-Schicht an sie übergebene Daten verwirft und selbst keine Daten an die Gegenseite
übermittelt. Sie dient primär zu Testzwecken und liegt
standardmäßig an Port 9.
Zur Durchführung des Versuches wird zunächst
tcpdump mit folgendem Befehl auf ipc654 gestartet:
17:04:58 dana.56086 > ipc654.discard:
. ack 1
In der Ausgabe von tcpdump wird zunächst für
jedes abgehörte Segment in der Form Quelle.Port >
Ziel.Port angegeben, von welchem Endpunkt es abgesendet wurde und an welchen Endpunkt es gerichtet
ist. Nachfolgend ist ersichtlich, ob ein SYN- (S), FIN(F), PSH- (P) oder RST-Flag (R) im TCP-Header des
Segments gesetzt ist. Falls keines der genannten Flags
gesetzt ist, wird dies an dieser Stelle durch einen
Punkt symbolisiert. Die folgenden durch einen Doppelpunkt getrennten beiden Zahlen sowie die in Klammern stehende Zahl werden nur dargestellt, wenn im
TCP-Header des Segments eine gültige Sequenznumipc654$ sudo tcpdump tcp port 9
mer enthalten ist. Die erste Zahl entspricht dabei der
Nun kann durch das im Anschluss dargestell- Sequenznummer, während die nachfolgende der Sete Kommando die Telnet-Anwendung auf da- quenznummer plus der Anzahl der im Segment überna ausgeführt werden. Diese leitet den TCP- mittelten Nutzdatenbytes gleicht. Die eingeklammerte Zahl gibt die im Segment enthaltenen NutzdatenVerbindungsaufbau ein.
bytes an. Ist im TCP-Header das ACK-Flag gesetzt,
dana$ telnet ipc654 discard
wird von tcpdump zusätzlich „ack“ und im Anschluss
die entsprechende Bestätigungsnummer ausgegeben.
Die von tcpdump erstellte Ausgabe ist nachfol- Hier ist noch zu erwähnen, dass tcpdump standardgend in vereinfachter Form dargestellt.
mäßig nur für das erste abgehörte Segment pro Richtung die wirklichen Sequenz- und Bestätigungsnum17:04:58 dana.56086 > ipc654.discard:
mern ausgibt. Die Sequenz- und BestätigungsnumS 1959095730:1959095730(0)
mern aller weiteren Segmente werden von tcpdump
17:04:58 ipc654.discard > dana.56086:
relativ dazu angegeben. D.h. die Bestätigungsnummer
S 2291850910:2291850910(0)
ack 1959095731
im dritten Segment ist in Wirklichkeit nicht 1 wie dar-
60
7.1. Verbindungsaufbau
gestellt, sondern entspricht der ISN 2 291 850 910 von
ipc654 plus 1, also 2 291 850 911. Diese Umformatierung hat den Sinn, die Lesbarkeit der Ausgabe zu
verbessern, kann aber gegebenenfalls auch durch die
Angabe des Parameters „-S“ ausgeschaltet werden.
In Abbildung 7.1(b) ist der zeitliche Ablauf, zusammen mit den in den TCP-Headern der einzelnen Segmente gesetzten Flags sowie den enthaltenen
Bestätigungsnummern, zu obigem Beispiel graphisch
dargestellt.
7.1.2. Wiederholte Übermittlung von
SYN-Segmenten
Wurde der Drei-Wege-Handschlag zwischen den
TCP-Schichten zweier Endpunkte erfolgreich realisiert, kann im Anschluss mit dem eigentlichen Datenaustausch begonnen werden. Wie aber reagiert das
clientseitige TCP, wenn auf das gesendete SYNSegment die Antwort in Form des serverseitigen
SYN-Segments ausbleibt und die Verbindung somit
nicht etabliert werden kann? Auf diese Frage soll im
Folgenden eingegangen werden.
Das Ausbleiben des serverseitigen SYN-Segments
kann unterschiedliche Gründe haben. Eine mögliche
Ursache besteht darin, dass das clientseitige SYNSegment auf dem Weg zum Empfänger verloren gegangen ist oder dort von einer Firewall herausgefiltert
wurde. Des Weiteren ist es möglich, dass der Host des
Servers zur Zeit nicht am Netz ist oder wegen Überlastung nicht auf Anfragen reagieren kann.
In BSD und den meisten Derivaten ist TCP so implementiert, dass beim Systemstart ein Timer angestoßen wird, der alle 500 ms einen Interrupt auslöst.
Sobald ein active open durchgeführt wird, wird ein
der Verbindung zugeordneter Zähler mit 12 initialisiert und bei jedem durch den Timer hervorgerufenen
Interrupt um 1 dekrementiert. Dies passiert solange,
bis entweder das serverseitige SYN-Segment eingetroffen ist oder der Zähler den Wert 0 erreicht hat. Ist
der Zähler bei 0 angelangt, wird nochmals ein SYNSegment, welches dem ersten entspricht, abgeschickt
und danach der Zähler auf den Wert 48 gesetzt. Im
Anschluss wird wie nach der ersten Initialisierung
des Zählers mit dem Wert 12 fortgefahren. Erreicht
der Zähler wiederum den Wert 0, erfolgt der erneute
Versand eines Duplikates des ersten SYN-Segments.
Nachfolgend wird allerdings nur noch bis zu dem
Zeitpunkt gewartet, an dem seit der Übermittlung des
ersten SYN-Segments 75 s vergangen sind. Ist das serverseitige SYN-Segment bis dahin noch nicht eingegangen, wird der Verbindungsaufbau abgebrochen.
Da der Zähler, nachdem er mit dem Wert 12 initialisiert wurde, das erste Mal zwischen 0 ms und weniger als 500 ms dekrementiert wird, erfolgt der Versand
des zweiten SYN-Segments zwischen 5, 5 s und weniger als 6 s nach dem ersten. In Abbildung 7.2(a) ist
dies graphisch dargestellt. Das dritte und letzte SYNSegment wird 24 s nach dem zweiten abgeschickt,
falls bis dahin noch keine serverseitige Antwort eingetroffen ist. Diese Zeitspanne entspricht dabei genau
48 mal 500 ms.
Das gerade Beschriebene bezieht sich, wie bereits
erwähnt, auf die Implementierung in BSD und vielen davon abgeleiteten Betriebssystemen. Die Realisierungen in anderen Betriebssystemen unterscheiden
sich davon hauptsächlich nur in der Anzahl der bis
zum Abbruch des Verbindungsaufbaues gesendeten
Duplikate sowie den Sendezeitpunkten.
Zum Abschluss soll durch einen praktischen
Versuch auf die Implementierung unter Debian
GNU/Linux 3.1 eingegangen werden. Dazu soll vom
Clusterrechner ipc654 eine Telnet-Verbindung zu einem Windows-XP-Host aufgebaut und die gesendeten Segmente mittels tcpdump abgehört werden.
Dem Netzzugang des XP-Rechners ist dabei die IPAdresse 141.35.180.92 zugewiesen. Zusätzlich verfügt er über eine ZoneAlarm-Firewall, die die ankommenden SYN-Segmente herausfiltert und somit keinen Verbindungsaufbau zustande kommen lässt. Um
den Versuch durchzuführen, wird zunächst tcpdump
und daraufhin telnet auf ipc654 gestartet. Die dazu
gemachten Eingaben sowie die Ausgaben beider Programme sind im Folgenden (im Falle von tcpdump
vereinfacht) dargestellt.
ipc654$ date; telnet 141.35.180.92;
date
Do Sep 21 16:58:12 CEST 2006
Trying 141.35.180.92...
telnet: Unable to connect to remote
host: Connection timed out
Do Sep 21 17:01:21 CEST 2006
ipc654$ tcpdump -i eth1 tcp port 23
16:58:12 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
16:58:15 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
16:58:21 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
16:58:33 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
16:58:57 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
16:59:45 ipc654.49123 > 141... telnet:
S 1863008374:1863008374(0)
61
7. TCP – Verbindungsaufbau und -abbau
dana
11 * 500 Millisekunden = 5,5 Sekunden
11
10
9
8
7
6
5
4
3
2
1
Segment 4
0
Applikation
close
Segment 5
Zu einem Zeitpunkt
dieses Intervalls erfolgt Initialisierung
des entsprechenden
Zählers mit Wert 12
1 Sekunde
Zurücksetzen
des entsprechenden Zählers
auf Wert 48
(a)
...
ipc654
FIN 195909
5731
EOF an
Applikation
5732
ACK 195909
0911
FIN 229185
Applikation
close
Segment 6
Segment 7
ACK 229815
0912
(b)
Abbildung 7.2.: (a) Der 500ms-Timer und (b) Vier-Wege-Verbindungsabbau.
Anhand der Ausgaben wird ersichtlich, dass unter
Debian GNU/Linux 3.1 insgesamt 6 SYN-Segmente
abgeschickt werden, um den Verbindungsaufbau einzuleiten. Die Wartezeit, die bis zum erneuten Versand eines SYN-Segments eingehalten wird, verdoppelt sich dabei jeweils, beginnend bei 3 s. Ist 96 s nach
Übermittlung des sechsten SYN-Segments noch keine
Antwort eingetroffen, so wird der Verbindungsaufbau
189 s nach der Übertragung des ersten SYN-Segments
abgebrochen.
7.2. Verbindungsabbau
Durch den Drei-Wege-Verbindungsaufbau wird eine
logische Punkt-zu-Punkt-Verbindung im VollduplexModus aufgebaut. Dies bedeutet, dass der Datentransfer über diese Verbindung in beide Richtungen
gleichzeitig erfolgen kann. Um eine bestehende TCPVerbindung zu trennen, müssen beide Datenflussrichtungen jeweils unabhängig voneinander geschlossen
werden. Das Schließen der Verbindung in Richtung
der Gegenseite wird dabei durch den Versand eines
Segments mit gesetztem FIN-Flag (ein sogenanntes
FIN-Segment) im enthaltenen TCP-Header realisiert.
Hierbei ist wichtig zu bemerken, dass FIN-Segmente
im Unterschied zu SYN-Segmenten zusätzlich zum
TCP-Header Nutzdaten enthalten können. In Analogie zum Verbindungsaufbau führt hier diejenige Seite,
62
die den Verbindungsabbau einleitet, den active close
bzw. die Gegenseite den passive close durch.
Die vollständige Trennung einer TCP-Verbindung
kann im Allgemeinen auf zwei leicht unterschiedliche Arten erfolgen. Zum einen durch den allgemeinen Vier-Wege-Verbindungsabbau sowie zum anderen durch einen Half-Close, der im Abschnitt 7.2.2
genauer vorgestellt werden soll.
7.2.1. Allgemeiner Vier-WegeVerbindungsabbau
Zum Abbau einer etablierten TCP-Verbindung wird
in den meisten Fällen der allgemeine Vier-WegeVerbindungsabbau durchgeführt. Dabei ruft diejenige Applikation, die keine weiteren Daten übermitteln sowie empfangen möchte, die TCP-Funktion close auf. TCP sendet daraufhin ein FIN-Segment, um
die Verbindung in Richtung der Gegenseite zu schließen. Eventuell noch zum Versand ausstehende, gepufferte Nutzdaten werden hierbei vollständig vor oder
spätestens in dem FIN-Segment übertragen.
Geht das FIN-Segment in der TCP-Schicht des
Empfängers ein, wird vom dortigen TCP ein ACKSegment als Empfangsbestätigung mit der entsprechenden Bestätigungsnummer zurückgesendet. Zusätzlich informiert das Transmission Contol Protocol
die betreffende Anwendung durch die Übergabe eines
End of File (EOF), dass die Applikation der Gegenseite keine weiteren Daten an sie übermitteln möchte.
7.2. Verbindungsabbau
Als Reaktion darauf ruft sie ebenfalls close auf, um
die Schließung der noch geöffneten Übertragungsrichtung einzuleiten. Auf diesen Aufruf reagierend,
übersendet TCP seinerseits ein FIN-Segment an die
Gegenseite. Diese bestätigt durch den Versand eines
ACK-Segments mit der entsprechenden Bestätigungsnummer den Empfang des FIN-Segments und schließt
dadurch den Vier-Wege-Verbindungsabbau ab.
Abschließend soll der Vier-Wege-Verbindungsabbau nochmals anhand eines praktischen Versuches
veranschaulicht werden. Dazu soll das zum DreiWege-Verbindungsaufbau durchgeführte Beispiel aus
Abschnitt 7.1.1 fortgesetzt werden. Dort wurde bereits eine Telnet-Verbindung von dana zur Anwendung discard auf dem Host ipc654 aufgebaut. Die dabei übermittelten Segmente wurden mittels tcpdump
von ipc654 aus abgehört. Nun soll „quit“ im TelnetClient eingegeben werden. Vor dem Schließen ruft
telnet jedoch close auf und leitet so den Vier-WegeVerbindungsabbau zur Trennung der etablierten Verbindung ein.
Die Ausgabe von tcpdump ist nachfolgend vereinfacht dargestellt. Auch wurde auf die erneute Auflistung der drei zum Verbindungsaufbau ausgetauschten
Segmente verzichtet.
ipc654$ sudo tcpdump tcp port 9
...
19:10:12 dana.56086 > ipc654.discard:
F 1:1(0) ack 1
19:10:12 ipc654.discard > dana.56086:
. ack 2
19:10:12 ipc654.discard > dana.56086:
F 1:1(0)
19:10:13 dana.56086 > ipc654.discard:
. ack 2
7.2.2. Half-Close
Im Gegensatz zum allgemeinen Vier-WegeVerbindungsabbau wird beim Half-Close die
aufgebaute TCP-Verbindung zunächst nur in eine
Richtung geschlossen. Die Gegenrichtung bleibt
weiter geöffnet und wird von der Anwendung der
Gegenseite zur Datenübertragung genutzt.
Bei der Einleitung des Half-Close muss dabei die
Anwendung die TCP-Funktion shutdown aufrufen,
damit die ankommenden Daten vom TCP überhaupt
noch an sie weitergeleitet werden. Diese Funktion impliziert, dass TCP zwar durch das Senden eines FINSegments die Verbindung in Richtung der Gegenseite
schließt, jedoch die auf der Gegenrichtung dieser Verbindung ankommenden Daten noch an die Anwendung weiterleitet.
Die eine Richtung der Verbindung bleibt weiterhin solange geöffnet, bis die entsprechende Anwendung keine Daten mehr übertragen möchte und ihrerseits close aufruft. Dies führt in Analogie zum allgemeinen Vier-Wege-Verbindungsabbau zur Übertragung eines FIN-Segments an die Gegenseite. Auch
wird vom dortigen TCP wiederum ein ACK-Segment
als Bestätigung für den Empfang des FIN-Segments
zurückgesendet und dadurch der Half-Close abgeschlossen. Der eben beschriebene Sachverhalt ist in
Abbildung 7.3(a) zusätzlich in graphischer Form angegeben.
In der Praxis kommt der Half-Close im Vergleich
zum allgemeinen Vier-Wege-Verbindungsabbau relativ selten vor. Im Folgenden soll ein Anwendungsbeispiel vorgestellt werden, bei dem ein Half-Close zur
Trennung der aufgebauten TCP-Verbindung durchgeführt wird.
Der nachfolgende Befehl führt die Anwendung
sort auf dem entfernten Host ipc654 aus.
dana$ rsh ipc654 sort < data
In Abbildung 7.2(b) sind die ausgetauschten Segmente mit den tatsächlichen Sequenz- und Bestätigungsnummern sowie den gesetzten Flags nochmals
graphisch dargestellt.
Es ist noch zu erwähnen, dass gelegentlich das
zweite und dritte Segment des allgemeinen VierWege-Verbindungsabbaus vom TCP der passiveclose-Seite durch ein einziges Segment ersetzt werden. Dieses enthält dabei ein gesetztes FIN- sowie
ACK-Flag und die entsprechende Sequenz- sowie Bestätigungsnummer. In diesen Fällen werden somit nur
drei Segmente zwischen beiden Seiten ausgetauscht,
um die etablierte Verbindung vollständig zu schließen.
sort ist dabei ein Programm, das Eingaben nach Er-
halt eines End of File (EOF) sortiert zurückgibt. Im
gegebenen Fall liegt die zu sortierende Eingabe allerdings in der Datei data auf dana vor, so dass zunächst
von rsh der Aufbau einer TCP-Verbindung zu ipc654
initiiert wird. Nach dem Aufbau der Verbindung liest
der Client-rsh den Inhalt der Datei aus und übermittelt diesen über die TCP-Verbindung. Wurde der Inhalt vollständig übertragen, leitet rsh den Half-Close
ein, woraufhin das serverseitige sort ein EOF erhält
und mit dem Sortieren beginnt. Die sortierte Eingabe wird über die noch geöffnete Richtung der Verbindung an den Client-rsh zurückgegeben und von diesem anschließend im Terminal ausgegeben. Die Ab-
63
7. TCP – Verbindungsaufbau und -abbau
Client
Applikation
shutdown
Server
FIN
ack des FIN's
Applikation
read
EOF an
Applikation
Applikation
write
Host dana
Standard Ausgabe:
Terminal
rsh
Daten
ack der Daten
EOF an
Applikation
Standard Eingabe:
Datei data
FIN
Applikation
close
TCPVerbindung
Host ipc654
ack des FIN's
(a)
sort
(b)
Abbildung 7.3.: Half-Close: (a) allgemein und (b) spezielles Beispiel.
bildung 7.3(b) stellt den Ablauf dieses Anwendungsbeispiels noch einmal graphisch dar.
Durch den Einsatz des Half-Close kann der Anwendung sort vergleichsweise einfach mitgeteilt
werden, dass die Eingabe vollständig erfolgt ist.
7.3. Zustandsdiagramm
Abbildung 7.4 zeigt das TCP-Zustandsdiagramm, in
dem alle Zustände, die TCP für eine Verbindung einnehmen kann, dargestellt sind. Die normalerweise
vom TCP des Clients vollzogenen Zustandsübergänge
sind hierbei mittels dickeren, durchgezogenen Pfeilen
angedeutet, während die gestrichelten Pfeile typische
serverseitige TCP-Zustandsübergänge symbolisieren.
Der Auslöser für einen Zustandsübergang und die
eventuell durch den Übergang ausgelösten Aktionen
sind jeweils an der entsprechenden Überführungslinie
spezifiziert. Es ist jedoch an dieser Stelle zu bemerken, dass einige der hier abgebildeten Zustandsüberführungen nicht immer gültig sind. Beispielsweise ist
der Übergang vom Zustand SYN_RCVD zu LISTEN
nur erlaubt, falls SYN_RCVD über LISTEN erreicht
wurde. Auch sind in den meisten Realisierungen von
TCP nicht alle der hier abgebildeten Zustandsüberführungen implementiert. Hier kann als Beispiel das
Betriebssystem BSD erwähnt werden, dessen TCP
den Übergang von SYN_RCVD in den Zustand LISTEN gar nicht unterstützt.
64
Die hier verwendeten Zustandsbezeichnungen
stimmen mit den Namen der Zustände, die von
netstat ausgegeben werden, überein. Im Vergleich
zu den im RFC 793 auf Seite 54 spezifizierten Namen
unterscheiden sie sich jedoch.
Im Folgenden soll kurz anhand des Zustandsüberführungdiagramms nachvollzogen werden, welche
Zustände das client- sowie serverseitige TCP während
des Auf- und Abbaus einer Verbindung durchläuft.
Dazu wird angenommen, dass der Client sowohl den
active open als auch den active close durchführt.
Das clientseitige TCP befindet sich zu Beginn
im Zustand CLOSED, wohingegen das serverseitige TCP im Zustand LISTEN auf eingehende Verbindungsanfragen wartet. Der Zustand CLOSED bildet
dabei nur einen Start- bzw. Endpunkt des Diagramms
und ist in Wirklichkeit nicht realisiert. Nachdem das
TCP des Clients den Verbindungsaufbau durch die
Übermittlung eines SYN-Segments eingeleitet hat,
geht es in den Zustand SYN_SENT über. Das TCP der
Gegenseite antwortet auf den Empfang dieses Segments mit dem Versand eines eigenen SYN-Segments
und nimmt daraufhin den Zustand SYN_RCVD ein.
Geht das serverseitige SYN-Segment im TCP des
Clients ein, überträgt dieses ein ACK-Segment und
wechselt im Anschluss in den Zustand ESTABLISHED. Empfängt das serverseitige TCP dieses ACKSegment, geht es ebenfalls in diesen Zustand über.
Nachdem beide Seiten den Zustand ESTABLISHED
erreicht haben, ist der Verbindungsaufbau abgeschlos-
7.3. Zustandsdiagramm
starting point
CLOSED
ap
appl: passive open
send: <nothing>
recv: SYN
send: SYN,ACK
v
rec
pl:
ac t
ive
s en
op
d:
en
SY
N
LISTEN
app
l
sen : send
d:
SY data
N
passive open
ST
:R
recv: SYN; send: SYN,ACK
SYN_RCVD
SYN_SENT
simultaneous open
r
se n e c v : A
d: <
C
no t K
hi n
g>
data transfer state
ESTABLISHED
appl: close
send: FIN
K
,A C
YN CK
S
:
v
A
rec end:
s
recv: FIN
send: ACK
e
lo s
: c IN
l
F
p
ap nd:
se
recv: FIN
send: ACK
appl: close
send: FIN
LAST_ACK
recv: ACK
send: <nothing>
recv: FIN
send: ACK
passive close
CLOSING
recv: ACK
rec
send: <nothing>
v:
F
sen IN,
A
d:
AC CK
K
FIN_WAIT_2
active open
CLOSE_WAIT
simultaneous close
FIN_WAIT_1
appl: close
or timeout
recv: ACK
send: <nothing>
TIME_WAIT
2MSL timeout
active close
appl:
recv:
send:
indicate normal transitions for client
indicate normal transitions for server
indicate state transitions taken when application issues operation
indicate state transitions taken when segment received
indicate what is sent for this transition
Abbildung 7.4.: TCP-Zustandsüberführungsdiagramm.
65
7. TCP – Verbindungsaufbau und -abbau
sen. Daraufhin kann die Datenübertragung zwischen
Client und Server in beide Richtungen erfolgen, bis
eine der beiden Seiten den Verbindungsabbau initiiert. In diesem Beispiel soll dies, wie oben angenommen, durch den Client passieren. Das clientseitige
TCP begibt sich nach der Übermittlung eines FINSegments in den Zustand FIN_WAIT_1, wohingegen
das Transmission Control Protocol des Servers den
Empfang dieses FIN-Segments durch den Versand eines ACK-Segments bestätigt und danach in den Zustand CLOSE_WAIT wechselt. Das Eintreffen des
ACK-Segments im TCP des Clients bewirkt den dortigen Übergang in den Zustand FIN_WAIT_2. Hier
angekommen verharrt das clientseitige TCP solange,
bis es von der Serverseite ein FIN-Segment übermittelt bekommt. Erhält es dieses, quittiert es den Empfang durch die Übertragung eines ACK-Segments und
geht im Anschluss in den Zustand TIME_WAIT über.
Das TCP des Servers, das sich vor dem Versand des
FIN-Segments an die Clientseite im Zustand CLOSE_WAIT befand, wechselt nach der Übermittlung
in den Zustand LAST_ACK. Nachdem es die Empfangsbestätigung für das gesendete FIN-Segment in
Form eines ACK-Segments vom TCP des Clients erhalten hat, erfolgt der Übergang in den Endzustand
CLOSED.
Natürlich müssen die Sequenz- bzw. Bestätigungsnummern in den ausgetauschten Segmenten entsprechend gesetzt werden. Aus Gründen der Lesbarkeit
wurde darauf im obigen Beispiel nicht explizit eingegangen.
weil TCP eine Verbindung zusätzlich noch solange bekannt bleibt, bis der TIME_WAIT-Zustand für
diese Verbindung verlassen wird. Auf Verbindungen
im TIME_WAIT-Zustand eingehende FIN-Duplikate
werden somit akzeptiert und durch den nochmaligen Versand des entsprechenden ACK-Segments bestätigt. Ein empfangenes FIN-Duplikat deutet hierbei darauf hin, dass der Sender diese Verbindung
noch nicht vollständig getrennt hat, weil er das ACKSegment für das vorausgegangene FIN-Segment nicht
erhalten hat. Würde TCP nicht zunächst in den
TIME_WAIT-Zustand übergehen, könnten verspätete Segmente sowie FIN-Duplikate keiner Verbindung
mehr zugeordnet werden. Dies würde die Übermittlung eines Segments mit gesetzem RST-Flag an den
jeweiligen Sender auslösen. Im Falle eines empfangenen FIN-Duplikates, dessen Sender die entsprechende
Verbindung noch nicht vollständig getrennt hat, hätte
die Übermittlung eines RST-Segments den sofortigen
Verbindungsabbruch der noch in eine Richtung geöffneten Verbindung zur Folge. Hat das TCP für eine
Verbindung bereits den TIME_WAIT-Zustand verlassen, lösen verspätete Segmente sowie Duplikate dieser Verbindung natürlich dennoch RST-Segmente aus.
Zusätzlich ist es nicht möglich, eine neue Instanz
einer Verbindung (Inkarnation) aufzubauen, für die
sich TCP im TIME_WAIT-Zustand befindet. Dies soll
verhindern, dass verspätete Segmente der alten Instanz von TCP als Segmente der neuen Inkarnation
fehlinterpretiert werden. In den meisten Implementierungen von TCP ist dies jedoch noch strenger ausgelegt. Dort kann der lokale Port einer Verbindung,
für die TCP den TIME_WAIT-Zustand eingenommen
7.3.1. Der Zustand TIME_WAIT
hat, keiner neuen Verbindung als Endpunkt zugewieDas TCP derjenigen Seite, die den active close durch- sen werden.
Im Folgenden soll ein praktisches Beispiel durchgeführt hat, geht in den Zustand TIME_WAIT über,
nachdem es das FIN-Segment der Gegenseite durch geführt werden, mit dem auf diesen Sachverhalt nochein entsprechendes ACK-Segment bestätigt hat. Im mals eingegangen wird. Hierbei soll das Programm
Anschluss verharrt es in diesem Zustand für die zwei- sock zum Einsatz kommen, das entweder als Client
fache Maximum Segment Lifetime (MSL). Dies ist der oder auch als Server fungieren kann. Durch den nachGrund, warum der TIME_WAIT-Zustand auch gele- folgenden Aufruf wird sock zunächst als Server, dies
gentlich als 2MSL-Zustand bezeichnet wird. Die Ma- wird durch den Parameter „-s“ spezifiziert, auf dem
ximum Segment Lifetime ist dabei die angenomme- Host ipc654 an Port 6666 gestartet.
ne Maximalzeit, die ein Segment im Netzwerk verbringen kann, bevor es verworfen wird. Die MSL ipc654$ sock -s 6666
wird nicht dynamisch bestimmt, sondern bei der
Anschließend wird durch den unten angegebenen
TCP-Implementierung als Konstante vorgegeben. Im Befehl ein sock-Client auf dana ausgeführt, der sich
RFC 793 wird sie mit 2 Minuten spezifiziert, wohin- mit dem auf ipc654 laufenden sock-Server verbingegen sie in den meisten TCP-Realisierungen bei 30 s det. Der Parameter „-v“ bewirkt dabei, dass der Client
oder 60 s liegt.
nach erfolgreichem Verbindungsaufbau die EndpunkDurch das Verweilen im TIME_WAIT-Zustand te ausgibt.
kann der korrekte Abbau einer etablierten Verbindung besser gewährleistet werden. Dies ist der Fall, dana$ sock -v ipc654 6666
66
7.4. Resetsegmente
connected on 192.168.1.5.37356
to 192.168.1.1.6666
7.4.1. Verbindungsaufbau zu einem
unbesetzten Port
Empfängt TCP eine Verbindungsanfrage in Form eines SYN-Segments, in dem ein lokaler Zielport spezifiziert ist, der von keinem Server auf dem Host
abgehört wird, übermittelt es ein RST-Segment an
den Sender. Das RST-Segment bewirkt den sofortigen Abbruch des Verbindungsaufbaus. Die Sequenznummer des RST-Segments beträgt dabei 0, da zuvor
dana$ sock -b37356 ipc654 6666
keine Verbindung aufgebaut wurde und das eingehenbind() error: Address already in use
de SYN-Segment kein gesetztes ACK-Flag und damit
Durch die Fehlerausgabe ist zu erkennen, dass kei- keine gültige Bestätigungsnummer enthalten hat. Im
ne neue Verbindung zwischen Client und Server auf- RST-Segment ist zusätzlich noch das ACK-Flag gegebaut werden konnte. Der Grund dafür wird anhand setzt, um den Empfang des SYN-Segments zu bestäder im Anschluss vereinfacht dargestellten Ausgabe tigen. Die Bestätigungsnummer entspricht dabei wie
des Programms netstat, das auf dana aufgerufen üblich der um 1 erhöhten Sequenznummer des erhaltenen SYN-Segments.
wurde, ersichtlich.
Das beschriebene Verhalten soll zum Abschluss
dieses
Kapitels zusätzlich anhand eines kleinen prakdana$ netstat
tischen
Beispiels veranschaulicht werden. Dazu soll
Aktive Internetverbindungen (o. Server)
zunächst
tcpdump auf ipc654 gestartet werden, um
Prot Local A.
Foreign A.
State
die
übertragenen
Segmente abzuhören. Danach soll
tcp dana:37356 ipc654:6666 TIME_WAIT
von dana mittels telnet der Verbindungsaufbau zum
Das TCP des Clients befindet sich für die ers- unbesetzten Port 30000 auf ipc654 eingeleitet werte Verbindung noch im TIME_WAIT-Zustand. Der den. Die zur Durchführung nötigen Eingaben sowie
Port 37356 kann somit, bis TCP den TIME_WAIT- die resultierenden Ausgaben sind nachfolgend (im
Zustand für diese Verbindung verlassen hat, von da- Falle von tcpdump vereinfacht) dargestellt.
na nicht als lokaler Endpunkt einer neuen Verbindung dana$ telnet -4 ipc654 30000
verwendet werden.
Trying 192.168.1.1...
Im obigen Beispiel wird der active close von telnet: Unable to connect to remote
der Seite des Clients durchgeführt. Daraus resultiert,
host: Connection refused
dass das TCP des Clients für diese Verbindung den
TIME_WAIT-Zustand einnehmen muss. Dies stellt ipc654$ sudo tcpdump tcp port 30000
jedoch kein Problem dar, da Clients gewöhnlich nicht 13:10:53 dana.51112 > ipc654.30000:
S 2840327430:2840327430(0)
an einen bestimmten Port gebunden sind. Wird der
13:10:53
ipc654.30000
> dana.51112:
Abbau einer Verbindung hingegen vom Server einR
0:0(0)
ack
2840327431
geleitet, führt dies im Allgemeinen dazu, dass dieser seinen Dienst während der nachfolgenden zweifaDer beim Aufruf von telnet angegebene Parachen Maximum Segment Lifetime nicht mehr anbie- meter „-4“ bewirkt, dass die Übertragung der TCPten kann. Dies ist damit zu begründen, dass der Server Segmente nur über IPv4 erfolgt.
sich in dieser Zeit nicht den standardmäßigen lokalen
Port zuweisen kann.
Nun soll der Client zunächst geschlossen und danach mit dem im Anschluss dargestellten Kommando
erneut gestartet werden. Mit der Angabe des Parameters „-b37356“ wird ihm dabei wieder der gleiche lokale Port zugewiesen.
7.4.2. Verbindungsabbruch
7.4. Resetsegmente
Segmente, deren RST-Flag im enthaltenen TCPHeader gesetzt ist, werden auch als Resetsegmente
bezeichnet. Der Versand eines RST-Segments kann
dabei auf verschiedenen Gründen beruhen. Nachfolgend sollen zwei Situationen betrachtet werden, in denen es zur Übermittlung eines RST-Segments kommt.
Neben den beiden bereits bekannten Verfahren, mittels denen eine aufgebaute Verbindung getrennt werden kann (allgemeiner Vier-Wege-Verbindungsabau,
Half-Close), existiert noch eine weitere Möglichkeit
– der Verbindungsabbruch.
Erhält TCP den Befehl, eine Verbindung abzubrechen, werden alle eventuell noch zum Versand ausstehenden, gepufferten Daten verworfen und ein RSTSegment an die Gegenseite übermittelt, wodurch die-
67
7. TCP – Verbindungsaufbau und -abbau
se über den Verbindungsabbruch in Kenntnis gesetzt
wird. Nach dem Empfang dieses RST-Segments informiert das TCP der Gegenseite seine Anwendung über
den Verbindungsabbruch. Dieser ist daraufhin abgeschlossen, da kein ACK-Segment als Empfangsbestätigung für das erhaltene RST-Segment gesendet wird.
In dem zum sofortigen Abbruch der Verbindung
übertragenen RST-Segment ist die von der Gegenseite
erwartete, aktuelle Sequenznummer angegeben. Mittels eines gesetzten ACK-Flags und der entsprechenden Bestätigungsnummer kann zusätzlich noch der
Erhalt empfangener Segmente quittiert werden.
7.5. Zusammenfassung
In diesem Kapitel wurde zunächst darauf eingegangen, wie über TCP mittels eines sogenannten Drei-Wege-Handschlags eine logische Verbindung zwischen zwei Endpunkten hergestellt werden kann. Nachfolgend wurden mit dem allgemeinen
Vier-Wege-Verbindungsabbau und dem Half-Close
zwei Verfahren zur Trennung einer etablierten TCPVerbindung vorgestellt.
Anhand des Zustandsüberführungsdiagramms wurde näher auf die Zustände eingegangen, die vom TCP
eingenommen werden können. Zusätzlich wurde der
Zustand TIME_WAIT genauer analysiert, der im wesentlichen dazu dient, verspätete Segmente einer bestehenden Verbindung herauszufiltern und einen korrekten Verbindungsabbau besser zu gewährleisten.
Abschließend wurden mit dem Verbindungsaufbau
zu einem unbesetzten Port und dem Verbindungsabbruch zwei Situationen vorgestellt, in denen es zur
Übermittlung von RST-Segmenten kommt.
68
8. TCP Bulk Data Flow
Stefan Kratsch
8.1. Einführung
8.1.1. Grundlagen
Dieses Kapitel soll eine Einführung in die Aspekte
von TCP-Implementierungen bieten, welche besonders beim Versenden großer nicht-interaktiver Datenmengen zum Tragen kommen. Im Speziellen wollen wir Sliding Window, Slow Start und Congestion
Avoidance auf dem Stand von TCP Reno betrachten. Ebenso widmen wir uns den Änderungen, die
zur Vermeidung des Silly Window Syndrome und zum
Umgang mit Long Fat Pipe Networks (LFNs) dienen. Nicht betrachten werden wir die Vorhersage von
Paketverlusten auf Basis der gemessenen Round Trip
Time, wie sie in TCP Vegas betrieben wird.
Zunächst einige Grundannahmen über das Verhalten von TCP:
• TCP betrachtet Daten als einen Bytestream, und
weist jedem Byte eine Sequenznummer zu. Ein
TCP-Paket enthält dementsprechend im Header
die Nummer des ersten enthaltenen Datenbytes
und die Länge (Anzahl der Bytes).
• TCP abstrahiert auf eine direkte Verbindung zwischen Sender und Empfänger.
• TCP hat keine Information über Art und Zustand der vermittelnden Hardware, z. B. Größe
und Füllstand von Routerqueues.
• TCP erfährt nicht, ob andere Verbindungen zur
gleichen Zeit Daten übertragen.
• Insgesamt hat TCP nur eine sehr unscharfe Sicht
auf den Zustand des Netzwerks.
Der Schwerpunkt im Bereich Bulk Data Flow liegt
im möglichst effizienten Versenden ohne häufige Paketverluste. Es ist daher notwendig, dass der Sender
eine grobe Sicht der Verbindung gewinnt, sie möglichst gut auslastet, aber auch gegebenenfalls die Sen-
derate reduziert, wenn Paketverluste eine Verstopfung der Leitungen andeuten. Diese Reduzierung ist
auch notwendig im Hinblick auf die Fairness zwischen verschiedenen Verbindungen. Eine neu begonnene Übertragung in einem ausgelasteten Netzwerk
könnte sonst kaum Bandbreite bekommen.
Allerdings versuchen Implementierungen des TCP
regelmäßig, die Senderate zu erhöhen, um etwaige
frei werdende Kapazitäten zu nutzen. TCP Reno versucht dies ständig, während TCP Vegas die gemessene Round Trip Time zu Rate zieht. Trotz diverser
Techniken weiß TCP nicht, welchen Weg die Pakete
nehmen, und ob eine erhöhte oder verringerte Round
Trip Time wirklich eine gute Aussage über den Zustand der Verbindung macht. TCP Reno verwendet
die gemessene Round Trip Time nur für die Bestimmung des Timeout (Gegenstand von Kapitel 9), doch
Techniken wie Delayed Acknowledgements erschweren eine genaue Messung.
Im Gegensatz zum stop-and-wait-Ansatz wird eine Flusskontrolle in Form des Sliding Window verwendet. Dabei muss nicht jedes Paket einzeln bestätigt werden, bevor das nächste verschickt wird. Stattdessen teilt der Empfänger mit, bis zu welcher Byteposition er alle Pakete erhalten hat und wieviele der
folgenden Bytes empfangen werden können. Alle Datenbytes in diesem Bereich können also vom Sender
ohne weiteren Rückmeldungsbedarf verschickt werden. Problematisch ist diese Technik nur, wenn ein
Paket verloren ging, da darauf folgende Pakete vorerst
nicht bestätigt werden können. Es gibt jedoch auch
die Technik der Selective Acknowledgements, die eine
genauere Angabe fehlender Pakete erlaubt.
Wir werden in dieser Ausarbeitung einige Begriffe
und Abkürzungen verwenden:
• MSS = Maximum Segment Size bezeichnet die
maximale Größe eines Segments in Bytes.
• RTT = Round Trip Time bezeichnet die Zeit
zwischen dem Versenden eines Pakets und dem
Eintreffen des zugehörigen Acknowledgements.
69
8. TCP Bulk Data Flow
Receive Window
vom Empfänger angeboten
möglich zu
versenden
0
1
2
3
4
5
6
7
8
9
10
........
ungesendet
gesendet
bestätigt
noch nicht
versendbar
unbestätigt
Abbildung 8.1.: Sliding Window.
Dieser Wert kann sinnvollerweise nur für zum
ersten Mal gesendete Pakete (z. B. nicht für Retransmission) gemessen werden. Meistens wird
ein Mittelwert der bisherigen Messungen gespeichert und gewichtet mit dem aktuellen Messwert
verrechnet.
• Sender und Empfänger bezeichnen im Allgemeinen nicht immer eindeutig zwei Rechner. Vielmehr sind bei einer zweiseitigen Datenübertragung beide Seiten als Sender und Empfänger tätig. Unsere Betrachtungen werden sich aber auf
einen Datenstrom von einem Rechner zu einem
anderen beschränken, insofern ist hier stets einer
Sender und einer Empfänger.
8.1.2. Sliding Window
wurde, erfolgen dann ein oder mehrere Window Updates.
Hat der Empfänger sehr viele Daten erhalten, aber
noch keine an die Applikation weitergereicht, so dass
der Receive Buffer voll ist, dann kann er trotzdem bestätigen und keine weiteren Bytes erlauben. Diese Art
von Acknowledgement nennt man Zero Window. Es
wird erwartet, dass der Empfänger ein Window Update verschickt, sobald wieder hinreichend Platz im
Buffer ist. Wie groß diese Veränderung sein muss, war
ursprünglich nicht festgelegt.
Der Sender erfährt nur im Erfolgsfall durch ein
Acknowledgement des Empfängers, dass ein oder
mehrere Pakete angekommen sind. Vom Zeitpunkt
des ersten Versendens eines Pakets bis zum Eintreffen des entsprechenden Acknowledgements wird der
Sender die Daten daher im Sendebuffer bereithalten.
Er verwaltet daher ein Send Window: diejenigen Daten, deren Versenden er erwartet. Würden über längere Zeit keine Acknowledgements beim Sender eintreffen, dann würde der Empfänger irgendwann alle Daten innerhalb des Send Window erhalten haben. Das
Receive Window würde dann an der ersten Position
hinter dem Send Window liegen. Wären beide Fenster
in Summe größer als der Bereich der Sequenznummern: 0 . . . 232 − 1, dann könnte ein erneut eintreffendes altes Paket fälschlicherweise als neues Paket erkannt werden, da die Sequenznummern zyklisch gerechnet werden.
Beispiel:
Die Sliding-Window-Technik ist ein zentraler Be• Send Window: 0 . . . 2684354559.
standteil der Datenübertragung mittels TCP. Acknowledgements des Empfängers enthalten stets die Posi• Receive Window: 2684354560 . . . 5368709119
(5368709119 = 1073741823 mod 232 ).
tion des nächsten erwarteten Datenbytes sowie eine
Angabe, wie viele Bytes im Moment angenommen
• Alte Pakete zwischen 0 und 1073741823 würden jetzt
werden können. Der Sender kann dann sicher davon
fälschlicherweise als neue angenommen werden.
ausgehen, dass alle Daten bis zur vorigen Stelle anDie Abbildung 8.2 zeigt schematisch, wie sich das
gekommen sind. Des Weiteren ist er sicher, dass der
Sliding Window durch den zyklischen Bereich der SeEmpfänger die angegebene Menge folgender Bytes
quenznummern (0 . . . 232 − 1) bewegt:
annehmen kann, und kann diese sofort versenden. Abbildung 8.1 zeigt das Sliding Window aus Sicht des
1. Sequenznummer des ersten Datenbytes
Senders.
Ebenso kann der Empfänger auch erneut bis zur
2. Bereits an eine Applikation weitergereichte Dagleichen Stelle bestätigen, aber eine andere Window
ten
Size angeben. Diese Art von Acknowledgement nennt
3. Bestätigte Daten, die im Receive Buffer stehen
man Window Update, da sie nur eine Veränderung, in
aller Regel eine Vergrößerung, der Window Size an4. Erhaltene, aber noch nicht bestätigte Daten
gibt. Besonders zwischen einem sehr schnellen Sender und einem langsamen Empfänger kann es vor5. Freier Platz im Receive Buffer
kommen, dass die Acknowledgements das Fenster zunächst so verkleinern, dass keine weiteren Daten ge6. Aktuelles Receive Window
sendet werden können. Sobald der Inhalt des Empfangsbuffers dann an die Applikation weitergereicht
7. Größe des Receive Buffer
70
8.1. Einführung
8.1.3. Window Scaling
1
2
3
Sequenznummern
4
8
7
5
6
Ursprünglich stehen im TCP-Header nur 16 bit für die
Angabe der Window Size zur Verfügung, also können
maximal 64 kB angegeben werden. Mit schneller werdenden Verbindungen und größeren Empfangsbuffern
wurde es notwendig, auch größere Werte angeben
zu können. Die Lösung des Problems ist ein Skalierungsfaktor, der beim Verbindungsaufbau ausgehandelt wird. Ein gesendeter Wert von R entspricht einer
Skalierung um 2R .
Die Aushandlung des Window Scaling zwischen
zwei TCP-Implementierungen verläuft wie folgt:
• Beide Seiten können in ihren SYN-Segmenten
einen Skalierungsfaktor angeben.
• Verzichtet eine Seite auf die Angabe eines Faktors, dann findet keine Skalierung statt.
Abbildung 8.2.: Zyklisches Verhalten der Sequenznummern.
8. Bewegungsrichtung des Sliding Window.
• Haben beide TCP-Implementierungen einen
Faktor angegeben, so wird Window Scaling angewendet. Jede Seite verwendet für die Angabe
ihres Receive Window den eigenen Faktor. Gibt
also einer 3 und einer 5 als Wert für R im SYNSegment an, dann werden die Angaben des ersten um 23 = 8 und die des zweiten um 25 = 32
skaliert.
Die ursprüngliche Definition von TCP in
RFC 793 [Pos81c] ließ einige Freiheitsgrade,
von denen die meisten in späteren RFCs fixiert
wurden [Bra89, APS99]:
• Gibt eine Seite R = 0 an, also eine Skalierung um
2R = 1, so bedeutet dies, dass sie Window Scaling erlaubt, es für die eigenen Receive-WindowAngaben aber nicht verwenden wird.
• Soll der Empfänger schnellstmöglich Acknowledgements senden, oder noch kurze Zeit auf
weitere Pakete warten?
Ein Maximum von R ≤ 14 muss eingehalten werden, da es sonst zu einem sogenannten wrap around
der Sequenznummern kommen kann. Damit meint
man ein derartiges Überlappen der zyklisch gerechneten Sequenznummern, dass nicht mehr eindeutig zwischen neuen und alten Paketen unterschieden werden
kann. Verschiedene Techniken zur Vermeidung dieses
Problems beinhalteten Timestamps oder time-to-liveZähler in den Paketen.
Es kann theoretisch vorkommen, dass sich Sendeund Empfangsfenster nur noch berühren, etwa wenn
alle entsprechenden Pakete angekommen sind, aber
kein Acknowledgement den Sender erreicht hat. Wären die Fenster so groß, dass sie sich am anderen Ende
überlappen, dann könnte ein dupliziertes altes Paket
fälschlicherweise als neues Paket angenommen werden. Die doppelte Fenstergröße muss also kleiner als
die Anzahl der Sequenznummern sein:
• Wie häufig und ab welcher Größe der Veränderung sollen Window Updates erfolgen?
• Soll der Sender die Daten im nutzbaren Fenster
schnellstmöglich als Burst, oder eher gleichmäßig übertragen?
Manche der Punkte sind erst in konkreten Implementierungen festgelegt, oder können gegebenfalls selbst
gewählt werden.
Die meisten TCP-Implementierungen neigen zu
burstartigem Sendeverhalten. Gerade dieses Verhalten
kann leicht zu Verstopfung des Netzwerks und Paketverlusten führen, wenn das nutzbare Fenster zu viele Datenbytes erlaubt. TCP Vegas hingegen versucht,
dass nutzbare Fenster auf eine Round Trip Time zu
verteilen.
2 · Max_Window = 2 · 216 · 2R < 232
⇒
R
≤ 14.
71
8.2. Congestion Control
MSSs
8. TCP Bulk Data Flow
MSSs
Wenn mehrere Hosts viele Pakete senden, kann es zu
Congestion, d. h. Verstopfung des Netzwerks, kommen. Ebenso ist dies am Übergang von schnellen
zu langsameren Netzwerken möglich. In diesem Fall
speichert ein Router alle im schnellen Netzwerk ankommenden Pakete in einem FIFO-Speicher (Queue),
um sie im langsameren Netzwerk weiterzusenden.
Die Differenz der Bandbreiten ist dann die theoretische Geschwindigkeit, mit der sich der FIFOSpeicher unter Volllast füllt. Ist die Queue voll, so
müssen Pakete gelöscht werden. Der Paketverlust,
z. B. durch einen Timeout bemerkt, ist ein sicheres
RTTs
Anzeichen für Congestion.
(a) Slow Start.
Modernere Implementierungen wie TCP Vegas machen sich zu Nutze, dass die Verweilzeit in der Routerqueue sich bereits in der näherungsweise gemessen
Round Trip Time niederschlägt. TCP Vegas versucht,
durch die RTT-Messungen bereits Paketverluste vorherzuahnen und rechtzeitig die Senderate zu reduzieren. Auf dem Stand von TCP Reno sind die Paketverluste ein benötigtes Anzeichen von Congestion. TCP
Reno versucht konstant die Senderate zu erhöhen, um
frei werdende Kapazitäten schnell zu erkennen. Es
unterscheidet dabei zwischen leichten und schweren
Paketausfällen (Retransmission oder Timeout), auf die
Abschnitt 9.3 näher eingeht.
Diesen Implementierungen gemeinsam ist ein sogenanntes Congestion Window (CWND), das als weiRTTs
tere Beschränkung des Senders dient. Als Größe des
(b) Congestion Avoidance.
Send Window verwendet der Sender das Minimum aus
Receive Window und Congestion Window. Der Sender
verwaltet das Congestion Window je nachdem, wel- Abbildung 8.3.: Verlauf des Congestion Window.
che Vorstellung die Implementierung von der Netzwerksituation hat. In der Art und Weise, wie diese
Vorstellung gewonnen wird, unterscheiden sich die
Wird ein bestimmter Grenzwert, der Slow Start
Implementierungen.
Threshold, erreicht, dann wechselt der Sender zur
Congestion Avoidance.
Ist dieser Grenzwert zu hoch voreingestellt, dann
führt der exponentielle Anstieg der Senderate (solan8.2.1. Slow Start
ge nicht durch das Receive Window beschränkt) oft zu
Slow Start wird üblicherweise zu Beginn einer Über- einem schweren Paketausfall, da mit jeder RTT doptragung oder nach einem größeren Paketverlust (Ti- pelt so viele Pakete gesendet werden. Wird der Slow
meout) angewendet. Das Congestion Window beginnt Start Threshold wiederum zu niedrig gewählt, dann
dabei mit einer Größe von zwei bis drei maximalen wechselt der Sender zu schnell zur Phase CongestiPaketen. Für jedes bestätigte Paket erhöht sich das on Avoidance. In dieser Phase steigt die Größe des
Congestion Window um ein Segment maximaler Grö- Congestion Windows relativ langsam, es würde also
ße. Dies führt zu einer Verdopplung des Congestion zu lange dauern, bis die Möglichkeiten des Netzwerks
Window pro Round Trip Time, also einem exponen- vollständig genutzt werden. Die Folge wäre ein sehr
tiellen Verlauf dieses Wertes. Abbildung 8.3(a) zeigt starker Performanceverlust, da zu Beginn einer Überden Verlauf des Congestion Window in dieser Phase. tragung relativ wenig Daten übertragen werden.
72
MSSs
8.3. Experiment
8.3. Experiment
8.3.1. Idee
RTTs
MSSs
(a) CWND bei Paketverlust im Slow Start.
Zur Veranschaulichung der Techniken zur Vermeidung von Congestion haben wir das folgende Experiment durchgeführt.
Zwei Computer eines Clusters sollten Daten über
eine VPN-Verbindung an einen dritten Computer im
Cluster senden. Dabei wurde die zweite Verbindung
kurz nach der ersten aktiviert, so dass sie zunächst eine relativ ausgelastete VPN-Verbindung vorfand. Dadurch sollten folgende Aspekte aufzeigbar werden:
• Slow Start und Congestion Avoidance einer ungestörten Verbindung sollten sichtbar sein, bevor
die zweite Verbindung ihre Übertragung beginnt.
RTTs
(b) CWND bei schwerem Paketverlust im Slow Start.
Abbildung 8.4.: Verlauf des CWND und Slow
Start Threshold bei Paketverlusten.
8.2.2. Congestion Avoidance
Diese Phase verläuft ähnlich dem Slow Start, und
kommt zur Anwendung bei Erreichen des Slow Start
Threshold. Es existieren verschiedene Varianten für
die Erhöhung des Congestion Window in dieser Phase.
Im allgemeinen erhöht sich das Congestion Window
pro Round Trip Time um einen konstanten Wert, z. B.
ein Segment maximaler Größe. Während der Congestion Avoidance wächst das Congestion Window also
linear, siehe Abbildung 8.3(b).
Solange keine oder nur kleine Paketverluste (Retransmission) auftreten, bleibt der Sender in dieser
Phase. Im Falle einer Retransmission wird das Congestion Window halbiert und der Slow Start Threshold
wird ebenfalls auf diesen Wert gesetzt. Tritt in dieser
Phase ein schwerer Paketverlust auf, so wird der Slow
Start Threshold auf den halben Wert des bisherigen
Congestion Window gesetzt und der Sender beginnt
danach mit einem Slow Start.
Die Abbildungen 8.4(a) und 8.4(b) zeigen mögliche Verläufe des Congestion Window im Zusammenspiel von Slow Start und Congestion Avoidance. Die
dünne graue Linie stellt den Slow Start Threshold dar.
In Abbildung 8.4(a) ist dieser Wert so gewählt, dass
der erste Paketverlust bereits während des Slow Start
passiert. In Abbildung 8.4(b) führt ein zu niedriger
Threshold zu einem schweren Paketverlust während
des Slow Start, und in Folge zu einem erneuten Slow
Start.
• Es sollten Paketverluste auftreten, um die Wiederaufnahme des normalen Sendevorgangs mit
Slow Start oder Congestion Avoidance zu beobachten.
8.3.2. Durchführung
Zunächst wurde ein VPN-Skript im Cluster gestartet. Für die Verbindungen wurden spezielle VPNAdressen der Rechner verwendet, so dass aller Datenverkehr den VPN-Tunnel nutzen musste. Dadurch
war sichergestellt, dass trotz des schnellen GigabitLAN eine Konkurrenzsituation zwischen den beiden
Verbindungen entstehen würde. Der Einfluss anderer
Verbindungen war reduziert, da die VPN-Adressen
gewöhnlich nicht verwendet werden. Die Geschwindigkeit des darunterliegenden Gigabit-LAN lässt eine
Einschränkung des VPN durch Verbindungen außerhalb des VPN ausschließen.
Die Paketströme zwischen den Rechnern wurden
mittels tcpdump auf dem Empfängerrechner aufgezeichnet. Das Tool tcptrace identifizierte die Ströme im dump-File und erzeugte daraus xplot-Files, jeweils zwei pro Verbindung.
8.3.3. Beobachtungen
Die Auswertung der Plots ergab vielfältige Beobachtungen:
• Einen lehrbuchartigen Slow Start zu Beginn der
ersten Verbindung, siehe Abbildung 8.5.
• Den langsamen Start der zweiten Verbindung,
die ein zunächst sehr kleines Receive Window
vom Empfängerrechner angeboten bekam, siehe
Abbildung 8.6.
73
8. TCP Bulk Data Flow
Abbildung 8.5.: Slow Start.
Abbildung 8.6.: Start mit kleinem Receive Window.
74
8.3. Experiment
Abbildung 8.7.: Slow Start nach schwerem Paketverlust.
Abbildung 8.8.: Congestion Avoidance nach leichtem Paketverlust.
75
8. TCP Bulk Data Flow
Abbildung 8.9.: Überblick des Datenstroms vom ersten Rechner.
Abbildung 8.10.: Überblick des Datenstroms vom zweiten Rechner.
76
8.4. Weitere Probleme
• Einen schweren Paketverlust auf der ersten Verbindung dem ein gut erkennbarer Slow Start
folgt, siehe Abbildung 8.7. Die dunkelgrauen
Bereiche stellen Selective Acknowledgments dar.
ge Strecken besteht eine relative hohe Wahrscheinlichkeit für den Verlust mindestens eines Pakets. Ein
Paketverlust via timeout bedeutet allerdings den nachfolgenden Beginn eines Slow Start. Gerade darin liegt
eine großer Perfomanceverlust über LFNs. Glücklich• Einen leichten Paketverlust mit folgender Con- weise wurden viele Techniken entwickelt, die dieses
gestion Avoidance, siehe Abbildung 8.8.
Problem verbessern, etwa Fast Retransmit und Selective Acknowledgements.
Die Abbildungen 8.9 und 8.10 zeigen die Datenströme von den beiden Sendern zum Empfängerrechner.
8.4.2. Silly Window Syndrome
8.4. Weitere Probleme
8.4.1. Long Fat Pipe Networks
Die Performance von TCP hängt nicht nur von der
Bandbreite, sondern auch von der Round Trip Time
ab. Das sogenannte Bandwith-Delay-Product (BDP)
gibt an, wie viele Daten gleichzeitig unterwegs sein
können.
Solange kein Acknowledgement eintrifft, kann der
Sender nur Daten versenden, die im aktuellen Send
Window liegen, also nicht mehr als Window Size
viele Bytes. Die Zeit vom Absenden eines Paketes bis zum Eintreffen des Acknowledgements ist
gerade die Round Trip Time. Ist die Window Size kleiner als das BDP, so ist der Sender regelmäßig im Leerlauf. Der Durchsatz ist dann ungefähr
WindowSize/RT T , der maximale hingegen natürlich
Bandbreite = BDP/RT T .
Das Long-Fat-Pipe-Problem besteht darin, Daten
durch Netzwerke zu senden, die Leitungen mit hoher
Bandbreite und hoher Latenz haben. Aus Sicht von
TCP handelt es sich um eine einzelne lange Direktverbindung mit hoher Bandbreite. Zunächst ist eine
derartige Verbindung problematisch, wenn die Sendeund Empfangsbuffer der verwendeten Hardware nicht
mit dem hohen BDP der Verbindung mithalten können. Wenn genügend Buffer zur Verfügung steht, ist
es notwendig, auch eine entsprechend große Window
Size anzubieten. Als das Problem zuerst erkannt wurde, gab es manch negative Meinung, dass TCP nicht
langfristig mit moderner Netzhardware würde mithalten können. Eine Lösung ergab sich dann durch die
Entwicklung der Window-Scale-Option, die das Anbieten viel größerer Receive Windows erlaubt. Die
nächste limitierende Größe sind vielleicht die nur
32 bit für die Angabe der Sequenznummer im TCPHeader.
Ein weiteres bereits erkanntes Problem mit LFNs
besteht in deren Zusammenspiel mit Congestion Avoidance und Slow Start. Bei großen Windows über lan-
Beim Silly Window Syndrome handelt es sich um ein
eher historisches Problem, das durch moderne TCPImplementierungen weitestgehend vermieden wird.
Die Ursache dieses Problems waren Implementierungen, die auf Empfängerseite frei werdenden Inputbufferplatz sehr zügig mitteilten und Sender, die auch bei
kleinen Verschiebungen des nutzbaren Fensters bereits Segmente verschickten.
Im einfachsten Fall kann es bereits beim Datenverkehr zwischen einem Sender und einem Empfänger auftreten, wenn über längere Zeit konstant Daten übertragen werden. Optimalerweise werden große
Datenpakete aufgeteilt auf maximal große Segmente versendet. Wenn der Sender das angebotene Fenster stets sofort ausnutzt, dann können kleine Vergrößerungen des Receive Window auch in entsprechend
kleinen Paketen resultieren. Diese kleinen Window
Updates können entstehen, wenn andere kleine Pakete, z. B. durch ssh verursacht, versendet werden.
Ebenso ist es möglich, dass die Daten nur langsam aus
dem Receivebuffer an Applikationen weitergereicht
werden. Verhalten sich beide Seite wie oben beschrieben so, dass sie stets sehr schnell reagieren, dann wird
ein kleines Paket meist in einer entsprechend kleinen
Vergrößerung des Receive Window resultieren. Solange noch Daten zu senden sind, wird der Sender dann
wiederum ein kleines Paket versenden, um das Window sofort wieder komplett zu nutzen.
Sehr zügiges Reagieren von Sender und Empfänger
kann also in einer Vielzahl kleiner Pakete resultieren,
obwohl primär große Dateien zu versenden sind. Dieses Verhalten wirkt sich negativ auf die Sendeleistung
aus und hat einen größeren Protokolloverhead, da die
Pakete relativ klein sind. Ebenso wird das Netzwerk
unnötig durch kleine Pakete verstopft, die den Routern nicht weniger Arbeit abverlangen. Das Silly Window Syndrome endet spätestens dann, wenn alle Daten
angekommen sind.
Aktuelle TCP-Implementierungen vermeiden das
Silly Window Syndrome durch verändertes Verhalten
auf Sender- und Empfängerseite.
77
8. TCP Bulk Data Flow
• Der Empfänger versucht, kleine Window Updates zu verzögern, bis die Vergrößerung des Fensters mindestens einen bestimmten Anteil des
Maximalfensters oder mindestens eine MSS beträgt.
• Der Sender wiederum wartet bei großen Dateien, bis er wieder ein Paket maximaler Größe senden kann. Ein solcher Zeitpunkt wird immer eintreten, solange die Verbindung zum Empfänger
noch besteht.
Theoretisch genügt es schon, wenn eine der beiden Implementierungen dieses Verhalten nutzt, um
das Silly Window Syndrome zu vermeiden.
Striktere Varianten für den Empfänger geben stets
ein solches Receive Window zurück, dass der nutzbare Platz im Buffer stets ein ganzes Vielfaches eines
MSS ist. Dies kann auch bedeuten, dass der Sender
keine weiteren Daten senden kann, da sein nutzbares
Fenster leer ist. Auf diese Weise ist der Sender meist
in der Lage, Segmente maximaler Größe zu senden.
8.5. Abschließendes
Die Problematik des Übertragens großer Datenmengen mittels TCP hat die Vermeidung von Netzwerkverstopfungen als zentralen Bestandteil. Die dafür
verwendeten Techniken sind viel erforscht und verbessert worden. Das Ziel dabei ist es, die gegebene Hardware maximal gut auszunutzen. Daher haben Implementierungen mit ausgefeilter CongestionVermeidung im Schnitt bessere Übertragungsraten.
Erforscht werden auch Interaktionen verschiedener
Implementierungen hinsichtlich Fairness und gegenseitiger Beeinflussung.
TCP Vegas fügt den in diesem Kapitel aufgeführten
Ansätzen noch einige Ideen, wie die erweiterte Einbeziehung der Round Trip Time, hinzu. Es wird trotz der
beschränkten Sicht von TCP versucht, eine gewisse
Vorhersage zu treffen, die in die Wahl der CongestionWindow-Größe, und damit indirekt der Übertragungsrate, einfließt. Eine Beschäftigung mit den Grundideen von TCP Vegas ist insofern geeignet, den Inhalt
dieses Kapitels zu vertiefen.
78
9. TCP – Timeout und Retransmission
Tino Mai
9.1. Einleitung
In heterogenen Netzwerken, in dem viele Teilnehmer mit unterschiedlichen Eigenschaften verbunden
sind, ist die Möglichkeit eines Paketverlustes allgegenwärtig. Nicht für jede Übertragung ist dies unproblematisch. Eine Dateiübertragung beispielsweise
sollte als Ergebnis eine Datei liefern, die dem Original entspricht. Kommt es während der Übertragung
zu Paketverlusten, dann ist die Datei im günstigsten
Fall partiell unlesbar, wahrscheinlich aber gänzlich
unbrauchbar. Um dies zu verhindern, gilt es, einen
Paketverlust zu erkennen und das verloren gegangene Paket erneut zu übertragen.
Im Gegensatz zum Internet Protocol (IP), handelt es sich bei dem Transmission Control Protocol
(TCP) um ein verbindungsorientiertes Protokoll, welches zuverlässige Dienste für Anwendungen bereitstellt. TCP bietet eine Fehlerkontrolle für Anwendungsdaten durch erneutes Übertragen von fehlerhaften oder verloren gegangenen Segmenten, eine Flusskontrolle zur Koordinierung der Kommunikation zwischen Sender und Empfänger und einer Überlastkontrolle, um eine Überflutung durch Datenwiederholung zu vermeiden. Damit bietet uns TCP genau das,
was wir wünschen: eine robuste Übertragung von Daten. Zur Realisierung dieser Eigenschaften verwendet
TCP Timer.
9.2. TCP Timer
Die Verwendung von Timern ist die einzig effektive
Möglichkeit, da zum Beispiel die Unkontrollierbarkeit des Transportmediums ein direktes Austauschen
von Statusmeldungen zwischen Sendern und Empfängern (zum Beispiel ICMP) nicht ermöglichen. Die
Verwendung von ICMP-Nachrichten wäre sehr wohl
möglich, aber nicht zweckdienlich, da für ICMPPakete genau das gilt, was für TCP-Pakete auch gilt:
Die Zustellung kann nicht garantiert werden. Mittels
eines Timers kann dieses Problem elegant umgangen
werden. Parallel zu einer zu überwachenden Aktion
wird ein Timer gestartet. Wird die Aktion bis zum
Ablauf des Timers durch den Empfänger nicht bestätigt, dann gilt sie als gescheitert. Ob die Ursache nun
beim Kommunikationspartner oder beim Medium zu
finden ist, ist dabei unerheblich, da nicht entscheidbar. Einige Timer, die für das Funktionieren von TCP
unerlässlich sind, wollen wir genauer betrachten. Eine
Übersicht dieser Timer ist in Tabelle 9.1 gegeben.
9.2.1. Connection Establishment
Timer
Im Gegensatz zu IP ist TCP verbindungsorientiert.
Beim Öffnen einer TCP-Verbindung tauschen Sender und Empfänger Kontrollinformationen aus, die sicherstellen, dass der jeweilige Partner existiert und
Daten annehmen kann. Diese Art des Austausches
heißt Drei-wege-Handschlag. Wird der Handshake
nicht innerhalb des Connection Establishment Timeout erfolgreich durchgeführt, so gilt der Verbindungsaufbau als gescheitert.
9.2.2. Delayed Acknowledgement
Timer
Zur Entlastung des Netzwerkes muss TCP nicht
nach jedem empfangenen Segment ein ACK (Acknowledgement) senden. Normalerweise sendet TCP
ein ACK, nachdem es zwei Segmente mit maximaler Größe empfangen hat. Werden weniger Daten empfangen, sendet TCP spätestens nach Ablauf
des Timers ein ACK. Dieses ACK bezeichnet man
dann als Delayed Acknowledgement (siehe auch Abschnitt 6.4.2). Der RFC 1122 [Bra89] definiert 500 ms
als Timer, typisch sind Werte von 200 ms. Problematisch sind Delayed ACKs, wenn der Sender kleine
Datenmengen sendet und dann auf ein ACK wartet.
Dann entstehen in der Kommunikation immer wieder
Pausen von der Laufzeit des Timers.
79
9. TCP – Timeout und Retransmission
Timer
Wert
Funktion
Connection Establishment
ca. 75 s
Delayed Acknowledgement
ca. 200 ms
Keep Alive
ca. 45 s
Idle
ca. 360 s
TCP Persist
ca. 5 s
Maximum Segment Life Wait
ca. 30 s
Retransmission
dynamisch
Zeitfenster, in dem der Drei-Wege-Handschlag erfolgt sein
muss.
Werden weniger Daten empfangen als maximal möglich wäre, sendet TCP erst spätestens nach Ablauf des Timers ein
ACK.
Überprüft den Zustand der Gegenseite durch Senden eines
Paketes.
Bricht die Verbindung nach Ablauf ab, wenn der KeepAlive-Timer keine Antwort erhalten hat.
Überprüft die Gegenseite durch Senden eines Minipaketes,
wenn das Empfangsfenster gleich null ist.
Gibt Ports nach Abbau einer Verbindung erst nach Ablauf
des Timers wieder frei.
Veranlasst die Wiederholung eines Segments nach Ablauf
des Timers.
Tabelle 9.1.: Typische Werte von TCP-Timern in der Praxis.
9.2.3. Keep Alive Timer und Idle
Timer
9.2.5. Maximum Segment Life Wait
Timer
Hier handelt es sich um zwei nicht in der TCPSpezifikation vorgesehene Timer, die aber in UNIXSystemen implementiert sind. Beide stehen miteinander in Verbindung. Der Keep Alive Timer bewirkt,
dass in regelmäßigen Zeitabständen ein leeres Paket
abgeschickt wird, um das Bestehen der Verbindung
zum Partner zu überprüfen. Antwortet der Partnerrechner nicht, wird die Verbindung nach Ablauf des
Idle Timer abgebrochen. Eine Applikation aktiviert
diese Timer mit der KEEP_ALIVE-Option über die
Socket-Schnittstelle. Die Dauer der Timer ist implementationsabhängig und kann daher von System zu
System verschieden sein kann.
Jede Möglichkeit der Verwechslung von Verbindungen sollte verhindert werden. Daher werden nach
dem Abbau von TCP-Verbindungen Portnummern
erst wieder freigegeben, wenn eine bestimmte Zeitspanne, die zweimal die Maximum Segment Lifetime
(MSL) beträgt, vergangen ist (vergleiche dazu auch
Abschnitt 7.3.1). Der Anwender bemerkt diese Wartezeit, wenn er eine Verbindung zwischen gleichen
Partnern (d. h. gleichen IP-Adressen und Portnummern) sofort nach dem Abbruch wieder eröffnen will.
Das System teilt ihm dann mit, dass die verwendete Portnummer noch belegt ist. Erst nach Ablauf des
Timers ist ein erneuter Verbindungsaufbau möglich,
um verspätet eintreffende Pakete nicht irrtümlich einer falschen Verbindung zu zuzuordnen.
9.2.4. TCP Persist Timer
Beim Austausch von Daten über TCP ist es im Prinzip möglich, dass das Empfangsfenster gerade auf 0
steht (vgl. Abschnitt 8.1.2) und genau in diesem Moment das Paket verloren geht, das das Fenster wieder öffnen sollte. Als Ergebnis warten dann Sender
und Empfänger unendlich lange aufeinander. Ein Gegenmittel dazu ist der Persist Timer, der in bestimmten Zeitabschnitten kleine TCP-Segmente der Größe
1 Byte verschickt und damit überprüft, ob die Empfängerseite wieder bereit ist. Ist das Empfangsfenster
nach wie vor 0, kommt eine negative Quittung zurück.
Ist es größer, können nach der positiven Quittung weitere Daten gesendet werden.
80
9.2.6. Retransmission Timer
Der Empfänger bestätigt dem Sender den Empfang
eines Datenpaketes über die Acknowledgement Number. Da diese Nummer mit jedem empfangenen Paket um eins steigt, können auch mehrere empfangene TCP-Segmente durch Angabe der letzten Nummer bestätigt werden. Der Sender startet nach dem
Senden eines Paketes immer einen Retransmission Timer. Wird der Empfang eines Paketes bis zum Ablauf des Timers nicht bestätigt, so wird dieses erneut
verschickt. Abbildung 9.1 zeigt das prinzipielle Funktionieren des Timers. Der Timer wird der Geschwin-
9.3. TCP Retransmission
Zeit
Round Trip Time
Retransmission Timeout
Sender
Empfänger
Abbildung 9.1.: Prinzipieller Ablauf des Retransmission via Timeout.
digkeit der Datenübertragung angepasst und hat somit
keinen festen Wert, sondern ist dynamisch.
9.3. TCP Retransmission
Ein grundlegendes Problem ist, festzustellen, wann
es sich um Congestion handelt und wann nicht. Bekommt der Sender keine Bestätigung für ein versendetes Paket – muss er dann davon ausgehen, dass das
Netz überlastet ist? Oder befindet es sich noch auf
dem Weg und braucht nur länger? Oder ist das Paket
verloren gegangen? Wie lange gibt man einem Paket
Zeit, das Netz zu durchqueren? Und wie lange wartet
man, bis man das Paket noch einmal sendet?
Der Sender muss abschätzen, wann er davon ausgehen kann, dass das Paket verloren gegangen ist und
noch einmal gesendet werden muss. Sendet er das Paket zu früh, befindet sich das alte Paket noch im Netz
und wird unnötig erneut übertragen. Werden Pakete
häufig unnötig erneut übertragen, so provoziert er eine Congestion. Wartet er zu lange, leidet die Übertragungsrate. Ein Timer, dessen Zeitscheibe dynamisch
während der Übertragung der Netzsituation angepasst
wird, ist hier das zentrale Element. Es ist der Retransmission Timer.
das Paket neu gesendet (Retransmission). Grundlage
zur der Berechnung dieses Timers ist die Round Trip
Time (RTT) eines Pakets. Das ist die Zeit, die ein Paket braucht, um vom Sender zum Empfänger zu gelangen plus die Zeit, die das Acknowledgement zurück braucht. Doch da man nicht weiß, welche Route ein Paket durch das Netz nimmt, ist es unmöglich
vorherzusagen, wie lange ein Paket benötigt. Außerdem variiert die Dauer je nach aktueller Belastung
des Netzes. Sie muss also geschätzt werden. TCP benutzt hierfür einen adaptiven Algorithmus. Der Timer
wird im Verlauf der Verbindung ständig verändert und
passt sich der aktuellen Gegebenheiten des Netzes an.
Der Sender verwaltet zur Berechung des Timers
zwei Variablen: Die Smoothed Round Trip Time
(SRTT – geglättete Rundenzeit) und die Round-TripTime Variation (RTTvar – Varianz der Rundenzeiten).
Bevor die erste Rundenzeit gemessen werden kann,
wird das Retransmit Timeout Interval auf drei Sekunden (empirisch) gesetzt. Nach Messung der ersten
Rundenzeit wird die SRT T auf die gemessene Rundenzeit gesetzt und die Varianz auf die Hälfte der
Rundenzeit:
SRT T ← gemessene Rundenzeit
gemessene Rundenzeit
2
Das Retransmit-Timeout-Interval wird dann auf
RT T var ←
RT O ← SRT T + K · RT T var
gesetzt. K ist hierbei ein Faktor als Sicherheitsspielraum, der auf Erfahrungen beruht und in den meisten
Implementierungen auf vier gesetzt. Fortan wird die
Rundenzeit der Pakete kontinuierlich gemessen und
nach jeder Messung werden die Werte wie folgt gesetzt:
RT T var ← (1 − β) · RT T var + β · |SRT T − RT T |
SRT T ← (1 − α) · SRT T + α · RT T
RT O ← SRT T + K · RT T var
α und β sind hier Erfahrungswerte. Jacobson hat folgende Werte vorgeschlagen: α = 1/8 und β = 1/4
[Jac88]. Eine ausschlaggebende Beobachtung bei der
Berechung der Varianzen der Rundenzeiten war, dass
bei starker Belastung des Netzes die Rundenzeiten
stark variieren. Ein Lösungsansatz war, die Standard9.3.1. Retransmission via Timeout
abweichung der Rundenzeiten in die Berechnung mit
Die Zeit zwischen Versenden und Neuübertragung einfließen zu lassen. Allerdings ist die Berechnung
wird Retransmit Timeout Interval (RTO) genannt. Für der Standardabweichung für jedes Paket zu aufwenjedes gesendete Paket wird ein Timer mit dieser Zeit- dig. Daher ist die Berechnung der mittleren Abweischeibe neu gestartet. Läuft er ab (Timeout), wird chung (|SRT T − RT T |) sinnvoller.
81
9. TCP – Timeout und Retransmission
Die Praxis hat gezeigt, dass sich so berechnet ein
realistischer Wert für den Timer ermitteln lässt, der
auch resistent gegen Veränderungen der Netzauslastung ist. Gleichzeitig ist der Timer ein sehr guter Indikator für Congestion, da man mit hoher Wahrscheinlichkeit sagen kann, dass es bei einem Timeout um ein
Anzeichen für Überlastung des Netzwerkes handelt.
9.3.2. Fast Retransmit
Außer dem Retransmission-Timout gibt es einer weitere Möglichkeit, eine Retransmission zu initiieren:
den Erhalt dreier Duplicate-ACKs. Im Acknowledgement des Empfängers wird mit Hilfe der Sequenznummer codiert, welches Paket er als nächstes erwartet. Ein Duplicate-ACK ist ein Hinweis, dass der
Empfänger ein Datenpaket out-of-order erhalten hat.
Das heißt, er hat ein Paket erhalten, dessen Sequenznummer nicht der erwarteten Nummer entspricht.
Daraufhin schickt der Empfänger die Bestätigung des
letzten erhaltenen Pakets noch einmal und teilt dadurch dem Sender die Lücke und die Sequenznummer
des fehlenden Pakets mit. Drei solcher Hinweise sind
für den Sender ein sicheres Signal, dass das Paket verloren gegangen sein muss. Allerdings zeigt dies auch,
dass offensichtlich noch Datenpakete übermittelt werden, sonst würde der Empfänger keine ACKs generieren.
Ohne Fast Retransmit werden nach Ablauf des
Retransmission-Timers das verloren gegangene Datenpaket und alle nachfolgenden Datenpakete im Sendefenster neu übertragen. Dies bedeutet aber einerseits eine unnötige Belastung der Netzwerkressourcen, da alle nachfolgenden Datenpakete auch noch
einmal übertragen werden müssen und andererseits
ein unnötiger Zeitverlust, da bis zum Timeout mit der
Neuübertragung gewartet wird, obwohl schon nach
den dritten Duplicate-ACK klar ist, dass das Paket
verloren gegangen ist. Durch Fast Retransmit wird das
verloren gegangene Paket erneut versendet, ohne auf
das Ablaufen des Timers zu warten.
Obwohl der Fast-Retransmit-Algorithmus das verloren gegangene Paket noch einmal sendet, würde
nach Ablauf des Timers ein Slow Start ausgeführt
werden, bei dem auch die bestätigten Pakete innerhalb des Fensters noch einmal gesendet werden. Daher steuert nach der Fast Retransmission der Fast Recovery Algorithmus nach RFC 2001 [Ste97] die Übertragung. Fast Retransmit und Fast Recovery werden
meist wie folgt implementiert:
• Sobald das dritte Duplicate ACK empfangen
wurde, wird der Threshold auf die Hälfte der
82
noch ausstehenden Segmente des Sendefensters
gesetzt (maximal die Hälfte des Congestion Window):
ssthresh =
# ausstehende Pakete
2
• Das verloren gegangene Paket wird erneut übermittelt und das Congestion Window neu gesetzt:
cwnd = ssthresh + 3 · SMSS
Dies entspricht den drei Segmenten, die durch
Duplicate ACKs bestätigt wurden und vom Empfänger gepuffert werden.
• Für jedes weitere empfangene Duplicate ACK
wird das Congestion Window um ein SMSS erhöht (inflating):
cwnd = cwnd + SMSS
Da der Sender durch das Duplicate ACK weiß,
dass das gesendete Paket das Netzwerk verlassen hat, kann er ein weiteres Paket senden. Da
aber das verloren gegangene Paket noch nicht
bestätigt wurde, gleiten die nachfolgenden Pakete nicht aus dem Fenster. Daher wird es jedes
Mal um ein Segment erhöht.
• Dann kann ein neues Segment übermittelt werden, sofern es das Congestion Window und das
Empfängerfenster zulassen.
• Sobald der Sender ein neues ACK erhält, also
kein Duplicate ACK, wird das Congestion Window wieder auf die Größe des Schwellwertes gesetzt (deflating):
cwnd = ssthresh
Durch dieses erste, neue ACK sollten das verloren gegangene Paket und die anschließend empfangenen Pakete korrekt bestätigt werden.
Abbildung 9.2 zeigt Fast Retransmit in der Praxis.
Interessant sind hier die ACKs mit der Sequenznummer 13032. Offensichtlich bemerkt der Client, dass
das Segment der Sequenznummer 13032 verloren gegangen sein muss. Er beginnt darauf hin Duplicate
ACKs zu senden. Bereits nach dem Eintreffen des
zweiten ACKs mit der Sequenznummer 13032 überträgt der Sender das Paket erneut, da er bereits davon ausgeht, dass das Paket verloren gegangen oder
fehlerhaft ist. Das Sequenzdiagramm ist einer FTPDateiübertragung entnommen, bei der eine große Datei über ein Weitverkehrsnetz verschoben wurde.
9.3. TCP Retransmission
Abbildung 9.2.: Fast Retransmit in der Praxis.
83
9. TCP – Timeout und Retransmission
9.4. Verbesserungen für
WLAN-Netzwerke
WLANs, basierend zum Beispiel auf IEEE 802.11,
GPRS (General Packet Radio Service) oder UMTS
(Universal Mobile Telecommunications System),
stellen nahtlose Konnektivität für tragbare Systeme
zur Verfügung. In WLANs kann es jedoch auch, abhängig von den Bedingungen im Netzwerk, den Signalstärken, elektromagnetischen Interferenzen und
Standortveränderungen der mobilen Systemen, zu
hohen Paketverlusten kommen. Regelmäßige TCPTimeouts und Neuübertragungen können den traditionell ohnehin schmalen Datendurchsatz in solchen
Umgebungen drastisch verschlechtern. In der Praxis
gibt einige Erweiterungen der klassischen Implementierung, um diesen Effekten entgegen zu wirken.
9.4.1. NewReno-Modifikation des
Fast Recovery
Der Fast-Recovery-Agorithmus basiert auf dem
Reno-Algorithmus, der die Datenmenge, die ein Sender bei der Neuübermittlung eines Segments verschicken kann, verringert. Der Reno-Algorithmus funktioniert bei einzelnen verlorenen Segmenten zwar
hervorragend, dies gilt jedoch nicht mehr, wenn
mehrere Segmente verloren gehen. Der NewRenoAlgorithmus [FH99] ermöglicht einen höheren Datendurchsatz. Er ermöglicht Empfangsbestätigungen
für Teile der erfolgreich empfangenen Daten.
basis und überwacht eingehende Empfangsbestätigungen. So kann beim Verlust von mehreren Segmenten eine schnellere Wiederherstellung durchgeführt
werden.
9.4.4. Forward RTO-Recovery
(F-RTO)
Falsche Neuübertragungen (Retransmissions) von
TCP-Segmenten können zum Beispiel dann auftreten, wenn die RTT plötzlich und nur temporär steigt.
Wenn dies passiert, dann fangen die RTOs (Retransmission Timeouts) bereits gesendeter Pakete an abzulaufen. TCP beginnt daher, sie neu zu übertragen.
Wenn dies kurz vor dem Versenden von Daten mit
der Größe eines kompletten Empfangsfensters passiert, kann der Sender das gesamte Fenster erneut
versenden. Der F-RTP-Algorithmus [SK05] verhindert falsche Neuübertragungen. Er geht dabei folgendermaßen vor: Wenn die RTO mehrerer Segmente abläuft, dann überträgt TCP nur das erste Segment neu. Wenn die erste Empfangsbestätigung eingeht, dann fängt TCP an, neue Segmente zu übertragen (wenn dies durch die angegebene Fenstergröße
möglich ist). Wenn die nächste Empfangsbestätigung
einen Timeout für weitere Segmente anzeigt und diese nicht neu übertragen wurden, dann erkennt TCP,
dass der Timeout falsch ist und überträgt die Segmente auch nicht erneut. Dieses Verhalten führt dazu, dass
ein plötzliches Steigen der RTT (zum Beispiel, wenn
ein WLAN-Client von einem Access Point zu einem
anderen wechselt) nicht zu unnötigen Neuübertragungen führt.
9.4.2. Erweiterung der SACK-Option
Selective Acknowledgements (SACK) wurde in
RFC 2018 [MMFR96] definiert und ermöglicht es
dem Empfänger, bis zu vier nicht aufeinander folgende Datenblöcke zu erkennen. RFC 2883 [FMMP00]
definiert eine weitere Verwendung der SACK-TCPFelder. Mit ihr werden doppelte Pakete bestätigt.
Der Sender kann so bei Paketen mit SACK-Option
erkennen, wenn ein Segment unnötig neu übertragen wurde. Er kann dies dann bei zukünftigen
Übertragungen berücksichtigen.
9.4.3. SACK-basierter
Loss-Recovery-Algorithmus
RFC 3517 [BAFW03] definiert ein Verfahren, bei
dem Pakete bei doppelten Empfangsbestätigungen
wiederhergestellt werden können. Der TCP/IP-Stack
verfolgt die SACK-Informationen auf Verbindungs-
84
9.5. SYN-Flood-Angriff
Denial-of-Service-Angriffe zielen darauf ab, legitimen Nutzern den Zugriff auf einen Dienst zu verwehren. Im einfachsten Fall überflutet der Angreifer
den Server mit sinnlosen Paketen, um seine Leitungen zu überlasten. Ein typisches Beispiel dafür ist
ICMP-Flooding. Dies erfordert jedoch einerseits eine große Bandbreite auf Seiten des Angreifers, andererseits lassen sich die Pakete vergleichsweise einfach
mittels vorgelagerten Systemen ausfiltern. Alternativ
kann er versuchen, beispielsweise einen Webserver so
mit Anfragen zu torpedieren, dass normale Anwender
nicht mehr zum Zug kommen. Doch auch hier ist eine
große Bandbreite erforderlich und die IP-Adresse des
Angreifers ist schnell ermittelt und dann blockiert.
Deshalb verlagern sich immer mehr Angriffe auf
sogenannte SYN-Flood-Attacken, die nicht darauf ab-
9.6. Zusammenfassung
zielen, die Bandbreite auszulasten, sondern die Systemressourcen des Servers selbst blockieren. Dazu
verschicken sie SYN-Pakete an den TCP-Port des
Dienstes. Der Server registriert den Synchronisierungswunsch des Clients, legt einen Eintrag in seinen
Tabellen dafür an und bestätigt die Anfrage mit einem
eigenen Synchronisierungspaket (SYN/ACK). Bei einem normalen Verbindungsaufbau bestätigt der Client
dieses ebenfalls mit einem ACK-Paket und komplettiert damit den Drei-Wege-Handschlag einer TCPVerbindung.
Bei einer SYN-Flood-Attacke unterbleibt die Übermittlung des letzten ACK-Paketes. Nun unterhält der
Server eine halboffene Verbindung. Der wartet eine
Zeitlang und wiederholt sein SYN/ACK-Paket, in der
Annahme, das erste sei verloren gegangen (Retransmission). Statt einer Antwort kommen jedoch nur
weitere Verbindungsanfragen, die der Server ebenso
behandelt. Er speichert alle SYN-Anfragen in einem
speziellen Puffer, der sogenannten Backlog Queue. Ist
diese voll, kann er auf diesem Port keine Verbindungen mehr annehmen und das Systen verwirft weitere
SYN-Pakete – der Dienst ist nicht mehr zu erreichen.
Bis der Server einen einmal angelegten Eintrag
in der Backlog-Queue wieder löscht, weil er keine Antwort bekommt, können mehrere Minuten vergehen. Nach einem ersten Timeout, typischerweise
nach 3 s, nimmt der Server an, sein SYN/ACK-Paket
sei verloren gegangen und schickt es erneut. Dieser Vorgang wiederholt sich mit immer längeren Timeouts mehrfach (Linux: 5 Retransmissions). Auf
einem Standard-Linux-System bietet die BacklogQueue Platz für 256 solcher halboffenen Verbindungen. Der Angreifer hat also mehr als genug Zeit, diese
mit Anfragen zu füllen.
In der Regel verwendet der Angreifer gefälschte
Absenderadressen für die SYN-Anfragen. Daher bekommt er die Antwortpakete des Servers zwar nicht
zu sehen, aber durch geschicktes Verteilen der Adressen kann er ein Filtern der Angriffspakete verhindern.
Ein vorgeschalteter Router ist nicht in der Lage, die
gefälschten Pakete von echten Verbindungswünschen
zu unterscheiden.
sendete Paket startet der Sender einen Retransmission
Timer und überwacht deren Ablauf. Wird das Paket
durch den Empfänger nicht durch ein ACK während
dieses Zeitfensters bestätigt, so versucht der Sender
eine erneute Übertragung. Da der Weg eines Paketes
durch ein Netz und die Auslastung des Netzes eine unbekannte Größe ist, verwendet TCP einen adaptiven
Algorithmus zur Bestimmung des Timeout, um möglichst die aktuellen Gegebenheiten eines Netzes zu berücksichtigen. Dem Ablauf des Timers kann der Empfänger vorgreifen, in dem er drei Duplicate-ACKs an
den Sender übermittelt. Erkennt der Empfänger einen
Fehler in der Übertragung, so kann er mittels dieses
Fast Retransmit genannten Mechanismus’ eine Neuübertragung erzwingen.
In der Realität unterliegt die tatsächliche Implementierung der TCP Retransmission ständigen Veränderungen, die zum Teil der Praxis entstammen. Neue
Techniken, wie 10 Gbit/s-Ethernet oder WLAN, lassen eine kontinuierliche Nutzung einer Implementierung nicht zu, sondern verlangen eine stetige Anpassung.
9.6. Zusammenfassung
Zur Realisierung zuverlässiger Dienste für Anwendungen stellt TCP unter anderem einen Mechanismus
bereit, der für verloren gegangene Pakete eine Neuübertragung ermöglicht. Dieser Mechanismus ist ein
Zusammenspiel aus dem Retransmission Timer beim
Sender und ACKs durch den Empfänger. Für jedes ge-
85
Teil III.
Anwendungsschicht
10. Domain Name System (DNS)
Ferdinand Zirker
10.1. Einführung
10.1.1. Motivation
Jeder, der einmal eine E-Mail verschickt oder im
WWW gesurft hat, hat es – meist ohne es zu bemerken
– schon benutzt: das Domain Name System (DNS).
Das DNS ist die meist genutzte, größte und verteilteste Datenbank der Welt. Applikationen wie E-MailClient und Webbrowser verbergen den DNS-Zugriff
vor dem Benutzer. Deshalb ist vielen die Bedeutung
des DNS für das Internet unbekannt.
Dieses Kapitel soll erklären, was das DNS ist, wie
es entstand, welche Konzepte es einführt, welches
Format DNS-Nachrichten haben und wie DNS Software arbeitet.
Abbildung 10.1.: DNS-Protokoll im TCP/IPProtokollstapel.
liche Werte. Bei der Vielzahl der Rechner, mit denen
ein Internet-Nutzer heutzutage kommuniziert, stößt
das menschliche Gedächtnis schnell an seine Grenzen. Abhilfe schafft ein Namensdienst, denn Menschen merken sich Namen wesentlich besser als Zahlenkolonnen. Ein zweiter Vorteil eines Namensdienstes ist, dass Änderungen auf der niedrigen Abstrak10.1.2. Was ist das DNS?
tionsebene der IP-Adresse nach oben hin verschleiDas DNS ist eine verteilte Datenbank, die verschie- ert werden können. Ein weiterer Vorteil ist, dass eine
dene Informationen mit Namen assoziiert. Ein Da- rudimentäre Lastverteilung möglich wird, da einem
tensatz heißt Resource Record (RR). Die RRs sind Namen auch mehrere IP-Adressen zugeordnet werden
über tausende, hierarchisch angeordnete Computer, können
Der erste Namensdienst im Internet bestand in eisogenannte Nameserver, verteilt. Um einen RR zu lesen, wird ein Nameserver von einem Resolver ge- ner auf allen teilnehmenden Rechnern gespeicherten
nannten Client angesprochen. Die Kommunikation Datei namens HOSTS.TXT, in welcher Namen und
zwischen Client und Server erfolgt dabei gemäß ei- zugehörige IP-Adresse aufgelistet waren. Bis heute
nes DNS-eigenen Nachrichtenprotokolls. Dieses be- schlagen Programme lokale Zuordnungen von Namen
findet sich auf der Anwendungsschicht des TCP/IP- zu IP-Adressen in dieser Datei nach. Um damals auf
dem aktuellen Stand zu bleiben, musste man sich die
Protokollstapels, siehe Abbildung 10.1.
Der am häufigsten abgefragte Informationstyp ist neueste Version der Datei von einem zentralem FTPdie IP-Adresse. Das DNS wandelt also meist einen Server des Stanford Research Institute (SRI) herunNamen (z. B. ‘www.uni-jena.de’) in die ihm zugeord- terladen, bzw. dem SRI seine neuen oder geänderten
Namen-IP-Adresse-Paare mitteilen. Ein derart zentranete IP-Adresse (z. B. 141.35.1.50) um.
ler Namensdienst war jedoch nicht mit dem exponentiellen Wachstum des Internets zu skalieren. Die FTP10.1.3. Entstehung des DNS
Last wurde zu groß und Mitarbeiter des SRI waren
Um mit einem Rechner, wie z. B. einem Webserver, nur noch damit beschäftigt, die vielen Änderungen
über das Internet zu kommunizieren, braucht man und Neueintragungen vorzunehmen. Außerdem daudessen IP-Adresse. Ein Internet-Nutzer muss also für erte es recht lange, bis eine Änderung bei den anderen
jeden Kontakt eine 32 bit (mit IPv6 sogar 128 bit) lan- Teilnehmern sichtbar wurde.
ge Zahl wissen. Das sind mehr als 4 Milliarden mög1984 spezifierte Paul Mockapetris in den RFCs 882
89
10. Domain Name System (DNS)
und 883 [Moc83a, Moc83b] das DNS. Designziele
waren Verteilung der Information und ihrer Verwaltung bei gleichzeitiger Konsistenz des Datenbestandes, Unabhängigkeit vom zu Grunde liegenden Kommunikationssystem, Flexibilität in der Art der zu speichernden Information und schließlich Erweiterbarkeit. Sicherheit stand leider nicht von Anfang an mit
auf der Liste. Der Namensdienst, den das DNS bietet, ist vielseitiger und vor allem dezentraler als sein
Vorgänger. 1987 wurden die beiden RFCs verfeinert
und durch RFCs 1034 und 1035 [Moc87a, Moc87b]
ersetzt.
ten hat ein Label und steht für einen Domainnamen, der sich aus den Knotenlabeln auf dem Pfad
zur Wurzel ergibt. Die Label werden dabei durch
einen Punkt voneinander getrennt. Brüderknoten dürfen keine gleichen Label haben. Der Wurzelknoten
hat als einziger ein leeres Label (Länge 0).
Eine Domain wird durch einen Domainnamen
identifiziert und besteht aus dem Teil des Namensraums, der sich unterhalb des zum Domainnamen gehörenden Knoten befindet. Eine Domain ist Subdomain einer Domain, wenn sie in ihr enthalten ist. In
diesem Falle endet der Subdomainname auf den Domainnamen. Die Begriffe Domain und Domainname
werden häufig falsch verwendet.
10.2. Konzepte
Das in einem Domainnamen ganz rechts stehende
Label (erste Ebene des Baumes) ist seine Top Level
Domain (TLD). Domains mit einer country code TLD
10.2.1. Lexikalischer Aufbau eines
(ccTLD), heißen Country Domains oder GeographiNamens
cal Domains. Die Labels der ccTLDs sind die LänIm DNS heißt ein Name Domainname und ist in bis derkürzel aus dem ISO-Standard 3166 [Int06a]. Dozu 127 Teile strukturiert. Die Teile werden Label ge- mains mit einer generic TLD (gTLD) heißen Generic
nannt und durch einen Punkt voneinander getrennt. Domains. Ursprünglich waren es nur sieben (‘com.’,
Domainnamen mit mehr als vier Label kommen aber ‘edu.’, ‘gov.’, ‘int.’, ‘org.’, ‘mil.’, ‘net.’), aber die Innur selten vor.
ternet Corporation for Assigned Names and Numbers
Ein Label ist
(ICANN) führt hin und wieder weitere ein (‘aero.’,
‘biz.’, ‘coop.’, ‘info.’, ‘jobs.’, ‘museum.’, ‘name.’,
• eine 1 bis 63 Zeichen lange Zeichenkette
‘pro.’, ‘travel.’, . . . ). Die gTLDs ‘gov.’ und ‘mil.’ sind
• aus alphanumerische Zeichen (bei Vergleichen den USA vorbehalten, nicht so ‘com.’, ‘org.’ und algelten Großbuchstaben und Kleinbuchstaben als le anderen – trotz gegenteiliger landläufiger Meinung.
Manche Länder unterstrukturieren ihre TLD. So engleich) und Bindestrich,
den z. B. im Vereinigten Königreich die Domainnawobei das erste Zeichen ein Buchstabe sein muss, was men von Unternehmen auf ‘co.uk.’ und die von Bilbisweilen missachtet wird.
dungseinrichtungen auf ‘ac.uk.’. Eine Sonderrolle hat
Ein vollständig qualifizierter Domainname, zu eng- die TLD ‘arpa.’ inne. Sie wird nur für die Inverssuche
lisch Fully Qualified Domain Name (FQDN), darf und die Lokalisierung von Gateways verwendet.
höchstens 255 Zeichen haben und endet auf einen
Punkt. Ein Beispiel für einen FQDN ist ‘ipc654.inf10.2.3. Zonen
ra.uni-jena.de.’, aber auch ‘de.’ ist ein FQDN. Durch
den Endpunkt wird ein FQDN von einem Namen un- Der Namensbaum ist in Zonen unterteilt. In Abbilterschieden, an den eventuell noch ein konfigurations- dung 10.3 sind einige Zonen umrandet. Eine Zone ist
abhängiges Suffix (Domainname des lokalen Netz- eine (großteils zusammenhängende) Menge von Dowerks) angehängt wird. Ohne den Endpunkt ist ein mainnamen mit mindestens zwei Nameservern und
Name nicht eindeutig, denn je nach Konfiguration der eigenständiger Verwaltung. Die Verwaltung ist zubenutzten Applikation und des Resolver kann er zu ständig für die Zonendatei, in der alle RRs der Dounterschiedlichen FQDNs ergänzt werden. Trotzdem mainnamen der Zone liegen. Die Nameserver einer
wird der Punkt von Benutzern oft nicht mit eingege- Zone sind autoritativ für alle Domainnamen der Zoben, wenn das Ergänzungsverhalten bekannt ist.
ne, d. h. sie sind in der Lage zu entscheiden, ob ein
RR zu einem bestimmten Domainnamen existiert und
welche Daten er enthält.
10.2.2. Namensraum
Für jede Zone gibt es genau einen RR vom Typ
Die Reihenfolge der Label in einem Domainnamen SOA, der auf den primären, autoritativen Nameserver
drückt eine Hierarchie aus. Der Namensraum hat ei- der eigenen Zone verweist. Dieser bezieht seine Daten
ne Baumstruktur, siehe Abbildung 10.2. Jeder Kno- direkt aus der Zonendatei, die anderen, sekundären,
90
10.2. Konzepte
Abbildung 10.2.: Namensbaum und ein paar Begriffe.
Abbildung 10.3.: Namensbaum mit Zonenmarkierungen.
91
10. Domain Name System (DNS)
autoritativen Nameserver der Zone beziehen ihre Daten von ihm. Der Vorgang heißt Zonentransfer. Der
Administrator der Zone lässt die Zonendatei vom primären, autoritativen Nameserver neu einlesen, wenn
er Änderungen an ihr vorgenommen hat.
Der Verwalter einer Zone kann die Verwaltung einer Domain, deren Domainname in seiner Zone ist,
an eine andere Partei delegieren. Hierzu erstellt er für
den Domainnamen der zu vergebenden Domain RRs
vom Typ NS, die auf die Nameserver der anderen Partei verweist. Die delegierte Domain gehört jetzt zur
Zone der neuen Verwaltung; es entsteht eine neue Zone. Durch diesen Delegationmechanismus wird das
DNS zu einer verteilten Datenbank. Er ermöglicht den
einzelnen Parteien, ihre Domainnamen selbst zu verwalten, so dass die Datenbank trotz ihrer Größe und
der Vielzahl der Zugriffe lesbar und änderbar bleibt.
Alle Zonen sind Subzonen der Rootzone. Ihr Verwalter, die ICANN, bestimmt also welche TLDs es gibt
und wer sie verwalten darf. Alle anderen Parteien sind
im Grunde nur Pächter, denen die Verwaltungsmacht
auch wieder entzogen werden kann.
Die gTLDs hat die ICANN an Netzwerkfirmen wie
z. B. VeriSign delegiert. Die ccTLD sind an die NICs
(Network Information Centers) der einzelnen Länder
delegiert. Beide delegieren weiter an Domain Name
Registries (DNR) genannte Unternehmen, die wiederum an kleinere DNRs oder an den Registrant genannten Endnutzer delegieren, wenn diese eine freie Subzone/Subdomain beantragen. Die Delegation erfolgt
meistens gegen eine Gebühr und für einen Zeitraum
von ein bis zwei Jahren. Ein Registrant entrichtet eine
Gebühr an die DNR seiner Domain – i. d. R. für ein
oder zwei Jahre im voraus.
Die Nameserver, die für die Rootzone autoritativ sind, werden Rootnameserver genannt. Das
sind derzeit 13 Server mit den Domainnamen
‘a.root-servers.net.’ bis ‘m.root-servers.net.’. Ihre IPAdressen sind in DNS-Software bereits enthalten,
müssen aber regelmäßig aktualisiert werden. Die
meisten Rootnameserver stehen nominell in den USA,
implementieren aber Anycast, damit das DNS auch
von anderen Regionen aus hinreichend schnell ist.
10.2.4. Resource Records
Die aktuelle Ausprägung des Namenbaums und die
aktuelle Einteilung in Zonen ergibt sich aus den
auf den Nameservern vorhandenen, Resource Record
(RR) genannten Datensätzen.
Ein RR besteht aus folgenden Feldern:
NAME Domainname, zu dem die Information gehört
92
TTL Time To Live; Zeit in Sekunden, die der RR gecached werden darf
CLASS Klasse von des RR; ist für Internetbezogene Information immer „IN“
TYPE Typ von RDATA
RDATA Resource Data; der eigentliche Wert (ist bei
bestimmten Typen weiter strukturiert).
Die wichtigsten Typen sind:
A IPv4 Adress
AAAA IPv6 Adress (vier mal so groß wie eine IPv4Adresse)
PTR Domain Name PoinTeR
SOA Start Of Authority
NS Name Server
CNAME Canonical Name
MX Mail eXchange.
Ein RR vom Typ A enthält eine IPv4-Adresse, einer
vom Typ AAAA eine IPv6-Adresse. Ein Domainname, zu dem es ein A- oder AAAA-RR gibt, ist ein
Host, also eine adressierbarer Computer. Normalerweise sind die Blätter des Namensbaums Hosts. Aber
auch ein innerer Knoten kann ein Host sein. Das ist
nützlich, wenn erreicht werden soll, dass ein Domainname wie ‘uni-jena.de.’ zu der IP-Adresse eines bestimmten Rechners, z. B. der des Webservers der Universität Jena, aufgelöst wird.
Ein RR vom Typ PTR enthält (als RDATA) einen
Domainnamen. Das NAME-Feld dieses RR enthält
einen speziellen Domainnamen aus der Domain ‘arpa.net.’, in dem eine IP-Adresse codiert ist. Dieser
RR-Typ wird für die Inverssuche (finde Domainnamen zu einer IP-Adresse) benötigt.
Ein RR vom Typ SOA enthält den Domainnamen
des primären, autoritativen Nameservers und einige
weitere Parameter der Zone. Es gibt pro Zonendatei
genau einen SOA-RR.
Ein RR vom Typ NS enthält den Domainnamen
eines autoritativen Nameservers für die Domain mit
dem Domainnamen aus dem NAME-Feld. Einen solchen RR erstellt man zur Delegation. Auf Rootnameservern gibt es z. B. NS-RRs für die Domain ‘de.’, die
als Wert die Domainnamen der Nameserver des DeNIC (Deutsches Network Information Center) enthalten.
10.3. DNS-Protokoll
Ein RR vom Typ CNAME enthält den Domainnamen, für den der Domainname aus dem NAME-Feld
ein Alias sein soll.
Ein RR vom Typ MX enthält den Domainnamen
eines für die Zone zuständigen Mailservers nebst einem Prioritätswert für diesen. Dieser RR hat nichts
mit der Auflösung von Namen in IP-Adressen oder
umgekehrt zu tun und soll hier als Beispiel dafür dienen, dass das DNS auch andere Information zu Domainnamen speichern kann.
Beispiel:
www.example.com. 8218 IN A 192.0.34.166
Dieser RR hat die Bedeutung, dass dem Domainnamen „www.example.com.“ in der Klasse Internet die
IPv4-Adresse 192.0.34.166 zugeordnet ist und dass
diese Information noch 8218 s gecached werden kann.
Abbildung 10.4.: DNS-Protokoll – allgemeines
Paketformat.
Abbildung 10.5.: DNS-Protokoll – Flags.
10.2.5. Inverssuche
Die Inverssuche ist die Suche nach dem/den Domainnamen zu einer gegebenen IP-Adresse. Hierzu wird
die IP-Adresse in einen Domainnamen aus der Domain ‘in-addr.arpa.’, umgewandelt. Da Domainnamen
rechts am allgemeinsten sind – also von rechts nach
links aufgelöst werden – IP-Adressen in der dezimalen Punktschreibweise aber umgekehrt, wird die IPAdresse „gedreht“. Danach wird ‘in-addr.arpa.’ hinten
angehängt und nach einem PTR-RR für den entstandenen Domainnamen gesucht.
Beispiel: Bei der Inverssuche zur IP-Adresse
141.35.1.50 wird nach einem RR vom Typ PTR zum
Domainnamen ‘50.1.35.141.in-addr.arpa.’ gesucht.
Die NS-RRs der ‘in-addr.arpa.’-Domain sind extra für diesen Zweck erstellt und verweisen schließlich auf autoritative Nameserver der Zone, zu der die
gesuchte IP-Adresse gehört. Auf diesen Nameservern sollte – falls ein Domainname mit der IP-Adresse
existiert – auch ein PTR-RR (in unserem Beispiel zu
‘50.1.35.141.in-addr.arpa’) erstellt worden sein, der
den gesuchten Domainnamen enthält.
10.3. DNS-Protokoll
Das DNS-Protokoll ist auf der Anwendungsebene des
TCP/IP-Protokollstapels, siehe Abbildung 10.1. Standardmäßig benutzt es UDP Port 53. TCP Port 53 wird
bei Zonentransfers und bei Paketen größer 512 B benutzt.
Es gibt ein gemeinsames Nachrichtenformat für
DNS-Anfragen und -Antworten. Das Nachrichtenformat besteht aus einem fixen Header von 12 B Länge
und bis zu vier weiteren Teilen variabler Länge, siehe
Abbildung 10.4.
10.3.1. Header
Die ID wird vom Client in der Anfrage gesetzt und
vom Server in der Antwort übernommen. Sie ermöglicht dem Client, erhaltene Antworten gesendeten
Fragen zuzuordnen. In der Regel erzeugt der Client
einen zufälligen Wert für die ID.
Das FLAGS-Feld ist in Abbildung 10.5 aufgeschlüsselt.
QR Question/Response; zeigt an, ob es sich um eine
Anfrage oder eine Antwort handelt.
OPCODE Operation Code; dieses 4 bit-Feld hat nur
in Anfragen eine Bedeutung und wird bei der
Antwort einfach übernommen. Es zeigt an, ob es
sich um eine normale Anfrage, eine inverse Anfrage oder eine Serverstatusanforderung handelt.
AA Authoritative Answer; das Flag zeigt in Antworten an, ob die Antwort von einem autoritativen
Nameserver stammt.
TC TrunCation; das Flag zeigt an, dass ein Teil der
Nachricht wegen Größenbeschränkung (z. B. bei
Transport über UDP maximal 512 B) abgeschnitten wurde.
RD Recursion Desired; das Flag zeigt in Anfragen
an, dass der rekursive Modus erwünscht ist.
93
10. Domain Name System (DNS)
Klasse QCLASS) haben kann, ist ein Wert von
QTYPE zugeordnet. Zusätzlich gibt es einen
ANY genannter Wert, der für „alle Typen“ steht,
und einen AXFR genannten Wert, der für „Zonentransfer“ steht.
Abbildung 10.6.: DNS-Protokoll – Question
Section.
RA Recursion Available; das Flag zeigt in Antworten
an, dass der rekursive Modus angeboten wird.
Z Zero; dieses 3 bit-Feld ist reserviert für Erweiterungen und muss ‘000’ sein.
RCODE Response Code; dieses 4 bit-Feld hat nur in
Antworten Bedeutung. Es zeigt an, ob und welche Art von Fehler aufgetreten ist, z. B. „Domainname existiert nicht“.
Die folgenden vier Felder sind 16 bit große Zähler, die die Anzahl der Einträge in der Question, Answer, Authority bzw. Additional Section anzeigen. Die
Question Section wird vom Resolver gesetzt und in
der Antwort übernommen. Die anderen Sections werden in Antworten vom Nameserver gesetzt.
10.3.2. Question Section
Die Question Section beinhaltet die Parameter, die eine Anfrage spezifizieren. In der Regel hat die Question Section genau einen Eintrag. Wie man in Abbildung 10.6 sieht, ist ein Eintrag der Question Section
ähnlich aufgebaut wie ein RR, nur dass es kein TTLund kein RDATA-Feld gibt.
QNAME hat eine variable Größe und enthält einen
codierten FQDN. Label von Domainnamen werden in DNS-Nachrichten nicht durch einen
Punkt, sondern durch ein Zählerbyte getrennt.
Das Zählerbyte zeigt die Anzahl der Zeichen des
folgenden Labels an. Ein Zähler mit dem Wert
0 signalisiert, dass das nächste Label das leere
Label des Rootknoten ist. Er zeigt also das Ende von QNAME an. Siehe hierzu auch den Abschnitt „Kompressionsschema“ (10.3.4).
10.3.3. Answer, Authority und
Additional Section
Answer, Authority und Additional Section haben das
gleiche Format: Eine im entsprechenden Headerfeld
angegebene Anzahl von in Abbildung 10.7 dargestellten Einträgen. Ein Eintrag repräsentiert einen RR des
antwortenden Nameservers.
NAME, TYPE und CLASS sind wie QNAME,
QTYPE und QCLASS aus der Question Section spezifiziert. TTL ist 32 bit groß und gibt die Zahl der Sekunden an, die der zugehörige Eintrag (RR) im Cache
gehalten werden soll. RDLENGTH ist 16 bit groß und
gibt die Länge des folgenden Feldes RDATA in Byte
an. RDATA hat eine variable Größe und enthält ein
von TYPE und CLASS abhängiges Datum, so wie im
Abschnitt 10.2.4 beschrieben.
Die Answer Section enthält RRs, die in der Question Section angefragten wurden. Kleine Optimierung: Um nachfolgende DNS-Fragen zu vermeiden,
sendet ein Nameserver, der nach RRs zu einem
Alias-Domainnamen gefragt wurde, zusätzlich zum
CNAME-RR (=Alias) noch den angefragten RR des
kanonischen Domainnamen, falls vorhanden.
Die Authority Section enthält NS-RRs, die auf
Nameserver verweisen, die für eine Domain autoritativ sind, die dem angefragten Domainnamen näher
kommt.
Die Additional Section enthält alle anderen RRs,
die der Nameserver mitsenden möchte. Meist sind
das RRs vom Typ A oder AAAA, die die IP-Adresse
QCLASS ist 16 bit groß und enthält die Klasse des
gewünschten RR, z. B. IN für Internet. Zusätzlich gibt es einen ANY genannter Wert, der für
„alle Klassen“ steht.
QTYPE ist 16 bit groß und enthält den Typ des gewünschten RR. Jedem Typen, den ein RR (der
94
Abbildung 10.7.: DNS-Protokoll – Nonquestion
Section.
10.4. DNS-Software
Auf UNIX-artigen Systemen lässt sich in der Datei
/etc/resolv.conf konfigurieren, wie der Resolver
unvollständige Namen ergänzen soll und ob er einem
bestimmten Nameserver (IP-Adresse!) als erstes eine
Anfrage senden soll.
Wenn er die erwünschte Information nicht im
Cache hat, wandelt der Resolver die Anfrage der Applikation in eine DNS-Anfrage um. Das weitere Vorgehen ist vom Modus abhängig. Ein Resolver kann im
rekursiven Modus oder im iterativen Modus arbeiten.
Im rekursiven Modus sendet er seine Anfrage mit
RD-Flag (Recursion Desired) an einen vorkonfigu10.3.4. Kompressionsschema
rierten Nameserver. Alle weiteren, zum Erhalt der geWie oben erwähnt, darf ein Label zwischen 1 und 63 wünschten Information nötigen Anfragen übernimmt
Zeichen haben. Die beiden Most Significant Bits der dann ein im Nameserver eingebauter, iterativ arbeiZählerbytes in QNAME und NAME sind also stets tender Resolver. Voraussetzung ist, dass der Namenull. Die Längenrestriktion für Labels ist absichtlich server den rekursiven Modus anbietet – ersichtlich am
so gewählt worden. Man benutzt diese beiden bis- gesetzten RA-Flag (Recursion Available) in seinen
her redundanten Bits, um ein Kompressionsschema Antworten. Die meisten Rootnameserver und TLDfür die häufig innerhalb eines DNS-Paketes wieder- Nameserver bieten keinen rekursiven Modus an, um
kehrenden Labels zu implementieren. Sind die beiden sich keine zusätzliche Last aufzubürden. Ein Stub ReMSB ‘11’, so sind die restlichen 6 bit des Bytes kein solver ist ein Resolver, der ausschließlich im rekursiZähler, sondern Teil eines Pointers. Die auf die ersten ven Modus arbeitet.
Im iterativen Modus sendet der Resolver eine An2 bit folgenden 14 bit sind das Offset desjenigen Bytes
frage
ohne RD-Flag an einen ihm bekannten Rootim DNS-Paket, das das Zählerbyte des darzustellennameserver.
Von dem kontaktierten Nameserver erden Labels ist. Auf diese Weise werden zur Darstelhält
er
entweder
den gesuchten RR oder die Konlung eines bereits vorgekommenen Label (bis zu 64 B)
taktdaten
für
einen
Nameserver, der autoritativ ist für
nur 2 Bytes benötigt. Es darf allerdings kein Pointer
eine
in
der
Kette
vom
Rootknoten zum angefragten
auf ein Byte in einem von einer Klasse abhängigen
Domainnamen
tiefer
gelegene
Domain. Diesen fragt
Feld (also RDATA der Nonquestion Sections) verweier
wiederum
an.
Der
Resolver
hangelt sich auf diese
sen, auch wenn es einen Domainnamen enthält.
Weise durch die Zonen-Hierarchie im Namensbaum.
Spätestens beim Anfragen eines für den angefragten
Domainnamen autoritativen Nameserver bekommt er
10.4. DNS-Software
den gesuchten RR oder die zuverlässige Auskunft,
dass der gesuchte RR nicht existiert (DNS-Antwort
10.4.1. Resolver
mit bestimmten Response Code). Dann gibt er einen
Ein Resolver ist ein Software-Modul, das auf den geeigneten Wert an die Applikation zurück bzw. senRechnern von DNS-Teilnehmern installiert ist. Er bil- det eine geeignete DNS-Antwort an den rekursiven
det die Schnittstelle zwischen Applikation und den Resolver, den er bedient.
Beliebte Linux-Tools, um DNS-Anfragen zu stelNameservern.
Aus Applikationssicht ist das DNS ein lokal vor- len, sind nslookup, host und dig.
handener Baum mit Information in den Knoten,
die durch Anfragen an den Resolver gelesen wer10.4.2. Nameserver
den können. Auf UNIX-artigen Systemen heißen die
dafür meist verwendeten Funktionen gethostbyna- Ein Nameserver ist ein Programm, das Antworten auf
me() und gethostbyadress(). Erstere erwartet einen DNS-Anfragen gibt. Umgangssprachlich wird auch
Domainnamen und gibt, falls vorhanden, eine IP- der Computer, auf dem das Programm läuft, als
Adresse zurück, letztere erwartet eine IP-Adresse und Nameserver bezeichnet.
gibt, falls vorhanden, einen Domainnamen zurück.
Ein Nameserver versucht eine Anfrage mit den RRs
Aus Resolversicht hingegen besteht das DNS aus aus seiner Zonendatei oder aus seinem Cache zu beeiner unbekannten Menge von Nameservern, die je- dienen. Ist dies nicht möglich, ist das weitere Vorgeweils einen Teil der gesamten Information haben. hen vom Modus abhängig.
der Nameserver aus der Authority Section enthalten.
Solche RRs werden Glue Records genannt und sie
verhindern, dass durch kreisförmige Abhängigkeiten
ein Nameserver-Domainnamen nicht aufgelöst werden kann. Wenn z. B. ein zu kontaktierender Nameserver einen Domainnamen aus einer Domain hat, für
die er selbst zuständig ist, könnte ohne einen stets mitgesendeten Glue Record auf dem auf ihn verweisenden Nameserver seine IP-Adresse nicht ermittlet werden.
95
10. Domain Name System (DNS)
Wenn der Nameserver keine Rekursion anbietet
oder die Anfrage keine Rekursion erwünscht, so
schickt er in der Authority Section einige NS-RRs für
Nameserver einer Domain, die möglichst nahe an der
angefragten Domain ist. Im ungünstigsten Fall sind
dies die NS-RRs für die Rootnameserver. Diese muss
jeder Nameserver kennen. Ausgehend von den Rootnameservern aber ist ein Nameserver entweder selbst
autoritativ für den gesuchten Domainnamen, oder er
hat delegiert. Im letzteren Fall hat er NS-RRs für die
Nameserver, an die er delegiert. Diese übermittelt er
in der Authority Section seiner Antwort. In der Additional Section seiner Antwort muss mindestens ein
RR mit der IP-Adresse von einem der Nameserver
sein – Stichwort Glue Records.
Wenn der Nameserver Rekursion anbietet und in
der Anfrage Rekursion erwünscht wird, so stellt der
Nameserver die notwendigen Anfragen an die anderen Nameserver. Er agiert also als Client. Für diesen
Zweck ist ein Resolver, der im iterativen Modus arbeitet, im Nameserverprogramm eingebaut. Er hangelt
sich wie im Abschnitt „Resolver“ beschrieben durch
die Domain-Hierarchie. Die Antwort wird schließlich
dem Resolver, der die ursprüngliche Anfrage gestellt
hat, zugesendet.
Wie weiter oben bereits beschrieben, muss ein sekundärer, autoritativen Nameserver regelmäßig seine
Zonendatei mit den Daten vom primären, autoritativen Nameserver aktualisieren. Im SOA-RR der Zone
steht u.a., wann er dies tun soll und welche Versionsnummer die Zonendatei hat.
10.4.3. Caching
Caching ist im DNS wichtig, um die Zahl der Anfragen und damit die Netzlast zu reduzieren, die Verfügbarkeit von Nameservern sicher zu stellen und
die Antwortzeit zu minimieren. Von Vorteil ist dabei die naturgemäß lange Invarianz der meisten DNSInformationen.
Um eine möglichst hohe Trefferquote zu erreichen,
sollte es für einen Bereich ähnlicher Anfragen einen
großen, zentralen Cache geben. Deshalb cachen StubResolver nicht, sondern verlassen sich auf den Cache
ihres Nameservers. Auch Applikationen sollten, wenn
überhaupt, dann nur in sehr eingeschränktem Maße
cachen. Ob ein Resolver cachen sollte, ist von seiner
Umgebung abhängig. Möglich ist auch, dass sich Resolver und Nameserver einen Cache teilen.
Um die Aktualität der RRs und somit die Konsistenz des DNS möglichst hoch zu halten, kann jede Informationsquelle selbst im TTL-Feld ihrer RRs vorschlagen, wie lange der RR maximal gecached wer-
96
den darf. Üblich sind Werte zwischen wenigen Minuten und etlichen Tagen. Bei einer anstehenden RRÄnderung kann der Administrator den TTL-Wert vorher schrittweise senken und so dafür sorgen, dass nach
der Änderung kaum jemand den alten RR im Cache
hat.
Experiment: Man tätige eine DNS-Anfrage nach
einem ungecachten RR. Man tätige dieselbe Anfrage noch einmal. Man beachte verkürzte Dauer für die
Antwort und den gesenkten TTL-Wert des RR bei der
zweiten Anfrage.
10.4.4. Beispiel für eine DNS-Anfrage
Folgendes Beispiel erwähnt Besonderheiten, wie z. B.
ein bestimmter Wert im Flag-Bereich einer DNSNachricht, nur beim ersten Auftreten.
Bob klickt in seinem Webbrowser auf den Link
„http://www.example.pro/index.html“. Der Webbrowser soll also mit einem Rechner mit dem
Domainnamen ‘www.example.pro’ kommunizieren.
Um die dazu nötige IP-Adresse zu erhalten, ruft der
Webbrowser eine geeignete Funktion des lokalen Resolvers auf. Der Resolver sei ein Stub-Resolver und
habe als Nameserver die IP-Adresse des Rechners
‘workhard.isp.de.’, ein Nameserver von Bobs Internet
Service Provider (ISP), eingestellt. Wenn es der Webbrowser noch nicht getan hat, ergänzt der Resolver
den Endpunkt und sendet eine DNS-Anfrage mit OPCODE für „normale Anfrage“ und gesetzten RD-Flag
an den ISP-Nameserver. Die Question Section enthält
die Anfrage nach RRs der Klasse IN vom Typ A zu
dem Domainnamen ‘www.example.pro.’, die anderen
Sections sind leer.
Der Nameserver ‘workhard.isp.de.’ hat den gesuchten RR weder in seiner Zonendatei, noch in seinem
Cache. Er ist auch nicht autoritativ für die angefrage Domain. Da er Rekursion anbietet und RD gesetzt ist, sendet er die Anfrage mit neuer ID und ohne RD-Flag (iterativ) an die IP-Adresse eines zufällig aus seiner Rootnameserver-Liste augewählten Nameservers ‘k.root-server.net.’. Dieser hat zwar keinen gesuchten RR, aber er hat einen NS-RR für
‘ns23.netzwerkfirma.com.’, ein für die TLD ‘com.’
autoritativer Nameserver. Den NS-RR packt er in die
Authority Section und zugehörigen A-RR in die Additional Section und sendet dann eine DNS-Antwort
(mit RCODE „No Error“) zurück an die IP-Adresse
von ‘workhard.isp.de.’.
Eine bis auf die ID gleich gebliebene DNS-Anfrage
sendet ‘workhard.isp.de.’ an die eben erhaltene IPAdresse von ‘ns23.netzwerkfirma.com.’. Leider hat
auch dieser keinen passenden RR, kennt aber einen
10.5. Erweiterungen, Wirtschaft und Politik
für die betreffende Zone autoritativen Nameserver
‘ns.example.pro.’ inklusive IP-Adresse, die er ‘workhard.isp.de.’ mitteilt.
Nun sendet ‘workhard.isp.de.’ eine bis auf die ID
gleich gebliebene DNS-Anfrage an ‘ns.example.pro.’
und erhält den gesuchten RR in der Answer Section
als autoritative Antwort (AA-Flag gesetzt).
Diesen sendet er mit der ID der zu Beginn erhaltenen Anfrage versehen zurück an Bobs Rechner. Bobs
Resolver liest die gesuchte IP-Adresse aus dem RR
und gibt sie an den Webbrowser.
10.5. Erweiterungen,
Wirtschaft und Politik
Mit der Bedeutung des Internet wächst auch die
Macht derjenigen, die die Kontrolle über den DNSNamensraum haben. Firmen wie VeriSign haben
großes finanzielles Interesse, ihre bereits gewonnene Kontrolle zu behalten und geraten deswegen öfters in die Kritik. Um welche Beträge es dabei geht,
zeigt das pazifische Inselarchipel Tuvalu. Tuvalu hat
die ccTLD ‘tv.’ – eines der international bekanntesten
Kürzel. Ein jedes Unternehmen aus der TV-Branche
hätte gerne eine ‘tv.’-Domain für seine Internetpräsenz. Dieser Umstand führte dazu, dass Tuvalu seine
Domain für 50 Millionen Dollar verkauft hat. Heute
ist man der Meinung, dass die Domain noch wesentlich mehr wert ist.
Zu den Haupt-RFCs 1034 und 1035 gibt es gut ein
Dutzend weitere, die
• Ratschläge und Erläuterungen für Administratoren und DNS-Software-Entwickler geben
• neue RR-Typen beschreiben
• das DNS um Sicherheitsmechanismen ergänzen
(DNSSEC, TSIG)
• Unicode-Zeichen in Domainnamen erlauben
• die Inverssuche trotz klassenloser IP-Netzwerke
ermöglichen
• das DNS dynamisieren, so dass es auch für kurzlebigere Daten geeignet ist
• reservierte Headercodes verwenden, um anzuzeigen, dass UDP-Pakete größer 512 Bytes empfangen werden können (EDNS)
• das Anwählen von Internet-Geräten über Telefonnummern (ENUM) ermöglichen
• RFID unterstützen
• das DNS IPv6-kompatibel machen
und noch vieles mehr.
Die Verantwortung über die Rootserver hatte früher die Internet-Organisation IANA, seit einigen Jahren jedoch die ICANN. Da die ICANN eine Organisation amerikanischen Rechts ist, sind viele InternetAktivisten über den Einfluss der USA auf das DNS
beunruhigt. Deshalb haben sie das Open Root Server
Network (ORSN) als eine Alternative zu den RootNameservern der ICANN gegründet.
97
11. File Transfer Protocol (FTP)
Christian Ros
11.1. Einleitung
Die Entwicklung moderner Netzwerke nahm in den
frühen 60er Jahren am Massachusetts Institute of
Technology (MIT) ihren Anfang. Ebendort wurde 1971 im Rahmen des Projektes MAC mit dem
RFC 114 [Bhu71] der Grundstein für das File Transfer Protocol (FTP) gelegt, das sich die sichere und
effiziente Übertragung von Dateien zwischen heterogenen Systemen zum Ziel gemacht hat. Im weiteren Entwicklungsprozess wurde das Protokoll zahlreichen Anpassungen und Erweiterungen unterzogen
und basiert seit 1980 (RFC 765 [Pos80a]) auf TCP/IP.
FTP ist in der Anwendungsschicht des Protokollstapels angesiedelt (vgl. Abbildung 11.1). Im Jahr 1985
wurde mit dem RFC 959 [PR85] eine überarbeitete
Version des RFC 765 veröffentlicht, der die bis heute offiziell gültige Fassung des Protokolls darstellt.
Aufbauend auf diese Fassung sind nach 1985 weitere RFCs erschienen, die die Funktionalität des Protokolls durch die Spezifikation optionaler Erweiterungen verbessern.
TCP/IP Schichten
Protokolle
Anwendungsschicht
FTP
Transportschicht
TCP
Client
Client
FTP-Server
Client
Client
Abbildung 11.2.: Eine Client-Server-Architektur.
Im Zuge dieser langjährigen Entwicklung und des
wachsenden Bedarfs, Daten zu übertragen, hat sich
das File Transfer Protocol als der Standard für die
Datenübertragung im Internet etabliert und steht auf
praktisch allen Plattformen zur Verfügung. Aus diesem Grund wird das File Transfer Protocol im Folgenden detailliert beschrieben und die ihm zu Grunde
liegenden Mechanismen dargestellt. Hierzu werden
im Abschnitt 11.2 die verschiedenen Verbindungen
des Protokolls vorgestellt, bevor im Abschnitt 11.3
auf den Aufbau der Verbindungen, die Datenübertragung und den Verbindungsabbau eingegangen wird.
Daran anschließend wird in Abschnitt 11.4 eine Erweiterung des File Transfer Protocol behandelt – das
File eXchange Protocol.
11.2. FTP-Verbindungen
Netzwerkschicht
Netzzugangsschicht
IP
Netzwerk
Abbildung 11.1.: FTP im TCP/IP-Schichtenmodell.
Das File Transfer Protocol basiert auf einer klassischen Client-Server-Architektur und ermöglicht verschiedenen Clients den Fernzugriff auf einen FTPServer (vgl. Abbildung 11.2). Dabei verwendet FTP
zwei separate TCP-Verbindungen:
• die Steuerverbindung für die Kommunikation
und
99
11. File Transfer Protocol (FTP)
• die Datenverbindung für die Datenübertragung.
Wie Abbildung 11.3 zeigt, erfolgt die Steuerung
des Client direkt durch den Anwender, der diesen über
eine Anwenderschnittstelle bedient, während die Verwaltung der Verbindungen nur intern realisiert wird
und somit für den Anwender nicht unmittelbar sichtbar ist. Sowohl auf dem Client als auch auf dem
Server existieren dabei für die Kontrolle der Steuerverbindung entsprechende Protokollinterpreter und
die mit dem Dateisystem verbundenen Datentransferfunktionen, welche die Datenverbindung steuern.
Bevor der Zugriff auf den Server erfolgen kann,
ist eine Authentifikation mit einem Benutzernamen
und dem dazugehörigen Passwort erforderlich. Viele
FTP-Server ermöglichen hier neben der normalen accountbezogenen Authentifikation mit einem vollwertigen Konto auch eine anonyme Anmeldung, bei der
als Benutzername anonymous und als Passwort in der
Regel die E-Mail Adresse übermittelt wird. Dieser anonyme Zugriff unterliegt im Unterschied zur accountbezogenen Authentifikation jedoch meist zusätzlichen
Beschränkungen.
Das File Transfer Protocol verwendet zwei getrennte TCP-Verbindungen, um den Zugriff auf einen
FTP-Server zu realisieren – die Steuerverbindung für
die Kommunikation und die Datenverbindung für den
eigentlichen Datentransfer. Die Übertragung der Daten über diese Leitungen erfolgt dabei ohne jegliche
Verschlüsselung, weshalb das Protokoll vom Sicherheitsstandpunkt aus gesehen mangelhaft ist.
1997 wurde FTP im RFC 2228 [HL97] durch die
Spezifikation verschiedener Verschlüsselungsmechanismen erweitert. Da diese Erweiterung allerdings
kaum Verbreitung gefunden hat, empfiehlt es sich in
sicherheitskritischen Bereichen, Alternativen wie das
SSH File Transfer Protocol (SFTP)1 zu verwenden.
11.2.1. Die Steuerverbindung
Die Steuerverbindung ist eine VollduplexVerbindung, die während einer FTP-Sitzung
zwischen den Protokollinterpretern permanent
aufgebaut ist und der Kommunikation zwischen dem
Client und dem Server dient. Somit werden über die
Steuerverbindung ausschließlich die Befehle vom
Client an den Server und die Antworten vom Server
an den Client übertragen.
1 Das SSH File Transfer Protocol sollte keinesfalls mit dem Secure File Transfer Protocol verwechselt werden, da dieses nur
die Steuerverbindung per SSH tunnelt und die eigentliche Datenübertragung wie beim File Transfer Protocol unverschlüsselt
erfolgt.
100
Zur Aufrechterhaltung der Kompatibilität zwischen
heterogenen Systemen verwendet das File Transfer
Protocol für den Datentransfer eine rudimentäre Version des bereits spezifizierten Telnet Protokolls (RFCs
854–861 [PR83]). Dementsprechend erfolgt die Übertragung der Daten im 8 bit NVT-ASCII-Format2 bei
dem jede Zeile mittels <CR><LF>3 abgeschlossen
wird.
11.2.1.1. FTP-Befehle
Der Zugriff und die Steuerung des Servers erfolgt anhand von Befehlen, die zwischen den Protokollinterpretern des Client und des Servers übermittelt werden.
Die Befehle lassen sich dabei drei Gruppen zuordnen:
• Befehle für die Zugriffskontrolle,
• Befehle für die Übertragungsparameter und
• Befehle für die Bedienung.
In Tabelle 11.1 wird eine Auswahl verschiedener
Befehle dargestellt.
11.2.1.2. Antworten des Servers
Neben den Befehlen werden auch die Antworten
vom Server über die Steuerverbindung transferiert.
Es handelt sich dabei in der Regel um obligatorische
Antworten, die wichtige Informationen und Statusmeldungen für die Interaktion zwischen Anwender,
Client und Server enthalten und auf empfangene Befehle folgen müssen. Wenn es notwendig sein sollte,
kann der Server auch spontane Nachrichten senden.
Eine Antwort besteht aus einem dreistelligen Zahlencode, dem dazugehörigen optionalen Text und der
Zeilenendemarkierung <CR><LF>. Dabei wird der
Code vom Text durch ein Leerzeichen (<SP>) getrennt:
<Zahlencode><SP><Text><CR><LF>
Beispiel:
257 "/pub" is current directory.
Falls sich die Verwendung von einzeiligen Antworten als unzureichend erweist, können auch mehrzeilige Antworten an den Client verschickt werden. Bei
diesen Nachrichten werden die erste und die letzte
2 Im 8 bit Network-Virtual-Terminal-ASCII-Format wird jedes
Zeichen mit 7 bit codiert und das höchstwertige Bit auf 0 gesetzt.
3 CR = Carriage Return; LF = Line Feed.
11.2. FTP-Verbindungen
FTP-Client
Anwender
Dateisystem
Anwender
Schnittstelle
FTP-Server
Anwender
Protokoll
Interpreter
Steuerverbindung
Server
Protokoll
Interpreter
Anwender
Datentransfer
Funktion
Datenverbindung
Server
Datentransfer
Funktion
Dateisystem
Abbildung 11.3.: Darstellung einer Client-Server-Verbindung des File Transfer Protocols.
Befehle für die
Befehl
Beschreibung
Zugriffskontrolle
USER
PASS
QUIT
(user name)
(password)
(logout)
Benutzernamen an den Server senden.
Passwort an den Server übermitteln.
Die Verbindung beenden.
Übertragungsparameter
PORT
PASV
TYPE
STRU
MODE
(port)
(passive)
(type)
(structure)
(mode)
Client-IP-Adresse und -Port an den Server übermitteln.
In den Passive-Modus wechseln.
Die Datenrepräsentation ändern.
Die Struktur der Daten ändern.
Den Übertragungsmodus wählen.
Bedienung
RETR
STOR
REST
ABOR
LIST
(retrieve)
(store)
(restart)
(abort)
(list)
Veranlasst den Server, eine Datei zu übertragen.
Eine Datei auf dem Server speichern.
Wiederaufnehmen einer unterbrochenen Übertragung.
Den vorherigen Befehl abbrechen.
Den Verzeichnisinhalt auflisten.
Tabelle 11.1.: Eine Auswahl verschiedener FTP-Befehle.
101
11. File Transfer Protocol (FTP)
Antwort
Beschreibung
1yz
Positive einleitende Antwort: Es wird
eine weitere Antwort gesendet, bevor
mit dem nächsten Befehl fortgefahren
werden kann.
Positive abschließende Antwort: Die
Aktion wurde erfolgreich ausgeführt.
Positiver Zwischenbericht: Senden Sie
den nächsten Befehl.
Transiente negative Antwort: Der Befehl kann nicht ausgeführt werden.
Wiederholen Sie den Befehl oder die
Befehlsfolge.
Permanente negative Antwort: Der Befehl wurde nicht akzeptiert.
2yz
3yz
4yz
5yz
x0z
x1z
x2z
x3z
x4z
x5z
Syntax
Informationen
Verbindungen
Authentifikation und Benutzerkonten
Nicht spezifiziert
Dateisystem
Tabelle 11.2.: Bedeutung des 3-stelligen Antwortcodes.
Ziffern ist dazu in Tabelle 11.2 angegeben. Die dritte
Ziffer dient primär der feineren Unterscheidung verschiedener Antworten.
Beispiel:
110
200
226
230
257
331
425
550
Restart marker reply.
Command okay.
Transfer ok.
User logged in, proceed.
<path> created.
User name okay, need password.
Can’t open data connection.
No such file or directory.
11.2.2. Die Datenverbindung
Die Datenverbindung ist eine Vollduplex-Verbindung,
die ausschließlich für die Datenübertragung zwischen
dem Client und dem Server verwendet wird. Dies umfasst neben dem Dateitransfer auch die Übertragung
von Verzeichnisinhalten, da dies nicht über die Steuerverbindung realisiert wird. Im Unterschied zur permanent vorhandenen Steuerverbindung ist die Datenverbindung nur während der eigentlich Übertragung
aufgebaut und wird nach Beendigung des Transfers
geschlossen.
Zeile gesondert gekennzeichnet. Die erste Zeile enthält den Zahlencode, gefolgt von einem Bindestrich, 11.3. Verbindungsdem Text und der Zeilenendemarkierung, während die
Management
letzte Zeile den Zahlencode, <SP>, den Text und die
Zeilenendemarkierung enthält:
Das Verbindungs-Management wird direkt durch die
Protokollinterpreter und Datentransferfunktionen ge<Zahlencode>-<Text><CR><LF>
steuert und umfasst neben dem Auf- und Abbau der
<Text><CR><LF>
Verbindungen ebenso die Datenübertragung. Der An<Text><CR><LF>
wender hat dabei nur beschränkte Interaktionsmög<Zahlencode><SP><Text><CR><LF>
lichkeiten, da die Anwenderschnittstelle die direkte
Kontrolle der Verbindungen meist nicht zulässt.
Beispiel:
211-Status of ’CTAN’
Connected from pixie.uni-jena.de
TYPE: ASCII
STRUcture: File
Mode: Stream
No data connection
211 End of status
Der Text in den Antworten dient dem Anwender
dabei lediglich als Erläuterung, hat aber im weiteren
Sinne keine Bedeutung. Im Unterschied dazu verwendet der Anwender-Protokollinterpreter ausschließlich
den Zahlencode und erhält dadurch Informationen
über gesendete Befehle und den Zustand des Servers.
Dementsprechend hat jede Ziffer des Codes eine bestimmte Bedeutung. Die Bedeutung der ersten beiden
102
11.3.1. Verbindungsaufbau
In einer FTP-Sitzung gliedert sich der Verbindungsaufbau meist in drei Abschnitte:
• den Aufbau der Steuerverbindung,
• die Anmeldung am FTP-Server und
• den Aufbau der Datenverbindung.
11.3.1.1. Aufbau der Steuerverbindung
Der erste Schritt einer FTP-Sitzung ist stets die Etablierung der Steuerverbindung zwischen dem Client
und dem Server. Hierbei initiiert der Client, analog
11.3. Verbindungs-Management
FTP-Server
FTP-Client
Port N
(active open)
Steuerverbindung
Port L
(passive open)
dem Server einen Befehl, für den eine Datenverbindung erforderlich ist (z. B. retrieve, store, list, etc.).
Die Datenverbindung kann auf drei Arten etabliert werden, die durch drei Modi realisiert sind:
Standard-, Port-, und Passive-Modus.
SV
SV
Zeitlicher Verlauf
Standard-Modus Wie Abbildung 11.6(a) zeigt,
erfolgt der Aufbau der Datenverbindung, indem der
Server die Verbindung durch ein active open zwiAbbildung 11.4.: Aufbau der Steuerverbindung.
schen seinem lokalen Port L − 14 und Port N des
Client herstellt. Um diesen bereits für die SteuerverFTP-Server
FTP-Client
bindung verwendeten Port erneut zum Aufbau der
Datenverbindung nutzen zu können, ist es notwenUSER <Benutzername>
N
dig, dass der Client Port N beim passive open mit
L
ed.
SO_REUSEADDR kennzeichnet. Dies hat allerdings
L
331 Password requir
N
den entscheidenden Nachteil, dass nach dem serverseitigem Schließen der Verbindung aufgrund des
PASS <Passwort>
TIME_WAIT-Zustands, der in Abschnitt 7.3.1 erläuN
L
tert wird, für 2MSL Sekunden keine erneute Datenged in.
L
230 User <...> log
verbindung zwischen diesen Ports aufgebaut werden
N
kann.
Abbildung 11.6(b) stellt die zeitliche Abfolge der
Befehle
zum Aufbau der Datenverbindung dar und
Abbildung 11.5.: Befehlsabfolge zur Anmeldung
zeigt
im
Speziellen, dass die Datenverbindung direkt
am Server.
im Anschluss an den Befehl des Client aufgebaut wird
– also noch bevor der Server eine Antwort schickt.
zu Abbildung 11.4, den Verbindungsaufbau durch ein Die Antwort übermittelt der Server somit erst, wenn
active open vom Port N zum Port L des Servers. die Datenverbindung etabliert wurde und der Transfer
Port N sollte dabei möglichst kein Standard-Port sein. zwischen Client und Server möglich ist.
Der Port für die Steuerverbindung auf dem Server ist
Da der TIME_WAIT-Zustand im Standard-Modus
in der Regel Port 21 – kann aber bei den meisten er- jedoch ein grundlegendes Problem darstellt, wird diehältlichen FTP-Servern verändert werden.
ser Modus in der Regel nicht unterstützt und es erfolgt
Nach dem erfolgreichen Aufbau der Verbindungen ein Rückgriff auf den Port- oder Passive-Modus.
sendet der Server im Normalfall eine spontane Antwort, um zu signalisieren, dass die Verbindung aufge- Port-Modus Im Port-Modus wird die Datenverbaut wurde.
bindung nicht zu Port N, sondern zu dem frei wählbaren Port M des Client aufgebaut (vgl. Abbildung 11.7(a)), wodurch die Probleme, die sich durch
11.3.1.2. Anmeldung am FTP-Server
den TIME_WAIT-Zustand ergeben, umgangen werNachdem die Steuerverbindung zwischen dem Client den. Die Spezifikation des verwendeten Ports erfolgt
und dem Server erfolgreich etabliert wurde, ist eine dabei durch den Client, indem dieser den port-Befehl
Authentifikation erforderlich, durch die dem Client und die entsprechenden Parameter an den Server
der Zugriff zum Server ermöglicht wird. Die Anmel- übermittelt.
dung folgt dabei dem Schema aus Abbildung 11.5 und
Der Befehl hat folgende Struktur:
umfasst das Übermitteln des Benutzernamens und des
PORT a1,a2,a3,a4,p1,p2
entsprechenden Passworts an den FTP-Server.
Die obligatorischen Parameter a1 , a2 , a3 , a4 , p1 und
p
2 beschreiben die IP-Adresse und den Port, zu der
11.3.1.3. Aufbau der Datenverbindung
der Server die Verbindung aufbaut:
Der Aufbau der Datenverbindung wird stets durch den
IP:
a1 .a2 .a3 .a4
Client initiiert und ist notwendig, wenn Dateien übertragen oder Verzeichnisinhalte abgerufen werden. Um
4 Da die Steuerverbindung in der Regel Port 21 verwendet, ist der
Port für die Datenverbindung 20.
den Verbindungsaufbau einzuleiten, sendet der Client
103
11. File Transfer Protocol (FTP)
FTP-Server
enver
bindung
Port L - 1
(active open)
(a) Port-Verbindungs-Koordination.
SV
Dat
Port L
DV
(REUSEADDR)
Steuerverbindung
N
SV
Port N
(passive open)
Zeitlicher Verlauf
FTP-Server
FTP-Client
N
N
DV
FTP-Client
N
<Befehl> [<Paramet
er>]
L
Aufbau der Datenverbindu
ng
connection.
150 Opening data
Datenübertragung
L-1
L
L-1
(b) Abfolge der Befehle der Steuerverbindung (SV) und
Auswirkungen auf die Datenverbindung (DV).
Abbildung 11.6.: Aufbau der Datenverbindung im Standard-Modus.
Port:
p1 · 256 + p2 ;
0 ≤ p1 ≤ 255
0 ≤ p2 ≤ 256.
Beispiel:
PORT 141,35,3,16,75,19
IP-Nummer:
Port:
Adresse:
141.35.3.16
75 · 256 + 19 = 19219
141.35.3.16:19219
Nach der Übermittlung der IP-Adresse und des
Ports wird der Verbindungsaufbau durch das Senden
eines Befehls initiiert, woraufhin der Server die Datenverbindung zwischen seinem lokalen Port L − 1
und dem Client-Port M etabliert. Abbildung 11.7(b)
stellt den vollständigen Ablauf und der Befehlsfolge
und die Auswirkung auf die Datenverbindung dar.
Allerdings ergeben sich auch im Port-Modus gewisse Schwierigkeiten:
Die für den Server relevanten Daten (IP-Adresse
und Port) werden im Datenbereich eines IP-Pckets
übertragen, weshalb bei Verwendung von Network
Adress Translation (NAT) eventuell Probleme auftreten. NAT übersetzt in der Regel nur die Daten im IPHeader und nicht die im Datenbereich, was zur Folge
hat, dass die an den Server übermittelten Daten außerhalb des lokalen (NAT-)Netzes ungültig sind und
somit keine Datenverbindung zwischen Client und
Server aufgebaut werden kann.
Ein weiteres Problem entsteht durch das feste Format, mit dem IP-Adressen im Port-Modus übermittelt werden. Dieses Format basiert auf IPv4 und ist
somit nicht für IPv6-Adressen geeignet, weshalb das
104
File Transfer Protocol nicht ohne Weiteres zu IPv6
kompatibel ist.
Neben den Schwierigkeiten mit NAT und IPv6
stellt der stetige Portwechsel beim Aufbau der Datenverbindung ein Problem für Firewalls dar. Eine
Firewall muss deshalb in der Lage sein, eingehende Datenverbindungen zu erkennen, um diese nicht
zu blockieren. Dieses Problem lässt sich allerdings
meist durch die Verwendung des Passive-Modus beheben. Eine Lösung für die Schwierigkeiten, die
mit NAT und IPv6 auftreten, bietet dagegen die im
RFC 2428 [AOM98] spezifizierte Erweiterung, die
bisher jedoch kaum Verbreitung gefunden hat.
Passive-Modus Im Passive-Modus erfolgt der
Aufbau der Datenverbindung nicht durch den Server,
sondern direkt durch den Client. Dabei wird die Verbindung zwischen einem frei wählbarem Port M des
Client und einem durch den Server bestimmten Port P
etabliert (vgl. Abbildung 11.8(a)).
Für diese Realisierung ist es vorab notwendig, den
Server von der Verwendung des Passive-Modus in
Kenntnis zu setzen. Dazu sendet der Client den passive-Befehl an den Server. Als Antwort übermittelt
der Server seine IP-Adresse und den Port, zu dem die
Verbindung hergestellt werden soll. Das Format der
IP-Adresse und des Ports ist dabei mit dem Format,
dass für den port-Befehl verwendet wird, identisch.
Nachdem der Client die IP-Adresse und den Port erhalten hat, sendet er den entsprechenden Befehl an
den Server und initiiert den Aufbau der Datenverbindung. Der vollständige Befehlsablauf wird in Abbildung 11.8(b) dargestellt.
11.3. Verbindungs-Management
FTP-Server
FTP-Client
N
PORT a1, a2, a3,
a4, p1, p2
SV
L
successful.
200 PORT command
L
Datenverbindung
Zeitlicher Verlauf
SV
Port M
(passive open)
Steuerverbindung
DV
Port N
M
SV
FTP-Server
FTP-Client
N
N
DV
N
M
L
Aufbau der Datenverbindu
Port L
Port L - 1
(active open)
(a) Port-Verbindungs-Koordination.
<Befehl> [<Paramet
er>]
ng
L-1
connection.
150 Opening data
Datenübertragung
L
L-1
(b) Abfolge der Befehle der Steuerverbindung (SV) und
Auswirkungen auf die Datenverbindung (DV).
Abbildung 11.7.: Aufbau der Datenverbindung im Port-Modus.
FTP-Server
FTP-Client
N
PASV
N
e Mode
227 Entering Passiv
p2).
p1,
a4,
(a1, a2, a3,
Datenverbindung
Zeitlicher Verlauf
SV
Port M
(active open)
Steuerverbindung
DV
Port N
M
SV
FTP-Server
FTP-Client
N
N
DV
SV
L
M
(a) Port-Verbindungs-Koordination.
<Befehl> [<Paramet
er>]
L
Aufbau der Datenverbindu
ng
P
Port L
Port P
passive open)
L
connection.
150 Opening data
Datenübertragung
L
P
(b) Abfolge der Befehle der Steuerverbindung (SV) und
Auswirkungen auf die Datenverbindung (DV).
Abbildung 11.8.: Aufbau der Datenverbindung im Passive-Modus.
105
11. File Transfer Protocol (FTP)
System A
System B
Der Passive-Modus bietet im Unterschied zu
den anderen Modi gewisse Vorteile. Einerseits werDatentransfer-Funktion
Datentransfer-Funktion
den Probleme, die im Standard-Modus durch den
Transformation
Transformation
TIME_WAIT-Zustands auftreten, umgangen, und
Datentransfer
der
der
(1 Byte ´ 8 bit)
Daten
Daten
zum anderen lassen sich einige (jedoch nicht alle) Schwierigkeiten, die durch die Verwendung von
Firewalls auftreten beseitigen. Bezüglich NAT und
DateiDateisystem
system
IPv6 existieren im Passive-Modus allerdings dieselben Nachteile, die auch im Port-Modus vorhanden
sind. Dementsprechend ist es notwendig – mit Blick
auf die zukünftige Entwicklung des Internets – die Abbildung 11.9.: Übertragung der Daten beim
File Transfer Protocol.
Kompatibilität der Client und Server zu IPv6 herzustellen.
11.3.2.1. Datentypen
Durch den Datentyp wird der grundlegende Typ der
Daten festgelegt. Der FTP-Befehl dafür ist:
TYPE <A | E | I | L <byte>>
ASCII-Typ* Beim ASCII-Typ werden die Daten von
der systemspezifischen ASCII-Kodierung in das
8 bit NVT-ASCII-Format umgewandelt und im
5 Während der Entwicklung des File Transfer Protocols existierten auch Systeme, in denen ein Byte nicht durch 8 bit dargestellt
wurde.
106
Beispiel: Darstellung des Zeilenumbruchs
NVT ASCII:
<CR><LF>
Windows:
Linux:
Macintosh:
<CR><LF>
<LF>
<CR>
Da der Zeilenumbruch auf den verschiedenen Systemen unterschiedlich dargestellt wird, kommt es durch
die Transformation zur Datenveränderung. Dementsprechend werden die Daten zwischen Windows-,
Linux- und Macintosh-Systemen folgendermaßen
transformiert:
,
Windows
<CR><LF>
NVT ASCII
<CR><LF>
Linux
<LF>
,
Das File Transfer Protocol wurde unter Berücksichtigung verschiedener Systeme und Architekturen entworfen und ermöglicht dadurch auch den Datentransfer zwischen heterogenen Systemen. Um diese Flexibilität zu erreichen, werden die Daten vor der Übertragung aus dem systemspezifischen Format in eine standardisierte Form umgewandelt, bevor sie nach Abschluss des Transfers in dass auf dem Zielsystem vorhandene Format konvertiert werden. Die Datentransferfunktionen des Client und des Servers sind hier neben der Transformation auch für die Übertragung der
Daten zuständig, die stets byteweise erfolgt. Unabhängig vom System wird ein Byte als eine Folge von
8 bit, dargestellt.5 Ein Überblick über den Datentransfer ist in Abbildung 11.9 dargestellt.
Die Transformation und die Übertragung der Daten
kann durch verschiedene FTP-Befehle gesteuert werden. Allerdings unterstützt die Mehrheit der Implementierungen diese Befehle nur unzureichend, weshalb die Optionen, die am weitesten Verbreitung gefunden haben, im Folgenden mit einem * gekennzeichnet werden.
Anschluss an die Übertragung in die ASCIIRepräsentation des Zielsystems konvertiert. Dabei kann es speziell beim Datentransfer zwischen
heterogenen Systemen zu Datenveränderungen
kommen, da die Daten ohne Transformation auf
unterschiedlichen Systemen nicht korrekt dargestellt werden.
,
11.3.2. Datenübertragung und
Übertragungsmodi
Macintosh
<CR>
EBCDIC-Typ Der EBCDIC-Typ ermöglicht die effiziente Übertragung von Textdateien, wenn der
Client und der Server das EBCDIC Format verwenden.
Image/Binary-Typ* Beim Image-Typ werden die
Daten als Folge von Bits übertragen, wobei keine
Transformationen stattfinden.
Local-Typ Der Local-Typ erlaubt die Festlegung
der logischen Bytegröße, wodurch der Transfer
11.3. Verbindungs-Management
Für den ASCII- und den EBCDIC-Typ kann ein optionaler Parameter angegeben werden, der die zu verwendende Formatierung festlegt. Der FTP-Befehl für
die Formatsteuerung lautet:
N
QUIT
SV
L
221 Goodbye.
L
N
SV
11.3.2.2. Formatsteuerung
FTP-Server
FTP-Client
Zeitlicher Verlauf
zwischen Systemen mit unterschiedlichen Bytegrößen möglich wird.
N
Abbau der Steuerverbindung
L
Abbildung 11.10.: Abbau der Steuerverbindung.
TYPE <A [N|T|C] | E [N|T|C]>
Non-Print* Die Datei enthält keine zusätzlichen
Formatinformationen.
Telnet Format Control Die Datei enthält TelnetFormatinformationen.
Carriage Control (ASA) Die
Datei
Fortran-(ASA-)Formatinformationen.
enthält
11.3.2.3. Struktur der Daten
Neben dem Datentyp und der Formatsteuerung lässt
sich auch die interne Struktur der zu übertragenden
Dateien festlegen. Der FTP-Befehl für die Datenstrukturierung ist:
• Page-Strukturen durch die Festlegung einer
Last Page signalisiert.
Block -Modus Die Daten werden blockweise übertragen. Jeder Block besteht dabei aus einem
Header und den Nutzdaten. Das Dateiende wird
im Header festgelegt.
Compressed-Modus Die Daten werden blockweise übertragen und durch eine einfache Lauflängenkodierung komprimiert. Ein Block enthält
einen Header und die Nutzdaten.
11.3.3. Verbindungsabbau und
Wiederaufnahme der
File-Struktur* Die Dateien haben keine interne
Übertragung
STRU <F|R|P>
Struktur und sind zusammenhängend.
Im letzten Teil des Abschnitts „VerbindungsRecord-Struktur Die Dateien werden aus sequen- Management“ wird gezielt auf den Abbau der
tiellen Datensätzen aufgebaut.
Steuer- und Datenverbindung eingegangen, bevor
Page-Struktur Die Dateien sind nicht zusammen- abschließend der im File Transfer Protocol spezihängend und bestehen aus mehreren Teilen (so- fizierte Mechanismus zur Wiederaufnahme einer
abgebrochenen Übertragung erläutert wird.
genannten pages).
11.3.2.4. Übertragungsmodi
11.3.3.1. Abbau der Steuerverbindung
Der Übertragungsmodus legt fest, mit welcher Methode die Daten übertragen werden. Der FTP-Befehl zu
Wahl des Übertragungsmodus ist:
Mit dem Schließen der Steuerverbindung wird eine
FTP-Sitzung beendet. Wie Abbildung 11.10 zeigt, initiiert der Client den Abbau durch das Senden des Befehls quit. Nach der Übermittlung der Antwort wird
die Steuerverbindung entweder durch den Client oder
den Server geschlossen.
MODE <S|B|C>
Stream-Modus* Die Daten werden als kontinuierlicher Bytestrom übermittelt. Das Dateiende 11.3.3.2. Abbau der Datenverbindung
wird bei:
Die Datenverbindung wird im Unterschied zur Steu• File-Strukturen durch das Schließen der erverbindung nur temporär während der DatenüberDatenverbindung signalisiert.
tragung benötigt. Deshalb wird die Datenverbindung
• Record-Strukturen durch End-Of-Record- nach Beendigung des Transfers geschlossen. Der Ab(EOR-) und End-Of-File-(EOF-)Markie- bau zählt dabei primär zur Aufgabe des Servers und
rungen signalisiert.
erfolgt in den folgenden Fällen:
107
11. File Transfer Protocol (FTP)
FTP-Server
SV
FTP-Client
N
N
Spezifikation des Übertragungsmodus
(Standard-, Port-, Passivmodus)
L
soll, an den Server. Anschließend wird der Datentransfer durch den Befehle store oder retrieve initiiert.
Die Wiederaufnahme ist allerdings nur beim ImageTyp möglich.
REST <Byte-Positi
on>
SV
N
N
RETR|STOR <Paramete
r>
L
11.4. Das File eXchange
Protocol
L
Das File eXchange Protocol (FXP) ist eine Erweiterung des File Transfer Protocol, die im RFC 959
spezifiziert wird und den direkten Datentransfer zwischen zwei FTP-Servern ermöglicht. FXP stellt allerdings kein eigenes Protokoll dar, es verwendet lediglich verschiedene Eigenschaften des File Transfer
Protocol, um die Übertragung zwischen zwei Servern
zu ermöglichen. Dazu werden, in Analogie zu Abbildung 11.12, zwei Steuerverbindungen von einem
FTP-Client zu den entsprechenden Servern aufgebaut.
Im Falle einer Datenübertragung wird die Datenverbindung nicht zwischen dem Client und den Servern,
sondern direkt zwischen den Servern etabliert.
Durch die Verwendung von FXP ergeben sich folgende Vorteile: Die Datenübertragung findet direkt
zwischen den Servern statt und wird nicht indirekt
über den Client abgewickelt. Dadurch wird die Netzwerkverbindung des Client nicht unnötig belastet und
die CPU-Auslastung des Client ist geringer. Die Übertragungsraten werden nicht durch den Client, sondern
nur durch die Verbindung zwischen den Servern bestimmt. Somit kann unabhängig vom Client ein sehr
hoher Durchsatz erreicht werden, wenn die Server eine sehr schnelle Anbindung haben.
FXP wird in der Regel vom normalen Anwender
nicht benötigt, findet aber speziell bei Administratoren, die verschiedene Server verwalten und große Datenmengen transferieren müssen, Anwendung. Daneben hat FXP auch in der sogenannten Warez-Szene
seine Anhängerschaft gefunden, die es zur schnellen
Verbreitung von Dateien verwenden. FXP ermöglicht
allerdings auch den Missbrauch des Protokolls durch
die sogenannte FTP Bounce Attack, bei der der Client
eine Verbindung zu einem FTP-Server aufbaut und
versucht, über diesen Zugriff zu einem anderen Rechners zu erlangen. Auf öffentlich zugänglichen Systemen ist FXP deshalb in der Regel deaktiviert.
FXP basiert grundsätzlich auf denselben Mechanismen, die auch bei dem einfachen Client-Server
Modell des File Transfer Protocols Anwendung finden. Allerdings existieren beim Aufbau der Datenverbindung gewisse Besonderheiten, da diese zwischen
den beiden Servern etabliert wird. Die Befehlsabfol-
Aufbau der Datenverbindung
DV
DV
SV
Zeitlicher Verlauf
SV
L
<...>
350 Restarting at
VE to
RIE
RET
Send STORE or
initiate Transfer.
connection.
150 Opening data
L
N
Datenübertragung
Abbildung 11.11.: Befehlsabfolge bei der Wiederaufnahme der Datenübertragung.
• Wenn der Server das Ende der Übertragung nur
durch das Schließen der Datenverbindung anzeigen kann.
• Falls der Client den abort-Befehl an den Server
sendet.
• Wenn der Client mit einer Anweisung den Port
ändert.
• Wenn die Datenverbindung geschlossen wird.
• Falls nicht behebbare Fehler auftreten.
Der Client schließt die Verbindung nur dann, wenn
die Daten, die er an den Server sendet (z. B. mittels
store), vollständig übertragen worden sind, und das
Ende des Transfers nur durch den Verbindungsabbau
mitgeteilt werden kann.
11.3.3.3. Wiederaufnahme der
Datenübertragung
Im Falle einer Unterbrechung des Datentransfers ermöglicht das File Transfer Protocol die Wiederaufnahme der Übertragung durch die in Abbildung 11.11
dargestellte Befehlsabfolge.
Der Client spezifiziert dazu den Übertragungsmodus und sendet den Befehl restart mitsamt der BytePosition, an der die Übertragung fortgesetzt werden
108
11.4. Das File eXchange Protocol
FTP-Client
Anwender
Anwender
Schnittstelle
FTP-Server
Server
Protokoll
Interpreter
Steuer
verbindung
Server
Datentransfer
Funktion
Dateisystem
Anwender
Protokoll
Interpreter
FTP-Server
Steuer
verbindung
Server
Protokoll
Interpreter
Server
Datentransfer
Funktion
Datenverbindung
Dateisystem
Abbildung 11.12.: Darstellung einer FXP-Verbindung zwischen einem Client und zwei Servern.
FTP-Server A
SV
PASV
N1
L
L
227 Entering Passiv
e Mode
(a1, a2, a3, a4,
p1, p2).
N1
N2
PORT a1, a2, a3,
a4, p1, p2
SV
L
successful.
200 PORT command
L
SV
N2
STOR <Parameter>
RETR <Parameter>
N1 N2
L
DV
Zeitlicher Verlauf
FTP-Server B
FTP-Client
L
Aufbau der Datenverbindung
L-1
SV
L
DV
P
P
150 Opening data
connection.
connection.
150 Opening data
L
N1 N2
Datenübertragung
L-1
Abbildung 11.13.: Befehlsabfolge zum Aufbau der Datenverbindung beim File eXchange Protocol.
109
11. File Transfer Protocol (FTP)
ge verläuft dabei analog zu Abbildung 11.13. Nachdem der Client die Steuerverbindung zu beiden Servern aufgebaut hat, sendet er an Server A den passive-Befehl und erhält dadurch dessen IP-Adresse und
den Port zu dem die Verbindung aufgebaut werden
soll. Diese Daten sendet der Client anschließend mit
dem port-Befehl an Server B. Nachdem der Client
das store- und retrieve-Kommando an den jeweiligen Server übermittelt hat, öffnet A seine Verbindung
passiv, während B den Aufbau der Datenverbindung
durch ein active open initiiert. Der Datentransfer beginnt, nachdem beide Server die entsprechende Antwort an den Client gesendet haben.
11.5. Fazit
Das File Transfer Protocol wurde als Protokoll zur
Datenübertragung entwickelt und ist seit 1985 standardisiert. Dabei unterscheidet es sich von anderen Übertragungsarten insbesondere dadurch, dass es
zwei TCP-Verbindungen verwendet.
Bei genauerer Betrachtung offenbart das Protokoll allerdings einige Schwachstellen. So existieren neben den verschiedenen Problemen mit Firewalls und der NAT-Adressübersetzung insbesondere
sicherheitstechnische Mängel, da das Protokoll über
praktisch keine Verschlüsselungsmechanismen verfügt und somit aus sicherheitstechnischer Sicht mangelhaft ist. Dementsprechend sollte in sicherheitskritischen Bereichen Alternativen wie dem SSH File
Transfer Protocol der Vorzug gegeben werden. Weil
FTP in der ursprünglichen Form nur IPv4-kompatibel
ist, ergeben sich hinsichtlich IPv6 ebenfalls gewisse
Schwierigkeiten, da eine Erweiterung für IPv6 zwar
existiert, bisher jedoch von den wenigsten Implementierungen eingesetzt wird.
Trotz dieser Probleme wird das File Transfer
Protocol auch in der Zukunft in vielen Bereichen Verwendung finden, da es eine sehr effektive Möglichkeit
bietet, Daten über das Internet zur übertragen und einem großen Personenkreis zur Verfügung zu stellen.
110
12. Simple Mail Transfer Protocol (SMTP)
Qiguang Yan
12.1. Einleitung
E-Mail (von Electronic Mail), einer der am häufigsten
benutzten Internetdienste, bezeichnet eine auf elektronischem Weg in Computernetzwerken übertragene, briefartige Nachricht. Um E-Mails zu verschicken,
wird das SMTP-Protokoll benutzt. SMTP ist die Abkürzung für Simple Mail Transfer Protocol und liegt
in der Anwendungsschicht im TCP/IP-Protokollstapel
(Tabelle 12.1). Die Kommunikation erfolgt über den
Port 25.
Im Abschnitt 12.2 werden das dem SMTPProtokoll zu Grunde liegende Modell und die
Funktionsweise vorgestellt. Danach werden im Abschnitt 12.3 die SMTP-Befehle und SMTP-StatusCodes besprochen. Anschließend wird ESMTP im
Abschnitt 12.4 erklärt. Besondere Aufmerksamkeit wird dabei den ESMTP-Befehlen AUTH und
STARTTLS gewidmet. Anhand eines Beispiels wird
gezeigt, wie die wichtigsten ESMTP-Befehle zum
Versenden einer E-Mail verwendet werden. Daran anschließend wird im Abschnitt 12.5 zwischen „Offenem Mail-Relay“ und „SMTP-Relay-Server“ unterschieden. Im Abschnitt 12.6 wird der Ablauf des EMail-Routings betrachtet. Dabei wird anhand geeigneter Beispiele gezeigt, wie der MX-Record zur Zustellung von E-Mails verwendet wird. Der Aufbau der
E-Mail wird im Abschnitt 12.7 besprochen. Besondere Aufmerksamkeit wird der Received-Zeile und MIME gewidmet. Abschließend wird im Abschnitt 12.8
eine kurze Zusammenfassung gegeben.
TCP/IP-Schicht
Anwendung
Transport
Internet
Netzwerk
Protokoll
SMTP
TCP
IP (IPv4, IPv6)
Ethernet Token Ring
...
Tabelle 12.1.: SMTP im TCP/IP-Protokollstapel.
E-Mail-Benutzer verwenden einen Benutzeragenten, um Nachrichten zu lesen und zu schreiben. EMail-Nachrichten enthielten ursprünglich nur Text,
aber der so genannte MIME-Standard (siehe Abschnitt 12.7.2) erlaubt heute auch Textformatierung
und Anhänge für E-Mail. Er wird von den meisten
Benutzeragenten unterstützt. Ursprünlich war unter
UNIX /bin/mail der Benutzeragent. Heute gibt es
mehrere Alternativen. Die gebräuchlichsten Benutzeragenten sind z. B. mh, pine, mutt für UNIX/Linux
und Outlook für Windows.
Ein Transportagent muss die Mail von einem Benutzeragenten übernehmen, die Adresse des Empfängers verstehen und die Mail an den entsprechenden
Host ausliefern. Für UNIX- und Linux-System stehen
mehrere Transportagenten zur Verfügung, beispielsweise sendmail postfix oder qmail.
Die vom Benutzer erstellten Nachrichten werden
vom Benutzeragenten in eine Warteschlange gestellt,
die der Transportagent verwaltet. Der Transportagent wartet, bis Nachrichten in seine Warteschlange gestellt werden. Dann überträgt er eine Kopie
der Nachrichten an die jeweiligen Empfänger. Um
Nachrichten an den entfernten Empfänger zu sen12.2. Funktionsweise
den, baut der Transportagent des Senders eine TCPVerbindung auf. Steht die Verbindung, arbeiten die
Das SMTP-Design basiert auf einem Kommunikati- beiden Transportagenten mit dem SMTP-Protokoll,
onsmodell nach Abbildung 12.1. In diesem Modell mit dem sich der Sender identifiziert, Empfängegibt es einen Benutzeragenten (Mail User Agent – radressen angibt und die Nachricht überträgt. Der
MUA) und einen Transportagenten (Message Transfer Transportagent des Senders fungiert dabei als SMTPAgent – MTA), welches die Hauptkomponenten des Client, der Transportagent des Empfängers als SMTPMail-Systems sind.
Server. Der SMTP-Client sendet die Nachrichten an
111
12. Simple Mail Transfer Protocol (SMTP)
Abbildung 12.1.: SMTP-Kommunikationsmodell.
den SMTP-Server, der eine Kopie der Nachricht in die
Mailbox des Empfängers stellt.
tigen SMTP-Status-Codes sind in der Tabelle 12.3
aufgelistet.
12.3. SMTP-Befehle und
SMTP-Status-Code
12.4. Extended SMTP (ESMTP)
Für den Austausch der E-Mails sind die Transportagenten zuständig. Untereinander verständigen sich
die Transportagenten mit ASCII-Kommandos. Dabei sendet der SMTP-Client dem SMTP-Server ein
Kommando und dieser antwortet mit einem StatusCode und einer Klartext-Meldung. In diesem Abschnitt werden die SMTP-Befehle und SMTP-StatusCodes diskutiert.
12.3.1. SMTP-Befehle
Die Kommunikation zwischen SMTP-Client und
SMTP-Server basiert auf ASCII-Kommandos.
Laut SMTP-Spezifikation muss eine SMTPImplementierung mindestens die folgenden acht
Kommandos laut Tabelle 12.2 unterstützen.
12.3.2. SMTP-Status-Code
Auf jedes Kommando vom SMTP-Client an den
SMTP-Server schickt der Server einen 3-stelligen
Status-Code mit Klartext-Meldung zurück. Die wich-
112
Als SMTP 1982 durch RFC 821 [Pos82] definiert
wurde, war die Anzahl von Hosts im Internet überschaubar. Da die Verbindungen langsam und instabil
waren, wurde auf Zuverlässigkeit großer Wert gelegt.
Authentifikation war nicht vorgesehen, somit war jeder Mailserver ein Open Relay (Abschnitt 12.5.1),
über den Mails an jeden anderen Knoten weitergeleitet werden konnten. Viele Jahre lang stellte dies auch
kein Problem dar, doch dann brach die Zeit der Spammer und des Werbemülls an, gefälschte Virenwarnungen und Würmer überschwemmten das Medium EMail [Wik06e].
1995 wurde mit Extended SMTP (ESMTP) durch
RFC 1869 [KFR+ 95] das Protokoll erweitert. ESMTP
erweitert SMTP um die Möglichkeit der Authentifikation per Passwortabfrage, um Spammern die Benutzung fremder SMTP-Gateways zu verwehren. Nutzt
ein E-Mail-Client die Erweiterungen von ESMTP,
meldet er sich beim SMTP-Server mit dem Kommando EHLO an. Antwortet der Server mit einer Fehlermeldung, kennt er ESMTP nicht und der Client muss
sich mit HELO anmelden.
In Tabelle 12.4 sind einige ESMTP-Befehle beschrieben, die sehr häufig benutzt werden. Die
12.4. Extended SMTP (ESMTP)
Kommando
Beschreibung
HELO
MAIL
RCPT
HELO startet die SMTP-Sitzung und identifiziert den Client am Server.
MAIL leitet die Mailübertragung ein und liefert gleich die Absender-Adresse mit.
RCPT gibt die Adresse eines oder mehrerer Empfänger an. Dieses Kommando kann deshalb
mehrmals ausgeführt werden.
Mit DATA wird die Übermittlung der eigentlichen E-Mail-Nachricht eingeleitet. Das Ende
wird mit <CR><LF>.<CR><LF> gekennzeichnet.
Mit RSET wird die bereits eingeleitete Mailübertragung abgebrochen. Die Verbindung zwischen Client und Server bleibt bestehen.
NOOP bewirkt eine Antwort vom Server. Damit wird die Verbindungstrennung durch einen
Timeout verhindert.
QUIT beendet die Verbindung zum SMTP-Server. Der Server liefert eine letzte Antwort
zurück.
DATA
RSET
NOOP
QUIT
Tabelle 12.2.: Grundlegende SMTP-Befehle.
Code
Beschreibung
211
214
220
221
250
251
252
354
421
450
451
452
500
501
502
503
504
550
551
552
553
554
System-Status oder System-Hilfe
Hilfe – Informationen zum Ausführen eines Kommandos
Server bereit
Server beendet Verbindung
Kommando ausgeführt
Keine lokale Mailbox – Weiterleitung an “forward path“
Überprüfung der Empfängeradresse nicht möglich – die Nachricht wird dennoch versendet
Starte Empfang der Mail – Beenden mit <CR><LF>.<CR><LF>
Service nicht verfügbar – Verbindung wird beendet
Aktion nicht ausgeführt – Mailbox nicht verfügbar
Aktion abgebrochen – Fehler beim Ausführen
Aktion abgebrochen – Nicht genügend System-Speicher
Syntax-Fehler – Kommando unbekannt
Syntax-Fehler – Parameter oder Argument falsch
Kommando nicht implementiert
Falsche Reihenfolge der Kommandos
Parameter unbekannt / nicht implementiert
Syntax-Fehler – Kommando unbekannt
Mailbox nicht lokal – “forward path“ versuchen
Aktion abgebrochen – Fehler bei der Speicherzuweisung
Aktion nicht ausgeführt – Mailbox-Name nicht erlaubt (Syntax inkorrekt)
Transaktion fehlgeschlagen (beim Verbindungsaufbau: Kein SMTP-Service verfügbar)
Tabelle 12.3.: Übersicht der SMTP-Status-Codes.
113
12. Simple Mail Transfer Protocol (SMTP)
ESMTP-Kommando
Beschreibung
8BITMIME
Mit 8BITMIME gibt der Server an, dass er die Verwendung des 8 bit-ASCIIZeichensatzes im Nachrichtentext erlaubt.
Mit SIZE gibt der SMTP-Server die maximale E-Mail-Größe in Byte an, die er
akzeptiert.
Mit EHLO meldet sich der ESMTP-Client beim SMTP-Server an und teilt ihm
auf diese Weise mit, dass er die ESMTP-Erweiterungen beherrscht.
Mit STARTTLS teilt der Server dem Client mit, dass er eine Verschlüsselung per
TLS wünscht. Mit dem Kommando STARTTLS leitet der Client dann die Verschlüsselung ein.
Durch die Einführung des Befehls AUTH wird eine Authentifikation mit Nutzername und Kennwort am Mailserver ermöglicht.
SIZE
EHLO
STARTTLS
AUTH
Tabelle 12.4.: ESMTP-Befehle.
Tabelle ist nicht vollständig. In den Abschnitten
12.4.1 und 12.4.2 werden die Befehle AUTH und
STARTTLS ausführlich erklärt. Anschließend wird in
Abschnitt 12.4.3 ein Beispiel vorgestellt.
12.4.1. AUTH
SMTP-AUTH bedeutet Authentifikation beim Mailversand. Der wichtigste Grund dafür ist, Benutzern
mit dynamischen IP-Adressen eine Möglichkeit zur
Identifikation gegenüber dem Transportagent zu geben. Dies wurde durch die Einführung des neuen Befehls AUTH ermöglicht. Nun bieten sich hier mehrere Möglichkeiten, das Passwort zu übermitteln. Der
wohl einfachste Weg ist AUTH PLAIN, bei dem das
Passwort im Klartext übermittelt wird. Dies ist im
heutigen Internetzeitalter nicht mehr zumutbar. Deswegen existieren Möglichkeiten, das Passwort verschlüsselt zu übermitteln. Bei der Benutzung von
TLS kann man jedoch gefahrlos AUTH PLAIN benutzen [Mye99].
12.4.2. STARTTLS
TLS bzw. SSL ist eine Möglichkeit, Datenverkehr auf
Layer 3 zu verschlüsseln. Bei SMTP wird TLS benutzt. Dies geschieht nach dem EHLO-Kommando
durch das Senden von STARTTLS. „Sprechen“ ein
SMTP-Client und ein SMTP-Server beide TLS, einigen sie sich von alleine auf die sichere Übertragung.
Dazu tauschen die beiden Rechner bei der Begrüßung,
dem Handshake, Zertifikate aus, mit denen sie sich
gegenseitig authentifizieren. Sie zeigen sich sozusagen die Personalausweise. Im Mail-Verkehr ist es aus
pragmatischen Gründen in der Regel so, dass sich
nur der die Mail entgegennehmende Server gegenüber dem Client ausweist. Ob der Client ein anderer
114
Mailserver ist, der Nachrichten weiterleiten will, oder
das Mail-Programm eines Users, ist dabei gleichgültig. Nun, da der Client dem Server vertrauen kann, einigen sich beide auf einen Verschlüsselungsalgorithmus und die geheimen Sitzungsschlüssel, mit der sie
den nachfolgenden Datenverkehr für Außenstehende
unlesbar machen [Hof99].
12.4.3. ESMTP-Beispiel
Das folgende Beispiel zeigt, wie die wichtigsten
ESMTP-Befehle zum Versenden einer E-Mail verwendet werden.
Zuerst stellen wir über Telnet eine Verbindung zu
einem SMTP-Server her. Der Port ist bei SMTPServern meist 25.
C: telnet mail.example.org 25
S: 220 mail.example.org ESMTP
Nach dem Verbindungsaufbau meldet sich der
Mailserver mit einer einzelnen Zeile. Sie enthält neben einem Erfolg-Statuscode (220) den Rechnernamen. Das Schlüsselwort ESMTP zeigt, dass eine erweiterte Version von SMTP akzeptiert wird.
Um die Verbindung zu initialisieren, begrüßen wir
den SMTP-Server mit einem freundlichen EHLO. Der
Befehl erwartet einen Parameter, der der Name des
SMTP-Servers ist.
C: EHLO example.net
S: 250 example.org Hello example.net
250 AUTH CRAM-MD5 LOGIN PLAIN
250 STARTTLS
250 8BITMIME
250 SIZE
Der SMTP-Server reagiert auf diese Begrüßung
und zeigt zusätzlich noch einige Befehle an, die vom
SMTP-Server unterstützt werden.
12.5. Mail-Relaying
Mit dem Befehl STARTTLS leitet der Client dann
die Verschlüsselung ein. Der Befehl soll vor den anderen Befehlen ausgeführt werden.
C: STARTTLS
S: 220 Go ahead
AUTH ermöglicht eine Authentifikation mit Nutzername und Kennwort am Mailserver. Die folgenden Zeilen demonstriert die Authentifikation mittels
des LOGIN-Verfahrens. Somit erfolgt eine Base64Kodierung (Abschnitt 12.7.2) des Benutzernamens
„hans“ [Wik06f].
C:
S:
C:
S:
C:
S:
AUTH LOGIN
334 VXNlcm5hbWU6
aGFucw==
334 UGFzc3dvcmQ6
c2Nobml0emVsbWl0a2FydG9mZmVsc2FsYXQ=
235 ok
Eine neue E-Mail beginnt immer mit dem Befehl
MAIL. Da wir gleichzeitig den Absender festlegen
möchten, können wir dies über MAIL FROM tun.
C: MAIL FROM: <[email protected]>
S: 250 ok
Wir können einen oder mehrere Empfänger über
das Kommando RCPT TO spezifizieren. Für mehrere
Empfänger wird das Kommando mehrere Male hintereinander eingegeben.
C: RCPT TO: <[email protected]>
S: 250 ok
Das DATA-Kommando leitet die eigentliche Mail
ein. Der MTA wechselt vom Kommando- in den Datenmodus, den er durch einen einzelnen Punkt ganz
am Ende des Textes wieder verlässt. Zur Mail gehören
Header (wieder mit Absender- und Empfängeradresse) und Body (Abschnitt 12.7):
C:
S:
C:
C:
C:
DATA
354 Go ahead.
From: <[email protected]>
To: <[email protected]>
Subject: Hallo
C: Hallo Fritz. Willkommen!
C: .
S: 250 Mail delivered.
Bleibt nur noch der Abschied:
C: QUIT
S: 221 smtp.web.de closing connection
12.5. Mail-Relaying
Man stellt E-Mails in der Regel nicht selbst zu, sondern liefert sie bei einem Mailserver seines Providers
ein, der sich dann um den Weitertransport kümmert.
Der Mailserver des Providers findet dann heraus, welcher Server die Mail für den Empfänger entgegennimmt und leitet sie entsprechend weiter. Beispielsweise schicken Kunden von T-Online ihre ausgehenden E-Mails an mailto.t-online.de, von wo sie dann
weiterverschickt werden. Diese Server werden auch
als Relay-Server bezeichnet, denn sie dienen nur als
Zwischenstation (Relay) für die E-Mails.
12.5.1. Offenes Mail-Relay
Als Offenes Mail-Relay wird ein Rechner B bezeichnet, der von jedem beliebigen Rechner A E-Mail annimmt und an beliebige Dritte C weiterleitet, obwohl
er weder für Mail von A noch für Mail an C zuständig
ist [Wik06c].
Über offene Mail-Relays können von außerhalb
kriminelle Inhalte oder Malware (z. B. Spam, Viren,
Phishing-Mails und Drohungen) verbreitet werden.
Dabei werden die Ressourcen des eigentlichen Verursachers (Bandbreite und Hardware) gespart und seine Identität bleibt gegenüber den Mail-Empfängern
verschleiert. Zur Lösung dieses Problems gibt es
verschiedene Methoden, z. B. SMTP AUTH als Erweiterung des SMTP-Protokolls (Abschnitt 12.4.1),
SMTP-after-POP und Verwendung eines SMTPRelay-Servers.
12.5.2. SMTP-Relay-Server
Als SMTP-Relay-Server, Mail-Relay-Server oder
Smarthost wird ein Mail-Server B bezeichnet, der von
einem Sender A E-Mail annimmt und an beliebige
Dritte C weiterleitet [Wik06g].
Anders beim offenen Mail-Relay nehmen SMTPRelay-Server entweder nur E-Mails der eigenen Kunden entgegen und leiten diese weiter, oder nehmen
Mails von überall an und leiten diese nur an die eigenen Kunden weiter.
12.5.3. Beispiele
In diesem Beispiel hat das Relay-System den
SMTP-Relay-Server mailhost in der lokalen Domain
tuc.noao.edu. Der SMTP-Relay-Server nimmt alle EMails von den Sendern in dieser Domain an. Wir können den Befehl host ausführen und betrachten, wie
sein DNS-Name definiert ist.
115
12. Simple Mail Transfer Protocol (SMTP)
Abbildung 12.2.: Ein Relay-System von zwei Organisationen.
sun% host mailhost
mailhost.tuc.noao.edu CNAME noao.edu
noao.edu
A 140.252.1.54
Alle Transportagenten in diesem Beispiel benutzen
SMTP.
Die Antwort des Befehls host enthält zwei
Zeilen. In der ersten Zeile handelt es sich um
ein CNAME Resource-Record (Details siehe Abschnitt 10.2.4). Die erste Zeile gibt an, dass der
DNS-Name mailhost.tuc.noao.edu als noao.edu definiert ist. In der zweiten Zeile wird mittels eines A
Resource-Record dem DNS-Namen noao.edu die IPAdresse 140.252.1.54 zugeordnet. Wenn der SMTPRelay-Server in der Zukunft geändert wird, brauchen
nur die Informationen im DNS geändert zu werden.
Die Mailkonfiguration jedes einzelnen Rechner in
dieser Domain braucht sich nicht zu ändern.
Viele Organisationen benutzen heute ein RelaySystem. Die Abbildung 12.2 zeigt zwei Organistionen, die SMTP-Relay-Server verwenden. In diesem
Beispiel gibt es vier Transportagenten zwischen Sender und Empfänger. Der lokale Transportagent auf
dem Sender-Host in Organistion A leitet die E-Mail
nur an seinen Relay-Transportagenten weiter. Dies erfolgt mittels einer SMTP-Verbindung im lokalen Netz
der Organisation. Der Relay-Transportagent in Organisation A leitet die E-Mail über das Internet an den
Relay-Transportagent in der Organisation B weiter,
der die E-Mail an den Host des Empfängers sendet.
12.6. E-Mail-Routing über
SMTP und DNS
116
Nachdem der SMTP-Relay-Server eine E-Mail von
einem E-Mail-Client entgegengenommen hat, ist er
für das Weiterleiten an den Ziel-SMTP-Server verantwortlich. Das DNS spielt wie bei den Protokollen
HTTP und FTP eine zentrale Rolle. Im DNS sind spezielle Einträge für die elektronische Post vorhanden:
die Mail Exchange Records (MX-Records). Über diese Einträge identifiziert der SMTP-Server den ZielSMTP-Server der Domain, die in der E-Mail-Adresse
des Empfängers angegeben ist. In den folgenden Beispielen, die Stevens’ Buch [Ste94] entnommen sind,
wird ausführlich diskutiert, wie der MX-Record zum
Senden der E-Mail verwendet wird.
12.6.1. Beispiel: MX-Record
Der Host mlfarm.com ist nicht direkt mit dem Internet
verbunden. Er hat zwei MX-Records, die auf zwei mit
dem Internet verbundene SMTP-Server verweisen.
sun% host -a -v -t mx mlfarm.com
12.6. E-Mail-Routing über SMTP und DNS
mlfarm.com
mlfarm.com
IN MX 10 mercury.hsi.com
IN MX 15 hsi86.hsi.com
Additional information:
mercury.hsi.com IN A 143.122.1.91
hsi86.hsi.com
IN A 143.122.1.6
3
0.505739 (0.0602)
sun.1143 > mercury.hsi.com.25 :
S 1617536000:1617536000(0) win 4096
4
0.985428 (0.4797)
mercury.hsi.com.25 > sun.1143:
S 1832064000:1832064000(0)
ack 1617536001 win 16384
5
0.986003 (0.0006)
sun.1143> mercury.hsi.com.25:
. ack 1 win 4096
6
1.735360 (0.7494)
mercury.hsi.com.25 > sun.1143:
P 1:90(89) ack 1 win 16384
Wir senden jetzt eine E-Mail an dem Host mlfarm.com.
sun% mail -v [email protected]
To: [email protected]
Subject: MX test message
.
Dann erhalten wir die folgenden Nachrichten:
Sending letter ... [email protected]...
Connecting to mlfarm.com via tcp...
mail exchanger is mercury.hsi.com
Trying 143.122.1.91...connected
220 mercury.hsi.com ...
In den Zeilen 3 bis 5 baut der Host sun mit dem
SMTP-Server des Hosts mercury.hsi.com eine TCPVerbindung auf. Der SMTP-Server schickt in der Zeile 6 einen Status-Code 220 zurück (Abschnitt 12.3.2).
Das bedeutet, dass der Transportagent eine DNS- Das Beispiel wird in der Abbildung 12.3 veranschauAbfrage nach den Mail Exchangern für mlfarm.com licht.
macht. Wenn er eine Antwort bekommt, sucht er sich
den MX mit der kleinsten Priorität heraus, in unserem 12.6.2. Beispiel: Zielhost nicht
Beispiel 10, und macht eine erneute DNS-Abfrage,
erreichbar
um die IP-Adresse des MX zu bekommen.
Wir können mittels tcpdump diese SMTP- Wenn ein Zielhost nicht erreichbar ist, können wir
Verbindung mitschneiden. Vor dem Senden der E- mittels MX-Records nach weiteren Mail Exchangern
Mails vom Host sun soll er so konfiguriert werden, suchen. Dies wird an folgendem Beispiel verdeutlicht.
Wir können mittels des Programms host ermitteln,
dass er kein Relay verwendet. Das Ziel ist, dass
die SMTP-Verbindung zwischen den Hosts sun und dass der Host sun zwei MX-Records hat.
mercury.hsi.com betrachtet werden kann. Weiterhin
wird der Host noao.edu als Nameserver benutzt. Die sun% host -a -v -t mx sun.tuc.noao.edu
sun.tuc.noao.edu MX 0 sun.tuc.noao.edu
mittels tcpdump mitgeschnittenen Pakete sehen wie
sun.tuc.noao.edu MX 10 noao.edu
folgt aus:
1
0.0 sun.1624 > noao.edu.53:
2+ MX? mlfarm.com.
2
0.445572 (0.4456)
noao.edu.53 > sun.1624:
2* 2/0/2 MX mercury.hsi.com. 10
Additional information:
sun.tuc.noao.edu A 140.252.1.29
sun.tuc.noao.edu A 140.252.13.33
noao.edu
A 140.252.1.54
Nachdem
der
SMTP-Server
des
Hosts
sun.tuc.noao.edu abgeschaltet worden ist, senden wir
In der ersten Zeile macht der Transportagent ei- eine E-Mail vom Host vangogh.cs.berkeley.edu zu
ne DNS-Abfrage nach den Mail Exchangern für ml- ihm. Dies sieht wie folgendes aus:
farm.com. Das Plus-Zeichen nach der 2 steht für
das Setzen des recursion-desired-Flags (siehe Ab- % mail -v [email protected]
schnitt 10.3). Die Antwort in der Zeile 2 zeigt, dass A test to a host that’s down.
EOT
das authoritative-answer-Flag gesetzt ist (das Sternchen nach 2). Das impliziert, dass der Namenserver [email protected]... Connecting
noao.edu zuständig für die Domain mlfarm.com ist. to sun.tuc.noao.edu. (smtp)...
2/0/2 bedeutet, dass zwei Antwort-RR (die zwei MXRR), keine Authority-RR und zwei zusätzliche A-RR [email protected]... Connecting
(die zwei IP-Adressen der Hosts in MX-RR) in der to noao.edu. (smtp)...
220 noao.edu
Antwort enthalten sind.
117
12. Simple Mail Transfer Protocol (SMTP)
Abbildung 12.3.: E-Mail-Routing über SMTP und DNS.
Der SMTP-Server sucht sich zuerst den MX
mit der kleinsten Priorität heraus. In unserem Beispiel wird der Zielhost sun.tuc.noao.edu zum Senden ausgewählt. Dann verbindet sich der Host vangogh.cs.berkeley.edu mit dem Host sun.tuc.noao.edu.
Der Host sun.tuc.noao.edu ist nicht erreichbar. Anschließend versucht vangogh.cs.berkeley.edu es mit
dem nächsten MX-Record mit höherer Priorität,
nähmlich noao.edu. Der Host noao.edu ist erreichbar und liefert einen Status-Code 220 zurück (Abschnitt 12.3.2).
Wir können mittels tcpdump diese SMTPVerbindung mitschneiden. Die Pakete sehen wie folgt
aus:
Der Verbindungsaufbau wird von sun abgelehnt in
der Zeile 2. Anschließend versucht es vangogh mit
der nächsten IP-Adresse für sun (140.252.13.33). Der
Verbindungsaufbau wird wieder abgelehnt in der Zeile 3.
Der SMTP-Client kann nicht zwischen den verschiedenen Fehlermeldungen vom SMTP-Server unterscheiden. Das führt dazu, dass der SMTP-Client
die nächste IP-Adresse versucht, wenn eine IPAdresse nicht erreichbar ist. In manchen Fällen ist es
nicht günstig. Im Fall von „host unreachable“ kann
z. B. dieselbe IP-Adresse beim zweiten Versuch erreicht werden.
1
0.0 vangogh.3873 > 140.252.1.29.25:
S 2358303745:2358303745(0) ...
12.7. Aufbau einer E-Mail
2
0.000621 (0.0006)
140.252.1.29.25 > vangogh.3873:
R 0:0(0) ack 2358303746 win 0
3
0.300203 (0.2996)
vangogh.3874 > 140.252.13.33.25:
S 2358367745:2358367745(0) ...
4
0.300620 (0.0004)
140.252.13.33.25 > vangogh.3874;
R 0:0(0) ack 2358367746 win 0
Um Computern die Weiterleitung bzw. die Darstellung zu erleichtern, sind E-Mails intern in zwei Teile geteilt. Der für Weiterleitung wesentliche Teil mit
Sender- und Empfängerzeilen heißt Header. Der Body enthält den Nachrichtentext der E-Mail.
12.7.1. Header
Die in Abbildung 12.4 dargestellte E-Mail wurde von [email protected] an [email protected] versendet. Die Zeilennummern
In der ersten Zeile sendet vangogh ein SYN-Paket wurden hingefügt, damit in der nachfolgenden Bemit einer Sequenznummer 2358303745 an die pri- schreibung besser darauf verwiesen werden kann. Sie
märe IP-Adresse für den Host sun (140.252.1.29). sind nicht Teil der eigentlichen Nachricht.
118
12.7. Aufbau einer E-Mail
Abbildung 12.4.: Typischer E-Mail-Header.
Zeile 1 wurde von /bin/mail oder mail.local
bei der endgültigen Auslieferung hinzugefügt. Dadurch kann der Server – falls vorhanden – eine erste
und einfache Benutzerüberprüfung durchführen, um
Spamming einzudämmen. Aufgrund der Fälschbarkeit lässt sich Spamming aber nicht sicher vermeiden.
Es gibt zu viele offene Mailserver (Abschnitt 12.5.1),
die keinerlei Überprüfung vornehmen. Zeile 2 gibt
den Return-Path an, der eine andere Adresse enthalten
kann, als die From-Zeile später im Mail-Header. Fehlermeldungen sollen an die Adresse im Return-Path
geschickt werden.
Die Zeilen 3 bis 8 dokumentieren, wie die Nachricht auf dem Weg zu der Mailbox des Benutzers über
verschiedene Relay-Server weitergereicht wurde. Jeder Relay-Server (Abschnitt 12.5), der die Nachricht
verarbeitet, fügt dem Header eine Received-Zeile hinzu. Die Received-Zeilen werden immer oberhalb der
bisherigen Zeilen eingefügt, wodurch sich von unten nach oben der genaue Weg, den die Nachricht
nahm, nachvollziehen lassen sollte. Jede dieser Received-Zeilen beinhaltet den Namen der sendenden Maschine, den Namen der empfangenden Maschine, die
MTA-Version auf der empfangenden Maschine und
den Empfänger.
Zeile 11 enthält die Message-ID, die sich von einer Warteschlangen-ID unterscheidet und innerhalb
des weltweiten Mail-Systems eindeutig ist. Eindeutig heißt hier, dass keine E-Mail von einem beliebigen Absender mindestens innerhalb der nächsten zwei
Jahre die gleiche Message-ID haben darf. Sie wird
der Nachricht hinzugefügt, sobald diese in das MailSystem eingespeist wird.
12.7.2. Multimedia Internet Mail
Extensions (MIME)
Die ersten E-Mail-Systeme waren nur für die Übertragung von 7 bit-Daten ausgelegt. Andere Daten mussten vor dem Verschicken manuell in 7 bit-Darstellung
umgewandelt (z. B. mittels uuencode) und beim
Empfänger entsprechend zurückgewandelt werden.
Selbst die Umlaute musste man „verstümmeln“.
Durch die Hardwareausstattung von heutigen
Rechnern (Rechenleistung, Audio, hochauflösende Bildschirme, Scanner, . . . ) ist natürlich auch
Multimedia-Mail praktikabel geworden. Dazu kommen gestiegene Übertragungskapazitäten im Netz. Im
Juni 1992 wurde die Spezifikation für MultimediaNachrichten unter dem Namen Multipurpose Internet
Mail Extensions (MIME) veröffentlicht.
MIME ermöglicht das Versenden von binären Anhängen und Mails, die aus mehreren Teilen bestehen.
Realisiert wird dies von den beteiligten Mailprogram-
119
12. Simple Mail Transfer Protocol (SMTP)
Abbildung 12.5.: Eine einfache Multipart-Message.
men durch Verwendung des Content-Type-Headers
„multipart/mixed“ und die Festlegung einer speziellen Zeichenfolge, die als Grenze (boundary) zwischen
diesen Teilen dient (und natürlich in der Mail sonst
nicht vorkommen darf). Innerhalb der einzelnen Teile der Mail kann man wieder angeben, ob es sich um
einen Text oder eine Binär-Datei handelt. Binäre Daten werden nach einem speziellen Verfahren (Base64)
für die Übertragung umgewandelt.
Das nächste Beispiel (Abbildung 12.5) zeigt eine
solche Mail, so wie sie per SMTP übertragen wird,
aber vom Benutzer in dieser Form nicht gesehen wird.
Sie besteht aus Text mit Sonderfunktionen, einem
Bild-Teil und einer Referenz auf ein Postscript-File
in einem FTP-Archiv.
12.8. Zusammenfassung
Im einfachsten Fall wird die E-Mail direkt von dem
Host des Senders zu dem des Empfängers übertragen. Ein Hintergrundprogramm im Host des Senders
fungiert als Client und nimmt mit dem Mailserver
im Host des Empfängers Kontakt auf. Die beiden
Programme übertragen Nachrichten über das SMTPProtokoll. Der Server speichert die Nachrichten in der
Mailbox des Empfängers auf dem entfernten Host.
120
Man stellt E-Mails in der Regel nicht selbst zu, sondern liefert sie bei einem Mailserver seines Providers
ein, der sich dann um den Weitertransport kümmert.
Der Mailserver des Providers findet dann heraus, welcher Server die Mail für den Empfänger entgegennimmt und leitet sie entsprechend weiter.
Nachdem der SMTP-Relay-Server eine E-Mail von
einem E-Mail-Client entgegengenommen hat, ist er
für das Weiterleiten an den Ziel-SMTP-Server verantwortlich. Das DNS spielt hierbei eine zentrale Rolle. Im DNS sind spezielle Einträge für die elektronische Post vorhanden. Das sind die Mail Exchange
Records (MX-Records). Über diese Einträge identifiziert der SMTP-Server den Ziel-SMTP-Server der
Domain, die in der E-Mail-Adresse des Empfängers
angegeben ist.
Da E-Mail-Systeme Nachrichten nur in ASCII-Text
darstellen, können in eine E-Mail keine Binärdaten
direkt eingebunden werden. Der MIME-Standard ermöglicht es einem Sender, binäre Daten zu kodieren
und mit einer Nachricht zu übertragen.
13. Network File System (NFS)
Friedemann Boelter
13.1. Allgemeine
Informationen zu NFS
Die folgenden Seiten befassen sich mit NFS, dem Network File System. Es stellt Dienste bereit, um transparent auf Dateien, welche auf verteilten Datenträgern
innerhalb eines Netzwerkes verfügbar sind, zugreifen zu können. Hierbei handelt sich um eine ClientServer-Anwendung. Das System ist so angelegt, dass
für den Nutzer die Zugriffe auf lokale und entfernte Dateien praktisch keinen Unterschied machen. Intern werden für die Zugriffe auf einen NFS-Server
automatisch Anfragen, die Remote Procedure Calls
(RPC), generiert, und über das Netzwerk versendet. Abbildung 13.1.: NFS im OSI-Schichtenmodell.
Die RPC-Antworten des Servers werden ebenfalls automatisch empfangen und für die Anwendung des
Nutzers aufbereitet. Somit ist NFS in die Anwen- gründet auf dem einheitlichen Kommunikationsprodungsschicht des ISO-OSI Referenzmodells 13.1 ein- tokoll. RPC gibt es in verschiedenen Varianten, die
interessante Erscheinungsform für das NFS ist Sunzuordnen [Wik06b].
RPC.
13.2. Remote Procedure Call
13.2.1. Funktionsweise von RPC
Remote Procedure Calls (RPC) sind eine Möglichkeit, Operationen auf einem mit dem Netzwerk verbundenen Rechner auszuführen, die von einem anderen Netzwerkrechner gesteuert werden. Dabei ist es
nicht notwendig, dass beide Rechner eine einheitliche
Architektur oder gleiches Betriebssystem verwenden,
insofern die genutzte Hard- und Software RPCs handhaben kann. Hierbei werden nicht direkt Befehle zwischen Client und Server verschickt, sondern beide
Rechner haben eine Kommunikationsinstanz, einen
Dolmetscher zwischengeschaltet. Diese kommunizieren miteinander über das Netzwerk. Die beteiligten
Rechner sorgen sich darum, dass diese Zwischeninstanzen kompatibel zu den internen Vorgängen sind.
RPCs treten meistens in Client-Server-Strukturen auf.
Dabei ist der Client der Befehlssender und der Server
der Befehlsempfänger. Die Tatsache, dass diese Architektur übergreifende Kommunikation funktioniert,
Wie schon im vorherigen Abschnitt erwähnt, besitzen Client und Server einen Dolmetscher, der für die
direkte Kommunikation untereinander sorgt. Dieser
wird als Client- bzw. Server-Stub bezeichnet. Der Ablauf eines solchen Nachrichtenaustausch ist in Abbildung 13.2 veranschaulicht und wird im folgenden genauer erläutert. Kommt es während der Ausführung
des Clientprogramms zum Aufruf einer remote procedure, dann wird der Aufruf weitergegeben an den
Client-Stub, der Teil des RPC-Package ist. Der ClientStub übersetzt die Parameter des Prozeduraufrufs in
eine Nachricht und sendet diese via Netzwerk an den
Server. Der Server-Stub nimmt die Nachricht entgegen und übersetzt die geschickten Parameter in für
den Server verständliche Formate und ruft die entsprechende Operation auf. Die Rückgabewerte des
Servers werden intern an den Server-Stub übermittelt, dieser übersetzt sie in eine Netzwerknachricht
121
13. Network File System (NFS)
Abbildung 13.2.: Aufruf eines RPC (links) und Rückgabe eines RPC (rechts).
und sendet sie an den Client-Rechner. Die gesendete
Nachricht wird als RPC auf dem Client erkannt und
von dem Client-Stub bearbeitet, dieser übersetzt sie
in ein systeminternes Format und leitet die Ergebnisse an den ursprünglichen Aufruf zurück. Aus Sicht
der Client-Anwendung wurde direkt mit dem Server
in scheinbar einer Sprache kommuniziert.
Auf diese Weise lassen sich einfach Programme implementieren, die Ressourcen fremder Rechner
nutzen, ohne die genaue Architektur oder die verwendete Software des Zielrechners zu kennen. Des Weiteren ist es für die Nutzung unerheblich, welches Kommunikationsprotokoll oder Übertragungsmedium verwendet wird. Der Client- und Server-Stub kümmern
sich um den fehlerfreien und reibungslosen Ablauf
der Übertragung. Eine weitere Vereinfachung durch
das RPC-Package besteht darin, dass die Parameter
des jeweiligen Aufrufs automatisch in die entsprechenden Formate der verschiedenen Systeme übersetzt werden. Hierzu wird eine einheitliche im RPCPackage definierte Darstellung eingesetzt, die External Data Representation (XDR).
zwischen Client und Server und wird vom Client gesetzt. Stellt der Client beim Empfang eines RPC fest,
dass die Nummer nicht gleich der im gesendeten Aufruf ist, dann wird die Nachricht verworfen und solange gewartet, bis die korrekte Antwort vom Server gesendet wird. Jeder neue Aufruf bekommt eine neue
XID. Der nächste Teil beschreibt, ob eine Nachricht
ein Call (0) oder ein Reply (1) ist. Diese Unterscheidung ist wichtig, denn es könnte sein, dass ein System sowohl als Client als auch als Server agiert. RPC
version, program, version und procedure number charakterisieren eindeutig, welche RPC-Version verwendet und welche Prozedur in welcher Version auf dem
Server ausgeführt werden soll. Der nächste Abschnitt,
die credentials, enthalten nähere Informationen über
den Client, diese sind für Zugriffsrechte und zur Authentifikation des Clients beim Server vorgesehen. Es
folgt der verifier; dieser Abschnitt enthält ähnliche Informationen wie der vorhergehende, nur sind sie in
diesem Fall verschlüsselt. Im Gegensatz zu den bisherigen Feldern haben diese beiden keine feste Länge.
Die übrigen Bytes des Datagramms sind reserviert für
die Eingabeparameter der Prozedur. Anhand der Größe des Datagramms und der Länge der bisherigen Ab13.2.2. Aufbau von SunRPCschnitte kann der Server-Stub ermitteln, wie groß das
Nachrichten
Parameterfeld ist. Die Parameter werden in einem eiEs gibt inzwischen mehrere Versionen von RPC, die genen Format, welches das RPC-Package bereitstellt,
auf einen jeweils größeren Operationsbereich ausge- übertragen.
Der RPC-Reply (Abbildung 13.3 rechts) ist bis zur
legt sind. Auch die verwendeten Kommunikationsprotokolle variieren. So gibt es auf TCP und UDP ba- XID analog aufgebaut. reply (1) beschreibt das Datasierende RPC-Definitionen und sogenannte transport- gramm als eine Antwort. Der folgende Abschnitt gibt
unabhängige Varianten, die mit praktisch jeder durch den Status der Bearbeitung des RPCs wieder. 0 heißt
den Kernel bereitgestellten Kommunikationsart arbei- in dem Fall accepted. Hiermit kann der Server mitten können. Der Aufbau der Netzwerknachrichten äh- teilen, wenn ein Fehler bei der Annahme der Nachnelt sich in den meisten Fällen, so dass sich im folgen- richt durch den Server-Stub erkannt wird, z. B. bei
den auf eine spezielle Form, den RPC-Nachrichten nicht übereinstimmender RPC-Version. Sollte auch
der Server sich authentifizieren sollen, so kann dies
über UDP, bezogen werden kann.
Der RPC-Request in Abbildung 13.3 links enthält im verifier-Teil entsprechend verschlüsselt geschezunächst IP- und UDP-Header, die aus den Kapiteln hen. Der accept status weist auf Fehler hin, die bei der
1 und 5 bekannt sind. Die transaction_ID (XID) ent- Wahl der Prozedur und bzw. bei der Übertragung der
spricht im wesentlichen der aus dem TCP-Protokoll auszuwählenden Prozedur vorgekommen sind. 0 steht
bekannten Sequenznummer. Sie dient zum Abgleich hier wiederum für eine erfolgreiche Verarbeitung. Die
122
13.2. Remote Procedure Call
Abbildung 13.3.: Aufbau eines aufrufenden RPC (links) und Antwort (rechts) unter Verwendung
von UDP.
Ergebnisparameter werden auf die gleiche Weise wie
beim Senden codiert und in den procedure results angegeben.
ruf der RPC wird nicht explizit eine Verbindung zwischen Sender und Empfänger aufgebaut. Erst wenn eine Anwendung des Client eine remote procedure ausführt und der Client-Stub mit der Bearbeitung beauftragt wird, wird eine entsprechende Verbindung zum
13.2.3. External Data Representation Server aufgebaut (active open für TCP) oder eine bis(XDR)
herige Verbindung weiter genutzt. Des Weiteren ist es
Da sich die Darstellung der Parameter auf verschiede- möglich, dass der Server nicht nur RPCs von nur einen Rechnersystemen unterscheiden kann, bietet das nem Client bekommt, sondern gerade für AnwendunRPC-Package ein allgemeines Format für die Über- gen wie NFS kommen Anfragen von mehreren Clitragung der Parameter an. Dieses nennt man Ex- ents. Hierfür gibt es auf dem Server, aber auch auf
ternal Data Representation (XDR). In XDR werden den Clients, ein Liste aller durch RPCs verwendeten
nicht nur die Eingabe- und Ergebniswerte formatiert, Ports. Jedes Programm jeder Prozedur in jeder Versisondern der Inhalt des gesamten Datagramms außer on bekommt einen eigenen Port und somit einen eigeder IP-Header und dem Header des Transportproto- nen TCP- bzw. UDP-Endpunkt. Die Verwaltung diekolls. Aufgrund dieser Standardisierung muss ledig- ser Liste wird durch den Portmapper durchgeführt.
lich jeder Rechner das RPC-Package entsprechend Wird nun eine RPC-Anfrage ausgeführt, so erfragt
seiner internen Spezifikation der Parameter imple- die Client-Seite durch einen RPC an den Portmapmentieren, um RPCs korrekt empfangen und senden per, auf welchem Port die gewünschte Prozedur in der
zu können [CPS95]. Für die gebräuchlichen Datenty- jeweiligen Version des bestimmten laufenden Serverpen wie Integer, Float, usw. gibt es in diesem Stan- Programms erreichbar ist. Nach einer Antwort durch
dard fest definierte Darstellungen. So werden z. B. den Portmapper kommuniziert der Client direkt mit
alle Integer-Zahlen mit 4 Bytes kodiert. Aus diesem der entsprechenden Port auf dem Server. Der PortGrund hat auch jeder Abschnitt aus dem unteren Be- mapper selbst ist dabei ein RPC-Server-Programm,
reichen in 13.3, welcher eine einfache Zahl darstellt, also Teil des RPC-Packages.
In den neueren Servern werden, um die Last ein4 B reserviert.
zelner Aufgaben und auch die benutze Portanzahl zu
reduzieren, so genannte Daemons wie z. B. der Mount
13.2.4. Portmapper und Daemons
Daemon für NFS eingesetzt. Hierbei handelt es sich
um mehrfach ausgeführte Instanzen eines Programms
Die Übertragung von RPCs geschieht unabhängig daim Kernel, die praktisch parallel arbeiten. Dabei sind
von, ob der Server oder der Client überhaupt bereit
sie über einen Port erreichbar.
sind, eine Nachricht entgegen zu nehmen. Vor Auf-
123
13. Network File System (NFS)
Die Liste des Portmapper lässt sich mit Hilfe von
rpcinfo -p ausgeben.
13.3. Das NFS-Protokoll
Die Einleitung beschrieb das NFS-Protokoll als eine
transparente Art der Zugriffe auf Dateien und Verzeichnissen auf einem Server im Netzwerk. Transparenz bedeutet hier, dass Dateien über das Netzwerk
abgefragt werden können, ohne dass die jeweilige
Anwendung einen Unterschied zwischen lokalen und
NFS-Zugriffen macht. Dies wird über die Anwendung
der RPCs gewährleistet, da die Abwicklung der Kommunikation gänzlich vom RPC-Package übernommen
wird. Somit werden externe Filesysteme virtuell in
das eigene System integriert. Hierin liegt auch der
Grund für die Client-Serverstruktur von NFS. Gleichwertige Kommunikationspartner würden die Kontrolle über den Informationsaustausch gegenseitig regeln
müssen, dies kostet Zeit und Rechenleistung, was
die effiziente Arbeitsweise mit verteilten Ressourcen
mindern würde. Deshalb wird nur einem Partner, dem
Client, die Kontrolle über den Transfer gewährt. Dies
wiederum ermöglicht aufgabenorientierte Implementierung auf beiden Seiten. NFS gibt es mittlerweile in
4 Versionen. Die am weitesten verbreitete Version ist
NFS 3.
13.3.1. Ablauf eines NFS-Zugriffs
Greift eine beliebige Anwendung während der Ausführung auf eine Datei zu (siehe Abbildung 13.4), so
weiß erst der Kernel des Clients, ob diese Datei lokal oder über NFS erreichbar ist. Handelt es sich um
einen NFS-Zugriff, so wird eine RPC generiert und an
den Server geschickt. Dies geschieht über das Netzwerkinterface via TCP oder UDP an den entsprechenden Port des Servers. Häufig wird UDP verwendet,
Port 2049 ist standardmäßig implementiert. Der NFSServer empfängt den RPC und gibt an das lokale System den jeweiligen Zugriff auf die Dateien weiter. Das
Ergebnis dieses Zugriffs wird anschließend in eine
RPC-Antwort gesteckt und an den Client übermittelt.
Zuletzt stellt der Kernel die Ergebnisse des Zugriffs
der aufrufenden Anwendung zu Verfügung.
Offensichtlich entsteht hier ein Engpass, denn
selbst moderne Netzwerktechnik ermöglicht nicht
solche Zugriffszeiten wie auf lokale Speichermedien. Auch Fehler in der Übertragung verzögern das
schnelle Arbeiten. Um die Zeiten für den Zugriff auf
größere Daten zu beschleunigen, werden sowohl auf
Client- als auch auf Server-Seite Daemons eingesetzt.
124
So werden scheinbar parallel mehrere Anfragen bearbeitet. Die Verwaltung der jeweiligen Daemons obliegt dabei dem jeweiligen Betriebssystem.
13.3.2. Dateizugriff via File Handles
Für die Anzeige und den Zugriff auf Dateien, erstellt
der Server bei NFS ein Objekt (file handle), welches
die jeweilige Datei oder das Verzeichnis eindeutig referenziert. Dieser Handle wird an den Client übermittelt. Jeder Zugriff des Client auf eine Datei auf dem
NFS-Server erfolgt nur noch über diesen file handle. Dabei ist es für den Client nicht möglich, dieses
Objekt selbst in irgendeiner Weise zu bearbeiten. Für
die Anwendungen des Clients macht es im Übrigen
keinen Unterschied, wie dieses Objekt beschaffen ist
oder generiert wird. Die Implementierung des NFSServers kümmert sich um die Verwaltung dieses file
handle.
In der aktuellen NFS-Version haben die Handles eine Größe von 64 B.
13.3.3. Einbinden von NFS auf dem
Client
Um NFS einsetzen zu können, muss der Client das
Server-NFS in seinen Verzeichnisbaum einbinden,
dies geschieht über einen festgelegten Mountpunkt.
Der zugehörige UNIX-Befehl ist mount (siehe Abbildung 13.5). Nach dem Start des NFS-Servers wird
der Mount Daemon gestartet, erstellt einen UDP- und
TCP-Endpunkt und registriert diese via RPC bei dem
eigenen Portmapper. Der NFS-Server ist nun betriebsbereit. Wird der Mount-Befehl des Client gestartet,
so wird zuerst der Port des Mount Daemon des Servers über RPC an den Portmapper abgefragt. Der
Server antwortet mit den entsprechenden Ports. Darauf stellt der Client eine RPC-Anfrage an den Port
des Mount Daemon, um das entsprechenden Dateisystem zu integrieren. Der Daemon antwortet mit dem file handle des angeforderten Dateisystems. Als letzte
Aktion wird der file handle im NFS-Client registriert
und an gegebener Stelle (Mountpunkt) in das lokale
Dateisystem eingebunden. Der Mount Daemon kann
dabei auch Anfragen zurückweisen, falls der Client
nicht die Berechtigung hat, das bestimmte Dateisystem einzubinden. Mount Daemon, Portmapper und
der mount-Befehl sind alles Anwendungen des Nutzers, also nicht vom Kernel ausgelöst.
Abbildung 13.6 zeigt den Verzeichnisbaum eines
NFS-Client. Die Unterverzeichnisse des Mountpunktes (home) werden durch den Kernel automatisch auf
das Server-Dateisystem verwiesen. Sollte der lokale
13.3. Das NFS-Protokoll
Abbildung 13.4.: Aufbau eines NFS-Systems.
Abbildung 13.5.: Ablauf eines Aufruf des mount-Befehls.
125
13. Network File System (NFS)
Abbildung 13.6.: Verzeichnisstruktur aus Sicht des Clients.
Ordner Dateien oder Verzeichnisse enthalten, so sind
diese nicht erreichbar, solange das NFS eingebunden
bleibt.
13.3.4. Die NFS-Prozeduren
Es gibt 21 RPC-Prozeduren [CPS95] in NFS Version 3. Nicht alle dieser Funktionen sind gleich häufig
in der Ausführung, so dass einige Funktionen, die speziell auf die Eigenschaften des UNIX-Betriebssystem
aufbauen und somit schwer in andere Umgebung umgesetzt werden können, in gewissen System nicht belegt sind. Die wichtigsten Lese- und Schreibzugriffe
sind jedoch von jedem System realisiert. Es folgt eine
Liste der wichtigsten (häufigsten) Funktionen:
write Analog zum Lesen werden file handle, Byteanzahl und Startpunkt mit den zu schreibenden
Bytes übergeben.
create Erstellt eine Datei auf dem NFS-Server.
remove Löscht eine Datei auf dem NFS-Server.
mkdir Erstellt ein Verzeichnis.
rmdir Löscht ein Verzeichnis.
readdir Gibt die Unterverzeichnis und Dateien eines
Verzeichnisses an. Entspricht dem „lookup“ für
Verzeichnisse.
13.3.5. Zustandslosigkeit und
Idempotenz
getattr Gibt die Eigenschaften und Attribute der gewünschten Datei zurück
Um den Betrieb mit vielen Clients zu gewährleisten,
wird, wie schon erwähnt, dem Server die Kontrolle
setattr Setzt die änderbaren Attribute wie Rechte,
über die Art und Abfolge der Datenzugriffe entzoZeitpunkt der letzen Änderung usw. einer Datei
gen. Über den Fortschritt und den Stand der angelookup Vor jedem Öffnen von Dateien wird dieser forderten Daten weiß nur der NFS-Client Bescheid.
Befehl ausgeführt, es wird ein file handle für den Da der Server keinen Zustand hat, können unerwartete Ereignisse wie Verbindungsabbrüche nicht durch
jeweiligen Zugriff zurückgegeben.
den Client abgefragt werden. In solchen Fällen wieread Der Inhalt einer NFS-Datei kann ausgelesen derholt der Client solange die gewünschten Anfragen,
werden. Hierzu wird der file handle und die Zahl bis der Server antwortet. Dies hat natürlich den Vorder zu lesenden Bytes, sowie der Startpunkt in- teil, das Ausfälle des Servers den Fortschritt der Verarbeitung des Client in keiner Weise abbrechen. Der
nerhalb der Datei angegeben.
126
13.4. Experimente rund um NFS
Client merkt lediglich, dass der Server länger benötigt, um eine Anfrage zu bearbeiten. Nachteil der Zustandslosigkeit ist, dass der Server mit scheinbar beliebigen Anfragen bombardiert werden könnte, ohne
zu merken, ob diese Befehlsabfolge überhaupt Sinn
ergibt. Ein Prinzip, diese Unabhängigkeit und somit
die Eigenschaften des NFS zu ermöglichen, ist die
Idempotenz der verwendeten Prozedur. Das heißt, eine Prozedur ist so angelegt, dass sie bei der Ausführung mit denselben Eingaben zu jedem Zeitpunkt
auch das gleiche Ergebnis liefert. „read“ ist ein Beispiel einer solchen Prozedur. Wie im vorherigen Abschnitt erwähnt, wird Byteanzahl und Startpunkt der
zu lesenden Datei angegeben. Dies ermöglicht, dass
jede RPC-Anfrage auch den gewünschten Teil der Datei wiedergibt. Es sind aber nicht alle Prozeduren von
NFS auch idempotent. Geht zum Beispiel die erfolgreiche Antwort auf ein „create“ oder ein „remove“
verloren, so sendet der Client diesen nach gewisser
Zeit erneut, der Server hat aber die geforderte Datei
nicht mehr oder bereits erstellt. Dies würde eine negative Antwort des Servers bedeuten; der Client würde
eine fehlerhafte Auskunft an die aufrufende Anwendung weitergeben, ohne diese erkannt zu haben. Genau für solche Sonderfälle besitzt der NFS-Server eine Eweiterung um ein begrenztes Gedächtnis (ReplyCache). Dieser speichert für bekannte Prozeduren, die
nicht idempotent sind, die zuletzt gesendeten Antworten. Kommt es nun zu einer RPC-Retransmission
durch den Client, wird die Antwort mit der entsprechenden XID nochmals gesendet, ohne die betreffende Aktion auszuführen.
13.4. Experimente rund um
NFS
Die folgenden Experimente wurden im Rahmen des
Seminars durchgeführt. Die verwendeten Systeme unterstützen UNIX-NFS-Zugriffe.
13.4.1. Experiment: Einfache
NFS-Zugriffe
Im Versuch in Abbildung 13.7 wird von einem NFSClient eine einfache Anwendung zum Lesen einer
Datei auf dem NFS-Server gestartet. Die auftretende
Kommunikation wird abgehorcht und im folgenden
erläutert. Die Datei test enthält nur wenige beliebige
Buchstaben, so dass der Datenverkehr überschaubar
bleibt. test befindet sich auf dem NFS-Server. Die
Kommunikation wird mit
$ tcpdump ...
auf dem Port 2049 abgehört. Wie schon in den vorhergehenden Abschnitten erwähnt, ist der Port 2049 für
die NFS-Kommunikation standardmäßig implementiert, dies erleichtert die Auswertung der Ausgabe.
Folgender Befehl wird eingegeben:
$ cat test
hello world
Nach wenigen Millisekunden erhält man die Antwort,
den Inhalt der Datei, angezeigt. Der Client sendet für
die jeweilige Datei ein „getattr“ und darauf ein „access“. „access“ ist dabei eine NFS3-Funktion, welche
die Zugriffsrechte des Clients überprüft. Es folgt eine
„read“-Anfrage über den gewählten file handle. Die
Anfragen werden jeweils mit „reply ok“ beantwortet.
Wie man leicht sehen kann, löst eine Anwendung des
Nutzers automatisch eine Vielzahl von RPC-Requests
aus. Der Nutzer hat keine Einsicht in diese Vorgänge.
13.4.2. Experiment: NFS-Zugriffe
während eines
Verbindungsabbruchs
Der Versuch in Abbildung 13.8 soll die Zustandslosigkeit des NFS-Servers veranschaulichen. Der
Grundgedanke ist, während eines NFS-Zugriffs den
Server abstürzen zu lassen oder die physikalische
Netzwerkverbindung zu trennen. Anschließend müsste der Server neu gestartet werden, um alle evtl. Speicherungen der bisherigen Kommunikation zu löschen.
Würde nun die physikalische Verbindung wieder aufgebaut, so müsste der NFS-Zugriff an der Stelle des
Verbindungsabbruch wieder aufgenommen werden.
Der Nutzer sollte dabei nichts weiter feststellen als eine längere Wartezeit bei der Ausführung der Anwendung.
Auf dem vorliegenden Testnetzwerk ist diese harte
Trennung nicht möglich, darum wurde der Ablauf ein
wenig modifiziert. Der Client und Server entspricht
den aus Abbildung 13.7. Allerdings wird ein zusätzlicher VPN-Tunnel zwischen dem Client und Server
eingerichtet. Nach Installation ist der Server über die
physische und über ein virtuelle Verbindung erreichbar. Über die virtuelle Schnittstelle wird nun NFS auf
dem Client eingebunden.
$ mount ipc654-mp:/export/tmp /tcp
Anschließend wird die virtuelle Verbindung beendet. Dies löscht auch automatisch den für diese Verbindung verwendeten Cache des Servers. Vom Client
aus wird nun eine einfache Anwendung
127
13. Network File System (NFS)
Abbildung 13.7.: Struktureller Aufbau und Ablauf des 1. Experiments
Abbildung 13.8.: Struktureller Aufbau und Ablauf des 2. Experiments.
128
13.5. Fazit
$ ls -i tcp/TCP_IP
gestartet, die auf den gerade eingerichteten NFS-Teil
zugreift. Diese Kommunikation wird abgehört. Nach
einiger Zeit wird der VPN-Tunnel wieder gestartet. Ist
der Startvorgang beendet, kann man feststellen, dass
die Ausgabe der Anwendung des Clients ordnungsgemäß erfolgt ist. Dabei gibt es keine Fehlerausgabe oder ähnliches, lediglich die größere Wartezeit ist
am Client-Rechner zu bemerken. Ein Blick auf die abgehörten Daten lässt den Grund dafür erkennen: Der
Client stellt Anfragen an den Server mit einer XID,
während die Serververbindung unterbrochen ist. Man
erkennt, dass der Client weiterhin versucht, die Anfrage zu senden. Sobald die Verbindung wieder aufgebaut wird, bekommt der Client exakt die Antwort auf
den wiederholt gesendeten RPC, leicht zu erkennen
an der entsprechenden XID. Die folgenden RPC werden normal übermittelt, ohne einen Unterschied durch
den Serverausfall zu verdeutlichen.
13.5. Fazit
Wie die Experimente gezeigt haben, merkt der
Anwender von dem Ablauf der einzelnen RPCKommunikationsprozesse zwischen Client und
Server nichts. Das NFS wird wie ein lokales Dateisystem angesprochen und bearbeitet. Sogar die
Einrichtung von NFS auf dem Client stellt keinen
großen Aufwand dar. Prinzipien wie die Idempotenz
der Prozeduren und die Zustandslosigkeit des Servers
sichern den ordnungsgemäßen und transparenten
Ablauf des Datenzugriffs. Die Organisation der
übertragenen Inhalte über standardisierte Typdarstellung (XDR) und der Zugriff über eigens definierte
file handle ermöglichen System und Architektur
übergreifende Kommunikation.
Die neuste NFS-Version 4 geht in die Richtung,
die Sicherheit der übertragenen Daten zu steigern,
um den NFS-Betrieb innerhalb lokaler Netzwerke
auf LAN-übergreifende Strukturen zu erweitern. Das
Konzept der Zustandslosigkeit lässt sich dabei nicht
mehr verwirklichen, da der Server Informationen zum
Client behalten muss, um die Geschwindigkeit einzelner Verbindungen zu optimieren.
129
Literaturverzeichnis
[AOM98]
A LLMAN , M., S. O STERMANN und C. M ETZ: FTP Extensions for IPv6 and NATs. RFC 2428
(Proposed Standard), September 1998.
[APS99]
A LLMAN , M., V. PAXSON und W. S TEVENS: TCP Congestion Control. RFC 2581 (Proposed
Standard), April 1999. Updated by RFC 3390.
[BAFW03] B LANTON , E., M. A LLMAN, K. FALL und L. WANG: A Conservative Selective
Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. RFC 3517 (Proposed
Standard), April 2003.
[Bak95]
BAKER , F.: Requirements for IP Version 4 Routers. RFC 1812 (Proposed Standard), Juni 1995.
Updated by RFC 2644.
[Bhu71]
B HUSHAN , A.K.: File Transfer Protocol. RFC 114, April 1971. Updated by RFCs 133, 141,
171, 172.
[Bra89]
B RADEN , R.: Requirements for Internet Hosts - Communication Layers. RFC 1122 (Standard),
Oktober 1989. Updated by RFCs 1349, 4379.
[Com00]
C OMER , D OUGLAS (editor): Internetworking with TCP/IP – Principles, Protocols, and
Architectures. Prentice Hall, 4th edition, 2000.
[CPS95]
C ALLAGHAN , B., B. PAWLOWSKI, and P. S TAUBACH: NFS Version 3 Protocol Specification.
RFC 1813 (Informational), June 1995.
[CS91]
C OMER , D OUGLAS E. and DAVID L. S TEVENS: Internetworking with TCP/IP, volume 1:
Principles, Protocols and Architectures. Prentice Hall, 1991.
[Dee91]
D EERING , S.: ICMP Router Discovery Messages. RFC 1256 (Proposed Standard), September
1991.
[DH98]
D EERING , S. and R. H INDEN: Internet Protocol, Version 6 (IPv6) Specification. RFC 2460
(Draft Standard), December 1998.
[Dro97]
D ROMS , R.: Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard), March 1997.
Updated by RFCs 3396, 4361.
[FH99]
F LOYD , S. and T. H ENDERSON: The NewReno Modification to TCP’s Fast Recovery
Algorithm. RFC 2582 (Experimental), April 1999. Obsoleted by RFC 3782.
[FLYV93]
F ULLER , V., T. L I, J. Y U, and K. VARADHAN: Classless Inter-Domain Routing (CIDR): an
Address Assignment and Aggregation Strategy. RFC 1519 (Proposed Standard), September
1993. Obsoleted by RFC 4632.
[FMMP00] F LOYD , S., J. M AHDAVI, M. M ATHIS, and M. P ODOLSKY: An Extension to the Selective
Acknowledgement (SACK) Option for TCP. RFC 2883 (Proposed Standard), July 2000.
[Fre06]
F REE BSD G ERMAN D OCUMENTATION P ROJECT: Das FreeBSD-Handbuch, chapter 27.2.
Gateways und Routen. FreeBSD Project, 2006.
http://www.freebsd.org/doc/de/books/handbook/network-routing. Zugriff am 21.09.2006.
131
Literaturverzeichnis
[HD03]
H INDEN , R. and S. D EERING: Internet Protocol Version 6 (IPv6) Addressing Architecture.
RFC 3513 (Proposed Standard), April 2003. Obsoleted by RFC 4291.
[Hed88]
H EDRICK , C.L.: Routing Information Protocol. RFC 1058 (Historic), June 1988. Updated by
RFCs 1388, 1723.
[HKC+ 96] H UBBARD , K., M. KOSTERS, D. C ONRAD, D. K ARRENBERG, and J. P OSTEL: Internet
Registry IP Allocation Guidelines. RFC 2050 (Best Current Practice), November 1996.
[HL97]
H OROWITZ , M. and S. L UNT: FTP Security Extensions. RFC 2228 (Proposed Standard),
October 1997.
[Hof99]
H OFFMAN , P.: SMTP Service Extension for Secure SMTP over TLS. RFC 2487 (Proposed
Standard), January 1999. Obsoleted by RFC 3207.
[How06]
H OWSTUFFWORKS . COM: Domain Name System. http://computer.howstuffworks.com/dns.htm,
2006. Zugriff am 20.09.2006.
[Int06a]
I NTERNATIONAL O RGANIZATION FOR S TANDARDIZATION: ISO 3166 code lists.
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html, 2006.
Zugriff am 19.10.2006.
[Int06b]
I NTERNET A SSIGNED N UMBERS AUTHORITY: ICMP message types.
http://www.iana.org/assignments/icmp-parameters, 2006. Zugriff am 11.10.2006.
[Int06c]
I NTERNET A SSIGNED N UMBERS AUTHORITY: Port numbers.
http://www.iana.org/assignments/port-numbers, 2006. Zugriff am 18.10.2006.
[Int06d]
I NTERNET A SSIGNED N UMBERS AUTHORITY: Protocol numbers.
http://www.iana.org/assignments/protocol-numbers, 2006. Zugriff am 07.09.2006.
[Int06e]
I NTERNET W ORLD S TATS: Internet usage statistics – the big picture.
http://www.internetworldstats.com/stats.htm, 2006. Zugriff am 07.09.2006.
[Jac88]
JACOBSON , VAN: Congestion avoidance and control. In ACM SIGCOMM ’88, pages 314–329,
Stanford, CA, August 1988.
[JBB92]
JACOBSON , V., R. B RADEN, and D. B ORMAN: TCP Extensions for High Performance. RFC
1323 (Proposed Standard), May 1992.
[KFR+ 95] K LENSIN , J., N. F REED, M. ROSE, E. S TEFFERUD, and D. C ROCKER: SMTP Service
Extensions. RFC 1869 (Standard), November 1995. Obsoleted by RFC 2821.
[Lin06]
L INUXFIBEL: Netzwerk-Diagnose. http://www.linuxfibel.de/netdiag.htm, 2006. Zugriff am
22.09.2006.
[Mei05]
M EINEL , C HRISTOPH: Technische Grundlagen des Internet. Vorlesung, Universität Potsdam,
2005.
[Mil85]
M ILLS , D.L.: Network Time Protocol (NTP). RFC 958, September 1985. Obsoleted by RFCs
1059, 1119, 1305.
[Mil06]
M ILLS , D.: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. RFC
4330 (Informational), January 2006.
[MMFR96] M ATHIS , M., J. M AHDAVI, S. F LOYD, and A. ROMANOW: TCP Selective Acknowledgment
Options. RFC 2018 (Proposed Standard), October 1996.
[Moc83a]
132
M OCKAPETRIS , P.V.: Domain names: Concepts and facilities. RFC 882, November 1983.
Obsoleted by RFCs 1034, 1035, updated by RFC 973.
Literaturverzeichnis
[Moc83b]
M OCKAPETRIS , P.V.: Domain names: Implementation specification. RFC 883, November
1983. Obsoleted by RFCs 1034, 1035, updated by RFC 973.
[Moc87a]
M OCKAPETRIS , P.V.: Domain names - concepts and facilities. RFC 1034 (Standard),
November 1987. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535,
4033, 4034, 4035, 4343, 4035, 4592.
[Moc87b]
M OCKAPETRIS , P.V.: Domain names - implementation and specification. RFC 1035
(Standard), November 1987. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 1995, 1996,
2065, 2136, 2181, 2137, 2308, 2535, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 2137, 2845,
3425, 3658, 4035, 4033.
[Moy94]
M OY, J.: OSPF Version 2. RFC 1583 (Draft Standard), March 1994. Obsoleted by RFC 2178.
[MP85]
M OGUL , J.C. and J. P OSTEL: Internet Standard Subnetting Procedure. RFC 950 (Standard),
August 1985.
[Mye99]
M YERS , J.: SMTP Service Extension for Authentication. RFC 2554 (Proposed Standard),
March 1999.
[Nag84]
NAGLE , J.: Congestion control in IP/TCP internetworks. RFC 896, January 1984.
[pin06]
Webseite des Erfinders von ping. http://ftp.arl.mil/~mike/ping.html, 2006. Zugriff am
11.10.2006.
[Pos80a]
P OSTEL , J.: File Transfer Protocol specification. RFC 765, June 1980. Obsoleted by RFC 959.
[Pos80b]
P OSTEL , J.: User Datagram Protocol. RFC 768 (Standard), August 1980.
[Pos81a]
P OSTEL , J.: Internet Control Message Protocol. RFC 792 (Standard), September 1981.
Updated by RFC 950.
[Pos81b]
P OSTEL , J.: Internet Protocol. RFC 791 (Standard), September 1981. Updated by RFC 1349.
[Pos81c]
P OSTEL , J.: Transmission Control Protocol. RFC 793 (Standard), September 1981. Updated by
RFC 3168.
[Pos82]
P OSTEL , J.: Simple Mail Transfer Protocol. RFC 821 (Standard), August 1982. Obsoleted by
RFC 2821.
[PR83]
P OSTEL , J. and J.K. R EYNOLDS: Telnet Protocol Specification. RFC 854 (Standard), May
1983.
[PR85]
P OSTEL , J. and J. R EYNOLDS: File Transfer Protocol. RFC 959 (Standard), October 1985.
Updated by RFCs 2228, 2640, 2773.
[SK05]
S AROLAHTI , P. and M. KOJO: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol
(SCTP). RFC 4138 (Experimental), August 2005.
[Ste94]
S TEVENS , W. R ICHARD: TCP/IP Illustrated, volume 1: The Protocols. Addison-Wesley, 1994.
[Ste97]
S TEVENS , W.: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms. RFC 2001 (Proposed Standard), January 1997. Obsoleted by RFC 2581.
[Tan02]
TANENBAUM , A NDREW S.: Computer Networks. Prentice Hall, 4th edition, 2002.
[Wik06a]
W IKIPEDIA: Autonomes System. http://de.wikipedia.org/wiki/Autonomes_System, 2006.
Zugriff am 14.08.2006.
133
Literaturverzeichnis
[Wik06b]
W IKIPEDIA: Network File System. http://de.wikipedia.org/wiki/Network_File_System, 2006.
Zugriff am 21.09.2006.
[Wik06c]
W IKIPEDIA: Offenes Mail-Relay. http://de.wikipedia.org/wiki/Offenes_Mail-Relay, 2006.
Zugriff am 09.09.2006.
[Wik06d]
W IKIPEDIA: Schema des Internets. http://de.wikipedia.org/wiki/Bild:Schema_internet.png,
2006. Zugriff am 06.09.2006.
[Wik06e]
W IKIPEDIA: Simple Mail Transfer Protocol.
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol, 2006. Zugriff am 09.09.2006.
[Wik06f]
W IKIPEDIA: SMTP-Auth. http://de.wikipedia.org/wiki/SMTP-Auth, 2006. Zugriff am
09.09.2006.
[Wik06g]
W IKIPEDIA: SMTP-Relay-Server. http://de.wikipedia.org/wiki/SMTP-Relay-Server, 2006.
Zugriff am 09.09.2006.
[Wik06h]
W IKIPEDIA: Transmission Control Protocol.
http://de.wikipedia.org/wiki/Transmission_Control_Protocol, 2006. Zugriff am 05.06.2006.
134
Autorenverzeichnis
Stephan Arenswald, 17
Friedemann Boelter, 121
Sascha Brose, 59
Norbert Hundeshagen, 29
Christian Kauhaus, 1
Stefan Kratsch, 69
Pascal Lenzner, 5
Tino Mai, 79
Matthias Pischeli, 47
Christian Ros, 98
Marco Swiercy, 38
Christiane Topp, 51
Qiguang Yan, 111
Ferdinand Zirker, 89
135