Q1. What is WebSocket?
WebSocket is an application-layer protocol that begins with an HTTP Upgrade, continues over the same underlying TCP connection, and allows the client and server to exchange messages in both directions.
Q2. What is the core purpose of WebSocket?
The core purpose of WebSocket is to let the server and client send messages to each other without creating a new HTTP request every time one side needs to send data.
Q3. Is WebSocket the same as TCP?
No. TCP is a transport-layer protocol that provides a reliable ordered byte stream. WebSocket is an application-layer protocol that uses TCP to exchange application messages.
Q4. What is a socket?
See What Is a Socket? - Source Note.
Q5. What does it mean that WebSocket keeps the connection open?
It means the underlying TCP connection remains alive after the initial HTTP upgrade, so later messages can be sent through the same connection.
Q6. Does WebSocket change TCP itself?
No. WebSocket does not change TCP. It changes how the application interprets the data flowing over the TCP connection.
Q7. What changes during the HTTP Upgrade?
The application-layer protocol changes. The connection starts as HTTP, and after the server accepts the upgrade, the same TCP connection is used for WebSocket frames instead of normal HTTP request-response messages.
Q8. Why does WebSocket start with HTTP?
WebSocket starts with HTTP because it is designed to work in the existing web environment, including browsers, web servers, proxies, and load balancers.
Q9. How is WebSocket different from normal HTTP?
Normal HTTP is mainly request-response based: the client sends a request, and the server sends a response. WebSocket keeps the connection open so either side can send messages later.
Q10. Can HTTP keep a TCP connection open too?
Yes. HTTP keep-alive can reuse a TCP connection for multiple HTTP requests and responses. But that is still HTTP request-response communication, not WebSocket-style bidirectional messaging.
Q11. Can HTTP behave like WebSocket if the TCP connection stays open?
Not exactly. Keeping a TCP connection open is not enough. WebSocket also changes the application protocol so that both sides can exchange messages without creating new HTTP requests.
Q12. Why is keeping the TCP connection open not enough?
TCP is only a persistent bidirectional byte stream. It does not know whether the bytes flowing through it represent HTTP, WebSocket, or a custom protocol.
Q13. What defines the meaning of bytes flowing over TCP?
The application protocol running on top of TCP defines what the bytes mean, when messages begin and end, and which communication patterns are valid.
Q14. What are HTTP’s normal communication semantics?
HTTP is an application protocol with request-response semantics: a client sends a request, and that request is associated with a response.
Q15. Could HTTP send response 2, response 3, and more for one completed request?
Not as standard HTTP. Once the final response message for a request is complete, the response for that request is complete.
Q16. What are HTTP 1xx responses, and why are they different from WebSocket messages?
HTTP can include informational 1xx responses before the final response, but they are protocol-level interim responses, not independent application messages like WebSocket messages.
Q17. Does HTTP keep-alive turn one completed request into unlimited responses?
No. HTTP persistent connections allow the same TCP connection to be reused for later HTTP messages, but they do not turn one completed request into an unlimited sequence of separate completed final responses.
Q18. Can HTTP headers redefine one completed request as an unlimited sequence of responses?
No. Headers can add metadata within HTTP’s rules, but they cannot make standard clients, servers, proxies, and libraries reinterpret later messages as more final responses for the same completed request.
Q19. What if a client and server agree to treat later messages as more responses?
Then they are defining custom behavior rather than relying on standard HTTP semantics. The protocol may start with HTTP-like syntax, but the meaning of later bytes is no longer ordinary HTTP.
Q20. How do HTTP streaming and SSE differ from multiple HTTP responses?
HTTP streaming and SSE keep one HTTP response body open and continue writing data into that still-active response. They do not send multiple completed HTTP responses for one request.
Q21. What is the essential difference between HTTP keep-alive and WebSocket?
HTTP keep-alive reuses one TCP connection for multiple HTTP request-response exchanges. WebSocket switches the application protocol so both sides exchange WebSocket frames over the same TCP connection.
Q22. What is the key distinction behind the HTTP versus WebSocket confusion?
The key distinction is TCP connection persistence versus application protocol semantics. TCP can keep bytes flowing in both directions, but HTTP and WebSocket define different meanings for those bytes.
Q23. What is a server-to-client update?
A server-to-client update is data that the server needs to send to the client because something changed on the server side, such as a new chat message, notification, or status change.
Q24. Why is WebSocket useful for server-to-client updates?
WebSocket is useful because the server can send updates through the already-open connection instead of waiting for the client to make another HTTP request.
Q25. Is “without creating a new HTTP request for every server-to-client update” a good expression?
Yes, it is understandable. A clearer version is: “without creating a new HTTP request every time the server needs to send an update to the client.”
Q26. What is SSE?
SSE, or Server-Sent Events, is an HTTP-based technique where the server keeps a response open and sends events to the client over time.
Q27. How is SSE different from WebSocket?
SSE is mainly server-to-client communication. WebSocket is bidirectional, so both the client and server can send messages through the same connection.
Q28. Does SSE also keep an HTTP request open?
Yes. With SSE, the client sends an HTTP request, and the server keeps the response open while sending events over time.
Q29. Can SSE or WebSocket be affected by server timeout settings?
Yes. Long-lived connections can be affected by application server timeouts, proxy timeouts, load balancer idle timeouts, web server timeout settings, or platform-specific timeout rules.
Q30. Does one WebSocket connection always occupy one server thread?
Not necessarily. In a blocking model, it can. In modern asynchronous or non-blocking servers, the connection can stay open without holding one dedicated thread the entire time.
Q31. What resources does a WebSocket connection consume?
A WebSocket connection consumes server resources such as socket state, memory, connection objects, kernel buffers, and sometimes event-loop or thread-pool work when data is read or written.
Q32. Where does the server store active WebSocket connections?
The OS manages the actual TCP socket state, while the server framework exposes a session or connection object. The application may store those session objects in an in-memory registry.
Q33. Is that just a global variable?
In a simple example, it may look like a global map. More precisely, it is a connection registry that maps users, rooms, or channels to active WebSocket session objects.
Q34. What might a simple WebSocket connection registry look like?
It may look like userId -> WebSocketSession or roomId -> Set<WebSocketSession>.
Q35. What happens when the server wants to send a message later?
The server finds the relevant WebSocket session from its registry and writes a message to it. The runtime then sends that message through the underlying TCP connection.
Q36. What if the user is not connected?
The server cannot deliver the message through WebSocket immediately. The application must either ignore it, store it, send another kind of notification, or let the client fetch missed state after reconnecting.
Q37. Does WebSocket guarantee message order?
Within one WebSocket connection, messages are generally delivered in order because WebSocket runs over TCP. But application-level ordering can still require separate design in multi-server or reconnect scenarios.
Q38. Does WebSocket guarantee that no message is ever lost?
No. WebSocket is reliable while the connection is alive, but missed messages, reconnection recovery, retries, and duplicate handling belong to application-level design.
Q39. What does WebSocket not handle?
WebSocket does not handle authentication, authorization, message persistence, offline delivery, business rules, room membership, or multi-server message routing by itself.
Q40. When should WebSocket be used?
WebSocket should be used when the client and server need continuous bidirectional messaging, such as chat, online games, collaborative editing, or interactive real-time dashboards.
Q41. When is WebSocket unnecessary?
WebSocket is usually unnecessary for simple request-response tasks such as login, loading a page, fetching a list, submitting a form, or checking rarely changing data.
Q42. What is the durable protocol insight behind WebSocket?
Do not confuse a lower-layer capability with higher-layer protocol behavior. A transport layer may allow bidirectional bytes to flow, but the application protocol defines what those bytes mean.
Q43. When does this distinction matter?
It matters when comparing HTTP keep-alive, HTTP streaming, Server-Sent Events, WebSocket, and custom protocols. The important question is not only whether the underlying connection stays open, but what semantics the protocol defines above that connection.