3.1.1. Entstehung und Geschichte
In den Anfangsjahren der Computertechnologie waren Computer groß und keineswegs anwenderfreundlich. Verbindungen zwischen ihnen gab es wenige und wenn, dann meist nur in der Bildung oder bei Forschungsprojekten. Davon abgesehen waren Computerverbindungen auf die maximale Länge teurer Spezialkabel beschränkt.
Das U.S. Department of Defense (DOD) wollte eine Methode entwickeln, welche Computer vieler Bundesstaaten miteinander verbindet und eine sehr hohe Fehlersicherheit bietet. Desweiteren mußte das Netz noch funktionieren, wenn einige Teile des Netzes ausfallen sollten, z.B. bei militärischen Aktionen.
1957 wurde eine neue Technologie entwickelt, das "packet-switching". Dieses System spaltet den zu übertragenden Datenstrom in kleine Blöcke auf, markierte und verschickte sie. Die Pakete hatten dabei eine feste Länge und konnten auch von den einzelnen Computern weitergeleitet werden.
Aufgrund dieser Technologie entstand aus einem Forschungsprogramm der DARPA (U.S. Defense Advanced Research Projects Agency) das ARPANET. Dieses Forschungsprogramm konzentrierte sich auf die Methoden zur Verbindung unterschiedlicher Computernetzwerke.
Die University of California at Los Angeles (UCLA) bildete den ersten Knoten des entstehenden Netzes mittels eines Xerox Sigma 7 Computers. Wenig später wurde eine Honeywell 516 [ein Interface Message Prozessor (IMP)] mittels einer 400 Kbps Datenleitung angeschlossen, welche für die damalige Zeit eine Hochgeschwindigkeitsstrecke darstellte. Drei weitere Plätze wurden noch miteinander verbunden. Es entstand das erste Netzwerk mit vier Knoten. Das waren UCLA, die University of California at Santa Barbera (UCSB), das Stanford Research Institute und die University of Utah in Salt Lake City. Dieses kleine Netzwerk nutzte zur Verbindung untereinander 50 Kbps Modems von der Größe eines Kühlschrankes.
In der weiteren Entwicklung entstand 1969 das ARPANET, welches aus anfangs 40 Computern bestand. In dieser Zeit wurden auch die Requests for Comments (RFC) eingeführt. 1970 wurden die Protokolle Telnet, File Transfer Protocol (FTP) und die erste Version des Network Control Protocol (NCP) mit einer minimalen Client/Server-Funktionalität entwickelt. Telnet dient zum Anmelden und zum Ausführen von Kommandos auf einem entfernten Rechner. Zum Kopieren von Dateien zwischen zwei Rechnern diente und dient FTP. NCP stellte die grundlegenden Code zur Datenübertragung bereit.
3.1.1.2. Die weitere Entwicklung
Die weitere Forschung führte zur Entwicklung der TCP/IP-Protokolle, welche im Laufe der Zeit zum Standard avancierten.
1973 begann man damit, neue Medien zur internationalen Kommunikation einzusetzen. Es wurden Tiefseekabel verlegt und Kommunikationssatelliten im Orbit installiert. Man erkannte, daß das Internet Protokoll (IP) modifiziert werden muß. Im Ergebnis daran wurde das Transmission Control Protocol (TCP) aus dem Internet Protocol extrahiert.
Die Version 7 des AT&T UNIX-Betriebssystems enthielt eine neue Funktion, die UNIX-to-UNIX Copy (UUCP) genannte wurde. Studenten der Duke und der East Carolina University entworfen das Design eines selbstwählenden Modems und benutzten die UUCP-Software, um die UNIX-Systeme beider Schulen zu verbinden. Daraus entwickelte sich schließlich das NetNews Network, welches heute Usenet News heißt.
1980 wurde zum ersten Mal der Begriff Internet geprägt. Dieser Begriff bezeichnete damals die Gesamtheit des kommerziellen ARPANET’s und des militärischen MILNET’s. 1990 wurde das ARPANET geschlossen und das Internet übernahm seine Funktion.
1984 wurde ein neuer Mechanismus für Namensauflösung entwickelt. Der Domain Name Service (DNS). Nun war es für die Nutzer sehr einfach, aus den Namen die numerischen IP-Adressen herauszufinden und umgekehrt.
Ab diesem Zeitpunkt wuchs das Internet stetig an, d.h. die Anzahl der
an das Internet angeschlossenen Hosts nahm rapid zu (siehe Abb. 3-1). Allerdings
wuchs auch die Komplexität und Wartbarkeit des Netzes. Um dem entgegenzuwirken
entwickelte man das Simple Network Management Protocol
(SNMP). Damit wurde eine komfortable Fernwartung- und Administration
des Netzes über das Netz selbst möglich.
| Jahr |
|
|
|
|
|
| Hosts |
|
|
|
|
|
Ein weiterer "Meilenstein" in der Geschichte des Internets war der 1. November 1988. An diesem Tag legte der 1. Internetvirus 10% aller zu diesem Zeitpunkt angeschlossenen 60.000 Hosts lahm, indem er unsichtbare Tasks laufen ließ, welche dem Administrator das Herunterfahren des Systems unmöglich machte. Infolgedessen wurde das Computer Emergency Response Team (CERT) gegründet, dessen Aufgabe es war und ist, die Computergemeinschaft vor solchen Dingen zu warnen.
1989 bildete sich die Internet Engineering Task Force (IETF), eine große, offene und internationale Organisation. Ihre Aufgabe ist es, die Entwicklung neuer Funktionalitäten in den RFC’s zu manifestieren.
Als das Internet immer komplexer und unüberschaubarer wurde und die Suche nach der richtigen Information immer schwieriger, begann man Suchprogramme zu entwickeln. Hierzu zählen u.a.:
Im Januar 1993 entwickelte sich aus einem gemeinsamen Projekt von AT&T, General Atomics und Network Solutions, Inc. das International Network Information Center (InterNIC). Das InterNIC verwaltet den Zugriff auf das Internet und registriert die verschiedenen Domains.
Mosaic, ein anwenderfreundlicher grafischer Internet- und WWW-Browser entstand 1993 am National Center for Supercomputing Applikations (NCSA) in Illinois. Zum ersten Mal war es möglich, sich durch das Internet intuitiv zu bewegen, indem man einfach mit der Maus auf einen hervorgehobenen Textteil, einen Hyperlink, klickte. Grundlage dafür ist das Hypertext Transfer Protocol (HTTP). Um die weltweit verstreuten Seiten zu referencieren wurde der sogenante Uniform Resource Locator (URL) eingeführt. Durch die Entwicklung weiterer Technologien wie die Multiple Internet Mail Extension (MIME) und die Hypertext Markup Language (HTML) explodierte das Internet inklusive dem WWW und es begann die Kommerzialisierung des Internets mit all seinen Vor- und Nachteilen, auf die der Autor näher im Punkt 3.1.3. eingehen wird. Die weitere Entwicklung ist bei diesem Wachstumstempo noch nicht abzusehen.
Das Internet ist ein Netzwerk aus vielen weiteren Netzwerken, welche untereinander Informationen austauschen. Dies geschieht hauptsächlich mittels dem TCP/IP-Protokoll. Das Wort Internet kommt von dem Begriff Internetwork, was soviel bedeutet wie "zwischen den Netzwerken kommunizieren".
Sinnbildlich kann man das Internet als eine riesige Wolke betrachten (siehe Abb. 3-2), an die Hosts angeschlossen sind. Diese Wolke ist von der Form her nicht beständig und wächst permanent weiter, da neue Netzwerke und Hosts hinzukommen oder bereits bestehende verändert werden.
Die wirtschaftliche und ökonomische Bedeutung des Internets läßt sich kaum abschätzen. Durch die Verbindung lokaler Firmen-LANs ist es zum Beispiel möglich, auf Kundenwünsche schneller zu reagieren. In Firmen mit weltweit verteilten Niederlassungen und Forschungswerkstätten können die einzelnen Abteilungen untereinander schneller und komfortabler ihre Ergebnisse und Erkenntnisse austauschen. Ähnliches gilt für die Bildungseinrichtungen. Jeder Nutzer kann theoretisch innerhalb von Sekundenbruchteilen mit jedem anderen Nutzer kommunizieren. Deshalb ist es möglich, die Ideen anderer zu nutzen und eigene Ideen darauf aufzubauen; natürlich innerhalb der gesetzlichen Grenzen.
Die Datenbestände der unzähligen weltweit verteilten Server mit ihren Informationen sind sofort abrufbar. Der Autor vertritt die Meinung, daß das gesamte Wissen der Menschheit in Internet in Form von Daten enthalten ist. Man braucht es nur abzurufen.
Durch die Kommerzialisierung des Internets in der letzten Zeit kommen immer mehr Nutzer in den Genuß grenzenloser Kommunikation. Die Datenleitungen wachsen jedoch nicht im selben Umfang wie neue Nutzer hinzukommen. Die Folge davon sind überlastete Leitungen. Darüber hinaus belegen die privaten Nutzer einen Großteil der Netzperformance durch einen Datenaustausch, der kaum etwas mit Wissenserweiterung und Erfahrungsaustausch sowie Völkerverständigung zu tun hat. Viele Firmen haben das Internet als Werbe- und Konsumträger entdeckt, verschicken ihre Werbung weltweit und bieten ihre Waren an.
Seit ca. 2 Jahren wird das Netz von manchen Nutzern auch zum Telefonieren benutzt. Dabei nehmen die Anwender keine Rücksicht darauf, daß diese vielen Megabytes ernsthafte Anwendungen blockieren. Der Autor vertritt die Ansicht, daß das Internet abermals gespalten werden müßte. In einen kommerziellen Teil, welcher sich selbst finanziell trägt und einem nicht öffentlichen Teil für Forschung, Bildung und Technik, welcher vom Staat finanziert wird. Damit wäre zumindest die ursprüngliche Aufgabe wiederhergestellt.
Die Tatsache, daß sich viele Anwender im Netz profilieren möchten, ist ein zusätzliches Problem. Sie stellen Daten zur Verfügung, die an anderer Stelle schon zu finden sind. Aus diesem Grund ist es ziemlich schwer aus dem riesigen Informationsangebot die Information zu finden, die man sucht. Bis man sie gefunden hat, verschwendet man viel Zeit und viele Netzressourcen. Die nicht benötigten Informationen werden bei der Suche zwangsläufig mitübertragen.
Ein sehr wichtiger Gesichtspunkt bei dieser Betrachtung ist der Aspekt der Datensicherheit. Als es nur wenig "Eingeweihte" gab, die wußten, was man mit dem Internet alles anstellen konnte, war die Gefahr, daß persönliche und vertrauliche Daten in falsche Hände gelangen, nicht so groß. Die Meisten nutzten das Netz zu dem Zweck zu dem es entstand. Es gab nur wenige, die das Internet für kriminelle Zwecke mißbrauchten. Diese Zahl ist rapide gestiegen. Jeder halbwegs begabte Hacker kann heutzutage an vertrauliche Informationen gelangen. Desweiteren kommunizieren terroristische Gruppen ungehindert miteinander. Firmen sammeln bei Anwahl ihrer Webseite alle Informationen über den potentiellen Kunden, ohne die Bestimmungen des Datenschutzgesetzes zu beachten und um diese möglichst gewinnbringend zu vermarkten. Diese Aufzählung läßt sich ohne weiteres um viele Punkte erweitern. Dies verdeutlicht, daß im Netz der Netze viele Gefahren bestehen, die sich ein unbedarfter Anwender kaum vorstellen kann.
Firmen schützen sich vor diesen Gefahren mit Hilfe einer Firewall. Diese Technik soll in Theorie und Praxis Gegenstand dieser Diplomarbeit sein. Den meisten privaten Anwendern ist diese Technik jedoch verwehrt, da fast niemand eine permanente Leitung ins Internet besitzt. Eventuell frei verfügbare Firewalls, wie zum Beispiel WinHack, bieten sicherlich nicht den Schutz eines kommerziellen Produktes. Für einen Privatanwender mag diese Sicherheit aber ausreichend sein. Dazu kommen noch die Kosten einer Firewall hinzu. Die einzelnen Provider sind angesichts der riesigen Nutzeranzahl nicht in der Lage, Sicherheit auf dem Niveau zu bieten, das angemessen erscheint. Sie schützen, wenn überhaupt, nur vor den allgemein bekannten Gefahren.
Um im Internet bei den Millionen von Computern genau mit dem richtigen kommunizieren zu können, muß man denjenigen genau kennen. D.h., man muß seinen Namen kennen.
Diese Namen werden nach der DNS-Konvention gebildet, welche in den RFC 1032, 1033, 1034 und 1035 definiert ist. Das DNS ist hierarchisch aufgebaut und hat das folgende Format:
[Subdomain].[Subdomain].[...].Domain
Der Teil des Namens, welcher sich ganz rechts befindet, ist die Top-Level-Domain
und spezialisiert die allgemeinste Kategorie. Danach folgt nach links eine
mehrstufige Aufteilung, welche anfangs nur nach organisatorischen Gesichtspunkten
vorgenommen wurde (siehe Tabelle 3-1). Später wurde mit der Internationalisierung
des Internets weitere Top-Level-Domains nach geographischen Gesichtspunkten
eingeführt. Dabei wird jedes Land durch eine Abkürzung aus zwei
Buchstaben dargestellt. Eine kleine Auswahl zeigt Tabelle 3-2. In dem hierarchischen
Aufbau sind bis zu 127 Ebenen zulässig.
| Domain | Beschreibung |
| com | "commercial", kommerzielle und industrielle Organisationen |
| edu | "educational", Universitäten und Lehreinrichtungen |
| gov | "government", Nichtmilitärische Regierungsorganisationen |
| mil | "military", Militär |
| net | "network", Organisationen zum Netzwerkbetrieb |
| org | "organizations", Andere Organisationen |
| us | "united states", US-ISO-Domains |
| Domain | Land |
| de | Deutschland |
| au | Australien |
| uk | Großbritannien |
| jp | Japan |
| tw | Taiwan |
| fi | Finnland |
| ch | Schweiz |
| tt | Trinidad und Tobago |
Jede Organisation wird in eine Top-Level-Domain eingeordnet und bildet eine Subdomain. Innerhalb dieser Subdomain können durch die Organisation weitere Subdomains festgelegt werden. Damit werden die Subdomains von rechts nach links immer spezifischer. Sie geben in der Regel eine Abteilung, ein Teilnetz oder einen Computer innerhalb einer Organisation an.
Ein voller Pfad, beginnend von Hostnamen bis zur Top-Level-Domain, heißt Fully Qualified Domain Name (FQDN). Ein Beispiel hierfür wäre:
alpha.mpi.htwm.de
Der Host alpha gehört zur Subdomain mpi (Bereich Mathematik/Physik/Informatik) der Hochschule für Technik und Wirtschaft Mittweida (htwm) in Deutschland (de). Innerhalb einer Domain kann man auch relative Hostnamen ohne Domänenangabe benutzen.
Das Symbol @ (Klammeraffe, gesprochen: "ät") gibt einen Benutzer, einen Alias oder eine Mailbox im DNS-Namen an. Somit ist es möglich, einen Nutzer an genau einem bestimmten Rechner zu erreichen, oder in einer bestimmten Domain:
3.2.1. Aufbau und Unterteilung
Jeder Host im Internet braucht eine weltweit eindeutige Adresse, mit der er im Netz identifiziert werden kann. Diese Adresse besteht aus 4 Bytes (oder auch 32 Bits) und wird auch IP-Adresse genannt (siehe auch Punkt 3.3.). Diese 4 Bytes werden zwecks der besseren Lesbarkeit mit Punkten getrennt in Dezimalschreibweise angegeben, z.B.:
199.20.123.11
Intern wird eine IP-Adresse nochmals aufgeteilt. In einen Netzwerkanteil, welcher je nach Netzwerkklasse (siehe Punkt 3.2.2.) 1 bis 3 Byte umfaßt, und einen Hostanteil. Dabei wird in der obigen Schreibweise von links beginnend ein, zwei oder drei Zahlen zum Netzwerkanteil gerechnet, der Rest gehört zum Hostanteil. Der Netzwerkanteil wird weltweit vom NIC (Network Information Center) vergeben, der Hostanteil kann in der Organisation selbst festgelegt werden.
Class-A-Netz:
Die restlichen möglichen Adressen werden noch in Class-D-Adressen und Class-E-Adressen unterteilt.
Class-D-Adressen:
| Adresse | Bedeutung |
| 130.20.1.4 | Host in einem Class-B-Netz |
| 127.0.0.1 | Loopbackadresse |
| 200.11.13.0 | Class-C-Netz - das Netzwerk selbst |
| 20.123.54.255 | Broadcastadresse in einem Class-A-Netzwerk |
| 244.2.3.4 | reservierte Class-E-Adresse |
| 225.5.33.116 | Multicastadresse |
Die IP-Adressen adressieren nicht direkt den Host an sich, sondern das Netzwerkinterface. Da ein Host mehrere Interfaces besitzen kann, können ihm demzufolge auch mehrere IP-Adressen zugewiesen werden. Ein Router (Routing siehe 3.3.3.) hat nicht nur eine IP-Adresse.
Weitere Information über Netzklassen und ihren Adressraum können dem RFC 1466 entnommen werden.
Die oben genannte Notation der Adressen ist für den Nutzer leicht zu verstehen. Allerdings lassen sich solche Adressen in Form von Zahlen schlecht merken. Deshalb erhält gewöhnlich jeder Host einen in seinem Netz eindeutigen Namen (siehe auch 3.1.4.). Dieser kann völlig frei gewählt werden. Er sollte allerdings aus sinnvollen Wörtern oder Buchstaben-Zahlen-Kombinationen bestehen, da sonst "der Zweck des leichter Merkens" nicht mehr erfüllt wäre. So sollten alle Hostnamen eines Netzes irgendwie verwandt sein, z.B. Tiernamen, Sternzeichen, Griechisches Alphabet u.ä. Auch Kombinationen von Raumnummern, Rechnernummern und Abteilungsnamen bilden sinnvolle Hostnamen, wie z.B. verw200_2 - Verwaltung Zimmer 200 Rechner 2.
Die Zuordnung der Hostnamen zu den IP-Adressen erfolgt normalerweise
in der Datei hosts. Die Position (und leider auch der Name) dieser
Datei kann von Betriebssystem zu Betriebssystem schwanken. Der syntaktische
Aufbau ist in der Regel aber gleich. Eine kurze Auflistung von möglichen
Namen und Positionen zeigt Tabelle 3.4.
| Betriebssystem | Position und Dateiname | Bemerkung |
| Unix | /etc/hosts | |
| Windows NT | %Systemroot%\System32\Drivers\Etc\hosts | |
| Windows NT | %Systemroot%\System32\Drivers\Etc\lmhosts | Namen für LAN-Manager |
Diese Datei ist eine normale ASCII-Datei und kann mit jedem Editor bearbeitet werden. In jeder Zeile steht eine IP-Adresse gefolgt vom offiziellen Hostnamen. Danach können beliebig viele Aliasnamen stehen. Sie dienen zur Vereinfachung, zur Abkürzung oder für verschiedene Schreibweisen des offiziellen Hostnamens. Als Trennzeichen dienen Leerzeichen oder Tabulatoren. Kommentare beginnen mit einem Doppelkreuz "#". Leerzeilen sind zulässig. Z.B.:
# Zuweisung der IP-Adressen zu den Hostnamen
127.0.0.1 localhost
211.1.1.1 server.organisation.de server
211.1.1.2 alpha.organisation.de alpha # beta.organisation.de
beta
Um weltweit Hostnamen auf IP-Adressen abzubilden und umgekehrt, kann natürlich nicht auf dieses Verfahren zurückgegriffen werden. So müßten auf jedem Host in der hosts-Datei alle weltweiten Hosts eingetragen sein und sie müßte ständig aktualisiert werden. In den Anfängen des Internet, als es noch wenige Rechner gab, wurden in einer einzigen Datei am NIC alle Hosts geführt. Dieses Vorgehen ist heute nicht mehr akzeptabel. Zu diesem Zweck wurde der Domain-Name-Service (siehe auch 3.1.4.) eingeführt. Hierbei besitzt der (oder die) Name-Server eines Unternehmens alle IP-Adressen des lokalen Netzwerkes mit den zugeordneten Host- und Domainnamen. Desweiteren sind diesem Name-Server weitere Name-Server im Internet bekannt. Schickt nun ein Client eine Adressanfrage an den lokalen Name-Server, kann er sie beantworten, falls in seiner Tabelle die Antwort (IP-Adresse) enthalten ist. Ansonsten leitet er die Anfrage an einen anderen bekannten Name-Server weiter. Nach einer gewissen Zeit ist die Anfrage bei einem Name-Server angelangt, der die gesuchte IP-Adresse kennt. Diese wird zurückgeschickt. Selbstverständlich kreist bei Mißerfolg eine solche Anfrage nicht ewig im Netz, sondern wird nach einem Timeout gelöscht. Auch der umgekehrte Weg ist möglich. Fragt ein Client nach dem Hostnamen zu einer bestimmten IP-Adresse, wird nach dem selben Schema vorgegangen, allerdings wird dabei die reverse Tabelle befragt.
Die hosts-Datei ist dadurch allerdings nicht überflüssig geworden, da nach einem Systemstart noch kein Netzwerk angebunden ist. Bei Vorhandensein eines Name-Servers im lokalen Netz sollten deshalb in der hosts-Datei jedes Clients zumindest einige wichtige Hosts und ein Name-Server eingetragen sein. Dies ist auch bei einem Netzausfall wichtig, um einen Stand-Alone-Betrieb zu gewährleisten.
Nach erfolgreicher Konfiguration des Name-Servers oder nach editieren einer korrekten hosts-Datei kann nun immer statt der IP-Adresse der Name oder ein Alias des Hosts angegeben werden; z.B.:
ping beta statt ping 211.1.1.3 oder ping beta.organisation.de
Ob nun der eigene Name-Server Anfragen ins Internet weiterleitet, sollte man einen externen Host mit seinem Namen anpingen, wie z.B.:
ping ftp.cdrom.com oder ping ftp.funet.fi
3.2.4. Ausblick auf neue Konvention
Schon seit geraumer Zeit ist abzusehen, daß die IP-Adressen nicht mehr lange reichen. Hochrechnungen der Address Lifetime Expectation (ALE)- Arbeitsgruppe, die von der Internet Engineering Task Force (IETF) gebildet wurde, gehen davon aus, daß im Jahre 2005 alle verfügbaren Adressen aufgebraucht sind, und daß obwohl theoretisch über 4 Milliarden möglich sind. Ein Großteil davon ist jedoch für Experimentierzwecke bestimmt und durch die Aufteilung in die Netzklassen bekommen viele Firmen einen zu großen Adreßraum zugewiesen. So wird einer Firma, die ca. 400 Adressen nutzen will, eine Class-B-Adresse zugewiesen, weil eine Class-C-Adresse nicht ausreichen würde. Aus dem zugewiesenen Adressraum nutzt sie jedoch nicht mal ein Prozent! Aus diesen und noch weiteren Gründen sind von den 4 Milliarden nur noch ca. 200 Millionen nutzbar. Die IETF forderte daraufhin 1993 die Internetgemeinde auf, Vorschläge für ein neues Protokoll einzureichen.
Die IP next generation (IPng)-Arbeitsgruppe entschied sich für eine Variante mit 128 Bit (bisher 32 Bit) großen Adressen. Das entspricht ungefähr 3.4*1038 Adressen. Obwohl sicher wieder viele für andere Zwecke genutzt werden sollen, dürften die verbleibenen Adressen für die nächste Zeit ausreichen. Eine neue Adresse wird mit 8 durch einen Doppelpunkt getrennte vierstellige Dezimalzahlen geschrieben. Zur Vereinfachung ist es zulässig, führende Nullen wegzulassen oder bei komplett aus Nullen bestehende Adreßteile nur den Doppelpunkt zu schreiben. So kann zum Beispiel 0:2034:0:0:0:12:89ab:c50 auch als 2034::::12:89ab:c50 geschrieben werden. Alte IP-Adressen der zur Zeit aktuellen Version 4 können durch 6 vierstellige Hexadezimalzahlen gefolgt von 4 Dezimalzahlen dargestellt werden (zum Beispiel ::199.12.3.45). Die Kompatibilität zur alten Version ist somit gewahrt.
Die wichtigsten Neuerungen von IPv6 in einem Überblick:
Da das TCP/IP-Protokoll in Form eines Protokollstacks aufgebaut ist, kann das OSI-Schichtenmodell darauf angewendet werden (siehe Abb. 3-4). TCP/IP setzt auf die Netzwerkzugriffsschicht auf, welche keine physischen Netzwerkstandards enthält. Sie beschreibt, wie vorhandene Netzwerke mit TCP/IP genutzt werden können. Die Internetschicht ist für die Adressierung zuständig und vergleichbar mit der Netzschicht des OSI-Modells. Aufgabe der Transportschicht ist die Bereitstellung von Diensten für den Transport von Nutzerdaten und entspricht Schicht 4 des OSI-Modells. Alle Applikationen und Prozesse die auf die Netzdienste wie z.B. telnet, ftp und NFS zugreifen, sind in der Applikationsschicht zusammengefaßt. Diese wird im Gegensatz zum OSI-Modell nicht weiter unterteilt.
Abb. 3-4: TCP/IP-Schichtenmodell gegenüber OSI-Modell
3.3.1.1. Netzwerkzugriffsschicht
Die Aufgabe der Netzwerkschicht ist die von der Internetschicht übergebenen
Datagramme an die Netzwerkinterfaces weiterzuleiten. Mit Hilfe des Address
Resolution Protokolls (ARP) wird eine Adressumsetzung
der von der Internetschicht verwendeten IP-Adressierung in die Adressierungsart
des jeweiligen Netzwerkes durchgeführt. Bei Ethernet wird demzufolge
eine IP-Adresse in eine MAC-Adresse (Media Access
Control) umgewandelt. In das Protokoll des jeweiligen Netzwerkes
werden die Datagramme als Nutzdaten eingebettet. Die äußeren
Protokolldaten werden als Rahmen oder Frame bezeichnet (siehe Abb. 3-5).
|
|
|
|
|
|
|
Die empfangenen Daten müssen aus dem Frame extrahiert und an die nächsthöhere Schicht, die Internetschicht, übergeben werden. Aus diesem Grund muß die Netzwerkzugriffsschicht die Details des darunterliegenden Netzwerkes (Paketaufbau, Adressierung) kennen. Das darunter liegende physische Netzwerk kann demzufolge ein Ethernet-, ein Token-Ring-Netz oder auch eine serielle Schnittstelle sein. Das heißt, die Netzwerkzugriffsschicht ist hardwareabhängig und wird durch die Netzwerkinterfacetreiber realisiert, während die höheren Schichten hardwareunabhängig sind.
Zum Aufgabenbereich der Internetschicht gehören folgende Punkte:
|
|
|
Ein IP-Datagramm setzt sich aus einem mindestens fünf mal 32-Bit
langem Header und den zu übertragenden Daten zusammen. Die Felder
des IP-Headers (nach RFC 826) sollen nun etwas genauer betrachtet werden:
| Feld | Bedeutung |
| Version | IP-Versionsnummer (4 Bits), aktuell ist 4 |
| IHL | Länge des Headers in 32-Bit-Worten, mindestens 5 |
| Service-Typ | Angaben zur geforderten Qualität und Zuverlässigkeit |
| Gesamtlänge | IP-Header und Daten |
| Identifikation | wird bei Fragmentierung genutzt und identifiziert das Datagramm |
| Flags | zur Fragmentierungssteuerung |
| Fragmentoffset | Offset des Fragments im Datagramm |
| Lebenszeit | (auch TTL); Zeit in Sekunden, die das Datagramm noch existieren darf. Wenn das Datagramm in einem Router nicht weitervermittelt werden kann, wird TTL nach jeder Sekunde dekrementiert. Ansonsten wird TTL bei jedem Durchlauf durch einen Router dekrementiert. Wenn TTL gleich Null ist, wird das Datagramm nicht weitervermittelt. Damit können fehlerhafte Datagramme nicht ewig im Netz kreisen. Nach jedem Dekrementieren wird die Prüfsumme neu berechnet. |
| Protokoll | Protokoll der Transportschicht, an welches das Datagramm beim Empfänger vermittelt wird, z.B. TCP oder UDP. Eine vollständige Auflistung der möglichen Einträge findet man in RFC 1340 |
| Optionen | Optionsfeld mit variabler Länge, wird mit Füllzeichen auf 32-Bit-Grenzen aufgefüllt |
Wenn der Zielhost nicht im selben Netzwerk wie der sendende Host ist, übergibt die Internetschicht der Netzwerkzugriffsschicht die Adresse des entsprechenden Routers als Ziel. Im IP-Header steht natürlich weiterhin die entfernte Zieladresse.
Wenn die Netzwerkinterfaces von Routern unterschiedliche Datenpaketgrößen zulassen, kann es erforderlich werden, die ankommenden Datagramme zur Weiterleitung aufzuteilen, zu fragmentieren. Aus diesen Fragmenten muß der Zielhost wieder die ursprünglichen Datagramme zusammensetzen. Mit Hilfe der im IP-Header vorhandenen Felder wird die Fragmentierung und Defragmentierung transparent für die darüberliegenden Schichten von der Internetschicht durchgeführt.
Eine genaue Beschreibung des Internet Protokolls findet man in den RFC 791.
Um zwischen den Hosts im Internet Steuer- und Fehlermeldungen auszutauschen, wird das Internet Control Message Protokoll (ICMP) verwendet, welches integraler Bestandteil der Internetschicht ist. ICMP nutzt wie die Protokolle TCP und UDP das IP. Demzufolge wird im IP-Header das Protokollfeld auf den Wert 1 (=ICMP) gesetzt.
Wichtige Aufgaben des ICMP sind u.a.:
Die Internetschicht ist für die Adressierung der Hosts verantwortlich. Eine Netzwerkanwendung kommuniziert aber nicht mit einem Host an sich, sondern mit einer Anwendung, die auf dem entfernten Host läuft. Es muß also eine Möglichkeit geben, direkt an die Anwendung Daten zu übergeben. Dazu dient die Portnummer, welche bei der TCP/IP-Protokollfamilie eine vorzeichenlose ganze 16-bittige Zahl ist. Ein Host kann über mehrere Ports zugleich kommunizieren, das heißt, er nutzt mehrere Kommunikationskanäle und ist damit multiplexfähig. Somit kann man durch Angabe von
Die Portnummern für die Server bekannter Internetdienste liegen fest, während die Portnummern für die Clients dynamisch vergeben werden. Die Portnummern von 0 bis 1023 sind fest vergeben und dürfen nur von Prozessen benutzt werden, die Rootrechte benötigen. Die Internet Assigned Numbers Authority (IANA) ist für die Vergabe dieser Nummern zuständig (RFC 1340). Die Nummern im Bereich von 1024 bis 65535 können von beliebigen Prozessen verwendet werden. Allerdings werden solche Portnummern von der IANA registriert und veröffentlicht, um Mehrfachvergaben und die damit verbundenen Konflikte zu vermeiden.
Für den Transport von Nutzdaten über das Netz stellt die Transportschicht zwei Protokolle bereit:
|
|
|
|
|
|
In die Prüfsumme gehen die Felder mit den Ziel- und Quelladressen aus dem IP-Header, das Längenfeld des UDP-Headers und die Daten ein. Die Prüfsumme wird folgendermaßen gebildet:
TCP bietet im Gegensatz zu UDP eine sichere und verbindungsorientierte Datenübertragung an. Die Verbindung wird auf TCP-Ebene als Datenstrom realisiert, während UDP Datagramme überträgt. Man kann also auf TCP-Verbindungen ähnlich zugreifen, wie auf Dateien. Allerdings wird dieser Bytestrom in Segmente aufgeteilt und an die darunterliegende IP-Schicht übergeben. Vor einer Kommunikation mit einem anderen Host muß erst einmal eine Verbindung aufgebaut werden. Dazu erfolgt ein Austausch von bestimmten Signalen, welche den Zustand des betreffenden Hosts entsprechend beeinflußt. Bei Kommunikationsende ist eine TCP-Verbindung auch wieder mit Hilfe solcher Signale zu schließen.
Die Datenverbindung auf TCP-Ebene wird durch einen Mechanismus gesichert, der "Positive Acknowledgement" heißt. Jedes korrekt empfangene Segment muß der empfangende Host bestätigen. Sollte nach einer gewissen Zeit die Bestätigung beim Sender nicht eingetroffen sein, nimmt dieser an, daß das Segment verloren gegangen ist und schickt es ein weiteres mal. Natürlich kann auch die Bestätigung verloren gehen. Deshalb muß der Empfänger auch mit mehrmals eingetroffenen Segmenten etwas anfangen können. Die Lösung für dieses Problem sind die sogenannten Folgenummern. Damit wird jedes Segment durchnummeriert. Es ist somit ohne weiteres möglich, bestimmte Segmente nochmals zu senden, Mehrfachsendungen zu erkennen und die Segmente in der richtigen Reihenfolge wieder zusammenzusetzen. Zusätzlich wird innerhalb jedes Segments eine Prüfsumme gebildet, welche die Korrektheit des Segments gewährleistet. Diese Prüfsumme wird wie bei UDP errechnet. Desweiteren wird bei TCP-Verbindungen noch eine Flußkontrolle realisiert, welche in jedem Acknowledgement-Paket dem Sender eine bestimmte Fenstergröße übermittelt. Diese Fenstergröße gibt an, wie viele Bytes der Empfänger noch aufnehmen kann. Der Sender übermittelt dann eine entsprechende Anzahl von Segmenten ohne Unterbrechung.
Den Aufbau eines TCP-Headers zeigt die Abbildung 3-9. Direkt nach dem Header folgen die Nutzdaten, welche von der oberen Applikationsschicht übermittelt wurden.
| Feld | Bedeutung |
| Quellport | Portnummer auf sendendem Host |
| Zielport | Portnummer auf entferntem Host |
| Folgenummer | gibt Reihenfolge der Segmente an |
| Acknowledgement-Nummer | Sequenznummer des Segments, das der Sender des Acknowledgements als nächstes erwartet |
| Offset | Größe des TCP-Headers in 32-Bit-Wörtern; entspricht Offset zu Nutzdaten (4 Bits) |
| Flags | 6 Bits für Steuerflags, Bedeutung von links
nach rechts
|
| Fenster | gibt an, wie viele Bytes der Empfänger ohne Unterbrechung noch aufnehmen kann |
| Prüfsumme | wie bei UDP |
| Dringlichkeitszeiger | Offset zur Sequenznummer, zeigt auf das letzte Byte dringlicher Daten, die außerhalb der Reihenfolge des normalen Bytestroms an den Empfänger geliefert werden müssen. Diese "Out-of-band"-Daten gestatten es, neben der normalen TCP-Verbindung eine Art zweiten, gleichzeitig existierenden, dringlichen Datenkanal zu nutzen. |
| Optionen | Feld mit variabler Länge für Optionen, wird mit Füllbytes auf 32 Bit aufgefüllt |
In der Abbildung 3-10 sehen wir noch den Aufbau eines TCP/IP-Paketes
innerhalb eines ETHERNET-Netzwerkes.
|
|
|
|
|
|
Der Applikationsschicht werden die Anwendungen, Prozesse und Dienste zugeordnet, die die Transportprotokolle TCP und UDP nutzen. Dazu gehören zum Beispiel Telnet, FTP und E-Mail. Allerdings benutzen diese Dienste eigene Protokolle wie das Network Terminal Protokoll (NTP), FTP und das Simple Mail Transport Protokoll (SMTP). Diese Protokolle greifen für den Datentransport auf TCP zurück. Das NFS, DNS und RIP nutzen im Gegensatz dazu UDP.
Der Anwendungsprogrammierer nutzt als Programmierschnittstelle zu den Transportprotokollen die Sockets, welche integrale Bestandteile der BSD-Linie von UNIX sind und zur Standardnetzwerkausrüstung aller UNIX-Systeme gehören. Für den Zugriff auf TCP/IP-Netze unter Microsoft Windows gibt es auch eine Socket-Bibliothek.
Das Transport Layer Interface (TLI) bietet seit SystemV R3 eine alternative Schnittstelle zur Transportschicht von TCP/IP. Das TLI kann auch für andere Protokolle als für TCP/IP genutzt werden, da diese Schnittstelle unabhängig vom darunterliegenden Transportversorger ist.
Ein Unternehmen bekommt in der Regel nur eine Netzadresse aus einer der drei Netzklassen vom NIC zugewiesen. Das bedeutet, daß das Unternehmen bei einer Class-B-Adresse nun ein Netz mit 64000 Hosts aufbauen kann. Dies ist in den wenigsten Fällen sinnvoll. Das Unternehmensnetz soll und wird meistens in mehrere Subnetze aufgespalten. Die Gründe hierfür sind vielfältiger Natur. Hier nur einige Beispiele:
Abb. 3-11: Beispielsweise Aufteilung in Netz-, Subnetz- und Hostanteil eines Class-B-Netzes
Es ist nun als erstes festzustellen, wieviele Bits des zur Verfügung
stehenden Teils der IP-Adresse (Hostanteil der Netzklasse) für die
Subnetz- und die Hostnummern des Subnetzes verwendet werden sollen. Bei
einem Class-C-Netz könnten zum Beispiel 3 Bits Subnetzanteil und 5
Bits Hostanteil genutzt werden. Das entspräche 6 Subnetzen, da 000
und 111 wiederum für die Netzadresse und der Broadcastadresse entfallen,
und 30 Hosts. In einem Class-B-Netz bietet sich an, jeweils 8 Bits für
beide Anteile zu nutzen. Dabei wären 254 Subnetze mit jeweils 254
Hosts möglich. Die Tabelle zeigt eine Auflistung der möglichen
Kombinationen bei einem Class-C-Netz.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Somit liegt die sogenannte Netzmaske fest. In der Internetschicht wird anhand der Netzmaske, der IP-Adresse und der Netzadresse entschieden, ob der Zielhost im eigenen Netzsegment (Subnetz) liegt. Dazu wird die IP-Adresse mit der Netzmaske bitweise UND verknüpft und das Ergebnis mit der eigenen Subnetzadresse verglichen. Siehe auch folgende 2 Beispiele:
Beispiel 1:
Beispiel 2:
Wie schon in 3.2.2. besprochen sind die Felder, die nur aus binären Einsen bestehen, Broadcastadressen. Bei einer Unterteilung in Subnetze ist es somit möglich, Broadcasts an das komplette Netz (z.B.: 145.100.255.255) oder auch nur an das Subnetz (z.B.: 145.100.127.255) zu senden. Die Angaben beziehen sich hierbei auf oben genanntes Beispiel 2. Allerdings adressiert 255.255.255.255 nicht alle Hosts weltweit, sondern nur alle Hosts im lokalen Subnetz. Workstations, die über das Netz booten, nutzen diese Funktion, um Broadcasts zu senden, solange sie noch nicht ihre eigene Netzadresse kennen.
Ein Besonderheit stellen Adressen aus einem der drei folgenden Blöcke dar.
Analog der Hostnamenszuweisung zu den IP-Adressen (siehe 3.2.3.) ist es auch möglich, Netzwerknamen zu vergeben. Normalerweise wird hierfür die Datei networks verwendet. Die Position und der Name dieser Datei ist ähnlich wie bei der hosts-Datei nicht bei jedem Betriebssystem gleich. Das Format dieser ASCII-Datei besteht aus der Netzadresse, gefolgt vom Netznamen und weiteren Aliasnamen. Ansonsten gelten die selben Fakten, wie schon bei der hosts-Datei besprochen. Natürlich können die Netznamen auch über den Name-Service verwaltet werden.
Im Punkt 3.3.2. wurde aufgezeigt, wie festgestellt wird, ob der Zielhost bzw. die Zieladresse in einem anderen Netzsegment liegt wie der Absender. Wie kommen nun die IP-Pakete in ein anderes Netzwerk? Das Verbindungsglied zwischen zwei (oder mehreren) Netzen ist der Router. Das kann ein externes Gerät sein oder ein Host bzw. Server mit Routingfunktionalität.
Je nach Topologie schickt entweder der Host selbst das Paket an den Router oder ein Hub übernimmt diese Aufgabe. Die zugrunde liegende Wirkungsweise ist allerdings immer die selbe. Es wird in der Routingtabelle, welche im Host, im Switch oder im Router geführt wird, nachgesehen, über welchen Anschluß das Zielnetz erreichbar ist. Dabei spielt es keine Rolle, ob die Routingtabelle
In jeder Routingtabelle gibt es zwei Standardeinträge. Der eine enthält die Loopback-Route für den lokalen Rechner. Diese wird vom lokalen System benutzt, um Datagramme an das eigene System zu schicken. Der zweite Eintrag enthält die default-Route, welche das Standardgateway spezifiziert. Sie wird immer dann benutzt, wenn für eine Zieladresse kein passender Routingeintrag existiert.
Wichtig ist noch, daß eine Route immer auf das nächste Gateway auf dem Weg zum Zielnetz zeigt. Ein Datagramm muß irgendwann an ein Gateway kommen, das den direkten Weg zum Zielhost kennt. Damit bei unerreichbaren Netzen das Paket nicht ewig im Netz kreist, existiert im IP-Header ein Feld, das die Lebenszeit des Datagramms angibt. Der Wert wird entweder bei jedem Durchlauf durch einen Router dekrementiert oder jede Sekunde, wenn das Paket nicht weitervermittelt werden kann. Enthält das Feld den Wert 0, wird das Paket verworfen. Näheres dazu siehe auch Punkt 3.3.1.2. Ausführliche Beschreibungen und zusätzliche Informationen können noch den
Multicasting ist eine Adressierungstechnik, die es einer Quelle ermöglich, Kopien bzw. Mehrere Exemplare von Datenpaketen an mehrere Empfänger zu schicken. Dazu kann sich ein Host dynamisch über einen Registrierungsprozeß an einer Multicastgruppe anmelden. Man nutzt dazu Class-D-Adressen (auch Multicastadressen genannt), welche die Nutzung von bis zu 268 Multicastsitzungen weltweit zur gleichen Zeit ermöglicht. Die Nutzung dieser Adressen wurde limitiert, um die Bandbreite zu begrenzen. Wenn zum Beispiel ein Anbieter eine Videopräsentation über das Internet in ein Netzwerk mit 5 Nutzern senden will, müssen bei der herkömmlichen Methode 5 separate Verbindungen mit konkreten Empfangsadressen erstellt werden. Dazu müssen die Verbindungen auch performant genug sein, um die Videodaten in ansprechender (ruckelfreier) Form übertragen zu können. Über jede dieser Verbindungen müßten nun die gleichen Videodaten übertragen werden. Bei der Nutzung einer Multicastadresse muß nur eine Verbindung in das Netzwerk gerouted werden, die auch nur einmal die Videodaten überträgt. Jedes Mitglied der Multicastgruppe erhält die gleichen Daten. Ohne großen Aufwand können auch weitere Nutzer in die Gruppe mit aufgenommen werden.
Zur Übertragung der Daten werden spezielle Protokolle genutzt, wie zum Beispiel:
Level 0:
Abb. 3-12: Format einer IGMP-Message
Dabei bedeuten die einzelnen Felder:
| Feld | Bedeutung |
| Version | IGMP-Version (aktuell ist Version 1) |
| Typ | 1 - Host Query
2 - Host Report |
| unbenutzt | 0 - wenn gesendet wird; sonst ignoriert |
| Checksumme | Prüfsumme; wenn 0, soll sie gebildet werden |
| Gruppenadresse | bei Typ 1:
|
Multicast Router senden eine Host Query Nachricht, um herauszufinden, welche Hostgruppen im lokalen Netz Mitglieder haben. Diese Anfrage wird an die Adresse 224.0.0.1 gesendet und erhält eine IP-Lebenszeit von 1. Die Hosts antworten mit einer Host Report Nachricht und teilen dem Netzinterface, von dem die Query kam, mit, zu welcher Gruppe sie gehören. Nach gewissen Zeitabständen wiederholen die Multicast Router die Anfrage, um neue Mitglieder zu registrieren oder nicht mehr vorhandene aus ihrer Datenbank zu entfernen.
Weitergehende Informationen können unter folgenden RFCs nachgelesen werden:
© by Stephan Pilz |