Wer ein wenig verfolgt, wie sich das Web entwickelt (z.B. indem man den W3C Blog in Google Reader abonniert!) hat vielleicht am Rande mitbekommen, dass die Spezifikation für HTTP 2.0 so langsam aber sicher beginnt.Google freut sich, denn das SPDY Protokoll wird hierfür als Grundlage genommen – auch wenn der finale Entwurf damit eventuell nicht mehr viel Gemein haben muss.
Jetzt ist natürlich die Frage, warum man einen Artikel über ein Protokoll schreiben soll das bisher noch nicht existiert. Den meisten Menschen ist es Bums, ob jetzt HTML über SPDY oder HTTP 1.1 versendet wird wenn Sie eine Abfrage abschicken. Hauptsache es geht.
Und die Anzahl der Webanwendungen, die aufgrund konkreter Limitierungen in HTTP nicht umgesetzt werden können sollte eher gering sein. Aber ehrlich: Da geht noch mehr. Seit HTTP 1.1 (1999) hat sich in der Netz- und Anwendungs- und Gerätewelt die ein oder andere Sache geändert (wer das noch nicht bemerkt hat soll doch über sein Tablet mal ‘mobile web’ googeln, sofern der WLAN Hotspot des Smartphones noch nicht den Akku gefressen hat).
Ich bin mir sicher (und hoffe es!), dass wir in Zukunft einen Aha-Effekt haben wenn wir auf das Jahr 2013 zurückblicken. Ungefähr so, wie wenn man heute mit einem älteren Firefox surft und sich wundert warum man damals so begeistert über dessen Geschwindigkeit war.
Da vieles bereits in ein paar Monaten obsolet ist, lass ich Protokolldetails aus und spreche nur ein paar Grundpfeiler des neuen Protokolls an. Die Drafts finden sich ja im Netz.

Eine Verbindung statt vieler Einzelabfragen
Einer der Hauptkritikpunkte an HTTP 1.1 ist die mangende Unterstützung persistenter Verbindungen. Keep-Alive ist genau genommen eine Krücke, die nur flickt, aber das Grundproblem nicht löst. Fehler kann man den Machern aber auch schwer vowerfen: 1999 wäre es auch komplett praxisfern gewesen, persistente bidirektionale Verbindungen in das Protokoll mit aufzunehmen. Im selben Jahr erschien der Internet Explorer 5 und brachte XHRequests (…wenns sein muss: Ajax) über ActiveX mit.
Nachdem heute immer mehr Anwendung in den Browser wandern, die früher ausschliesslich auf dem Desktop zu finden haben, stellen sich ganz andere Anforderungen an das Kommunikationsprotokoll. Die meisten Inhalte werden zur Laufzeit dynamisch nachgeladen, der Browser will jetzt vom auch mal Server wissen wann ein Ereignis eintritt und Antworten vom Server sind nicht mehr komplette HTML Seiten oder Bilder, sondern bestehen oft aus kleinen, z.B. JSON-kodierten Datenfetzen. HTTP bremst hier den Browser merklich aus: Vor allem bei kleinen Antworten die Anfragegröße (durch die vielen HTTP Header, die mitgeschickt werden) um ein vielfaches größer als die Antwort des Servers. Zusätzlich bremst jede offene Anfrage den Browser aus, da pro Verbindung nur eine Anfrage laufen kann: Sind alle Verbindungen dicht, muss der Browser warten. SPDY – und damit auch der aktuelle HTTP 2 Entwurf – setzt hier an, indem es die Anfragen transparent (d.h. eine Schicht unter HTTP) in eine SPDY Anfrage verpackt und über eine einzige, permanent geöffnete Verbindung verschickt. Ausserdem spielt hier kompression von Anfragen und Antworten eine zentrale Rolle und gilt als Normalzustand.
Trennung von Session und Applikationsschicht
Ja, jetzt sind wir beim Schichtenmodell. Aber ich mach es kurz: Da HTTP 2.0 Abwärtskompatibel bleiben soll (zumindest vorerst), wird es in zwei Teile aufgetrennt (wie es in SPDY auch schon der Fall ist): Der Framing Layer kümmert sich darum, wie die Daten wirklich in Frames gepackt, komprimiert und verschickt werden und übernimmt sich um die eigentliche Kommunikation (meist wohl über TCP). In der HTTP Schicht darüber wird dann das uns bekannte HTTP gesprochen, z.B. HTTP 1.1. Damit bleibt man einerseits abwärtskompatibel und hält die Logik des Streams aus dem HTTP Protokoll heraus. Jedem sollte aber klar sein: ‘Einfach so’ einen rudimentären HTTP 2 Client oder Server zu schreiben ist jetzt viel Aufwendiger als es mit HTTP 1.1 der Fall war.
Verschobene Machtverhältnisse
Persistenten Kanäle liefern Server Push quasi out-of-the-box mit – zusätzliche Protokolle wie WebSockets werden damit (hoffentlich) obsolet. Interessant wird da der Einfluss auf die serverseitige Webprogrammierung – nicht nur aktuelle Request/Response-Programmiermodelle werden damit zum Teil schlagartig veraltet, auch das Machtverhätlnis im Internet wird hier stark verschoben, wenn beide Kommunikationspartner gleichberechtigt sind.
Natürlich gibt es noch viele weitere Punkte (z.B. einen Time-Memory Tradeoff bei den Headern) in dem Draft, allerdings glaube ich die wichtigsten Punkte zusammengefasst zu haben. Ich find die Ansätze sehr gut und bin gespannt, wie sich HTTP 2.0 noch entwickelt (und vor allem was an eigentlich sinnvollen Features rausfällt, weil sie in der Praxis Probleme bereiten würden…).
Für alle, die die aktuelle Entwicklung mitverfolgen wollen empfehle ich die Mailingliste der HTTP Workingroup (die ist wirklich interessant!).
Für alle, die darauf keinen Bock habe fasse ich zusammen: Wir leben in einer spannenden Zeit! Da SPDY von vielen größeren (auch nicht-google) Diensten bereits verwendet wird, ist die Zukunft näher als man denkt.