The Life and Times of a Network Request


Now that you understand something about the function of each layer, let's look at how this works in the real world. Some of this touches on stuff that we'll cover later in this chapter, but if you're reading this book you're probably conversant enough with networks that you'll be able to follow it. If you have trouble, you may want to read this section once again after finishing the chapter.

Suppose a user on a computer connected to the Internet via your company's Ethernet wants to look at the Yahoo web page. The user interfaces with the application and types in the URL. The web browser needs to know how to make requests of the next layer down, so it translates the host name into an IP address and sends a request for a connection to TCP port 80 on that IP address down to the logical protocol layer.

The logical protocol layer examines the request it has received from the application. Because the application has requested a TCP/IP connection, the logical protocol allocates the appropriate system resources for that sort of connection. The request is broken up into chunks, or packets, to be sent over Internet Protocol.

From here on, the logical protocol doesn't care about the application's actual request; instead, it wants to deliver these packets to the address required. The Internet Protocol subsystem checks its internal tables to see how to reach the requested IP address from this computer. It then bundles up the packets, adds on the IP routing information, and hands the packets to the physical protocol layer.

The physical protocol layer examines the request from the logical protocol layer. The logical protocol doesn't know anything about the packets it is given; it doesn't know that this is a web request or its final destination. All it knows about is getting each packet to its destination. The physical protocol just knows that it needs to add its own information to the packet. This packet-plus-physical-protocol chunk of data is called a frame. Finally, it hands the frame off to the physical layer for broadcast on the local Ethernet.

The physical layer simply transmits a bunch of zeros and ones over the local network. It has no idea what sort of protocol is being spoken, or how these numbers may be echoed through a switch, hub, or repeater, but one of the hosts on this network is presumably the router out of the network.

The physical layer of your router accepts these zeros and ones and hands them up to the physical protocol. The physical protocol will strip off the Ethernet information and hand the resulting packet up to the logical protocol handler within the router. The router's logical protocol layer examines the packet, specifically checking the destination address. Once it knows where the packet is supposed to go, it can consult its internal routing tables and decide how to get the packet to that destination. It then hands the packet down to a physical protocol layer. This might be another Ethernet interface, or (more likely) a PPP interface out over a T1.

Your wire can go through various physical changes as your data travels. For example, your T1 line can be aggregated into a DS3 over fiber, which could then be transformed into an OC192 cross-country link. Thanks to the wonders of layering and abstraction, you don't need to know about any of these. [2]

When your request finally reaches its destination, the computer at the other end of the transaction, it starts a return trip all the way back up the protocol stack. The physical layer gives each frame to the physical protocol, which does some basic sanity checking on the frame to be sure it hasn't been corrupted in transit. Once the physical protocol layer is satisfied that the frame is correct, it removes the physical protocol encapsulation and hands a naked packet up to the logical protocol.

The logical protocol, in turn, performs its own sanity checking. Remember how the logical protocol broke up the request into packets for easy handling? Now it assembles the packets into a stream of data. It then hands this stream of data to the application — in this case, a web server.

The application can process the request and return an answer. This answer descends the protocol stack again and travels across the network, bouncing up and down various protocol stacks along the way as necessary.

And if this doesn't all happen very, very quickly, your user will call the help desk and complain.

This seems like an awful lot of work, but it's an excellent example of why layering is important. Each layer knows only what it absolutely must about the layers above and below it, making it possible to swap out the innards of layers if desired. When a new physical protocol is created, the other layers don't have to care; the logical protocol just hands the request off to the physical protocol layer and lets that layer do its thing. When you have a new type of network card, all you need to do is write a driver that interfaces with the physical protocol; the application and logical protocol layers don't care.

[2]Unless, of course, some of it breaks, in which case your managers will want to know exactly what sort of equipment it is, how long it will take to repair, and why you need it anyway.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net