How a Network Packet Leaves Your Device

Have you ever wondered what actually goes on behind the scenes when we type google.com and click search?

Let's remove the whole internet for a moment.

Forget about all the routers, cables, data centers and servers. Let's just focus on your laptop.

How does a request actually leave your laptop and enter the universe of the internet?

In this article, we're going to dig into what actually happens inside your laptop before the network packet leaves your device.

And don't worry, we're not going to treat a "server" like it's some magical computer sitting in a secret room somewhere. A server can literally be another computer running some software and waiting for requests. The same goes for a lot of the other things we'll encounter — they're mostly just different pieces of software and hardware doing specific jobs.

So let's start with something familiar.

---

Let's open YouTube

Let's take youtube.com as our example — one of the most used sites on the internet.

When we type youtube.com, the browser actually interprets this request like:

https://www.youtube.com/

or, conceptually:

www.youtube.com:443

The first one might be familiar to a lot of you people, but what the hell is the second one?

The 443 is the port.

By default, when we use HTTPS, port 443 is used. There is one more — the less secure guy — HTTP, which traditionally runs on port 80.

But wait, what exactly is a port?

If you are wondering what ports are and how they work, well, that would make another article. But for simplicity, there is something called an IP address, which is like the address of a device, and ports are like small rooms inside that device.

A device can be running many different network applications at the same time. One application might be waiting for connections on one port, while another application is using a different port.

So when we say:

93.184.216.34:443

we're essentially saying:

“I want to communicate with port 443 on the device having IP address 93.184.216.34.”

The IP address helps us identify which device we're trying to reach, while the port helps identify which network service on that device we're trying to talk to.

And just like we have domain names because remembering IP addresses for every website would be a nightmare, we also have names for commonly used network protocols.

HTTP and HTTPS are two of them, but there are many others.

DNS is used for translating domain names into IP addresses. SMTP is used for sending email. FTP is used for transferring files. There are many more protocols, each designed for different kinds of communication.

If you're wondering how all these protocols actually work, well, that can make several more articles.

For now, let's stay with our YouTube example.

---

What does the browser actually want?

Now that we have a destination and a protocol, what is the browser actually trying to communicate?

At the HTTP level, a simplified request could look something like this:

GET / HTTP/1.1
Host: www.youtube.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Now, what the hell are we looking at here?

This is simply the browser describing what it wants from the server.

GET is the HTTP method. It basically tells the server that we want to retrieve something.

The / represents the root resource of the website.

HTTP/1.1 tells the server which version of HTTP is being used.

And then we have:

Host: www.youtube.com

which tells the server which website we're trying to access.

There are also several other headers here. They can carry information about things like the browser, accepted content types, compression, language, cookies, caching and so on.

If this looks like a lot of information for something as simple as opening a website, don't worry about it.

At this level, the important thing is simply that the browser has some data it wants to send.

And eventually, that data is going to become part of a network packet.

Not a magical internet object.

Just data, with some additional information attached to it so that the different parts of the network know what to do with it.

But there is a problem.

The browser can't simply take this HTTP request and throw it at the Wi-Fi adapter.

There are several things that need to happen first.

And that's where our laptop's operating system and networking stack enter the picture.

---

Before the packet leaves

So, the next time you type a URL into your browser, remember that the request doesn't magically jump from the browser into the internet.

It starts as something very simple: data that an application wants to send somewhere.

From there, different parts of your computer work together to figure out where that data needs to go, how it should be packaged, and how it can eventually be handed over to the network.

And all of this happens before the packet ever leaves your device.

What looks like a simple action — typing youtube.com and hitting Enter — is actually your browser, operating system, networking stack and network hardware quietly working together in a fraction of a second.

The internet may look like this huge, complicated thing from the outside. But when you zoom in, it's mostly a collection of smaller, understandable pieces doing their jobs and passing data between each other.

And that, to me, is what makes networking interesting.