WebSocket - Versionsgeschichte

Uncopy: Korrigiere sachlichen Fehler

2025-02-26T16:06:07Z

Korrigiere sachlichen Fehler

← Nächstältere Version		Version vom 26. Februar 2025, 18:06 Uhr
Zeile 17:		Zeile 17:
	\|}		\|}

	Das '''WebSocket-Protokoll''' ist ein auf [[Transmission Control Protocol\|TCP]] basierendes [[Netzwerkprotokoll]], das entworfen wurde, um eine [[bidirektional]]e Verbindung zwischen ~~einer~~ [[~~Webanwendung~~]] und einem WebSocket-Server bzw. einem [[Webserver]], der auch WebSockets unterstützt, herzustellen.		Das '''WebSocket-Protokoll''' ist ein auf [[Transmission Control Protocol\|TCP]] basierendes [[Netzwerkprotokoll]], das entworfen wurde, um eine [[bidirektional]]e Verbindung zwischen einem [[Webbrowser]] und einem WebSocket-Server bzw. einem [[Webserver]], der auch WebSockets unterstützt, herzustellen.

	== Vorteile gegenüber reinem HTTP ==		== Vorteile gegenüber reinem HTTP ==

2001:9E8:A285:800:B098:8285:82D1:4843: /* Vorteile gegenüber reinem HTTP */

2025-02-05T19:43:45Z

Vorteile gegenüber reinem HTTP

← Nächstältere Version		Version vom 5. Februar 2025, 21:43 Uhr
Zeile 45:		Zeile 45:
	</syntaxhighlight>		</syntaxhighlight>

	Wie auch im [[Hypertext Transfer Protocol\|HTTP~~-Protokoll~~]] gibt der Client an, auf welche Ressource (hier: ''/chat'') und auf welchen Host (hier: ''server.example.com'') er zugreifen möchte. Außerdem fordert der Client ein Upgrade auf das Websocket-Protokoll. Der zufällig generierte „Sec-WebSocket-Key“ dient zur Überprüfung, ob der Server die Anfrage tatsächlich gelesen und verstanden hat (''siehe Abschnitt [[#Antwort des Servers\|Antwort des Servers]]''). Unter „Sec-WebSocket-Protocol“ hat der Client die Möglichkeit, auf das Websocket-Protokoll aufbauende Protokolle anzugeben, die die Clientanwendung unterstützt (hier: ein Chat-Protokoll). Selbsterklärend sollte unter „Sec-WebSocket-Version“ die verwendete Protokollversion angegeben werden.		Wie auch im [[Hypertext Transfer Protocol\|HTTP]] gibt der Client an, auf welche Ressource (hier: ''/chat'') und auf welchen Host (hier: ''server.example.com'') er zugreifen möchte. Außerdem fordert der Client ein Upgrade auf das Websocket-Protokoll. Der zufällig generierte „Sec-WebSocket-Key“ dient zur Überprüfung, ob der Server die Anfrage tatsächlich gelesen und verstanden hat (''siehe Abschnitt [[#Antwort des Servers\|Antwort des Servers]]''). Unter „Sec-WebSocket-Protocol“ hat der Client die Möglichkeit, auf das Websocket-Protokoll aufbauende Protokolle anzugeben, die die Clientanwendung unterstützt (hier: ein Chat-Protokoll). Selbsterklärend sollte unter „Sec-WebSocket-Version“ die verwendete Protokollversion angegeben werden.

	=== Antwort des Servers ===		=== Antwort des Servers ===

PerfektesChaos: tk k

2023-06-27T15:17:29Z

tk k

← Nächstältere Version		Version vom 27. Juni 2023, 17:17 Uhr
Zeile 1:		Zeile 1:
	{\| class="wikitable float-right"		{\| class="wikitable float-right"
		⚫	\|+ style="background:#C0C0FF; font-size:larger;"\| WebSocket-Protokoll
	\|-
⚫	! ~~bgcolor~~="#~~c0c0ff" colspan="2"~~ font="size:larger" \| WebSocket-Protokoll
	\|-		\|-
	\| '''Familie:'''		\| '''Familie:'''
Zeile 7:		Zeile 6:
	\|-		\|-
	\| '''Einsatzgebiet:'''		\| '''Einsatzgebiet:'''
	\| bidirektionale Verbindung zwischen<br> einer Webanwendung und einem WebSocket-Server		\| bidirektionale Verbindung zwischen<br /> einer Webanwendung und einem WebSocket-Server
	\|-		\|-
	\| '''Port:''' \|\| 80/TCP, 443/TCP		\| '''Port:''' \|\| 80/TCP, 443/TCP
	\|-		\|-
	\| ~~align~~="~~center~~" ~~colspan~~="2" \|		\|colspan="2" class="center"\|
	{{Netzwerk-TCP-IP-Anwendungsprotokoll\|WebSocket}}		{{Netzwerk-TCP-IP-Anwendungsprotokoll\|WebSocket}}
	\|-		\|-
	\| '''Standards:'''		\| '''Standards:'''
	\| RFC 6455 (The WebSocket Protocol Version 13, 2011)		\| <nowiki>RFC 6455</nowiki><ref>{{RFC-Internet \|RFC=6455 \|Titel=The WebSocket Protocol Version 13 \|Datum=2011}}</ref>
	\|}		\|}

Zeile 58:		Zeile 57:
	</syntaxhighlight>		</syntaxhighlight>

	Durch den [[HTTP-Statuscode]] 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist. Von diesem Zeitpunkt an verwenden beide ein binäres Protokoll, das nicht mehr HTTP-kompatibel ist. Es ist in Pakete aufgeteilt, die als Binär oder Text, als Ping oder Pong oder als Ende der Verbindung markiert sind und die Länge des Inhalts angeben.<ref>~~[https://tools.ietf.org/html/rfc6455#section~~-5.2 Base Framing Protocoll~~] in RFC 6455~~</ref>		Durch den [[HTTP-Statuscode]] 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist. Von diesem Zeitpunkt an verwenden beide ein binäres Protokoll, das nicht mehr HTTP-kompatibel ist. Es ist in Pakete aufgeteilt, die als Binär oder Text, als Ping oder Pong oder als Ende der Verbindung markiert sind und die Länge des Inhalts angeben.<ref>{{RFC-Internet \|RFC=6455 \|Titel=The WebSocket Protocol Version 13 \|Datum=2011 \|Abschnitt=5.2 \|Abschnittstitel=Base Framing Protocoll}}</ref>

	Der zurückgesendete Schlüssel unter „Sec-WebSocket-Accept“ dient der Verifikation, dass der Server die Anfrage des Clients gelesen hat. Er wird wie folgt erstellt: An den oben erwähnten, [[Base64]]-kodierten String, den der Client sendet („Sec-WebSocket-Key“) wird der [[Globally Unique Identifier]] <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> angehängt. Daraufhin wird ein [[Secure Hash Algorithm\|SHA1-Hash]] des entstandenen Schlüssels erstellt und Base64-kodiert. Anzumerken ist hierbei, dass der ursprünglich empfangene Schlüssel zwar Base64-kodiert ist, jedoch zu keinem Zeitpunkt dekodiert wird.		Der zurückgesendete Schlüssel unter „Sec-WebSocket-Accept“ dient der Verifikation, dass der Server die Anfrage des Clients gelesen hat. Er wird wie folgt erstellt: An den oben erwähnten, [[Base64]]-kodierten String, den der Client sendet („Sec-WebSocket-Key“) wird der [[Globally Unique Identifier]] <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> angehängt. Daraufhin wird ein [[Secure Hash Algorithm\|SHA1-Hash]] des entstandenen Schlüssels erstellt und Base64-kodiert. Anzumerken ist hierbei, dass der ursprünglich empfangene Schlüssel zwar Base64-kodiert ist, jedoch zu keinem Zeitpunkt dekodiert wird.
Zeile 65:		Zeile 64:

	== Beispiel ==		== Beispiel ==
	WebSocket Client in [[JavaScript]]<syntaxhighlight lang="javascript" line="1">		WebSocket Client in [[JavaScript]]
			<syntaxhighlight lang="javascript" line="1">
	var socket = new WebSocket(urlToWebsocketServer);		var socket = new WebSocket(urlToWebsocketServer);

Zeile 99:		Zeile 99:
	* [[Opera (Browser)\|Opera]], ab Version 10.70		* [[Opera (Browser)\|Opera]], ab Version 10.70
	* [[Microsoft Edge]], ab erster Version		* [[Microsoft Edge]], ab erster Version
	* [[Mozilla Firefox]], ab Version 4<ref>https://developer.mozilla.org/de/docs/WebSockets</ref>		* [[Mozilla Firefox]], ab Version 4<ref>[https://developer.mozilla.org/de/docs/WebSockets developer.mozilla.org]</ref>
	* [[Internet Explorer]], ab Version 10.0		* [[Internet Explorer]], ab Version 10.0

Zeile 106:		Zeile 106:

	== Weblinks ==		== Weblinks ==
	* ~~[https://datatracker.ietf.org/doc/html/rfc6455~~ RFC 6455 ~~– ''~~The WebSocket Protocol~~'']~~		* {{RFC-Internet \|RFC=6455 \|Titel=The WebSocket Protocol Version 13 \|Datum=2011}}
	* [https://websockets.spec.whatwg.org/ The WebSocket API] – WHATWG Entwurf für die API-Spezifikation		* [https://websockets.spec.whatwg.org/ The WebSocket API] – WHATWG Entwurf für die API-Spezifikation
	* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets		* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2.] community.oracle.com; Einführung in WebSockets
	* [https://www.heise.de/developer/artikel/WebSocket-Annaeherung-an-Echtzeit-im-Web-1260189.html ~~„WebSocket~~: Annäherung an Echtzeit im ~~Web“~~] ~~– Artikel über Websocket bei ''~~heise Developer''		* [https://www.heise.de/developer/artikel/WebSocket-Annaeherung-an-Echtzeit-im-Web-1260189.html ''WebSocket: Annäherung an Echtzeit im Web''.] heise Developer

	== Einzelnachweise ==		== Einzelnachweise ==
Zeile 116:		Zeile 116:
	{{Navigationsleiste W3C-Standards}}		{{Navigationsleiste W3C-Standards}}

	{{SORTIERUNG:Websockets}}
	[[Kategorie:JavaScript-Programmierschnittstelle]]		[[Kategorie:JavaScript-Programmierschnittstelle]]
	[[Kategorie:Internet-Anwendungsprotokoll]]		[[Kategorie:Internet-Anwendungsprotokoll]]

Juergeen: Grossschreibung gemaess RR § 55 (3) - siehe WP:Auskunft#Gross-/Kleinschreibung englischer Begriffe im Deutschen

2023-04-14T23:13:04Z

Grossschreibung gemaess RR § 55 (3) - siehe WP:Auskunft#Gross-/Kleinschreibung englischer Begriffe im Deutschen

← Nächstältere Version		Version vom 15. April 2023, 01:13 Uhr
Zeile 21:		Zeile 21:

	== Vorteile gegenüber reinem HTTP ==		== Vorteile gegenüber reinem HTTP ==
	Während bei einer reinen [[Hypertext Transfer Protocol\|HTTP]]-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, reicht es beim WebSocket-Protokoll, wenn der Client die Verbindung öffnet. Der Server kann dann diese offene Verbindung aktiv verwenden und neue Informationen an den Client ausliefern, ohne auf eine neue Verbindung des Clients zu warten. Eine vom Server initiierte Übertragung ist bei einer reinen HTTP-Verbindung nur durch verzögertes Antworten auf eine vom Client initiierte Anfrage möglich ([[long ~~polling~~]]). Seit HTTP/2 kann der Server auch Push-Meldungen absetzen.		Während bei einer reinen [[Hypertext Transfer Protocol\|HTTP]]-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, reicht es beim WebSocket-Protokoll, wenn der Client die Verbindung öffnet. Der Server kann dann diese offene Verbindung aktiv verwenden und neue Informationen an den Client ausliefern, ohne auf eine neue Verbindung des Clients zu warten. Eine vom Server initiierte Übertragung ist bei einer reinen HTTP-Verbindung nur durch verzögertes Antworten auf eine vom Client initiierte Anfrage möglich ([[long Polling]]). Seit HTTP/2 kann der Server auch Push-Meldungen absetzen.
	Zudem entfallen bei WebSockets die durch den HTTP-Header verursachten zusätzlichen Daten, die bei jeder Anfrage einige hundert Bytes umfassen können.		Zudem entfallen bei WebSockets die durch den HTTP-Header verursachten zusätzlichen Daten, die bei jeder Anfrage einige hundert Bytes umfassen können.
	Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.		Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.

217.61.195.200: Link

2023-04-08T14:51:38Z

Link

← Nächstältere Version		Version vom 8. April 2023, 16:51 Uhr
Zeile 21:		Zeile 21:

	== Vorteile gegenüber reinem HTTP ==		== Vorteile gegenüber reinem HTTP ==
	Während bei einer reinen [[Hypertext Transfer Protocol\|HTTP]]-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, reicht es beim WebSocket-Protokoll, wenn der Client die Verbindung öffnet. Der Server kann dann diese offene Verbindung aktiv verwenden und neue Informationen an den Client ausliefern, ohne auf eine neue Verbindung des Clients zu warten. Eine vom Server initiierte Übertragung ist bei einer reinen HTTP-Verbindung nur durch verzögertes Antworten auf eine vom Client initiierte Anfrage möglich (''long polling''). Seit HTTP/2 kann der Server auch Push-Meldungen absetzen.		Während bei einer reinen [[Hypertext Transfer Protocol\|HTTP]]-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, reicht es beim WebSocket-Protokoll, wenn der Client die Verbindung öffnet. Der Server kann dann diese offene Verbindung aktiv verwenden und neue Informationen an den Client ausliefern, ohne auf eine neue Verbindung des Clients zu warten. Eine vom Server initiierte Übertragung ist bei einer reinen HTTP-Verbindung nur durch verzögertes Antworten auf eine vom Client initiierte Anfrage möglich ([[long polling]]). Seit HTTP/2 kann der Server auch Push-Meldungen absetzen.
	Zudem entfallen bei WebSockets die durch den HTTP-Header verursachten zusätzlichen Daten, die bei jeder Anfrage einige hundert Bytes umfassen können.		Zudem entfallen bei WebSockets die durch den HTTP-Header verursachten zusätzlichen Daten, die bei jeder Anfrage einige hundert Bytes umfassen können.
	Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.		Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.

Hajo.thelen: /* Weblinks */ der alte W3C Linkt wurde zu whatwg.org weiter geleitet und landete dort auf einer 404 Seite. Ich denke so passt es wieder.

2023-02-10T10:51:46Z

Weblinks: der alte W3C Linkt wurde zu whatwg.org weiter geleitet und landete dort auf einer 404 Seite. Ich denke so passt es wieder.

← Nächstältere Version		Version vom 10. Februar 2023, 12:51 Uhr
Zeile 107:		Zeile 107:
	== Weblinks ==		== Weblinks ==
	* [https://datatracker.ietf.org/doc/html/rfc6455 RFC 6455 – ''The WebSocket Protocol'']		* [https://datatracker.ietf.org/doc/html/rfc6455 RFC 6455 – ''The WebSocket Protocol'']
	* [~~http~~://~~dev~~.w3.org~~/html5/websockets~~/ The WebSocket API] – ~~W3C~~ Entwurf für die API-Spezifikation		* [https://websockets.spec.whatwg.org/ The WebSocket API] – WHATWG Entwurf für die API-Spezifikation
	* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets		* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets
	* [https://www.heise.de/developer/artikel/WebSocket-Annaeherung-an-Echtzeit-im-Web-1260189.html „WebSocket: Annäherung an Echtzeit im Web“] – Artikel über Websocket bei ''heise Developer''		* [https://www.heise.de/developer/artikel/WebSocket-Annaeherung-an-Echtzeit-im-Web-1260189.html „WebSocket: Annäherung an Echtzeit im Web“] – Artikel über Websocket bei ''heise Developer''

Trustable: Auf dieser Webseite sind die Überschriften anklickbar

2021-07-22T06:49:26Z

Auf dieser Webseite sind die Überschriften anklickbar

← Nächstältere Version		Version vom 22. Juli 2021, 08:49 Uhr
Zeile 12:		Zeile 12:
	\|-		\|-
	\| align="center" colspan="2" \|		\| align="center" colspan="2" \|
	{{Netzwerk-TCP-IP-Anwendungsprotokoll\|WebSocket\|}}		{{Netzwerk-TCP-IP-Anwendungsprotokoll\|WebSocket}}
	\|-		\|-
	\| '''Standards:'''		\| '''Standards:'''
Zeile 106:		Zeile 106:

	== Weblinks ==		== Weblinks ==
	* [https://~~www~~.~~rfc-editor~~.org/~~info~~/rfc6455 RFC 6455 – ''The WebSocket Protocol'']		* [https://datatracker.ietf.org/doc/html/rfc6455 RFC 6455 – ''The WebSocket Protocol'']
	* [http://dev.w3.org/html5/websockets/ The WebSocket API] – W3C Entwurf für die API-Spezifikation		* [http://dev.w3.org/html5/websockets/ The WebSocket API] – W3C Entwurf für die API-Spezifikation
	* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets		* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets

ProfIT: Link to actual destination instead into void.

2021-07-22T06:11:19Z

Link to actual destination instead into void.

← Nächstältere Version		Version vom 22. Juli 2021, 08:11 Uhr
Zeile 106:		Zeile 106:

	== Weblinks ==		== Weblinks ==
	* [~~http~~://~~tools~~.~~ietf~~.org/~~html~~/rfc6455 RFC 6455 – ''The WebSocket Protocol'']		* [https://www.rfc-editor.org/info/rfc6455 RFC 6455 – ''The WebSocket Protocol'']
	* [http://dev.w3.org/html5/websockets/ The WebSocket API] – W3C Entwurf für die API-Spezifikation		* [http://dev.w3.org/html5/websockets/ The WebSocket API] – W3C Entwurf für die API-Spezifikation
	* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets		* [https://community.oracle.com/docs/DOC-982926 HTML5 Server-Push Technologies, Part 2] – Einführung in WebSockets

1234qwer1234qwer4: Section heading change: URL-Schema → URI-Schema using a script

2021-05-20T07:29:56Z

Section heading change: URL-Schema → URI-Schema using a script

← Nächstältere Version		Version vom 20. Mai 2021, 09:29 Uhr
Zeile 25:		Zeile 25:
	Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.		Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende [[Transmission Control Protocol\|TCP]]-Verbindung bestehen bleibt und asynchrone Übertragungen in beide Richtungen ermöglicht.

	== ~~URL~~-Schema ==		== URI-Schema ==
	Die WebSocket-Protokoll-Spezifikation definiert zwei neue [[Uniform Resource Identifier\|URI]]-Schemata, ''ws:'' für unverschlüsselte, und ''wss:'' für verschlüsselte Verbindungen.		Die WebSocket-Protokoll-Spezifikation definiert zwei neue [[Uniform Resource Identifier\|URI]]-Schemata, ''ws:'' für unverschlüsselte, und ''wss:'' für verschlüsselte Verbindungen.

2003:D4:3738:6900:CD1:4F5A:2DB9:E285: /* Antwort des Servers */

2021-02-08T11:48:14Z

Antwort des Servers

← Nächstältere Version		Version vom 8. Februar 2021, 13:48 Uhr
Zeile 58:		Zeile 58:
	</syntaxhighlight>		</syntaxhighlight>

	Durch den [[HTTP-Statuscode]] 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist. Von diesem Zeitpunkt an verwenden beide ein binäres Protokoll, das nicht mehr HTTP-~~Kompatibel~~ ist. Es ist in Pakete aufgeteilt, die als Binär oder Text, als Ping oder Pong oder als Ende der Verbindung markiert sind und die Länge des Inhalts angeben.<ref>[https://tools.ietf.org/html/rfc6455#section-5.2 Base Framing Protocoll] in RFC 6455</ref>		Durch den [[HTTP-Statuscode]] 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist. Von diesem Zeitpunkt an verwenden beide ein binäres Protokoll, das nicht mehr HTTP-kompatibel ist. Es ist in Pakete aufgeteilt, die als Binär oder Text, als Ping oder Pong oder als Ende der Verbindung markiert sind und die Länge des Inhalts angeben.<ref>[https://tools.ietf.org/html/rfc6455#section-5.2 Base Framing Protocoll] in RFC 6455</ref>

	Der zurückgesendete Schlüssel unter „Sec-WebSocket-Accept“ dient der Verifikation, dass der Server die Anfrage des Clients gelesen hat. Er wird wie folgt erstellt: An den oben erwähnten, [[Base64]]-kodierten String, den der Client sendet („Sec-WebSocket-Key“) wird der [[Globally Unique Identifier]] <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> angehängt. Daraufhin wird ein [[Secure Hash Algorithm\|SHA1-Hash]] des entstandenen Schlüssels erstellt und Base64-kodiert. Anzumerken ist hierbei, dass der ursprünglich empfangene Schlüssel zwar Base64-kodiert ist, jedoch zu keinem Zeitpunkt dekodiert wird.		Der zurückgesendete Schlüssel unter „Sec-WebSocket-Accept“ dient der Verifikation, dass der Server die Anfrage des Clients gelesen hat. Er wird wie folgt erstellt: An den oben erwähnten, [[Base64]]-kodierten String, den der Client sendet („Sec-WebSocket-Key“) wird der [[Globally Unique Identifier]] <code>258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code> angehängt. Daraufhin wird ein [[Secure Hash Algorithm\|SHA1-Hash]] des entstandenen Schlüssels erstellt und Base64-kodiert. Anzumerken ist hierbei, dass der ursprünglich empfangene Schlüssel zwar Base64-kodiert ist, jedoch zu keinem Zeitpunkt dekodiert wird.