REAL LIFE example!! (TCP/IP and OSI layers) // FREE CCNA // EP 4

A packet’s journey from a web browser to a web server becomes clear when each protocol layer adds its own “envelope,” then strips those envelopes back off at the destination. Using a Packet Tracer simulation, the walkthrough follows “Johnny” requesting a secure website (HTTPS) to order coffee, showing how application data turns into a TCP segment, then into an IP packet, then into a MAC-addressed Ethernet frame—crossing switches and routers until the server finally hands the request to the application.

The process starts at the application layer (OSI layer 7), where the browser generates an HTTP request wrapped for HTTPS. The key detail is that the browser’s job is to produce the web request; the networking stack’s job is to move it reliably across the network. Next comes the transport layer (OSI layer 4), where the data is prepared for delivery using TCP or UDP. Here, the destination port is 443, the standard port for HTTPS. The transport layer adds a TCP header, turning the application data into a “segment.” That encapsulation step matters because it creates the metadata needed for delivery and reassembly.

At the network layer (OSI layer 3), the segment is encapsulated again with IP addressing. The header includes a source IP (Johnny’s) and a destination IP (the server’s). Once the router receives this layer-3 information, it can consult its routing table to decide where the packet should go next. But routers can’t rely on IP alone when forwarding across local links; they must translate to link-layer addressing.

That translation happens at the data link layer (OSI layer 2), where MAC addresses and switching come into play. The frame includes a source MAC (the sender) and a destination MAC (the next hop). When Johnny’s frame reaches a switch, the switch reads only the MAC destination, checks its CAM table, and forwards the frame out the correct port toward the router. The router then de-encapsulates to inspect the IP header, looks up the destination network, and re-encapsulates the packet into a new Ethernet frame with updated MAC addresses. The next switch repeats the same MAC-based forwarding logic until the frame reaches the server.

When the server receives the Ethernet frame, it reverses the process: it verifies the frame is addressed to its MAC, checks the IP header, confirms the transport protocol and port (TCP/443), and finally passes the payload up to the application layer where HTTPS/browser processing can occur. The cycle then repeats in the opposite direction as the server responds.

The session ends with two CCNA/CCNP-style quiz questions: one asks which functions belong to the OSI application layer (including items that are sometimes associated with presentation/session in the OSI model), and the other asks which protocol relies on a three-way handshake for connection-oriented reliable transfer—TCP, not UDP. The takeaway is that end-to-end web access is really a chain of encapsulation and de-encapsulation across layers, with TCP/443 and IP addressing doing the heavy lifting for reliability and routing.