Logo von Developer

Suche
preisvergleich_weiss

Recherche in 2.302.663 Produkten

Maik Wojcieszak

Internet-Protokolle, Teil 3: Neue Standards für die Aufgaben der Zukunft

Internet-Protokolle, Teil 3: Neue Standards für die Aufgaben der Zukunft

Trotz sich ändernder Anforderungen verteilter Systeme ist es nicht sinnvoll, immer ein neues Protokoll zu erfinden, wenn ein altes an seine Grenzen stößt. BEEP bietet einen Ausgangspunkt, um Netzwerkkommunikation flexibel zu gestalten.

Nachdem in den ersten beiden Teilen der Artikelserie die wichtigsten Funktionen von TCP/IP und darauf aufsetzende Anwendungsprotokolle Thema waren, geht es im dritten und letzten Teil um zukünftige Standards für derartige Protokolle.

Nachrichtenprotokolle spielen eine besondere Rolle in modernen, verteilten Anwendungen. Dabei tauchen immer neue Anforderungen auf, was zu einer inflationären Standardisierung führt. Welche Protokolle das Wettrennen zwischen Anforderungen und Standards beenden werden, lässt sich kaum vorhersagen. Der Artikel beschreibt einige der aktuellen Herausforderungen und zeigt, wie die Flexibilisierung des Protokollstapels die langfristige Verwendbarkeit der Anwendung sichert.

Überall Microservices

Eine Alternative zu monolithischen Anwendungen bietet der aktuell stark im Trend liegende Architekturansatz der Microservices. Seine Vorteile sind beispielsweise eine gute Skalierbarkeit, hohe Fehlertoleranz und bessere Wartbarkeit. Besonders beim Betrieb auf Server-Clustern oder in der Cloud entfalten Microservices ihr Potenzial. So ermöglichen sie es unter anderem, Ressourcen je nach Lastanforderung dynamisch freizugeben oder hinzuzufügen.

Die Grundidee ist die Zerlegung einer Anwendung in kleinere Einheiten, die als Dienste zur Verfügung stehen und über das Netz miteinander kommunizieren. Dabei steigt die Menge und Komplexität der zwischen den Diensten ausgetauschten Informationen mit der Größe der Anwendung. Ungenügende Performance und inkompatible Schnittstellen sind zwei der Probleme, die daraus entstehen können. Neben der reinen Interprozesskommunikation zwischen den Diensten ist beim Einsatz dieser Architektur eine Überwachung des gesamten Systems nötig. Dienste müssen dafür im laufenden Betrieb Telemetriedaten und Log-Informationen liefern. Der interne Kommunikationsbedarf der gesamten Anwendung steigt erneut. All das darf keine Auswirkungen auf die Performance haben, egal wie der Betriebszustand des Systems ist.

Wachsendes Internet

Das Internet of Things (IoT) beziehungsweise das Internet of Everything (IoE) erweitern den Begriff des globalen Netzwerks. Nicht mehr nur Server in Rechenzentren liefern Daten, die Anwendungen ihren Nutzern zur Verfügung stellen, sondern Klein- und Kleinstgeräte bis hin zu einzelnen Sensoren lassen sich einbeziehen. Es ist dabei nicht immer möglich, die Verbindung mit dem Internet über eine TCP/IP-Verbindung herzustellen.

Die Geräte verwenden Batterien als Stromversorgung und müssen, da sie räumlich verteilt sind, auf energiesparende, drahtlose Übertragungstechniken wie Bluetooth zurückgreifen. Ähnlich wie bei Microservices steigt der Kommunikationsbedarf mit der Komplexität der verteilten Systeme. Je nach verwendeter Übertragungstechnik muss die Anwendung unterschiedliche Protokolle beherrschen und ihre Kommunikation entsprechend anpassen.

Internet of Things und Microservices sind Beispiele für Anwendungen, deren Anforderungen existierende Netzwerkprotokolle an ihre Grenzen bringen. Daher entstehen fortwährend neue Protokolle und Standards, wobei sich die Frage stellt, welchen Sinn letztere haben, wenn gleich mehrere Protokolle für einen Anwendungsfall geeignet sind. Solange es kein Standard geschafft hat, sich vollständig zu etablieren, folgen wohl zunehmend mehr. Anwendungsprotokolle, die über Jahrzehnte verwendet und immer nur leicht verändert wurden, sind auf überschaubare Anwendungsfälle spezialisiert. Beispiele sind Dateifreigabe (FTP, SMB), E-Mail-Versand (SMTP) oder das Ausliefern einer Textdatei mit HTML (HTTP).

Neue Dienste im Netz erfordern hingegen flexible Protokolle, die sich leicht den Anforderungen anpassen lassen. Neue Standards wie Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) oder HTTP/2 konzentrieren sich auf spezielle Anwendungsfälle, die damit hinreichend gelöst sind. Im Kern sind es jedoch Nachrichtenprotokolle, die einige Übereinstimmungen aufweisen. Entwickler "erfinden" trotzdem viele solcher Funktionen immer wieder neu. Die Herausforderung könnte darin bestehen, derartige Gemeinsamkeiten von Nachrichtenprotokollen zu identifizieren und sie in einem Protokoll zusammenzufassen. Das Ergebnis sollte flexibel und für eine Vielzahl von Anwendungsfällen geeignet sein.

BEEP

Noch ein Standard

Internetstandards sollen die Interoperabilität von Anwendungen im Netz gewährleisten. HTTP als einer der erfolgreichsten Vertreter zeigt die Richtigkeit eines derartigen Vorgehens. Die Aufgabe, für die HTTP entwickelt wurde, ist klar umrissen und hat sich seit der ersten Version kaum verändert. Erst die Diskussion um HTTP/2, das außer dem Namen nur noch wenig mit HTTP/1.1 gemeinsam hat, zeigte die Schwierigkeiten, eine neue Version eines bestehenden Standards zu definieren, die den Anwendungsbereich eines anderen erweitert. Automatisch kommt in dem Szenario schnell die Frage nach der Abwärtskompatibilität auf. Die Folge sind Kompromisse beim Design, die sich negativ auf die Akzeptanz der neuen Version auswirken können.

Oft verzichten die zuständigen Organe daher auf eine neue Version und streben direkt einen komplett neuen Standard an, der sich wiederum häufig nur langsam, wenn überhaupt, durchsetzt. Ein möglicher Grund dafür sind die sogenannten Well-known Ports. Ein neues Protokoll muss einen neuen Port verwenden. Damit ein Server mit dem Protokoll erreichbar ist, sind in vielen Fällen Firewall-Regeln anzupassen. Iterative Verbesserungen sind so kaum durchsetzbar. Es stellt sich die Frage, ob die seit Jahrzehnten bekannten und bewährten Methoden der Standardisierung von Protokollen ungeeignet für die aktuellen Anforderungen sind. Jon Postel hat 1977 auf das Prinzip der Schichten verwiesen (siehe Teil 1). Das monolithische Transmission Control Program wurde daraufhin in TCP und IP aufgeteilt. Dabei fassten die Entwickler grundlegende Funktionen zusammen, um sie modular verwenden zu können. Wollte man die Vorgehensweise auf Nachrichtenprotokolle anwenden, wäre zunächst zu überlegen, welche Funktionen letztlich vorhanden sein sollten.

Profile statt Protokolle

Elementare Funktionen wie Flusskontrolle, Kanäle und Multiplexing bilden mit vielen anderen die Infrastruktur für einen reibungslosen Nachrichtenaustausch im Netz. Der Inhalt der Nachrichten spielt dabei keine Rolle. Auch Kommunikationsmuster wie Client/Server oder Publish/Subscribe legt erst die Anwendung fest. Von den in Teil 2 vorgestellten Protokollen bietet das Blocks Extensible Exchange Protocol (BEEP) als einziges die Option, mit Profilen die Syntax und Semantik von Nachrichten sowie das Kommunikationsmuster zu definieren.

Abbildung 1 zeigt, wie sich BEEP-Profile wie eine neue Schicht in den Protokollstapel einfügen. Sie übernehmen die Rolle der Schnittstelle zur Anwendung. Andere Nachrichtenprotokolle wie HTTP, SOAP, RPC, aber auch MQTT lassen sich mit Profilen nachbilden. Eine Reihe von BEEP-Profilen stehen als IANA-Standard zur Verfügung. Ob Standard oder proprietär, die Profile übernehmen die Rolle des TCP/IP-Anwendungsprotokolls und nutzen die Möglichkeiten asynchroner, skalierbarer Kommunikation über eine einzige Transportverbindung.

BEEP-Profile übernehmen die Rolle der Anwendungsschnittstelle (Abb. 1).
BEEP-Profile übernehmen die Rolle der Anwendungsschnittstelle (Abb. 1).


Kanäle statt Ports

BEEP und der neue HTTP/2-Standard verwenden Kanäle für asynchrone Kommunikation. Ein einzelner Kanal verhält sich wie ein Vollduplex-Stream, man kann also lesend und schreibend auf ihn zugreifen. Entsprechende Systeme übertragen Nachrichten nacheinander. Die Kanäle sind jedoch unabhängig und erlauben eine asynchrone Kommunikation über eine einzige TCP-Verbindung. Nachrichten werden in Pakete (Frames) zerlegt und über eine gemeinsam genutzte TCP-Verbindung versendet (Multiplexing). JederKanal verfügt über einen eigenen Puffer, der wiederum eine Flusskontrolle erfordert, damit es nicht zu Übertragungsfehlern durch zu schnelles Senden von Daten kommt. Framing und Multiplexing erlauben einer Anwendung, die Übertragung einer großen Nachricht zu unterbrechen, wenn eine Änderung des Systemzustands es erfordert.

Die Idee von Framing und Flusskontrolle in einem Anwendungsprotokoll erscheint zunächst ungewohnt. Diejenigen, die Details des TCP-Protokolls kennen, lehnen die Idee gelegentlich mit dem Argument ab, dass die entsprechenden Funktionen in der Transportschicht vorhanden sind. Wenn für asynchrone Kommunikation mehrere TCP-Verbindungen zum Einsatz kommen, reicht das folglich aus. Für asynchrone Kommunikation über eine TCP-Verbindung durch Kanäle und jeweils einen Empfangspuffer pro Kanal ist jedoch auch im Anwendungsprotokoll Framing und Flusskontrolle nötig. Quality of Service, also die Steuerung der Priorität unterschiedlicher Kanäle, ist eine wichtige Anforderung, wenn ein Dienst unterschiedliche Leistungen anbieten soll. Framing, Multiplexing und Flusskontrolle ermöglichen eine gezielte Steuerung der Bandbreite, die einer Schnittstelle zur Verfügung steht.

Sicherheit und Unabhängigkeit

Sichere Verbindung

Um im TCP/IP- und OSI-Schichtenmodell die Datenübertragung zu verschlüsseln, muss eine Anwendung Funktionen des TLS-Protokolls steuern, das unterhalb der Anwendungsschicht und damit der Applikationsschnittstelle zu finden ist. Im TCP/IP-Modell ist es der Transportschicht zugeordnet, während es sich im OSI-Modell in der Kommunikationssteuerung auf Ebene 5 befindet. Das Anwendungsprotokoll und seine Schnittstelle muss Informationen durchreichen und verwalten sowie entsprechende APIs bereitstellen. Dafür entstanden neue Anwendungsprotokolle wie HTTPS. Der BEEP-Standard sieht für die Sicherung einer Verbindung Profile für SASL und TLS vor, die Anwendungen beim Aufbau einer Session nutzen können. Abbildung 2 zeigt, wie Kanäle eine Session mit Profilen verbinden. Ist eine Session zwischen zwei Peers etabliert, sichert sie den Nachrichtenaustausch für alle Profile. Es ist nicht nötig, bei der Entwicklung Letzterer Verschlüsselung und Authentifizierung zu berücksichtigen, da die BEEP-Nachrichtenschicht die Aufgabe erledigt. Nach einem Ändern der Sicherheitsmechanismen einer BEEP-Session sind bestehende Profile nicht anzupassen.

Internet-Protokolle, Teil 3: Neue Standards für die Aufgaben der Zukunft
Einmal aufgebaut, sichert die Session den Nachrichtenaustausch für alle Profile (Abb. 2).


Die Anforderungen in modernen IT-Projekten ändern sich laufend und schnell. Es ist im Allgemeinen nicht möglich, erst auf die Verabschiedung eines entsprechenden Standards zu warten. Das dadurch entstehende Vakuum motiviert die Entwicklung proprietärer Lösungen. Da die Programmierung eines Anwendungsprotokolls nicht trivial ist, wählen Entwickler oft einen existierenden Standard, der nur ungefähr zur Aufgabe passt. Beide Wege haben ihre Vor- und Nachteile. Eines gilt aber für beide: Hat ein Team eine Herangehensweise gewählt, revidiert es seine Entscheidung selten. Proprietäre Protokolle für eine neue Anwendung zu erstellen, ist eine Sache, sie später zu ändern und zu riskieren, das System zu destabilisieren, eine ganz andere. Im Fall einer Anpassung steht die Forderung nach Abwärtskompatibilität im Raum.

Im Betrieb befindliche Systeme müssen weiterhin in der Lage sein, mit neuen Komponenten Daten auszutauschen. In dem Fall bieten Profile einen Ausweg. Abbildung 3 zeigt zwei Versionen des SOAP-Protokolls, das ein TCP-Port als Profile zur Verfügung stellt. Ältere Anwendungen sind in ihrer Funktion nicht durch das Bereitstellen der neuen Variante beeinträchtigt, während aktuelle Systeme auf neue Funktionen zugreifen können. Dass neue Profilversionen abwärtskompatibel sind, ist nicht erforderlich.

Internet-Protokolle, Teil 3: Neue Standards für die Aufgaben der Zukunft
Ein TCP-Port kann unterschiedliche Versionen eines Profils bereitstellen (Abb. 3).


Mehr Unabhängigkeit

Protokolle wie RPC oder SOAP sind unabhängig vom Transportprotokoll definiert. Auch BEEP ist in RFC3080 ohne Festlegung auf eine bestimmte Transportschicht beschrieben. Durch die Unabhängigkeit vom Datentransport sind die Protokolle universell einsetzbar. Die bisherige Netzwerkinfrastrukturbleibt im Betrieb, und der Protokollstapel lässt sich je nach Anforderung verändern. Wie BEEP TCP als Übertragungsprotokoll verwendet, beschreibt RFC3081. Eine TCP-Verbindung ist ein bidirektionaler Vollduplex-Stream, der sicherstellt, dass die übertragenen Daten in der gleichen Reihenfolge beim Empfänger ankommen, wie sie der Sender verschickt hat. Das trifft jedoch auch auf andere Protokolle wie das WebSocket-Protokoll zu.

Die quelloffene BEEP-Implementierung Vortex bietet die Möglichkeit, den TCP-Transport durch Alternativen zu ersetzen. Sie tauscht über eine WebSocket-Verbindung asynchrone Nachrichten aus. Eine Anwendung, die aus einer Vielzahl von Profilen und unterschiedlichen Diensten besteht, von einem Transportprotokoll auf ein anderes übertragen zu können, erhöht die Flexibilität. Da für den vollen Funktionsumfang von BEEP im Unterschied zu den meisten TCP-Protokollen eine einzige Verbindung ausreicht, ist eine RS232- oder USB-Schnittstelle als Übertragungsweg denkbar. Das Bluetooth-Protokoll RFCOMM ist eine Emulation der RS232-Übertragung, die in praktisch allen Bluetooth-Stack-Implementierungen vorhanden ist. Es liegt daher nahe, BEEP-Frames via Bluetooth über RFCOMM zu transportieren. Abbildung 4 zeigt die beschriebenen Beispiele des Protokollstapels. Weitere Techniken lassen sich leicht ohne Auswirkungen auf die Funktionsweise der Anwendung adaptieren.

Internet-Protokolle, Teil 3: Neue Standards für die Aufgaben der Zukunft
Protokollstapel lassen sich je nach Bedarf zusammensetzen (Abb. 4).


Viele der klassischen Internetprotokolle sind auf die Übertragung von Text beschränkt. Aktuelle Entwicklungen wie MQTT, CoAP, BEEP und HTTP/2 setzen auf die Übertragung binärer Daten. Der Grund dafür ist die Möglichkeit, praktisch jedes Datenformat binär zu transportieren. Nicht nur Text, sondern auch Multimediadaten wie Bilder, Videos oder Audiodateien lassen sich ohne aufwendige Kodierung verschicken. Darüber hinaus sind die Daten kompakter, was besonders im Internet der Dinge für den sparsamen Umgang mit Netzwerkbandbreite, Stromverbrauch und CPU-Last wichtig ist.

Fazit

Was die Zukunft bringt, kann niemand wissen. Jahrzehnte der Arbeit mit Netzwerktechnik haben jedoch dazu geführt, dass sich jede beliebige Anforderung erfüllen lässt. Mit Nachrichtenprotokollen ist die Entwicklung an einem Punkt angekommen, an dem sowohl das Wissen als auch die Implementierungen zu strukturieren und zusammenzufassen sind.

Marschall T. Rose sagt über die Motivation für die Entwicklung des Blocks Extensible Exchange Protocol:

"BEEP integrates the best practices for common, basic mechanisms that are needed when designing an application protocol over TCP." [1]

Das Internet of Everything und Microservices wenden bekannte Techniken an. Die Dynamik der Anforderungen derartig verteilter Systeme erfordert jedoch eine bisher unbekannte Flexibilität und Erweiterbarkeit. Jedes Mal das Rad neu zu erfinden, wenn ein Protokoll an seine Grenzen stößt, ist dabei ein Bremsfaktor. Eine Beschränkung auf eine Technik wie TCP/IP reicht bei der Betrachtung von Netzwerken und Protokollen mindestens für Anwendungen im Internet der Dinge nicht mehr aus. Es ist mit Blick auf neue Übertragungstechniken sicherzustellen, dass Anwendungen zukünftig funktionieren – unabhängig davon, wie die Knoten im Netzwerk miteinander verbunden sind. Es erfordert Weitsicht, gesunden Menschenverstand und Erfahrung, um einen Anwendungsbereich so festzulegen, dass er so klein wie möglich und so groß wie nötig ist.

Mit BEEP standardisierte die IETF 2001 Antworten auf die Fragen, welche Gemeinsamkeiten Nachrichtenprotokolle haben und wie sie sich zu einer neuen Kommunikationsschicht zusammenfassen lassen. Zwar konnte sich das Protokoll bisher nicht durchsetzen, aktuelle Standards nähern sich allerdings seinem Funktionsumfang an. HTTP/2 verwendet beispielsweise Kanäle und binäre Payloads. Für diejenigen, die sich dafür interessieren, Netzwerkkommunikation flexibel und effektiv zu gestalten, bietet BEEP eine Fülle von Ideen und einen guten Ausgangspunkt zur Umsetzung. (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.

Literatur

Kommentieren