Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

☯ The IP Protocol field.

☯ The UDP Length field.

The total length of this “pseudo header” is 11 bytes. It is padded to 12 bytes with a byte of

zeroes and then prepended to the real UDP message. The checksum is then computed

over the combination of the pseudo header and the real UDP message, and the value is

placed into the Checksum field. The pseudo header is used only for this calculation and is

then discarded; it is not actually transmitted. The UDP software in the destination device

creates the same pseudo header when calculating its checksum to compare to the one

transmitted in the UDP header.

Computing the checksum over the regular UDP fields protects against bit errors in the UDP

message itself. Adding the pseudo header allows the checksum to also protect against

other types of problems as well, most notably the accidental delivery of a message to the

wrong destination. The checksum calculation in UDP, including the use of the pseudo

header is exactly the same as the method used in TCP (except the Length field is different

Figure 200: UDP Message Format

Figure 201: UDP Pseudo Header Format

Source Port Destination Port

Length Checksum

Data

4 8 12 16 20 24 28 320

Source Address

(from IP Header)

Destination Address

(from IP Header)

Reserved

Protocol

(from IP Header)

Length

(from UDP Header)

4 8 12 16 20 24 28 320

in TCP). See the topic describing TCP checksum calculation for a full description of why the

pseudo header is important, and some of the interesting implications of using IP fields in

transport layer datagram calculations.

Key Concept: UDP packages application layer data into a very simple message

format that includes only four header fields. One of these is an optional checksum

field; when used, the checksum is computed over both the real header and a

“pseudo header” of fields from the UDP and IP headers, in a manner very similar to how the

TCP checksum is calculated.

Note that the use of the Checksum field is optional in UDP. If it is not used, it is set to a

value of all zeroes. This could potentially create confusion, however, since when the

checksum is used, the calculation can sometimes result in a value of zero. To avoid having

the destination think the checksum was not used in this case, this zero value is instead

represented as a value of all ones (65,535 decimal).

UDP Common Applications and Server Port Assignments

As we have seen in our exploration of the User Datagram Protocol, UDP contains very little

functionality. With the exception of the important addressing capability that UDP ports

represent, using UDP is very much like using IP directly. This means UDP has most of the

same disadvantages that IP has. It doesn't establish a lasting connection between devices;

it doesn't acknowledge received data or retransmit lost messages, and it certainly doesn't

concern itself with esoterics such as flow control and congestion management.

The lack of these features makes UDP simply unsuitable for the majority of “classical”

networking applications. These usually need to be able to establish a connection, so the

two devices can exchange data back and forth. Many also need the ability to occasionally

or even regularly send very large amounts of data that must be received intact for it to be of

value. For example, consider a message transfer protocol like HTTP. If only part of a Web

page gets from a server back to a Web browser, it's useless. HTTP and other file and

message transfer protocols like it need the capabilities we mentioned just above.

I have read about problems that have occurred in the past in applications using UDP.

Sometimes programmers don't realize how little UDP does, and that it leaves the appli-

cation responsible for handling all the potential vagaries of an internetworking environment.

Someone writing a UDP-based application must always keep in mind that no assumptions

can be made about how or even whether any message will be received by its destination,

and must plan accordingly. Insufficient testing can lead to disaster in worst-case scenarios

on a larger internet and especially, the Internet.

Why Some TCP/IP Applications Use UDP

What applications use UDP then? Well, the classic “disclaimer” with UDP is that since it

doesn't provide the features we saw earlier, an application that uses UDP is responsible for

those functions. In reality, if an application needs the features that TCP provides but UDP

does not, having the application implement them is inefficient, except in special cases. If the

application needs what TCP provides, it should just use TCP! However, applications that

only need some of what TCP implements are sometimes better off to use UDP and

implement that limited set of functionality at the application level.

So, the applications that run over UDP are normally those that do not require all or even

most of the features that TCP has, and that can benefit from the increased efficiency of

avoiding the setup and overhead associated with TCP. Applications usually (but not always)

meet this description because the data they send falls into one of two categories.

Data Where Performance Is More Important Than Completeness

The classic example of this category is a multimedia application. If you are streaming a

video clip over the Internet, the most important thing is that the stream starts flowing quickly

and keeps flowing. Humans only really notice significant disruptions in the flow of this type

of information, so a few bytes of data missing due to a lost datagram is not only not a big

problem, it's unlikely to even be noticed.

Furthermore, even if TCP were used for something like this and a lost datagram was

noticed and retransmitted, it would be useless because it would belong to a part of the clip

that is long past—and the time spent in that retransmission might make the actual current

part of the clip arrive late. Clearly, UDP is best for this situation.

Data Exchanges That Are “Short And Sweet”

There are many TCP/IP applications where the underlying protocol consists of only a very

simple request/reply exchange. A short request message is sent from a client to a server,

and a short reply message goes back from the server to the client. In this situation, there is

no real need to set up a connection like TCP does. Also, if only one short message is sent,

it can be carried in a single IP datagram. This means there is no need to worry about data

arriving out of order, flow control between the devices and so forth.

How about loss of the request or the reply? These can be handled simply at the application

level using timers. If a client sends a request and the server doesn't get it, it won't reply, and

the client will eventually send a replacement request. The same logic applies if the server

sends a response that never arrives.

Other Cases Where UDP Is Required

As I said before, these are the most common cases where UDP is used, but there are other

reasons. For example, if an application needs to multicast or broadcast data, it must use

UDP, because TCP is only supported for unicast communication between two devices.

Key Concept: UDP is most often used by a protocol instead of TCP in two situa-

tions. The first is when an application values timely delivery over reliable delivery,

and where TCP’s retransmission of lost data would be of limited or even no value.

The second is when a simple protocol is able to handle the potential loss of an IP datagram

itself at the application layer using a timer/retransmit strategy, and where the other features

of TCP are not required. UDP is also used for applications that require multicast or

broadcast transmissions, since these are not supported by TCP.

Common UDP Applications and Server Port Use

Table 149 shows some of the more interesting protocols that use UDP and the well-known

and registered port numbers used for each one's server processes. It also provides a very

brief description of why these protocols use UDP instead of TCP. See the sections or topics

devoted to each application for more details:

Table 149: Common UDP Applications and Server Port Assignments (Page 1 of 2)

Port # Keyword Protocol Comments

53 domain

Domain Name Server

(DNS)

Uses a simple request/reply messaging system for

most exchanges (but also uses TCP for longer ones).

67 and 68

bootps /

bootpc

Bootstrap Protocol

(BOOTP) and

Dynamic Host Config-

uration Protocol

(DHCP)

Host configuration protocols that consist of short

request and reply exchanges.

69 tftp

Trivial File Transfer

Protocol (TFTP)

TFTP is a great example of a protocol that was specif-

ically designed for UDP, especially when it is

compared to regular FTP. The latter protocol uses

TCP to establish a session between two devices, and

then makes use of its own large command set and

TCP's features to ensure reliable transfer of possibly

very large files. In contrast, TFTP is designed for the

quick and easy transfer of small files. It includes

simple versions of some of TCP's features, such as

acknowledgments, to avoid file corruption.

161 and

162

snmp

Simple Network

Management Protocol

An administrative protocol that uses relatively short

messages.

Applications That Use Both UDP and TCP

There are some protocols that actually use both UDP and TCP. This is often the case either

for utility protocols that are designed to accept connection using both transport layer

protocols, or for applications that need the benefits of TCP in some cases, but not others.

The classic example of the latter is DNS, which normally uses UDP port 53 for simple

requests and replies, which are usually short. Larger messages requiring reliable delivery,

such as zone transfers, use TCP port 53 instead. Note that in the table above I have

omitted some of the less-significant protocols, such as the ones used for diagnostic

purposes (Echo, Discard, CharGen, etc.) For a full list of all common applications, see the

topic on common TCP/IP applications and port numbers.

520 and

521

router / ripng

Routing Information

Protocol (RIP-1, RIP-

2, RIPng)

Unlike more complex routing protocols like BGP, RIP

uses a simple request/reply messaging system,

doesn't require connections, and does require multi-

casts/broadcasts. This makes it a natural choice for

UDP. If a routing update is sent due to a request and is

lost, it can be replaced by sending a new request.

Routine (unsolicited) updates that are lost are

replaced in the next cycle.

2049 nfs Network File System

NFS is an interesting case. Since it is a file sharing

protocol, one would think that it would use TCP

instead of UDP, but it was originally designed to use

UDP for performance reasons. There were many

people who felt this was not the best design decision,

and later versions moved to the use of TCP. The latest

version of NFS uses only TCP.

Table 149: Common UDP Applications and Server Port Assignments (Page 2 of 2)

Port # Keyword Protocol Comments

TCP/IP Transmission Control Protocol (TCP)

In my description of the Internet Protocol, I call it the “workhorse” of the TCP/IP protocol

suite. IP is, in fact, the foundation upon which the other protocols of the suite are built. Well,

if IP is the “workhorse”, then the “worker” that rides on that horse would have to be the TCP/

IP Transmission Control Protocol (TCP). Like horse and rider, TCP and IP form a team that

work together to make it possible for applications to easily run over an internetwork.

TCP and IP share the marquee in the name of the suite, and are very important comple-

ments to each other. IP concerns itself with classic network-layer tasks such as addressing,

datagram packaging and routing, which provide basic internetworking capabilities. TCP

provides to applications a method of easily making use of IP, while filling in the capabilities

that IP lacks. It allows TCP/IP devices to establish and manage connections and send data

reliably, and takes care of handling all the potential “gotchas” that can occur during trans-

mission so each application doesn't need to worry about such matters. To applications, TCP

could thus be considered almost like a nice user interface to the fairly rudimentary capabil-

ities of IP.

This section provides a comprehensive description of the concepts, characteristics and

functions of the Transmission Control Protocol (TCP). TCP is a rather complex protocol that

includes a number of sophisticated functions to ensure that applications function in the

potentially difficult environment of a large internetwork. It's also, as I said above, a very

important part of the TCP/IP protocol suite. For this reason, the section is rather large, and

has been divided into five subsections.

The first subsection provides an overview of TCP, describing its history, what it does and

how it works. The second paints some important background information that is necessary

to understanding how TCP operates. This is done by explaining key concepts such as

streams and segments, sliding windows and TCP ports and connections. The third

subsection describes the process used by TCP to establish, maintain and terminate

sessions. The fourth describes TCP messages, and how they are formatted and trans-

ferred. Finally, the last subsection shows how TCP provides reliability and other important

transport layer functions to applications, such as flow control, retransmission of lost data

and congestion avoidance.

Background Information: Since TCP is built on top of IP, in describing TCP, I

make the assumption that the reader has at least a basic familiarity with IP. If you

have come to this section without first gaining an understanding of IP, I'd suggest

reading that section first. Since it's large, reviewing the portion describing IP concepts will

likely suffice for background.

TCP Overview, Functions and Characteristics

As I mentioned in the previous section overview, the Transmission Control Protocol (TCP)

is a critically important part of the TCP/IP suite. It's also a fairly complicated protocol, with a

lot of important concepts and mechanisms to understand. The old joke says the best way to

eat an elephant is “one bite at a time”. Similarly here, we can best comprehend the

operation of this complicated protocol by going slowly, starting with a high-level look at it,

where it came from, and what it does in general terms.

In this section I begin our look at TCP with an introduction to the protocol. I first provide an

overview and history of TCP, and describe the standards that define it. I then give a “bird's

eye” view of TCP by describing it in two important ways. I illustrate what TCP actually does

by listing its functions, and then explain how TCP works by describing its most important

characteristics. This will give you a feel for what TCP is all about, and hopefully set the

stage for the more complex technical discussions in subsequent sections.

TCP Overview, History and Standards

Between them, layers three and four of the OSI Reference Model represent the interface

between networking software (the applications that need to move data across networks)

and networking hardware (the devices that carry the data over networks). Any protocol suite

must have a protocol or set of protocols that handles these layer three and layer four

functions.

The TCP/IP protocol suite is named for the two main protocols that provides these capabil-

ities, allowing software to run on an internetwork: the Transmission Control Protocol (TCP)

and the Internet Protocol (IP). IP deals with internetwork datagram delivery and routing,

while TCP handles connections and provides reliability. What's interesting, however, is that

in the early days of the protocol suite, there was, in fact, no “TCP/IP” at all.

TCP History

Due to its prominent role, the history of TCP is impossible to describe without going back to

the early days of the protocol suite as a whole. In the early 1970s, what we know of today

as the global Internet was a small research internetwork called the ARPAnet, named for the

United States Defense Advanced Research Projects Agency (DARPA or ARPA). This

network used a technology called the Network Control Protocol (NCP) to allow hosts to

connect to each other. NCP did approximately the jobs that TCP and IP do together today.

Due to limitations in the NCP, development began on a new protocol that would be better

suited to a growing internetwork. This new protocol, first formalized in RFC 675, was called

the Internet Transmission Control Program (TCP). Like its predecessor NCP, TCP was

responsible for basically everything that was needed to allow applications to run on an inter-

network. Thus, TCP was at first both TCP and IP.

As I explain in detail in the topic describing the history of TCP/IP as a whole, several years

were spent adjusting and revising TCP, with version 2 of the protocol documented in 1977.

While the functionality of TCP was steadily improved, there was a problem with the basic

concept behind the protocol. Having TCP by itself handle both datagram transmissions and

routing (layer three functions) as well as connections, reliability and data flow management

(layer four functions) meant that TCP violated key concepts of protocol layering and

modularity. TCP forced all applications to use the layer four functions in order to use the

layer three functions. This made TCP inflexible, and poorly-suited to the needs of applica-

tions that only need the lower-level functions and not the higher-level ones.

As a result, the decision was made to split TCP into two: the layer four functions were

retained, with TCP renamed the Transmission Control Protocol (as opposed to Program).

The layer three functions became the Internet Protocol. This split was finalized in version 4

of TCP, and so the first IP was given “version 4” as well, for consistency. Version 4 of TCP

was defined in RFC 793, Transmission Control Protocol

, published September 1981, and is

still the current version of the standard.

Even though it is more than 20 years old and is the first version most people have ever

used, version 4 was the result of several years work and many earlier TCP versions tested

on the early Internet. It is therefore a very mature protocol for its age. A precocious protocol,

you could say. (To be fair, many additional features and modifications to how TCP works

have been described in other standards, rather than upgrading the main document.)

Overview of TCP Characteristics and Operation

TCP is a full-featured transport layer protocol that provides all the functions needed by a

typical application for the reliable transportation of data across an arbitrary internetwork. It

provides transport-layer addressing for application processes in the form of TCP ports, and

allows these ports to be used in establishing connections between machines. Once connec-

tions have been created, data can be passed bidirectionally between two devices.

Applications can send data to TCP as a simple stream of bytes, and TCP takes care of

packaging and sending the data as segments that are packaged into IP datagrams. The

receiving device's TCP implementation reverses the process, passing up to the application

the stream of data originally sent.

TCP includes an extensive set of mechanisms to ensure that data gets from source to desti-

nation reliably, consistently and in a timely fashion. The key to its operation in this regard is

the sliding window acknowledgement system, which allows each device to keep track of

which bytes of data have been sent and to confirm receipt of data received from the other

device in the connection. Unacknowledged data is eventually retransmitted automatically,

and the parameters of the system can be adjusted to the needs of the devices and the

connection. This same system also provides buffering and flow control capabilities between

devices, to handle uneven data delivery rates and other problems.

The inclusion of so many capabilities in TCP maximizes the likelihood that just about any

application requiring connection-oriented reliable data delivery will be satisfied by the

protocol. This is a primary goal of TCP, as it means that higher-layer applications don't

individually have to provide these common functions. TCP is the most widely used TCP/IP

transport protocol, employed by the majority of conventional message-passing applications.

Key Concept: The primary transport layer protocol in the TCP/IP suite is the Trans-

mission Control Protocol (TCP). TCP is a connection-oriented, acknowledged,

reliable, fully-featured protocol designed to provide applications with a reliable way to

send data using the unreliable Internet Protocol. It allows applications to send bytes of data

as a stream of bytes, and automatically packages them into appropriately-sized segments

for transmission. It uses a special sliding window acknowledgment system to ensure that all

data is received by its recipient, to handle necessary retransmissions, and to provide flow

control so each device in a connection can manage the rate at which it is sent data.

TCP Standards

RFC 793 is the defining standard for TCP, but it doesn't include all the details of how

modern TCP operates. Several other standards include additional information about how

the protocol works, and describe enhancements to the basic TCP mechanisms that were

developed over the years. Some of these are fairly “esoteric” and not widely known, but

they are useful in gaining a more complete understanding of TCP. I have listed some of

them in Table 150

Table 150: Supplementary TCP Standards (Page 1 of 2)

RFC

Number

Name Description

813

Window and Acknowledgment

Strategy in TCP

Discusses the TCP sliding window acknowledgment

system, describing certain problems that can occur with it

and methods to correct them.

879

The TCP Maximum Segment Size

and Related Topics

Discusses the important Maximum Segment Size (MSS)

parameter that controls the size of TCP messages, and

relates this parameter to IP datagram size.

896

Congestion Control in IP/TCP

Internetworks

Talks about congestion problems and how TCP can be

used to handle them.

Note the interesting inversion of the normal protocol suite

name: “IP/TCP”.

1122

Requirements for Internet Hosts —

Communication Layers

Describes important details of how TCP should be imple-

mented on hosts.

1146 TCP Alternate Checksum Options

Specifies a mechanism for having TCP devices use an

alternative method of checksum generation.

1323

TCP Extensions for High

Performance

Defines extensions to TCP for high-speed links, and new

TCP options.

2018

TCP Selective Acknowledgment

Options

An enhancement to basic TCP functionality that allows

TCP devices to selectively specify specific segments for

retransmission.

Of course, there are hundreds of higher-layer application protocols that use TCP, and

whose defining standards therefore make at least glancing reference to it.

TCP is of course designed to use the Internet Protocol, since they were developed together

and as we have seen, were even once part of the same specification. At the same time,

they were split up for the specific reason of respect the principles of architectural layering.

For this reason, TCP tries to make as few assumptions as possible regarding the under-

lying protocol over which it runs. It is not as strictly tied to the use of IP as one might

imagine, and can even be adapted for use over other network-layer protocols. For our

purposes, however, this should be considered mainly an "interesting aside". We will be

assuming TCP works over IP in our discussions, since that is almost always how it is used.

TCP Functions: What TCP Does

We have now seen where TCP comes from and the standards that describe it. As I said in

the introduction to this section, TCP is a complicated protocol, so it will take some time to

explain how it works. The most logical first “bite” in consuming this particular “elephant” is to

look at exactly what TCP does. From there, we can describe its characteristics and then get

into the details of its operation.

Functions Performed By TCP

Despite the complexity of TCP, its basic operation can be reasonably simplified by

describing its primary functions. The following are what I believe to be the five main tasks

that TCP performs:

☯ Addressing/Multiplexing: TCP is used by many different applications for their

transport protocol. Therefore, like its simpler sibling UDP, an important job for TCP is

multiplexing the data received from these different processes so they can be sent out

using the underlying network-layer protocol. At the same time, these higher-layer

application processes are identified using TCP ports. The section on TCP/IP transport

layer addressing contains a great deal of detail on how this addressing works.

☯ Connection Establishment, Management and Termination: TCP provides a set of

procedures that devices follow to negotiate and establish a TCP connection over

which data can travel. Once opened, TCP includes logic for managing connections

and handling problems that may result with them. When a device is done with a TCP

connection, a special process is followed to terminate it.

2581 TCP Congestion Control

Describes four algorithms used for congestion control in

TCP networks: slow start, congestion avoidance, fast

retransmit and fast recovery.

2988

Computing TCP's

Retransmission Timer

Discusses issues related to setting the TCP retrans-

mission timer, which controls how long a device waits for

acknowledgment of sent data before retransmitting it.

Table 150: Supplementary TCP Standards (Page 2 of 2)

RFC

Number

Name Description