© Liashko/Shutterstock.com
Entwickler Magazin
Portorientierte Entwicklung und BEEP

Neue Wege für Internetprotokolle

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. Die Suche nach Lösungen für die Zukunft hat bereits begonnen. Welche Möglichkeiten müssen neue Standards bieten und wie kann das bereits 2001 als Standard veröffentlichte Blocks Extensible Exchange Protocol (BEEP) bei der Suche helfen?

Maik Wojcieszak


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 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 [1]. 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 [2].

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 d...

Entwickler Magazin
Portorientierte Entwicklung und BEEP

Neue Wege für Internetprotokolle

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. Die Suche nach Lösungen für die Zukunft hat bereits begonnen. Welche Möglichkeiten müssen neue Standards bieten und wie kann das bereits 2001 als Standard veröffentlichte Blocks Extensible Exchange Protocol (BEEP) bei der Suche helfen?

Maik Wojcieszak


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 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 [1]. 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 [2].

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 d...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang