nicht direkt sichtbar. Wenn Sie versuchen, einen Intranetserver einer Firma anzusprechen, dann werden Sie abgewiesen. Der Computer, der für die Ab- weisung zuständig ist, wird Firewall genannt.
Extranet Ein Extranet ist ein geschlossenes Netz zwischen verschiedenen Firmen un- ter Nutzung des Internets. So könnten ein Hersteller und seine Vertrags- händler in einem Extranet miteinander verbunden sein. Alle Teilnehmer an einem Extranet nutzen lokale Internetprovider für die nötigen Dienste.
Intranet und Extranet sind logische Einheiten und Komponenten, die das In- ternet nutzen.
Das Netzwerkprotokoll TCP/IP besitzt heute als das Standardprotokoll des Internet eine fundamentale Bedeutung. In diesem Kapitel sollen die Grund- lagen besprochen werden, um einen Ausblick auf den für die professionelle Programmierung notwendigen Wissensstand zu geben.
3.2 Die Internet-Protokolle und ihr Ursprung
Internet Protocol Suite (IPS)
Im Zusammenhang mit TCP/IP werden Sie häufig auf die Begriffe Internet Protocol Suite (IPS), Internet-Protokollfamilie oder einfach Internet-Proto- kolle stoßen. Dies sind eigentlich die heute üblichen Bezeichnungen. Im fol- genden Text werden wir vor allem die deutschen Begriffe einsetzen.
DoD / ARPANET Daneben werden die Internet-Protokolle auch als Department of Defense (DoD)- oder ARPANET-Protokolle bezeichnet. Dies ist in der Entstehungs- geschichte des Internet begründet, dessen Entwicklung Ende der sechziger Jahre durch das amerikanische Verteidigungsministerium initiiert wurde und im Aufbau des ARPANET (Advanced Research Project Agency) gipfelte.
Das ARPANET stellt damit die erste Implementierung des Internet mit sei- nen wesentlichen Protokollbestandteilen dar. Noch heute ist es, natürlich in weiterentwickelter Form, eines der größten zusammenhängenden IP-Netz- werke.
Der Beginn der Entwicklung plattformübergreifender Kommunikations- möglichkeiten zwischen Computersystemen liegt in einer Zeit, als an allge- mein gültige Standards in diesem Bereich noch nicht zu denken war. Man- gels Alternativen entschlossen sich aber nach öffentlicher Verfügbarkeit der Internet-Protokollfamilie immer mehr Hersteller, diesen Quasi-Standard zu unterstützen und kompatible Netzwerklösungen zu entwickeln.
3.2.1 Die Organisationen ICANN und IANA
Für die Festlegung und Sicherung eines für das Internet allgemein gültigen Domain-Standards zeichnen vor allem zwei Institutionen verantwortlich:
ICANN 왘 ICANN (Internet Corporation for Assigned Names and Numbers)
Diese Organisation wurde erst im Oktober 1998 gegründet und dient der Sicherstellung der technischen Rahmenbedingungen für das Internet. Sie zeichnet für die grundlegenden Kommunikationsstandards verantwort- lich, welche vormals allein durch die US-Regierung beziehungsweise durch von ihr beautragte Organisationen wahrgenommen wurden. So obliegt ihr die Koordination des gesamten Internet-Rootserversystem.
Darüber hinaus werden innerhalb dieses Gremiums Vorschläge der In- ternet-Community aufgegriffen und diskutiert.
Die Verwaltung der generischen TLDs (gTLDs wie COM, NET etc.) liegt ebenfalls in der Verantwortung der ICANN. So werden hier die Unter- nehmen registriert und zugelassen, die für die Vergabe von SLDs direkt unterhalb der TLDs weltweit verantwortlich sind.
Weitergehende Informationen finden Sie auch auf der ICANN-Website:
www.icann.org
왘 IANA (Internet Assigned Number Authority) IANA
Die IANA ist wie die ICANN eine Non-Profit-Organisation und dient der Sicherstellung der korrekten Vergabe der IP-Nummern und der zen- tralen Verwaltung der Country Code Top-Level Domains (ccTLDs wie US, DE).
Weitere Informationen finden Sie auch auf der Website der IANA:
www.iana.org
3.2.2 Das ISO/OSI-Modell und die Internet-Protokolle
International Organization for Standardization
1977 begann die ISO (International Organization for Standardization) mit den Ar- beiten an einem allgemein gültigen Standard für die Kommunikation mit (und zwischen) Computersystemen. Im Ergebnis dieser Bemühungen entstand das heute bekannte und für die Beschreibung technischer Kommunikationspro- zesse oft herangezogene ISO/OSI-Referenzmodell (Reference Model for Open Systems Interconnection of the International Organization for Standardization).
Das ISO/OSI-Referenzmodell
Dieses Modell teilt Netzwerkverbindungen in sieben logische Schichten ein, die jeweils eigene Aufgaben übernehmen. Eine höhere Schicht baut dabei immer auf den Funktionen der tiefer liegenden auf. Die folgenden sieben Schichten werden dabei unterschieden:
Tabelle 3.1:
Die sieben Schich- ten des ISO/OSI- Referenzmodells
Nachfolgend finden Sie, beginnend bei der untersten Schicht, die einzelnen Funktionen etwas genauer:
Bitübertragung 왘 Schicht 1: Bitübertragungsschicht (physical layer). Hier wird die physikali- sche Übertragung (elektrisch sowie mechanisch) definiert: das Medium (Kabel, Funk, Infrarot), die gesendeten Signale usw.
Sicherung 왘 Schicht 2: Sicherungsschicht (data link layer, auch Verbindungsschicht oder MAC-Layer genannt). Hier werden die Daten in einzelne Rahmen aufgeteilt und gesichert übertragen.
Vermittlung 왘 Schicht 3: Netzwerkschicht (network layer, auch Vermittlungsschicht).
Zentrale Aufgabe ist die Bestimmung eines optimalen Weges durch ein Netzwerk.
Transport 왘 Schicht 4: Transportschicht (transport layer). Diese Schicht stellt einen ge- sicherten Kanal zwischen zwei Stationen her, sodass die Daten einfach seriell geschrieben bzw. gelesen werden können.
Sitzung 왘 Schicht 5: Sitzungsschicht (session layer, auch Kommunikationssteue- rungsschicht). Diese Schicht synchronisiert das Zusammenspiel mehre- rer Stationen. Es wird beispielsweise festgelegt, wie eine Sitzung zeitlich abzulaufen hat (Aufforderung zum Senden eines Kennwortes, Senden des Kennwortes selbst, Bestätigung des empfangenen Kennwortes usw.).
Darstellung 왘 Schicht 6: Darstellungsschicht (presentation layer). Hier werden die Daten in ein einheitliches Format transformiert, zum Beispiel durch Alphabet- umwandlungen oder Datenkompression. An dieser Stelle gehen oft die Umlaute verloren, wenn die Übertragung mit 7 Bit statt 8 Bit erfolgt.
Anwendung 왘 Schicht 7: Anwendungsschicht (application layer). Diese Schicht be- schreibt die Schnittstelle, über die Anwendungen auf Dienste eines ande- ren Systems zugreifen können.
Kommunikations- prozesse
Jede Schicht kommuniziert mit der entsprechenden Schicht auf dem ande- ren System (logischer Datenfluss), indem sie Daten entweder an die darüber oder darunter liegende Schicht weiterleitet (physikalischer Datenfluss). Dabei verfügt jede Schicht über Schnittstellen, die folgende Abläufe ausführen können:
Nr. Schicht Funktionen
7 Anwendung Nutzerschnittstelle, Kommando-Auswahl 6 Darstellung Kodierung, Dekodierung, Kompression 5 Sitzung Steuerung der Kommunikation 4 Transport Verbindungsaufbau, Datentransport 3 Vermittlung Adressierung, Routing
2 Sicherung Fragmentierung, Kontrolle, Prüfung 1 Bitübertragung Physischer Datentransport
왘 Austausch von Daten mit der darüber liegenden Schicht
왘 Austausch von Daten mit der darunter liegenden Schicht
왘 Entscheidung darüber, welche Daten an dieselbe Schicht im anderen Sys- tem übermittelt werden
Wenn die Sitzung auf Schicht Fünf ihre Daten an die Schicht Vier übergeben hat, wartet sie, bis die Antwort von Schicht Fünf des anderen Systems zu- rückkommt. Wie diese Nachricht auf das andere System gelangt, ist Aufgabe von Schicht Vier, die sich wiederum nur mit Schicht Drei in Verbindung setzt usw. Der wirkliche Datenaustausch findet nur auf Schicht Eins statt.
Durch dieses Verfahren sind höhere Schichten völlig unabhängig von den phy- sikalischen Gegebenheiten (Funknetz, ISDN, Glasfaser usw.). Andererseits kön- nen über eine funktionierende physikalische Verbindung (Schicht Eins) alle Ar- ten von Daten und Protokollen (höhere Schichten) benutzt werden.
Abbildung der Internet-Protokolle im ISO/OSI-Referenzmodell
Der theoretische Ansatz des Referenzmodells geht davon aus, dass auf jeder Ebene ein Protokoll arbeitet. Allerdings trifft das gerade auf die Internetpro- tokolle nicht zu. Deren Entwicklung beginnt bereits, bevor die ISO am Refe- renzmodell arbeitet und verläuft praktisch parallel zu diesem.
4-Schichten- modell der Internet-Proto- kollfamilie
Die Internet-Protokollfamilie kann aber durchaus mit dem ISO/OSI-Referenz- modell verglichen werden. Die Daten durchlaufen beim Transport über ein Übertragungsmedium, wie beispielsweise ein Kupferkabel, üblicherweise alle Schichten von der Anwendung des Senders bis hin zum Empfänger.
Kapselung der Daten
So übergibt eine Anwendung wie beispielsweise ein FTP-Client oder ein Ter- minalprogramm für Telnet seine Datenpakete an die Transportschicht. Hier bekommt das Paket einen Header, in dem weitere Informationen zu dessen Aufbau hinterlegt werden. Wird das Protokoll TCP verwendet, befinden sich im so genannten TCP-Header Angaben zum Quell- und Zielport sowie die TCP-Flags. Bei der Übergabe an die nächste Schicht (Netzwerk) wird das Paket um einen weiteren Header, beispielsweise den IP-Header, erweitert. In diesem werden unter anderem die IP-Quell- und Zieladresse hinterlegt, um den richtigen Weg im Netzwerk, auch über IP-Router, finden zu können.
Schließlich erfolgt eine letzte Erweiterung des Pakets in der Verbindungs- schicht. Der neue Header enthält dann unter anderem Informationen zum verwendeten Übertragungsverfahren wie Ethernet oder Token Ring. Beim Weg zum Empfänger werden dann alle Schichten rückwärts wieder durch- laufen und die jeweiligen Header-Informationen entfernt. Dieser ganze Vor- gang wird auch als Daten-Kapselung bezeichnet.
Mit Hilfe dieser Datenkapselung können Kommunikationslösungen ge- schaffen werden, welche unabhängig vom verwendeten technischen Verfah- ren funktionieren. So ist beispielsweise die Verwendung der IP-Protokollfa- milie nicht an ein bestimmtes Übertragungsverfahren gebunden, sondern ist auch über Ethernet, Token Ring, ATM, PPP für die Datenfernübertragung oder andere, vielleicht erst in Zukunft verfügbare Medien möglich.
Die wichtigsten Protokollbestandteile der Internet-Protokollfamilie werden eingehender in folgenden Abschnitt beschrieben. Diese Protokolle können auch bei der Programmierung von Active Server Pages von Bedeutung sein, die in FrontPage-Webs eingesetzte serverseitige Script-Umgebung.
3.2.3 Request For Comments (RFC)
RFC Als wichtiges Standardisierungsinstrument in der Protokollwelt sind seit mehr als 30 Jahren die so genannten RFCs in Gebrauch. RFCs (Request For Comments) sind öffentlich zugängliche Dokumente, die einem einheitlichen Schema und einer fortlaufenden Nummerierung folgen. In diesen können sich entsprechend qualifizierte Personen oder Hersteller äußern.
Fortlaufende Nummerierung
RFCs tragen generell eine fortlaufende Nummer. RFC 0001 wurde am 7.
April 1969 veröffentlicht. Ändert sich ein RFC, wird eine neue Nummer ver- geben und das alte Dokument als obsolet gekennzeichnet. Im vorliegenden Buch wird an einigen Stellen auf RFCs verwiesen. Damit können Sie, wenn Sie weitergehende Informationen benötigen, schnell die entsprechenden Quellen des betreffenden Standards oder der Technologie finden.
Stufen eines RFC
Ein RFC kann mehrere Stufen durchlaufen, bis es vielleicht einmal den „offi- ziellen“ Status in Form eines anerkannten Standards erlangt. Eine der be- kanntesten Standardisierungsgremien ist die IETF (Internet Engineering Task Force).
Mögliche Stufen eines RFC sind:
Experimental 왘 Experimental (Experimentell)
Das hier spezifizierte Protokoll oder Verfahren sollte nur zu experimen- tellen Zwecken oder zur Evaluierung eingesetzt werden. Es sind noch grundlegende Änderungen möglich, ebenso wie das völlige Verwerfen der Entwicklung durch den Hersteller.
Proposed Standard
왘 Proposed Standard (Vorgeschlagener Standard)
Als Vorschlag werden RFCs gekennzeichnet, wenn die Standardisierung gezielt angestrebt wird. Dennoch befindet sich das Protokoll noch in der Entwicklung und wird voraussichtlich noch Änderungen unterworfen sein. Oft sind solche Änderungen auch Kompromisse, die notwendig sind, um die Anerkennung als Standard zu erlangen.
Draft 왘 Draft (Entwurf)
In diesem Stadium, das Sie häufiger beobachten können, befinden sich Dokumente, die als Standard ernsthaft in Betracht gezogen werden.
Praktisch ist die Entwicklung abgeschlossen. Durch die Veröffentlichung gelangen die Methoden zum praktischen Einsatz. Im Feldtest können sich Probleme herausstellen, die noch zu Änderungen am endgültigen Standard führen.
Standard 왘 Standard
In dieser Phase ist das RFC verabschiedet und endgültig. Wenn sich Än- derungen oder Weiterentwicklungen ergeben, wird eine neue Nummer vergeben und das alte RFC wird obsolet. Als Verabschiedungsgremium agiert das IAB (Internet Architecture Board).
Neben diesen grundlegenden Eigenschaften können ergänzende Hinweise anfallen, die sich teilweise auch auf Systeme beziehen:
Recommended 왘 Recommended (empfohlen)
Das Protokoll wird zum Einsatz empfohlen.
Not recom- mended 왘 Not recommended (nicht empfohlen)
Es ist nicht empfehlenswert, dieses Protokoll einzusetzen, weil es inzwi- schen oft ein neueres gibt.
Limited use 왘 Limited use (begrenzter Einsatz)
Dieses Protokoll wird nur für sehr eng gesteckte Spezialfälle zur Anwen- dung kommen.
Required 왘 Required (erforderlich)
Die Anwendung ist im Zusammenhang mit anderen Protokollen zwin- gend.
Elective 왘 Elective (wahlweise)
Für den vorgesehenen Zweck stehen mehrere Protokolle gleichwertig zur Auswahl.
STD-Nummern
Aus den gültigen, verabschiedeten RFCs werden Standards, indem eine Standardnummer STD zugewiesen wird. Manchmal umfasst ein solcher Standard mehrere RFCs. STD-Nummern sind endgültig, werden also nicht geändert, wenn sich die zugrunde liegenden RFCs verändern. Die Zusam- menfassung der STDs und RFCs wird in der RFC 2500 spezifiziert.
Mehr Information und vor allem alle RFCs und STDs finden Sie im Internet unter den folgenden Adressen:
RFCs im Internet www.faqs.org
www.rfc-editor.org
Im Buch wird an vielen Stellen auf die zum Thema passende RFC hingewie- sen.
3.2.4 Internetprotokolle im Detail
In diesem Abschnitt werden die Protokolle der Internet-Protokollfamilie nä- her betrachtet. Dabei stehen vor allem die Protokolle im Mittelpunkt, die aus Sicht der Webserververwaltung wichtig sind.
Tabelle 3.2:
Übersicht über die behandelten Inter- net-Protokolle
Andere wichtige Protokolle der Schicht Vier (Anwendung) der Internet-Pro- tokollfamilie wie SMTP oder HTTP werden eingehend in Abschnitt Höhere Netzwerkprotokolle Höhere Netzwerkprotokolle ab Seite Höhere Netz- werkprotokolle behandelt.
Internet Protocol (IP)
Das meistverwendete Protokoll auf der Schicht Zwei (Netzwerk) der Inter- net-Protokollfamilie ist IP. Das wesentliche Merkmal dieses Protokolls be- steht darin, dass jeder Netzwerkknoten (jedes Endgerät im Netzwerk) direkt angesprochen werden kann. Zu diesem Zweck verfügt jeder Knoten über eine IP-Adresse.
Zustellung ohne Fehlerkorrektur
IP ist für die Zustellung der Datenpakete verantwortlich, hat jedoch keine Mechanismen zur Fehlerkorrektur. Werden TCP-Datagramme transportiert, stellt TCP sicher, dass auch alle Daten garantiert fehlerfrei übertragen wer- den. Bei UDP-Datagrammen hingegen steht die fehlerfreie Übertragung zu- gunsten einer maximalen Performance nicht im Vordergrund.
IP-Fragmentierung IP zerlegt die Datenpakete der darüber liegenden Schicht in IP-Pakete, wel- che ihrerseits aus dem IP-Header und dem Datenteil bestehen.
MTU-Parameter Für den Datentransport im Netzwerk besitzt IP die Fähigkeit, die Pakete in kleinere Einheiten aufzuteilen (fragmentieren). Das kann notwendig sein, wenn das zu übertragene Paket die maximale IP-Paketgrößenbeschränkung eines Netzwerkgerätes (beispielsweise eines IP-Routers) überschreitet. Die- ser Parameter wird auch mit MTU (Maximum Transmission Unit) bezeichnet.
Sicherheitsrisiko IP-Fragmente
Fragmentierte IP-Datenpakete können ein nicht unerhebliches Sicherheitsri- siko darstellen. Die einzelnen Fragmente können manipuliert den Zielhost erreichen. Geschickte Hacker sind in der Lage die Fragmente so zu bilden, dass diese nicht direkt aneinander passen, sondern gemeinsam überlap- pende Bereiche enthalten. Beim Zusammensetzen im Zielsystem kann es dann durchaus dazu kommen, dass sich das Betriebssystem ins Nirwana verabschiedet. Heute gängige Firewall-Systeme weisen IP-Fragmente in der Regel ab.
Path MTU Discovery
Durch den Einsatz der „Path MTU Discovery“-Technologie in Netzwerksys- temen wie Routern wird die IP-Fragmentierung überflüssig. Dabei handeln die beteiligten Systeme untereinander aus, wie groß die maximale Paket- größe (MTU) sein darf. Der eine Host startet dann Übertragungsversuche mit steigenden IP-Paketgrößen (Fragmentierungsflag: „Nicht fragmentie- ren“). Dies geschieht solange, bis er eine ICMP-Fehlermeldung „Paket zu groß“ zurückerhält.
Protokoll Funktion Seite
IP Adressierung und Transport der Datenpakete (keine Fehlerkorrektur)
68 TCP Gesicherter Transport der Daten mit Fehlerkorrektur 72
IP-Broadcast
Die meisten IP-Pakete im Netzwerk werden an einen bestimmten Zielkno- ten geschickt. Dies wird auch mit Unicast bezeichnet. Gehen IP-Pakete an alle erreichbaren Knoten, spricht man von Broadcast. Mit der Broadcast- Adresse 192.168.100.255 erreichen Sie alle Hosts im angenommenen Netz- werk 192.168.100 (Netzmaske 255.255.255.0). Soll eine Nachricht an die über Router verbundenen Netzwerke 192.168.100, 192.168.101 und 192.168.102 gehen, ist die Broadcast-Adresse 192.168.255.255.
IP-Multicast
Über IP-Multicast lassen sich bestimmte Hosts adressieren. Dazu werden Adressen aus dem IP-Bereich 224.0.0.0 bis 239.255.255.255 gewählt und zur Bildung von so genannten Multicast-Gruppen benutzt. Eine einzelne IP- Adresse aus diesem Bereich steht dann für eine Multicast-Gruppe (beispiels- weise 224.1.1.22). Über IP-Multicast-Pakete werden nur IP-Protokolle über- tragen, die nicht sitzungsorientiert (wie etwa TCP; siehe nächster Abschnitt) arbeiten. Das sind beispielsweise UDP oder Routingprotokolle wie IGMP und OSPF.
Über UDP lassen sich Datenströme übertragen, bei denen es auf einen abso- lut fehlerfreien Transport nicht ankommt. Bei der Verwendung von IP-Mul- ticast anstelle von Unicast lässt sich die verfügbare Bandbreite für eine höhere Anzahl von Nutzern wesentlich effektiver nutzen. Statt Einzelver- bindungen mit dem entsprechenden Overhead aufzusetzen, können die den entsprechenden Multicast-Gruppen zugewiesenen Hosts den Datenstrom direkt empfangen. Dabei ist die Vorgehensweise mit dem des Abonnierens eines bestimmten Fernsehkabelkanals vergleichbar. Eine Kabelgesellschaft speist eine Reihe von Kanälen in das Kabel ein, die jeweils nur von verschie- denen Gruppen von Kunden empfangen werden können.
Damit eignet sich IP-Multicast insbesondere für die Implementierung von Audio- und Video-Streaming (beispielsweise für Konferenzsysteme). Das ist momentan auch die häufigste Anwendung im Internet.
IP-Adress- versionen
Die heute gebräuchliche und jedem bekannte Form einer IP-Adresse besteht aus vier dezimalen Zahlen, die jeweils durch einen Punkt voneinander ge- trennt sind. Hier kann sich in Zukunft einiges ändern, sodass sich eine nä- here Betrachtung der IP-Adressversionen lohnt.
왘 Internet Protocol Version 4
Heutiger Standard
Im derzeitigen Standard IPv4 (Internet Protocol Version 4) besteht die IP- Adresse aus vier Oktetts. Jedes Oktett entspricht einem Byte (0–255). Zur besseren Lesbarkeit werden sie dezimal ausgeschrieben und durch Punkte getrennt (beispielsweise 195.145.212.138). Theoretisch lassen sich damit 2564 = 232 = 4.294.967.296 verschiedene Adressen darstellen. In der Realität verbleiben aber weniger direkt im Internet nutzbare Adressen übrig, da ein Teil davon für die nichtöffentliche Verwendung reserviert ist (siehe auch Abschnitt Spezielle IP-Adressen ab Seite 71). Letztlich bleibt festzustellen, dass der einmal mit IPv4 definierte Adressraum langsam knapp wird und auf absehbare Zeit nicht mehr ausreicht.
왘 Internet Protocol Version 6
Zukunft Mit IPv6 wird die Größe einer IP-Adresse von 4 auf 16 Oktetts erweitert.
Der derzeitigen Adressenverknappung mit IPv4 kann damit massiv ent- gegengetreten werden. Es können jetzt 2128 statt 232 Adressen gebildet werden. Dies entspricht einer Menge von etwa 3,4 x 1038 Computern oder anderen Systemen, die mit einer eindeutigen IP-Adresse versorgt wer- den könnten, was auch für die weitere Zukunft ausreichend dimensio- niert ist.
Erweiterte Möglichkeiten
Neben einer grundsätzlich höheren Anzahl an verfügbaren Adressen bringt IPv6 auch weitere Möglichkeiten mit. So lassen sich beispielsweise unterschiedliche Datentypen spezifizieren (wie etwa Video- oder Ton- Übertragungen), die gegenüber weniger zeitkritischen Datentypen (zum Beispiel E-Mails) bevorzugt bearbeitet werden. Damit können Echtzeit- anwendungen besser mit der nötigen Bandbreite ausgeführt werden.
Diese neue IP-Version steht kurz vor der Praxiseinführung. Erste Geräte unterstützen es bereits, der Großteil des Internets läuft aber noch unter der alten Version 4. Alle folgenden Ausführungen im vorliegenden Buch sind der derzeitigen Praxis angepasst und beschränken sich auf die aktu- elle IP-Version 4.
Subnetze und Netzwerkklassen
Jede IP-Adresse wird in einen Netzwerk- und einen Hostbereich aufgeteilt. Da- für wird eine so genannte Subnetzmaske eingerichtet, die angibt, wie viele Bits einer Adresse zum Netz und wie viele zum Rechner gehören. Hier ein Beispiel in dezimaler und binärer Notation für die IP-Adresse 192.168.100.38 mit der Subnetzmaske 255.255.255.0.
Tabelle 3.3:
Netzwerk- und Hostadresse in dezi- maler und binärer Form
Mit der Subnetzmaske 255.255.255.0 können in einem Netzwerk bis zu 254 Rechnern adressiert werden. Das ist für kleinere Netzumgebungen ausrei- chend. Die Null ist als reguläre Host-Adresse nicht zulässig (kennzeichnet das Netzwerk), ebenso die 255. Die 255 wird als Broadcast-Adresse benutzt, wenn alle Hosts angesprochen werden sollen (siehe auch Seite IP-Broad- cast).
Subnetzmaske Die Subnetzmaske besteht generell aus einem durchgängigen Bereich von binären Einsen. Es hat sich eingebürgert, die Einsen zu zählen und in der Kurzform /n hinter der Netzwerkadresse aufzuschreiben. Eine Angabe von 192.168.100.0/24 bedeutet also Netzadressen im Bereich von 192.168.100.x mit einer Subnetzmaske von 255.255.255.0 (24 Einsen).
Netzwerkbereich Hostbereich
Dezimal Binär Dez Binär
Subnetz- maske
255.255.255 11111111.11111111.11111111 0 00000000 IP-
Adresse
192.168.100 11000000.10101000.01100100 38 00100110
Über die Aufsplittung der IP-Adresse in den Netzwerk- und den Hostbe- reich kann der Host einfach feststellen, ob diese im eigenen (Sub)-Netz oder in einem anderen liegt. In unserem Beispiel würde dann die Adresse 192.168.101.56 einen Host im (anderen) Subnetz 192.168.101 adressieren, während 192.168.100.78 im gleichen Netz zu finden ist.
Die Netzwerk- klassen
Eine IP-Adresse enthält im Netzwerkbereich eine Netzwerkkennung, die die verwendete Netzwerkklasse angibt. Es werden fünf verschiedene Netz- werkklassen (A bis E) unterschieden, wobei jeder Klasse eine bestimmte Standard-Subnetzmaske zugeordnet ist.
Klasse A
Ein Klasse-A-Netz hat standardmäßig die Subnetzmaske 255.0.0.0. Das erste Bit der Adresse ist auf 0 gesetzt.
Klasse B
Ein Klasse-B-Netz hat die Subnetzmaske 255.255.0.0. Die ersten beiden Bits der Adresse sind auf 10 gesetzt.
Klasse C
Ein Klasse-C-Netz hat die Subnetzmaske 255.255.255.0. Die ersten drei Bits der Adresse sind hier auf 110 gesetzt.
Klasse D und E
Daneben gibt es noch Klasse-D- (beginnt mit 1110) und Klasse-E-Netze (be- ginnend mit 1111). Klasse-D-Adressen dienen zur Bildung von Multicast- Gruppen (siehe Seite IP-Broadcast), Klasse-E-Netze sind für Spezialfälle re- serviert.
Spezielle IP-Adressen
Es gibt eine Reihe von IP-Adressen, die nicht im öffentlichen Internet oder generell nicht im Netzwerk selbst zum Einsatz kommen und für spezielle Einsatzzwecke reserviert sind.
Broadcast- Adressen
Eine Broadcast-Adresse teilt dem Rechner mit, wie er alle Rechner in seinem Netz auf einmal erreichen kann (so genanntes Broadcast). Dabei werden ein- fach alle Bits im Rechnerbereich der Adresse auf Eins gesetzt (allgemeingül- tige Definition für ALL-ONE-Broadcasts). Die Standard-Broadcast-Adresse für einen Rechner aus dem Netz 192.168.100.0/24 wäre demnach 192.168.100.255. Sie können deshalb Adressen, die auf 255 enden, nicht als reguläre Netzwerkadresse angeben.
Loopback
Mit einer Adresse, die im ersten Oktett eine 127 enthält, adressiert sich jeder Rechner selbst (Loopback), was zu Tests der Netzwerksoftware benutzt wer- den kann. Eine solche Adresse ist daher niemals auf dem Kabel zu sehen.
Reservierte Adressen
Adressen aus den Klasse-D- und -E-Netzen sind für bestimmte Zwecke re- serviert. Die Adressen 224.x.x.x bis 255.x.x.x dürfen deshalb nicht für die normale Adressierung von Hosts benutzt werden. Genauere Informationen dazu stehen im RFC 2236.
Private Netzwerkadressen
In jeder IP-Netzklasse (siehe vorhergehender Abschnitt) gibt es Adressberei- che, die nicht im Internet selbst zulässig sind und somit für die Implementie- rung lokaler Netzwerke genutzt werden können.
Tabelle 3.4:
Private Netzwerk- adressen je Netz- klasse
NAT Für die Anbindung lokaler Netzwerke an das Internet, in denen diese priva- ten IP-Adressen verwendet werden, kommt NAT (Network Adress Transla- tion) zum Einsatz. Dabei werden die Anfragen der Clients, die über eine pri- vate IP verfügen, in die jeweilige öffentliche IP-Adresse des Internet-Routers übersetzt. Dieses Verfahren wird auch Masquerading genannt. NAT kommt beispielsweise in Internet-Routern zum Einsatz, die lokale Netzwerke mit dem Internet verbinden.
IP-Adressvergabe im Internet
Jede öffentliche IP-Adresse ist weltweit eindeutig und wird von der IANA an die drei Organisationen APNIC, ARIN und RIPE vergeben, die diese dann wiederum an Endkunden (Firmen oder Internetprovider) verteilen. Weitere Informationen gibt es bei den entsprechenden Organisationen unter folgen- den Adressen:
왘 IANA (Internet Assigned Numbers Authority):
www.iana.net
왘 APNIC (Asia-Pacific Network Information Center):
www.apnic.net
왘 ARIN (American Registry for Internet Numbers):
www.arin.net
왘 RIPE NCC (Réseaux IP Europeens):
www.ripe.net
Generell bleibt festzuhalten, dass jegliche Verwendung von IP-Adressen bei direkt am Internet angeschlossenen Computern oder anderen Netzwerkge- räten sich nach diesen Bestimmungen zu richten hat. Für den Aufbau lokaler Netzwerke empfiehlt sich im Regelfall die Einrichtung von IP-Adressen aus dem nichtöffentlichen (privaten) Adressbereich (siehe vorhergehender Ab- schnitt).
Transmission Control Protocol (TCP)
Verbindungs- orientiert mit Fehlerkorrektur
Dieses Protokoll ist das meistbenutzte der Schicht Drei (Transport) der Inter- net-Protokollfamilie. Es arbeitet verbindungsorientiert und ist in der Lage, eine Fehlerkorrektur durchzuführen. Eine Verbindung wird dabei über Ports zwischen Sender und Empfänger hergestellt (siehe auch Abschnitt Port- und Protokollnummern auf Seite 75). Damit ist auch ein gleichzeitiges Senden und Empfangen, eine so genannte vollduplexe Verbindung, möglich.
Klasse Anz. Subnetze Nutzbare Adressbereiche
A 1 10.0.0.0 bis 10.0.0.255
B 16 172.16.0.0 bis 172.31.255.255
C 256 192.168.0.0 bis 192.168.255.255
Aufbau einer TCP- Verbindung
Für den Aufbau einer TCP-Verbindung spielen das ACK- und das SYN-Flag eine entscheidende Rolle. So ist beim ersten TCP-Paket das ACK-Flag stets auf 0 gesetzt. Mit einem Handshake über drei Datenpakete wird die Verbin- dung aufgebaut.
Beenden der TCP- Verbindung
Zum Beenden der Verbindung werden das RST- oder das FIN-Flag benutzt.
Ein gesetztes RST zeigt einen Verbindungsfehler an, während über FIN (wird sowohl von Empfänger als auch vom Sender im jeweils letzten Paket gesetzt) ein normaler Verbindungsabbau durchgeführt wird.
Kontrolle der Paketreihenfolge
Über die Sequenz- und Bestätigungsnummern wird dafür gesorgt, dass alle Datenpakete in der richtigen Reihenfolge beim Empfänger zusammenge- setzt und doppelt versandte Pakete ignoriert werden können. Beide Hosts generieren unabhängig voneinander eine eigenständige Sequenznummer, die sie sich beim Aufbau der Verbindung übermitteln (wenn SYN gesetzt ist). Danach werden die Sequenznummern jeweils erhöht (um die Anzahl der Datenbytes im Paket). So wird sichergestellt, dass die Pakete beim Emp- fänger in der richtigen Reihenfolge wieder zusammengesetzt werden kön- nen.
Prüfsumme
Für die Sicherstellung eines ordnungsgemäßen Datentransfers ist allein die Kontrolle der richtigen Reihenfolge der Pakete nicht ausreichend. Über die Prüfsumme kann daher ermittelt werden, ob das Datenpaket selbst korrekt übertragen worden ist. Die Prüfsumme wird aus der Summe der 16-Bit- Wörter des TCP-Pakets berechnet, wobei bestimmte IP-Headerinformatio- nen mit einbezogen werden.
Port- und Protokollnummern
Für die eindeutige Identifizierung der Protokolle und Ports bei der Netz- werkkommunikation über IP, TCP und UDP gibt es die so genannten Port- und Protokollnummern. Vor der Explosion der Protokolle (es gibt inzwi- schen Hunderte solcher Kombinationen aus Protokollen und Ports), wurden diese in der RFC 1700 geführt. Da RFCs keine Versionsnummer besitzen und bei jeder Änderung durch eine neue ersetzt werden, würde dies zu einer In- flation von RFCs führen. Die für die Nummernvergabe zuständige Organi- sation IANA verwaltet deshalb die Nummern heute direkt auf ihrer Website:
http://www.iana.org
Ports
Multiplexing
Damit ein Rechner gleichzeitig mehrere Verbindungen (Multiplexing) bear- beiten kann, müssen diese unterschieden werden. Dazu bedient sich das TCP der Ports. Jeder Anwendung, die das TCP benutzen will, wird ein Port zugeordnet. Es gibt 65.535 verschiedene Ports, fortlaufend nummeriert. Da- bei gelten folgende Grundsätze:
왘 Ein Paar aus IP-Adresse und Port wird Socket genannt.
왘 Eine Verbindung zwischen zwei Rechnern ist wiederum eindeutig durch zwei Sockets definiert.
왘 Ein Rechner kann mehrere TCP-Verbindungen gleichzeitig bearbeiten.
Dafür werden verschiedene Ports definiert. Dieser Vorgang wird als
„Multiplexing“ bezeichnet.
Eine Portbezeichnung wird normalerweise hinter einem Doppelpunkt an die IP-Adresse oder den DNS-Namen gehängt, beispielsweise wie folgt:
192.168.0.101:80.
Ports Das Port-Konzept lässt sich in etwa mit einer Telefonnummer vergleichen:
Der Netzwerkteil einer Internet-Adresse entspricht der Vorwahl, der Host- Teil der eigentlichen Telefonnummer und der Port schließlich einer Neben- stellennummer. Dabei wird eine TCP-Verbindung generell eindeutig durch die beteiligten Sockets definiert (Sender und Empfänger). Es kann keine zwei identischen Socket-Paare zur gleichen Zeit geben. Der Sender bestimmt eine Portnummer per Zufallsgenerator. Damit ist es beispielsweise möglich, dass von einem Rechner zwei Telnet-Verbindungen zu dem gleichen Ziel- rechner existieren. In einem solchen Fall unterscheiden sich dann jedoch die einzelnen Portnummern des Client-Rechners. Beim Verbindungsaufbau lei- tet die Anwendungsschicht das Datenpaket mit der Internet-Adresse des Servers und dem Port 21 an die Transportschicht weiter. Da TCP stromorien- tiert sendet, verläuft die Übertragung der Bytes in der gleichen Reihenfolge vom Client zum Server und vermittelt der Anwendungsschicht das Bild ei- nes kontinuierlichen Datenstroms.
Auf den meisten Systemen sind die Ports über 1.024 für jede Anwendung of- fen, während die Ports 1 – 1.024 nur Systemprozessen (oder Anwendungen, die über entsprechende Privilegien verfügen) zur Verfügung stehen. Die fol- gende Tabelle zeigt die wichtigsten Ports.
Tabelle 3.5:
Einige wichtige Portnummern
Dienst Port Erklärung
ftp-data 20 File Transfer [Default Data]
ftp 21 File Transfer [Control]
telnet 23 Telnet
Smtp 25 Simple Mail Transfer
domain 53 Domain Name Server
finger 79 Finger
www-http 80 World Wide Web HTTP
pop3 110 Post Office Protocol – Version 3 uucp-path 117 UUCP Path Service
nntp 119 Network News Transfer Protocol
Ntp 123 Network Time Protocol
netbios-ns 137 NETBIOS Name Service netbios-dgm 138 NETBIOS Datagram Service
Socket
Socket ist ein im Zusammenhang mit TCP/IP häufig verwendeter Begriff, der die Kombination aus Internet-Adresse und Portnummer bezeichnet. In- nerhalb der Transportschicht werden bestimme Ports zur Adressierung ver- wendet. Sowohl UDP als auch TCP verwenden Port-Adressen, um Daten an das betreffende Programm (Protokoll) der Anwendungsschicht zu senden, wobei beide teilweise unterschiedliche Dienste für die gleiche Portnummer vermitteln.
Protokollnummern
Im Feld HEADER des IP-Datenpakets finden Sie die Nummer des nächst hö- heren Protokolls, an das die Daten weitergeleitet werden sollen. Diese Num- mern sind für alle Protokolle der Internet-Protokollfamilie definiert.
Die folgende Abbildung zeigt als Beispiel eine Datei PROTOCOL eines Win- dows 2000 Systems.
# <Protokollname> <Nummer> [Alias...] [#<Kommentar>]
ip 0 IP # Internet Protocol
icmp 1 ICMP # Internet Control Message Protocol ggp 3 GGP # Gateway-Gateway Protocol
tcp 6 TCP # Transmission Control Protocol egp 8 EGP # Exterior Gateway Protocol pup 12 PUP # PARC Universal Packet Protocol udp 17 UDP # User Datagram Protocol
hmp 20 HMP # Host Monitoring Protocol xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "Reliable Datagram" Protocol rvd 66 RVD # MIT Remote Virtual Disk Listing 3.1: Inhalt der Datei Protocol
Diese Datei ist eine normale ASCII-Textdatei und kann mit dem Editor ge- öffnet werden.
netbios-ssn 139 NETBIOS Session Service imap2 143 Interim Mail Access Protocol v2 Irc 194 Internet Relay Chat Protocol
Ipx 213 IPX
imap3 220 Interactive Mail Access Protocol v3
Uucp 540 uucpd
Dienst Port Erklärung
3.3 Höhere Netzwerkprotokolle
Die in den folgenden Abschnitten behandelten Protokolle arbeiten auf Ebene der Anwendungsschicht (Schicht Vier der Internet-Protokollfamilie).
Dabei werden hier die Protokolle näher behandelt, die im Zusammenhang mit dem Einsatz von Webdiensten eine besondere Rolle spielen.
Tabelle 3.6:
Übersicht über die behandelten höhe- ren Protokolle
Weitere Hinweise zum Schichtenmodell der Internet-Protokollfamilie finden Sie auch im Abschnitt Das ISO/OSI-Modell und die Internet-Protokolle Das ISO/OSI-Modell und die Internet-Protokolle ab Seite Das ISO/OSI-Modell und die Internet-Protokolle.
Die hier vorgestellten Protokolle der höheren Schichten arbeiten zeilenorien- tiert. Das Ende eines Kommandos wird also spätestens durch das Senden ei- nes Zeilenvorschubs angezeigt. Der normale Ablauf geht davon aus, dass der Server an dem entsprechenden Port auf Kommandos hört (er lauscht).
Trifft ein Kommando ein, interpretiert er es und sendet seinerseits eine ent- sprechende Reaktion. Manche Protokolle, wie beispielsweise FTP, interpre- tieren schon den erfolgreichen Verbindungsaufbau als Kommando – der Ser- ver reagiert dann sofort mit einer Begrüßung.
3.3.1 Hypertext Transfer Protocol (HTTP)
HTTP (Hypertext Transfer Protocol) dient der Kommunikation mit Webser- vern. Es gibt derzeit zwei Versionen, 1.0 und 1.1. Das modernere 1.1 steht al- lerdings nicht allen Servern zur Verfügung. Auf Seiten der Browser domi- niert inzwischen HTTP 1.1, denn alle Browser ab Version 4 beherrschen dieses Protokoll. Der Internet Information Server 5 (IIS 5) beherrscht die Ver- sion 1.1 vollständig. Der IIS 5 ist die Basis für den Einsatz der FrontPage 2002-Erweiterungen unter Windows 2000.
RFC 1945 HTTP 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, schon im Au- gust desselben Jahres folgte HTTP 1.1. Für das neuere Protokoll stand auch in 1999 noch kein eigenes RFC zur Verfügung, nur ein Draft. Trotz der lan- gen Zeit (für Internet-Verhältnisse) und den enormen Vorteilen von HTTP 1.x sind immer noch Server mit der Entwicklungsversion 0.9 im Einsatz.
Verbindungsloses Protokoll
Bei HTTP handelt es sich, wie bei Finger, Telnet und Echo auch, um ein ver- bindungs- oder statusloses Protokoll. Server und Client nehmen also nie ei- nen besonderen Zustand ein, sondern beenden nach jedem Kommando den
Protokoll Bezeichnung Seite
HTTP Hypertext Transfer Protocol 76
FTP File Transfer Protocol 81
SMTP Simple Mail Transfer Protocol 92
NNTP Network News Transfer Protocol 96
