Wie funktioniert ein WebSocket-Schlüssel?

Question

Vor kurzem habe ich WebSockets recherchiert, ich denke, sie sind sehr cool. Allerdings, wenn ich einen Blick auf here werfen, sind einige Dinge für mich unklar.

Anfrage:

GET /chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== 
Sec-WebSocket-Protocol: chat, superchat 
Sec-WebSocket-Version: 13 
Origin: http://example.com 

Antwort:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= 
Sec-WebSocket-Protocol: chat 

Der Anforderer gibt den Host, wird so Zwischenserver wissen, wo die Anforderung sollte ankommen. Der Anforderer sendet eine zufällige Zeichenfolge, die in base64 codiert ist, und der Server sendet einen gesalzenen SHA1-verschlüsselten Schlüssel zurück. Wird dieser Schlüssel zwischen den beiden verwendet, während die Verbindung besteht? Wenn ja, gibt es einen Weg, wie dieser Schlüssel wiederverwendet werden kann, selbst wenn die Verbindung unterbrochen wurde?

Answer 1

Wie es in der Wikipedia Link erwähnt wird:

Zusätzlich Header zu aktualisieren, sendet der Client eine Sec-WebSocket-Key-Header base64-codierte zufällige Bytes enthalten und der Server antwortet mit einem Hash des Schlüssels im Sec-WebSocket-Accept-Header. Dies soll verhindern, dass ein Caching-Proxy eine vorherige WebSocket-Konversation erneut sendet, und bietet keine Authentifizierung, Datenschutz oder Integrität.

Sec-WebSocket-Key wird nur im Inneren des Handshake verwendet und ist nicht für die eigentliche Kommunikation verwendet.

Der Schlüssel soll verhindern, dass Proxys die Anfrage zwischenspeichern, indem sie einen zufälligen Schlüssel senden. Wenn der Proxy weiterhin eine zwischengespeicherte Antwort zurückgibt, kann er überprüft werden, indem der Header Sec-WebSocket-Accept überprüft wird.

Der Client könnte den Header Sec-WebSocket-Accept ignorieren (und hoffe, dass die Antwort nicht zwischengespeichert wird) und das WebSocket-Protokoll würde immer noch normal funktionieren.
In diesem Fall könnte der Server so implementiert werden, dass der Header Sec-WebSocket-Key ignoriert wird und der Header Sec-WebSocket-Accept nicht zurückgegeben wird.

Wie die Sec-WebSocket-Accept Header für Antwort oder Bestätigung zu erzeugen, kann innerhalb dieser Antwort gelesen werden:
generate "Sec-WebSocket-Accept" from "Sec-WebSocket-Key"

Answer 2

Die Hashing-Funktion anhängt den feststehenden String 258EAFA5-E914-47DA-95cA-C5AB0DC85B11 (a GUID) auf den Wert von Sec-WebSocket-Key-Header (die von Base64 nicht decodiert wird), wendet die SHA-1-Hashing-Funktion und codiert das Ergebnis mit Base64.

https://en.wikipedia.org/wiki/WebSocket#Protocol%20handshake

Mehr Infos unter: https://tools.ietf.org/html/rfc6455#section-1.3