RFC 6455 Websocket 標準に準拠
最初の部分:
.. the server has to prove to the client that it received the
client's WebSocket handshake, so that the server doesn't accept
connections that are not WebSocket connections. This prevents an
attacker from tricking a WebSocket server by sending it carefully
crafted packets using XMLHttpRequest [XMLHttpRequest] or a form
submission.
...
For this header field, the server has to take the value (as present
in the header field, e.g., the base64-encoded [RFC4648] version minus
any leading and trailing whitespace) and concatenate this with the
Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
95CA-C5AB0DC85B11" in string form, which is unlikely to be used by
network endpoints that do not understand the WebSocket Protocol.
第二部：
The |Sec-WebSocket-Key| header field is used in the WebSocket opening
handshake. It is sent from the client to the server to provide part
of the information used by the server to prove that it received a
valid WebSocket opening handshake. This helps ensure that the server
does not accept connections from non-WebSocket clients (e.g., HTTP
clients) that are being abused to send data to unsuspecting WebSocket
servers.
したがって、GUID の値は標準で指定されているため、Websocket を認識していないサーバーがそれを使用する可能性はほとんどありません(可能性は非常に低いと言えます)。セキュリティは提供しません (安全な websockets - wss:// - は提供します)。サーバーが websockets プロトコルを理解することを保証するだけです。
本当に、あなたが言及したように、Websocket を認識している場合 (これを確認する必要があります)、正しい応答を送信することで Websocket サーバーのふりをすることができます。ただし、正しく動作しない場合 (フレームを正しく形成するなど)、プロトコル違反と見なされます。実際には、正しくない Websocket サーバーを作成することはできますが、あまり役に立ちません。
もう 1 つの目的は、クライアントが Websockets のアップグレードを期待せずに誤って要求するのを防ぐことです (たとえば、対応するヘッダーを手動で追加してから、他の方法を期待することによって)。Sec-WebSocket-Key およびその他の関連するヘッダーはsetRequestHeader、ブラウザーのメソッドを使用して設定することは禁止されています。