{"id":12162,"date":"2021-02-19T21:20:10","date_gmt":"2021-02-19T20:20:10","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=12162"},"modified":"2023-06-18T18:08:10","modified_gmt":"2023-06-18T16:08:10","slug":"websocket-protokoll-ein-detaillierter-technischer-einblick","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/02\/19\/websocket-protokoll-ein-detaillierter-technischer-einblick\/","title":{"rendered":"WebSocket-Protokoll: Ein detaillierter technischer Einblick"},"content":{"rendered":"

Das HTTP-Protokoll existiert seit Beginn des Internets und hat sich bis heute in Bezug auf Performance immer weiter entwickelt. Die vielen TCP-Verbindungs-Aufbau-Prozeduren wurden durch das Multiplexing auf ein paar Wenige reduziert, welche jeweils mehrere verschiedene Daten \u00fcbertragen [7]. Auch der Header selbst wurde auf Performance getrimmt. So wurde aus dem textuellen Format ein bin\u00e4r-Kodiertes. Zudem wurden neue Funktionen wie das Caching hinzugef\u00fcgt, um das Laden von Daten zu minimieren [7][8].<\/span><\/p>\n

Jedoch funktioniert das HTTP-Protokoll in seiner Grund-Funktionalit\u00e4t immer noch gleich. Es besteht immer noch aus einer Anfrage und einer Antwort und die Verbindung kann nicht beliebig lange offen gehalten werden.<\/span><\/p>\n

Es ist dem Server nicht m\u00f6glich, von sich aus Daten an den Client zu senden. Dieser Datenaustausch kann nur vom Client initiiert werden [7][8].<\/span><\/p>\n

Hier kn\u00fcpft das WebSocket-Protokoll [2] an. Es bietet eine bidirektionale Daten\u00fcbertragung, welche es dem Server erlaubt, direkt ohne Client-Anfrage Daten zu senden, was das Realisieren von Echtzeit-Web-Anwendungen ohne gro\u00dfe Netzlast oder Latenz erm\u00f6glicht. Zudem ist der Header sehr klein und einfach zu interpretieren. Dadurch ist das Protokoll sehr gut zum Senden vieler kleiner Nachrichten geeignet.<\/span><\/p>\n

Im Folgenden werden zun\u00e4chst allgemeine Informationen und wichtige Eigenschaften des WebSocket-Protokolls beschrieben und die Vorteile und Nachteile gegen\u00fcber dem HTTP-Protokoll offen gelegt. Daraufhin wird ein detaillierter technischer Einblick in die Implementierung und Funktionsweise des Protokolls gegeben. Am Schluss wird die JavaScript-WebSocket-API als Beispiel-API f\u00fcr die Client-seitige WebSocket-Implementierung vorgestellt und deren Funktionen mit dem internen Verhalten des Protokolls in Beziehung gesetzt.<\/span><\/p>\n\n\n

Allgemein<\/h2>\n\n\n

Das WebSocket-Protokoll ist ein seit 2011 existierendes Internet-Protokoll, welches auf der Anwendungsschicht des OSI-Modells angesiedelt ist und der bidirektionalen Daten-\u00dcbermittlung \u00fcber einer konstanten TCP-Verbindung dient. Dabei werden die Standard-HTTP-Ports mit verwendet, also 80 oder 8080 bei unverschl\u00fcsselten und 443 bei verschl\u00fcsselten Verbindungen. Dies hat den Vorteil, dass keine zus\u00e4tzlichen Firewall-Einstellungen n\u00f6tig sind, um das WebSocket-Protokoll zu ber\u00fccksichtigen [9]. Das WebSocket-Protokoll ist im RFC 6455 von der IETF (Internet Engineering Task Force) standardisiert und aktuell in der Version 13 verf\u00fcgbar [2]. Es dient prim\u00e4r der Echtzeit-Daten\u00fcbertragung bei Echtzeit-Web-Anwendungen.<\/span><\/p>\n\n\n

Protokoll-Eigenschaften<\/h3>\n\n\n

Im Folgenden werden wichtige Eigenschaften des WebSocket-Protokolls genannt und die daraus entstehenden Einschr\u00e4nkungen und Vorteile gegen\u00fcber dem HTTP-Protokoll beschrieben.<\/span><\/p>\n\n\n

\u00dcbertragung gro\u00dfer Daten<\/h4>\n\n\n

Wie beim HTTP-Protokoll auch, k\u00f6nnen gr\u00f6\u00dfere Daten, welche nicht auf einmal in einen Puffer passen, wie zum Beispiel gr\u00f6\u00dfere Dateien, St\u00fcck f\u00fcr St\u00fcck versendet werden. Hierbei ist aber keine Fragmentierung auf Anwender-Schicht notwendig. Die Nachricht wird als eine gro\u00dfe Nachricht mit einem Header und gro\u00dfer Payload interpretiert, welche je nach Puffer-Gr\u00f6\u00dfe St\u00fcck f\u00fcr St\u00fcck eingelesen wird. Anhand der im Header gegebenen Payload-Gr\u00f6\u00dfe und der bisher empfangenen Payload-Daten kann ermittelt werden, ob noch Daten fehlen oder die Nachricht vollst\u00e4ndig ist [10].<\/span><\/p>\n

In Abbildung 1 ist die entsprechende Nachricht und der verf\u00fcgbare Puffer veranschaulicht.<\/span><\/p>\n\n\n

\"Senden<\/a>
Abbildung 1: Senden gro\u00dfer Daten durch St\u00fcck-weises einlesen in den Puffer<\/figcaption><\/figure>\n\n\n

Da dieses Verfahren von beiden Protokollen unterst\u00fctzt wird, existieren hier weder Vor- noch Nachteile.<\/span><\/p>\n\n\n

Verbindungsorientiert + konstante Verbindung + kleiner Header<\/h4>\n\n\n

Das WebSocket-Protokoll ist verbindungsorientiert [2]. Dies bedeutet, dass zun\u00e4chst eine HTTP-Anfrage und eine entsprechende Antwort geschickt werden muss, bevor die eigentlichen Daten versendet werden k\u00f6nnen [7]. Dies erzeugt zun\u00e4chst einen Mehraufwand in Form von Verarbeitungs-Aufwand und der Gr\u00f6\u00dfe an Daten, welche gesendet werden m\u00fcssen. Sollten jedoch mehrere Daten \u00fcber eine konstante Verbindung ohne erneuten Verbindungsaufbau gesendet werden, kann das WebSocket-Protokoll seine St\u00e4rke ausspielen. Der Header des WebSocket-Protokolls ist deutlich kleiner als der des HTTP-Protokolls, auch wenn der HTTP-Header bin\u00e4r kodiert sein sollte. Zudem muss das HTTP-Protokoll pro Daten-Transfer zwei Header, eine Anfrage und eine Antwort, senden. Somit ist der Aufwand pro Nachricht beim WebSocket-Protokoll geringer, was bei vielen zu \u00fcbermittelnden Nachrichten einen gro\u00dfen Vorteil bringt. Da bereits das HTTP\/1.1-Protokoll mit Multiplexing-Funktionalit\u00e4r ausgestattet ist [7], kann der entscheidene Vorteil darin gesehen werden, dass das WebSocket-Protokoll eine konstante Verbindung besitzt, sodass die zu \u00fcbertragenden Daten nicht zu Beginn der \u00dcbertragung bekannt sein m\u00fcssen, was bei HTTP-Multiplexing aber der Fall ist, da die HTTP-Verbindung wieder geschlossen werden muss.<\/p>\n

Die folgende Formel gibt an, ab welcher Nachrichten-Anzahl sich der Einsatz von WebSockets lohnt, wenn f\u00fcr HTTP Multiplexing verwendet werden kann. Mit \u2018WS-Header\u2018 oder \u2018HTTP-Header\u2018 ist der Aufwand gemeint, welcher mit dem Versenden und Erstellen beziehungsweise Lesen des entsprechenden Headers einhergeht. Der linke Teil gibt den Aufwand des WebSocket-Protokolls, der rechte Teil den Aufwand f\u00fcr das HTTP-Protokoll an. \u2018n\u2018 entspricht der Anzahl an Nachrichten [10].<\/p>\n\n\n

2 HTTP-Header + n WS-Header + 2 WS-Header < n*2 HTTP-Header<\/code><\/pre>\n\n\n
Die zus\u00e4tzlichen 2 WS-Header entsprechen dem Verbindungs-Abbau.<\/span><\/p>\n\n\n
Maskierung<\/h4>\n\n\n
Da beim Hochladen von Daten die Payload maskiert werden muss [2], entsteht beim WebSocket-Protokoll ein Mehraufwand. Je gr\u00f6\u00dfer die Payload einer Nachricht ist, desto mehr muss maskiert werden, was die Gesamt-\u00dcbertragungszeit reduziert. Daher sollten beim Hochladen von Daten, der Payload-Anteil m\u00f6glichst gering gehalten werden.<\/span><\/p>\n\n\n
Bidirektional vs. Polling<\/h4>\n\n\n\n
Bidirektional bedeutet, dass zu einer beliebigen Zeit einer der Teilnehmer eine Nachricht an die Gegenstelle senden kann. Dadurch ist es dem Server m\u00f6glich, Nachrichten an den Client zu senden, ohne eine vorherige Anfrage erhalten zu haben. Dies ist vor allem in Anwendungsgebieten von Vorteil, in denen der Server dem Client m\u00f6glichst schnell Zustands-Aktualisierungen mitteilen muss. Anwendungs-Gebiete sind hierbei Echtzeit-Anwendungen wie Browser-Spiele [5], in welchen der Spieler m\u00f6glichst schnell vom Server informiert werden muss, wenn zum Beispiel ein neuer Gegner in sein Sichtfeld ger\u00e4t. Mit Hilfe des WebSocket-Protokolls kann der Server daher direkt eine Nachricht senden, was der Latenz einer Daten-\u00dcbertragung f\u00fcr eine Strecke entspricht.<\/p>\n\n\n\n
Die selbe Funktionalit\u00e4t mit dem HTTP-Protokoll muss mit Hilfe von Polling implementiert werden [6]. Dabei wird regelm\u00e4\u00dfig eine Anfrage gesendet, um den aktuellen Server-Zustand abzufragen. Dabei verursacht das permanente Abfragen eine gro\u00dfe Netzlast, was beim WebSocket-Protokoll nicht der Fall ist. Dar\u00fcber hinaus ist die Latenz meist deutlich h\u00f6her und abh\u00e4ngig von der Abfrage-Frequenz des Clients.<\/p>\n\n\n\n
In Abbildung 2 und 3 wird die Eigenschaft der Bidirektionalit\u00e4t und das Polling-Verfahren visuell veranschaulicht.<\/p>\n\n\n\n
\"Server-Mitteilung<\/a>
Abbildung 2: Server-Mitteilung mit bidirektionaler Daten\u00fcbertragung<\/figcaption><\/figure>\n\n\n\n
\"\"<\/a>
Abbildung 3: Server-Mitteilung mit Polling-Verfahren<\/figcaption><\/figure>\n\n\n\n
Keine Same-Origin-Policy<\/h4>\n\n\n
Das WebSocket-Protokoll folgt im Gegensatz zum HTTP-Protokoll keiner Same-Origin-Policy [1]. Es k\u00f6nnen also mehrere Verbindungen mit unterschiedlichen Dom\u00e4nen existieren. Um Sicherheitsprobleme wie Cross-Site-Scripting zu umgehen, muss der Server beim Verbindungsaufbau den mitgelieferten Origin-Header mit der eigenen Dom\u00e4ne abgleichen und eventuell die Verbindung trennen, wenn die Dom\u00e4ne der Client-Anwendung keine Valide ist.<\/span><\/p>\n\n\n
Anwendungsgebiete<\/h3>\n\n\n\n
Anwendungsgebiete f\u00fcr das WebSocket-Protokoll sind alle Anwendungen, welche m\u00f6glichst alle Eigenschaften und deren Einschr\u00e4nkungen des Protokolls optimal nutzen k\u00f6nnen. Prim\u00e4r wird das WebSocket-Protokoll in Echtzeit-Anwendungen wie Browser-Spielen [5], Chat-Anwendungen oder beim Streaming verwendet. Browser-Spiele tauschen viele kleine Nachrichten zwischen Server und Client aus. Zudem muss der Server dem Client schnellstm\u00f6glich mitteilen, wenn sich der Spiel-Zustand insofern \u00e4ndert, dass es den entsprechenden Spieler betrifft. Aber auch beim Monitoring kann das WebSocket-Protokoll bestm\u00f6glich eingesetzt werden, da auch hier ein schneller bidirektionaler Datenverkehr zwischen Server und Client ben\u00f6tigt wird. Zudem kann durch das Verbinden mit verschiedener Dom\u00e4nen, der Zustand mehrerer Server eines gr\u00f6\u00dferen Netzwerks visualisiert werden [10].<\/p>\n\n\n\n
Verbindungsaufbau<\/h2>\n\n\n
Der Verbindungsaufbau des WebSocket-Protokolls entspricht einem klassischen HTTP-Zyklus bestehend aus Anfrage und Antwort. Im Folgenden sind die Minimal-Header f\u00fcr Anfrage und Antwort gegeben [1].<\/span><\/p>\n\n\n
HTTP-Anfrage<\/td>HTTP-Antwort<\/td><\/tr>
GET \/<URL> HTTP\/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: <String-In>
Sec-WebSocket-Version: <Version-in><\/td>		HTTP\/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <String-Out>
Sec-WebSocket-Version: <Version-out><\/td><\/tr><\/tbody><\/table>
Tabelle 1: Minimaler Anfrage\/- und Antwort-HTTP-Header f\u00fcr WebSocket-Verbindungsaufbau [1]<\/figcaption><\/figure>\n\n\n
Die zu \u00fcbergebende <URL> kann beliebig gew\u00e4hlt werden, da diese f\u00fcr das WebSocket-Protokoll keine Bedeutung hat. Typischerweise wird die <URL> daher zur Differenzierung verschiedener WebSocket-Anwendungen, welche parallel auf dem Server laufen, verwendet [1].<\/span><\/p>\n
Um dem Server mitzuteilen, dass auf das WebSocket-Protokoll gewechselt werden soll, m\u00fcssen die Header \u2018Upgrade\u2018 und \u2018Connection\u2018 verwendet werden.<\/span><\/p>\n
Im \u2018Sec-WebSocket-Version\u2018-Header wird die vom Client unterst\u00fctzte WebSocket-Version <Version-in> angegeben. Meistens entspricht dies der aktuellen Version 13 [10].<\/span><\/p>\n
Vor dem Senden einer WebSocket-Nachricht muss der Client sicher stellen, dass der kontaktierte Server das WebSocket-Protokoll auch versteht. Andernfalls best\u00fcnde die Gefahr, dass der Server f\u00e4lschlicherweise eine WebSocket-Nachricht als HTTP-Nachricht interpretiert, was zu einer Sicherheitsl\u00fccke f\u00fchrt. Aus diesem Grund muss ein Base64-kodierter String <String-in>, welcher beliebig gew\u00e4hlt werden kann, im \u2018Sec-WebSocket-Key\u2018-Header mitgeliefert werden. Der Server muss diesen entsprechend der in Tabelle 2 angegebenen Schritte konvertieren und das Ergebnis in seiner Antwort im \u2018Sec-WebSocket-Accept\u2018-Header zur\u00fcck senden [1].<\/span><\/p>\n
Zus\u00e4tzlich kann der Server eine WebSocket-Version <Version-out> angeben, falls diese von der Angabe des Clients <Version-in> abweicht.<\/span><\/p>\n
Konnte keine Vereinbarung bez\u00fcglich der Version oder des Wechsels auf das WebSocket-Protokoll getroffen werden oder der zur\u00fcck gelieferte String <String-out> falsch sein, wird der Verbindungsaufbau abgebrochen [1].<\/span><\/p>\n\n\n
Beschreibung<\/th>Beispiel<\/th>L\u00e4nge (Byte)<\/th><\/tr><\/thead>
<String-In>: beliebiger Base64-String<\/td>MQBbM45rKkPH\/ocIaDfOjw==<\/td>24<\/td><\/tr>
Konkatinierung mit statischem String<\/td>MQBbM45rKkPH\/ocIaDfOjw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11<\/td>60<\/td><\/tr>
sha1-Hash<\/td>2e9a036975af28d8828712ff45a733eb4d9c2f53<\/td>40<\/td><\/tr>
Hex -> Int<\/td><nicht darstellbar><\/td>20<\/td><\/tr>
base64: <String-Out><\/td>LpoDaXWvKNiChxL\/Racz602cL1M=<\/td>28<\/td><\/tr><\/tbody><\/table>
Tabelle 2: Sec-WebSocket-Key-Konvertierung [1] [10]<\/figcaption><\/figure>\n\n\n\n
WebSocket-Header<\/h2>\n\n\n
Der WebSocket-Header ist bin\u00e4r kodiert und in seiner Gr\u00f6\u00dfe variabel. Er kann je nach Payload-Gr\u00f6\u00dfe und \u00dcbertragungs-Richtung bis zu 14 Byte umfassen und eine minimale Gr\u00f6\u00dfe von 2 Byte betragen [1][2], was im Gegensatz zum HTTP-Header, auch wenn dieser bin\u00e4r kodiert sein sollte, deutlich kleiner ist. In Abbildung 4 ist der WebSocket-Header mit seinen Bestandteilen dargestellt. Im Folgenden werden diese detailliert beschrieben.<\/span><\/p>\n\n\n
\"\"<\/a>
Abbildung 4: WebSocket-Header [1]<\/figcaption><\/figure>\n\n\n\n
Opcode<\/h3>\n\n\n
Der Opcode, auch Operation-Code genannt, gibt den Typ der Nachricht an [2]. Aktuell sind folgende sechs Nachrichten-Typen definiert:<\/span><\/p>\n\n\n
Code<\/th>Beschreibung<\/th><\/tr><\/thead>
0x0<\/td>Continuation (Kontroll-Rahmen)<\/td><\/tr>
0x1<\/td>Text (Payload-Typ: UTF-8-Text)<\/td><\/tr>
0x2<\/td>Binary (Payload-Typ: Bin\u00e4r-Format)<\/td><\/tr>
0x3-0x7<\/td>not used<\/td><\/tr>
0x8<\/td>Close (Kontroll-Rahmen)<\/td><\/tr>
0x9<\/td>Ping (Kontroll-Rahmen)<\/td><\/tr>
0xa<\/td>Pong (Kontroll-Rahmen)<\/td><\/tr>
0xb-0xf<\/td>not used<\/td><\/tr><\/tbody><\/table>
Tabelle 3: verf\u00fcgbare Opcodes des WebSocket-Header<\/figcaption><\/figure>\n\n\n
Die Opcodes \u2018Text\u2018 und \u2018Binary\u2018 geben an, dass in der Payload Anwendungs-bezogene Daten enthalten sind. Bei \u2018Text\u2018 muss die Payload als UTF-8-String, bei \u2018Binary\u2018 als Bin\u00e4r-Daten interpretiert werden. Die restlichen vier Kontroll-Rahmen werden in nachfolgenden Kapiteln mit Ihrem jeweiligen Verwendungszweck beschrieben.<\/span><\/p>\n\n\n
Fin – Fragmentierung auf Anwendungsschicht<\/h3>\n\n\n
Das Fin-Flag wird im Zusammenhang mit dem Opcode \u2018Continuation\u2018 verwendet, um Fragmentierung auf Applikations-Schicht zu erm\u00f6glichen. Dabei wird das Fin-Bit nur gesetzt, wenn es sich bei der Nachricht um das letzte Fragment der Gesamt-Nachricht handelt. Der Opcode wird zu Beginn auf den Daten-Typ der Payload, also \u2018Text\u2018 oder \u2018Binary\u2018 gesetzt. Der Daten-Typ ist dabei f\u00fcr alle Fragmente einer Gesamt-Nachricht der Selbe. Alle nachfolgenden Fragmente m\u00fcssen mit Opcode \u2018Continuation\u2018 gekennzeichnet werden [1][2].<\/span><\/p>\n
In Tabelle 4 ist das Zusammenspiel zwischen Opcode und Fin-Flag bei fragmentierter und nicht-fragmentierter Nachricht veranschaulicht. Aus [1] inspiriert.
<\/span><\/p>\n\n\n
\n
\n
\n
Fin<\/strong><\/td>Opcode<\/strong><\/td>Beschreibung<\/strong><\/td><\/tr>
1<\/td>1,2<\/td>Nachricht nicht fragmentiert.<\/td><\/tr>
0<\/td>1,2<\/td>Nachricht mit Typ 1,2 beginnt.
=> weitere Nachrichten folgen, um Payload zu vervollst\u00e4ndigen.<\/td><\/tr>
0<\/td>0<\/td>Weiterer Teil der Nachricht mit Typ 1,2.<\/td><\/tr>
1<\/td>0<\/td>Letzter Teil der Nachricht.
=> Payload jetzt vollst\u00e4ndig.<\/td><\/tr><\/tbody><\/table>
Tabelle 4: Zusammenspiel zwischen Opcode und Fin-Flag bei fragmentierter und nicht-fragmentierter Nachricht.<\/figcaption><\/figure>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n\n\n
Mask<\/h3>\n\n\n
Wenn das Mask-Flag gesetzt ist, ist die Nachricht gemasked. Dies bedeutet, dass die Payload der Nachricht mit dem mitgelieferten 4-Byte gro\u00dfen Mask-Key XOR-Verschl\u00fcsselt wurde. Das Ver\/- und Entschl\u00fcsselungs-Verfahren ist dabei das Selbe und im Folgenden mit Programm-Code beschrieben, welcher von [1] inspiriert wurde:<\/span><\/p>\n\n\n
for (unsigned int i = 0; i < payloadSize; ++i) {\n     pBuffer[i] = pPayload[i] ^ pMaskKey[i % 4];\n}<\/code><\/pre>\n\n\n
‘pBuffer’ enth\u00e4lt hierbei nach dem Verfahren entweder die verschl\u00fcsselte oder entschl\u00fcsselte Version der Payload, jenachdem, ob die Payload ‘pPayload’ ver\/- oder entschl\u00fcsselt vorliegt.<\/span><\/p>\n
Wichtig ist hierbei, dass nur Nachrichten vom Client zum Server gemasked werden m\u00fcssen. Nachrichten vom Server zum Client d\u00fcrfen nicht gemasked werden [2].<\/span><\/p>\n
Sollte eine unverschl\u00fcsselte Nachricht dem Server oder eine Verschl\u00fcsselte dem Client gesendet werden, muss der Empf\u00e4nger die Verbindung schlie\u00dfen [1].<\/span><\/p>\n\n\n
Payload-Gr\u00f6\u00dfe<\/h3>\n\n\n
Die Anzahl der ben\u00f6tigten Bytes f\u00fcr die Kodierung der Payload-Gr\u00f6\u00dfe ist je nach Payload-Gr\u00f6\u00dfe unterschiedlich. Um die Gr\u00f6\u00dfe der Payload zu ermitteln m\u00fcssen zun\u00e4chst die 7 Bit des \u2018Payload-Len\u2019-Feldes interpretiert werden. Sollte dieser Wert kleiner als 126 sein, so entspricht dies der Payload-Gr\u00f6\u00dfe. Sollte der Wert aber 126 oder 127 sein, so m\u00fcssen weitere Bytes eingelesen werden und deren Wert als Payload-Gr\u00f6\u00dfe interpretiert werden. Bei 126 sind es 2 Byte, bei 127 8 Byte, die zus\u00e4tzlich eingelesen werden m\u00fcssen [1]. Dadurch m\u00fcssen bei kleineren Nachrichten unn\u00f6tige Bytes nicht mitgesendet werden, da sich die Anzahl der zur Kodierung der Payload-Gr\u00f6\u00dfe ben\u00f6tigten Bytes von der Nachrichten-Gr\u00f6\u00dfe abh\u00e4ngt.<\/span><\/p>\n\n\n
RSV<\/h3>\n\n\n
RSV steht f\u00fcr \u2018Reserved\u2018 und stellt bisher ungenutzte Bits im Header dar, welche f\u00fcr eventuell sp\u00e4tere Protokoll-Erweiterungen in der Spezifikation reserviert sind.<\/span><\/p>\n\n\n
Verbindungsabbau<\/h2>\n\n\n
Um eine WebSocket-Verbindung zu schlie\u00dfen, kann einer der Teilnehmer zu jeder Zeit eine Nachricht mit dem Opcode \u2018Close\u2018 senden. Die Gegenstelle muss dann eine entsprechende Close-Nachricht zur\u00fcck senden. Die Payload der Close-Nachricht ist in zwei Abschnitte eingeteilt, welche zusammen nicht gr\u00f6\u00dfer als 125 Byte sein d\u00fcrfen. Hierbei entsprechen die ersten 2 Byte dem Close-Code, einer ID zur exakten Bestimmung des Schlie\u00df-Grunds. Alle nachfolgenden Bytes enthalten, wenn vorhanden, eine textuelle Beschreibung des Close-Codes [1]. Meistens wird jedoch nur der Close-Code gesendet [10].
<\/span><\/p>\n
Nach dem Senden oder Empfangen einer Close-Nachricht d\u00fcrfen keine weiteren Nachrichten gesendet und empfangene Nachrichten nicht mehr ber\u00fccksichtigt werden [1].<\/span><\/p>\n\n\n
Zus\u00e4tzliche Funktionen<\/h2>\n\n\n\n
Pings und Pongs<\/h3>\n\n\n
Sollte die Gegenstelle auf Anwender-Schicht nicht mehr erreichbar sein, so k\u00f6nnen Ressourcen gespart werden, wenn die Verbindung getrennt wird. Um zu erkennen, ob ein anderer Teilnehmer noch erreichbar ist, oder nicht, k\u00f6nnen zu einem beliebigen Zeitpunkt, Nachrichten mit dem Opcode \u2018Ping\u2018 gesendet werden. Die Payload kann hierbei beliebig gew\u00e4hlt werden, darf aber die Maximal-Gr\u00f6\u00dfe von 125 nicht \u00fcberschreiten. Durch den Empfang einer entsprechenden Ping-Nachricht ist der Empf\u00e4nger dazu gezwungen, eine Nachricht mit dem Opcode \u2018Pong\u2018 zur\u00fcck zu senden. Dabei muss die Payload der Pong-Nachricht den Daten der Ping-Nachricht entsprechen [1].<\/span><\/p>\n
Wann genau eine Ping-Nachricht gesendet werden sollte, ist in der Spezifikation nicht definiert und daher der Anwendung \u00fcberlassen [2]. Die Anwendung k\u00f6nnte die vergangene Zeit seit der letzten angekommenen Nachricht von einem bestimmten Teilnehmer messen. Sollte diese einen bestimmten festgelegten Wert \u00fcberschreiten, k\u00f6nnte eine Ping-Nachricht gesendet werden. Auf die entsprechende Pong-Antwort kann nun wiederum eine bestimmte festgelegte Zeit gewartet werden. Sollte bis dahin keine Pong-Nachricht ankommen, kann die TCP-Verbindung geschlossen werden [10].<\/p>\n
Bisher konnte aber die Erfahrung gemacht werden, dass der ‘Firefox’-Browser [12] keine Ping-Nachrichten an den selbst erstellten Server gesendet hat. Dies liegt eventuell daran, dass der Browser erkennt, dass der Server lokal erreichbar ist, was bedeutet, dass sich beide Teilnehmer auf der selben Maschine befinden wodurch das Senden einer Ping-Nachricht damit unn\u00f6tig ist [10].<\/p>\n
Sollten mehrere Pings gesendet werden, gen\u00fcgt es, einen Pong als Antwort zu senden. Pong-Nachrichten ohne dazugeh\u00f6rige Ping-Nachricht werden ignoriert [1].<\/span><\/p>\n\n\n
Sub-Protokolle<\/h3>\n\n\n
Subprotokolle dienen der Kennzeichnung bez\u00fcglich der Kodierung einer Payload. Beinhaltet die Payload beispielsweise einen JSON-String, so kann durch ein Sub-Protokoll dem Server mitgeteilt werden, dass er einen JSON-Parser zum interpretieren der Payload verwenden soll. Die Mitteilung der Sub-Protokolle geschieht \u00fcber einen eigenen HTTP-Header w\u00e4hrend dem Verbindungs-Aufbau. \u00dcber den HTTP-Header \u2018Sec-WebSocket-Protocol\u2018 k\u00f6nnen ein oder mehrere Sub-Protokolle beim Server angefragt werden, zum Beispiel mehrere Versionen eines Parsers. Der Server sendet dann das erste passende Sub-Protokoll \u00fcber selbigen Header zur\u00fcck an den Client [1].<\/span><\/p>\n\n\n
JavaScript WebSocket-API<\/h2>\n\n\n
Im Folgenden werden die wichtigsten Funktionen der WebSocket-API f\u00fcr die Sprache JavaScript auf Client-Seite kurz erl\u00e4utert, und im Parallelen veranschaulicht, welche Funktionen zu welchen Aktionen intern im Browser f\u00fchren, bezogen auf das WebSocket-Protokoll.<\/span> Die daf\u00fcr n\u00f6tigen Informationen wurden aus [3] und [4] entnommen.<\/p>\n\n\n
Verbindungsaufbau<\/h3>\n\n\n\n
var ws = new WebSocket(<URL>, <subProtocols>);<\/code><\/pre>\n\n\n
Das Erzeugen eines WebSocket-Objekts entspricht dem WebSocket-Verbindungs-Aufbau. Der erste Parameter entspricht der <URL>, \u00fcber welche der Server und eine auf dem Server laufende WebSocket-Anwendung gew\u00e4hlt werden kann, zu der eine Verbindung aufgebaut werden soll. Zu Beachten gilt, dass das \u2018http:\/\/\u2018 oder \u2018https:\/\/\u2018 in typischen HTTP-URL\u2019s mit einem \u2018ws:\/\/\u2018 f\u00fcr ‘WebSocket’ beziehungsweise einem \u2018wss:\/\/’ f\u00fcr ‘WebSocket Secure\u2018 bei sicheren Verbindungen ersetzt werden muss.<\/span><\/p>\n
Der zweite Parameter ist optional und kann zur Angabe bestimmter Sub-Protokolle verwendet werden. Hierbei kann entweder ein String oder Array von Strings \u00fcbergeben werden.<\/span><\/p>\n\n\n
ws.onopen = ()=>{};<\/code><\/pre>\n\n\n
Bei erfolgreichem Verbindungsaufbau wird der Anendungs-Code durch den onopen-Listener informiert.<\/span><\/p>\n\n\n
Senden<\/h3>\n\n\n\n
ws.send(<Content>);<\/code><\/pre>\n\n\n
Das Senden von Daten geschieht \u00fcber die send-Funktion des WebSocket-Objekts. Jenachdem, welche Objekte als Parameter \u00fcbergeben werden, wird der Obcode im WebSocket-Header gesetzt. Tabelle 5 stellt alle m\u00f6glichen Kombinationen zwischen \u00fcbergebenem Objekt und Opcode dar.<\/span><\/p>\n\n\n
<Content><\/th>Opcode<\/th><\/tr><\/thead>
String<\/td>Text<\/td><\/tr>
ArrayBuffer \/ Blob<\/td>Binary<\/td><\/tr><\/tbody><\/table>
Tabelle 5: Mapping zwischen \u00fcbergebenem Parameter und Opcode<\/figcaption><\/figure>\n\n\n\n
Empfangen<\/h3>\n\n\n\n
ws.onmessage = ev=>{ev.data;};\nws.binaryType = <Type>;<\/code><\/pre>\n\n\n
F\u00fcr den Empfang von Daten, wird der onmessage-Listener ben\u00f6tigt, welcher informiert wird, sobald die Payload der Nachricht vollst\u00e4ndig vorliegt. Die f\u00fcr den Empfang zur Verf\u00fcgung stehenden Objekte sind die Selben wie f\u00fcr das Senden. Jedoch muss beim Empfang einer Nachricht mit Opcode \u2018Binary\u2018 zus\u00e4tzlich bestimmt werden, ob ein ArrayBuffer-Objekt oder ein Blob-Objekt empfangen werden soll, da beide jeweils Bin\u00e4r-Formate darstellen. Daf\u00fcr wird das Objekt-Feld \u2018binaryType\u2018 verwendet. Ein \u00dcberblick \u00fcber die m\u00f6glichen Werte und deren Beziehungen ist in Tabelle 6 gegeben. \u2018-\u2018 <\/span>bedeutet, dass der Wert <\/span>nicht ber\u00fccksichtigt <\/span>wird.<\/span><\/p>\n\n\n
Opcode<\/th>binaryType<\/th>ev.data<\/th><\/tr><\/thead>
Text<\/td>–<\/td>String<\/td><\/tr>
Binary<\/td>“arraybuffer”<\/td>ArrayBuffer<\/td><\/tr>
Binary<\/td>“blob”<\/td>Blob<\/td><\/tr><\/tbody><\/table>
Tabelle 6: Abh\u00e4ngigkeiten zwischen Opcode, <Type> und ev.data<\/figcaption><\/figure>\n\n\n\n
Verbindungsabbau<\/h3>\n\n\n\n
ws.onclose = ev=>{};\nws.close(<Code>, <Msg>);<\/code><\/pre>\n\n\n
F\u00fcr den Verbindungsabbau existieren zum Empfangen einer Close-Nachricht ein entsprechender Listener und zum Senden einer Close-Nachricht eine Sende-Funktion. Hierbei muss aber beim Empfang einer Close-Nachricht keine Close-Nachricht manuell zur\u00fcck gesendet werden. Dies wird vom Browser-Laufzeit-System \u00fcbernommen. Sowohl das Event-Objekt, als auch die Sende-Funktion besitzen die M\u00f6glichkeit, den Close-Code, sowie eine optionale textuelle Close-Nachricht zu empfangen beziehungsweise zu senden.<\/span><\/p>\n\n\n
Payload-Bestandteil<\/th>Senden<\/th>Empfangen<\/th><\/tr><\/thead>
Close-Code<\/td><Code><\/td>ev.code<\/td><\/tr>
Close-Message<\/td><Msg><\/td>ev.reason<\/td><\/tr><\/tbody><\/table>
Tabelle 7: Komponenten zum Lesen und Schreiben der Close-Payload<\/figcaption><\/figure>\n\n\n\n
Fehlermeldung<\/h3>\n\n\n\n
ws.onerror = ()=>{};<\/code><\/pre>\n\n\n
Sollte w\u00e4hrend der WebSocket-Kommunikation ein Fehler auftreten, kann dieser \u00fcber den \u2018onerror\u2018-Event-Listener mitgeteilt werden. Jedoch wird hier lediglich ein Event-Objekt \u00fcbergeben, welches keinerlei Informationen \u00fcber den Fehler enth\u00e4lt. Ein entsprechender Fehler-Code ist immer nur im Close-Code enthalten, da dar\u00fcber alles kommuniziert wird, was das Schlie\u00dfen der Verbindung bewirkt hat, also auch Fehler [11].<\/span><\/p>\n\n\n
Socket.io<\/h2>\n\n\n\n
‘Socket.io’ ist eine abstraktere JavaScript-Bibliothek f\u00fcr Client- aber auch Server-seitige Echtzeit-Kommunikation mit einer einheitlichen Schnittstelle, welche die Verwendung und Einbindung von Echtzeit-Kommunikation in Web-Anwendungen erleichtern soll. Dabei wird je nach Kompatibilit\u00e4t der darunterliegenden Technologien, im Hintergrund entweder auf HTTP mittels Polling oder auf das WebSocket-Protokoll zugegriffen. ‘Socket.io’ bietet aber noch weitere  Funktionalit\u00e4ten wie zum Beispiel Echtzeit-Analysen [13].<\/p>\n\n\n\n
Quellen<\/h2>\n\n\n\n