Protocol basics: Packets and connections

Not so long ago, the easiest way, and in some cases the only practical way, to get in touch with someone a long distance away was to send a message by mail.  Physical mail, that is.  I found it handy when traveling in Europe, um a while ago, for example.  Rather than hunt down a payphone (really, spell check, you don't recognize "payphone"?), double-check that the other person was likely to be awake, buy a card or assemble the right pile of coins, dial, wait to see if the other person was actually home, and then worry about cramming a conversation into an alarmingly small number of minutes, it was often easier and more fun to buy a few postcards, scrawl "Having a lovely time, wish you were" on them, address them, stamp them and throw them in the nearest post box.

It's not that one couldn't make an international phone call, or that it was never worth it, just that it was often cheaper and easier not to.

Mail and the telephone are canonical examples of two basic ways of sending information.  These two ways have gone by various names, but the two that stick in my head are "packet-switched" (mail) vs. "circuit-switched" (phone), and "connection-oriented" (phone) vs. "connectionless" (mail).  Each approach has its own pros and cons and neither is perfect for every situation, which is why both are still going strong.

Connection-oriented protocols require time to set up the connection.  In the case of the telephone, this means identifying the other party (dialing the number) and establishing a connection (whatever the phone company does, plus waiting for the other party to pick up).  Both parties must participate in the connection at the same time.  Once this is done, however, communication is efficient.  I say something to you and you can reply immediately.  Depending on the exact protocol, we may even be able to both talk at once ("full-duplex") or we may have to take turns ("half-duplex"), but this distinction is more important in computer protocols than human conversations (human conversations are effectively half-duplex, as anyone who's ever said "no, you go ahead" at the same time as the other person will realize).

Connectionless protocols are the mirror image of this.  Setup is minimal.  You only have to identify the other party and send the message.  Depending on the protocol, your party may or may not have to be present to receive the message when it arrives.  On the other hand, you generally don't know whether your message arrived at all, and if you send two messages to the same person, they may or may not arrive in the order you sent them, and in some cases the same message might get sent more than once (though this is not likely to happen through the mails).

Of the common ways we exchange information as people, some are connection-oriented, for example, phone calls and video conferences, and some are connectionless, such as texting and email.

The underlying protocol of most of the internet, IP (for ... wait for it ... Internet Protocol) is connectionless.  You build a packet of data, slap an address on it, send it and hope for the best.  Generally there is no specific connection involved, though it used to be more common (in the days of dedicated T1 lines, PLIP and such) for IP to run on top of something that happened to us a point-to-point connection at a lower level.

However, most actual applications of the internet are connection-oriented.  When you browse a web page, for example, your browser uses a connection to the server serving the page.  That way it doesn't care whether the page fits in a single packet (which it almost certainly doesn't) and it knows for sure when it's retrieved the entire page.  Likewise, when you send mail, your mail client makes a connection to a mail server, when you join a videoconference your device makes a connection to the videoconference server, and so forth.

To bridge this gap, we use what is hands-down one of the most successful inventions in the field of computing: the Transmission Control Protocol, or TCP.  TCP assumes that you have some way -- it doesn't much care what -- to deliver packets of information -- it doesn't care what's in them and doesn't much care how big they are -- to a given address.  IP is one way of doing this, so you'll see the term TCP/IP for TCP using IP to transport packets, but it's not the only way.

From these basic assumptions, TCP allows you to pretend you have a direct connection to another party.  If you send a series of messages to that other party, you know that either they will all arrive, in order, or the whole connection will fail and you will know it failed.

This is a big improvement over simply sending messages and hoping they arrive.  The cost is that it takes time to set up a TCP connection, TCP adds extra traffic, particularly ACK (acknowledgement) messages to be sure that messages have arrived, it may have to re-send messages, and it requires each side of the connection to remember a certain amount of previous traffic.  For example, if I'm sending you a bunch of data, TCP will break that down into packets, and then keep track of which packets have and haven't been acknowledged.  If too many haven't been acknowledged, it will stop sending new data, slowing things down.  Each side also has to keep around any packets that it's sent but hasn't had acknowledged yet, since it may have to resend them.

Since setting up connections is expensive, we try to avoid it.  The worst case is establishing a fresh connection for each message to be sent.  In the early days of the web, HTTP/1.0 required a fresh connection for each object retrieved.  If your web page included an image, the browser would have to set up one connection to get the text of the web page, tear it down, and then set up a fresh connection to get the image, even if it was stored on the same server.  HTTP/1.1 fixed this with its "keep-alive" mechanism, but the same problem comes up in other contexts, with the same solution: re-use connections where possible.

A great many "application layer" protocols are built on TCP.  They all start by making a connection to a remote host and then sending messages back and forth on that connection.  These include

• HTTP and HTTPS, the fundamental protocols of the web
• SMTP, POP and IMAP, used for email
• SSL/TLS, for making secure connections to other hosts (HTTPS is essentially HTTP using SSL/TLS)
• SSH, also used for making secure connections to other hosts
• FTP, SFTP and FTPS, used for transferring files (technically, SFTP is built on SSH, which is in turn built on TCP)
• XMPP, one way of sending short messages like texts
• Any number of special purpose protocols developed over the years

Several of these (particularly SSH and HTTP) allow for "tunneling" of TCP, meaning you can establish a TCP connection on top of SSH or TCP, which will in turn be using a different TCP connection.  There are actually legitimate reasons to do this.

To bring things full circle, email protocols and file transfer protocols are essentially packet protocols, just with nicer addresses and bigger packets.  You could, in principle, use them as an underlying protocol for TCP.  This would be hugely inefficient for a number of reasons.  Among others, you'd generally be paying the cost of setting up a connection for each "packet", which is pretty much the worst of both worlds ... but it's certainly possible.  In a more abstract way, an email thread is essentially an ad-hoc connection on top of email (packets), which in turn is delivered via TCP (connection), which in turn (generally) uses IP (packets).