Meine Herren!
Google hat nun ein mod_spdy für den Apache Webserver bei der Apache Foundation eingereicht. Es ist also absehbar, dass dieses Modul demnächst in der Praxis auftaucht, zumal SPDY von aktuellen Browsern anscheinend breit unterstützt wird.
Und SPDY fließt in HTTP 2.0 ein, also die noch ein Grund mehr, das im Auge zu behalten. Meine Erkenntnisse im folgenden basieren auf Halbwissen und sind mit Vorsicht zu genießen, ich versuche natürlich trotzdem nur nach bestem Gewissen zu antworten.
Muss ich mich beim Erstellen von PHP-Scripten damit befassen, ob das alles mit SPDY oder mit herkömmlichen HTTP 1.0/1.1 übertragen wird?
Immerhin will ich in PHP einen einzelnen Request beantworten, und nicht mehrere auf einmal.
Das ist richtig. Aber dein PHP-Skript wird vermutlich HTML ausliefern, der generierte HTML-Code wird den Browser veranlassen neue Anfragen zu schicken, für Stylesheets, Skripte, Bilder usw. Aktuell muss der Browser für jede dieser Anfragen eine eigene HTTP-Anfrage senden, die wiederum mit einer eigener TCP-Verbindung korrespondiert. Mit SPDY wird der Browser weiterhin eine HTTP-Anfrage je Ressource schicken, aber hintergründig kann die selbe, bestehende TCP-Verbindung für alle Anfragen genutzt werden.
Oder kann dieses SPDY auf der Serverseite mehrere Requests "simulieren"?
SPDY kann Daten an den Browser senden, ohne dass dieser jedesmal eine Anfrage zu schicken braucht. (Server-Push).
Oder ist das Ganze nur eine Art Wrapper für die Verbindung selbst, innerhalb derer auf Anwendungsseite wie gewohnt einzelne Requests in üblicher Manier mittels HTTP einzeln abgearbeitet werden?
Die Betrachtung ist ganz gut, HTTP-Anfragen kommen an, werden bearbeitet und beantwortet wie zuvor. Aber im Hintergrund wird nicht jedesmal eine TCP-Verbindung benötigt. Ähnlich ist ja bei HTTP 2.0 Abwärtskompatibilität spielt bei der Spezifikation eine enorm wichtige Rolle, deshalb bleiben bestehende Semantiken so gut wie unangetastet.
“All right, then, I'll go to hell.” – Huck Finn