Logo von Developer

Suche
preisvergleich_weiss

Recherche in 2.302.663 Produkten

Maik Wojcieszak

Internet-Protokolle, Teil 2: Anwendungsprotokolle im Vergleich

Internet-Protokolle, Teil 2: Anwendungsprotokolle im Vergleich

Bevor man ein eigenes Protokoll entwickelt, lohnt es sich häufig, erst einmal zu prüfen, was bestehende bereits leisten. Sei es, um Inspiration und Verständnis zu erlangen, sei es, um zu erkennen, dass man sich die Arbeit sparen kann.

Die im ersten Teil dieser Artikelserie vorgestellte TCP/IP-Protokollsuite ermöglicht die Übertragung von Daten im Netz. Damit jedoch aus dem Datenstrom, den Anwendungen austauschen, eine sinnvolle Kommunikation wird, ist noch Einiges zu tun. Verwendung finden dabei Protokolle, die dem Anwendungsentwickler wichtige Werkzeuge zur Verfügung stellen und modular einsetzbar sind. Das richtige Anwendungsprotokoll aus einer Vielzahl von Möglichkeiten auszuwählen, ist jedoch oft eine Herausforderung.

Noch mehr Schichten

Das OSI-Modell (*.zip) wurde 1979 als Referenzmodell für Netzwerkprotokolle entwickelt. Die Abkürzung OSI steht für Open Systems Interconnection und ist ein Teil des ISO/IEC-7498-1-Standards, weshalb häufig auch vom ISO/OSI-Modell die Rede ist.

Letztlich hat sich die OSI-Protokollsuite, die gern als zu kompliziert, groß und ineffizient kritisiert wurde, nicht gegen den pragmatischen Ansatz der TCP/IP-Protokollsuite durchsetzen können. Das OSI-Modell eignet sich jedoch gut zur Erläuterung von Netzwerktechniken. Abbildung 1 stellt die sieben Ebenen des OSI-Modells den vier Schichten des TCP/IP-Modells gegenüber, das im ersten Teil dieser Artikelserie vorgestellt wurde. Die Ebenen 1 bis 4 des OSI-Modells entsprechen den Ebenen 1 bis 3 im TCP/IP-Modell. Die Ebenen 5 bis 7 des OSI-Modells teilen die Anwendungsschicht in drei Schichten auf und sollen hier näher betrachtet werden.

Das ISO/OSI-Schichtenmodell gliedert Protokollfunktionen im Gegensatz zum TCP/IP-Modell feiner auf (Abb. 1).
Das ISO/OSI-Schichtenmodell gliedert Protokollfunktionen im Gegensatz zum TCP/IP-Modell feiner auf (Abb. 1).


OSI-Ebene 5: Kommunikationssteuerung (Session)

Die Kommunikationssteuerung erzeugt, verwaltet und löscht Verbindungsparameter, die den Datenfluss durch eine oder mehrere Transportverbindungen steuern. Alle Änderungen der Verbindungsparameter müssen beide Kommunikationspartner bestätigen, damit immer ein definierter Zustand entsteht. Falls nötig, werden Daten zwischengespeichert und der Datenfluss synchronisiert. Die Kommunikationssteuerung ist außerdem für die Verwaltung der Transportverbindungen zuständig, die sie je nach Bedarf startet oder beendet.

OSI-Ebene 6: Darstellungsschicht (Presentation)

Daten werden auf verschiedenen Plattformen unterschiedlich dargestellt und sind für die Übertragung in eine allgemein gültige Form zu bringen. Auf der Seite des Empfängers findet dann der umgekehrte Prozess statt. Das Telnet-Protokoll zum Beispiel verwendet auf dieser Ebene maschinenunabhängige Steuerbefehle. Neben dem Festlegen von Steuerzeichen und der Kodierung/Dekodierung der Daten sind auch Verschlüsselung und Kompression Aufgaben der Darstellungsschicht.

OSI-Ebene 7: Anwendungsschicht (Application)

Trotz ihres Namens handelt es sich bei der Anwendungsschicht nicht um das Anwendungsprogramm selbst, sondern um eine abstrakte, möglichst standardisierte Schnittstelle, die Netzwerkdienste zur Verfügung stellt. Anwendungen setzen auf dieser Schnittstelle auf.

Beispiele für Dienste auf dieser Ebene sind Dateitransfer, Nachrichtenaustausch oder die Steuerung von Zugriffsrechten. Für den Anwendungsprogrammierer ist nur die Anwendungsschicht sichtbar. Kenntnisse über die darunter liegenden Schichten sind jedoch für das Verständnis der Einsatzmöglichkeiten bestimmter Protokolle notwendig.

Verbunden oder nicht verbunden?

Anwendungsprotokolle, die auf der Ebene 5 des OSI-Modells Verbindungsparameter verwenden, sind verbindungsorientiert. Beginn und Ende einer Session sind genau festgelegt. Im Gegensatz dazu beginnen verbindungslose Protokolle, Nutzdaten zu senden, sobald eine Transportverbindung besteht. Das am weitesten verbreitete verbindungslose Protokoll ist wohl HTTP/1.1 und seine Vorgängerversionen. Ursprünglich wurde für jede Anfrage an den Server eine eigene TCP-Verbindung geöffnet und anschließend wieder beendet. Aktuelle Versionen des HTTP-Protokolls erlauben es, Verbindungen mehrfach zu verwenden, um den Datenaustausch zu beschleunigen.

Für den verschlüsselten Transport sensibler Daten zwischen Client und Server ist jedoch eine Erweiterung nötig, die eine abgesicherte Session auf OSI-Ebene 5 etabliert, um eine Verschlüsselung auf OSI-Ebene 6 zu ermöglichen. Dafür sind Verbindungsparameter erforderlich. Weil HTTP diese Parameter nicht vorsieht, wird das verbindungsorientierte HTTPS-Protokoll verwendet.

HTTPS setzt für das Absichern der Verbindung das Transport-Layer-Security-Protokoll (TLS) ein, das früher unter dem Namen Secure Socket Layer (SSL) bekannt war. Der Name wurde im Zuge der Standardisierung im Januar 1999 geändert. TLS wird im OSI-Modell Ebene 5 zugeordnet, da sich dessen Funktionen auf die Session beziehen. Im TCP/IP-Modell dagegen kommt TLS unabhängig vom Anwendungsprotokoll zum Einsatz und wird daher der Transportschicht zugeordnet.

In jedem Fall erfordern eine flexible Steuerung des Datenflusses, Sicherheitsfunktionen wie Authentifizierung und Verschlüsselung oder eine solide Behandlung von Transportfehlern die Verwendung von Verbindungsparametern. Der Aufbau einer Session benötigt jedoch Zeit und Ressourcen und erhöht den Aufwand für die Implementierung.

Kommunikationsarten

Eine Klasse für sich

Je spezifischer ein Protokoll für einen bestimmten Zweck entwickelt wurde, desto weniger Möglichkeiten sind vorhanden, es an einen anderen Anwendungsfall anzupassen. FTP ist beispielsweise für die Übertragung von Dateien gut geeignet. Dafür wurde es entwickelt. Ein festgelegter Befehlssatz ist für diesen speziellen Zweck vorhanden. Anwendungen, die FTP verwenden, können daher problemlos miteinander kommunizieren.

Jedes spezialisierte, nicht erweiterbare Protokoll bildet eine Klasse für sich und lässt sich für einen genau festgelegten Fall verwenden. Meist liegt es auf der Hand, welches Standardprotokoll zum Problem passt.

Schwieriger gestaltet es sich, ein geeignetes, nachrichtenorientiertes Protokoll zu finden, das Entwickler für wachsende Anforderungen im Laufe eines Projekts erweitern können.

Kommunikationsmuster unter der Lupe

Ein grundlegendes Kommunikationsmuster für den Austausch von Nachrichten in Anwendungsprotokollen ist das Anfrage/Antwort-Muster (request/reply). Ein Netzknoten sendet eine Anfrage an einen anderen und erhält eine Antwort. Bleibt sie aus, kommt es zu einem Fehler. In modernen Anwendungen reicht ein derartiger Mechanismus jedoch oft nicht aus, weshalb Abwandlungen nötig sind.

Der Austausch von Nachrichten kann in einem verteilten System im Netzwerk auf die unterschiedlichsten Arten erfolgen. Diese systematischen Kommunikationsmuster bilden, wenn die Entscheidung für eine nachrichtenorientierte Kommunikation gefallen ist, das wichtigste Kriterium für ein geeignetes Protokoll.

Nicht immer ist es sinnvoll oder möglich, Nachrichten direkt von einem Knoten zum anderen zu schicken. Ein Message Broker übernimmt in dem Fall die Aufgabe des Vermittlers. Verwenden Netzwerkknoten beispielsweise ein anderes Protokoll oder eine andere Netzwerktechnik wie Bluetooth, sammeln und organisieren Message Broker Daten und leiten sie weiter. Das funktioniert prinzipiell in jede Richtung. Kommunikationsmuster finden dann zwischen Broker zu Knoten und Knoten zu Knoten Anwendung.

Synchron oder asynchron

Dynamische Eigenschaften des Nachrichtenaustauschs werden bei der Entscheidung für ein Protokoll häufig vernachlässigt. Steigen im Laufe des Projekts die Anforderungen an Geschwindigkeit und Skalierbarkeit, können Probleme wie Datenstau und Blocking-Effekte auftreten.

Im einfachsten Fall wird eine Nachricht synchron bearbeitet. Ein Sender überträgt dabei die komplette Nachricht und wartet die Antwort des Empfängers ab, bevor er die nächste Nachricht schickt. Diese Zeitspanne umfasst nicht nur die Bearbeitungszeit, sondern auch die Übertragungszeit der Daten durch das Netz.

Werden mehrere Nachrichten vom Sender an den Empfänger geschickt, ohne die Antwort abzuwarten, spricht man von Pipelining. Der Empfänger arbeitet dabei eine Nachricht nach der anderen ab und beantwortet sie in der Reihenfolge des Empfangs. Er muss die Bearbeitung nicht mehr unterbrechen, bis der Sender die nächste Nachricht übertragen hat, was zu schnelleren Antwortzeiten führt.

In beiden Fällen lassen sich Nachrichten nur in der durch den Sendezeitpunkt festgelegten Reihenfolge bearbeiten. Es entsteht ein Effekt, der als Head-of-line Blocking bezeichnet wird. Große Nachrichten oder Nachrichten mit einer langen Bearbeitungszeit blockieren dabei nachfolgende Anfragen. Eine asynchrone Kommunikation erlaubt es, Nachrichten unabhängig voneinander zu schicken und zu bearbeiten. Die Bearbeitung lässt sich parallel durchführen, was zu einer besseren Ausnutzung von Multicore-CPUs führt. Abbildung 2 stellt asynchronen Nachrichtenaustausch dem synchronen und Pipelining gegenüber.

Asynchrone Kommunikation vermeidet das Blockieren einer Nachricht durch andere (Abb. 2).
Asynchrone Kommunikation vermeidet das Blockieren einer Nachricht durch andere (Abb. 2).


Ein weiterer Vorteil asynchroner Kommunikation ist die Option, Nachrichten zu priorisieren. Eine gezielte Steuerung der Bandbreite innerhalb einer einzigen Verbindung ist so möglich (Quality of Service).

Ein möglicher Weg, Pipelining und asynchrone Kommunikation in einem Protokoll parallel zu verwenden, sind Kanäle. Ein Kanal verhält sich wie eine Vollduplex-Pipe, während Nachrichten, die über verschiedene Kanäle transportiert werden, asynchron sind. Anwendungen öffnen und schließen Kanäle nach Belieben und verwenden dabei die gleiche Transportverbindung. Die Nachteile kurzlebiger TCP-Verbindungen werden so vermieden (siehe "Internet-Protokolle, Teil 1: TCP/IP, der Grundstein für Anwendungsprotokolle").

Die Datenschicht

Protokolle legen neben dem Transport auch die Syntax und Semantik von Nachrichten fest. Die Bandbreite erstreckt sich dabei von festgelegten Datenfeldern mit einer bestimmten Bedeutung über Standardformate wie JSON oder XML bis zu Nachrichten, die aus einer Payload, also einer frei verwendbaren Menge an Bytes, bestehen. Eine genaue Betrachtung der Möglichkeiten und Einschränkungen unterschiedlicher Datenformate lohnt sich.

Für Anwendungen mit Knoten im Netz, die über geringe Ressourcen wie Rechenleistung und Speicher verfügen, ist ein Blick auf binäre Austauschformate wie MessagePack oder CBOR zu empfehlen. Auf jeden Fall ist das Datenformat ein wichtiges Kriterium für die Auswahl eines Anwendungsprotokolls.

Protokollstapel und Übersicht

Modul oder Monolith

Das OSI-Modell sieht einen modularen Ansatz für Anwendungsprotokolle vor. Funktionen auf verschiedenen Ebenen sind gegeneinander austauschbar und klar abgegrenzt. Im TCP/IP-Modell enthält ein Anwendungsprotokoll unter Umständen alle Funktionen der OSI-Ebenen 5 bis 7 in einer monolithischen Implementierung. Da TCP bereits über umfangreiche Funktionen verfügt, sind Anwendungsprotokolle schnell und einfach zu implementieren. Eine Aufteilung in kleinere Module erscheint daher nicht sinnvoll. Tatsächlich nutzen Anwendungen die TCP/IP-Socket-Schnittstelle häufig direkt. Genaue Überlegungen dazu, ob die beschriebenen Protokollfunktionen für die eigene Socket-Umsetzung nötig sind, erlauben eine bessere Einschätzung des Entwicklungsaufwands und lohnt daher in jedem Fall.

Anwendungsprotokolle stapeln

Auf den Anwendungsschichten 5 bis 7 des OSI-Modells sind modular einsetzbare, spezialisierte Protokolle vorgesehen. Im TCP/IP-Modell bildet die Anwendungsschicht einen soliden Block, der die Funktionen der Protokolle nicht weiter unterteilt. Eine Modularität wird durch das Stapeln von Anwendungsprotokollen erreicht. So ist beispielsweise SOAP für den Transport über verschiedene Anwendungsprotokolle definiert. Das jeweils darunter liegende Protokoll kommt auf OSI-Schicht 5 für den Transport zum Einsatz, bleibt jedoch im TCP/IP-Modell, der Anwendungsebene zugeordnet.

Abbildung 3 zeigt den Aufbau des Protokollstapels für einige Beispiele. Das jeweils für den Datentransport verwendete Protokoll schränkt die Möglichkeiten des darauf aufsetzenden Anwendungsprotokolls ein. Nutzt eine Applikation für den Transport ein Client/Server-Protokoll wie HTTP, ist beispielsweise Peer-to-Peer-Kommunikation keine Option.

Der Protokollstapel mit verschiedenen Anwendungsprotokollen, die auch aufeinander aufsetzen können (Abb. 3).
Der Protokollstapel mit verschiedenen Anwendungsprotokollen, die auch aufeinander aufsetzen können (Abb. 3).


Die Protokolle

Die bisher beschriebenen Eigenschaften sind in folgender Tabelle für eine Auswahl von Anwendungsprotokollen gegenüber gestellt. Nicht immer sind die Ausprägungen der Eigenschaften identisch. Ein Blick in die Spezifikation des jeweiligen Protokolls ist daher stets zu empfehlen.

BEEP CoAP FTP HTTP/1.1 HTTP/2
Transport TCP UDP TCP TCP TCP
Session
Authentication
Synchron
Pipelining
Asynchron
Kanäle
Request/Response
Single call,
Multiple Answer
Unacknowledged
Message
Multicast
Peer-to-Peer
Client/Server
Distributed Client/Server
Publish/Subscribe push
Message Broker
Message Data Binary* Binary Text* Text Binary
MQTT RPC
SMTP
SOAP
XMPP
Transport TCP HTTP*** TCP HTTP*** TCP
Session
Authentication
Synchron
Pipelining
Asynchron
Kanäle
Request/Response
Single Call, Multiple Answer
Unacknowledged Message
Multicast
Peer-to-Peer
Client/Server
Distributed Client/Server
Publish/Subscribe
Message Broker
Message Data Binary* Text** MIME XML XML


* ist Default, kann aber angepasst werden
** je nach RPC-Typ unterschiedlich (zum Beispiel XML für XML-RPC)
*** kann beliebe Nachrichtenprotokolle verwenden
☑ abhängig vom Transport oder der jeweiligen Anwendung

Fazit

Fazit und Ausblick

Der Versuch, die Architektur von Anwendungsprotokollen anhand verfügbarer Modelle zu erläutern oder sie sinnvoll zu klassifizieren, führt leicht zu verwirrenden Ergebnissen. Das OSI-Modell passt nur eingeschränkt zu Anwendungsprotokollen, die TCP/IP nutzen, während das TCP/IP-Modell die Voraussetzungen und Regeln für Protokolle, die auf anderen Protokollen in der Anwendungsebene aufsetzen, nicht ausreichend darstellt.

Teilweise aufgegeben wurde die ursprüngliche Idee des OSI-Modells, klare Schnittstellen und modulare, austauschbare Protokolle zu schaffen. TCP erlaubt die schnelle und einfache Implementierung einer Kommunikation im Netz. So entsteht ein Protokoll nach dem anderen, und Entwickler erfinden und implementieren die beschriebenen Eigenschaften immer wieder neu.

Der dritte Teil der Artikelserie wird sich einem horizontalen Modell für Protokolle widmen, das Anwendungen nicht nur die Sicht auf die oberste Schicht des Protokollstapels bietet, sondern eine Kombination aus modularen Schnittstellen verfügbar macht. Es wird erläutert, weshalb sich komplexe Eigenschaften wie Asynchronität, Skalierbarkeit und Sicherheit dadurch besser wiederverwenden und leichter nutzen lassen. (jul)

Maik Wojcieszak
ist Gründer und Geschäftsführer der Kieler Firma wobe-systems GmbH. Er entwickelt seit mehr als 10 Jahren mit seinem Team verteilte Systeme für industrielle Anforderungen.

Kommentieren