This article discusses the various types of networks, the methods for connnecting networks, how network data is moved from network to network, and the protocols used on today's popular networks. It is excerpted from chapter one of the book The Definitive Guide to Linux Networking Programming, written by Keir Davis et. al. (Apress, 2004; ISBN: 1590593227).
So far we’ve discussed the underlying physical hardware of a network, and in the case of an internet, the protocol used to ensure compatibility between different networks. More than one protocol exists, however. For example, take the acronym “TCP/IP.” You already know what “IP” stands for: Internet Protocol. But what about “TCP”? What about other protocols we use on our networks, such as HTTP or FTP? How do these protocols relate to each other if they’re not all the same?
It’s practically impossible to create a single protocol that can handle every issue that might be encountered on a network. Consider security, packet loss, hardware failure, network congestion, and data corruption. These issues and more need to be addressed in any networked system, but it can’t be done with just a single “super” protocol. The solution, then, is to develop a system in which complementary protocols, each handling a specific task, work together in a standardized fashion. This solution is known as protocol layering.
Imagine the different protocols involved in network communications stacked on top of each other in layers. This is also known as a protocol stack or stack. Each layer in a stack takes responsibility for a particular aspect of sending and receiving information on a network, with each layer in the stack working in concert with the other layers (see Figure 1-7).
Figure 1-7.Protocol layers
As shown in Figure 1-7, sending information to another computer means sending the information “down” through a stack, over the network, and then “up” through the stack on the receiving node. When the receiving node wishes to send a response, the roles are reversed: it becomes a sender and the process is repeated. Each layer on each node is the same. That is, the protocol in layer 3 on the sender is the same protocol in layer 3 on the receiver. Thus, a protocol layer is designed so that layer n at the destination receives essentially the same datagram or packet sent by layer n at the source. We say “essentially” because datagrams have components like time to live fields that will be changed by each node involved in the transfer, even though the core data payload should remain identical from sender to receiver.
Protocol Layer Models
The dominating standard for a protocol layer is from the International Organization for Standardization (ISO) and is known as the Open Systems Interconnection reference model, or simply the OSI model. The OSI model describes seven specific layers: Application, Presentation, Session, Transport, Network, Data Link, and Physical Hardware. A description of each layer is shown in Table 1-5.
Table 1-5. OSI Seven-Layer Reference Model
Application programs such as web browsers and
file transfer programs
Standard routines such as compression
functions used by layer 7
Establishes transmission control between two
nodes, regulating which node can transmit and
how long it can transmit
Provides additional reliability checks to those
performed by lower layers
Defines the basic unit of communication across
a network, including addressing and routing
Controls how data is sent between nodes, such
as defining frames and frame boundaries
Controls the physical aspects of a network
connection, such as voltage
Figure 1-8 shows the result of applying the OSI model to our earlier layer diagram.
Figure 1-8.The OSI model
In practice, though, the typical protocol stack found in most networked environments today is known as a TCP/IP stack and, while perfectly compatible with the OSI model, it is conceptually different. The “TCP” in TCP/IP means Transmission Control Protocol and will be discussed later in this chapter. Just by the name alone, you can see that today’s networks require multiple protocols working together to function.
In a TCP/IP environment, the network transport is relatively simple, while the nodes on the network are relatively complex. TCP/IP requires all hosts to involve themselves in almost every network function, unlike some other networking protocols. TCP/IP hosts are responsible for end-to-end error checking and recovery, and also make routing decisions since they must choose the appropriate gateway when sending packets.
Using our OSI diagram as a basis, a corresponding diagram describing a TCP/IP stack would look like Figure 1-9.
Figure 1-9.The TCP/IP layer model
This diagram shows a TCP/IP stack as having four layers versus the seven layers in an OSI model. There are fewer layers because the TCP/IP model doesn’t need to describe requirements that are needed by older networking protocols like X.25, such as the Session layer. Looking at our TCP/IP stack, we can see that Ethernet is our Network Interface, IP is our Internet layer, and TCP is our Transport layer. The Application layer, then, consists of the applications that use the network, such as a web browser, file transfer client, or other network-enabled applications.
There are two boundaries in our TCP/IP stack that describe the division of information among the application, the operating system, and the network. These boundaries correspond directly to the addressing schemes already discussed. In the Application layer, the application needs to know nothing other than the IP address (and port) of the receiver. Specifics such as datagram fragmentation, checksum calculations, and delivery verification are handled in the operating system by the Transport and Internet layers. Once the packets move from the Internet layer to the Network layer, only physical addresses are used.
At first it would seem like a lookup must be performed to get the physical address of the receiver when starting communications, but this would be incorrect. Remembering the gateway rule, the only physical address that needs to be known by the sender is the physical address of the destination if the destination is on the same network, or the physical address of the gateway if the destination is on a remote network.