How That Cat Video Gets to Your Phone

Explaining How Data Moves Around the Internet in Layman’s Terms

Imagine, for a moment, that you are a spy. And not only that: you are a spy who just hit the jackpot. You just overheard the conversation of the century between two of your targets of interest. And you’ve rushed back to your secret spy office to dispatch a memo right away to your superiors. How do you get your message to them?

We’re going to walk through an imaginary spy message process, and it turns out it’s a pretty good approximation of how data is moved across the internet, too. Our internet counterpart to the spy memo, is, of course, a cat video. So how does the spy get their message to headquarters? And how does the cat video get to your phone? Here’s how:

On the Sender’s Side: Application Layer

So we’ve gotten back to our office with this incredible spy scoop of the century. The first thing we’re going to do is write out the content of our message. What are we reporting? What did we actually overhear? Get it down on paper as soon as possible. Of course, since you’re a spy, the original draft is probably on burn paper, but still, you need this out of your head and on some medium you can work with.

On the web, this message — the actual content we want to send — is the “data” and the data comes from the source “application.” Whatever program it is that houses that cat video we want to see, that’s the application. And it has a video it wants to send to us, that’s the data. So the first step in this whole process is gathering the actual content that’s going to be sent. In technical speak, we call this the “Application Layer.”

Sender’s Side: Presentation Layer

Now, we wouldn’t be a very good spy if we just sent this scoop of the century message in plain English for all the world to see. So of course, once we’ve figured out what we’re going to say, the very next thing we’re going to do is put it into a secret code that only we and our handler know how to decipher. For the purposes of this example, we’re going to ignore the complexities of how such a code might work (that’ll be a future article) and we’re just going to leave this at “we put the message into our secret code.” Step two done.

Similarly, the application that’s sending our cat video probably isn’t going to just dump the data onto the internet in “plaintext” for everyone. There might be various reasons why it wants to “encode” its content: maybe they are good netizens (net citizens) and believe strongly in security. Maybe they know that Google downgrades sites that don’t use HTTPS, and they want to maintain their cat video search ranking. Maybe they specialize in NSFW (not safe for work) cat videos and know their customers don’t want to be snooped on. Whatever the reason, they probably use some form of “encryption,” and the next step in the process is encoding the data into that encrypted form.

Note that there might be other kinds of “encoding” that needs to happen here beyond encryption (for a variety of technical reasons that you probably don’t care about), so this isn’t the only thing that might be happening at this step. But collectively, all those various encoding processes are called the “presentation layer.”

Sender’s Side: Session Layer

Ok, our incredibly important spy message is written and put into our super secret code. Now, we need to prep it for sending. The first step in that process is deciding how to categorize it in the pantheon of spy conversations we have with headquarters (because, after all, we are very productive spy with lots of open conversations/threads/topics of inquiry running at once). Do we want to put this into an existing conversation as a “reply” message? Or do we want to start a whole new conversation with a unique subject line to catch everyone at HQ’s attention: HUUUGE NEW THING, PLEASE READ?

Similarly, our cat video application that’s now packed up and encoded a video it wants to send us needs to decide if this is part of an existing “session” (ie, you’re already browsing the site and just clicked a new link) or a new one. On the web, it’s almost always the case that an application that is sending data is sending it as part of an already established session/conversation. If you stop to think about this, you can probably see why: you don’t usually just “get” data from the web sent to you, it’s normally something you “request.” You open a web page or app on your phone, you click a link in an email or text message, you type something into the search bar or pull down to refresh in a social media feed. It’s in response to these sorts of actions that data gets sent. In all of those cases, you have (behind the scenes) already established a connection to the app/site, setting up a session that the data will be sent through.

An aside: it’s because of this that most firewalls (especially the ones built-into personal computers/home WiFi routers, etc) default to blocking all “incoming” connections. This is because 99.9% of the time, you as the user are the one initiating sessions through an “outgoing” request to get something from an app or a website. Once you’ve established those connections, the data will flow through the opened session. So if data shows up addressed to you that isn’t part of such an already existing session (in other words, data you’ve never requested), your firewall can reasonably assume that it’s at the very least suspicious and should be blocked just in case.

Sender’s Side: Transport Layer

We’ve written our amazing spy scoop, we’ve put it into our secret code, and we’ve determined how to categorize/flag it for HQ. Now we have to decide how to send it. Do we put a letter in the mail (and if we do, will it ever arrive?)? Do we take out a coded advertisement in the classifieds of the local paper? Do we initiate a dead drop on a bridge? Send a message over a secret satellite communication device? So many options, how’s a spy to choose?

Our cat video has to similarly decide how to send the data. On the web, these “methods” of sending the data are called “protocols.” There’s a few different options, and they matter because they have different features. For example, some “guarantee” delivery (by sending you a confirmation message, for example) while others make a “best attempt”: just sending the data and hoping it arrives.

Now, in reality on the web, this isn’t much of a choice. The application sending the data has almost certainly been programmed to always use a particular protocol, so when you get to this step there’s no decision to be made, the protocol just needs to be invoked. Sometimes, however, different steps in an application’s process may use different protocols. For example, when you browse to a website your web browser may use one protocol to look up the location of the server and a different one to actually request the data from the server.

Sender’s Side: Network and Link Layers

Message written and put into secret code, “conversation”/“thread” chosen, and we’ve decided how we’re transmitting it. Now, the next thing we have to do is actually “address” our spy message. There are probably two levels to this address, which we’ll call “external” and “internal.” To visualize this, imagine you’re dispatching your super secret message to your handler, who works out of an office in another city. Of course, the office is a “cover” where they manage a fake travel agency or something. But the address actually exists and it’s convenient enough to send messages to. Addressing messages to this office, you need to both put the street address for the building and the suite number. In this case, the street address is the “external” part and the suite number is the “internal” part. You may have done this in your not-imaginary-spy-life whenever you mail something to a business with multiple internal departments (and needed to put a suite number or “ATTENTION: Billing” on it) or if you’ve sent mail to someone who lives in a large apartment building and needed to specify not just the building address but their apartment number.

Similarly, on the web, there’s two levels to addressing messages. This comes about because our devices don’t directly connect to the internet. Instead, they connect to your WiFi Router (or Ethernet Router if you’re hard-wired into the network), which then connects to the internet (with perhaps some additional in-between steps like a firewall or modem, especially if you’re in a business/corporate environment). So the router/modem (whichever device is actually directly connected to the internet) is the “external” or “IP” address, connected to what we call the “network layer.” Then, all the devices in your home/office have their own “internal” address, which operates on what we call the “link layer.” For our cat video app to send us the data it’s packaged up for us, it has to address it to both, basically saying “send the data to this device on this network” in the same way you might say “deliver to this apartment number inside this building.”

The “Physical” Layer

Ok, so now we’ve written our super-important message about the spy scoop of the century, we’ve put it into our secret code, classified it into the right conversation, chosen the right method to transmit it, and addressed it. Now we’re ready to actually send the message! We hand it off to the courier/postal worker or feed it into our special transmitter and away it goes.

Similarly, now that our cat video app has packed up and encoded the video for us, fed it into the right session, invoked the protocol for delivering it, and addressed it to our external and internal address, it sends it on it’s way. All that data starts moving through the many wires and cables that make up the internet, heading it our direction!

The Receiver’s Side: Climbing Back Up the Ladder

Our spy message has been transmitted! Now what?

Well, on the other side, something of a reversal of what we’ve described happens. The message arrives at the building we addressed it to (network layer) and gets sorted with other incoming messages to be delivered to the right office suite (link layer). If we requested confirmation of delivery, someone signs for it and we get a confirmation message (transport layer). Then someone in the office files the message into the appropriate “file” for review by the appropriate eyes — it’s highly sensitive spy material, right? (Session layer) Next, the intended recipient opens and decodes the message using their own special spy skills (presentation layer) and finally reads our spy scoop of the century (application layer)!

Now how about that cat video? Well, after crossing all those cables and wires, it arrives at our router (network layer), which then delivers it to our device (link layer). Upon receiving the message, our device says “got it” and (if requested) sends confirmation of such back through across the web to the sender (transport layer). Then our device decides which app/web page this data corresponds to (session layer). The app is probably the one that decodes the data into something we can watch (presentation layer) and then it shows us the video (application layer). Cat videos for the win!

Going Deeper:

Now, of course, everything we’ve written is somewhat simplified and there are lots of wrinkles that can happen along the way. The point of this article isn’t to make you an expert in all of that, it’s to give a broad overview of how data moves around on the web. If you’d like to dive deeper and really get into the weeds, here are some places you might look:

• Introduction to Computer Networking: Online Course (free on YouTube) from Stanford
• Cybrary Networking Courses: Catalog of courses focused on more practical/hands-on implementations of various networking technologies
• Free Books: A large collection of free books on various computer/tech related topics (link will take you to the “networking section”) for those who prefer to read and looking for more in-depth/technical information