Was ist eigentlich TCP/IP?

Historie
IP-Adressen
Aufbau
1. Das OSI-Referenzmodell
2. Das TCP/IP-Modell
Fußnoten

Den Begriff hat jeder schon einmal gehört, der irgendetwas mit Computern und etwas neueren Betriebssystemen zu tun hat; mindestens mußte er/sie TCP/IP installieren, als das Betriebssystem eingerichtet wurde.
TCP/IP bezeichnet eine Familie von Protokollen, also Übereinkünften, wie Computer miteinander kommunizieren, um ganz genau zu sein: UN*X-Computer, denn historisch hat diese Protokollfamilie ihre Wurzeln in der Entwicklung des Internet, und bis heute liegt dem Internet diese Protokollsammlung zugrunde.
Eine Einschränkung im Voraus: dieser Artikel beschränkt sich auf die derzeitige Version 4; bezüglich der neuen Version 6 (eine Version 5 gibt es zwar, sie wird aber nur zu Testzwecken verwendet) werden nur kurze Hinweise gegeben.

Historie

1969 beschloss die Advanced Research Projects Agency (ARPA)ein Projekt zur Erforschung der Möglichkeiten eines nicht leitungs- sondern paketorientierten Netzwerkes. Das Ziel dieses Projektes bestand darin, robuste, verläßliche und vor allem von den verwendeten Betriebssystemen und der Hardware unabhängige Möglichkeiten der Datenübertragung zu finden. Verbunden mit diesem Netz waren anfangs die vier Universitäten Los Angeles (UCLA), Santa Barbara (UCSB), Utah und das Stanford Research Institute.
Zwei Dienste standen am Anfang dieser Entwicklung:

Terminalsitzungen (remote login)
Dateitransfer (file transfer)

Die elektronische Post wurde als Spezialvariante des Dateitransfers abgewickelt; erst später bekam sie ihr eigenes Protokoll (SMTP). Zugrunde lag dem ganzen das NCP (network control program), der Vorläufer des TCP/IP.
1974 verfaßten Cerf und Kahn einen Artikel, in dem die Grundzüge der heutigen Protokollsammlung definiert wurden; ab 1983 begann die US-Bundesregierung, TCP-IP als Standard für Ausschreibungen zu verwenden, nachdem 1982 der komplette Umstieg des ARPANet von NCP auf TCP/IP erfolgt war. Vorher waren die Standards zunächst in sogenannten IEN (Internet Engineering Notes) und dann in RFC's (Request for Comments) niedergelegt worden. Diese Dokumente beinhalten bis heute die gültigen Standards, die immer noch den Datenverkehr im Internet regeln; sie sind hier erhältlich; allerdings liegen auf den meisten Linuxsystemen - wenn installiert - die rfcs lokal in /usr/share/doc/rfc/ (wer Lust hat, in der Geschichte des Internet zu stöbern, dem sei die Lektüre dieser Dokumente empfohlen; es geht mehr daraus hervor als nur der definierte technische Standard...).
Ebenfalls 1983 wurde TCP/IP von Bolt, Beranek und Newman in Berkeley (BSD) UNIX implementiert; gleichzeitig wurde das Netz in den militärischen Teil (MILNET) und einen neuen, damals kleineren Teil, das ARPANET aufgeteilt.
1985 gründete die NSF (National Science Foundation) das NSFNet und schloß es an das junge ARPANET an; 1990 übernahm das NSFNet die Rolle des ARPANET, das damit formal aufgelöst wurde.

IP-Adressen

Rechnernamen (wie zum Beispiel die berühmte Adresse www.lug-sw.de) werden zu Adressen aufgelöst, wenn es gilt, Pakete an einen Rechner zu senden. Mit diesen IP-Adressen wollen wir uns im folgenden beschäftigen. Der Dienst, der diese Auflösung vornimmt, heißt DNS; standardmäßig wird er von einem Dämon namens "named" aus dem Paket BIND (Bereley Internet Name Daemon) versehen. Darüber werde ich jedoch hier nicht sehr viel schreiben, da darüber Marco, der gerade die wunderbare Welt des named entdeckt, einen Artikel beisteuern will; er wußte nur bis eben noch nichts davon.... ;-))
....
IP-Adressen sind zur Zeit vier Byte lange Ganzzahlen (das wird sich mit der neuen Version des IP-Protokolls ändern; dann sind die Adressen sechzehn Byte lang), die üblicherweise wie folgt geschrieben werden:
Byte1.Byte2.Byte3.Byte4
Beispiel: 192.168.1.1
(in IPv6 dann übrigens 16Bit:16Bit:16Bit:16Bit:16Bit:16Bit:16Bit:16Bit; Beispiel: 20AA:FFFF:D0AE:00C0:00A8:0001:0002:1770)
Es ist zwar genauso gültig, die Adresse einfach als Integerzahl auszuschreiben, allerdings ist das nicht die übliche Weise der Darstellung, da in der Regel etwas unübersichtlich.... Eine in der üblichen Darstellung geschriebene Adresse, bei der das letzte Byte gleich 0 ist, bezeichnet in der klassischen Einteilung ein Netzwerk, eine Adresse mit dem Wert 255 im letzten Byte bezeichnet alle Rechner des Netzwerkes (sogenannte "Broadcast-Adresse")
Klassischerweise werden IP-Adressen in fünf Bereiche eingeteilt, je nachdem, wie viele Bytes das Netzwerk und wie viele Bytes den Rechner bezeichnen; diese Aufteilung verschwindet durch Sub- und Supranetting, dennoch hat sie noch eine Bedeutung; daher stelle ich sie hier noch einmal dar. Es gibt

Klasse A-Netzwerke; ein Byte (das erste) bezeichnet das Netz, alle anderen den Rechner. In einem Klasse A-Netzwerk sind somit 2^²⁴ - 2 = 16.777.214 Rechner möglich.A-Netz-Adressen haben im höchstwertigen Bit den Wert 0, reichen also von 1.x.x.x bis 126.x.x.x (Die Adresse 127.0.0.0 bezeichnet die aktuelle Domain, 127.0.0.1 bezeichnet den aktuellen Rechner und wird in der Regel zu localhost aufgelöst)
Klasse B-Netzwerke; in einem solchen Netz bezeichnen die ersten beiden Bytes das Netz, die letzten beiden die Rechner (2^¹⁶ - 2 = 65534 Rechner pro Netz); hier haben die beiden höchstwertigen Bits die Werte 10, die Adressen liegen also im Bereich zwischen 128.0.0.1 bis 191.255.255.254.
Klasse C-Netzwerke; drei Byte bezeichnen das Netz, ein Byte den Rechner; es sind pro Netz 254 Rechner möglich. Bei Klasse C-Netzwerkadressen haben die höchstwertigen Bits die Werte 110, die Adressen liegen also im Bereich zwischen 192.0.0.1 und 223.255.255.254.
Klasse D: Multicast-Adressen; die höchstwertigsten Bit haben die Werte 1110. Diese Adressen sind für das Ansprechen von Rechnergruppen vorgesehen, die dann auf dieser Adresse nur Daten empfangen, jedoch beliebig im verwendeten Netz verteilt sein können.
Klasse E: reserviert.Höchstwertige Bits haben die Werte 1111; diese Adressen werden im Internet nicht geroutet. Werte zwischen 240.x.x.x und 255.x.x.x.

In jedem der Bereiche A bis C sind Adressbereiche reserviert, die nur in Intranets verwendet werden sollen und im Internet nicht geroutet werden; die wohl am häfigsten verwendete Adresse 192.168.1.1 zum Beispiel liegt in so einem Bereich.

Die Netzwerk- oder Subnetzmaske

Da diese Einteilung zunehmend aufgegeben wird, braucht es jetzt eine andere Angabe, welcher Teil der IP-Adresse das Netz und welcher den Rechner bezeichnet; dazu verwendet man die sogenannte Netzwerkmaske. Zudem sind die Byte-Grenzen aufgegeben worden; es können jetzt also auch z.B. 10 Bit das Netz und die restlichen 22 Bit den Rechner bezeichnen.
Eine Netzwerkmaske sieht wie folgt aus (Standardbeispiel für ein Klasse C-Netz):
255.255.255.0
oder in binärer Schreibweise:
11111111 11111111 11111111 00000000
wobei die Lücken natürlich nur der Übersicht halber eingefügt worden sind.
Angenommen, wir haben eine Adresse
192.168.1.2
oder binär
11000000 10101000 00000001 00000011
und die dazugehörige Netzmaske
255.255.255.0
oder in binärer Schreibweise:
11111111 11111111 11111111 00000000
dann führt der prüfende Rechner eine AND-Operation durch:
11000000 10101000 00000001 00000011 AND
11111111 11111111 11111111 00000000
------------------------------------
11000000 10101000 00000001 00000000

das entspricht, wie man leicht sehen kann, der Dezimalschreibweise
192.168.1.0;
es handelt sich um die zugehörige Netzwerkadresse; dafür sollte er einen Eintrag in seiner Routing-Tabelle finden (mindestens einen Default-Gateway-Eintrag), die ihm sagt, wohin er die Pakete weitergeben soll.
Alles klar?

Der Aufbau:

1. Das OSI-Referenzmodell

Als Referenz für den Aufbau eines Kommunikationsmodell dient das von der ISO (International Standardisation Organization) entworfene OSI-Modell, das aus 7 Schichten besteht. Diese sind (von der Anwenderseite aus gesehen):

Application Layer; hier befinden sich alle Prozesse, die der Benutzer direkt aufruft (z.B. telnet)
Presentation Layer: dieses Layer ist dazu da, eine Übereinkunft über die Art der Darstellung z. B. von Zeichen zwischen verschiedenen Applikationen zu erreichen; diese Aufgaben werden in TCP/IP in der Regel von den Applikationen übernommen.
Session Layer: regelt Dinge, wie Abbruch, Neuaufbau, Transferrichtung innerhalb einer Sitzung; in TCP/IP nicht als einzelnes Layer realisiert, sondern wird dort von Protokollen des Transport Layers übernommen.
Transport Layer; Fehlererkennung, Handshake und ähnliche Dinge sind auf diesem Layer eingeordnet
Network Layer; Routing und Adressierung
Data Link Layer; Sicherung der Übertragung durch das Netzwerk
Physical Layer; regelt u.a. den Austausch und die Codierung von Bits, Übertragungsgeschwindigkeit, Voltage etc.

2. Das TCP/IP-Modell

TCP/IP ist im Gegensatz zum OSI-Schichtenmodell aus vier "Schichten" aufgebaut und basiert auf dem DoD-Modell (Department of Defence):

Application Layer
(Host-to-Host-)Transport Layer
Internet Layer
Network Access Layer

dabei ist das Bild der Schicht gewählt, um darzustellen, daß es sich um eigenständige Dienste handelt, die die aus den vorherigen Diensten kommenden Pakete verarbeiten und weiterreichen. Ähnlich geeignet wäre eventuell das Bild der Post; hier werden zum Beispiel ein Brief oder ein Paket zunächst vom Absender verpackt und adressiert; anhand der Adresse wird dieser Brief von dem Postamt erneut verpackt und mit einer weiteren Adressierung versehen und ggf. im Laufe des Transportes umgepackt. Das kann man sich etwa so vorstellen:

Zum Beispiel ein telnet (auf dem Application Layer) setzt ein Paket (das dort dann application message heißt) ab und schickt es an das "Postamt" TCP (auf dem Transport Layer); TCP fügt dem Paket ein paar Informationen (den sogenannten TCP-Protokollkopf) wie z. B. den Sender- und Empfängerport, Information darüber, wo im Datenstrom sich das aktuelle Paket befindet, eine Prüfsumme und ein paar weitere Angaben hinzu und gibt das Paket (jetzt ist es ein TCP-Segment oder eine transport message) weiter an das IP (auf dem -wir haben es uns schon gedacht- Internet Layer).
Dort wird es erneut verpackt, es werden Informationen wie die Version des IP-Protokolls (zur Zeit 4), eine eindeutige Bezeichnung dieses Paketes, Information darüber, ob dieses Paket notfalls umgepackt werden darf (in kleinere Einheiten zerlegt) und ob ihm weitere Pakete folgen, die zur selben Kette gehören, die Absender- und Empfängeradressen, über das Transportprotokoll (in unserem Beispiel 6 für TCP) und die sogenannte Lebenszeit hinzugefügt (der IP-Protokollkopf).
Von hier wird es (auf das Network Layer) an den Netzwerktreiber weitergereicht, z. B. als Ethernet-Frame den Ethernettreiber und zum Zielrechner bzw. zum Router weitergegeben; dort läuft der ganze Vorgang umgekehrt: der Ethernettreiber gibt das Paket an IP weiter, das anhand des Eintrags in Wort 5 erkennt, ob der eigene Host der Zielrechner ist (das sei in unserem Beispiel der Fall) und es dann anhand des Protocol-Eintrags an das entsprechende Protokoll weiterreicht; bei uns war das TCP, der Eintrag wuerde in unserem Beispielpaket also "6" lauten. Von hier wird das Paket anhand des Destination Port-Eintrags im TCP-Header an den Port 23 an den Telnetserver weitergereicht.
Die Layer im einzelnen:

2.1. Application Layer

Hier finden sich Protokolle wie Telnet, FTP, SMTP, HTTP, DNS (BIND), NFS; gegenüber dem unterliegenden Host-to-Host-Transport Layer werden die Applikation durch ihren Port identifiziert, an dem sie lauschen (SMTP zum Beispiel an Port 25).

2.2. (Host-to-Host-)Transport Layer

Hier finden sich die Transportprotokolle wie TCP, UDP, ICMP und andere; wir werden hier TCP und UDP als zwei sehr unterschiedliche Transportprotokolle betrachten, die auch die beiden bedeutendsten sind (IMHO).

TCP

Eigenschaften von TCP:

verbindungsorientiert (three way handshake)
gesichert (Quittungsnummern, Sequenznummern, Prüfsummen, Timeout)
erstellt eine bidirektionale Verbindung
bietet beidseits möglichen Verbindungsabbau
bietet Urgent Data
Applikation wird durch Port adressiert

Der Protokollkopf

Spezifiziert wird TCP im rfc 793 vom September 1981; hier der Protokollkopf:

Sender- und Empfängerport enthalten die jeweiligen Ports (siehe /etc/services);
Sequenznummer ist eine Zahl, die der sendende Host generiert bzw. um die gesendeten Bytes erhöht;
Quittungsnummer ist eine Zahl, die vom empfangenden Host am Anfang generiert und dann um die empfangenen Bytes erhöht wird;
Datenabstand: Länge des Protokollkopfes in 32 Bit-Worten zur Ermittlung des Datenbeginns
Flags:
1. URG: wenn gesetzt, ist der Urgent Pointer gültig
2. ACK: Quittungsnummer ist gültig
3. PSH: Daten in diesem Segment sofort der Anwendung übergeben
4. RST: Reset der Verbindung
5. SYN: Signalisiert den Wunsch zum Verbindungsaufbau
6. FIN: Signalisiert den Wunsch zum Verbindungsabbau
Fenstergröße: Grösse der maximal aufnehmbaren Datenmenge vom empfangenden Host (Receive Window)
Prüfsumme: Bildet über Kopf, Daten und Pseudo-Protokollkopf das Eins-Komplement einer 16 Bit langen Summe aller 16-Bit-Worte
Urgent Zeiger: Bildet zusammen mit der Sequenznummer einen Zeiger auf eine Stelle im Segment; die folgenden Daten werden als besonders wichtig gekennzeichnet.
Optionen: End of Option List, No Operation oder Maximum Segment Size; letzteres signalisiert die Bereitschaft, größere Pakete als 536 Bytes anzunehmen.

Verbindungsaufbau (three-way-handshake)

Hier versuchen wir einmal, darzustellen, was geschieht, wenn eine TCP-Verbindung zwischen zwei Hosts hergestellt werden soll:

Der initiierende Host sendet ein Paket mit gesetztem SYN-Flag und einer Sequenznummer (die hier 200 sei); darauf antwortet der angesprochene Rechner (hier ist nur die Kommunikation auf dem Transportlayer dargestellt), indem er ein Paket zurücksendet, in dessen TCP-Header die Sequenznummer hier mit 100 besetzt ist, die Sequenznummer des initierenden Hostes (nennen wir ihn mal host1) findet sich um eins erhöht (nämlich die Anzahl der empfangenen Datenbytes, die quittiert werden) als Quittungsnummer wieder und der angesprochene Host (den wir von nun an host2 nennen) hat zudem die SYN- und ACK-Flags gesetzt.
Alles klar soweit? Sonst nochmal lesen, ich warte solange.....
OK?
Schließlich schickt host1 ein Paket mit der Sequenznummer 201, der um ein (empfangenes Byte) erhöhten Quitungsnummer und gesetztem ACK-Flag. In diesem Paket befinden sich die ersten tatsächlichen Daten, da jetzt beide Rechner wissen, das der andere Host erreichbar und für Daten aufnahmebereit ist.
Die Analogie zur menschlichen Kommunikation:

Absender	Menschlich	Three way handshake bei TCP
Willi	(Hallo )Erwin?	SYN, Sequenznummer[Willi]
Erwin	Ja Willi?	SYN, ACK, Sequenznummer[Erwin], Quittungsnummer[Erwin](=Sequenznummer[Willi]+Datenmenge)
Willi	Ich hätte gerne....	ACK, Sequenznummer[Willi](=Quittungsnummer[Erwin]), Quittungsnummer[Willi](=Sequenznummer[Erwin]+Datenmenge) Daten....

Sliding window

Wieviel Daten der andere Rechner aufnehmen kann, teilt er im Window-(Fenstergröße-) Feld mit; soviel Daten darf der absendende Host ohne Quittung auf den Weg schicken. Gerät der empfangende Rechner in Not, weil er die Daten nicht mehr verarbeiten kann, dann verkleinert er sein Fenster, was die Kommunikation verlangsamt.
Diese Technik wird als sliding window-Technik bezeichnet; bei längeren Laufzeiten spart diese Technik Zeit und nutzt die vorhandene Bandbreite besser, da nicht erst auf die Quittung gewartet werden muß, bevor neue Daten auf den Weg geschickt werden können.

Datenaustausch

Hier sind unsere beiden Hosts ins Gespräch vertieft:

Was wir sehen:
host1 hat oben offensichtlich 5 Byte Daten geschickt (seit dem obigen Bild), den er bekommt seine Sequenznummer von oben (201) um 5 erhöht als Quittungsnummer zurück; gleichzeitig sendet host2 256 Byte Daten im Paket.
host1 antwortet, quittiert den Empfang der 256 Byte in der Quittungsnummer und sendet seinerseits 16 Bytes; diese quitiert host2 und sendet 128 Bytes und so weiter.

Beenden der Kommunikation

TCP ist ein höfliches Protokoll; so wird der Wunsch, die Kommunikation zu beenden, durch Setzen des FIN-Flags angekündigt; wenn also Host Willi alles weiß, was er wissen will, dann schickt er ein Paket mit gesetztem FIN-Bit.
Erwin weiss dann, daß Willis Pakete von nun an nur noch Bestätigungen seiner Pakete enthalten werden.
Willi seinerseits wartet, bis Erwin ebenfalls ein Paket mit gesetztem FIN-Flag schickt; erst dann ist die Verbindung beendet.

UDP

Eigenschaften von UDP:

verbindungslos
keine garantierte Zustellung, keine erneute Sendung nach Timeout
Applikation wird durch Port adressiert
Datenprüfsumme
schnell, wenig overhead

Spezifiziert wird UDP im rfc 768, hier der Header:

Portnummern referenzieren die entsprechenden Applikationen
Länge: die Länge des Datagramms incl. Kopf
Prüfsumme: 1-Komplement der Summe der 16-Bit-Worte des Kopfes, des Pseudokopfes und der Daten; falls 0, erhält der Empfänger keine Prüfsumme (SunOS).

2.3. Internet Layer

IP-Protokoll

Spezifiziert wird das IP-Protokoll im rfc 791 sowie im MIL-STD 1777; es stellt sozusagen den Kern von TCP/IP dar.
Es

ist verbindungslos
fragmentiert Pakete bei Bedarf
adressiert durch (in der Version 4) 32 Bit lange Adressen
hat eine Paketgröße von maximal 65535 Bytes
prüft lediglich den Protokollkopf, nicht die Daten
garantiert nicht selber die Zustellung des Paketes (das macht evtl. dann das Transportprotokoll)
bietet eine endliche Lebensdauer der Pakete
hat eine variable Länge des Protokollkopfes

Hier der IP-Protokollkopf:

Version: Version des IP-Protokolls, zur Zeit 4
Länge: Länge des IP-Protokollkopfes
Servicetypen: setzt mehrere unterschiedliche Leitungen zwischen den Rechnern voraus.
Hier der Aufbau dieses Feldes:
1. Priorität (3 Bit)
2. Wartezeit (1 Bit); wenn gesetzt, niedrige Wartezeit
3. Durchsatz (1 Bit); wenn gesetzt, hoher Durchsatz
4. Zuverlässigkeit (1 Bit); wenn gesetzt, hohe Zuverlässigkeit
5. Reserviert (2 Bit)
Paketlänge: genau das.
Identifikation:Identifikation für diese Paketkette, um alle Fragmente wiederzufinden. Wird vom absendenden Host vergeben.
DF-Bit: Don't fragment-Bit: verbietet das Zerteilen dieses Pakets, auch, wenn es dann verworfen werden muß.
MF-Bit: Es folgen weitere Fragmente; beim letzten Fragment steht dieser Wert auf "0"
Fragmentabstand: Lage dieses Pakets relativ zum Gesamtpaket in Einheiten von 8 Bytes
Lebenszeit: Dieser Wert wird von jedem Rechner, der das Paket verarbeitet, um die Zahl Sekunden verringert, die die Verarbeitung braucht; mindestens jedoch um eins. Da in der Regel die Verarbeitungszeit unter einer Sekunde liegt, ist letzteres der Regelfall; wenn dieser Wert "0" erreicht, wird das Paket verworfen und der absendende Rechner davon informiert. Der Befehl "traceroute" nutzt diese Eigenschaft von IP, indem er Pakete mit begrenzter Lebensdauer losschickt, deren Verfall dann von den verarbeitenden Rechnern quittiert wird.
Transportprotokoll, dem dieses Paket übergeben werden soll. Es bedeuten z. B.(weitere siehe /etc/protocols):
- 1: ICMP, das Internet Control Message Protocol
- 2: IGMP, das Internet Group Managment Protocol
- 6: TCP, das Transmission Control Protocol
- 17: UDP, das User Datagram Protocol
Kopfprüfsumme: Prüfsumme (Eins-Komplement der 16 Bit-Worte) über den IP-Header
Absenderadresse: klaro, oder?
Empfängeradresse: dito
Optionen:
1. Source Route: es wird ein Weg durch eine Liste von Rechnern vorgegeben (im Anschluss an den Header)
  1. strict source: diesem Weg muß genau gefolgt werden
  2. loose source: Zwischenstationen dürfen benutzt werden
2. Record Route: die Route des Pakets wird aufgezeichnet
3. Timestamp: die Uhrzeit beim Durchlauf wird aufgezeichnet
4. Security: siehe rfc 1038
5. Stream Identifier: veraltet
6. End of option list: Ende der Optionsliste (haben wir uns schon gedacht, gelle?).
7. No Operation: Na.....?
Fuelltext: hier wird aufgefüllt, bis der Header ein vielfaches von 32 Bit lang ist

2.4. Network Access Layer

Es gibt hier eine Reihe Protokolle, die auf das jeweilige physikalische Netzwerk zugeschnitten sind; dazu gehört zum Beispiel auch der bereits erwähnte Ethernet-Treiber. Eine weitere Aufgabe, die beim Ethernet auf diesem Layer erledigt wird, ist die Übersetzung von 4 Byte langen IP-Adressen zu 6 Byte langen Ethernet-Adresssen. Ethernet-Adressen meint die für jede Ethernet-Karte einmalige Kennung, an der die Karte in einem Netz (und mit ihr der Rechner, in dem sie steckt) identifiziert werden kann. Für diese Übersetzung ist das ARP, das Adress Resolution Protocol zuständig; das aber erkläre ich ein anderes Mal.

(ma)

Zum Weiterlesen...

Socolofsky T, Kale C; rfc 1180; 1991 (lokal in /usr/share/doc/rfc/rfc1180.txt.gz)
Weitere Bücher zum Thema auf der Bücherseite (Punkt 4)

Fußnoten

Die maximale Länge des Pakets folgt aus der Länge des Feldes "Paketlänge": da dieses 16 Bit lang ist und die Länge in Bytes angibt, kann die maximale Länge "1111 1111 1111 1111"=65535 Bytes nicht überschreiten (nicht 65536, da dies binär "1 0000 0000 0000 0000" ist). Zurück...

HTML neated by FaPi with kedit/Quanta/CVS/Linux. 00/09/03