Mail Order vs Tech Support: HTTP and Sockets in Plain English

A programmer’s job is, in essence, to create things that don’t really exist out of other things that don’t really exist. In what is now technically a series of articles (read: this is part two), I will be trying to explain fundamental programming concepts with simple, tangible metaphors.

If you’re at all involved with web apps, either because you’re learning to develop them, or work with people who do, you have likely been hearing a lot of talk about HTTP and sockets. You probably know that both concepts are related to network communication, but the difference between them might not be entirely clear. Let’s try a comparison to explore the two.

HTTP

Imagine, if you will, that you’re buying something from a mail order catalog.

Also, imagine you’re over thirty and think mail order catalogs are still a thing. (Micheile Henderson, Unsplash)

You fill out a form in which you describe what item you want, you send it to the provider, and eventually you’ll get a response from them. This is the essence of HTTP: the client sends a request, and the server sends a response to that request.

Ideally, the response will be the item you requested, but there might be other results. In HTTP, each response is marked with a three-digit status code that indicates its general nature. In our analogy, you could picture it as stamped on the reply envelope, so you can immediately glean what the gist of it is.

• A successful request is stamped with the code 200 OK.
• The provider might let you know you made a mistake in your form and they were unable to process it (400 Bad Request).
• You might have requested an item that’s only available to certain members of the provider’s customer club, without attaching any proof of your membership. In this case, they might require you to send it in (401 Unauthorized), or deny it outright (403 Forbidden).
• You might have requested an item that the provider doesn’t have (404 Not Found).
• The provider might have moved to a different office, and ask you to resubmit your order to that address (301 Moved). More often than not, the “post office” (i.e. the HTTP client in your software) will do this automatically.
• And sometimes, the provider might just be unable to fulfil your request for some other technical reason (500 Internal Server Error).

This analogy also helps remember some of the key characteristics and limitations of HTTP:

• Each transaction consists of one request, and one response. If you want any kind of follow-up, you have to submit another request.
• There is no guarantee you’ll ever get a response to your request, or even any confirmation that the server received it. All you can do is sit and wait until you eventually get bored and give up (Request Timeout).
• Compared to some other types of communication, HTTP has pretty significant overhead: you have to wrap it, stamp it, and address it with the server’s full address. Each individual message is treated as though it was the first message you’ve ever sent (Statelessness).

Limited or not, HTTP is still the most widely used protocol today, as the entire internet is built upon it. Pretty much any programming language or framework that is capable of network communication will support it natively, so developers don’t have to adopt a new protocol in every system they work with.

Sockets

Mail order services are fine if you just want to request something, but they’re not very well suited for longer discussions. If you have a problem with your product and want to contact tech support, you won’t want to spend weeks in a single conversation. It’s also not suited for communicating with multiple parties in parallel; in HTTP, each message has one and precisely one recipient.

Given the single-user nature of most apps, this has not been much of a concern in the web’s first two decades. However, as time passed and technology grew in complexity, the need arose for even more instantaneous communication. Hence the web adopted sockets.

If HTTP can be compared to mail order, then a socket is like a phone call. You initiate the connection, wait for the other party to respond, then freely exchange messages back and forth until one of you decides to hang up (or the line breaks for some other reason). Here are some ways in which you may compare sockets to HTTP messages:

• In HTTP, one request triggers one response. In a socket connection, either party may send any number of messages, without waiting for the other to respond.
• In HTTP, each message has to be stamped and addressed as if it was the very first. In a socket connection, the call opens with a brief handshake that establishes who the communicating parties are, and all subsequent messages consist of pure data (Statefulness).
• Much like in HTTP, a socket connection may break at any moment without any indication. The same way you’d say a quick “Hello?” if the line fell silent, either of the parties may send a brief message (ping) to which the other party should immediately reply (pong) to confirm the connection is still alive.
• In HTTP, only clients may initiate connections, and only to servers. With sockets, servers can easily group clients together into “conference calls” (rooms). Each time one of the clients says something, the server will immediately repeat that message to the other live connections in the room.

Unlike an actual conference call, there’s a significantly lower chance of any one party eating a bag of chips during the connection. You know who you are. (Nick Youngson, Alpha Stock Images)

WebSockets

Socket connections have existed long before the internet itself, and their adoption in web apps has in fact posed a bit of difficulty for both server and browser developers. Since the web was built entirely on HTTP, a browser could not assume that any particular server would support sockets; trying to initiate a connection could therefore lead to all sorts of unpredictable results. The way it was eventually implemented marries both technologies to allow a smooth and fail-safe transition from one protocol to the other:

1. The browser sends a special HTTP request to indicate that it wishes to open a WebSocket connection.
2. If the server doesn’t support sockets, it will be unable to process the request; thus, it returns HTTP code 400 (Bad Request), and the communication ends there.
3. If the server does support WebSockets, it returns HTTP code 101 (Switching Protocols) and prepares to accept the socket connection.
4. The browser can now safely open the socket, knowing the data will be received on the other end.
5. Once the connection’s established, the browser and the server perform the handshake and proceed with the exchange of data.

If steps 1 to 3 didn’t take place, and the browser incorrectly assumed that a server supports WebSockets, it would just start sending random pieces of data that the server wouldn’t know what to do with (since the server is expecting properly stamped and addressed HTTP messages).

Since their introduction in 2011, browser support for WebSockets at this point is practically universal. The technology has opened up a slew of exciting new options for developers, from real-time chat to streaming to online games.

Truly what 25 years of technological development has been building up to.

Mate Safranka is a frontend developer at Supercharge. If you liked this article, you may be interested in part one about layers of abstraction, or perhaps the 5 ways that writing prose can help you code better.