Zusammenfassung:

1. RFC: Request For Comments

2. TCP/IP

2.1. IP - Internet Protocol

    2.1.1. Die IP-Adresse
    2.2.2. IPv6

2.2. TCP - Transmission Control Protocol

3. DNS - Domain Name Service

4. HTTP - Hyper Text Transfer Protocol

5. MIME-Types - Multipurpose Internet Mail Extension

6. SMTP - Simple Mail Transfer Protocol

7. NNTP - Network News Transfer Protocol

8. FTP - File Transfer Protocol

RFC:

RFC ist die Abkürzung für Request For Comments. Durch sie werden alle Standards und Protokolle im Internet beschrieben. Sie sind jedem im Internet zugänglich. Die zugehörige Nummer (z.B. RFC793 für TCP - s.u.) ist eindeutig, wird nur einmal vergeben und nach der Vergabe wird auch das zugehörige Dokument nicht mehr verändert.

Da es keine Organisation gibt, die für das Internet an sich verantwortlich ist, sind Arbeitsgruppen entstanden, die über RFCs versuchen Standards in den verschiedenen Bereiche festzulegen und somit die Entwicklung zu vereinfachen und zu beschleunigen.
Die wichtigste dieser Organisationen die sich mit diesen Standards beschäftigt ist "Internet Activities Board" (IAB). Sie ist für die Internet-Standards und die Verwaltung der RFCs zuständig.

Das IAB hat zwei Unterorganisationen gebildet, die IETF (Internet Engineering Task Force), die für die Funktion des Internets sowie die Lösung aller Protokoll- und Architekturfragen verantwortlich ist, sowie die IRTF (Internet Research Task Force), deren Schwerpunkt auf der Forschung und Entwicklung von neuen Technologien liegt.

Die RFCs sind als Arbeitspapiere für die Gemeinschaft der Internet-Entwickler zu sehen und behandeln thematisch jedes Gebiet der Computer-Kommunikation. Der Status kann dabei von einem einfachen Informationspapier bis hin zur Spezifikation eines Standards variieren.

Sie lassen sich in folgende Kategorien einteilen:
- Required: Vorraussetzung für das Internet
- Recommended/Suggested: wird sehr empfohlen (üblicherweise auch implementiert)
- Elective: der Entwurf ist anerkannt aber kein Standard, Implementierung offen
- Limited Use: keine generelle Nutzung empfohlen
- Not recommended: veraltet, nicht implementieren
- Obsolete: nicht ausgearbeitet, keine Implementierung empfohlen

Wie man an der Aufteilung sieht, wird zwar jeder Standard als RFC veröffentlicht, aber nicht alle RFCs sind Standards. Jeder kann eine Publikation als RFC vorschlagen, dieser Vorschlag wird von entsprechenden Experten vor der Veröffentlichung geprüft. Die offiziellen Standards für die Veröffentlichung sind in RFC 1140 (IAB Official Protocol Standards) enthalten.

Bei der Prüfung als RFC werden folgende Stufen durchlaufen:
- Experimental: in einer Testphase
- Proposed Standard: im Test der IAB
- Draft Standard: Entwurf, Modifikationen möglich
- Internet Standard: offizieller Standard
- Historic: veraltet

Da die RFC-Nummer einmalig vergeben wird, erhält ein überarbeitetes Dokument eine neue Nummer. Eine Neuerscheinung wird über die RFC-DIST-Mailinglist bekannt gegeben. In diese Liste kann man sich Eintragen indem man z.B. eine Email an Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. mit dem Body-Text "subscribe rfc-dist" schickt.
Die Suche nach RFCs beziehungsweise das Anfordern bekannter RFCs geht auch per Email an die Adresse Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. . Mit bestimmten Anweisungen, die man beim Anmelden per Email zugeschickt bekommt, kann man Daten suchen und anfordern. Das gleiche gilt auch für Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. (weitere Möglichkeiten siehe Vortragsfolie RFC). Über die Webseite http://www.rfc-editor.orgsind alle verfügbaren RFCs und zugehörige HOWTOs über einen herkömmlichen Browser abrufbar.

Auch über FTP hat man über folgende Server Zugang zu RFCs:

Server	Verzeichnis
ds.internic.net	rfc
nis.nsf.net	internet/documents/rfc
nisc.jvnc.net	rfc
ftp.isi.edu	in-notes
wuarchive.wustl.edu	info/rfc
src.doc.ic.ac.uk	rfc

Im entsprechenden Verzeichnis sind die RFCs dann als .txt- oder .ps-Dateien mit folgenden Befehlen abrufbar:
  GET RFC-INDEX.TXT local_name (RFC Index)
  GET RFCxxxx.TXT local_name (Textversion)
  GET RFCxxxx.PS local_name (Postscriptversion)

Im Index-File sind alle RFCs erfasst es beinhaltet eine Übersicht über z.Zt. etwa 3300 Dokumente. Das erste aufgeführte Dokument ist aus dem Jahr 1969 und hat als Titel "Host Software". Nicht alle RFCs unter der Nummer 698 (Juli 1975) sind online verfügbar.

Als Alternative zu den inzwischen umfangreichen und unübersichtlichen RFCs gibt es die im März 1992 eingeführten STDs (Standards). Sie sind Internetstandards auf dem neuesten Stand und beziehen sich auf die aktuellsten RFCs. Ihre Nummerierung bleibt gleich und der Inhalt wird jeweils auf den aktuellen Stand gebracht. Die STD-Bezeichnung eines NetBIOS Service Protocols würde dann lauten: STD-19/RFC-1001/RFC-1002, da sich u.a. auf 2 RFCs bezieht.

Im folgenden werden RFCs angeführt, die sich hauptsächlich mit den unterschiedlichen Netzwerkprotokollen des Internets beschäftigen.

TCP/IP:

Bei Protokollen im Allgemeinen handelt es sich um festgelegte Standards für einen Datenaustausch. Sie regeln das Verhalten beim Transfer und machen eine Kommunikation erst möglich. Meist werden für diese Vorgänge mehrere Protokolle benötigt, die dann nacheinander in Aktion treten. Die Informationseinheit durchläuft mehrere Schichten, die jeweils eine bestimmte Aufgabe erfüllen. Werden Daten gesendet, durchlaufen sie diese schichten von oben nach unten, beim Empfang werden diese in umgekehrter Reihenfolge verarbeitet und so wieder in den ursprünglichen Zustand gebracht.

Open Systems Interconnection Referenzmodell:

senden \/	Anwendungsschicht	empfangen /\
	Darstellungsschicht
	Sitzungsschicht
	Transportschicht
	Vermittlungssschicht
	Datensicherungsschicht
	Bitübertragungsschicht

Das US-Verteidigungsministerium wollte in den sechziger Jahren eine Netzwerktechnologie entwickeln, die mit Teilausfällen von genutzten Leitungen zurechtkommt. Aus diesem Grund war eine direkte Datenübertragung zwischen Sender und Empfänger nicht möglich. Die Advanced Research Projects Agency (ARPA), ein Zusammenschluss mehrerer Wissenschaftler und Universitäten, wurde 1957 mit der Entwicklung eines neuen Systems beauftragt.
Die Grundidee war ein paketvermittelndes Netzwerk (packet-switched network) zu organisieren. D.h. es werden keine direkte Verbindung zwischen zwei Rechnern aufgebaut, die Information wird in Pakete aufgeteilt und auf bestmöglichem Wege übertragen. Nach Ankunft aller Pakete beim Empfänger werden diese wiederum in richtiger Reihenfolge zusammengesetzt.

Durchgesetzt hat sich die Kombination von TCP/IP, die 1974 offiziell eingeführt wurde.

Bei TCP/IP handelt es sich um die Zusammenarbeit von zwei Protokollen. Das Transmission Control Protocol (TCP - RFC793) und das Internet Protocol (IP - RFC791) bilden die Grundlage für die Informationsübertragung im Internet. Alle unten aufgeführten Netzwerkprotokolle bauen auf diesen beiden auf. Sie sind an sich plattformunabhängig und erfüllt somit ein wichtiges Kriterium für die Datenübertragung im Internet zwischen unterschiedlichen Systemen.

Das Schichtmodell für die Datenübertragung über TCP/IP ist an das OSI-Modell angelehnt. Das Open System Interconnection Referenzmodell besteht aus sieben Schichten (Application, Presentation, Session, Transport, Network, Data Link und Physical Layer). Jede Schicht hat die Aufgabe der übergeordneten Schicht bestimmte Funktionen bereitzustellen. Vorraussetzungen für eine einzelne Schicht ist u.a. ein eigener Abstraktionsgrad, eine genau definierte Funktion, international genormte Protokolle sollen berücksichtigt werden, die Schnittstellen zu anderen Schichten sollen so wenig Daten wie möglich benötigen, wobei dennoch die Anzahl der Schichten gering zu halten ist.
Das OSI-Referenzmodell ist erst nach der TCP/IP Entwicklung entstanden. Somit ist das OSI-Modell bereits an den TCP/IP-Aufbau angelehnt, wobei das TCP/IP-Modell nur aus vier Schichten besteht.
Die oberste Schicht ist die Application Layer, danach folgt die Transport Layer, hier ist das TCP zu finden, gefolgt von der Internet Layer mit dem IP und schließlich die Network Layer.

Die Application Layer beinhaltet höherliegende Protokolle, die das TCP/IP nutzen. Dazu gehören z.B. TELNET, FTP, SMTP, DNS, HTTP und mehr. Die wichtigsten werden im folgenden näher beschrieben.

Die Transport Layer bereitet die Information für den Weg vom Host zum Zielhost vor. Hier kann neben TCP das User Datagram Protocol (UDP) als Protokoll eingesetzt werden.
Der Unterschied liegt darin, dass bei UDP im Gegensatz zu TCP keine Empfangsbestätigung vom Zielhost zurückgeschickt wird. Das UDP wird dort eingesetzt, wo die Geschwindigkeit wichtiger als die Übertragungssicherheit ist, dies ist z.B. bei Video- oder Audiostreaming der Fall.
Die Internet Layer besteht aus dem IP. Dieses Protokoll ist für die richtige Adressierung und Zustellung (Routing) der Informationspakete im Netz zuständig.
Die unterste Schicht, die network layer, ist für die physikalische Übermittlung von Daten übers Netzwerk(kabel) zuständig (z.B. Firewire, Ethernet).
Um ihre Aufgabe erfüllen zu können hängt jede Schicht einen s.g. HEADER an die eigentliche Informationseinheit. Hier sind entsprechende Informationen abgelegt, die der Funktionalität und der Kontrolle dienen.

IP:

Das Internet besteht aus mehreren Netzen die über die ganze Welt verteilt sind. Die "Hauptadern" des Internets sind die s.g. Backbones (Rückgrat). Sie bestehen aus Routern und sind über Hochleistungsleitungen miteinander verbunden. So kann man z.B. ein US-Backbone und ein European-Backbone unterscheiden. Diese sind über sehr leistungsfähige Transatlantic-Leitungen miteinander verbunden.
An die Backbones schließen dann weitere Netzwerke an, z.B. die von Universitäten oder Providern. Über das IP wird der Datenfluss zwischen den Routern gesteuert und kontrolliert. Die Hauptaufgabe besteht somit darin, aus großen Informationseinheiten kleinere Pakete zu bilden und diese auf verschiedenen Wegen sicher vom Host zum Zielhost zu übertragen. Die Daten wandern so über verschiedene Netzwerke. Das IP an sich besitzt aber keinerlei Kontrolle über die Zustellsicherheit der einzelnen Pakete. Diese werden einfach vom Host ins Netzwerk gesendet. Das IP hat folgende konkrete Aufgaben: die Aufteilung in Pakete, Zuordnung zu einer Adresse nach einem festgelegten Schema (IP-Adresse - s.u.), die Übertragung der Daten an die Netzwerkschicht, die Weiterleitung der Daten über die einzelnen Router und Netzwerke (Routing) und die Zusammensetzung der empfangenen Daten beim Zielhost.
Ein solches Packet wird Datagram genannt. Es besteht aus der zu übertragenden Information und einem ihr vom IP angefügten HEADER. Der Header hat eine feste Größe von 20 Byte und enthält alle notwendigen Informationen für den Datentransport.
Der Body mit den eigentlichen Daten kann von IP aus bis zu 64kByte groß sein, durch die zugrundeliegende Ethernet-Technik ist die Größe auf etwa 1500 Byte beschränkt.

Version: gibt die Versionsnummer des IP (V4, V6) an
Type of Service: legt Prioritäten für die Paketbearbeitung fest
Length: Länge des Headers (Grundgröße 20 Byte + weitere Optionen)
Total Length: gesamte Paketgröße
Identification: Zuordnung von einzelnen Fragmenten
Fragment Offset: Datagram-Nummer im gesamten Datenkontext
Time to Live: Lebensdauer eines Pakets
Protocol: bestimmt das Protokoll in der Transport Layer (TCP = 6, UDP = 17)
Header Checksum: Prüfsumme für den Header (Time To Live, Flg und Fragment Offset)
Flags: DF - Don't Fragment und MF - More Fragments
Source Address/Destination Address: 32bit lange IP-Adressen
Options: optionale Informationen (z.B. Sicherheit)
Padding: Auffüllfunktion

Das IP ist auch in der Lage beim Transport der Daten über verschiedenen Netzwerke die Datenpakete entsprechend anzupassen. Bei der s.g. Fragmentierung wird u.U. ein Paket, das die maximale Paketgröße eines Netzwerks überschreitet, in kleinere Pakete aufgeteilt. So zerteilt das IP eines Netzwerkknotens das ursprüngliche Paket in kleinere Pakete. Diese werden entsprechend mit einem Header versehen, mit dessen Hilfe sie wieder an beliebiger Stelle im Netz über das IP zusammengesetzt werden können.
Zur Fehlerdiagnose wird zusätzlich das Internet Control Message Protocol (ICMP - PING) im Datagram eingebaut. Dies ermöglicht die Anforderung von Diagnoseinformationen von einem Router bzw. Zielhost, die dann an den Sender zurückgeschickt werden (über IP).
U.a. werden folgende Informationen zurückgeschickt: Destination Unreachable, Source Quench (Paketanzahl übersteigt Kapazität, Sender muss Anzahl verringern), Parameter Problem (Header ist fehlerhaft, Paket noch mal senden), Redirect (falsch weitergeleitete Pakete, Route ändern), Time Exceed (Lebensdauer abgelaufen), Echo Reply/Echo Request (Erreichbarkeit eines Hosts - ein Request wird gesendet und bekommt als Antwort die Reply-Meldung), Timestamp Request/Timestamp Reply (wie zuvor, jedoch mit Ankunfts- und Sendezeiten versehen).

Die IP-Adresse:

Jeder Host und Router im Internet bekommt eine eindeutige IP-Adresse zugewiesen. Ist ein System an mehreren Netzwerken angeschlossen hat es in jedem Netzwerk eine eigene Adresse. Somit identifiziert eine IP-Adresse nicht unbedingt einen Rechner, sondern dessen Zugang zum Netz.

Beim Routing-Vorgang sucht der Router nach Einträgen in seiner Routing-Tabelle die die IP-Adresse (Netzwerk ID und Host ID) des Ziels beinhaltet. Ist ein Eintrag vorhanden, wird das Datagramm an den entsprechenden Router zur direkten Übermittlung übergeben.
Ist dies nicht der Fall, sucht der Router lediglich nach der Netzwerk-ID. Ist hier ebenfalls kein Eintrag vorhanden wird der Standard-Router ("default") gesucht und das Paket an diesen übergeben. Sonst ist das Datagramm nicht zustellbar.

Es gibt zwei Routing-Verfahren. Statisches Routing legt einen Weg vor. Beim dynamischen Routing kommunizieren die Router über Protokolle wie RIP (Router Information Protocol) oder IGRP (Interior Gateway Routing Protocol) über den Verlauf.

Für die Verwaltung von IP-Adressen ist die IANA (Internet Assigned Numbers Authority) zuständig. Weltweit ist sie in drei regionale Organisationen unterteilt.

  Nord- und Südamerika ARIN
  Europa RIPE
  Asien APNIC

Die Vergabe von IP-Adressen wird in RFC 2050 beschrieben. In der Praxis erfolgt die Reservierung von einer oder mehreren IP-Adressen immer über einen Internet Provider.

Die IP-Adresse an sich hat eine Länge von 32 Bit und wird als Dezimalzahl dargestellt, die der Übersichtlichkeit halber in 4 Blöcke (=Byte) aufgeteilt wird. Die 32-Bit große Zahl 01111111111111111111111111111111 entspricht der IP-Adresse 126.255.255.255. Die Adressbereich erstrecken sich von 0.0.0.0 bis 255.255.255.255.

Die Adressen werden in Klassen unterteilt. Bei der Adressklasse A wird das Netzwerk über die erste Stelle bestimmt. Die folgenden drei Stellen beziehen sich auf einzelne Hosts in diesem Netzwerk. Die Anzahl der Hosts liegt bei etwa 16 Mio. (2hoch24) verteilt auf 126 Netze. Das erste Bit ist eine Null.
Bei der Klasse B bezeichnen die ersten beiden Byte-Blöcke ein Netzwerk und die folgenden einen Host in diesem Netzwerk (etwa 64000 Hosts = 2hoch16). Der Wert für das erste Byte liegt unter 192, der Anfang in Bits lautet 10. Die Klasse C hat lediglich die letzte Stelle für Hosts frei (254 Hosts/Netzwerk, Bitfolge 110...). Der erste Byte-Block geht bis zum Wert 223.
Darüber hinaus kommt man in die Klasse D Adressen, s.g. Multicast-Adressen. Sie dienen dazu ein Datagram an mehrere Hosts zu versenden. Dazu wird ein spezielles Protokoll genutzt, das Internet Group Management Protocol (IGMP; RFC1112). Dieses arbeitet mit Anfrage- und Antwort-Paketen, um zu erfahren welche Hosts einer Gruppe angehören bzw. welcher Gruppe ein Host angehört. Dazu werden spezielle Router (M-Router) benötigt. Die Multicast - Adressen können nur zum Adressieren genutzt werden. Sie werden von Internetorganosationen genutzt (224.0.0.2 - alle multicastfähigen Knoten).
Der Bereich über 240 ist z.Zt. reserviert.

Einige Bereiche haben weitere Sonderfunktionen. So sind die Adressen 10.0.0.0 bis 10.255.255.254 für ein privates (RFC 1918) Klasse A-Netz reserviert. Ein privates Klasse B-Netz nutzt die Adressen von 172.16.0.0 bis 172.31.0.0 mit bis zu 65.000 Hosts. Adressen die mit 192.168.0.. beginnen sind Klasse C-Adressen, die für eine private Nutzung reserviert sind und bis zu 254 Hosts enthalten. Privat bedeutet, dass diese Adressen beliebig genutzt werden können, ohne Adressenkonflikte im Internet zu verursachen. Sie werden nicht weiter über das Internet übertragen.

Über die 255 bei der Hostadresse (Broadcast-Adresse) werden alle Hosts in einem Netzwerk adressiert. Die Netznummer 0 steht für das für den Host aktuelle Netzwerk. D.h. der Host muss die eigene Netzwerkadresse nicht wissen.
Die 127 steht für den s.g. Loopback Device und wird auf dem System lokal verarbeitet.

IPv6:

Durch das starke Wachstum des Internets und die Annäherung der Hostzahlen an die momentane Möglichkeiten der IP-Adressierung soll in Zukunft die momentane Version 4 durch eine leistungsstärkere abgelöst werden.
Ipv6 (1995/96 zum Standard RFC1883) soll der wachsenden Leistungsanforderung im Internet gewachsen sein.
Zu Anfangszeiten des Intenets schienen bei etwa 1000 aktiven Rechnern die Möglichkeiten mit über 4 Milliarden Adressen vollkommen ausreichend. Durch das wachsen des Internets ist dies zwischenzeitlich nicht der Fall. Hierzu wird die Adressauflösung von 32 auf 128 Bit erhöht. Dadurch können in Zukunft etwa 2hoch128 bzw. 3.4*10hoch38 Adressen verwaltet werden. Die Anzahl der Felder im Header sinkt von 13 auf 7 um die Routing-Geschwindigkeit zu erhöhen. Weitere Informationen werden auf zusätzliche Header ausgelagert.
Ipv6 soll in Zukunft auch bestimmte Dienste im Internet besser unterstützen. V.a. bei Video- und Audiodaten sollen Möglichkeiten einer Echtzeitübertragung geschaffen werden. Hinzu kommen Funktionen, die die Sicherheit der Datenübertragung stützen sollen.

die Adresse sieht dann wie folgt aus:
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Nullen können zusammengefasst werden:
1234:0000:0000:0000:0000:0000:0000:1234 = 1234:0:0:0:0:0:0:1234 = 1234::1234
bzw.
63.254.4.0.2.128.0.0.0.0.0.0.0.0.0.1 = 3ffe:400:280:0:0:0:0:1 = 3ffe:400:280::1


Kompatibilität zu IPv4:
195.26.159.14 -> ::ffff:195:26:159:14 = ::ffff:c31a:9fe

Die Loopback Adresse:
::1 (anstelle 127.0.0.1)


Möglichkeiten von IPv6:

- Quality of Service
Multimedia-Anwendungen, wie Video und Sound, werden optimierter übertragen. Bei IPv4 können einzelne Pakete verworfen werden und somit auch aufgrund unterschiedlicher Wege in einer anderen Reihenfolge eintreffen, was bei einer normalen Datenübertragung nicht auffällt.
IPv6 besitzt im Header einen Flow Label. Dadurch werden solche Pakete gekennzeichnet, merken sich die Route und werden bevorrechtigt behandelt. Dadurch kommt zumindest eine kontinuierliche Leitung zustande.

- Authentisierung und Verschlüsselung
Bei IPv4 wir der Sicherheitsaspekte z.Zt. durch Zusatzdienste https oder Telnet und SSH abgedeckt. Bei IPv6 wird ein Sicherheitsstandard auf der Protokollebene möglich zur Authentisierung und Verschlüsselung von Daten. Hierzu werden zwei zusätzliche Header eingesetzt:
  Authentication-Header: Empfänger kann feststellen, ob das Paket wirklich vom angegebenen
  Absender stammt oder ob es auf dem Weg verändert wurde
  Encapsulating Security Payload Header: verschlüsselt Daten und sorgt für die korrekte Übertragung

- IPv6 Address Privacy
Gewährleistung der Sicherheit bei Geräten mit eindeutiger Seriennummer. Um das Übertragen von Informationen über den einzelnen User zu verhindern wird von der IETF ein System entwickelt das über Zufallszahlen eine temporäre Verbindung aufbaut. Der Webserver besitzt dabei eine feste Adresse.

- Mobile IPv6
Bei GPRS und UMTS-Übertragungen werden mobile Geräte eine feste IP-Adresse bekommen und überall auf der Welt erreichbar sein. Der Mobility Support in IPv6 teilt einem mobile Gerät zusätzlich eine zweite, sogenannten care-of Adresse, zu. Das erste Paket geht an den Heimatrouter und wir dann weitergeleitet. Der Router schickt aber zusätzlich die care-of zurück. Weitere Pakete werden an die care-of Adresse geschickt.

- Router Discovery
Einzelne Rechnern suchen automatisch nach Routern im Netz. D.h. keine Einwahl nötig.

- statuslose Autokonfiguration
Durch IPv6 ist es Geräten in einem Netz möglich, sich vollkommen selbständig zu konfigurieren, d.h. ihre IP-Adresse auszuhandeln.

TCP:

Das TCP liegt im Schichtmodell in der Transport Layer und somit über dem IP. Es baut eine zuverlässige end-to-end-Verbindung auf. Zuverlässig heißt, dass die Pakete nicht einfach ins Netz geschickt werden, wie beim oben erwähnten UDP. Es wird eine Verbindung zum Zielhost aufgebaut, die bestätigt werden muss. Hinzu kommt eine Prüfsumme im TCP-Header zur Überprüfung von Fehlern im Datenabschnitt der Pakete, die auf der Ebene des TCP als Segmente bezeichnet werden. Ist die Prüfsumme nicht korrekt, d.h. sind Pakete verloren gegangen oder beschädigt, wird keine Empfangsbestätigung versendet. Erhält der Sender nach einer Zeit keine Empfangsbestätigung, sendet er ein Paket erneut.

Bereits vor dem Senden der eigentlichen Daten wird eine Verbindung über den s.g. Three-Way-Handshake aufgebaut. Hier wird zuerst ein Segment gesendet, dessen SYN-Flag im Header aktiviert ist. Dadurch wird dem Zielhost mitgeteilt, dass eine Verbindung aufgebaut werden soll und zwar mit der Sequenznummer, die ebenfalls im Header festgelegt ist. Der Empfänger kann die Verbindung aufnehmen, indem er ein Bestätigungssegment zurückschickt in dem zusätzlich das ACK-Bit aktiviert ist. Die Sequenznummer wird zur Bestätigung im Feld Acknowledgement Number abgelegt und dann um Eins erhöht, damit der Senderhost weiß, mit welcher er fortfahren soll.
Der Sender bestätigt die zustande gekommene Verbindung indem er erneut ein Segment an den Empfänger schickt (aktives ACK-Feld und die vom Empfänger angegebenen Sequenznummer als Acknowledgement Number). An dieses Paket können bereits die ersten Daten angehängt werden. Am Ende der Datenübertragung wird das FIN-Bit aktiviert. Es kommt meistens vor, dass die einzelnen Datenpakete nicht in der gleichen Reihenfolge ankommen in der sie verschickt wurden, da sie über verschiedene Wege weitergeleitet wurden. Somit sind die Hauptaufgaben von TCP sicherzustellen, dass diese Daten beim Empfänger ankommen und dort wieder in der richtigen Reihenfolge zusammengesetzt werden.
Über das TCP kann auch eine s.g. Portnummer (16bit, 65.535 Ports) angegeben werden. Dadurch ist es möglich eine Applikation auf dem Zielsystem direkt anzusprechen. Beispiele für Portnummern sind: TELNET auf Port 23, FTP auf 21, SQL auf 14333.

Der TCP-Header ist 20 Byte groß, daran können weitere Optionen angehängt werden. Die Informationseinheit und der Header müssen in das Datenfeld des IP-Fragments passen.

Die einzelnen Felder werden wie folgt definiert:

· Source Port: Portnummer des Senders
· Destination Port: Portnummer des Empfängers
· Sequence und Acknowledgement Number: zur Kontrolle der Reihenfolge der einzelnen Pakete
· Offset: Länge des gesamten Headers
· Flags

o URG: urgent pointer - dringend
o ACK: Bestätigung wird mitverschickt
o PSH: Daten werden nicht gepuffert, sondern sofort verarbeitet
o RST: Verbindung wird zurückgesetzt. V.a. bei Übertragungsfehlern, beim ungültigen Segment oder beim Zurückweisen einer Verbindung
o SYN: Verbindungsaufbau
o FIN: Verbindungsende

· Window: Anzahl Bytes die in beide Richtungen gesendet werden dürfen. Ist z.B. das Feld auf 0 gesetzt heißt das das Pakete bis zur Acknoledgement Number minus Eins empfangen wurden, aber der Empfänger nun keine Daten mehr empfangen kann. Ein Paket mit gleicher Acknowledgement Number und einem Wert ungleich 0 bedeutet eine Wiederaufnahme des Empfanges.
· Checksum: Enthält eine algorithmisch erzeugte Summe anhand der Daten auf ihre Richtigkeit überprüft werden
· Urgent Pointer: weist zusammen mit der Sequenznummer auf die Stelle hin, in der dringende Daten abgelegt sind
· Options: weitere Felder, u.a. für die maximale Segmentgröße
· Padding: sichert die Headerlänge von max. 32 Bit und den Anfang der eigentlichen Daten

PORTS:
· Well known Ports: 0 bis 1023 werden von der IANA bestimmt, sind fest und sind nur vom System nutzbar (FTP: 21, SSH: 22, TELNET: 23, SMTP: 24, http: 80)
· Registered Ports: 1024 bis 49151 ebenfalls von der IANA verwaltet, können von Entwicklern beantragt werden und auf USER-Ebene nutzbar (MS SQL: 1433, mySQL: 3306)
· Dynamic/Private Ports: 49151 bis 65535 keine Kontrolle
 

DNS:

Ein wichtiges Protokoll für das Web das TCP/IP nutzt ist der Domain Name Service (RFC1034, RFC1035). Dieser wandelt ASCII-Zeichenketten in IP-Adressen um. Die Notwendigkeit für DNS ergibt sich aus der Tatsache heraus, dass begriffliche Namen für den User besser zu handhaben sind.
Rechner, die für diese Zuordnung von Namen zu IP-Adressen und umgekehrt verantwortlich sind, heißen Domain Name Server oder auch Name Server. Mehrere Domains können einer IP-Adresse zugeordnet werden.

Eine Domain wir wie folgt aufgelöst:

129.187.  214.81
\/
/\
Rechnername.Subdomain.   Toplevel-Domain.Domain
www.pms.informatik.     uni-muenchen.de     

Die Toplevel-Domain entspricht der Landeskennung (.de, .ch, .at) bzw. der Art der Organisation (.otg, .edu, .com). Wobei eine systematische Zuordnung der Länderkennung erst in V6 vorgesehen ist. Da das System aus den USA stammt waren die ersten Endungen .com (Company), .edu (Education), .org (non-commercial organisation) bzw. .net (Network).
Für die Vergabe von Domanis ist das Network Information Center zuständig (NIC - für Deutschland: deNIC). Hier wird auch der Name der Domain zuerst beantragt, bevor er genutzt werden kann. Als Rechnername wird standardmäßig WWW eingetragen um zu zeigen, dass ein Webserver angesprochen wird. Es könne aber auch Rechnernamen oder weitere Subdomain vorangestellt werden.

HTTP:

Das Hyper Text Transfer Protokoll (V1.1 - RFC2616) basiert ebenfalls auf TCP/IP und ist somit auch verbindungsorientiert. Das HTTP ist das zugrundeliegende Protokoll für das WWW in der Aplication-Layer. HTTP übermittelt Daten vom Webserver zum Webbrowser und umgekehrt. Übertragen werden HTML-Dokumente (Hypertext Markup Language) sowie einige Erweiterungen wie Bilddateien, Audiodateien etc. Dateien werden im Zusammenhang mit HTTP als Ressourcen bezeichnet. Die Spezialisierung der zusätzlichen Formate finden auf Browser und Server über die s.g. MIME-Types statt (s.u.). Zwischen Browser (Client) und Server wird über das TCP/IP eine Verbindung hergestellt und über die URL (Unified Ressource Locators - Format für Pfadangaben im Internet - http://www.pms.informatik.uni-muenchen.de/lehre/seminar/client-server/01ss/index.htm) wird eine bestimmte Datei aufgerufen. Diese Datei besteht meistens aus einem HTML-Code und anderen implementierten Datenformaten wie z.B. .jpg, .png oder .gif als typische Bildformate im Internet.
Sind die Daten an den Browser übermittelt, wird die Verbindung zum Server wieder beendet. Um Daten vom Server anzufordern wird zuerst die Initial Request Line gesendet. Diese besteht aus dem Aufruf einer bestimmten Methode. Die Methode zum Anfordern von Daten heißt GET. Anschließend folgt die Pfadangabe auf dem Server für das gesuchte File, dann die benutzte HTTP-Version.

    GET /path/to/file/index.html HTTP/1.0

Um größere Datenmengen zu übergeben wird die POST-Methode verwendet. Hier werden die Daten nicht über die URL sondern im Kontext der Anfrage übertragen.
Mit der PUT-Methode können Daten unter der angegebenen URL abgelegt werden, wenn dieses der Server zulässt.

Der angesprochene Server sendet dann die s.g. Initial Response Line (Status Line) die ebenfalls aus 3 Teilen besteht. Zuerst die HTTP-Version, dann der response status code und die zugehörige Kurzbeschreibung.

    http/1.0 404 Not Found

Der Response Status Code besteht aus einer dreistelligen Zahl. Aufgrund der ersten Ziffer kann er in folgende Gruppen eingeteilt werden.
   1xx - zur Information
   2xx - Erfolgsmeldung
   3xx - Client wird umgeleitet auf eine andere URL
   4xx - Fehler clientseitig
   5xx - Fehler serverseitig

Beispiele sind:
   200 OK: Erfolgreiche Anfrage
   404 Not Found: das angeforderte File konnte nicht gefunden werden
   301 Moved Permanetly: Umleitung
   302 Moved Temporarily: vorübergehende Umleitung
   400 Bad Request: Anfrage enthält falsche Syntax
   500 Server Error: Fehler beim abrufen der Datei auf dem Server

Danach können mehrere Headerlines folgen in denen weitere Informationen vom Client oder Server abgelegt werden. HTTP 1.0 kennt 16 verschiedene Headerlines, diese sind für eine reguläre Verbindung nicht erforderlich.

Beispiele:

Client:
  Accept: MIME-Types des Browsers
  From: gibt Emailadresse des Benutzers an
  User-Agent: gibt das Programm an, dass diese Anfrage macht (User-agent: Mozilla/3.0Gold)

Server:
Server: gibt die Serversoftware an (Server: Apache/1.2b3-dev)
 Last-Modified: das Datum der letzten Änderung (Sun, 11 Feb 2001 20:34:54 GMT)
 Content-Length: Länge des Body-Inhalts
 Content-Type: MIME-Type des Body

Abschließend folgt eine Leerzeile und danach der Body mit den Daten für den User.

Vom Client aus können ebenfalls Daten, die vom User eingegeben wurden, übertragen werden. Über eine Angabe im Feld Content-Type des Headers wird der MIME-Type (s.u.) des Bodys übertragen (Content-Type: text/html für ein HTML-Dokument) und über Content-Length die Größe der Datei.

Verwendet man statt GET die HEAD-Methode, so werden nur die Header-Daten ausgetauscht. Mit der POST-Methode werden Daten an ein Script auf dem Server geschickt. Als Pfad ist dann das entsprechende Script anzugeben, die Antwort ist das Auswertungsergebnis dieses Skripts (CGI, Pearl etc.).

Die Version 1.1 des HTTP wird seit etwa 1997 verwendet und ist zur Version 1.0 abwärtskompatibel. V1.1 ist durch eine Datenkompression und kleinere Pakete bis zu 10mal schneller als V1.0. Sie unterstützt die CSS und das Bildformat PNG. Weitere Vorteile sind u.a. die Möglichkeit mehrere Aktionen über eine bestehende Verbindung durchzuführen. Ein zusätzlicher Cache-Support. Bei dynamischen Seiten besteht die Möglichkeit diese zu versenden ohne die Gesamtgröße zu kennen (Chunked-Transfer-Encoding).
Im Gegensatz zur V 1.0 werden aber bestimmte Header-Felder benötigt. Clientseitig und Serverseitig ist es die Angabe des Zielhosts (Host) erforderlich, da man mehrere Hosts einer IP-Adresse zuordnen kann (multi-homed Server). Die Aufforderung die Verbindung nach dem Transfer zu schließen (Connection: close) muss ebenfalls explizit angegeben werden, da hier die Verbindung sonst bis zu einem Timeout von Seiten des Servers offen bleibt.

MIME-Types:

In der Anfangszeit der Internets wurden lediglich Emails im ASCII-Format verschickt. Inzwischen werden aber weitere Dateiformate sowohl per Email versendet, als auch über einen Webserver angefordert. Die Multipurpose Internet Mail Extension (RFC 1521) ermöglicht auch die Übertragung von Daten im anderen Format. Diese werden dann entsprechend ihrer Dateiendung an ein weiterverarbeitendes Programm geleitet bzw. könne vom Browser entsprechend angezeigt werden. Handelt es sich um ein zusätzliches Programm das auf Browser-Ebene ausgeführt wird, spricht man beim Browser von einem Plug-In. Ist das Format nicht eingetragen bzw. nicht zugeordnet wird die Möglichkeit eines Downloads angeboten.
Es werden folgende Felder im Header hinzugefügt:

· Mime-Version: Version für MIME bisher nur 1.0
· Content-Type: gibt das Datenformat an. Besteht aus Typ und Untertyp (text/plain - ASCII Text, test/html für HTML, image/jpeg oder image/gif für die gängigsten Bildformate, multipart/mixed - aus mehreren Teilen bestehend). Sowohl beim Absender als auch Empfänger muss der Mime-Type eingetragen sein, um eine eindeutige Zuordnung zu ermöglichen.
· Content-Transfer-Encoding: gibt das Codierungsformat an (z.B. 7bit für normalen ASCII-Text (Standard), 8bit für 8bit ASCII, quoted-printable für Text in dem Sonderzeichen speziell codiert werden). Der benötigte Zeichensatz wird als ISO-Format angegeben (Content-Type: text/plain; charset=iso-8859-1).
· Content-ID: stellt bei Emails eine Beziehung zu einer anderen Email her (optional).
· Content-Description: kurze Beschreibung des Inhalts (optional).

Bei einer Webpage werden Inhalte wie Bilder etc. als neue Nachricht an den Browser verschickt. Anhand des Dateitypes erkennt der Browser, wie die Datei zu verarbeiten ist. D.h. ob er sie direkt anzeigen soll, an ein anderes Programm schicken oder zum Download anbieten soll.

SMTP:

Das Simple Mail Transfer Protocol ist das Protokoll für das Versenden von Email (electronic mail) und ebenfalls in der Application Layer über Port 25 zu finden. Zum Emails versenden werden zusätzlich zwei Komponenten benötigt. Zum einen der Message Transfer Agent und zum anderen der User Agent. MTA sorgt für die Übermittlung im Internet und benutzt dazu SMTP. UA wird vom User zum erstellen und Verwalten von Emails auf dem Rechner benutzt und kontaktiert zum Senden und Empfangen der Emails einen MTA (lokaler MTA). Ankommende Emails werden in entsprechende Mailboxes ablegt.

Nach einem Verbindungsaufbau wartet der Sender-MTA auf eine Nachricht "220 READY FOR MAIL". Danach wird der Befehl HELO zurückgesendet und es wird eine Identifikation des Empfänger-Servers erwartet. Danach beginnt die eigentliche Datenübertragung.

Einige Commandos (alle auf 4 Buchstaben beschränkt):
· HELP Liste aller verfügbaren Befehle
· HELO Senderidentifikation
· MAIL Beginn der Transaktion
· RCPT Identifikation des Empfängers
· VRFY Bestätigung der Benutzeridentifikation
· DATA Beginn des Datentransfers
· NOOP No Operation (OK erwartet)
· QUIT Ende der Verbindung

Nach Aufbau einer Verbindung wird das MAIL-Commando (MAIL <SP> FROM:<reverse-path> <CRLF>) mit der Absenderidentifikation geschickt. Die Absenderadresse (reverse-path) dient zum Versenden von Fehlermeldungen. Werden Emails vom angegebenen Sender akzeptiert, folgt vom Empfänger das OK (Report: 250 OK). Danach kommt wiederum vom Sender das RCPT-Commando (RCPT <SP> TO:<forward-path> <CRLF>) mit dem entsprechenden Empfängernamen (forward-path). Ist der Name auf dem Zielsystem registriert, wird vom Empfänger erneut ein OK gesendet. Ansonsten wird der Empfänger zurückgewiesen. Es können auch mehrere Empfänger angegeben werden (jeweils ein RCPT Befehl).
Ist ein Empfänger unbekannt wird das "550 Failure reply" zurückgesendet. Wird mindestens ein Empfänger akzeptiert beginnt der Sender mit dem Befehl DATA die eigentliche Datenübertragung. Nach Empfang der Daten kommt vom Zielserver ein OK zur Bestätigung. Die Daten, also der eigentliche Messagebody, enthalten einen Header der die bekannten Felder Date,Subject,To,Cc,From enthält (siehe Folien).

Ein SMTP-Server kann auch Informationen speichern, die zur Weiterleitung einer falsch adressierten Email dienen. Als Rückmeldung kommt hier "251 User not local; will forward to <forward-path>" bei einer zuverlässigen Weiterleitung, bzw. "551 User not local; please try <forward-path>" bei einem Versuch, hier muss allerdings der Sender die Weiterleitung übernehmen.

zusätzliche Commandos sind:

· VRFY gibt bei einer Anfrage nach einem User dessen vollständigen Namen bzw. die bekannte Email-Adresse
· EXPN gibt die User einer Mailingliste an

Unter "mailing" versteht man die Zuordnung einer Email in eine Mailbox. "Sending" ist die Lieferung zum entsprechenden Rechner.

Die Email-Nachricht an sich besteht ebenfalls aus einem Header und dem eigentlichen Inhalt, der durch eine Leerzeile getrennt ist.

Im Header sind u.a. folgende Felder enthalten:
· Date : Zeitpunkt des Absendens
· From : Absender (dieses Feld oder das Sender-Feld müssen vorhanden sein)
· Subject : Betreff, Überschrift.
· Sender : ist optional wenn From ausgefüllt ist
· Reply-to : Angabe einer gesonderten Antwortadresse
· To : Hauptempfänger
· cc : weitere Empfänger der Mail (Kopie)
· Comment : Optionaler Kommentar zur Nachricht
· In-Reply-To : vorangegangene Mails, auf die geantwortet wurde
· Message-ID : eindeutige ID einer Mail
· Return-Path : Informationen über die genutzte Route
· bcc : weitere Empfänger, bleiben für To: und cc: unsichtbar

Die Adressierung erfolgt über DNS indem vor den Domainnamen der Username (Empfänger) gefolgt von einem @ angegeben wird. Die Email wird dann an den zugehörigen Mailserver geleitet. Da nicht jeder einen eigenen MTA besitzt und nicht jeder Server für Emails verantwortlich ist, müssen die Mailserver vom Empfänger kontaktiert werden. Das Verwalten der Emails läuft dann über POP3 (RFC 1225) auf Port 110.

NNTP:
Das USENET ist das größte Newsnetzwerk das am das Internet hängt. Die einzelnen News werden zwischen den s.g. Newsservern über das Network News Transfer Protocol (RFC977) ausgetauscht. Es ist von den Grundfunktionen an das SMTP (s.o.) angelehnt. Die Nachrichten werden aber nicht zwischen einzelnen Personen, sondern zwischen Newsservern ausgetauscht.
Hier besteht die Möglichkeit über Newsgroups, bestehend aus Experten eines Themengebietes, Informationen anzufordern bzw. eigene Fragen zu stellen. Dazu benötigt man einen Newsreader (z.B. Forteagent oder auch Email-Programme wie MS Outlook oder NS Messanger) und einen Newsserver. Es wird der nächstgelegene Server zugeteilt der die Newsgroup hostet. Über das NNTP erfolgt die Verteilung der News auf die zuständigen Newsserver. Für das Senden von neu eingegangenen News sind die Daemons NNTPSEND und NNTPXMIT zuständig (push). NNTPD und NNTPXFER sind für das Empfangen von News auf einem Server zuständig (pull). Der Sytemadministrator legt die gewünschten Newsgroups auf dem Server fest und kann auch bestimmen, wie lange eine News auf dem Server abrufbereit ist. Bei Ankunft einer News wird diese jedem weiteren bekannten Newsserver angeboten. Der angesprochene Server überprüft anhand einer Liste, ob er vom Sender News empfangen darf. Ist dies nicht der Fall wird angenommen, dass es sich um einen Client handelt, der News abrufen will.

Die News werden auf dem entsprechenden Newsserver gespeichert. Der Name einer Newsgroup besteht im Allgemeinen aus deren Themengebieten, die in hierarchischer Form einen Punkt getrennt sind. Am Anfang kann die Landeskennung verwendet werden, um die Newsgroup lokal zu spezifizieren (de.comp.lang.javascript ist eine JavaScript-Newsgroup).

Weitere Kategorien sind u.a.:
· Comp : Computerfragen
· Misc : nicht zuordenbar
· News : Themen zu News selbst
· Rec : Freizeit
· Sci : Wissenschaft
· Soc : Soziales und Kulturelles
· Alt: Alternativen für alle Themenbereiche

Über lokale Kategorien wird auch die Ausbreitung der News auf den einzelnen Newsservern entsprechend beschränkt:
· De : deutsche Gruppen
· Eunet : europäische Gruppen
· Etc.

Über jede neue Newsgroup wird auf der Ebene der Kategorie abgestimmt. Eine Ausnahme ist die Kategorie ALT. Hier können alle Themen eingerichtet werden.

Eine News (RFC1036) hat den Aufbau einer Email (RFC822) mit folgenden Header-Angaben:
· FROM: Email-Adresse vom Verfasser
· Newsgroups: Newsgroup in der veröffentlich wird (Mehrfachangabe möglich)
· Subject: kurze Beschreibung der News (wichtig, da von den Usern zuerst gelesen)
· Reply-To: Emailadresse für eine Antwort an den Verfasser
· Followup-To: Newsgroup in denen Kommentare oder Antworten auf die gepostete News erscheinen
· Expires: Angabe eines Verfallsdatums
· Keywords: Schlüsselbegriffe
· Summary: Zusammenfassung

Häufig gestellte Fragen und Probleme werden in den s.g. FAQs (Frequently Asked Questions) zusammengestellt, um übermäßige Wiederholungen von Themen zu vermeiden.

FTP:

Für den direkten Austausch von Dateien wird das File Transfer Protocol verwendet. FTP wird oft bei File-Archiven eingesetzt und ermöglicht auch nichtregistrierten Usern Dateien vom Server zu kopieren.

Format für Anfrage:
ftp [IP_address|host_name]

Ein registrierter User hat über einen Login und ein Passwort Zugang auf für ihn freigegebenen Daten. Bei einem öffentlichen Fileserver kann man sich mit Login "ftp" und der Email-Adresse anmelden bzw. auch mit dem Login "anonymous" .

Folgende Befehle stehen nach der Verbindung u.a. zur Verfügung:
· open: Neue Verbindung zum Host
· close: Beendet die bestehende Verbindung
· user: Anmelden mit Username (nach fehlgeschlagener Anmeldung)
· dir, ls: Anzeigen des Verzeichnisinhaltes
· cd: Verzeichniswechsel
· pwd: Anzeige des aktuellen Verzeichnisses
· get: kopiert ein File vom FTP-Server (get remote_file_name local_file_name)
· put: kopiert ein File auf den FTP-Server
· quit: beendet FTP