{"id":23781,"date":"2023-02-01T17:49:00","date_gmt":"2023-02-01T16:49:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=23781"},"modified":"2023-06-18T17:25:11","modified_gmt":"2023-06-18T15:25:11","slug":"websockets-technischer-einblick-und-performance-vergleich","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/02\/01\/websockets-technischer-einblick-und-performance-vergleich\/","title":{"rendered":"WebSockets: Technischer Einblick und Performance-Vergleich"},"content":{"rendered":"\n

In diesem Artikel wird ein kurzer Blick auf die zu Grunde liegende, technische Funktionsweise von WebSockets geworfen und ihre Performance im Vergleich zu HTTP und Server-sent Events (SSE) untersucht, wodurch letztlich das Potenzial von WebSockets eruiert werden kann.<\/p>\n\n\n\n

Hintergrund & Entstehung<\/h2>\n\n\n\n

In der Vergangenheit war es bei Webanwendungen nur unter unsachgem\u00e4\u00dfer Verwendung des Hypertext Transfer Protokolls (HTTP) realisierbar, eine bidirektionale Verbindung zwischen Client und Server herzustellen. Dabei sind folgende Probleme entstanden: (1.) Der Server muss verschiedene Transmission Control Protocol (TCP) Verbindungen f\u00fcr jeden Client nutzen. Eine, um Informationen zum Client zu senden, und eine neue f\u00fcr jede eintreffende Nachricht. (2.) Es gibt einen gro\u00dfen Overhead, da jede Client-to-Server Nachricht einen eigenen HTTP-Header hat. (3.) Das Client-seitige Skript muss sich merken, welche abgehenden Verbindungen zu welchen eingehenden Verbindungen geh\u00f6ren. Nur so k\u00f6nnen Antworten verfolgt werden. [vgl. 1]<\/p>\n\n\n\n

Eine bessere L\u00f6sung w\u00e4re eine einzige TCP-Verbindung f\u00fcr beide Richtungen \u2013 hier kommt der WebSocket-Standard ins Spiel. Der Standard setzt sich zusammen aus dem WebSocket-Protokoll und der WebSocket-API (WSAPI). Der WebSocket-Standard kann einen bidirektionalen Kommunikationskanal zwischen einer Webanwendung und einem Server herstellen. Es stellt dadurch eine Alternative zu allen bislang verwendeten, HTTP-basierten Kommunikationstechnologien dar. [vgl. 1]<\/p>\n\n\n\n

Im Jahr 2009 hat Google das WebSocket-Protokoll der Internet Engineering Task Force (IETF) als Draft vorgelegt [vgl. 2]. Die IETF ist ein weltweites Komitee, welches die Standardbetriebsprotokolle f\u00fcr das Internet definiert [vgl. 3]. Bis Mai 2010 [vgl. 4] wurde das Protokoll von Google und anderen weiterentwickelt und kontinuierlich verbessert. Nach einem zweimonatigen Stillstand hat die \u201eBiDirectional or Server-Initiated HTTP (HyBi)\u201c-Arbeitsgruppe \u2013 eine Gruppe der IETF \u2013 die Weiterentwicklung offiziell fortgef\u00fchrt. Im Dezember 2011 ist das WebSocket-Protokoll schlie\u00dflich unter dem Request for Comments (RFC) 6455 erschienen [vgl. 1]. Ein RFC ist die Form, in welcher die IETF die Standardbetriebsprotokolle formuliert [vgl. 3].<\/p>\n\n\n\n

Technische Funktionsweise<\/h2>\n\n\n\n

Opening-Handshake<\/h3>\n\n\n\n

Sobald im Browser eine WebSocket-Verbindung aufgebaut wird, findet durch den sogenannten Opening-Handshake zun\u00e4chst der Verbindungsaufbau statt. HTTP-basierend wird dabei ein WebSocket-Kanal er\u00f6ffnet. Ein beispielhafter HTTP-GET-Request ist nachfolgend zu sehen. [vgl. 5, S. 35]<\/p>\n\n\n\n

GET \/chat HTTP\/1.1<br>Host: server.example.com<br>Upgrade: websocket<br>Connection: Upgrade<br>Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==<br>Origin: http:\/\/example.com<br>Sec-WebSocket-Protocol: chat<br>Sec-WebSocket-Version: 13<\/code><\/p>\n\n\n\n

GET \/chat<\/strong> spricht den Endpunkt des WebSocket-Servers an. Ein Server kann dabei mehrere WebSocket-Endpoints besitzen. Mit Upgrade: websocket<\/strong> wird mitgeteilt, dass auf das Websocket-Protokoll umgestellt werden soll. Der eigentliche Wechsel passiert durch Connection: Upgrade<\/strong>. Im Header Sec-WebSocket-Key<\/strong> steht eine Zufallszahl. Mit ihr wird \u00fcberpr\u00fcft, ob der Server das WebSocket-Protokoll unterst\u00fctzt. \u00dcber den Origin<\/strong> kann der Client den Server dar\u00fcber informieren, von welcher Ursprungsdomain der Request gesendet wurde. Darauf basierend kann der Server entscheiden, ob er die Verbindung annimmt. \u00dcber den Header Sec-WebSocket-Protocol<\/strong> kann der Client dem Server optional mitteilen, welche Subprotokolle \u00fcber den WebSocket-Kanal verarbeitet werden k\u00f6nnen. Die Versionsnummer des WebSocket-Protokolls wird mit Sec-WebSocket-Version<\/strong> angegeben. Da die Reihenfolge der Header vom Client zuf\u00e4llig gew\u00e4hlt werden, spielt sie keine Rolle. Wenn ein Handshake-Request nicht alle notwendigen Felder liefert, wird keine Verbindung aufgebaut. [vgl. 5, S. 36 f.]<\/p>\n\n\n\n

Wird die Handshake-Anfrage vom Server akzeptiert, sendet er eine HTTP-Response an den Client [vgl. 5, S. 37]. Eine beispielhafte Response ist nachfolgend zu sehen. <\/p>\n\n\n\n

HTTP\/1.1 101 Switching Protocols<br>Upgrade: websocket<br>Connection: Upgrade<br>Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+0o=<br>Sec-WebSocket-Protocol: chat<\/code><\/p>\n\n\n\n

Diese Antwort enth\u00e4lt den Statuscode 101 Switching Protocols<\/strong>, wodurch best\u00e4tigt wird, dass der Protokollwechsel stattfinden kann. Der Wert f\u00fcr Sec-WebSocket-Accept<\/strong> wird folgenderma\u00dfen erstellt: Zun\u00e4chst wird ein Globally Unique Identifier (hier: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11<\/strong>) and den Sec-WebSocket-Key<\/strong> des Handshake-Requests angeh\u00e4ngt. Dadurch ergibt sich dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11<\/strong>. Aus dieser Zeichenkette wird unter Einsatz der kryptografischen Hashfunktion SHA-1 ein Hashwert erzeugt, welcher daraufhin mittels einer Base64-Codierung [vgl. 6] in einen Textstring umgewandelt wird. Dieser String ergibt den Wert des Headers Sec-WebSocket-Accept<\/strong>. Nun ist es dem Client m\u00f6glich, anhand des Sec-WebSocket-Keys<\/strong> und des Sec-WebSocket-Accepts<\/strong> zu \u00fcberpr\u00fcfen, ob die Antwort von dem richtigen WebSocket-Server kommt. Sofern in dem Opening-Handshake-Request Subprotokolle im Header Sec-WebSocket-Protocol<\/strong> angegeben wurden, teilt der Server im gleichnamigen Header der Response mit, welche Subprotokolle er unterst\u00fctzt \u2013 hier: chat<\/strong>. Es finden Verbindungsabbr\u00fcche statt, wenn angeforderte Subprotokolle nicht unterst\u00fctzt werden oder wenn der Server mit einem nicht-angefragten Subprotokoll antwortet. Nach erfolgreichem Ablauf aller genannten Schritte gilt der Handshake als abgeschlossen und der WebSocket-Kanal wurde aufgebaut. \u00dcber diesen Kanal k\u00f6nnen nun sequenzweise Daten in Form von sogenannten Frames in beide Richtungen geschickt werden. [vgl. 5, S. 37-39]<\/p>\n\n\n\n

Datentransfer<\/h3>\n\n\n\n

Die zu transportierenden Daten liegen als Sequenz von Frames vor. Die Protokollnachricht besteht \u2013 wie \u00fcblich \u2013 aus einem Header mit Kontrolldaten und den Nutzdaten im Payload. Ein vereinfachter Aufbau eines WebSocket-Frames ist in Abbildung 1 dargestellt. Aus dieser Darstellung ist auch abzulesen, wie schlank das WebSocket-Protokoll ist \u2013 im Vergleich zu HTTP. Der kleinste WebSocket-Frame, der vom Server zum Client gesendet wird, betr\u00e4gt 2 Bytes. Ist die Header-L\u00e4nge maximal, so betr\u00e4gt sie 14 Bytes. [vgl. 5, S. 39]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 1:<\/strong> Vereinfachter Aufbau eines WebSocket-Frames [vgl. 5, S. 39]<\/em><\/figcaption><\/figure>\n\n\n\n

WebSockets \u00fcbertragen Nutzdaten sequenzweise. Besondere Bedeutung hat dies, wenn Nutzdaten zum \u00dcbertragungszeitpunkt nicht vollst\u00e4ndig sind. Sie k\u00f6nnen daher weder in ein WebSocket-Frame eingef\u00fcgt werden, noch kann die Datenl\u00e4nge der Nutzdaten im Frame-Header angegeben werden. Dennoch besteht die M\u00f6glichkeit, in diesem Fall Daten zu \u00fcbertragen \u2013 n\u00e4mlich st\u00fcckchenweise. Das FIN<\/strong>-Bit des ersten Bytes gibt Auskunft dar\u00fcber, ob der Frame vollst\u00e4ndig ist. Trifft dies zu, so ist das Bit auf 1<\/strong> gesetzt, anderenfalls auf 0<\/strong>. Das FIN<\/strong>-Bit ist in Abbildung 1 zu erkennen. [vgl. 5, S. 42 f.]<\/p>\n\n\n\n

F\u00fcr alle Frames, die vom Client zum Server geschickt werden, gibt es aus Sicherheitsgr\u00fcnden eine Besonderheit: Sie m\u00fcssen maskiert werden. F\u00fcr jeden Frame muss der Client dazu eine neue, noch unverwendete 32-Bit-Zufallszahl generieren. Dieser sogenannte Masking-Key<\/strong> wird in das entsprechende Header-Feld gesetzt (siehe Abbildung 1). Mittels eines Algorithmus werden die Nutzdaten unter Verwendung des Masking-Keys<\/strong> maskiert. Das Demaskieren erfolgt auf Serverseite entsprechend umgekehrt. [vgl. 5, S. 43\u201345]<\/p>\n\n\n\n

Closing-Handshake<\/h3>\n\n\n\n

Ein Closing-Handshake kann sowohl vom Client als auch vom Server veranlasst werden und wird durch einem sogenannten Close-Frame gestartet. Haben sowohl Client als auch Server einen solchen Close-Frame empfangen und gesendet, gilt der Closing-Handshake als abgeschlossen. Der darunterliegende TCP-Kanal wird vom Server beendet. [vgl. 5, S. 53 f.]<\/p>\n\n\n\n

Performance-Vergleich<\/h2>\n\n\n\n

HTTP vs. WebSockets<\/h3>\n\n\n\n

In einem Blogpost auf Feathersjs.com vergleicht David Luecke die Performance von HTTP und WebSockets. Der Test-Server ist dabei auf Heroku gehostet und gibt auf einen Request ein JSON-Objekt zur\u00fcck. \u00dcber eine Webseite k\u00f6nnen eine festgelegte Anzahl von Requests durchgef\u00fchrt werden, w\u00e4hrend die daf\u00fcr ben\u00f6tigte Zeit gestoppt wird. [vgl. 7]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 2:<\/strong> Vergleich der ben\u00f6tigten Zeit f\u00fcr einen Request zwischen HTTP und WebSocket [vgl. 7]<\/em><\/figcaption><\/figure>\n\n\n\n

Die durchschnittliche Dauer eines einzigen HTTP-Requests betr\u00e4gt 107 Millisekunden, w\u00e4hrend ein einzelner WebSocket-Request 83 Millisekunden dauert (siehe Abbildung 2). F\u00fcr alle durchgef\u00fchrten Tests wird die Zeit, die ben\u00f6tigt wird, um die WebSocket-Verbindung herzustellen, nicht ber\u00fccksichtigt. Gr\u00f6\u00dfere Unterschiede zeigen sich, sobald mehrere parallele Requests durchgef\u00fchrt werden: 50 WebSocket-Requests dauern 180 Millisekunden, w\u00e4hrend f\u00fcr dieselbe Anzahl \u00fcber HTTP 5 Sekunden ben\u00f6tigt werden (siehe Abbildung 3). \u00dcber HTTP k\u00f6nnen ungef\u00e4hr 10 Requests pro Sekunden geschickt werden \u2013 bei WebSocket sind es knapp 4.000 Requests. Hauptgrund hierf\u00fcr ist, dass der Browser die Anzahl der gleichzeitigen HTTP-Verbindungen begrenzt. Bei Google Chrome \u2013 dem Testbrowser \u2013 liegt die Anzahl standardm\u00e4\u00dfig bei 6 Requests. Bei WebSockets gibt es solche Beschr\u00e4nkungen hingegen nicht. [vgl. 7]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 3:<\/strong> Vergleich der ben\u00f6tigten Zeit f\u00fcr 50 parallele Requests zwischen HTTP und WebSocket [vgl. 7]<\/em><\/figcaption><\/figure>\n\n\n\n

David Luecke hat auch die \u00fcbertragenen Datenmengen verglichen. Auch hier wird der initiale WebSocket-Verbindungsaufbau nicht ber\u00fccksichtigt. Ein HTTP-Request und -Response erzielt eine \u00dcbertragungsmenge von 282 Bytes. Unter Verwendung eines WebSockets liegt die entsprechende Datenmenge bei 54 Bytes (31 Bytes f\u00fcr den Request und 24 Bytes f\u00fcr die Response). Zu beachten ist jedoch, dass diese Differenz mit steigender Nutzdatenmenge (Payload) abnimmt, da die Header-Gr\u00f6\u00dfe bei HTTP gleichbleibend ist. [vgl. 7]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 4:<\/strong> Vergleich der bei einem Request \u00fcbertragenen Datenmenge zwischen HTTP und WebSocket [vgl. 7]<\/em><\/figcaption><\/figure>\n\n\n\n

Abschlie\u00dfend hat David Luecke Benchmark-Tests (Lasttests) durchgef\u00fchrt, um herauszufinden, ob und wie sich die bisherigen Ergebnisse ver\u00e4ndern, wenn mehrere Clients mit dem Server kommunizieren. Die Benchmarks laufen mit 100 gleichzeitigen Verbindungen und beinhalten auch die Verbindungsaufbauzeit des WebSockets. Wenn nur ein einziger Request pro Verbindung get\u00e4tigt wird, so ist HTTP etwa doppelt so schnell wie WebSocket. Bei 50 Requests pro Verbindung ist der WebSocket allerdings ca. 50 Prozent schneller. Bei einer hohen Anzahl an Requests pro Verbindung erzielen WebSockets also bessere Ergebnisse. [vgl. 7]<\/p>\n\n\n\n

Server-sent Events vs. WebSockets<\/h3>\n\n\n\n

Bei Server-sent Events (SSE) wird ein einzelner HTTP-Request kontinuierlich aufrechterhalten, um dar\u00fcber Updates zu schicken. Das bedeutet, dass Header nur einmalig \u2013 wenn der Request veranlasst wird \u2013 gesendet werden m\u00fcssen. Dadurch werden f\u00fcr jedes Update nur die notwendigen Informationen \u00fcbertragen, wodurch sich die Datenmenge reduziert. Ein weiterer Vorteil von SSE ist, dass sie sich im HTML5-Standard befinden. Das bedeutet: Bestehende Anwendungen k\u00f6nnen mit minimalem Aufwand nachtr\u00e4glich auf SSE umgestellt werden. Es ist jedoch zu beachten, dass SSE unidirektional funktionieren, das hei\u00dft Updates k\u00f6nnen nur vom Server zum Client gesendet werden \u2013 nicht andersherum. Eine Verbindung vom Client zum Server w\u00fcrde einen zus\u00e4tzlichen HTTP-Request ben\u00f6tigen. Laut einem Test von Alexis Abril schneiden SSE im Vergleich zu WebSockets \u00e4hnlich performant ab. Die Menge der \u00fcbertragenden Daten unterscheidet sich lediglich um wenige Kilobytes. Die Ergebnisse sind in Abbildung 5 dargestellt. Alexis Abril kommt zu dem Ergebnis, dass sich f\u00fcr die meisten Webanwendungen SSE aufgrund ihres geringeren Entwicklungsaufwands besser eignen. Falls jedoch h\u00e4ufig Daten vom Client zum Server geschickt werden m\u00fcssen, liefern WebSockets eine bessere Performance, wodurch der etwas h\u00f6here Implementierungsaufwand gerechtfertigt werden kann. [vgl. 8]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 5:<\/strong> Testergebnisse Vergleich zwischen Server-sent Events und WebSocket [vgl. 8]<\/em><\/figcaption><\/figure>\n\n\n\n

Vor- und Nachteile von WebSockets<\/h2>\n\n\n\n

Vorteile von WebSockets sind, dass \u00fcber einen bidirektionalen Kanal Daten in Echtzeit zwischen Client und Server \u00fcbermittelt werden k\u00f6nnen. Dies beschr\u00e4nkt sich dabei nicht auf Textdateien, sondern es k\u00f6nnen auch bin\u00e4re Daten (z. B. Video-, Audio- und Bilddateien) \u00fcbertragen werden. Zudem haben WebSockets nur einen kleinen Overhead, d. h. es werden geringere Datenmengen \u00fcbertragen, wodurch eine bessere Performance erzielt werden kann. Gerade f\u00fcr Anwendungen, die h\u00e4ufig mobil genutzt werden, kann dies entscheidend sein. [vgl. 5, S. 35]<\/p>\n\n\n\n

Ebenso weisen WebSockets eine sehr gute Browserunterst\u00fctzung auf. Seit 2013 werden sie von allen g\u00e4ngigen Desktop-Browsern unterst\u00fctzt und inzwischen auch von den vertretenen Smartphone-Browsern. Welche Browser WebSockets unterst\u00fctzen ist aus Abbildung 6 zu entnehmen. [vgl. 10]<\/p>\n\n\n\n

\"\"<\/a>
Abbildung 6:<\/strong> Browserunterst\u00fctzung von WebSockets [10]<\/em><\/figcaption><\/figure>\n\n\n\n

Gravierende Nachteile weisen WebSockets nicht auf. Man sollte sich jedoch \u00fcber gewisse Sicherheitsrisiken bewusst sein und entsprechende Schutzma\u00dfnahmen einrichten. Die Risiken gleichen denen des zugrundeliegenden HTTP-Protokolls. So sind beispielsweise Denial-of-Service-Angriffe (DoS-Angriffe) m\u00f6glich, da die Anzahl an Verbindungen zum Server nicht begrenzt wird. Bei einer DoS-Attacke wird eine hohe Anzahl an Anfragen an den Server gesendet, sodass das System enorm langsam wird oder sogar zusammenbricht [vgl. 11]. Zudem findet keine Authentifizierung und Autorisierung w\u00e4hrend des Handshake-Prozesses statt. Ebenso wird der Nutzer-Input nicht gepr\u00fcft, wodurch z. B. Cross-Site-Scripting (XSS) und SQL-Injections m\u00f6glich sind. [vgl. 12]<\/p>\n\n\n\n

In [13] sind einige Best Practices einzusehen, die f\u00fcr einen sicheren Einsatz von WebSockets umgesetzt werden sollten. <\/p>\n\n\n\n

Fazit<\/h2>\n\n\n\n

In WebSockets steckt gro\u00dfes Potenzial, da es bislang keine andere Technologie gibt, die eine bidirektionale Verbindung zwischen Client und Server erm\u00f6glicht. Auch kann eine sehr hohe Performance erzielt werden. Allerdings gibt es gewisse Sicherheitsrisiken, auf die bei der Implementierung geachtet werden sollte. Sofern Textdaten lediglich unidirektional vom Server zum Client gesendet werden m\u00fcssen, empfielt sich stattdessen die Verwendung von Server-sent Events. Diese erzielen eine vergleichbare Performance, bei einem geringeren Entwicklungsaufwand.<\/p>\n\n\n\n

Literatur<\/h2>\n\n\n\n