EinNetzwerkprotokoll/Netzprotokoll ist eine exakte Vereinbarung, nach der Datenzwischen Computern bzw. Prozessen ausgetauscht werden, die durch ein Netzmiteinander verbunden sind (verteiltes System). Die Vereinbarung besteht auseinem Satz von Regeln und Formaten (Syntax), die das Kommunikationsverhaltender kommunizierenden Instanzen in den Computern bestimmen (Semantik).

Der Austauschvon Nachrichten erfordert häufig ein Zusammenspiel verschiedener Protokolle,die unterschiedliche Aufgaben übernehmen (beispielsweise TCP/IP Suite). Um diedamit verbundene Komplexität beherrschen zu können, werden die einzelnenProtokolle in Schichten organisiert. Im Rahmen einer solchen Architektur gehörtjedes Protokoll einer bestimmten Schicht an und ist für die Erledigung derspeziellen Aufgaben zuständig (beispielsweise Überprüfen der Daten aufVollständigkeit – Schicht 2). Protokolle höherer Schichten verwenden Dienstevon Protokollen tieferer Schichten (Schicht 3 verlässt sich z. B. darauf, dassdie Daten vollständig angekommen sind). Zusammen bilden die so strukturierten Protokolleeinen Protokollstapel – in Anlehnung an das ISO-OSI-Referenzmodell (siehe auchDoD-Schichtenmodell). Nachrichten einer bestimmten Schicht werden auch alsProtokolldateneinheiten (protocol data units) bezeichnet. Unter dem OberbegriffTCP/IP sind rund 500(!) Protokolle zusammengefasst. TCP/IP steht im allgemeinenSprachgebrauch für das Protokoll beim Datenaustausch zwischen verschiedenenRechnern.

Der in einemProtokoll beschriebene Aufbau eines Datenpakets enthält für den Datenaustauschwichtige Informationen über das Paket wie beispielsweise:

dessen Absender und Empfänger
den Typ des Pakets (z. B. Verbindungsaufbau, Verbindungsabbau oder reine Nutzdaten)
die Paketlänge
eine Prüfsumme
Diese Informationen werden den Nutzdaten als so genannter Header vorangestellt oder als Trailer angehängt.

Außerdem werden in einem Protokoll feste Paketsequenzen für den Verbindungsaufbau und -abbau beschrieben. Diese Maßnahmen verursachen weiteren Datenverkehr (Traffic) auf den Datenleitungen – den sog. Overhead. Dieser Overhead ist unerwünscht, weil er die Kapazität belastet, wird aber aufgrund der wichtigen Aufgaben, die Protokolle leisten, in der Regel in Kauf genommen. Mit User Datagram Protocol (UDP) steht in der Transportschicht auch ein Protokoll mit nur minimalem Overhead zur Verfügung, das keine Ende-zu-Ende-Kontrolle der Übertragung gewährleistet.

Anzahl von Parteien, die an der Kommunikation teilnehmen: Gibt es für eine Übermittlung immer nur einen Empfänger, spricht man von Unicast, bei Übertragungen an mehrere Teilnehmer von Multicast.
Findet die Kommunikation nur in eine Richtung statt, spricht man von Simplex, fließen die Daten wechselweise in beide Richtungen, von Halb-Duplex oder gleichzeitig in beide Richtungen, von Vollduplex.
Stellung der Kommunikationsteilnehmer: Sind diese untereinander gleichberechtigt, spricht man von Peer-to-Peer oder symmetrischer anderenfalls von asymmetrischer Kommunikation. Das am weitesten verbreitete asymmetrische Modell ist das Client-Server-System, bei dem ein Dienstanbieter (der Server) Anfragen von verschiedenen Clients bearbeitet (wobei es immer die Clients sind, die die Kommunikation initiieren, d. h. einen Kanal öffnen).
Wird nach einer Anfrage auf Antwort gewartet, spricht man von synchroner Kommunikation, sonst von asynchroner Kommunikation.
Während einer paketorientierten Kommunikation werden Nachrichten bzw. Datenpakete übertragen, beim Streaming wird mit einem kontinuierlichen Datenstrom einzelner Zeichen gearbeitet

Ein sicherer Verbindungsaufbau zwischen den an der Kommunikation beteiligten Computern (Handshake)
Das verlässliche Zustellen von Paketen
Wiederholen nicht angekommener Pakete
Zustellen der Datenpakete an den/die gewünschten Empfänger
Das Sicherstellen einer fehlerfreien Übertragung (Prüfsumme)
Das Zusammenfügen ankommender Datenpakete in der richtigen Reihenfolge
Das Verhindern eines Eingriffs unbefugter Dritter (durch Verschlüsselung)
Ein zuverlässiger Verbindungsabbau

Funktionsbeispiel
Anhand des Verbindungsaufbau-Prozederes des TCP-Protokolls soll ein einfaches praktisches Beispiel gezeigt werden. (siehe auch Handshake-Verfahren)

Zunächst schickt Computer 1 ein Paket, in dem steht, dass er eine Verbindung zu Computer 2 aufbauen möchte.
Darauf antwortet Computer 2, dass er dazu bereit ist.
Computer 1 bestätigt anschließend Computer 2, dass er verstanden hat, dass Computer 2 bereit ist.
Die Verbindung ist damit hergestellt, und der eigentliche Datenaustausch kann beginnen.

Die bekannteste Nutzung von Protokollen findet rund um das Internet statt, hier sorgen sie für (Anwendung - (Protokollbezeichnung)):

Das Laden von Web-Seiten – (HTTP)
Verschicken von E-Mails – (SMTP)
Herunterladen von Dateien – (FTP oder HTTP)
Diese Funktionen bauen zum Teil aufeinander auf. So löst beispielsweise das Protokoll TCP das Problem der Datenübertragung. Das Protokoll SMTP zum Übermitteln von E-Mails benötigt wiederum die Funktion, Daten zu versenden und setzt dazu auf das TCP auf.

Dieses schichtweise Aufeinanderaufbauen der Protokolle wird mit Hilfe des OSI-Modells dargestellt.

Im Jahr 1968 wurden auf Veranlassung des amerikanischen Verteidigungsministeriums (DoD) Versuche durchgeführt, mit denen grundlegende Erkenntnisse über die Funktionsweise von Rechnernetzen gewonnen werden sollten. Als praktisches Ergebnis wurde 1969 das ARPANET-Projekt aufgelegt. Hier wurden für die Kommunikationsverwaltung zusätzliche Rechner bei den clients des Netzes eingerichtet. Das ARPANET wurde 1972 in der Öffentlichkeit vorgestellt und in den Folgejahren stetig weiter ausgebaut, UNIX 6 kam auf den Netzknoten zum Einsatz. Ab 1983 hatten sich die TCP/IP-Protokolle durchgesetzt. Aus dem ARPANET wurde für militärische Belange ein separates Netz abgeteilt, das MILNET. Mit TCP/IP etablierte sich ein Standard zuverlässiger und leistungsfähiger Datenübertragung. Die massenhafte kommerzielle Verwertung begann.

Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem World Wide Web (WWW) in einen Webbrowser zu laden.

Datenübertragung in Netzwerken ist ein komplexes Problem. Um dieses zu lösen, unterteilt man es in mehrere triviale Probleme und bildet diese in Schichtenmodellen ab. Jede Schicht ist für die Lösung eines solchen trivialen Problems verantwortlich und bietet diese der darüberliegenden Schicht als Dienstleistung an. Das HTTP bildet die sogenannte Anwendungsschicht, über der die Modelle keine weiteren Schichten vorsehen. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall des HTTP ist dies meistens der Webbrowser. Im (heute kaum noch in der Praxis anzutreffenden) ISO/OSI-Schichtenmodell entspricht die Anwendungsschicht Schicht 7. Das im Internet angewendete TCP/IP-Referenzmodell sieht die Anwendungsschicht in Schicht 4.

HTTP ist ein zustandsloses Protokoll. Das bedeutet, dass nach erfolgreicher Datenübertragung die Verbindung zwischen den beiden Kommunikationspartnern nicht aufrecht erhalten wird. Sollen weitere Daten übertragen werden, muss zunächst eine weitere Verbindung aufgebaut werden.

Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Fehlercodes ist das HTTP allerdings nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet. Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen. In nahezu allen Fällen wird hierfür TCP verwendet.

Das Protokoll wurde 1989 von Tim Berners-Lee am CERN zusammen mit dem URL und der HTML erfunden, wodurch praktisch das World Wide Web (WWW) geboren wurde.

HTTP ist ein Kommunikationsschema, um Webseiten (oder Bilder oder prinzipiell jede andere beliebige Datei) von einem entfernten Computer auf den eigenen zu übertragen. Wenn auf einer Webseite der Link zur URL https://www.example.net/infotext.html aktiviert wird, so wird an den Computer mit dem Namen www.example.net die Anfrage gerichtet, die Datei infotext.html zurückzusenden. Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse umgesetzt. Zur Übertragung wird über das TCP-Protokoll auf Port 80 eine HTTP-GET-Anforderung gesendet.

Anfrage:

GET /infotext.html HTTP/1.1
Host: www.example.net
Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc. können über einen Header (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden. Sobald der Header mit einer Leerzeile abgeschlossen wird, sendet dann der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Diese besteht aus Header-Informationen des Servers, einer Leerzeile und dem Inhalt der Datei infotext.html. Die Datei ist normalerweise im Hypertext-Format HTML, das vom Browser in eine lesbare Darstellung gebracht wird. Es kann jedoch jede andere Datei in jedem beliebigen Format sein, zum Beispiel Bildinformationen, Audio- und Videodaten. Die Information kann auch dynamisch generiert werden und braucht auf dem Server nicht als Datei abgelegt zu sein.

Antwort:

HTTP/1.1 200 OK
Server: Apache/1.3.29 (Unix) PHP/4.3.4
Content-Length: (Größe von infotext.html in Byte)
Content-Language: de
Content-Type: text/html
Connection: close
 
(Inhalt von infotext.html)
Der Server sendet eine Fehlermeldung zurück, wenn die Information aus irgendeinem Grund nicht gesendet werden kann. Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt.

Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1 verwendet.

Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen. In der Version 1.1 können mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Da die Geschwindigkeit von TCP-Verbindungen zu Beginn auf Grund des Slow-Start-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Downloads fortgesetzt werden. Informationen aus früheren Anforderungen gehen verloren (zustandsloses Protokoll). Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können. Dadurch können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern, die im Netzwerk durchlaufen werden, gelesen werden. Über HTTPS kann die Übertragung verschlüsselt erfolgen.

Die Kommunikation der beteiligten Rechner kann mit Werkzeugen zur Netzwerkanalyse (zum Beispiel Ethereal) anschaulich nachvollzogen werden.

Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des MIME-Typs multipart/replace, bei dem der Browser nach Sendung eines Boundary-Codes und einem neuerlichen Content-Length-Header sowie eines neuen Content-Type-Headers den Inhalt des Browserfensters komplett erneuert.

Mit HTTP/1.1 ist es neben dem Holen von Daten auch möglich, Daten zum Server zu übertragen. Mithilfe der PUT-Methode können so Webdesigner ihre Seiten direkt über den Webserver per WebDAV publizieren, und mit der DELETE-Methode ist es ihnen möglich, Daten vom Server zu löschen.

Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der man den Weg zum Webserver verfolgen kann und überprüfen kann, ob die Daten korrekt dorthin übertragen werden. Mithilfe dieser Methode ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.

GET ist die gebräuchliste Methode. Mit ihr werden Inhalte vom Server angefordert.
POST ähnelt der GET-Methode, nur daß ein zusätzlicher Datenblock übermittelt wird. Dieser besteht üblicherweise aus Name/Wert-Paaren, die aus einem HTML-Formular stammen. Grundsätzlich können Daten auch mittels GET übertragen werden (als Parameter im URI), aber die zulässige Datenmenge ist bei POST deutlich größer.
HEAD weist den Server an, die gleichen HTTP-Header wie ein GET oder POST, nicht jedoch das Dokument selbst senden. So kann z.B. schnell die Gültigkeit einer Datei im Browsercache geprüft werden.
PUT dient dazu, Dateien unter Angabe des Ziel-URIs auf einen Webserver hochzuladen. Kaum implementiert.
DELETE löscht die angegebene Datei auf dem Server. Kaum implementiert.
TRACE liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist – sinnvoll für das Debugging von Verbindungen.
OPTIONS liefert eine Liste der vom Server unterstützen Methoden und Features.
CONNECT wird von Proxy-Servern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.

1xx: Informationen
100: Continue
101: Switching Protocols
2xx: Erfolgreiche Operation
200: OK
201: Created
202: Accepted
203: Non-Authoritative Information
204: No Content
205: Reset Content
206: Partial Content
3xx: Umleitung
300: Multiple Choices
301: Moved Permanently
302: Found
303: See Other
304: Not Modified
305: Use Proxy
307: Temporary Redirect
4xx: Client-Fehler
400: Bad Request
401: Unauthorized
402: Payment Required (in HTTP/1.1 noch nicht spezifiziert)
403: Forbidden
404: Not Found
405: Method Not Allowed
406: Not Acceptable
407: Proxy Authentication Required
408: Request Time-out
409: Conflict
410: Gone
411: Length Required
412: Precondition Failed
413: Request Entity Too Large
414: Request-URI Too Large
415: Unsupported Media Type
416: Requested range not satisfiable
417: Expectation Failed
5xx: Server-Fehler
500: Internal Server Error
501: Not Implemented
502: Bad Gateway
503: Service Unavailable
504: Gateway Time-out
505: HTTP Version not supported

Es gibt mehrere Möglichkeiten, Benutzer (Clients) zu authentifizieren, verbreitet sind:

Basic Authentication (RFC 2617)
Digest Access Authentication (ebenfalls RFC 2617)
NTLM HTTP Authentication (in Intranets mit Windows-Servern)

Siehe auch
HTTPS
SOAP
HTML, XML
WebDAV
Zeichenkodierung

Die Abkürzung SMTP steht für Simple Mail Transfer Protocol (Einfaches E-Mail-Übertragungsverfahren). SMTP ist ein Protokoll der TCP/IP-Protokollfamilie, das den Versand von E-Mails in Computer-Netzwerken regelt. Ein SMTP-Server belegt in der Regel den von der IANA dafür registrierten Port 25.

Ein Benutzer wird zumeist vom Ablauf des SMTP-Protokolls nichts mitbekommen, da dies sein Mailprogramm im Hintergrund für ihn erledigt. Dieses Programm verbindet sich zu einem SMTP-Server (Mail Transfer Agent, MTA), der die Mail zum Empfänger weiterleitet.

SMTP setzt voraus, dass eine Übertragung vom Sender initiiert wird. Deshalb wird es nicht dazu benutzt, eine Mail von einem Server auf den Arbeitsplatzrechner zu übertragen. Dazu werden Post Office Protokolle wie das POP3-Protokoll, das IMAP-Protokoll oder andere verwendet.

Eine typische SMTP-Sitzung zum Versenden einer E-Mail sieht folgendermaßen aus:

> 220 mail.example.com SMTP Foo Mailserver
< HELO mail.example.org
> 250 Ok
< MAIL FROM:<hans.muster@example.org>
> 250 Ok
< RCPT TO:<foo@example.com>
> 250 Ok
< DATA
> 354 End data with <CR><LF>.<CR><LF>
< From: <hans.muster@example.org>
< To: <foo@example.com>
< Subject: Testmail
<
< Testmail
< .
> 250 Ok
< QUIT
> 221 Bye

Da SMTP ein sehr einfaches Protokoll ist, kann man unter den gängigen Betriebssystemen mit dem Kommandozeilen-Programm telnet selbst eine E-Mail von Hand verschicken. Absender- und Empfängeradresse sind frei wählbar – es können sich sogar die Adressen im MAIL FROM- und RCPT TO-Kommando (sog. Envelope-From bzw. Envelope-To) von den Adressen im From:- und To:-Mailheader unterscheiden.

Als SMTP 1982 in RFC 821 definiert wurde, gab es eine überschaubare Anzahl von Hosts im Internet. Da die Verbindungen langsam und instabil waren, wurde auf Zuverlässigkeit großen Wert gelegt. Authentifizierung war nicht vorgesehen, somit war jeder Mailserver ein Open Relay.

Mit der wachsenden Popularität des Internets entstand so das Problem des Spams.

1995 wurde mit Extended SMTP (ESMTP) in RFC 1869 das Protokoll erweitert. Diese Erweiterung erlaubt, dass über ein modulares Konzept weitere Befehle (SMTP-Verben) definiert werden. Wenn der Sender sich beim Server nicht wie oben gezeigt mit HELO, sondern mit EHLO (Extended HELO) meldet, teilt der Server ihm im Gegenzug mit, welche Erweiterungen des Protokolls er unterstützt. Gängige Beispiele hierfür sind STARTTLS (Secure SMTP over TLS), 8BITMIME (8bit-MIMEtransport), DSN (Delivery Status Notifications) und AUTH (SMTP-Auth).

Zwei „umstrittene“ Vorschläge für SMTP ergänzende Protokolle zur Identifizierung und Reputationsklassifizierung der Domain des absendenden Mailservers sind SPF (Sender Policy Framework, ehemals Sender Permitted From) von einer Gruppe verschiedener Firmen und Einzelpersonen und SMTPi (SMTP Identity) von der Firma IronPort.

Merkmal Definition Konzepte
Zugangskontrolle Nur zugelassene Benutzer dürfen den Mailserver benutzen SMTP-After-POP, SMTP-Auth
Echtheitsprüfung Eine eindeutige Zuordung Absender <-> Nachricht ist möglich PGP, S/MIME (siehe Elektronische Unterschrift), SPF
Integrität Die Nachricht kann auf dem Weg durchs Netz nicht unbemerkt verändert werden PGP, S/MIME
Vertraulichkeit Die Nachricht wird nicht im Klartext übertragen, sondern verschlüsselt PGP, S/MIME, SSL/TLS

RFC 821 (SMTP, Standard)
RFC 2821 (SMTP, Proposed Standard)
RFC 1652 (SMTP Service Extension for 8bit-MIMEtransport)
RFC 1891 (SMTP Service Extension for Delivery Status Notifications)
RFC 1845 (SMTP Service Extension for Checkpoint/Restart)
RFC 1869 (SMTP Service Extensions, ESMTP)
RFC 1870 (SMTP Service Extension for Message Size Declaration)
RFC 1893 (Enhanced Mail System Status Codes)
RFC 2487 (SMTP Service Extension for Secure SMTP over TLS)
RFC 2505 (Anti-Spam Recommendations for SMTP MTAs)
RFC 2554 (SMTP Service Extension for Authentication)
RFC 2920 (SMTP Service Extension for Command Pipelining)
RFC 3030 (SMTP Service Extensions for Transmission of Large and Binary MIME Messages)
RFC 3207 (SMTP Service Extension for Returning Enhanced Error Codes)
RFC 3700 (Internet Official Protocol Standards)
RFC 2606 (Reserved Top Level DNS Names)

Das File Transfer Protocol (engl. für "Dateiübertragungsverfahren", kurz FTP), ist ein in RFC 959 spezifiziertes Netzwerkprotokoll zur Dateiübertragung über TCP/IP-Netzwerke. FTP ist in der Anwendungsschicht des TCP/IP Protokollstapels angesiedelt. Es wird benutzt, um Dateien vom Server zum Client (Download), vom Client zum Server (Upload) oder clientgesteuert zwischen zwei Servern zu übertragen. Neben dem File Transfer Protocol (FTP) gibt es auch noch das IBM Transfer Protocol, welches die Verbindung von PC zu Mainframe Umgebungen ermöglicht.

Anders als z.B. HTTP benutzt FTP zur Kommunikation mehr als eine Verbindung: Zunächst wird zum Port 21 des Servers, dem Control Port, eine Verbindung zur Authentifizierung und Befehlsübertragung aufgebaut. Hier reagiert der Server auf jeden Befehl des Clients mit einem Statuscode, oft mit einem angehängten, erklärenden Text. Zur eigentlichen Datenübertragung wird dann im Bedarfsfall eine separate Verbindung initiiert (allgemein gilt: Port 20 - Datenübertragung, Port 21 - Initiierung der Session, Kommandoübertragung). FTP kennt dazu zwei Modi:

Beim Active Mode baut der Server von seinem Port 20, dem Data Port, eine Datenverbindung zu einem vom Client gewählten Endpunkt auf. Dieser Endpunkt ist typischerweise ein Port des Clients, der jenseits 1023 liegt, kann aber auch ein anderer Server sein, der seinerseits in den Passive Mode geschaltet wurde, also auf eine Verbindung wartet (sogenanntes FXP).
Die Kommunikation mit Befehlen erfolgt auf dem Port 21. Man spricht auch von der Steuerung "Out of Band". Somit bleibt es möglich, dass während der Datenübertragung die Partner noch immer miteinander kommunizieren können.

Beim Passive Mode baut der Client eine Datenverbindung zum vom Server gewünschten Port auf. Hier wird typischerweise von beiden Seiten ein Port jenseits 1023 benutzt.
Diese Technik wird eingesetzt, wenn der Client für den Server nicht erreichbar ist. Dies ist beispielsweise der Fall, wenn der Client sich hinter einem Router befindet, der die Adresse des Clients mittels NAT umschreibt, oder wenn eine Firewall das Netzwerk des Client vor Zugriffen von außen abschirmt.

Viele FTP-Server, vor allem Server von Universitäten und Fachhochschulen, bieten so genanntes Anonymous FTP an. Hier ist zum Einloggen neben den realen Benutzerkonten ein spezielles Benutzerkonto, typischerweise "anonymous" und/oder "ftp", vorgesehen, für das kein (oder ein beliebiges) Passwort angegeben werden muss. Zum "guten Ton" gehört jedoch, bei anonymem FTP seine eigene, gültige E-Mail-Adresse als Passwort anzugeben.
Für das Datenübertragungsverfahren wird ein FTP Client benötigt.