Charles M. Kozierok The TCP-IP Guide

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

☯ Data Handling and Packaging: TCP defines a mechanism by which applications are

able to send data to it from higher layers. This data is then packaged into messages to

be sent to the destination TCP software. The destination software unpackages the

data and gives it to the application on the destination machine.

☯ Data Transfer: Conceptually, the TCP implementation on a transmitting device is

responsible for the transfer of packaged data to the TCP process on the other device.

Following the principle of layering, this is done by having the TCP software on the

sending machine pass the data packets to the underlying network-layer protocol,

which again normally means IP.

☯ Providing Reliability and Transmission Quality Services: TCP includes a set of

services and features that allow an application to consider the sending of data using

the protocol to be “reliable”. This means that normally, a TCP application doesn't have

to worry about data being sent and never showing up, or arriving in the wrong order. It

also means other common problems that might arise if IP were used directly are

avoided.

☯ Providing Flow Control and Congestion Avoidance Features: TCP allows the flow

of data between two devices to be controlled and managed. It also includes features to

deal with congestion that may be experienced during communication between

devices.

Clearly, TCP is responsible for a fairly significant number of key functions. This list may not

seem that impressive. The reason is that this is just a high-level look at the protocol, and

these functions are summarized in the list above; when we look at them in detail we will see

that each one actually involves a rather significant amount of work for TCP to do.

Functions Not Performed By TCP

TCP does so much that sometimes it is described as doing “everything” an application

needs to use an internetwork. I may even have been guilty of this myself. However, the

protocol doesn't do everything. It has limitations and certain areas that its designers specif-

ically did not address. Among the notable functions TCP does not perform include:

☯ Specifying Application Use: TCP defines the transport protocol. It does not describe

specifically how applications are to use TCP.

☯ Providing Security: TCP does not provide any mechanism for ensuring the authen-

ticity or privacy of data it transmits. If these are needed they must be accomplished

using some other means, such as IPSec, for example.

☯ Maintaining Message Boundaries: TCP sends data as a continuous stream, not as

discrete messages. It is up to the application to specify where one message ends and

the next begins.

☯ Guaranteeing Communication: Wait a minute… isn't the whole point of TCP

supposed to be that it guarantees data will get to its destination? Well, yes and no. ☺

TCP will detect unacknowledged transmissions and re-send them if needed. However,

in the event of some sort of problem that prevents reliable communication, all TCP can

do is “keep trying”. It can't make any guarantees because there are too many things

out of its control. Similarly, it can attempt to manage the flow of data, but cannot

resolve every problem.

This last point might seem a bit pedantic, but is important to keep in mind, especially since

the tendency is to think of TCP as somewhat “bulletproof”. The overall success of communi-

cation depends entirely on the underlying internetwork and the networks that constitute it. A

chain is as strong as its weakest link, and if there is a problem at the lower layers, nothing

TCP can do will guarantee successful data transfer.

Key Concept: TCP provides reliable communication only by detecting failed trans-

missions and re-sending them. It cannot guarantee any particular transmission,

because it relies on IP, which is unreliable. All it can do is keep trying if an initial

delivery attempt fails.

TCP Characteristics: How TCP Does What It Does

In the preceding topic we began our high-level look at TCP by examining the most

important functions the protocol performs—as well as a few that it does not. In many ways,

it is more interesting to look at how TCP does its job than the functions of the job itself. By

examining the most important attributes of TCP and its operation, we can get a better

handle on the way TCP works. We can also see the many ways that it contrasts to its

simpler transport layer sibling, UDP.

TCP Characteristics

The following are the ways that I would best describe the Transmission Control Protocol

and how it performs the functions described in the preceding topic:

☯ Connection-Oriented: TCP requires that devices first establish a connection with

each other before they send data. The connection creates the equivalent of a circuit

between the units, and is analogous to a telephone call. A process of negotiation

occurs to establish the connection, ensuring that both devices agree on how data is to

be exchanged.

☯ Bidrectional: Once a connection is established, TCP devices send data bidirec-

tionally. Both devices on the connection can send and receive, regardless of which of

them initiated the connection.

☯ Multiply-Connected and Endpoint-Identified: TCP connections are identified by the

pair of sockets used by the two devices in the connection. This allows each device to

have multiple connections opened, either to the same IP device or different IP devices,

and to handle each connection independently without conflicts.

☯ Reliable: Communication using TCP is said to be reliable because TCP keeps track of

data that has been sent and received to ensure it all gets to its destination. As we saw

in the previous topic, TCP can't really “guarantee” that data will always be received.

However, it can guarantee that all data sent will be checked for reception, and

checked for data integrity, and then retransmitted when needed. So, while IP uses

“best effort” transmissions, you could say TCP tries harder, as the old rent-a-car

commercial goes.

☯ Acknowledged: A key to providing reliability is that all transmissions in TCP are

acknowledged (at the TCP layer—TCP cannot guarantee that all such transmissions

are received by the remote application). The recipient must tell the sender “yes, I got

that” for each piece of data transferred. This is in stark contrast to typical messaging

protocols where the sender never knows what happened to its transmission. As we will

see, this is fundamental to the operation of TCP as a whole.

☯ Stream-Oriented: Most lower-layer protocols are designed so that to use them,

higher-layer protocols must send them data in blocks. IP is the best example of this;

you send it a message to be formatted and it puts that message into a datagram. UDP

is the same. In contrast, TCP allows applications to send it a continuous stream of

data for transmission. Applications don't need to worry about making this into chunks

for transmission; TCP does it.

☯ Data-Unstructured: An important consequence of TCP's stream orientation is that

there are no natural divisions between data elements in the application's data stream.

When multiple messages are sent over TCP, applications must provide a way of differ-

entiating one message (data element, record, etc.) from the next.

☯ Data-Flow-Managed: TCP does more than just package data and send it as fast as

possible. A TCP connection is managed to ensure that data flows evenly and

smoothly, with means included to deal with problems that arise along the way.

Key Concept: To summarize TCP’s key characteristics, we can say that it is

connection-oriented, bidirectional, multiply-connected, reliable, acknowledged,

stream-oriented and flow-managed.

The Robustness Principle

There's one more thing about TCP that is more an indication of the general maxim behind

its creation than a particular characteristic of its operation. The TCP standard says that TCP

follows the robustness principle, which is described thusly: “be conservative in what you do;

be liberal in what you accept from others”. It means that every TCP implementation tries to

avoid doing anything that would cause a problem for another device's TCP layer, while at

the same time also trying to anticipate problems another TCP may cause and deal with

them gracefully.

This principle represents a “belt and suspenders” approach that helps provide extra

protection against unusual conditions in TCP operation. In fact, this general principle is

applied to many other protocols in the TCP/IP suite, which is part of the reason why it has

proven so capable over the years. It allows TCP and other protocols to often deal with even

unanticipated problems that might show up in the difficult environment of a large inter-

network such as the Internet.

Putting TCP's Performance In Perspective

Also, while we are on the subject of TCP’s characteristics, I want to reinforce one other

thing I said in the overview of TCP and UDP: TCP has many attributes but one of them is

not “slow”. It is true that UDP is usually used by applications for performance reasons when

they don't want to deal with the overhead TCP incorporates for connections and reliability.

That, however, should not lead one to conclude that TCP is glacial, by any means. It is in

fact quite efficient—were it not, it's unlikely it would have ever achieved such widespread

use.

TCP Fundamentals and General Operation

Many people have a difficult time really understanding how the Transmission Control

Protocol works. (After spending dozens of hours writing almost 100 pages on the protocol, I

am quite sympathetic.) I think a main reason for the difficulty in absorbing TCP is that too

many descriptions of the protocol quickly jump from a brief introduction straight into the

mind-boggling details of TCP's operation. The problem is that TCP has a very particular

way of doing certain things. Its operation is built around a few very important fundamentals

that it is essential to understand before the details of TCP operation will make much sense.

In this section I describe some of the key operating fundamentals of TCP. I begin with a

discussion of how TCP handles data, and introduce the concepts of streams, segments and

sequences. I then describe the very important TCP sliding window system, used for

acknowledgment, reliability and data flow control. I discuss how TCP uses ports, and how

connections are identified. I also describe the most important applications that use TCP and

what ports they use for server applications.

TCP Data Handling and Processing: Streams, Segments and Sequence

Numbers

One of the “givens” in the operation of most of the protocols we find at upper layers in the

OSI Reference Model is that they are oriented around the use of messages. These

messages are analogous to a written letter in an envelope, containing a specific piece of

information. They are passed from higher layers down to lower ones, where they are

encapsulated in the lower layer's headers (like putting them in another envelope) and then

passed down further until they are actually sent out at the physical layer.

A good example of this can be seen in looking at the User Datagram Protocol, TCP’s

transport layer peer. To use UDP, an application passes it a distinct block of data that is

usually fairly short. The block is packaged into a UDP message, then sent to IP. IP packs

the message into an IP datagram and eventually passes it to a layer two protocol such as

Ethernet. There it is placed into a frame and sent to layer one for transmission.

Increasing the Flexibility of Application Data Handling: TCP's Stream Orientation

The use of discrete messaging is pretty simple, and it obviously works well enough since

most protocols make use of it. However, it is inherently limiting, because it forces applica-

tions to create discrete blocks of data in order to communicate. There are many

applications that need to send information continuously in a manner that doesn't lend itself

well to creating “chunks” of data. Others need to send data in chunks that are so large that

they could never be sent as a single message at the lower layers anyway.

To use a protocol like UDP, many applications would be forced to artificially divide their data

into messages of a size that has no inherent meaning to them. This would immediately

introduce new problems requiring more work for the application. It would have to keep track

of what data is in what message, and replace any that were lost. It would need to ensure

that the messages could be reassembled in the correct order, since IP might deliver them

out of order.

Of course, one could program applications to do this, but these functions are already ones

that TCP is charged with taking care of, so it would make little sense. Instead, the designers

of TCP took the very smart approach of generalizing TCP so it could accept application

data of any size and structure, without requiring that it be in discrete pieces. More specifi-

cally, TCP is said to treat data coming from an application as a stream; thus, the description

of TCP as stream-oriented. Each application sends the data it wishes to transmit as a

steady stream of octets (bytes). It doesn't need to carve them into blocks, or worry about

how lengthy streams will get across the internetwork. It just “pumps bytes” to TCP.

TCP Data Packaging: Segments

Of course, TCP must take these bytes and send them using a network-layer protocol,

meaning the Internet Protocol. IP is a message-oriented protocol, not stream-oriented.

Thus, we have simply “passed the buck” to TCP, which must take the stream from the appli-

cation and divide it into discrete messages for IP. These messages are called TCP

segments.

Note: As an aside, this is one of the most confusing data structure names in the

world of networking. From a dictionary definition standpoint, referring to a piece of

a stream as a segment is sensible, but most people working with networks don't

think of a message as being a “segment”. In the industry, the term also refers to a length of

cable or a part of a local area network, among other things, so watch out for that.

TCP segments are treated by IP like all other discrete messages for transmission. They are

placed into IP datagrams and transmitted to the destination device. The recipient

unpackages the segments and passes them to TCP, which converts them back to a byte

stream to send to the application. This process is illustrated in Figure 202.

The TCP layer on a device accumulates data it receives from the application process

stream. On regular intervals, it forms segments to be transmitted using IP. The size of the

segment is controlled by two primary factors. The first issue is that there is an overall limit to

the size of a segment, chosen to prevent unnecessary fragmentation at the IP layer. This is

governed by a parameter called the maximum segment size (MSS), which is determined

during connection establishment. The second is that TCP is designed so that once a

connection is set up, each of the devices tells the other how much data it is ready to accept

at any given time. If this is lower than the MSS value, a smaller segment must be sent. This

is part of the sliding window system described in the next topic.

Figure 202: TCP Data Stream Processing and Segment Packaging

TCP is different from most protocols because it does not require applications that use it to send data to it in

messages. Once a TCP connection is set up, an application protocol can send TCP a steady stream of bytes

that does not need to conform to any particular structure. TCP packages these bytes into segments that are

sized based on a number of different parameters. These segments are passed to IP, where they are encapsu-

lated into IP datagrams and transmitted. The process is reversed by the receiving device: segments are

removed from IP datagrams, then the bytes are taken from the segments and passed up to the appropriate

recipient application protocol as a byte stream.

Server

Transmission Control

Protocol (TCP)

4 5 6 7

8 9

10 11

Application Protocol

Internet Protocol (IP)

12 13

15 16 17 18

Client

Application Protocol

Transmission Control

Protocol (TCP)

Byte Stream

Sent By

Application

Internet Protocol (IP)

Bytes Packaged

Into Segment

Segme nt

Encapsulated

Into IP Datagram

IP Datagram

In Transit

Segme nt

Removed From

IP Datagram

Bytes Unpackaged

From TCP Segment

And Passed To

Application

Key Concept: TCP is designed to have applications send data to it as a stream of

bytes, rather than requiring fixed-size messages to be used. This provide maximum

flexibility for a wide variety of uses, because applications don’t need to worry about

data packaging, and can send files or messages of any size. TCP takes care of packaging

these bytes into messages called segments.

TCP Data Identification: Sequence Numbers

The fact that TCP treats data coming from an application as a stream of octets has a couple

of very significant implications on the operation of the protocol. The first is related to data

identification. Since TCP is reliable, it needs to keep track of all the data it receives from an

application so it can make sure it is all received by the destination. Furthermore, it must

make sure the data is received in the order it was sent, and must retransmit any lost data.

If data were conveyed to TCP in block-like messages, it would be fairly simple to keep track

of the data by adding an identifier to each message. Since TCP is stream-oriented,

however, that identification must be done for each byte of data! This may seem surprising,

but it is actually what TCP does, through the use of sequence numbers. Each byte of data is

assigned a sequence number which is used to keep track of it through the process of trans-

mission, reception and acknowledgment (though in practice, blocks of many bytes are

managed using the sequence numbers of bytes at the start and end of the block). These

sequence numbers are used to ensure that data sent in segments is reassembled into the

original stream of data transmitted by the sending application. They are required to

implement the sliding window system that enables TCP to provide reliability and data flow

control.

Key Concept: Since TCP works with individual bytes of data rather than discrete

messages, it must use an identification scheme that works at the byte level to

implement its data transmission and tracking system. This is accomplished by

assigning each byte TCP processes a sequence number.

The Need For Application Data Delimiting

The other impact of TCP treating incoming data as a stream is that data received by an

application using TCP is unstructured. For transmission, a stream of data goes into TCP on

one device, and on reception, a stream of data goes back to the application on the receiving

device. Even though the stream is broken into segments for transmission by TCP, these

segments are TCP-level details that are hidden from the application. So, when a device

wants to send multiple pieces of data, TCP provides no mechanism for indicating where the

“dividing line” is between the pieces, since TCP doesn't examine the meaning of the data at

all. The application must provide a means for doing this.

Consider for example an application that is sending database records. It needs to transmit

record #579 from the Employees database table, followed by record #581 and record #611.

It sends these records to TCP, which treats them all collectively as a stream of bytes. TCP

will package these bytes into segments, but in a manner the application cannot predict. It is

possible that each will end up in a different segment, but more likely they will all be in one

segment, or part of each will end up in different segments, depending on their length. The

records themselves must have some sort of explicit markers so the receiving device can tell

where one record ends and the next starts.

Key Concept: Since applications send data to TCP as a stream of bytes and not

prepackaged messages, each application must use its own scheme to determine

where one application data element ends and the next begins.

TCP Sliding Window Acknowledgment System For Data Transport, Reliability

and Flow Control

What differentiates the Transmission Control Protocol from simpler transport protocols like

UDP is the quality of the manner in which it sends data between devices. Rather than just

sticking data in a message and saying “off you go”, TCP carefully keeps track of the data it

sends and what happens to it. This management of data is required to facilitate two key

requirements of the protocol:

☯ Reliability: Ensuring that data that is sent actually arrives at its destination, and if not,

detecting this and re-sending the data.

☯ Data Flow Control: Managing the rate at which data is sent so that it does not

overwhelm the device that is receiving it.

To accomplish these tasks, the entire operation of the protocol is oriented around

something called the sliding window acknowledgment system. It is no exaggeration to say

that comprehending how sliding windows works is critical to understanding just about

everything else in TCP. It is also, unfortunately, a bit hard to follow if you try to grasp it all at

once, which means many people's eyes glaze over trying to make sense of it.

Since you can’t really get TCP without understanding sliding windows, I wanted to make

sure that I explained the mechanism thoroughly—and without assuming you already under-

stand a great deal, as most references do. For this reason I am going to start with the

concepts behind sliding windows and eventually explain how the technique works in

general terms and why it is so powerful. Doing this properly required a considerable amount

of explanation (which took a long time to get right, I might add!) so buckle your seat belt. ☺

The Problem With Unreliable Protocols: Lack of Feedback

A simple “send and forget” protocol like IP is unreliable and includes no flow control for one

main reason: it is an open loop system where the transmitter receives no feedback from the

recipient. (I'm ignoring error reports using ICMP and the like for the purpose of this

discussion.) A datagram is sent and it may or may not get there, but the transmitter will

never have any way of knowing because no mechanism for feedback exists. This is shown

conceptually in Figure 203.

Providing Basic Reliability Using Positive Acknowledgment with Retransmission

(PAR)

Basic reliability in a protocol running over an unreliable protocol like IP can be implemented

by closing the loop so the recipient provides feedback to the sender. This is most easily

done with a simple acknowledgment system. Device A sends a piece of data to Device B.

Device B, receiving the data, sends back an acknowledgment saying, “Device A, I received

your message”. Device A then knows its transmission was successful.

Of course, since IP is unreliable, that message may in fact never get to where it is going.

Device A will sit waiting for the acknowledgment and never receive it. Conversely, it is also

possible that Device B gets the message from Device A, but the acknowledgment itself

vanishes somehow. In either case, we don't want Device A to sit forever waiting for an

acknowledgment that is never going to ever arrive.

To prevent this from happening, Device A starts a timer when it first sends the message to

Device B, which allows sufficient time for the message to get to B and the acknowledgment

to travel back, plus some reasonable time to allow for possible delays. If the timer expires

before the acknowledgment is received, A assumes there was a problem and retransmits

its original message. Since this method involves positive acknowledgments (“yes, I got your

message”) and a facility for retransmission when needed, it is commonly called (ta-da!)

positive acknowledgment with retransmission (PAR), as shown in Figure 204.

Figure 203: Operation Of An Unreliable Protocol

In a system such as that used by IP, if it gets there, great; otherwise, nobody will have a clue. ☺ Some

external mechanism is needed to take care of the lost message, unless the protocol doesn’t really care

whether a few bits and pieces are missing from its message stream.

Device A

Message

Device B

Send Message

Receive MessageSend Message

Message LostSend Message

Receive Message

Message