Vor- und Nachteile von HTTP-NG

Der Vorteil liegt wohl klar auf der Hand: Während bei HTTP 1.0 für jeden Request eine neue TCP-Verbindung aufgemacht wird, braucht man bei HTTP-NG nur noch eine einzige Verbindung. Dies hat einige Konsequenzen:

• Die Verbindungsauf- und -abbaukosten gehen zurück, da nur noch eine einzige Verbindung pro Session geöffnet wird. Somit werden auch die viele TIME_WAIT-Zustände  reduziert.
• Da die Header eines Request-Headers (insbesondere die Accept-Header, siehe HTTP-Header Beschreibung) nur einmal pro Session gesendet werden, verringert sich die Datenmenge eines Requests.
• Wenn der Server im predicted Mode arbeitet, erübrigen sich bei richtiger Voraussage die entsprechenden Requests vollständig.

Wenn man dieses Protokoll allerdings auf die Leistungsfähigkeit mit neueren Transport-Protokollen wie ATM  oder XTP  untersucht, so bemerkt man, daß man leider immer noch keine QoS-Parameter  bestimmen kann, da es unabhängig vom Transport-Protokoll entworfen wurde. Auch wurde bei diesem Protkoll versucht, die vorhandene Bandbreite möglichst gut auszunutzen, was nicht unbedingt kompatibel zur Beachtung von QoS-Parametern ist.

Die einzige Möglichkeit, so etwas wie Güte-Parameter zu bestimmen ist, daß man Präferenzen für einzelne Media-Types angeben kann. Dies ist aber gleichbedeutend mit Aussagen wie ,,Wenn ein JPEG vorhanden ist schicke mir dieses, ansonsten bitte das GIF``.