Charles M. Kozierok The TCP-IP Guide

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

Figure 222: TCP Transaction Example Showing Client’s Send Pointers

The transaction of Table 160 from the perspective of the client. See Figure 221 for the server’s pointers.

Client Server

1. Send Request

4. Send Part 1 of Requested File

Request

Length=140

Seq Num =1

Length = 80

Seq Num = 241

Ack Num = 141

File (part 1)

Length = 120

Seq Num = 321

6. Receive Ack For Reply

5. Receive Part 1 of File,

Send Acknowledgment

7. Receive Ack For Part 1 of File

8. Send Part 2 of File

9. Receive Part 2 of File,

Send Acknowledgment

10. Receive Ack For Part 2 of File

Acknowledgment

Ack Num = 441

File (part 2)

Length = 160

Seq Num = 441

Acknowledgment

Ack Num = 601

Acknowledgment

Ack Num = 321

SND.UNA = 1

SND.NXT = 1

Usable = 360

SND.WND = 360

SND.UNA = 141

SND.NXT = 141

140

Usable = 360

SND.WND = 360

RCV .NXT = 141

RCV .WND = 360

140

RCV .NXT = 1

RCV .WND = 360

2. Receive Request, Send

Combined Ack & Reply

3. Receive Combined Ack &

Reply, Send Acknowledgment

SND.UNA = 1

SND.NXT = 141

140

Usable = 220

SND.WND = 360

Real-World Complications of the Sliding Window Mechanism

I'm sure this seems rather complicated, but in fact, the example is highly simplified, to

show you how the basic data transfer mechanism works without too much going on. Scary,

isn’t it? ☺ A real world connection would include several complications:

☯ Overlapping Transmissions: I intentionally showed only one request from the client

and the response from the server. In reality, the client and server could be pumping

many requests and responses at each other in rapid-fire succession; the client would

be acknowledging segments received from the server with segments that themselves

contained new requests, and so on.

☯ Acknowledgment of Multiple Segments: I also didn't show a case where two

segments are received by a device and acknowledged with a single acknowledgment,

though this can certainly happen. Suppose that in the example above, the two parts of

the 280-byte file were sent at once and received by the client at the same time. The

client would acknowledge both by sending a single segment with an Acknowledgment

Number of 601. Remember, this field is a cumulative acknowledgment of all

segments containing data through the number preceding it, so this would acknowledge

all data up to byte 600.

☯ Fluctuating Window Sizes For Flow Control: The window sizes in the example

above remained constant, but in a real connection this will not always be the case. A

very busy server may not be able to process and remove data from its buffer as fast as

it acknowledges it. It may need to reduce its receive window to reduce the amount of

data the client sends it, and then increase the window when more space becomes

available. This is how TCP implements flow control.

☯ Lost Transmissions: In a real connection, some transmitted segments will be lost

and need to be retransmitted. This is handled by TCP's retransmission scheme.

☯ Avoiding Small Window Problems: I hinted in the table above that we don't neces-

sarily always want to send data as fast as we can, when it means we have to send a

very small segment. The reason is that this can lead to performance degradation,

including a phenomenon called silly window syndrome. This too will be explored in the

section that follows, where we will see how handling it requires that we change the

simple sliding windows scheme we have seen until the point.

☯ Congestion Handling and Avoidance: The basic sliding window mechanism has

been changed over the years to avoid having TCP connections cause internetwork

congestion and to have them handle congestion when it is detected. Congestion

issues are discussed, you guessed it, in the next section.

TCP Immediate Data Transfer: "Push" Function

The fact that TCP takes incoming data from a process as an unstructured stream of bytes

gives it great flexibility in meeting the needs of most applications. There is no need for an

application to create blocks or messages; it just sends the data to TCP when it is ready for

transmission. For its part, TCP has no knowledge or interest in the meaning of the bytes of

data in this stream. They are “just bytes” and TCP just sends them without any real concern

for their structure or purpose.

This has a couple of interesting impacts on how applications work. One is that TCP does

not provide any natural indication of the dividing point between pieces of data, such as

database records or files. The application must take care of this. Another result of TCP's

byte orientation is that TCP cannot decide when to form a segment and send bytes

between devices based on the contents of the data. TCP will generally accumulate data

sent to it by an application process in a buffer. It chooses when and how to send data based

solely on the sliding window system discussed in the previous topic, in combination with

logic that helps to ensure efficient operation of the protocol.

This means that while an application can control the rate and timing with which it sends

data to TCP, it cannot inherently control the timing with which TCP itself sends the data over

the internetwork. Now, if we are sending a large file, for example, this isn't a big problem. As

long as we keep sending data, TCP will keep forwarding it over the internetwork. It's

generally fine in such a case to let TCP fill its internal transmit buffer with data and form a

segment to be sent when TCP feels it is appropriate.

Problems with Accumulating Data for Transmission

However, there are situations where letting TCP accumulate data before transmitting it can

cause serious application problems. The classic example of this is an interactive application

such as the Telnet Protocol. When you are using such a program, you want each keystroke

to be sent immediately to the other application; you don't want TCP to accumulate hundreds

of keystrokes and then send them all at once. The latter may be more “efficient” but it

makes the application unusable, which is really putting the cart before the horse.

Even with a more mundane protocol that transfers files, there are many situations in which

we need to say “send the data now”. For example, many protocols begin with a client

sending a request to a server—like the hypothetical one in the example in the preceding

topic, or a request for a Web page sent by a Web browser. In that circumstance, we want

the client's request sent immediately; we don't want to wait until enough requests have

been accumulated by TCP to fill an “optimal-sized” segment.

Forcing Immediate Data Transfer

Naturally, the designers of TCP realized that a way was needed to handle these situations.

When an application has data that it needs to have sent across the internetwork immedi-

ately, it sends the data to TCP, and then uses the TCP push function. This tells the sending

TCP to immediately “push” all the data it has to the recipient's TCP as soon as it is able to

do so, without waiting for more data.

When this function is invoked, TCP will create a segment (or segments) that contains all the

data it has outstanding, and will transmit it with the PSH control bit set to 1. The destination

device's TCP software, seeing this bit sent, will know that it should not just take the data in

the segment it received and buffer it, but rather push it through directly to the application.

It's important to realize that the push function only forces immediate delivery of data. It

does not change the fact that TCP provides no boundaries between data elements. It may

seem that an application could send one record of data and then “push” it to the recipient;

then send the second record and “push” that, and so on. However, the application cannot

assume that because it sets the PSH bit for each piece of data it gives to TCP, that each

piece of data will be in a single segment. It possible that the first “push” may contain data

given to TCP earlier that wasn't yet transmitted, and it's also possible that two records

“pushed” in this manner may end up in the same segment anyway.

Key Concept: TCP includes a special “push” function to handle cases where data

given to TCP needs to be sent immediately. An application can send data to its TCP

software and indicate that it should be pushed. The segment will be sent right away

rather than being buffered. The pushed segment’s PSH control bit will be set to one to tell

the receiving TCP that it should immediately pass the data up to the receiving application.

TCP Priority Data Transfer: "Urgent" Function

TCP treats data to be transmitted as just an unstructured stream of bytes, and this has

some important implications on how it used. One aspect of this characteristic is that since

TCP doesn't understand the content of the data it sends, it normally treats all the data bytes

in a stream as equals. The data is sent to TCP in a particular sequence, and is transmitted

in that same order. This makes TCP, in this regard, like those annoying voice mail systems

that tell you not to hang up because they will answer calls in the order received.

Note: Pet peeve: I hate being told “your call will be answered in the order in which

it was received”. I only made one call, so my call wasn’t received in any “order”!

The phrase should be in the plural: “calls will be answered in the order in which

they were received”. ☺

TCP’s Normal Data Processing: First In, First Out

Of course, while waiting on hold is irritating, this first in, first out behavior is usually how we

want TCP to operate. If we are transmitting a message or a file we want to be able to give

TCP the bytes that comprise the file to be sent and have TCP transmit that data in the order

we gave it. However, just as special circumstances can require the “push” function we saw

in the previous topic, there are cases where we may not want to always send all data over

in the exact sequence it was given to TCP.

The most common example of this is when it is necessary to interrupt an application's data

transfer. Suppose we have an application that sends large files in both directions between

two devices. The user of the application realizes that the wrong file is being transferred.

When he or she tells the application to stop the file being sent, we want this to be communi-

cated to the other end of the TCP connection immediately. We don't want the “abort”

command to just be placed at the end of the line after the file we are trying to send!

Prioritizing Data For Transfer

TCP provides a means for a process to prioritize the sending of data in the form of its

“urgent” feature. To use it, the process that needs to send urgent data enables the function

and sends the urgent data to its TCP layer. TCP then creates a special TCP segment that

has the URG control bit set to 1. It also sets the Urgent Pointer field to an offset value that

points to the last byte of urgent data in the segment. So, for example, if the segment

contained 400 bytes of urgent data followed by 200 bytes of regular data, the URG bit would

be set and the Urgent Pointer field would have a value of 400.

Upon receipt of a segment with the URG flag set to 1, the receiving device looks at the

Urgent Pointer and from its value determines which data in the segment is urgent. It then

forwards the urgent data to the process with an indication that the data is marked as urgent

by the sender. The rest of the data in the segment is processed normally.

Since we typically want to send urgent data, well, urgently, it makes sense that when such

data is given to TCP, the “push” function is usually also invoked. This ensures that the

urgent data is sent as soon as possible by the transmitting TCP and also forwarded up the

protocol stack right away by the receiving TCP. Again, we need to remember that this does

not guarantee the contents of the urgent segment. Using the “push” function may mean the

segment contains only urgent data with no non-urgent data following, but again, an appli-

cation cannot assume that this will always be the case.

Key Concept: To deal with situations where a certain part of a data stream needs to

be sent with a higher priority than the rest, TCP incorporates an “urgent” function.

When critical data needs to be sent, the application signals this to its TCP layer,

which transmits it with the URG bit set in the TCP segment, bypassing any lower-priority

data that may have already been queued for transmission.

TCP Reliability and Flow Control Features and Protocol Modifications

The main task of the Transmission Control Protocol is simple: packaging and sending data.

Of course, almost every protocol packages and sends data. What distinguishes TCP from

these protocols is the sliding window mechanism that controls the flow of data between

devices. This system not only manages the basic data transfer process, it is also used to

ensure that data is sent reliably, and also to manage the flow of data between devices to

ensure that data is transferred efficiently without either device sending data faster than the

other can receive it.

To enable TCP to provide the features and quality of data transfer that applications require,

the protocol had to be enhanced beyond the simplified data transfer mechanism we saw in

preceding sections. Extra “smarts” needed to be given to the protocol to handle potential

problems, and changes to the basic way that devices send data were implemented to avoid

inefficiencies that might otherwise have resulted.

In this section I describe how TCP ensures that devices on a TCP connection communicate

in a reliable and efficient manner. I begin with an explanation of the basic method by which

TCP detects lost segments and retransmits them. I discuss some of the issues associated

with TCP's acknowledgment scheme and an optional feature for improving its efficiency. I

then describe the system by which TCP adjusts how long it will wait before deciding that a

segment is lost. I discuss how the window size can be adjusted to implement flow control,

and some of the issues involved in window size management. This includes a look at the

infamous “Silly Window Syndrome” problem, and special heuristics for addressing issues

related to small window size that modify the basic sliding windows scheme. I conclude with

a discussion of TCP's mechanisms for handling and avoiding congestion.

Background Information: This section assumes that you are already familiar with

TCP sequence numbers and segments, and the basics of the TCP sliding window

mechanism. It also assumes you have already read the section on TCP message

formatting and data transfer. If not, you may want to review at least the topic describing

TCP data transfer mechanics; several of the topics in this section extend that simplified

discussion of TCP data transfer to show what happens in non-ideal conditions.

TCP Segment Retransmission Timers and the Retransmission Queue

TCP's basic data transfer and acknowledgment mechanism uses a set of variables

maintained by each device to implement the sliding window acknowledgement system.

These pointers keep track of the bytes of data sent and received by each device, as well as

differentiating between acknowledged and unacknowledged transmissions. In the

preceding section I described this mechanism, and gave a simplified example showing how

a client and server uses them for basic data transfer.

One of the reasons why that example is simplified is that every segment that was trans-

mitted by the server was received by the client, and vice-versa. It would be nice if we could

always count on this happening, but as we know, in an Internet environment this is not

realistic. Due to any number of conditions, such as hardware failure, corruption of an IP

datagram or router congestion, a TCP segment may be sent but never received. To qualify

as a reliable transport protocol, TCP must be able detect lost segments and retransmit

them.

Managing Retransmissions Using the Retransmission Queue

The method for detecting lost segments and retransmitting them is conceptually simple.

Each time we send a segment, we start a retransmission timer. This timer starts at a prede-

termined value and counts down over time. If the timer expires before an acknowledgment

is received for the segment, we retransmit the segment.

TCP uses this basic technique but implements it in a slightly different way. The reason for

this is the need to efficiently deal with many segments that may be unacknowledged at

once, to ensure that they are each retransmitted at the appropriate time if needed. The TCP

system works according to the following specific sequence:

☯ Placement On Retransmission Queue, Timer Start: As soon as a segment

containing data is transmitted, a copy of the segment is placed in a data structure

called the retransmission queue. A retransmission timer is started for the segment

when it is placed on the queue. Thus, every segment is at some point placed in this

queue. The queue is kept sorted by the time remaining in the retransmission timer, so

the TCP software can keep track of which timers have the least time remaining before

they expire.

☯ Acknowledgment Processing: If an acknowledgment is received for a segment

before its timer expires, the segment is removed from the retransmission queue.

☯ Retransmission Timeout: If an acknowledgment is not received before the timer for

a segment expires, a retransmission timeout occurs, and the segment is automatically

retransmitted.

Of course, we have no more guarantee that a retransmitted segment will be received than

we had for the original segment. For this reason, after retransmitting a segment, it remains

on the retransmission queue. The retransmission timer is reset, and the countdown begins

again. Hopefully an acknowledgment will be received for the retransmission, but if not, the

segment will be retransmitted again and the process repeated.

Certain conditions may cause even repeated retransmissions of a segment to fail. We don't

want TCP to just keep retransmitting forever, so TCP will only retransmit a lost segment a

certain number of times before concluding that there is a problem and terminating the

connection.

Key Concept: To provide basic reliability for sent data, each device’s TCP imple-

mentation uses a retransmission queue. Each sent segment is placed on the queue

and a retransmission timer started for it. When an acknowledgment is received for

the data in the segment, it is removed from the retransmission queue. If the timer goes off

before an acknowledgment is received the segment is retransmitted and the timer

restarted.

Recognizing When a Segment is Fully Acknowledged

One issue we have yet to discuss is how we know when a segment has been fully acknowl-

edged. Retransmissions are handled on a segment basis, but TCP acknowledgments, as

we have seen, are done on a cumulative basis using sequence numbers. Each time a

segment is sent by Device A to Device B, B looks at the value of the Acknowledgment

Number field in the segment. All bytes with sequence numbers lower than the value of this

field have been received by A.

Thus, a segment sent by B to A is considered acknowledged when all of the bytes that were

sent in the segment have a lower sequence number than the latest Acknowledgment

Number sent by B to A. This is determined by calculating the last sequence number of the

segment using its first byte number (in the Sequence Number field) and length of the

segment’s Data field.

Key Concept: TCP uses a cumulative acknowledgment system. The Acknowl-

edgment Number field in a segment received by a device indicates that all bytes of

data with sequence numbers less than that value have been successfully received

by the other device. A segment is considered acknowledged when all of its bytes have been

acknowledged; in other words, when an Acknowledgment Number containing a value larger

than the sequence number of its last byte is received.

TCP Transaction Example with Retransmission

Let’s use an example to clarify how acknowledgments and retransmissions work in TCP

(illustrated in Figure 223, to which you may wish to refer as you read on). Suppose the

server in a connection sends out four contiguous segments (numbered starting with 1 for

clarity):

1. Segment #1: Sequence Number field is 1 and segment length is 80. So the last

sequence number in Segment #1 is 80.

2. Segment #2: Sequence Number field is 81 and segment length is 120. The last

sequence number in Segment #2 is 200.

3. Segment #3: Sequence Number field is 201 and segment length is 160. The last

sequence number in Segment #3 is 360.

4. Segment #4: Sequence Number field is 361 and segment length is 140. The last

sequence number in Segment #4 is 500.

Again, these can be sent one after the other without having to wait for each preceding

transmission to be acknowledged; this is a major benefit of TCP’s sliding window

mechanism.

Now let’s say the client receives the first two transmissions. It will send back an acknowl-

edgment with an Acknowledgment Number field value of 201. This tells the server that the

first two segments have been successfully received by the client; they will be removed from

the retransmission queue (and the server’s send window will slide 200 bytes to the right).

Segment #3 will remain on the retransmission queue until a segment with an Acknowl-

edgment Number field value of 361 or higher is received; Segment #4 requires an

acknowledgment value of 501 or greater.

Now, let’s further suppose in this example that Segment #3 gets lost in transit, but Segment

#4 is received. The client will store Segment #4 in its receive buffer, but will not be able to

acknowledge it, because of TCP’s cumulative acknowledgment system—acknowledging #4

would imply receipt of #3 as well, which never showed up. So the client will have to simply

wait for #3. Eventually, the retransmission timer that the server started for Segment #3 will

expire. The server will then retransmit Segment #3. It will be received by the client, which

will then be able to acknowledge both #3 and #4 to the server.

There’s another important issue here, however: how exactly the server should handle

Segment #4. While the client is waiting for the missing Segment #3, the server is receiving

no feedback; it doesn’t know that #3 is lost, and it also doesn’t know what happened to #4

(or any subsequent transmissions.) It is possible that the client has already received

Segment #4 but just couldn't acknowledge it. Then again, maybe Segment #4 got lost as

well. Some implementations may choose to only re-send Segment #3, while some may

choose to re-send both Segment #3 and Segment #4. This is an important issue that is

discussed in more detail in the next topic.

A final issue is what value we should use for the retransmission timer when we put a

segment on the retransmission queue. If it is set too low, excessive retransmissions occur;

if set too high, performance is reduced due to extraneous delays in re-sending lost

segments. In fact, TCP cannot use a single number for this value; it must determine it

dynamically using a process called adaptive retransmission.

TCP Non-Contiguous Acknowledgment Handling and Selective

Acknowledgment (SACK)

Computer science people sometimes use the term “elegant” to describe a simple but

effective solution to a problem or need. I think the term applies fairly well to the cumulative

acknowledgment method that is part of the TCP sliding window system. With a single

number, returned in the Acknowledgment Number field of a TCP segment, the device

sending the segment can acknowledge not just a single segment it has received from its

connection peer, but possibly several of them. We saw how this works in the topic on the

fundamentals of sliding windows, and again in the previous topic on retransmissions.

Figure 223: TCP Transaction Example With Retransmission

This diagram illustrates a simple transaction and shows the server’s send pointers and client’s receive

pointers. The server sends three segments to the client in rapid succession, setting a retransmission timer for

each. Parts 1 and 2 are received and the client sends an Acknowledgment for them; upon receipt of this ACK,

1 and 2 are taken off the retransmission queue. However, Part 3 is lost in transmit. When Part 4 is received,

the client cannot acknowledge it; this would imply receipt of the missing Part 3. Eventually the retransmission

timer for Part 3 expires and it is retransmitted, at which time both Part 3 and Part 4 are acknowledged.

Ack

Ack Num = 201

Client Server

1. Se nd Part 1

80 Bytes (1 to 80)

4. Receive First 2 Segments,

Send Acknowledgment

File Part 1

Seq Num = 1

6. Receive Ack For Reply

6. Receive Part 4 of File; Cannot

Send Acknowledgment

7. Receive Ack For Parts 1 & 2

8. Timeout For Part 3 -

Retransmit

9. Receive Part 3 of File,

Send Acknowledgment for 3 & 4

2. Se nd Part 2

120 Bytes (81 to 200)

3. Se nd Part 3

160 Bytes (201 to 360)

5. Se nd Part 4

140 Bytes (361 to 500)

RCV .WND = 560

RCV .NXT = 201

80 120

File Part 2

Seq Num = 81

File Part 3

Seq Num = 201

File Part 4

Seq Num = 361

RCV .NXT = 1

RCV .WND = 560

Usable = 560

SND.WND = 560

SND.UNA= 1

File Part 3

Seq Num = 201

RCV .WND = 560

RCV .NXT = 501

80 120 140160

...

Ack

Ack Num = 501

10. Receive Ack for Parts 3 & 4

Usable = 260

SND.NXT = 501

SND.WND = 560

140160

SND.UNA= 201

80 120

Usable = 60

SND.NXT = 501

SND.WND = 560

80 120 140160

SND.UNA= 1

RCV .WND = 560

RCV .NXT = 201

80 120 140???

Usable = 500

SND.NXT = 501

SND.WND = 560

SND.UNA= 501

80 120 140160

...