Neue Wege für Internetprotokolle

Portorientierte Entwicklung und BEEP
Kommentare

Mobile Apps, Desktopanwendungen oder Rich Internet Applications im Browser verwenden immer häufiger Web-APIs, die komfortabel Dienste im Netz nutzbar machen. Anwender bemängeln jedoch Wartezeiten und langsame Reaktionen grafischer Oberflächen und Webseiten. Eine mögliche Ursache ist das für die Verbindung genutzte Anwendungsprotokoll. Welche Möglichkeiten müssen also neue Standards bieten und wie kann das bereits 2001 als Standard veröffentlichte Blocks Extensible Exchange Protocol (BEEP) bei der Suche helfen?

HTTP wurde vor mehr als zwanzig Jahren für den Zugriff auf Dokumente und Bilder mittels Webbrowser entwickelt. Für die Übertragung von Daten mit HTTP werden mehrere TCP-Verbindungen gleichzeitig oder nacheinander genutzt. Um eine HTML-basierte Webseite mit Bildern zu laden, sind wenige Verbindungen ausreichend. Jede einzelne Verbindung liefert dabei umfangreiche Daten an den Browser.

Immer häufiger werden heute jedoch Web-APIs (Sieben Ratschläge zur sicheren Verwaltung von Web-APIs) und Internetdienste mittels HTTP genutzt. Dadurch haben sich die Anforderungen an das Protokoll verändert. Viele Anfragen liefern jeweils nur geringe Datenmengen für den Aufbau einer Seite (kleinteilige Kommunikation) oder formatierte Daten für eine App oder Desktopanwendung. Bei einer Vielzahl von Anfragen werden immer neue TCP-Verbindungen aufgebaut. Das wirkt sich auf die effektiv genutzte Bandbreite wie eine Bremse aus.

Weniger ist schneller

Bei jedem neuen Aufbau einer TCP-Verbindung wird diese zunächst optimiert (siehe: Stevens, W. R.: „TCP/IP Illustrated, Volume 1: The Protocols“, Addison-Wesley, 1994. Kapitel 21.6 Congestion Avoidance Algorithm). Während dieser Startphase wird nicht die gesamte mögliche Bandbreite des Netzwerks genutzt. Je häufiger also TCP-Verbindungen aufgebaut und je weniger Daten pro Verbindung übertragen werden, desto geringer ist die effektiv genutzte Bandbreite.

Der 1999 veröffentlichte Standard HTTP/1.1 bietet zwar die Möglichkeit, TCP-Verbindungen wieder zu verwenden (Keepalive) und erlaubt das Senden mehrerer Anfragen über eine einzelne Verbindung, ohne die Antwort abzuwarten (HTTP-Pipelining). Doch trotz dieser erweiterten Möglichkeiten ist parallele Kommunikation nur über mehrere Verbindungen möglich. Das Problem häufig neu aufgebauter Verbindungen taucht also wieder auf, sobald die Kommunikation der Anwendung mit dem Server umfangreicher wird.

Warum HTTP?

Die flexible URL-Notation beim Aufruf und die weitgehend freie Gestaltung der Antwort von HTTP erlauben eine Vielzahl von möglichen Anwendungen. Für HTTP spielt es keine Rolle, ob ein HTML-Dokument oder formatierte Daten (JSON, XML) geliefert werden. Damit bietet sich die Möglichkeit, Parameter für Funktionen an Web-APIs als URL zu übergeben und das Ergebnis als textformatierte Daten zu liefern. Bei genauer Betrachtung der Übertragung vom Client zum Server und umgekehrt sind jedoch Probleme erkennbar:

  • große Nachrichten blockieren andere
  • unterschiedliche Prioritäten sind nicht möglich
  • das aktive Senden von Daten vom Server zum Client ist nicht vorgesehen

Der Punkt, der HTTP trotz Problemen bei kleinteiliger Kommunikation mit Web-APIs interessant macht, ist die Möglichkeit, aus den meisten Netzen heraus über Port 80 oder mit HTTPS über Port 443 auf die Dienste zugreifen zu können, ohne von einer Firewall blockiert zu werden.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Zukunftsmusik

Die Reduzierung der Anzahl verwendeter TCP-Verbindungen pro Anwendung zu einem Server wurde durch die Erfahrungen mit HTTP bei kleinteiliger Kommunikation zu einer wichtigen Anforderung an zukünftige Protokolle. Optimal wäre eine einzige Verbindung, die erst geschlossen wird, wenn keine Datenübertragung mehr zu erwarten ist.

Der aktuell diskutierte Entwurf des HTTP/2-Protokolls soll dies ermöglichen. Ziel ist ein einheitlicher Standard für das Laden von Webseiten im Browser und den schnellen Zugriff auf Web-APIs. Bei der Spezifikation wird jedoch versucht, vollständig kompatibel zur Vorgängerversion HTTP/1.1 zu bleiben, was eine grundlegend neue und gradlinige Lösung erschwert. Der Artikel „Ein Baukasten für TCP/IP Protokolle“ in Ausgabe 1.2015 des Entwickler Magazins hat das bereits 2001 von der Internet Engineering Task Force (IETF) als Standard (RFC3080/3081) veröffentlichte Blocks Extensible Exchange Protocol (BEEP) vorgestellt und beleuchtete einige der vielen Möglichkeiten, die BEEP bietet. Unter anderem erlaubt BEEP das Senden von asynchronen Nachrichten über einen einzigen Port. Die Funktionen, die nötig sind, um dies zu erreichen, heißen Multiplexing und Flusskontrolle.

Flusskontrolle?

Die meisten Internetprotokolle basieren wie HTTP/1.1 darauf, die Flusskontrolle im Transmission Control Protocol (TCP) zu nutzen. Entwickler vertrauen deshalb häufig darauf, dass im Anwendungsprotokoll Flusskontrolle nicht benötigt wird, was die Spezifikation und Implementierung des Protokolls vereinfacht. TCP bietet zwar Flusskontrolle, jedoch für die gesamte Verbindung. Wie Abbildung 1 zeigt, sind dann für eine parallele Kommunikation mehrere Verbindungen nötig. Was in der Grafik für HTTP dargestellt ist, trifft auf die meisten TCP-basierten Anwendungsprotokolle zu, proprietäre Lösungen ohne Flusskontrolle eingeschlossen.

Das Blocks Extensible Exchange Protocol verwendet unabhängige (asynchrone) Kanäle, denen jeweils ein eigener Puffer für die Übertragung zugeordnet ist. Ein eigener Puffer pro Kanal entkoppelt die Nachrichten voneinander, damit sie sich nicht gegenseitig beeinflussen. Das setzt allerdings auch kanalbezogene Flusskontrolle voraus.

Abb. 1: Parallele Kanäle im Anwendungsprotokoll benötigen jeweils einen eigenen Puffer mit Flusskontrolle; ohne diese Möglichkeit werden für eine asynchrone Kommunikation immer mehrere Verbindungen benötigt

Abb. 1: Parallele Kanäle im Anwendungsprotokoll benötigen jeweils einen eigenen Puffer mit Flusskontrolle; ohne diese Möglichkeit werden für eine asynchrone Kommunikation immer mehrere Verbindungen benötigt

Der Nächste bitte!

Der Empfänger erhält durch Flusskontrolle die Möglichkeit, dem Sender mitzuteilen, wieviel Daten empfangen und verarbeitet werden können. Pufferüberläufe und damit Übertragungsfehler, wenn die Daten nicht schnell genug verarbeitet, bereitgestellt oder von der Anwendung gelesen werden, kann man so vermeiden.

BEEP-Kanäle (Channels) teilen dem Sender mithilfe von SEQ-Frames mit, wieviel Daten ein Puffer aufnehmen kann. Der Sender muss sich an diese Vorgaben halten. Werden mehr Daten gesendet als vom Empfänger erlaubt, ist das ein Protokollfehler, der zu einem sofortigen Verbindungsabbruch führt.

Abbildung 2 zeigt den Aufbau eines BEEP-SEQ-Frames. Nach der Zeichenfolge SEQ, die den Frame als SEQ-Frame markiert, folgt die Kanalnummer. Durch die unabhängige Flusssteuerung für jeden einzelnen Kanal ist es möglich, unterschiedliche Puffergrößen zu erlauben. Für kleinteilige Nachrichten reicht ein kleiner Puffer aus. Für Nachrichten, die viele Daten enthalten, ist ein großer Puffer besser. Die Bandbreite der Verbindung wird so optimal genutzt.

Der nächste Wert (ackno) bestätigt den Empfang der letzten Sequenz durch die Nummer des ersten Bytes im nächsten Frame. Dieser Wert wird fortlaufend hochgezählt und korrespondiert mit dem SEQ-Wert im Message-Frame. Abbildung 3 zeigt, wie Nachrichten (MSG) über einen Kanal (CH) gesendet werden. Der dritte Wert im SEQ-Frame (window) gibt die Anzahl der Bytes an, die der Empfänger aufnehmen kann, bevor ein neuer SEQ-Frame gesendet werden muss.

Große Nachrichten (MSG 3) werden segmentiert. Die Größe der Segmente richtet sich unter anderem danach, wieviele Bytes noch gesendet werden dürfen.

Abb. 2: Aufbau eines BEEP-SEQ-Frames zur Steuerung des Datenflusses eines Kanals innerhalb der BEEP-Session

Abb. 2: Aufbau eines BEEP-SEQ-Frames zur Steuerung des Datenflusses eines Kanals innerhalb der BEEP-Session

Abb. 3: Steuerung des Datenflusses mit Nachrichten durch Senden von SEQ-Frames

Abb. 3: Steuerung des Datenflusses mit Nachrichten durch Senden von SEQ-Frames

Vordrängeln erlaubt

Neben dem Schutz vor Pufferüberläufen ist die Hauptaufgabe der SEQ-Frames die Vermeidung von „head of line blocking“ (HOL). Antworten, die große Mengen Daten liefern oder lange auf sich warten lassen, können nicht unterbrochen werden. So kann nicht auf neue, wichtigere Anfragen reagiert werden. Beispielsweise beschreiben Gettys und Freier den Effekt, der beim Versuch, mehrere Clientanfragen in eine einzelne HTTP-Verbindung zu multiplexen, entsteht. Das Ergebnis ist so verheerend, dass empfohlen wird, dies auf keinen Fall zu tun. Ursache ist das HOL-Problem, das zu Verzögerungen bei der Kommunikation bis zur vollständigen Blockade des Diensts führt.

BEEP-SEQ-Frames sind speziell dafür designt, während einer laufenden Datenübertragung entscheiden zu können, andere Anfragen mit höherer Priorität bevorzugt zu bearbeiten und so das HOL-Problem zu vermeiden.

Abbildung 4 zeigt, wie große Nachrichten segmentiert und auf mehreren Kanälen über eine TCP-Verbindung gesendet werden (Multiplexing). Ein Segment darf dabei nicht zwei Drittel der aktuellen Größe eines TCP-Segments überschreiten. Welche Bandbreite einem Kanal jeweils zur Verfügung steht, kann vom Empfänger mittels SEQ-Frames gesteuert werden. Monopolisiert ein Kanal die Verbindung oder sind andere Kanäle wichtiger, kann spätestens beim nächsten SEQ-Frame die Bandbreite neu verteilt werden. Auf das Ende einer Nachricht muss dabei nicht gewartet werden.

Abb. 4: Segmentieren und Multiplexen von Nachrichten über eine einzige TCP-Verbindung

Abb. 4: Segmentieren und Multiplexen von Nachrichten über eine einzige TCP-Verbindung

BEEP zeigt Profil

Verschiedene Protokolle werden über festgelegte TCP-Ports bereitgestellt. Diese Vereinbarung vereinfacht es Anwendungen, Dienste im Internet zu finden und zu nutzen. Vergleicht man ein Protokoll mit einer Firma und die Portnummer mit einer Etage, müssten sich alle Firmen darauf einigen, in jedem Hochhaus in die gleiche Etage zu ziehen, um gefunden zu werden.

Sicherheitskonzepte sehen vor, bei Bedarf den zugeordneten Port eines Anwendungsprotokolls in einer Firewall zu sperren oder freizugeben. Benötigt eine Anwendung unterschiedliche Protokolle, kann es passieren, dass sie nur teilweise funktioniert, wenn einer oder mehrere Ports gesperrt sind.

Um dieses Problem zu umgehen, wird möglichst die komplette Kommunikation über ein einziges Protokoll abgewickelt. Beispielsweise werden Dateien häufig über HTTP heruntergeladen und nicht über das eigens für diesen Zweck entwickelte FTP-Protokoll. Je unterschiedlicher die Art der Kommunikation, desto häufiger werden dabei Kompromisse bei Geschwindigkeit, Sicherheit und Funktionalität akzeptiert.

BEEP-Kommunikationsprofile (siehe: Wojcieszak, Maik: „Ein Baukasten für TCP-/IP-Protokolle“, in Entwickler Magazin 1.2015, S. 26) erlauben die genaue Definition von Syntax und Semantik ausgetauschter Nachrichten zwischen Kommunikationspartnern. Sowohl Anfrage wie Antwort werden somit exakt den Anforderungen angepasst. Die Funktionalität der meisten Protokolle, die auf dem Request/Response-Modell basieren, kann leicht nachgebildet werden.

Mehrere BEEP-Profile können gleichzeitig über einen einzigen Port vom Server bereitgestellt werden. Statt über Portnummern werden BEEP-Profile über eindeutige Profilnamen (IDs) ausgewählt. Im oben genannten Beispiel stehen an den Etagenknöpfen im Fahrstuhl des Bürohochhauses in diesem Fall die Namensschilder der Firmen. Ein Kunde (Client) erkennt auf einen Blick, ob der gesuchte Dienst verfügbar ist und wie man ihn findet.

Alte Gewohnheiten

Natürlich können BEEP-Profile auch über unterschiedliche Ports bereitgestellt werden. Tatsächlich gibt es für Standard-BEEP-Profile bereits festgelegte Portnummern. Einige Beispiele sind:

  • 601 TCP: RFC3195 Reliable Delivery for syslog
  • 602 TCP: RFC3529 XML-RPC over BEEP
  • 604 TCP: RFC3620 The TUNNEL Profile

Diese Vereinbarung ist nützlich und sinnvoll, um den gewohnten Umgang mit Protokollen und Ports in TCP/IP-Netzen nicht ändern zu müssen. BEEP kann jedoch auch alle Profile über einen einzigen Port bereitstellen.

Veränderung ist beständig

Eine Anforderung für HTTP/2 ist es, abwärtskompatibel zum Vorgänger HTTP/1.1 zu sein, damit auch alte Browser, die den neuen Standard nicht unterstützen, den angebotenen Dienst nutzen können. Andere Anwendungsprotokolle werden sicher ebenfalls weiter entwickelt. Es stellt sich dabei die Frage, wie verhindert wird, dass ältere Anwendungen nicht mehr funktionieren. Ein neuer Port bedeutet ein neues Protokoll, neue Sicherheitseinstellungen für Firewalls und damit die Gefahr, dass die neue Version niemals genutzt wird.

Verschiedene Versionen eines BEEP-Profils können problemlos über den gleichen Port bereitgestellt werden. Neue Anwendungen können dann die aktuelle Version eines Profils nutzen. Ältere Anwendungen nutzen die jeweils passende Version über den gleichen Port. Das Design neuer Versionen wäre nicht mehr abhängig von der Notwendigkeit, abwärtskompatibel zu bleiben. Dadurch kann schneller und umfassender auf neue Anforderungen reagiert werden.

Fazit

Das Blocks Extensible Exchange Protocol (BEEP) ist seit 2001 als Standard verfügbar. Es gibt Implementierungen und praktische Projekte, die BEEP auf unterschiedlichen Plattformen nutzen. Dennoch scheinen nur wenige die Vorteile zu erkennen, die BEEP bietet.

Protokollentwickler schwören darauf, wenn es darum geht, den höchsten Anforderungen in der Praxis gerecht zu werden. Sie verwenden BEEP-Profile anstelle von komplett neu entwickelten Protokollen auf Basis von TCP-Sockets.

BEEP bietet mit Flusskontrolle, Multiplexing und Kanälen alle Vorteile eines „Next Generation“-Protokolls. Verschiedene Profile über einen einzigen TCP-Port am Server bereitzustellen geht sogar über die Möglichkeiten vergleichbarer Protokolle, wie HTTP/2, hinaus.

Marshall T. Rose, der den Vorgänger von BEEP unter dem Namen BXXP mit entworfen hat, sagt über BEEP, es enthalte nicht viel Neues, sondern sei eine Sammlung erprobter Praktiken in einem kohärenten Framework. Das stimmt sicher, jedoch bietet BEEP durch seinen Funktionsumfang und seine Flexibilität ungeahnte Möglichkeiten für Innovationen.

Internetprotokolle der nächsten Generation

Immer kleinteiligere Kommunikation mit Web Services mittels Web-APIs verändert die Anforderungen an Anwendungsprotokolle im Internet. Eine neue Generation von Protokollen wird gesucht. Als notwendige oder zumindest wünschenswerte Ziele dafür werden unter anderen folgende Funktionen diskutiert:

  • Nur eine einzige TCP-Verbindung für die gesamte Kommunikation einer Anwendung mit einem Server.
  • Asynchrone (parallele) Nachrichten für unabhängige Funktionsaufrufe, um Verzögerungen zu vermeiden.
  • Die Möglichkeit Daten vom Server zum Client zu schicken, ohne dass diese explizit angefragt wurden (Server-Push).
  • Quality of Service, also eine Steuerung der Bandbreite für Nachrichtenkanäle innerhalb einer einzigen TCP-Verbindung.

Das Blocks Extensible Exchange Protocol (BEEP) bietet bereits jetzt diese Möglichkeiten. Mit seinen Kommunikationsprofilen geht BEEP jedoch bezüglich Modularität und Erweiterbarkeit über diese Mindestanforderungen an ein „Next Generation“-Protokoll hinaus. Mehr Infos finden sich unter www.beepcore.org.

Aufmacherbild: Concept of internet connection and social network via Shutterstock.com /Urheberrecht: alphaspirit

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -