A Packet's Journey: From Your Keyboard to the Server and Back

What actually happens when you press Enter

You type https://www.google.com into a browser and hit Enter. The page loads in under a second. That feels simple, but behind it sit thousands of operations spread across hardware, software, and half a dozen networking protocols, all of which map directly to the OSI layers covered in Part 1.

This section follows that single request end-to-end. By the time you finish reading, the model stops being an abstract list of seven names and becomes something you can trace through an actual event.

Step 1: The browser builds a request (Layer 7)

The browser is the first thing involved. When you press Enter, it creates an HTTP GET request, basically a formatted message asking Google's server to send back the homepage. At this point the request knows what it wants, but has no idea how to get there. That's everyone else's job.

Step 2: DNS: finding the address (Layer 7)

Computers communicate using IP addresses, not domain names. Before anything else can happen, the browser needs to turn www.google.com into a number. It checks its local cache first; if it finds the answer there, it skips the network request entirely. If not, it asks a DNS resolver, the internet's phone book, which replies with Google's current IP address.

DNS is worth paying attention to from a security standpoint. It's one of the most abused protocols on the internet. DNS spoofing, cache poisoning, and DNS tunnelling all exploit the fact that most organisations trust DNS traffic implicitly and log it poorly. SOC teams that monitor DNS queries catch a surprising amount of malicious activity.

Step 3: Is the destination local or remote? (Layer 3)

Your computer compares Google's IP address to its own network. They're clearly on different networks, your machine is probably something like 192.168.1.x and Google's server is nowhere near that range. So your computer concludes: this packet needs to leave the local network. It will go to the default gateway, your router.

Step 4: ARP: finding the router's MAC address (Layer 2)

Your computer knows the router's IP address, but Ethernet frames are addressed using MAC addresses, not IPs. So it broadcasts an ARP request to the local network: "Who has 192.168.1.1? Tell me your MAC address." The router replies, your computer stores the mapping in its ARP cache, and now it knows exactly which physical device should receive the frame.

This is the mechanism that ARP spoofing exploits. An attacker on the same local network can send a forged ARP reply claiming that their MAC address belongs to the router's IP. Your computer updates its cache and starts sending all outbound traffic through the attacker's machine instead.

Step 5: TCP handshake: establishing a reliable connection (Layer 4)

Before any web content is exchanged, the browser establishes a TCP connection with Google's server. This takes three packets, a process called the three-way handshake.

Only after this exchange does application data start flowing. The reason TCP goes through this ceremony is that the internet is unreliable, packets can be delayed, dropped, or arrive out of order. TCP tracks sequence numbers, sends acknowledgements, and retransmits anything that gets lost. It's the difference between reliable delivery and hoping for the best.

Step 6: TLS handshake: encrypting the connection (Layer 6)

Because the URL begins with https://, the browser doesn't send the HTTP request yet. First it negotiates an encrypted channel using TLS. The two sides agree on the TLS version and cipher suites, the server presents its digital certificate (which the browser verifies against a trusted Certificate Authority), and they exchange enough information to derive the same symmetric encryption keys independently.

Modern HTTPS uses both types of encryption, each for what it's good at: asymmetric cryptography during the handshake to securely agree on keys, then fast symmetric encryption for the actual data transfer. Without TLS, anyone with access to the same network, or anywhere along the path, could read your traffic in plain text.

Step 7: Encapsulation: wrapping the data for travel

The application data is now ready to send. As it moves down the networking stack, each layer wraps it in additional information, a process called encapsulation. The receiving side reverses this, unwrapping one layer at a time in a process called decapsulation.

A key thing to notice: each layer ignores what the others added. The router only reads the IP header. The switch only reads the MAC address. Neither one cares about the HTTP request buried inside. This separation of responsibilities is what makes the OSI Model work, and what makes encapsulation one of the most important concepts in all of networking.

The data unit also changes name at each layer, which trips up a lot of people when reading documentation. It's the same information, just described from the perspective of whichever layer is looking at it.

Step 8: Bits travel the physical medium (Layer 1)

The completed frame reaches your network interface card. The NIC converts it into physical signals, electrical pulses on an Ethernet cable, light pulses through fibre, or radio waves over Wi-Fi. From this point, your data exists as a stream of ones and zeroes moving through the physical world.

Step 9: Routers forward the packet across the internet (Layer 3)

Your router receives the frame, strips the Layer 2 information, reads the destination IP address, and forwards the packet toward Google. This process repeats across every router along the path, through your ISP, regional providers, backbone networks, and eventually into Google's infrastructure. At each hop a new frame is built for the next link, but the IP packet inside stays intact (except the TTL field, which decrements by one at each hop to prevent infinite loops).

Step 10: Google receives and processes the request

Google's server runs the whole process in reverse. The physical layer receives the bits, the data link layer validates the frame, the network layer confirms the destination IP, the transport layer verifies the TCP segment, the presentation layer decrypts the TLS data, and the application layer finally reads the HTTP request. The server prepares an HTTP response and sends it back through the same process, encrypted, wrapped in headers, broken into packets, routed across the internet, and reassembled at your machine.

From your perspective: the page loaded. Behind that, dozens of protocols and hardware devices worked together in under a second.

Key networking vocabulary

These terms come up constantly in networking and security conversations. It's worth having them precise.

What a SOC analyst sees in this same journey

A security analyst watching this request doesn't see a webpage loading, they see a trail of evidence across every layer. Each stage generates different telemetry, and each stage can reveal different kinds of malicious activity.

Understanding this end-to-end journey is what allows an analyst to quickly answer "where did this actually happen?" when an alert fires, which, in turn, determines which team needs to respond and which tools are actually useful.