Network Protocols

I've mentioned that most Internet trafficHTTP, email, FTP, and so onuses TCP/IP as its transport protocol. TCP/IP itself refers to the combination of the most common "network" and "transport" protocols in use on the Internet. IP, the Internet Protocol, is the backbone of the vast majority of Internet trafficthe "network" layer of the TCP/IP stack. TCP, however, isn't the only commonly used "transport" layer protocol. There's also UDP, the User Datagram Protocol, which differs from TCP in a few key ways.

IP also isn't the only means of carrying traffic at the "network" level; it has a number of contemporaries, too, but they're mostly useful only on LANs. These include AppleTalk, IPX, NetBIOS, and so on.

Then there's ICMP, which exists partly on the "network" layer and partly on the "transport" layer; it's the mechanism by which the ping and TRaceroute utilities work. We'll talk about each of these protocols in some detail next.

The Transmission Control Protocol (TCP)

TCP is a two-way transmission protocol that's designed to be reliablenot a subjective term, it describes a specific characteristic of its architecture. Unlike UDP, TCP has lots of built-in features to make sure the traffic it carries arrives properly at its destination. It also has features to divide large packets into appropriately sized fragments so as to transmit more efficiently.

TCP uses retransmission to provide reliability. Here's how a simplified version of retransmission works: When a TCP packet is sent over the network, a timeout period (three seconds at the connection's initialization) is set by the sender, which then waits for an acknowledgment (ACK) packet to come back from the other side. When it receives the ACK, the sender then proceeds to send the next packet. If the sender doesn't get the ACK within the specified timeout, it knows that either its own packet didn't make it or the acknowledgment packet got lost on the way back. The sender resends the packet and again waits for the ACK. This is a retransmission. The system keeps retransmitting until it reaches a set number of failures (usually five) and aborts the connection.

A TCP connection involves an active setup procedure in which both hosts at the endpoints of the connection exchange startup tokens; disconnection at the end of a flow involves a similar exchange. This means that, unlike UDP flows, TCP flows can be accurately tracked by the system and their state can be viewed using tools such as netstat. TCP has a number of other interesting features, such as bidirectional payloads (reply data carried in the ACK packets), a checksum that ensures the integrity of the data in the packet, automatic packet fragmenting and reconstruction, and out-of-order resequencing at the receiver level. These are all things that UDP doesn't door at least isn't required to do.

TCP is used in protocols in which data integrity is important and a connection can be ensured, such as web surfing, email, FTP, and the vast majority of other network applications.

The User Datagram Protocol (UDP)

UDP is a similar "transport" protocol to TCP, existing at the same layer in the OSI stack model; however, it differs from TCP in a number of key ways. The big thing to remember about UDP is that it's unreliable. There is no acknowledgment mechanism, no retransmission mechanism, and no true concept of a "connection." UDP packets can be broadcast to anyone on the network, if so chosen, or a selected set of recipients, regardless of whether they're expecting to hear anything. It's up to the recipients to catch the packets and do something with them.

UDP packets can get lost along the way from the sender to the receiver, and neither can have any way of knowing that it missed any packets. There are no sequence numbers in UDP as there are in TCP. A sender simply spews out the traffic, and the specified recipients can receive it or notit's up to them and the network. Any reliability in a UDP flow must be added by the application using it; an example of this is the Network File System (NFS) protocol, which is described in detail in Chapter 33, "The Network File System (NFS)."

Note

Why would a file-management and transfer protocol such as NFS, with its obvious need for absolute data integrity, use UDP? The reason is that with NFS, many hosts on the network can be using an NFS resource, and any of them can drop off the network without warning. Rather than maintaining all the processing overhead necessary for keeping TCP connections with these ephemeral hosts, NFS chooses UDP as its transport and provides the data integrity necessary for file transfer at the application level. Information about the complete transfer is maintained in the packets' data, so NFS itself can know when it's missing any pieces, or if any are corrupt.

The biggest use for UDP these days is in streaming media. Teleconferencing, streamed video, broadcast musicthese protocols don't care if they miss a beat. They consist of long streams of datagrams (packets), usually very small ones, which are gathered in the order they're received by the application and then dumped to the screen or speakers. One lost packet probably won't even be missed. If network congestion occurs, the packets are simply lost at the router level (routers keep their own timeouts on their buffers), and the stream is resumed in real time when the host becomes available againand not where it left off. There's no reason to queue up all the missed packets and dump them through at once. They're irrelevant. That's the utility of UDP: speed and simplicity where reliability isn't important.

The Internet Control Message Protocol (ICMP)

ICMP is a small "diagnostic" protocol, mostly used in tools that gauge network health. Some consider ICMP to exist on the network layer, equivalent to IP and IPX; others treat it as a transport protocol like TCP or UDP. The truth is that it has elements of both. The messages received by ICMP are handled at the "network" layer, but these messages are built to interact with programs at the "transport" level, so it's difficult to say where it fits in the scheme of things.

The most common ways you'll use ICMP are with the ping and traceroute tools, both of which return information fundamental to the ICMP datagram structure. Mostly, they're built on ICMP's capability to query remote hosts for timestamps or echoes, which come back with specialized codes. ICMP can also be used to provide error messages to "transport" layer protocols, such as the "Port Unreachable" error returned by ICMP to a UDP sender that tries to talk to an unavailable port on the recipient's machine. ICMP has 16 of these error conditions it can report, as well as about as many additional functions. You generally won't need to know about them because they're really of interest only to the applications that can read them.

To see how TCP, UDP, ICMP, and other protocols fit into the OSI model, the best and most definitive reference is TCP/IP Illustrated by W. Richard Stevens (Addison-Wesley, 1994). This multivolume text is an indispensable addition to any network administrator's library; it uncovers all the relevant details of how the protocols interrelate and interoperate and presents key concepts in an understandable manner.