In section 1.3 \"Opening Handshake\" of draft-ietf-hybi-thewebsocketprotocol-17, it describes Sec-WebSocket-Key
as follows:
To prove that the
Mostly for cache busting.
Imagine a transparent reverse-proxy server watching HTTP traffic go by. If it doesn't understand WS, it could mistakenly cache a WS handshake and reply with a useless 101 to the next client.
Using a nonce (the key) and requiring a basic challenge-response rather specific to WS ensures the server actually understood this was a WS handshake and in turn tells the client that the server will indeed be listening on the port. A caching reverse-proxy would never implement that hashing logic "by mistake".