HTTP & APIs Interview Questions: Realtime & WebSockets

After the HTTP upgrade handshake, the WebSocket stays open on a single TCP connection, and either side can send messages independently whenever it wants. This is the persistent, full-duplex behaviour the statement describes. Plain HTTP/1.1 differs because it is request-response: the client sends a request, the server replies, and the exchange ends, even though keep-alive may reuse the connection for later requests.

A WebSocket connection begins as an HTTP request with an Upgrade: websocket header. When the server agrees to switch protocols, it responds with HTTP status code 101 (Switching Protocols). After that, the connection transitions from HTTP to the WebSocket protocol on the same TCP socket. Status codes like 200 and 201 are for normal HTTP request success, not protocol upgrades, and 100 is the Continue interim response used for request body expectations.

RFC 6455 defines two URI schemes for WebSocket endpoints. The ws:// scheme designates an unencrypted WebSocket connection, the direct analogue of http://, while wss:// designates a TLS-secured connection, the analogue of https://. Because the question explicitly asks only about the unencrypted variant, the single correct answer is ws://.

Per RFC 6455 Section 4.2.2, a valid 101 response must contain Upgrade: websocket and Connection: Upgrade to switch protocols, and Sec-WebSocket-Accept, which is computed by appending the fixed GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 to the client's Sec-WebSocket-Key, taking the SHA-1 hash, and base64-encoding it; for this key the result is s3pPLMBiTxaQ9kYGzzhZRbK+xOo=. Because the client offered subprotocols and the server supports one of them (mqtt, not chat), the server must echo the selected one in Sec-WebSocket-Protocol: mqtt.

WebSockets begin as an HTTP request carrying an Upgrade header; once the server accepts, the connection switches protocols and stays open as a single persistent TCP channel. Both client and server can send messages at any time without the client first issuing a request. A standard HTTP/1.1 exchange is request-response, where the client initiates each cycle and the server replies, so the statement is true.

A WebSocket upgrade request asks the server to switch protocols; on success the server responds with 101 Switching Protocols, after which the connection operates as WebSocket. 426 Upgrade Required is a server demand that the client upgrade, not the success signal.

The WebSocket opening handshake uses the HTTP Upgrade mechanism. The Upgrade header names the target protocol, which is websocket, and the Connection header carries the Upgrade token so that intermediaries forward the upgrade request rather than treating the header as hop-by-hop and dropping it.

After the WebSocket opening handshake completes, the connection upgrades from HTTP to WebSocket and operates in full-duplex mode over a single persistent TCP connection. Both the client and the server can independently push messages to each other at any time, without either side waiting for the other to make a request first, which is unlike the request-response pattern of plain HTTP. The expected answer names this mode as full-duplex (or equivalently bidirectional) and notes that both sides can send messages at any time over the single persistent connection.

The statement is true. RFC 6455 defines WebSocket as a persistent, full-duplex channel carried over a single TCP connection that is established by an HTTP Upgrade handshake. Unlike HTTP/1.1 request–response, where the server can only reply after a request, either endpoint can send frames at any time over that same long-lived connection.

RFC 6455 requires the client to send a Sec-WebSocket-Key request header containing a Base64-encoded random 16-byte value. The server concatenates this key with the magic GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, computes SHA-1, Base64-encodes the result, and returns it in the Sec-WebSocket-Accept response header. This round-trip proves the server genuinely processed the WebSocket handshake rather than blindly forwarding an HTTP request.

WebSockets begin with an HTTP handshake that upgrades the connection to a persistent, full-duplex channel over TCP, so the server can push messages at any time without the client repeatedly asking for them. Long-polling instead requires the client to issue HTTP requests, or hold one open until data arrives and then re-issue it, which adds per-request overhead and latency. The statement naming UDP is wrong because WebSockets run over TCP. The statement about a new connection per message is backwards, since a WebSocket keeps one connection open rather than opening one per message. The statement that long-polling is full-duplex is wrong, because long-polling is a sequence of request/response exchanges and WebSockets are the full-duplex option.

The WebSocket handshake (RFC 6455) begins as an ordinary HTTP/1.1 GET request carrying Upgrade: websocket and Connection: Upgrade headers, along with a Sec-WebSocket-Key header. A server that supports WebSockets and accepts the request responds with 101 Switching Protocols and a Sec-WebSocket-Accept value derived from the key. From that point the same TCP connection uses the WebSocket binary framing protocol instead of HTTP semantics, enabling full-duplex message exchange. A strong answer names the request headers, the 101 response, and the fact that the same connection switches protocols.

A WebSocket starts as an ordinary HTTP GET carrying Upgrade: websocket headers; a server that accepts it answers 101 Switching Protocols and the same TCP connection is then reused for WebSocket frames. Because that connection persists and supports full-duplex messaging, each message avoids the per-request cost of a new HTTP request/response cycle with its headers, which is why latency and overhead drop for frequent or server-initiated messages.

The HTML Living Standard requires SSE responses to use the MIME type text/event-stream, which is how the browser's EventSource recognizes the stream. Within the stream, each field is a line, and an event is terminated by an empty line: two consecutive line terminators such as \n\n. When the parser encounters that blank line, it dispatches the buffered event (multiple data: lines in one event are joined with newlines into a single MessageEvent). Both parts of the answer are needed: the MIME type and the blank-line delimiter.

Per RFC 6455, a WebSocket server completes the protocol upgrade by responding with 101 Switching Protocols. To prove it understood the handshake, the server takes the client's Sec-WebSocket-Key value, appends the fixed GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, computes the SHA-1 hash of the concatenation, base64-encodes the result, and returns it in the Sec-WebSocket-Accept header. The status is 101, not 200, because the upgrade is accepted and the protocol is switching. The accept value is derived deterministically from the key plus the GUID — it is neither an echo of the key nor a random nonce. The GUID ensures a non-WebSocket intermediary that ignores the Upgrade header cannot accidentally satisfy the handshake.

SSE is a one-way channel: the server writes events over a persistent HTTP response, and the client cannot send data back over that same stream, so it must use a separate HTTP request. WebSocket upgrades the connection to a full-duplex protocol in which both sides can send frames at any time over the same TCP connection. Chat needs the client to send messages upstream continuously as well as receive them, which makes WebSocket's bidirectional capability the deciding factor.

The Sec-WebSocket-Key is a client-generated nonce. The server must append the RFC 6455 magic GUID, hash with SHA-1, and Base64-encode the digest into Sec-WebSocket-Accept. Only a server that parsed the upgrade request and implements the WebSocket protocol can compute this value, so it proves the server understood the handshake and helps prevent cross-protocol attacks in which a plain HTTP server or caching proxy could be tricked into producing something that looks like a WebSocket response. The exchange does not authenticate the user, does not encrypt subsequent frames (that is the job of TLS in WSS), and does not select the subprotocol, which is handled by the separate Sec-WebSocket-Protocol header.

The WebSocket handshake (RFC 6455) reuses HTTP only to bootstrap, then leaves the request/response model entirely. The persistent full-duplex channel is what makes WebSockets suited to chat, live dashboards, and multiplayer — use cases where HTTP polling would be wasteful and high-latency.

RFC 6455 §7.4.1 defines three status codes with the explicit restriction 'MUST NOT be set as a status code in a Close control frame by an endpoint': 1005 (No Status Received — used internally when no close code was present), 1006 (Abnormal Closure — used internally when the connection dropped without a close frame), and 1015 (TLS Handshake — used internally when the TLS handshake fails). Although 1004 is listed as 'Reserved,' its entry in the spec merely states it is reserved for future use and does not carry the same 'MUST NOT be set in a Close control frame' language that 1005, 1006, and 1015 carry. The 4000–4999 range is designated for private use (§7.4.2), not reserved, so 4000 is not a forbidden reserved value.

Per RFC 6455 §7.4.1, status code 1005 ('No Status Received') is a reserved value that an endpoint uses internally when a close frame arrives without a status code; §7.4 forbids sending reserved codes, so no outgoing close frame may carry 1005. The option about 1006 is false for the same reason, since 1006 ('Abnormal Closure') is also reserved and must never appear in a frame on the wire. The option about tearing down TCP immediately is false because §5.5.1 requires an endpoint that receives a close frame to reply with its own close frame before closing the connection. The option about fragmenting close frames is false because §5.5 states that control frames, including close frames (opcode 0x8), MUST NOT be fragmented; only data frames may use continuation frames.

The frame bytes begin with 0x81: the high bit (FIN) is 1, and the low nibble (opcode) is 0x01, denoting a final text frame. The second byte 0x85 has the MASK bit set (high bit = 1) and a 7-bit payload length of 5. Per RFC 6455, frames from client to server must be masked; the next four bytes (0x37, 0xfa, 0x21, 0x3d) are the 32-bit masking key. The remaining five bytes (0x7f, 0x9f, 0x4d, 0x51, 0x58) are the masked payload. The parser extracts the masking key, then XORs each payload byte with the corresponding key byte (cyclically: index mod 4): 0x7f^0x37=0x48 ('H'), 0x9f^0xfa=0x65 ('e'), 0x4d^0x21=0x6c ('l'), 0x51^0x3d=0x6c ('l'), 0x58^0x37=0x6f ('o'). The recovered UTF-8 bytes decode to the string 'Hello'.

Frame 1: byte 0x01 gives FIN=0 and opcode 1 (text); byte 0x03 gives mask bit 0 and length 3, so the line is 'text fin=0 masked=0 len=3'. Frame 2: byte 0x80 gives FIN=1 and opcode 0 (continuation); byte 0x02 gives mask bit 0 and length 2, so the line is 'continuation fin=1 masked=0 len=2'. Frame 3: byte 0x88 gives FIN=1 and opcode 8 (close); byte 0x82 gives mask bit 1 and length 2, so the mask key is read from bytes 2-5 and the two payload bytes are unmasked to 0x03 and 0xE8 (status 1000); the line is 'close fin=1 masked=1 len=2'. Frame 4: byte 0x8A gives FIN=1 and opcode 10 (pong); byte 0x00 gives mask bit 0 and length 0, so the line is 'pong fin=1 masked=0 len=0'. The payload values never get printed, so only the header fields appear in the output.

Section 5.5 of RFC 6455 says control frames MUST NOT be fragmented, so every control frame carries FIN=1, and its payload is limited to 125 bytes, so it can never be split into continuation frames. Section 5.4 explicitly allows control frames to be injected between the fragments of a data message that is still in progress. The fragmentation-of-control-frames option contradicts the no-fragmentation rule, the ban on interleaving contradicts the explicit exception in section 5.4, and the oversized-Ping option contradicts the 125-byte cap, which makes splitting impossible.