Wie geht es weiter mit SPDY und HTTP/2?

[maltris]

Guten Tag,

hiermit möchte ich eine kleine Diskussionsrunde einberufen, in der ein paar Weise Ihren Kenntnisstand mitteilen können was HTTP/2 und SPDY angeht.

Mein aktueller Stand ist:

- HTTP/2 ist kurz vor der RFC-Veröffentlichung
- Google hat SPDY abgesagt, mergt mit HTTP/2 und wird den Support 2016 beenden

Wann können wir mit den ersten Webserver-Implementierungen (speziell bei Nginx und Apache) von HTTP/2 rechnen?

Danke schonmal,

ein Geschwindigkeitssuchti

 

[Deleted member 15972]

Moment, da gehe ich mal in den Keller und suche meine Kristallkugel.
Ernsthaft, niemand kann jetzt schon sagen: "ja, morgen sind wir fertig mit der Implementation". Allerdings sind das Open Source Projekte, Du kannst Dich also - wenn es Dir nicht schnell genug geht - auch einbringen.

Alternativ könntest Du mal direkt bei der jeweiligen Community anfragen, vielleicht arbeiten Devs schon daran.
Dann dauert es aber häufig noch, bis die Pakete in einigen Distributionen verfügbar sind.
Im Zweifel müsstest Du dann eben selbst kompilieren.

 

[d4f]

Google hat SPDY abgesagt, mergt mit HTTP/2 und wird den Support 2016 beenden

Das klingt als würde Google (als Erfinder von SPDY) das Protokoll einstampfen. Natürlich hat Google aber nicht diese Macht - wenngleich die Entfernung der Kapabilität in Chrome einem Todesstoß ähnelt.

Wann können wir mit den ersten Webserver-Implementierungen (speziell bei Nginx und Apache) von HTTP/2 rechnen?

Gegenfrage; willst du wirklich die ersten Implementierungen einsetzen?

Insgesamt stimme ich aber @Orebor zu: es ist nicht sehr sinnvoll im Voraus auf mögliche Daten und Untersützung zu spekulieren. Die Implementierungen (abseits von Experimenten) werden wohl erst nach Standardisierung anfangen und können ein paar Monate zu einer fertiggestellten und funktionellen Software dauern.

 

[MadMakz]

Das klingt als würde Google (als Erfinder von SPDY) das Protokoll einstampfen. Natürlich hat Google aber nicht diese Macht - wenngleich die Entfernung der Kapabilität in Chrome einem Todesstoß ähnelt.
...

SPDY ist, in leicht abgewandelt und gefixter Version (SPDY4), Transportlayer für HTTP/2.

SPDY wird es lediglich nicht mehr als Standalone geben sondern als fester Bestandteil von HTTP/2 (die Initiative ging von Google selbst aus)

Oder um es kurz zu sagen; Google stampft die "Marke" SPDY ein, das Konzept lebt aber weiter unter HTTP/2.


In Firefox (ab 35) ist HTTP/2 draft bereits aktiviert, in Chrome via chrome://flags und schalter HTTP/2 (bzw. SPDY/4) aktivieren.

 

[d4f]

Google stampft die "Marke" SPDY ein

SPDY ist nichtsdestotrotz ein offenes Protokoll und kann nicht eingestampft werden. Sollten andere SPDY-Implementierer wie Microsoft oder Amazon es weiter verwenden wollen, kann niemand sie daran hindern.


Seit heute gilt HTTPv2 ja als finaler Standard der IETF und in Kürze als RFC.

 

[MadMakz]

Keiner stampft SPDY ein, lediglich den Namen....HTTP/2 ist SPDY/4 + Microsoft und Amazon sind ebenfalls aktiv an der Entwicklung des HTTP/2 (somit auch SPDY) Standarts beteiligt.

IIS wird HTTP/2 in Windows 10 unterstützen.

SPDY großartig zu forken wird wenig Sinn machen wenn man es nicht dahingehend weiterentwickelt um im nächsten Draft, z.B. HTTP/2.1, berücksichtigt zu werden oder als rein internes Transferprotokol zu benutzen.

Andernfalls bekommt man eine inkonsitenz und inkompatibilität des Internets wenn jeder Webserver jetzt seine eigene, nicht RFC konforme, SPDY Version fährt.

Das wäre so als wenn jeder HTTP auf einem random Port abseits von 80/443 fahren würde. Woher soll der Browser dann wissen welchen Port er unter Domain XY ansprechen soll?

In HTTP/1 gab es so etwas aus diesem Grund auch nicht.

 

[d4f]

Keiner stampft SPDY ein, lediglich den Namen

Ein offener Standard kann nicht eingestampft werden, auch nicht sein Name! Google als Erfinder, Promoter und Entwickler hat lediglich Weiterentwicklungen eingestellt und entfernt es aus deren eigenem Web-Browser (vermutlich aber bis auf Weiteres noch nicht aus deren Web-Server)

Das wäre so als wenn jeder HTTP auf einem random Port abseits von 80/443 fahren würde.

Etwas OT, aber das wäre über SRV REcords realisierbar. Zumindest Mozilla hat einen Patch dahingehend "pending review"; https://bugzilla.mozilla.org/show_bug.cgi?id=14328

SPDY großartig zu forken wird wenig Sinn machen wenn man es nicht dahingehend weiterentwickelt

Wer sagt was von weiterentwickeln? Es geht rein um den aktuellen Stand welcher nicht grade schlecht ist.
Rein um die aktuellen SPDY-unterstützenden Geräte/Libraries welche kein HTTPv2 reden können zu unterstützen wird es ja eh notwendig sein wenn man sie nicht in die "Steinzeit" von HTTPv1.1 zurückfallen lassen will.
Insbesondere auf mobilen Endgeräten oder einkompilierten Libraries wird es ansonsten zu einem Problem.

In HTTP/1 gab es so etwas aus diesem Grund auch nicht.

Das Argument ist aber nun bei den Haaren herbei gezogen, schliesslich würde schon dieses Forum ohne HTTP1-Erweiterungen im Browser gar nicht funktionieren. Such mal nach dem Stichwort "Cookie" in den HTTP 1.0 und HTTP 1.1 RFC's

 

[MadMakz]

Wenn wir hier über SPDY und HTTP sprechen reden wir über den Transportlayer. Cookies gehören aber zu Inhalten und standen erstmals 1997 in einem RFC, kurz nach HTTP/1 (1996).

Google entfernt garnichts aus Chrome SPDY wird in richtung HTTP/2 Norm gepatcht https://groups.google.com/forum/#!topic/spdy-dev/EWEEWSYtlhc/discussion bis der Name dann irgendwann ganz verschwindet.

Der unterschied zwischen SPDY und HTTP/2 ist das HTTP/2 genormt und gefixt ist, SPDY nicht.

Es bringt nichts SPDY weiter zu supporten wenn die mehrheit einsieht das HTTP/2 das überlegenere Protokoll ist. Das war ja auch Googles idee hinter SPDY, die Leute zu motiviren ein besseres HTTP Transportstandart zu entwickeln. SPDY war lediglich der Anstoß, keine Norm.

Fallback HTTP/2 zu HTTP/1.1 ist https.


Ist ja auch egal, um mal auf OP zurück zu kommen: https://github.com/http2/http2-spec/wiki/Implementations

Wann nginx und Apache HTTP/2 im Kern unterstützen werden weiß keiner.

 

[cider]

Google hat ja schon bekannt gegeben das sie die SPDY-Unterstützung Anfang 2016 aus Chrome entfernen werden. Mozilla wird wohl auch in 2016 nachziehen. Es ist m.E. daher unnötig weiter über die Zukunft von SPDY nachzudenken, SPDY hat keine Zukunft. Es macht heutzutage doch auch keinen Sinn groß über die Einführung von TLS 1.0 nachzudenken wobei es schon längst TLS 1.2 gibt.

Ich denke HTTP/2 wird relativ schnell in nginx unterstützt werden (erste Hälfte 2015) da schon länger SPDY 3.1 unterstützt wird und die Änderungen zu HTTP/2 nicht allzu groß sind. Die Arbeiten daran sind sicher nicht erst gestern mit der offiziellen Standardisierung aufgenommen worden.

Die Unterstützung im Apache Webserver wird sicherlich wesentlich länger dauern. Aktuell gibt es für Apache 2.2 noch ein altes, nicht mehr weiterentwickeltes mod_spdy welches nicht standardmäßig aktiv ist. Für den aktuellen Apache 2.4 gibt es aber immer noch keine richtige Möglichkeit um SPDY zu unterstützen.
Noch vor einem halben Jahr hieß es auf der Apache-Mailingliste das *nicht* an SPDY/HTTP2 gearbeitet wird! Nur wenn Apache sich entscheiden sollte eine externe Implementierung wie z.B. nghttp2 einzubinden können wir meiner Meinung nach mit einer HTTP/2 Unterstützung noch innerhalb von 2015/2016 rechnen.

 

[MadMakz]

In letzter zeit ist es ruhig geworden bei nginx und apache bezgl. HTTP/2.Ich denke das die beiden erst einmal abwarten wollten bis HTTP/2 verabschiedet ist und die Rahmenbedingungen feststehen.
nginx ist schließlich auch ein großer befürworter von HTTP/2.

Ich tippe mal auf mainline 1.8/9 bei nginx. Bei Apache ka. Kann die Leute da nur schlecht einschätzen.

Am meisten würde es mich aber interessieren ob es dann auch Backports geben wird, wie zuletzt mit forward secrecy (Apache), Falls nicht wird es sowieso noch eine ganze Weile dauern bis HTTP/2 die Massen erreichen wird.

Wundern tut es mich aber das weder bei Apache noch bei nginx HTTP/2 überhaupt in der Roadmap steht. Oder ich bin nur blind.

 

[d4f]

Wenn wir hier über SPDY und HTTP sprechen reden wir über den Transportlayer.

Zumindest nach OSI-Modell ist sowohl SPDY als auch HTTP application-layer, nicht transport. Der Transportlayer von HTTP, also TCP, wird gott sei dank nicht auch noch umgebaut.

Cookies gehören aber zu Inhalten und standen erstmals 1997 in einem RFC, kurz nach HTTP/1 (1996).

Nichtdestotrotz sind Cookies NICHT Bestandteil von HTTP1 oder HTTP1.1 - mein Punkt steht also weiter. Übrigens wurde DNS über TCP 1987 festgelegt, die Telekom-Resolver können es trotzdem nicht.

Google entfernt garnichts aus Chrome SPDY wird in richtung HTTP/2 Norm gepatcht

Du hast übersehen dass der Artikel von 2013 ist, also als noch die HTTPv2-Festlegung in vollem Gange war. Es war sinnvoll SPDY-Weiterentwicklungen an den bereits festgelegten / optimierten HTTPv2-Features zu orientieren da die SPDY-Entwickler maßgeblich an HTTPv2 beteiligt sind.
Aktuell wird SPDY natürlich nicht mehr weiterentwickelt und, ja, in Zukunft aus Chrome entfernt. Patchen kann man einen Standard übrigens nicht.

Der unterschied zwischen SPDY und HTTP/2 ist das HTTP/2 genormt und gefixt ist, SPDY nicht.

Normen werden nicht nur von der IEEE/IETF/IANA festgelegt. Industriestandards und -normen können, wie hier von Google bei Spdy, von jedermann veröffentlicht und als "best practice" von Anderen implementiert werden.

Ich tippe mal auf mainline 1.8 bei nginx

Vermutlich deutlich früher via Module - Nginx ist dahingehend ja sehr flexibel und auch SPDY war/ist "nur" ein Modul welches nach Bedarf kompiliert werden kann. Allein die schnelle und stabile Entwicklung bei Nginx sowie oft sehr sauberen Implementierungen sind schon Grund genug, Nginx als reverse-proxy zu betreiben.

 

[MadMakz]

Applikations-Protokol meinte ich auch die ganze Zeit, Sorry.

Mit Cookies im HTTP Standart hast du angefangen nicht ich.

Standarts werden gepatcht indem man eine neue Major-Draft absetzt. SPDY/2...SPDY/3.1...SPDY/4..., HTTP/1...HTTP/1.1...HTTP/2.

Was die IETF verabschiedet ist zu befolgen wenn man 100%ige Kompatibilität im WWW erreichen will. Ob man Sie befolgt ist eine andere Frage.

Wenn die DTAG nicht auf TCP lauschen will ist es deren Problem und keine Referenz dazu ob man TCP bei DNS weglassen muss. (RFC von 2010 spricht das Problem auch noch einmal explizit an)

Genau so verhält es sich mit ISO normen. Z.B. Brandschutz. Befolge sie und du bekommst dein Zertifikat und Versicherungsschutz, tu es nicht und dir brennt die Bude ab/musst selbst Zahlen weil versicherung sagt "Nö, die Löschanlage entsprach keiner Norm die wir vorgaben".

Solange nichts Gesetzlich festgelegt ist musst keiner Prinzipiell irgend etwas von irgend jemandem befolgen.
Auf dauer wird das dann aber mit Sicherheit ziemlich chaotisch nicht?
Stell dir mal vor es würde keine freiwillige (ISO) Norm für z.B. Schraubenschlüssel geben.
Nebenbei würdest du Monopole fördern. Wirtschaft- und Verbrauchermäßig nicht gerade vorteilhaft würde ich mal meinen.

Module wären möglich (ich bin mir nicht sicher aber bei Apache ist glaube ich sogar HTTP ein modul was theoretisch abgeschaltet werden kann).
Edit: jup: --disable-http

 

[d4f]

Mit Cookies im HTTP Standart hast du angefangen nicht ich.

Ich glaube mein Punkt wurde missverstanden. Hiermit wurde/wird demonstriert dass ein gesetzter Standard sehr wohl in der Realität erweitert wird oder sich, wie im Beispiel der Cookies, sogar RFC's aus gängigen Industrie-Standards ableiten. Zu sagen "X gab es in Standard Y" nicht mag also korrekt sein, entspricht aber nicht der darauf basierenden best-practice im Internet.

Stell dir mal vor es würde keine freiwillige (ISO) Norm für z.B. Schraubenschlüssel geben.

Viel schlimmer würde ich es finden wenn die EU-Norm zur Bananenimport-Regulierung wegfallen würde. Dann könnte eine Banane ja glatt so krumm oder gerade sein wie sie wollte. Chaos pur!

 

[MadMakz]

Richtig, und HTTP/2 hat sich aus SPDY abgeleitet und erweitert, etwas anderes habe ich nie gesagt.
Quasi alle Normen kommen erst einmal aus der Industrie welche dann meistens in Zusammenarbeit erweitert oder verbessert werden und am ende als übergreifende Norm erlassen bzw empfohlen werden und auch scheitern können. Z.B. BluRay vs. HDDVD, h264 vs mpeg-4..
Sowie erweitert werden 650MB vs 700MB CD, VCR Longplay vs Shortplay..

Wenn jetzt jemand daher kommt und noch etwas besseres aus SPDY/3.1 oder gänzlich etwas anderes macht kann das unter Umständen zu HTTP/3 werden.

Keiner sagt das es verboten ist basierend auf SPDY weiter zu entwickeln (mal abgesehen davon das das bei quelloffenem Code ziemlich unmöglich wäre), lediglich das Google dabei nicht mehr mit macht.
Nur gibt es dann erst mal nicht die Garantie das du es mit Browser X ohne Änderung od. Addon benutzen kannst. vgl. Tor.

Und wenn ich mich recht erinnere ist die Bananen-Norm eine Gesetzliche und keine empfohlene Richtlinie. So dämlich Sie auch ist passt das Beispiel hier nicht ganz in's Topic.
Normen sind gut wenn auch nicht Perfekt.
Zudem bleibt Banane auch Banane. SPDY vs. HTTP ist eher Äpfel vs. Birnen oder Schlüssel und Schlüsselloch.

The goal of the Working Group is that typical uses of HTTP/1.x can use HTTP/2 and see some benefit. Having said that, we can’t force the world to migrate, and because of the way that people deploy proxies and servers, HTTP/1.x is likely to still be in use for quite some time.

 

[cider]

Nginx hat gestern einen Blogpost veröffentlicht in dem sie zwar sagen das sie "die Vorreiterrolle bei HTTP/2" einnehmen wollen aber schreiben weiter nur das der HTTP/2 support für dieses Jahr geplant ist: http://nginx.com/blog/how-nginx-plans-to-support-http2/

Ich hätte jetzt eine etwas konkretere Ankündigung zumindest für die erste Hälfte des Jahres erwartet

 

[Deleted member 11740]

Ein offener Standard kann nicht eingestampft werden, auch nicht sein Name! Google als Erfinder, Promoter und Entwickler hat lediglich Weiterentwicklungen eingestellt und entfernt es aus deren eigenem Web-Browser (vermutlich aber bis auf Weiteres noch nicht aus deren Web-Server)

Was passiert mit einem alten Standard, der in einer neueren Fassung in einem anderen Standard implementiert worden ist und der alte Standard nicht mehr genutzt und auch nicht mehr weiter entwickelt wird?

HTTP/2 wird sich sehr schnell durchsetzen. Die ersten Clients und Server gibt es bereits. Der neue Standard wird sich sehr schnell durchsetzen. Warum sich der Standard schnell durchsetzen wird, liegt einfach an positiven Nebeneffekten. For free bekommt man aufeinmal eine Optimierung. Besser geht es doch gar nicht.

 

[elias5000]

Der neue Standard wird sich sehr schnell durchsetzen.

So schnell wie HTML5, TLS1.x und IPv6?
(SCNR)

 

[MadMakz]

So schnell wie HTML5, TLS1.x und IPv6?
(SCNR)

Schlechte Beispiele denke ich aber dennoch irgendwie richtig.

HTTP/2 ist u.a. eine Performanceoptimierung. HTML5, TLS und IPv6 haben diese Eigenschaft nicht. Daher aus Wirtschaftlicher sicht uninteressant.

HTML5 ist eine (Halberzig umgesetzte) Funktionserweiterung (noch immer kein Majorbrowser der 100% dem HTML5-Standart folgen kann). Und an den Drafts wird glaube ich Täglich rumgekritzelt.

IPv6 ist aus der Not entstanden und wurde sehr schnell verfügbar sobald es dann notwendig wurde. Bis dahin wurde es 12(?) Jahre lang stetig Optimiert und implementiert so das man als Alltagsnutzer am Tag X eigentlich garnichts mitbekommen hat (Außer man ist Kunde bei Unitymedia).

TLS ist quasi das IPv6 in der Verschlüsselung.
Bis man herausfand das SSL unsicher ist hatte es wenig bedeutung. Dieses Blatt hat sich vor allem in den letzten zwei Jahren schlagartig gedreht.

Dennoch gebe ich dir Recht das es sehr wahrscheinlich noch dauern wird.

HTTP/2 wird sich meiner Meinung erst völlig durchsetzen wenn sich Litespeed, Apache, Nginx und IIS dazu entschließen HTTP/2 als Standartoption zu setzen bzw. als einzige Option mit bekanntlichem HTTP/1.1 Fallback, und dies die Enterprise Level erreicht (sprich Windows, Linux Enterprise/LTS) und nicht zu vergessen; bis Parallels Plesk es kann.

Da sehe ich nichts großartiges vor 2020-2025 (Rhel 7 EOL = 2024) da ich davon ausgehe das es keine HTTP/2 Stable-Backports geben wird.

 

[maltris]

Ich hab gelesen, dass es wohl stable erst Ende diesen Jahres wird. Also ist noch ein bisschen Geduld angesagt. Vielleicht gibt es eine benutzbare Beta-Version schon früher? Wer weiß ...

 

[remote_mind]

For free bekommt man aufeinmal eine Optimierung. Besser geht es doch gar nicht.

Das wird sich zeigen. Vorraussetzung für SPDY war die verschlüsselte Übertragung (und damit ein passendes SSL-Zertifikat). Bei HTTP/2 wird es wohl Browser geben, die das nur verschlüsselt mitmachen[1]

Für Seiten die eh schon https:// anbieten kein Problem, für andere würde es schon Kosten verursachen. Und eine Seite mit viel Traffic auf _nur_ TLS umzustellen kostet auch CPU...

Was die Einführung angeht, irgendwann wird Google sagen 'oh by the way, our next search engine update will score sites with HTTP/2 slightly higher', dann wirst Du sehen wie sie alle springen werden

So ähnlich wie Google den Tausch auf SHA-256-Zertifikate vorangetrieben hat, in dem sie einfach ihre Marktmacht spielen lassen (in dem Fall über Chrome).

[1] https://wiki.mozilla.org/Networking/http2 "Firefox will only be implementing HTTP/2 over TLS..."