Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
TCP Sliding Window Data Transfer and Acknowledgement Mechanics
(Page 5 of 6)
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 wont 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 159
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.
J 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 159,
but each from the perspective of one of the devices. Figure 221
shows the servers send pointers and clients receive pointers;
Figure 222
shows the clients send pointers and servers receive pointers.
(I would have put them all in one diagram but it wouldnt fit!)
Table 159: TCP Transaction Example With Send and Receive Pointers
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 incremented 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
& Reply
|
241
|
321
|
200
|
141
|
360
|
At this
point the client hasn't received an acknowledgment 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 acknowledgment.
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 acknowledging 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 TCPs ability
to ensure high throughput.
|
5. Receive Part 1 of File,
Send Ack
|
141
|
141
|
360
|
441
|
200
|
|
6. Receive Ack for Reply
|
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.
|
(still waiting J)
|
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 acknowledges 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 acknowledgment 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.
|
Figure 221: TCP Transaction Example Showing Servers Send Pointers The transaction of Table 159 from the perspective of the server. See Figure 222 for the clients pointers.
|
|