The Application Layer

Finally, we have the application layer–what the user deals with. The application might be a Web browser, a word processor, or a shell client. The application only has to worry about the user interface and the logical protocol. (You might consider the end user to be another layer, but problems with this layer are beyond the scope of this book.[1])

[1]No matter how desperate or annoyed you are, fsck−ing or BIOS−flashing the user layer is not a good idea. You can only reconfigure this layer through a process called "education." Don't expect too much from this.

The Network in Practice

Now that you understand something of each layer, let's look at some of them in detail. Let's consider how these network layers work for an office desktop connected via Ethernet.

Say you type http://www.absolutebsd.com/ into your Web browser. The Web browser needs to know how to make requests of the next layer down, so it translates the hostname into an IP address (a series of numbers like 192.168.1.84).

Note By default, a server delivers services on network ports, or logical identifiers. We'll look more at ports in a little bit; for now, just understand that each service a computer offers runs on a unique port. Web servers usually run on TCP port 80. The browser sends a request for a connection to that IP and that port to the next layer down.

The logical protocol layer then examines the request it has received from the application. Since 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 of the correct size to be sent over Internet Protocol, called packets.

From here on, the logical protocol doesn't care about the application's actual request; instead, it wants to deliver these packets to the specified address. The IP layer 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 layer routing information, and hands the packets to the physical protocol layer.

The physical protocol layer examines the request from the logical protocol layer (it doesn't know anything about the Web browser; all it cares about is getting each packet to its destination). The physical protocol layer checks the physical protocol address (the MAC address) for the packet's destination, and adds Ethernet information to the packet. This packet−plus−physical−protocol chunk of data is called a segment. Finally, the physical protocol hands the whole mess down to the physical layer, which converts it to zeros and ones, and feeds it to the wire. Switches and routers echo those zeros and ones all the way to the final destination.

Your wire can go through various physical changes as your data is transferred. For example, your Ethernet will probably become a T1 line (your office router will handle that conversion for you). Then, that T1 will join a piece of optical fiber that runs across the country (the phone company will handle that transition).

When the segment reaches its destination, the computer at the other end of the transaction, it starts a return trip back up the protocol stack.

The physical layer gives each segment to the physical protocol, which does some basic sanity−checking on the segment to make sure that it hasn't been corrupted in transit. Once the

100

physical layer is satisfied that the segment is correct, it removes the Ethernet information to create a packet, and hands it 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 transmission? Now it assembles the packets of the answer into a stream of information, and hands that stream off to the application. The application then has its answer and can display the Web page.

Of course, this is all expected to happen very, very quickly.

This seems like an awful lot of work, but it's an excellent example of interface abstraction. This means that each layer only knows what it must about the layers above and below, and makes it possible to swap out entire 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 new physical protocol layer, and lets it deal with things internally. When you have a new type of network card, all you need to do is write a driver for the physical protocol; the application and logical protocol layers don't care.

Mbufs

BSD optimizes networking by using mbufs. An mbuf is a discrete chunk of memory set aside for networking that lives within the kernel. A packet starts off life as an mbuf. Rather than copying the contents of a packet to the next layer down, each of the OS layers hand the entire mbuf down. Copying a piece of data consumes more time and resources than handing off the data in its current location.

What's more, mbufs are carefully designed not to require changes. When the logical protocol creates an mbuf, it leaves space at the front and back for physical protocol headers, which further minimizes the amount of copying. A packet becomes a segment within a single mbuf.

Those of you who are C programmers should recognize a pointer here. The pointer to the mbuf is handed around, while the mbuf itself remains constant. The rest of us just need to have a basic idea of what an mbuf is. You'll keep tripping across mentions of mbufs throughout any BSD network stack, so it's important to at least have a vague awareness of what they are.

What Is a Bit?

As a network administrator, you're going to start seeing terms like 32 bit and 48 bit more and more frequently. You should understand what these terms mean so that you can recognize an illegitimate number.

You probably already know that a computer treats all data as zeros and ones, and that a single one or a zero is a bit. When a protocol specifies a number of bits, it's talking about the number as seen by the computer–this is binary math. (You were probably introduced to binary math, or base 2, back in elementary school, and promptly forgot about it. It's time to dust that knowledge off. Binary numbers are just a different way of describing the numbers we work with every day.)

In decimal (meaning base 10) math, the math we typically use every day, digits run from 0 to 9. When you want to go above the highest digit you have, you add a digit on the left and set your current digit to 0. (This is the whole "carry the 1" thing you learned many years ago, and now probably do without conscious thought.) In binary math, digits run from 0 to 1. When you want to go above the highest digit you have, you add a digit on the left and set your current digit to 0. It's the same thing, just with fewer digits.

101