WebSocket

RFC 6455’s baseline uses an HTTP/1.1 Upgrade request and a 101 response before exchanging messages. Server-originated data then need not wait for a new ordinary HTTP query for each message. Endpoint, subprotocol and extension choices still matter.

HTTP/2 instead uses Extended CONNECT on a stream, replacing the HTTP/1.1 Connection, Upgrade and Key/Accept handshake processing; HTTP/3 has a corresponding mapping. Bidirectional application capability is distinct from one particular opening format.

References: [1] [2] [3]

Messages can be text interpreted as UTF-8 or binary data with application-defined meaning. A message can span ordered fragments, and permitted intermediaries can split or combine frames. A network read is therefore not necessarily one complete message.

Ping, Pong and Close control frames can occur between message fragments, so control need not wait for one large message to finish. Base control frames are not fragmented, and arbitrary interleaving of separate messages requires applicable extension rules.

References: [1]

Clients use a fresh 32-bit masking key per baseline frame, and the key travels in that frame. Masking limits application control of wire bytes for intermediary safety; it is not confidentiality encryption, which requires an appropriate protected transport such as TLS.

Browser Origin information assists source checks rather than replacing account authentication or authorization. An established connection, delivered message and completed business action are separate states; reconnection, acknowledgment and deduplication remain application concerns.

References: [1]