The Life and Times of a Network Request
So how do all these layers fit together in the real world? Let’s have a look at a hypothetical network request, and walk through how data traverses the layers and the network.
Note
Some of this discussion touches on topics covered later this chapter, so you might want to reread this section after finishing the chapter. Purists will notice that I skip a lot of parts of the process, but I’m trying to relay the basics of how TCP/IP works in practice, not model every painful detail of a real network transaction.
Suppose a user connected to your network wants to look at a very important work-related website, such as Scott Meyer’s Basic Instructions (http://www.basicinstructions.net/). The user opens his browser, enters the URL, and presses ENTER. The browser application transforms the user’s request into the proper format and asks the transport layer for a TCP connection to a particular IP address on port 80.
The transport layer inside your computer examines the browser’s request and allocates the appropriate resources for it. The request is broken up into digestible chunks, called segments, and handed down to the network layer.
The network layer doesn’t care about the contents of the request; it’s only concern is where that data is going. The network layer takes the TCP data and attaches the proper addressing information to it. The resulting chunk of data is called a packet. The network layer checks the packet’s destination, chooses the interface closest to the gateway to that destination, and drops packets down into the datalink layer.
The datalink layer doesn’t care about the contents of the packet, and it certainly doesn’t care about IP addresses or routing. It has been given a lump of zeros and ones, and its job is to transmit those zeros and ones to another network node. The datalink layer adds the appropriate header and/or footer information to the packet, creating a frame appropriate for the physical layer. The frame’s header and footer contain the addressing information for the physical layer. On most networks, the datalink layer prepares frames for the local Ethernet. Then the datalink layer hands off the frame to the physical layer for transmission.
The physical layer has no intelligence at all (think carrier pigeons). The datalink layer hands the physical layer a frame, and the physical layer transmits that frame to another physical device. For a web browsing client, this is usually the default router for the local Ethernet. The physical layer doesn’t care about the upper-level protocols. Its only job is to make sure the frame gets to the destination without errors.
When the client computer’s router receives the frame, it sends it up to the datalink layer. The datalink layer strips out the frame information and hands the resulting packet up to the network layer. The router’s network layer examines the packet, looks at its routing table, and decides which interface to send it out on. This might be another Ethernet interface, a T1, a DS3, an OC3, or whatever the router uses for upstream connectivity. Once the router chooses an interface, it hands the packet to the datalink layer for that interface.
The local router’s upstream connection probably goes through a whole series of routers. Each router decides where to send the request based on its routing table. The request probably traverses a variety of datalink layers as it travels. Thanks to layering and abstraction, neither you nor your computer needs to know anything about any of them.
When the request reaches its destination, the computer at the other end of the transaction accepts the frame and sends it all the way back up the protocol stack. The frame is stripped down to packets, which are stripped down to segments, which are reassembled into a data stream. The data stream is then handed to the application (in this case, a web server). The application processes the request and returns an answer, which goes back down through the protocol stack and travels across the network, bouncing up and down through various datalink layers on the way as necessary.
This example shows why the layer model is important: Each layer knows only what it absolutely must about the layers above and below it, making it possible to swap out layers if necessary. When a new datalink protocol is created, the other layers don’t need to change. The network layer just hands a packet to the datalink layer and lets the datalink do its thing. When you install a new network card, you need only a driver that interfaces with the datalink layer and the physical layer; you don’t need to change anything higher in the network stack.