📦 A Packet's Journey

Tip: use the ← and → arrow keys to step through.

1. The browser writes an HTTP request

   Your PC · Layer 7, Application

   Everything starts as plain text. The browser builds an HTTP request asking the server for one file. The Host header matters because one server often hosts many websites, and this is how it knows which one you want.

   GET /index.html HTTP/1.1 Host: osiexplain.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) … Accept: text/html Accept-Encoding: gzip, br Connection: keep-alive

   At this point there are no addresses or port numbers of any kind. The application layer just hands a block of data down and trusts the layers below to deliver it.

2. TLS encrypts the request

   Your PC · Layer 6, Presentation

   Because the link was https://, the request is handed to TLS. Using the keys agreed during the handshake, TLS encrypts the request with AES-GCM and adds an authentication tag, so any tampering on the way will be detected. The result is wrapped in a small TLS record header.

   Content type	23 (application data)
   Version	0x0303. TLS 1.3 still writes the TLS 1.2 number here so that old middleboxes keep working.
   Length	Size of the encrypted payload, including the tag

   From here on, nothing between you and the server can read the HTTP request. Your ISP and every router on the path see only encrypted bytes.

3. The session layer adds… nothing

   Your PC · Layer 5, Session

   This is the honest answer that textbooks often skip. The internet runs on TCP/IP, and TCP/IP has no separate session header. The OSI model's Layer 5 jobs are still being done, but by other parts of the stack:

   • The TLS session ties this request to the keys from the earlier handshake, and can be resumed later without a full new handshake.
   • HTTP keep-alive reuses the same TCP connection for the page's images and scripts.

   So the data passes straight through. See OSI vs TCP/IP for why layers 5–7 collapse into one in practice.

4. TCP turns it into a segment

   Your PC · Layer 4, Transport

   TCP adds its header, and the unit of data is now called a segment. Ports identify which program on each machine the data belongs to. Sequence numbers let the server put bytes back in order and spot anything missing.

   Source port	51514, a random ephemeral port picked by your PC
   Destination port	443, HTTPS
   Sequence number	Position of the first byte of this segment in the stream
   Acknowledgement	Next byte your PC expects from the server
   Flags	PSH, ACK
   Window	How much more data your PC can buffer (flow control)

5. IP turns it into a packet

   Your PC · Layer 3, Network

   The IP header carries the two addresses that stay the same for the whole trip, end to end (NAT is the exception, as step 8 shows). The unit is now a packet.

   Source IP	192.168.1.20 (your PC)
   Destination IP	203.0.113.10 (the web server)
   TTL	64. Every router subtracts one, so a looping packet eventually dies.
   Protocol	6, meaning "the payload is TCP"
   Flags	Don't Fragment set. Path MTU discovery handles packet size instead.

   Your PC now makes the key routing decision. Is 203.0.113.10 on my own subnet (192.168.1.0/24)? No. So the packet must go to the default gateway, the home router at 192.168.1.1.

6. Ethernet turns it into a frame

   Your PC · Layer 2, Data Link

   A frame only travels across one link. So the destination MAC is not the web server's. It is the router's, the next hop. Your PC looked that MAC up with ARP, or found it already in its ARP cache.

   Destination MAC	00:1a:2b:3c:4d:5e (home router's LAN port)
   Source MAC	a4:5e:60:12:34:56 (your PC's network card)
   EtherType	0x0800, meaning "the payload is IPv4"
   FCS (trailer)	A 4-byte CRC-32 checksum over the whole frame, added at the end

   This is the only layer that adds a trailer as well as a header. The packet is now sandwiched between them.

7. The network card sends bits

   Your PC · Layer 1, Physical

   The network card puts a preamble in front of the frame: 7 bytes of 10101010, then a start frame delimiter, 10101011. The alternating pattern lets the receiver lock on to the clock. Then every bit of the frame goes out as electrical signals. On gigabit Ethernet (1000BASE-T) that means PAM-5 voltage levels across all four twisted pairs at once.

   Layer 1 has no idea what any of these bits mean. It just moves them.

   Encapsulation is complete: Data → Segment → Packet → Frame → Bits. On Wi-Fi the steps are the same, but Layer 2 uses an 802.11 frame and Layer 1 is radio.

8. Your home router: unwrap, decide, rewrap

   Home router · Layers 1–3

   The router receives the bits (L1). It checks the FCS and sees the frame is addressed to its own MAC (L2), then throws the frame away to get at the packet. At Layer 3 it:

   1. Looks up 203.0.113.10 in its routing table. The only match is the default route, out of the WAN port towards your ISP.
   2. Decrements the TTL from 64 to 63, then recalculates the IP header checksum.
   3. Applies NAT. The private source 192.168.1.20:51514 becomes the router's public address, for example 198.51.100.7:40112. The router remembers this mapping so the reply can find its way back, and fixes up the TCP checksum, which also covers the IP addresses.

   Then it builds a brand-new frame for the next link. The source MAC is now the router's WAN port, the destination MAC is the ISP's router, and the FCS is new.

   A router never looks above Layer 3. It cannot see the TLS record or the HTTP request, and does not need to.

9. Across the internet, hop by hop

   ISP and backbone routers · Layers 1–3

   The same thing repeats at every router on the path, typically 10–20 of them. Each one strips the incoming frame, decrements the TTL, looks up the destination IP, and wraps the packet in a new frame for the next link. Some of those links are not Ethernet at all. A long-haul fibre run may use a different Layer 2 and Layer 1 entirely, and the packet does not care.

   Field	Changes at every hop?
   Source / destination MAC	Yes. A new frame is built for every link.
   TTL	Yes. Down by one each time; after 12 routers it reaches the server at 52.
   Source / destination IP	No. Only NAT, at the edge, changed them.
   TCP ports and everything inside	No.

   This is exactly what traceroute exploits. It sends packets with TTL 1, 2, 3… and records which router sends back the "time exceeded" error each time.

10. The server's network card accepts the frame

    Web server · Layers 1–2

    Now everything runs in reverse. This is de-encapsulation. The server's network card turns the signal back into bits (L1). Then at L2 it:

    • Recalculates the CRC-32 and compares it with the FCS. If they differ, the frame was damaged on the last link and is silently dropped. TCP will notice the gap and resend.
    • Checks that the destination MAC is its own. It is, because the last router addressed the frame to it.
    • Reads the EtherType 0x0800, strips the header and trailer, and hands the packet to IPv4.

11. IP confirms the packet is for this server

    Web server · Layer 3, Network

    The destination IP 203.0.113.10 matches one of the server's own addresses, and the header checksum is valid. The packet arrives with TTL 52. The Protocol field says 6, so the IP header comes off and the segment goes to TCP.

    Notice the source IP the server sees: 198.51.100.7, your router's public address, not your PC's private one. That is NAT at work. The server replies to that address.

12. TCP delivers the bytes to the right program

    Web server · Layer 4, Transport

    Destination port 443 belongs to the web server process (nginx, say). TCP finds the existing connection from the source IP and port, checks that the sequence number is the next one it expected, and places the bytes in the receive buffer in order.

    TCP then sends an ACK back, so your PC knows it does not need to resend. That ACK is a whole tiny packet that makes the journey in the opposite direction.

13. TLS decrypts and verifies

    Web server · Layers 5–6, Session and Presentation

    The connection belongs to an established TLS session, so the server already holds the matching keys. It decrypts the record and checks the authentication tag. If even one bit had been altered anywhere on the path, the check would fail and the connection would be torn down rather than trusted.

    What comes out is the exact HTTP text your browser wrote in step 1.

14. The web server reads the request and replies

    Web server · Layer 7, Application

    The web server parses GET /index.html, uses the Host header to pick the right site, and builds a response:

    HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Encoding: br Content-Length: 6120 <!DOCTYPE html> …

    That response now makes the same journey in reverse. It is encrypted, segmented, packeted and framed on the server, rebuilt hop by hop across the internet, un-NATed by your home router back to 192.168.1.20:51514, and unwrapped layer by layer on your PC. All of that usually takes tens of milliseconds.