Protokolle des Web

Dieser Text bietet einen sehr kompakten Überblick über die Protokolle, die Sie beherrschen sollten, wenn Sie aktiv Webanwendungen entwickeln. Die Informationen in diesem Kapitel sind grob in folgende Abschnitte unterteilt:

• Das OSI-Referenzmodell
• Netzwerkprotokolle wie TCP/IP, DNS und das
• Hypertext Transfer Protokoll (HTTP)
• Representational State Transfer (REST)

Das OSI-Referenzmodell

Für die Entwicklung und Bewertung von Kommunikationsprozessen wird in der IT-Welt häufig zum ISO/OSI-Referenzmodell Bezug genommen. Dieses Modell wurde im Jahre 1984 von der ISO (International Organization for Standardization) verabschiedet und beschreibt alle wesentlichen Prozesse bei der IT-gestützten Datenübertragung über ein Schichtenmodell. Komplett ausgeschrieben steht die Abkürzung ISO/OSI übrigens für Reference Model for Open Systems Interconnection of the International Organization for Standardization.

Die folgende Tabelle zeigt die sieben Schichten des ISO/OSI-Referenzmodells und ihre Bedeutungen.

Tabelle: Schichten des ISO/OSI-Referenzmodells

Nr.	Bezeichnung	Aufgabe bzw. Beispielanwendungen
7	Anwendung Nutzerschnittstelle	Programmschnittstelle
6	Darstellung	Kodierung und Dekodierung
5	Sitzung Kommunikationssteuerung
4	Transport Aufbau von Verbindungen	Datentransport
3	Vermittlung	Adressierung und Routing von Datenpaketen
2	Sicherung, Logical Link Control	Kontrollfunktionen, Datenfragmentierung
	MAC (Media Access Control)
1	Bitübertragung	Physikalischer Netzwerktransport (Kabel, Funk etc.)

Bei einem genau nach diesem Modell entwickelten Übertragungsverfahren arbeitet auf jeder Ebene genau eine Komponente beziehungsweise ein Netzwerkprotokoll. Zwischen zwei Computersystemen werden dann jeweils alle Schichten durchlaufen. Der eigentliche Datenaustausch findet schließlich nur über die Schicht 1, beispiels-weise das Netzwerkkabel, statt. Die einzelnen Schichten innerhalb eines Partners „kommunizieren“ damit jeweils nur mit den direkt darüber und darunter liegenden Nachbarn über die Protokolle und technischen Komponenten. Dadurch sind die höheren Schichten unabhängig von den Prozessen, die sich weiter unten abspielen. Ob die Schicht 1 technisch über ein Kupfer- oder ein Glasfaserkabel implementiert ist, ist für die Protokollschicht, die kontrolliert Datenpakete versenden will, irrelevant.

Das ISO/OSI-Referenzmodell ist ein wenig theoretisch und wird in der Praxis selten konsequent umgesetzt. Das beste Beispiel dafür ist die am meisten verbreitete Netzwerkprotokollfamilie TCP/IP. Die Entwicklung ist hier älter als die für das Referenzmodell, sodass sich die Protokolle der IPS (Internet Protocol Suite) nur teilweise darin abbilden lassen.

Die Internet-Protokollfamilie

Die IPS kann in vier Schichten eingeteilt werden, die allerdings ähnlich wie die des Referenzmodells strukturiert sind. Ab Schicht 2 übernehmen verschiedene Protokol-le jeweils spezifische Aufgaben. Diese werden in den nächsten Abschnitten noch näher vorgestellt.

{title=“Abbildung: Die Schichten der Internet-Protokollfamilie im Vergleich zum ISO/OSI-Referenzmodell“}

Standardisierung mit Hilfe von RFCs

Wenn Sie sich mit Protokollen und konkreten Implementierungen technischer Verfahren rund um die IPS beschäftigen, werden Sie immer wieder mit RFCs (Request for Comments) konfrontiert. Die RFCs dienen als öffentliches Diskussionsforum für technische und organisatorische Fragen des Internets. Sie wurden mit dem ARPA-NET im Jahre 1969 ins Leben gerufen. Die RFC 0001 wurde am 7. April 1969 veröffentlicht, noch während der laufenden Entwicklung des ARPANET.

RFCs werden fortlaufend nummeriert und können verschiedene Stufen durchlaufen. Es gibt keine Versionsnummern. Wird ein RFC umfassend weiterentwickelt, erscheint ein neues Dokument mit einer neuen Nummer. Das alte wird als obsolet gekennzeichnet. Werden aus RFCs Standards verabschiedet, so erscheinen diese in einer zweiten Dokumentform, die durch STD gekennzeichnet ist. Der Zusammenhang zwischen RFCs und STDs ist in RFC 2500 geregelt. Der Standardisierungsprozess wird in RFC 2026 erläutert.

Als gute Informationsquelle für RFCs ist die folgende Webseite zu empfehlen:

• http://www.rfc-editor.org/ „www.rfc-editor.org“

Hier können Sie in der RFC- und STD-Datenbank komfortabel stöbern. Wenn Sie nach tiefergehenden Informationen zu bestimmten Protokollen wie beispielsweise ICMP oder DNS suchen, tragen Sie diese in die Suchmaske ein.

{title=“Abbildung: Eine gute Informationsquelle ist der RFC-Editor“}

Amüsant kann das Studium von RFCs mit dem Erscheinungsdatum vom 1. April und dem Status INFORMATIONAL sein. Zu empfehlen ist hier beispielsweise RFC 2550, in welchem die Jahr 10.000-Problematik erörtert wird.

Wichtige Protokolle der Internet Protocol Suite

Nachfolgend werden die wichtigsten Protokolle der IPS vorgestellt. Die Reihenfolge entspricht dabei der im IPS-4-Schichtenmodell (siehe Abbildung 4.1).

Überblick

In der Abbildung 4.3 sind die nochmals die wichtigsten Protokolle und ihre Einord-nung in das TCP/IP Schichtenmodell sowie in das OSI-Schichtenmodell dargestellt.

{title=“Abbildung: Der IPS-Stack“}

Eine besondere Rolle kommt dabei dem ARP Protokoll zu. Da diese sich zwar rein technisch über dem DLCMAC (Ethernet) befindet, aber nicht zu Schicht 3 gehört, wird es oft auch als Schicht 2,5-Protokoll bezeichnet.

Address Resolution Protocol (ARP)

Über dieses Protokoll, welches auf einer sehr elementaren Ebene arbeitet, erfolgt die Zuordnung von IP-Adressen zu den physischen MAC-Adressen der Netzwerkadapter der beteiligten Kommunikations-Teilnehmer. MAC steht für Media Access Con-trol. MAC-Adressen sind stets weltweit eindeutig, sodass eine Verwechslung von Teilnehmern an dieser Stelle ausgeschlossen werden kann. Allerdings gibt es Netzwerkadapter, die das Eingeben einer benutzerdefinierten MAC-Adresse zulassen.

Die Informationen zu den MAC-Adressen der beteiligten Netzwerkcomputer wer-den bei Windows Server 2003/2008, wie bei anderen Betriebssystemen auch, in einem ARP-Cache gehalten. Damit müssen diese nicht immer wieder neu ermittelt werden. Den ARP-Cache können Sie über die Eingabeaufforderung mit dem Kommando Arp.exe und der Option –a anzeigen lassen:

arp -a

Haben Sie mehrere Netzwerkadapter in Ihrem Computersystem installiert, können Sie den ARP-Cache für einen bestimmten Adapter abfragen, indem Sie dessen IP-Adresse angeben:

arp –a 192.168.100.6

Welche und wie lange Daten in diesem Cache gehalten werden, können Sie anpas-sen. Dies ist in der Praxis allerdings kaum notwendig.
Eine genaue Syntaxbeschreibung zum Programm Arp.exe finden Sie in der Online-Hilfe zu Windows Server.

Internet Control Messaging Protocol (ICMP)

Dieses Protokoll dient vor allem zum Transport von Diagnose-, Kontroll- und Routingdatenpaketen im Netzwerk. Es befindet sich wie das Internet Protocol (IP) auf Schicht 2 des IPS-Schichtenmodells. ICMP wird beispielsweise vom Dienstpro-gramm Ping.exe benutzt, um Informationen von einem Host zu erfragen.

Internet Protocol (IP)

IP dient zum eigentlichen Transport der Nutzdaten im Netzwerk. Das Protokoll zeichnet sich durch diese Merkmale aus:

• IP-Adresse: Jeder Netzwerkknoten kann durch eine eindeutige Adresse, die IP-Adresse, direkt erreicht werden. Die Unterteilung zwischen dem Teilnetzwerk und der konkreten Hostadresse wird mit Hilfe von Subnetzmasken vorge-nommen.
• Keine Fehlerkorrektur: Über IP werden die Daten zwar transportiert, es erfolgt allerdings keine Fehlerkorrektur.
• IP-Fragmentierung: Datenpakete können bei Bedarf über IP in kleinere Einheiten zerlegt wer-den, wenn beteiligte Netzwerkgeräte auf bestimmte Paketgrößen limitiert sind.
• IP-Broadcast: Datenpakete können mit IP an einen ganz bestimmten Host geschickt werden, indem dessen IP-Adresse verwendet wird. Dies wird Unicast genannt. Über eine entsprechende Adressierung können aber mehrere Hosts auf einmal angesprochen werden. Dies wird mit Multicast bezeichnet und kommt dann zum Einsatz, wenn nicht sitzungsorientiert Daten ausge-tauscht werden. Das können beispielsweise UDP- oder ICMP-Datenpakete sein. Ein UDP-(Multimedia-) Datenstrom kann so an mehrere Empfänger gleichzeitig gesendet werden.
• IP-Routing: IP ist ein routingfähiges Protokoll. Das bedeutet, dass der IP-Datenstrom gezielt über IP-Router in voneinander sonst getrennte Teilnetzwerke geleitet werden kann.

I> Über eine Erweiterung von DHCP, die MADCAP (Multicast Address Dynamic Client Allocation Protocol) genannt wird, können dynamisch IP-Multicastadressen im Netzwerk zugewiesen und verwaltet werden.

Da IP zu den wichtigeren Protokollen im Web gehört, soll an dieser Stelle etwas genauer auf die Zusammensetzung des Kopfes (Headers) eingegangen werden.

{title=“IP-Header“}

IPV6 vs V4

Zwar ist das IP Protokoll in der Version 6 bereits seit langem spezifiziert, jedoch kommt es nur sehr schwer in Gang. Das mag zum Teil an den Providern und zum Teil an den Herstellern von IP-Equipment liegen. Aus diesem Grund steht IPv4 hier im Vordergrund.

• TOS

  Neben der Version wird die Länge des IP-Kopfes (IP Header Length – IHL) und der Diensttyp angegeben. Auf diese Weise können Geräte den Verkehr anhand der Art der Daten (Type of Service (TOS), eine Art der Priorisierung) priorisieren.

• Fragmentierung

  Ferner werden noch die gesamte Paketlänge sowie die Felder Identifikation (hilft bei der Erkennung von Fragmenten), Flags (gibt Auskunft, ob das Paket fragmentiert ist) und das FragmentationOffset für das Zusammensetzen frag-mentierter Pakete angegeben.

• Adressen

  Die wichtigsten zwei Felder stellen die Quelle (Source) sowie die Ziel (Destinati-on) der Adresse dar. Hier wird die IP Adresse byteweise als 32 Bit (= 4 Byte) Wert abgelegt.

• Options und Protocol

  Des Weiteren werden die Felder Options (Informationen für Router), Time To Live (Anzahl der Hops, über die ein Paket übermittelt wird), Protocol (welches Protokoll sich innerhalb des IP Paketes befindet, TCP = 6 oder UDP = 17) sowie eine Checksumme übermittelt, um Fehler im Kopf zu erkennen.

Eine Fehlerkorrektur ist im IP selbst nicht vorgesehen. Diese muss über ein Protokoll erfolgen, welches eine Schicht darüber angesiedelt ist. Dies ist beispielsweise das Transmission Control Protocol (TCP). TCP-Datenpakete werden dazu in IP-Pakete „verpackt“. Am Zielsystem erfolgt die Überprüfung der TCP-Pakete. Bei Fehlern können damit die Daten erneut angefordert werden. Aus diesem Grund spricht man bei IP auch von einem Transportprotokoll, wogegen TCP ein Absicherungsprotokoll ist.

{title=“IP-Fragmentierung“}

• MTU
  : Die maximale IP-Paketgröße wird mit Maximum Transmission Unit (MTU) be-zeichnet. Ist die Paketgröße kleiner oder gleich der MTU, muss das Paket nicht zerlegt, sondern fragmentiert werden. Fragmentierte IP-Pakete sind durch ein gesetztes Flag gekennzeichnet und werden über eine entsprechende Nummerierung am Zielsystem wieder zusammengesetzt. Allerdings birgt die IP-Fragmentierung ein potenzielles Sicherheitsrisiko. Geschickte Hacker können beispielsweise IP-Fragmente so bilden, dass sie beim Zusammensetzen das Zielsystem zum Absturz bringen. Deshalb werden IP-Fragmente durch moderne Firewalls in der Standardeinstellung abgewiesen. Die IP-Fragmentierung wird heute meist durch das Verfahren Path MTU Discovery vermieden. Dabei handeln die beteiligten Systeme die MTU-Größe untereinander aus.

Transmission Control Protocol (TCP)

TCP ist eine Schicht über IP angesiedelt und verfügt gegenüber diesem über einen wirksamen Mechanismus zur Fehlerkorrektur. Neben einer Nummerierung der Da-tenpakete werden Prüfsummen generiert, mit deren Hilfe die Integrität der Daten sichergestellt wird. Wird ein Fehler erkannt, erfolgt automatisch eine Anforderung des bzw. der defekten Datenpakete, das Gleiche gilt für den Fall, dass ein Paket bis zum Ablauf einer bestimmten Zeit nicht eingetroffen ist. Auch diese Daten werden neu angefordert.

Da jede Leitung unterschiedliche qualitative Eigenschaften hat, kann TCP die Pa-rameter, wann ein Paket zu wiederholen ist, dynamisch anpassen. Auf diese Weise wird immer eine optimale Performance garantiert.

{title=“Abbildung: TCP-Header“}

Port

Zusätzlich zu den IP-Quell und Zieladressen verwendet TCP sogenannte Portnum-mern. Diese ergeben zusammen mit den IP-Adressen eine eindeutige Verbindung. Jeder Dienst bekommt einen Port zugewiesen, auf dem dieser eingehende Verbin-dungen entgegennimmt. Da viele Standarddienste immer die gleichen Ports ver-wenden, werden Ports oft nach den jeweiligen Diensten benannt. Beispiele:

• Port 23: Telnet
• Port 80: HTTP
• Port 21: FTP

Datenstrom

TCP ist ein Datenstrom-Protokoll (stream oriented), man spricht auch von einem verbindungsorientierten Protokoll. Das bedeutet, es werden zwar einzelne Datenpakete gesendet, jedoch gibt eine Verbindung, welche vor der Datenübertragung auf-gebaut und danach wieder abgebaut wird, ganz im Gegenteil zu UDP.

• Sequence Number
  : Die Sequence Number ist eine fortlaufende Nummer, welche ein Paket in dem Datenstrom kennzeichnet. Mit ihrer Hilfe können Pakete, welche in der falschen Rei-henfolge eintreffen, wieder sortiert werden.
• Acknowledge Number
  : Die Acknowledge Number wird verwendet, um der Gegenstelle mitzuteilen, bis zum wievielten Datenpaket alle Daten erfolgreich eingetroffen sind. Auf diese Weise kann indirekt eine Neuübertragung ausgelöst werden, wenn beispielsweise nur bis zum vorletzten Paket bestätigt wurde. Der Sender wartet noch, ob das Paket etwas verspätet bestätigt wird (Timeout). Ist das nicht der Fall, werden in der Regel alle Pakete ab dem nicht empfangenen Pakt nochmals übertragen.
• Window
  : Window ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgment-Feld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen.

Auf weitere Felder soll in diesem Zusammenhang nicht weiter eingegangen werden, da sich mit diesem Thema allein ein Buch füllen ließe. Das TCP-Protokoll ist das meistgenutzte dieser Schicht und dient zum verbindungsorientierten Datentransfer zwischen zwei Hosts.

User Datagram Protocol (UDP)

Dieses Protokoll ist der „engste Verwandte“ von TCP. Es unterscheidet sich allerdings in wichtigen Parametern grundlegend und dient damit anderen Zwecken. So ist keine Fehlerkorrektur implementiert. Dies ist nicht für alle Arten von Datentransfers notwendig. Multimedia-Streams werden beispielsweise meist mit UDP übertra-gen, da es hier vor allem auf eine hohe Performance ankommt. Wenn bei bewegten Bildern einige Frames fehlen, fällt dies nicht unbedingt ins Gewicht. Wichtiger ist dann, dass die Information selbst übertragen wird, also der Inhalt des Films beim Empfänger ankommt. Andauerndes Stocken bei der Übertragung, weil fehlerhafte oder unvollständige Daten neu übertragen werden müssen, stören da mehr.

Multimedia und VoIP

UDP kommt standardmäßig bei der Abfrage von DNS-Informationen zum Einsatz. Hier bringt das Protokoll bei den zahlreichen kleinen Datenpaketen, die einen DNS-Server ständig erreichen, einen Performance-Vorteil. Weitere Anwendungen für dieses Protokoll sind Routingprotokolle wie RIP (Routing Information Protocol), TFTP (Trivial File Transfer Protocol) oder SNMP (Simple Network Management Protocol). Aber auch bei Multimedia und anderen Streaming Anwendungen wie VoIP kommt UDP zum Einsatz.

Zu beachten ist, dass UDP aufgrund der fehlenden Flusskontrolle und Fehlerkorrektur als nicht sehr sicheres Protokoll gilt. Deshalb ist es ein beliebtes Protokoll für Hacker, die beispielsweise mit Denial of Service-Attacken immer wieder von sich reden gemacht haben. Dabei werden Hosts mit einer Unmenge von UDP-Paketen überflutet, was zu deren Überforderung und damit der zeitweisen Lahmlegung führt.

Simple Mail Transfer Protocol (SMTP) / Extended SMTP (ESMTP)

SMTP kommt sogar an Clientsystemen für das Versenden sowie bei Mailservern zum Senden und Weiterleiten von E-Mails zum Einsatz. Inzwischen hat sich der ESMTP-Standard durchgesetzt. Dieser ist in RFC 2821 spezifiziert und bietet erweiterte Funktionen zur Kommunikation zwischen SMTP-Client und -Server.

Wie viele Protokolle im Web-Umfeld ist auch diese Protokoll ASCII-Text basiert. Alle Nachrichten, welche vom Client zum Server gesendet werden, können dabei sowohl vom Menschen als auch von der Software interpretiert werden.

Session Initiation Protocol (SIP)

VoIP (Voice over IP) nimmer immer mehr an Bedeutung zu. Auch wenn dieses Buch nicht über Multimedia und Telefonie handelt, darf dieses Protokoll in der Aufzählung der wichtigsten Internetprotokolle nicht fehlen. Wie der Name schon zum Ausdruck bringt, wird dieses Protokoll zum Aufbau und der Steuerung von Kommunikationssession aller Art verwendet. Weitere Informationen finden Sie im RFC 3261.

Die Hochsprachenprotokolle

Die Hochsprachenprotokolle arbeiten auf Schicht 7 des Referenzmodells. Sie sind in der Regel textbasiert und übermitteln einfache Kommandos. Für die Arbeit mit ASP.NET ist das Hypertext Transfer Protocol HTTP ausnahmslos das Wichtigste. Sie finden eine ausführliche Darstellung in diesem Abschnitt. Wichtig sind daneben auch das File Transfer Protocol FTP, das Network News Transfer Protocol NNTP und das Simple Mail Transfer Protocol SMTP, die kurz im Überblick vorgestellt werden.

File Transfer Protocol (FTP)

Neben HTTP ist dieses Protokoll das Wichtigste beim tagtäglichen Einsatz im Inter-net. Es dient dem Datenaustausch zwischen FTP-Server und –Client, wobei der Client sogar auf eine genau definierte Art und Weise Zugriff auf das Dateisystem des Servers erhalten kann.
Für den Zugriff auf einen FTP-Server bieten alle modernen Windows-Betriebssysteme zwei verschiedene Arten von Clients: Das einfache Programm Ftp.exe dient zur Kommunikation über die Eingabeaufforderung. Als grafischer FTP-Client kann der in das Betriebssystem integrierte Internet Explorer genutzt werden. Darüber hinaus gibt es noch jede Menge Freeware und kommerzielle Clien-tprogramme.

Network News Transfer Protocol (NNTP)

Dieses Protokoll dient zum Nachrichtenaustausch zwischen sogenannten News-Servern und entsprechenden Clients. Es ist historisch gesehen eines der ältesten Protokolle, welches noch weit vor dem Einzug des Internets in den Alltag genutzt wurde. Das Protokoll arbeitet, anders als HTTP, nicht statuslos, sondern führt einen Message Pointer. Für die Kommunikation mit einem News-Server ist eine Anmeldung erforderlich.

Das Protokoll gilt inzwischen als veraltet. Nachrichtengruppen werden zunehmen durch Web-basierte Foren verdrängt, die mehr Gestaltungsspielraum ermöglichen.

Hypertext Transfer Protocol (HTTP)

In diesem Abschnitt erfahren Sie das Wichtigste über HTTP, das in der Webserver-Programmierung die herausragende Rolle spielt.

HTTP dient der Kommunikation mit Webservern. Es gibt die Versionen, 1.0, 1.1 und 2.0. Auf Seiten der Browser wird HTTP 1.1 gesprochen. Die Version 2.0 befindet sich heute (2015) in der Einführungsphase.

HTTP 1.0 wurde im Mai 1996 in der RFC 1945 veröffentlicht, schon im August desselben Jahres folgte HTTP 1.1.

Bei HTTP handelt es sich um ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand ein, sondern beenden nach jedem Kommando den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren.

Protokollaufbau, Header, Body

HTTP-Kommandos werden als ASCII-Text übertragen und können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Kommandozeile. Daran angehängt kann ein sogenannter Message-Header (Kopf der Nachricht) folgen. Der Nachrich-tenkopf enthält weitere Parameter, die das Kommando näher beschreiben. So kann ein Content-Length-Feld enthalten sein. Steht dort ein Wert größer als 0, folgen dem Nachrichtenkopf Daten. Die Daten werden also gleich zusammen mit dem Kom-mando gesendet, man spricht dann vom Body (Nachrichtenkörper) der Nachricht. HTTP versteht im Gegensatz zu anderen Protokollen den Umgang mit 8-Bit-Werten. Binärdaten, wie Bilder oder Sounds, müssen nicht konvertiert werden. Fol-gen dem HTTP-Kommando und den Nachrichtenkopf-Zeilen zwei Leerzeilen (Zei-lenwechsel), so gilt das Kommando als beendet. Kommandos mit Nachrichtenkör-per haben kein spezielles Ende-Zeichen. Das Content-Length-Feld bestimmt, wie viele Bytes als Inhalt der Nachricht betrachtet werden.

Kommandoaufbau

Ein HTTP-Kommando hat immer folgenden Aufbau:

METHODE ID VERSION

Als METHODE wird das Kommando selbst bezeichnet. Die folgende Tabelle zeigt die HTTP-Kommandos auf einen Blick.

{title=“Tabelle: HTTP-Kommandos“}

Kommando	Bedeutung
DELETE	Ressource löschen
GET	Ressource anfordern
HEAD	Header der Ressource anfordern
LINK	Verknüpfung zweier Ressourcen beantragen
OPTIONS	Optionen des Webservers erfragen
POST	Formulardaten an einen Serverprozess senden
PUT	Ressource auf dem Webserver ablegen
TRACE	Kommando zurückschicken lassen
UNLINK	Verknüpfung zwischen Ressourcen löschen

Beachten Sie, dass die Kommandos unbedingt in Großbuchstaben geschrieben werden müssen, exakt wie in der Tabelle oben gezeigt. Als Ressource werden all die Objekte bezeichnet, die übertragen werden können –- in erster Linie also HTML-Dateien und Bilder.

Die ID einer Ressource kann beispielsweise eine Adresse oder ein Dateiname sein:

GET index.htm HTTP/1.0

Dieses Kommando fordert die Datei INDEX.HTM an.

Die HTTP-Statuscodes

Die Antwort auf ein Kommando besteht im Senden der Daten – wenn dies gefordert wurde – und einem Statuscode. Dem Statuscode folgen optionale Felder und, bei der Übertragung von Ressourcen, die Daten. Die Statuszeile hat folgenden Aufbau:

VERSION STATUSCODE STATUSTEXT

Der Statuscode ist eine dreistellige Zahl, von der die erste Ziffer (Hunderterstelle) die Zuordnung zu einer bestimmten Gruppe anzeigt.

Gruppe	Code	Name	Bedeutung
1	100	Continue	Weiter fortfahren
1	101	Switching	Protocols Protokollwechsel erforderlich, z.B.
			von HTTP auf WebSockets
1	102	Processing	Server bearbeitet die Anfrage, verhindert ggf.
			Timeout bei längere Verarbeitungszeit
2	200	OK	Kommando erfolgreich (nach GET/POST)
2	201	Created	Ressource wurde erstellt (nach PUT)
2	202	Accepted	Authentifizierung akzeptiert (nach GET)
2	204	No Content	Kein Inhalt oder nicht angefordert (GET)
3	301	Moved Permanently	Ressource am anderen Ort
3	302	Found Ressource	zeitweilig an anderem Ort
			(dies ist ein temporärer Zustand)
3	304	Not Modified	Ressource wurde nicht verändert (steuert Proxy)
4	400	Bad Request	Syntaxfehler (alle Kommandos)
4	401	Unauthorized	Keine Autorisierung
4	403	Forbidden	Nicht öffentlicher Bereich, Anfrage unzulässig
4	404	Not Found	Ressource nicht gefunden
5	500	Server Error	Serverfehler, Fehlfunktion der
			Serversoftware oder -applikation
5	503	Service Unavailable	Dienst nicht verfügbar

Sie werden den Fehler 404 sicher kennen. Kennenlernen werden Sie auch den Fehler Nummer 500, der erzeugt wird, wenn ein Programm nicht funktioniert, das Sie in Node geschrieben haben.

Sie können viele Status in Node selbst erzeugen und nutzen und damit Clients die Kommunikation erleichtern. Allerdings können zu detaillierte Fehlermeldungen auch eine Sicherheitslücke sein, da Interna offenbahrt werden. Bei Debuggen sind Details sinnvoll, in der Produktion reagieren die meisten Server mit einem difussen 400 Bad Request, um Angreifern keine Angriffsfläche zu bieten.

An ein Kommando oder an die Statuszeile können weitere Felder angehängt werden. Der Aufbau lehnt an den MIME-Standard an:

Feldname: Wert; Wert

MIME steht für Multipurpose Internet Mail Extension und definiert, wie bestimmte Dateiarten über Internet übertragen werden können. MIME wird nicht nur mit E-Mail, sondern unter anderem in Verbindung mit dem HTTP-Protokoll eingesetzt. Mehr dazu im Abschnitt MIME im Zusammenhang mit REST.

Die Nachrichtenkopffelder können in drei Hauptgruppen aufgeteilt werden:

* F

Frage-Felder (Request-Header-Fields), die nur in Kommandos erlaubt sind.
* A

Antwort-Felder (Response-Header-Fields), die Statusnachrichten vorbehal-ten sind.
* I

Informationsfelder (General-Header-Fields), dienen der Übertragung aller anderen Nachrichten in die eine oder andere Richtung.

Eine typische Anwendung, die bei der Node-Programmierung auftreten kann, ist die Übergabe eines Nachrichtenkopfes, der einen besonderen Dateityp angibt:

Content-Type: application/pdf; name=aspnet.pdf

Im Gegensatz zu anderen Protokollen ist die Länge eines Datenblocks im Contentlength festgelegt, irgendwelche Begrenzungszeichen gibt es nicht. Wichtig ist auch, dass der Server nach dem Verbindungsaufbau keine Antwort sendet. Nur das erste eintreffende Kommando löst eine Reaktion aus. Darin ist die Ursache zu sehen, wenn der Browser nach der Anforderung eines unerreichbaren Servers lange Zeit nicht reagiert. Als „Totsignal“ wird einfach eine vorgegebene Zeitspanne gewartet, in welcher der Server auf das erste Kommando reagieren sollte.

Verbindungsablauf

Eine einfache HTTP-Verbindung könnte also folgendermaßen aussehen:

{title=“Listing: Ablauf einer einfachen HTTP-Verbindung“}

Client: (Verbindungsaufbau des Browsers durch Nameserver, TCP/IP)
Server: (keine Antwort)
Client: GET /default.aspx HTTP/1.0
Server: HTTP/1.0 200 OK
        Date: Mon, 04 Mar 2015 12:23:55 GMT+100 Server: 
        Node... XXX
        Content-Type: text/html
        Last-Modified: Mon, 04 Mar 2015 12:23:55
        Content-Length: 1465

        <html>
        <head>
        ... Daten entsprechend der Längenangabe

Der Ablauf ist also recht simpel. Praktisch wird in diesem Beispiel eine Datei mit dem Namen default.aspx angefordert. Die Webapplikation startet dann, führt den Code in der Seite aus, produziert den Inhalt der Seite und gibt ihn zusammen mit den richtigen Headern an den Webserver. Dieser setzt den Code 200 davor und sendet alles an den Browser. Das der Benutzer dann mit den Daten etwas anfangen kann, dafür sind Sie verantwortlich. Den Rest können Sie vorerst Node überlassen. Profis wissen natürlich, dass sich hier trickreich eingreifen lässt. Im Normalfall ist das aber nicht notwendig.