Charles M. Kozierok The TCP-IP Guide

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

Key Concept: Devices can indicate that they wish to use a different MSS value from

the default by including a ©Maximum Segment Size option in the SYN message they

use to establish a connection. Each device in the connection may use a different

MSS value.

TCP Sliding Window Data Transfer and Acknowledgement Mechanics

The TCP connection establishment process is employed by a pair of devices to create a

TCP connection between them. Once all the setup is done, transmission control blocks

(TCBs) set up, parameters have been exchanged and so forth, the devices are ready to get

down to business: transferring data.

The sending of data between TCP devices on a connection is accomplished using the

sliding window system we explored in the fundamentals section. It's now time to take a

more detailed look at exactly how sliding windows are implemented to allow data to be sent

and received. For ease of explanation, we'll assume that our connection is between a client

and a server—this is easier than the whole “Device A / Device B” thing.

Sliding Window Transmit Categories

Each of the two devices on a connection must keep track of the data it is sending, as well as

the data it is receiving from the other device. This is done by conceptually dividing the bytes

into the categories we saw in the sliding windows overview. For data being transmitted,

there are four transmit categories:

1. Transmit Category #1: Bytes Sent And Acknowledged

2. Transmit Category #2: Bytes Sent But Not Yet Acknowledged

3. Transmit Category #3: Bytes Not Yet Sent For Which Recipient Is Ready

4. Transmit Category #4: Bytes Not Yet Sent For Which Recipient Is Not Ready

Sliding Window Receive Categories

For data being received, there is no need to separate into “received and acknowledged”

and “received and unacknowledged” the way the transmitter separates its first two

categories into “sent and acknowledged” and “sent but not yet acknowledged. The reason,

of course, is that the transmitter must wait for acknowledgment of each transmission, while

the receiver doesn’t need “acknowledgment” that it received something.

Thus, one receive category corresponds to Transmit Categories #1 and #2, while the other

two correspond to Transmit Category #3 and Transmit Category #4 respectively, making

three receive categories overall. To help make more clear how the categories relate, I am

numbering them as follows:

☯ Receive Category #1+2: Bytes Received And Acknowledged. This is the receiver’s

complement to Transmit Categories #1 and #2.

☯ Receive Category #3: Bytes Not Yet Received For Which Recipient Is Ready. This is

the receiver’s complement to Transmit Category #3.

☯ Receive Category #4: Bytes Not Yet Received For Which Recipient Is Not Ready.

This is the receiver’s complement to Transmit Category #4.

Send (SND) Pointers

Both the client and server in the connection must keep track of the stream it is transmitting

and the one it is receiving from the other device. This is done using a set of special

variables called pointers, that carve the byte stream into the categories above. The four

transmit categories are divided using three pointers. Two of the pointers are absolute (refer

to a specific sequence number) while one is an offset that is added to one of the absolute

pointers, as follows (refer to Figure 219):

☯ Send Unacknowledged (SND.UNA): The sequence number of the first byte of data

that has been sent but not yet acknowledged. This marks the first byte of Transmit

Category #2; all previous sequence numbers refer to bytes in Transmit Category #1.

☯ Send Next (SND.NXT): The sequence number of the next byte of data to be sent to

the other device (the server in this case). This marks the first byte of Transmit

Category #3.

☯ Send Window (SND.WND): The size of the send window. Recall that the window

specifies the total number of bytes that any device may have “outstanding”

(unacknowledged) at any one time. Thus, adding the sequence number of the first

unacknowledged byte (SND.UNA) and the send window (SND.WND) marks the first

byte of Transmit Category #4.

Another way of looking at these pointers is how they indicate the number of bytes a trans-

mitting device can send at any point in time; that is, the number of bytes in Transmit

Category #3. The start of Transmit Category #3 is marked by SND.NXT. The end is marked

by the first byte of Transmit Category #4, given by SND.UNA+SND.WND. Thus, the number

of bytes in Transmit Category #3 is given by the following formula:

SND.UNA + SND.WND - SND.NXT

This is called the usable window, since it indicates how many bytes the transmitter can use

at any point in time. When data is acknowledged, this causes bytes to move from Transmit

Category #2 to Category #1, by increasing the value of SND.UNA. Assuming that the send

window size doesn't change, this causes the window to slide to the right, permitting more

data to be sent.

Key Concept: The TCP sliding windows scheme uses three pointers that keep track

of which bytes are in each of the four transmit categories. SND.UNA points to the

first unacknowledged byte and indicates the start of Transmit Category #2; SND.NXT

points to the next byte of data to be sent and marks the start of Transmit Category #3.

SND.WND contains the size of the send window; it is added to SND.NXT to mark the start

of Transmit Category #4. Adding SND.WND to SND.UNA and then subtracting SND.NXT

yields the current size of the usable transmit window.

Receive (RCV) Pointers

The three receive categories are divided using two pointers:

☯ Receive Next (RCV.NXT): The sequence number of the next byte of data that is

expected from the other device. This marks the first byte in Receive Category #3. All

previous sequence numbers refer to bytes already received and acknowledged, in

Receive Category #1+2.

Figure 219: TCP Transmission Categories, Send Window and Pointers

This diagram is the same as Figure 207, but shows the TCP send pointers. SND.UNA points to the start of

Transmit Category #2, SND.NXT points to the start of Transmit Category #3, and SND.WND is the size of the

send window. The size of the usable window can be calculated as shown from those three pointers.

31 46 47 48 49 50 51 52 53 54 5530

...

29 56 57

...

Category #1 Category #2 Category #3 Category #4

Sent and

Acknowledged

(31 bytes)

Not Sent,

Recipient Ready

To Receive

Not Sent, Recipient

Not

Ready To Receive

(44 bytes)

Left Edge of

Send Window

Right Edge of

Send Window

32 33 34 35 36 37 38 39 40 41 42 43 44 45

Send Window

SND.WND = 20

Usable Window Size

= SND.UNA + SND.WND - SND.NXT

= 32 + 20 - 46 = 6

Sent But Not Yet Acknowledged

(Sent and Still Outstanding)

Send Unacknowledged

Pointer

SND.UNA = 32

Send Next

Pointer

SND.NXT = 46

☯ Receive Window (RCV.WND): The size of the receive window “advertised” to the

other device. This refers to the number of bytes the device is willing to accept at one

time from its peer, which is usually the size of the buffer allocated for receiving data for

this connection. When added to the RCV.NXT pointer, marks the first byte of Receive

Category #4.

The receive categories and pointers are illustrated in Figure 220.

Key Concept: A set of receive pointers are maintained by each device, which are

the complement of the send pointers. A device’s send pointers keep track of its

outgoing data and its receive pointers the incoming data. The two receive pointers

are RCV.NXT, which indicates the number of the next byte of data expected from the other

device, and RCV.WND, which is the size of the receive window for that device. The

RCV.WND of one device equals the SND.WND of the other device on the connection.

Figure 220: TCP Receive Categories and Pointers

This diagram is the complement of Figure 219, showing how the categories are set up for the receiving

device. Categories #1 and #2 have been combined since there is no differentiation between “received and

unacknowledged” and “received and acknowledged”. This example shows the state of the receiving device

prior to receipt of the 14 bytes that in Figure 219 have already been sent.

31 46 47 48 49 50 51 52 53 54 5530

...

29 56 57

...

Category #1+2 Category #3 Category #4

Received and

Acknowledged

(31 bytes)

Not Yet Received, Transmitter Permitted To Send

(20 bytes)

Not Yet Received,

Transmitter May

Not

Send (44 bytes)

Left Edge of

Receive Window

Right Edge of

Receive Window

32 33 34 35 36 37 38 39 40 41 42 43 44 45

Receive Window

RCV.WND = 20

Receive Next

Pointer

RCV.NXT = 32

The Relationship Between Send and Receive Pointers

The SND and RCV pointers are complementary, of course, just as the categories are, with

each device managing both the sending of its data and receiving of data from its peer.

Assuming we have a client and a server, then:

☯ Client: The SND pointers keep track of the client's outgoing data stream; the RCV

pointers refer to the data coming in from the server. The client’s SND categories corre-

spond to the server’s RCV categories.

☯ Server: The SND pointers keep track of the server's outgoing data stream; the RCV

pointers refer to the data being received from the client. The server’s SND categories

correspond to the client’s RCV categories.

TCP Segment Fields Used to Exchange Pointer Information

Since the SND and RCV values are complementary, the send window of one device is the

receive window of the other, and vice-versa. Note, however, that the values of the pointers

do not always line up exactly between the two devices, because at any given time, some

bytes may be in transit between the two. Figure 220, for example, shows the receive

pointers of the recipient prior to receiving bytes 32 to 45, which are shown in transit in

Figure 219.

Both SND and RCV pointers are all maintained in the transmission control block (TCB) for

the connection held by each device. As data is exchanged the pointers are updated, and

communication about the state of the send and receive streams is exchanged using control

fields in the TCP segment format. The three most important ones are:

☯ Sequence Number: Identifies the sequence number of the first byte of data in the

segment being transmitted. This will normally be equal to the value of the SND.UNA

pointer at the time that data is sent.

☯ Acknowledgment Number: Acknowledges the receipt of data by specifying the

sequence number that the sender of the segment expects in the segment recipient's

next transmission. This field will normally be equal to the RCV.NXT pointer of the

device that sends it.

☯ Window: The size of the receive window of the device sending the segment (and thus,

the send window of the device receiving the segment.)

The Acknowledgment Number field is critical because this is what a device uses to tell its

peer what segments it has received. The system is cumulative: the Acknowledgment

Number field says “I have received all data bytes with sequence numbers less than this

value”. This means if a client receives many segments of data from a server in rapid

succession, it can acknowledge all of them using a single number, as long as they are

contiguous. If they are not contiguous, then things get more complicated.

Key Concept: Three essential fields in the TCP segment format are used to

implement the sliding windows system. The Sequence Number field indicates the

number of the first byte of data being transmitted. The Acknowledgment Number is

used to acknowledge data received by the device sending this segment. The Window field

tells the recipient of the segment the size to which it should set its send window.

Example Illustration of TCP Sliding Window Mechanics

To see how all of this works, let's consider the example of a client and server using a

mythical file retrieval protocol. This protocol specifies that the client sends a request and

receives an immediate response from the server. The server then sends the file requested

when it is ready.

The two devices will of course first establish a connection and synchronize sequence

numbers. For simplicity, let's say the client uses an initial sequence number (ISN) of 0, and

the server an ISN of 240. The server will send the client an ACK with an Acknowledgement

Number of 1, indicating it is the sequence number it expects to receive next. Let's say the

server's receive window size is set to 350, so this is the client's send window size. The

client will send its ACK with an Acknowledgment Number of 241. Let's say its receive

window size is 200 (and the server's client window size is thus 200). Let's assume that both

devices maintain the same window size throughout the transaction. This won't normally

happen, especially if the devices are busy, but the example is complicated enough. Let's

also say the maximum segment size is 536 bytes in both directions. This means that the

MSS won’t affect the size of actual segments in this example (since the MSS is larger than

the send window sizes for both devices.)

With the background for our example established, we can now follow a sample transaction

to show in detail how the send and receive pointers are created and changed as messages

are exchanged between client and server. Table 160 describes the process in detail,

showing for each step what the send and receive pointers are for both devices. It is rather

large, so beware. ☺ The transaction is also graphically illustrated in two figures: Figure 221

and Figure 222. Both illustrate the same exchange of messages, using the step numbers of

Table 160, but each from the perspective of one of the devices. Figure 221 shows the

server’s send pointers and client’s receive pointers; Figure 222 shows the client’s send

pointers and server’s receive pointers. (I would have put them all in one diagram but it

wouldn’t fit!)

Table 160: TCP Transaction Example With Send and Receive Pointers (Page 1 of 3)

Client Server

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Description Description

(setup) 1 1 360 241 200 (setup) 241 241 200 1 360

During connection establishment, the client sets up

its pointers based on the parameters exchanged

during setup. Notice that the SND.UNA and

SND.NXT values are the same — no data has been

sent yet so nothing is unacknowledged. RCV.NXT is

the value of the first byte of data expected from the

server.

The server sets up its pointers just as the client

does. Notice how its values are the complement of

the client's.

1. Send

Request

1 141 360 241 200 (wait) 241 241 200 1 360

The client transmits a request to the server. Let's say

the request is 140 bytes in length. It will form a

segment with a data field of this length and transmit

it with the Sequence Number set to 1, the sequence

number of the first byte. Once this data has been

sent, the client's SND.NXT pointer will be incre-

mented to the value 141 to indicate this is the next

data to be sent to the server.

The server does nothing, waiting for a request.

(wait) 1 141 360 241 200

2. Receive

Request,

Send Ack &

241 321 200 141 360

At this point the client hasn't received an acknowl-

edgment for its request. At present,

SND.UNA+SND.WND is 361, while SND.NXT is

141. This means the current usable window is 220

bytes. The the client could send up to 220 more

bytes of data before getting back an acknowl-

edgment. For now, let's say it has nothing more to

transmit.

The server receives the 140-byte request from the

client. The server sends back an 80-byte response

that also acknowledges the client's TCP segment.

The Sequence Number field will be 241, the first

sequence number of the server's 80 bytes of data.

The Acknowledgment Number will be 141, telling the

client that is the next sequence number the server

expects to hear, and thereby implicitly acknowl-

edging receipt of bytes 1 through 140.

The server increases its RCV.NXT pointer to 141 to

reflect the 140 bytes of data received. It increases its

SND.NXT pointer by 80.

3. Receive

Ack &

Reply, Send

Ack

141 141 360 321 200

4. Send Part

1 of File

241 441 200 141 360

The client receives the server's response. It sees the

Acknowledgment Number of 141 and knows bytes 1

to 140 were successfully received. It increases its

SND.UNA to 141, effectively “sliding the send

window” by 140.

The client also accepts the 80 bytes of data the

server sent, increasing its RCV.NXT pointer by 80.

Assuming it has no more data to sent, it sends back

a TCP segment that is a pure acknowledgment of

the server's response. This segment has no data,

and an Acknowledgment Number value of 321.

While the client was receiving its response, the

server's TCP was supplied with a 280 byte file to be

sent to the client. It cannot send this all in one

segment however. The current value of

SND.UNA+SND.WND is 441, while SND.NXT is

321. Thus, the server's usable window contains 120

bytes of data. It creates a TCP segment with this

much data and a Sequence Number of 321. It

increases the SND.NXT pointer to 441. The server

has now filled the send window.

Note that the server does not have to wait for an

acknowledgement to the reply it sent in step #2. This

is a key factor in TCP’s ability to ensure high

throughput.

5. Receive

Part 1 of

File, Send

Ack

141 141 360 441 200

6. Receive

Ack for

321 441 200 141 360

The client receives the first 120-byte part of the file

the server was sending. It increases the RCV.NXT

pointer to 441 and sends an acknowledgment back

with an Acknowledgment Number of 441. Again, if it

had another request to make of the server it could

include it here, but we'll assume it does not.

The server receives the client's acknowledgment of

its earlier 80-byte response (sent in step #2). It

increases its SND.UNA to 321. Since it just received

acknowledgment of 80 bytes (and the client's

window didn't change), the server's usable window

is now 80 bytes. However, as we will see in the

section on TCP performance, sending small

segments like this can lead to performance issues.

Let's say the server has been programmed to not

send segments under 100 bytes when it has a lot of

data to transmit. It decides to wait.

(wait) 141 141 360 441 200

7. Receive

Ack for Part

1 of File

441 441 200 141 360

The client waits for the rest of the file. The server receives the acknowledgment for the first

part of the file. It increases SND.UNA to 441. This

now restores the full 200 byte window.

Table 160: TCP Transaction Example With Send and Receive Pointers (Page 2 of 3)

Client Server

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Description Description

(still waiting

☺)

141 141 360 441 200

8. Send Part

2 of File

441 601 200 141 360

The client continues to wait for the rest of the file. The server sends the remaining 160 bytes of data in

the file in one segment. It increases SND.NXT by

160, and sends the data with a Sequence Number

value of 441.

9. Receive

Part 2 of

File, Send

Ack

141 141 360 601 200 (wait) 441 601 200 141 360

The client receives the rest of the file and acknowl-

edges it. It increases RCV.NXT to 601 and sends

back a segment with an Acknowledgment Number

of 601.

The server is done for now; it waits for the acknowl-

edgment of the second part of the file.

(done) 141 141 360 601 200

10. Receive

Ack for Part

2 of File

601 601 200 141 360

The client is done with this exchange. The server receives the second acknowledgment

and slides its send window forward by 160 bytes.

The transaction is now completed.

Table 160: TCP Transaction Example With Send and Receive Pointers (Page 3 of 3)

Client Server

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Process

Step

SND.

UNA

SND.

NXT

SND.

WND

RCV.

NXT

RCV.

WND

Description Description

Figure 221: TCP Transaction Example Showing Server’s Send Pointers

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

Client Server

1. Send Request

2. Receive Request, Send

Combined Ack & Reply

3. Receive Combined Ack &

Reply, Send Acknowledgment

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

SND.UNA = 241

SND.NXT = 321

Usable = 120

SND.WND = 200

SND.UNA = 241

SND.NXT = 441

Usable = 0

SND.WND = 200

80 120

SND.UNA = 321

SND.NXT = 441

Usable = 80

SND.WND = 200

80 120

SND.UNA = 441

SND.NXT = 441

Usable = 200

SND.WND = 200

80 120

SND.UNA = 441

SND.NXT = 601

Usable = 40

SND.WND = 200

80 120 160

Usable = 200

SND.WND = 200

80 120 160

SND.NXT = 601

SND.UNA = 601

Usable = 200

SND.UNA = 241

SND.NXT = 241

SND.WND = 200

RCV .NXT = 601

80 120 160

RCV .WND = 200

RCV .NXT = 441

RCV .WND = 200

80 120

RCV .NXT = 321

RCV .WND = 200

RCV .NXT = 241

RCV .WND = 200

Acknowledgment

Ack Num = 601

Acknowledgment

Ack Num = 321