© saicle/Shutterstock.com
PHP Magazin
Server-Push und bidirektionale Kommunikation mit WebSockets

Server-Push und bidirektionale Kommunikation mit WebSockets

Benutzer wollen über neue Ereignisse, wie beispielsweise das Eintreffen einer Nachricht, benachrichtigt werden oder sich online über ihre Webseite austauschen. Wenn aktualisierte Daten den Benutzern sofort angezeigt werden sollen und nicht erst beim nächsten Seitenaufruf, dann muss der Server die Kommunikation anstoßen. Das Web hat diesen Fall aber nicht vorgesehen - die Kommunikation wird immer vom Client initiiert. Was also tun?

Arno Hollosi


In den vergangenen Jahren haben sich für die bidirektionale Kommunikation zwischen Server und Client (teils recht abenteuerliche) Verfahren unter dem Überbegriff Comet etabliert, die den Eindruck einer servergesteuerten Kommunikation erwecken: Forever Frame, Continuous Polling, HTTP-Streaming, XHR-Streaming, Long Polling, Implementierung in Flash, XHR-Multipart, -Long-Polling etc. Jede dieser Technologien hat Vor- und Nachteile. Moderne Browser bieten mit WebSockets endlich eine standardisierte Methode an.

Mit WebSockets können Browser und Server Nachrichten austauschen, ohne sich an den Anfrage-Antwort-Zyklus halten zu müssen; zudem handelt es sich um eine persistente Verbindung, ein ständiger Verbindungsauf- und -abbau entfällt. Damit kann der Server jederzeit Nachrichten an den Browser senden. Diese lösen im Browser Events aus, worauf mit JavaScript reagiert werden kann. Umgekehrt kann der Browser beliebig Nachrichten über die bestehende WebSocket-Verbindung an den Server senden. WebSockets sind damit echten TCP/IP-Verbindungen sehr ähnlich.

Die WebSocket-Spezifikation ist mittlerweile über drei Jahre alt und hat einige Überarbeitungen erfahren. Insbesondere Sicherheitsbedenken haben Änderungen im Protokoll bedingt. Inzwischen ist WebSocket eine Candidate Recommendation des W3C [1] und ein Proposed Standard RFC [2]. WebSocket wird aktuell von Firefox, Chrome, Opera und Safari unterstützt, Internet Explorer wird WebSocket ab Version 10 unterstützen. Safari implementiert derzeit leider nur eine ältere, unsichere Version des Protokolls [3].

Handshake

Das WebSocket-Protokoll nützt eine bestehende (oder zu diesem Zweck geöffnete) HTTP-Verbindung. Aus diesem Grund besteht das Protokoll aus zwei Phasen, wie in Abbildung 1 zu sehen: dem Handshake zu Beginn, der den Wechsel vom HTTP-Protokoll zum WebSocket-Protokoll aushandelt (Listing 1), und der WebSocket-Datenverbindung, sobald das Protokoll gewechselt worden ist.

Abb. 1: Übersicht über den Ablauf des WebSocket-Protokolls

Der Protokollwechsel zu Beginn wird vom Client eingeleitet, indem er über die HTTP-Header Upgrade und Connection den Umstieg auf das WebSocket-Protokoll einleitet. Listing 1 führt die wichtigsten HTTP-Header des Handshake auf. Der Client sendet zusätzlich zu den beiden erwähnten Headern den Origin-Header sowie eine Zufallszahl (Sec-WebSocket-Key) mit. Über den Origin-Header kann serverseitig der Zugriff kontrolliert werden. Der Server setzt bei erfolgreicher Antwort seinerseits die Upgr...

PHP Magazin
Server-Push und bidirektionale Kommunikation mit WebSockets

Server-Push und bidirektionale Kommunikation mit WebSockets

Benutzer wollen über neue Ereignisse, wie beispielsweise das Eintreffen einer Nachricht, benachrichtigt werden oder sich online über ihre Webseite austauschen. Wenn aktualisierte Daten den Benutzern sofort angezeigt werden sollen und nicht erst beim nächsten Seitenaufruf, dann muss der Server die Kommunikation anstoßen. Das Web hat diesen Fall aber nicht vorgesehen - die Kommunikation wird immer vom Client initiiert. Was also tun?

Arno Hollosi


In den vergangenen Jahren haben sich für die bidirektionale Kommunikation zwischen Server und Client (teils recht abenteuerliche) Verfahren unter dem Überbegriff Comet etabliert, die den Eindruck einer servergesteuerten Kommunikation erwecken: Forever Frame, Continuous Polling, HTTP-Streaming, XHR-Streaming, Long Polling, Implementierung in Flash, XHR-Multipart, -Long-Polling etc. Jede dieser Technologien hat Vor- und Nachteile. Moderne Browser bieten mit WebSockets endlich eine standardisierte Methode an.

Mit WebSockets können Browser und Server Nachrichten austauschen, ohne sich an den Anfrage-Antwort-Zyklus halten zu müssen; zudem handelt es sich um eine persistente Verbindung, ein ständiger Verbindungsauf- und -abbau entfällt. Damit kann der Server jederzeit Nachrichten an den Browser senden. Diese lösen im Browser Events aus, worauf mit JavaScript reagiert werden kann. Umgekehrt kann der Browser beliebig Nachrichten über die bestehende WebSocket-Verbindung an den Server senden. WebSockets sind damit echten TCP/IP-Verbindungen sehr ähnlich.

Die WebSocket-Spezifikation ist mittlerweile über drei Jahre alt und hat einige Überarbeitungen erfahren. Insbesondere Sicherheitsbedenken haben Änderungen im Protokoll bedingt. Inzwischen ist WebSocket eine Candidate Recommendation des W3C [1] und ein Proposed Standard RFC [2]. WebSocket wird aktuell von Firefox, Chrome, Opera und Safari unterstützt, Internet Explorer wird WebSocket ab Version 10 unterstützen. Safari implementiert derzeit leider nur eine ältere, unsichere Version des Protokolls [3].

Handshake

Das WebSocket-Protokoll nützt eine bestehende (oder zu diesem Zweck geöffnete) HTTP-Verbindung. Aus diesem Grund besteht das Protokoll aus zwei Phasen, wie in Abbildung 1 zu sehen: dem Handshake zu Beginn, der den Wechsel vom HTTP-Protokoll zum WebSocket-Protokoll aushandelt (Listing 1), und der WebSocket-Datenverbindung, sobald das Protokoll gewechselt worden ist.

Abb. 1: Übersicht über den Ablauf des WebSocket-Protokolls

Der Protokollwechsel zu Beginn wird vom Client eingeleitet, indem er über die HTTP-Header Upgrade und Connection den Umstieg auf das WebSocket-Protokoll einleitet. Listing 1 führt die wichtigsten HTTP-Header des Handshake auf. Der Client sendet zusätzlich zu den beiden erwähnten Headern den Origin-Header sowie eine Zufallszahl (Sec-WebSocket-Key) mit. Über den Origin-Header kann serverseitig der Zugriff kontrolliert werden. Der Server setzt bei erfolgreicher Antwort seinerseits die Upgr...

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