Charles M. Kozierok The TCP-IP Guide

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

Key Concept: TCP includes a special connection reset feature to allow devices to

deal with problem situations, such as half-open connections or the receipt of

unexpected message types. To use the feature, the device detecting the problem

sends a TCP segment with the RST (reset) flag set to 1. The receiving device either returns

to the LISTEN state, if it was in the process of connection establishment, or closes the

connection and returns to the CLOSED state pending a new session negotiation.

Idle Connection Management and "Keepalive" Messages

One final connection management issue in TCP is how to handle an idle connection; that is,

a TCP session that is active but that has no data being transmitted by either device for a

prolonged period of time. The TCP standard specifies that the appropriate action to take in

this situation is… nothing. The reason is that, strictly speaking, there is no need to do

anything to maintain an idle connection in TCP. The protocol is perfectly happy to allow both

devices to stop transmitting for a very long period of time, and then simply resume transmis-

sions of data and acknowledgment segments when either has data to send.

However, just as many people become “antsy” when they are on a telephone call and they

don’t hear anything for a long while, there was concern on the part of some TCP imple-

mentors that a TCP connection that was idle for a very long while might mean that the

connection had been broken.

Thus, TCP software often includes an “unofficial” feature that allows a device with a TCP

link to periodically send a null segment containing no data to its peer on the connection. If

the connection is still valid, the other device responds with a segment containing an

acknowledgment; if it is not, the other device will reply with a connection reset segment as

described above. These segments sometimes called TCP “keepalive” messages, or just

“keepalives”. They are analogous to BGP Keepalive messages.

The use of these messages is quite controversial, and therefore, not universal. Those who

are opposed to them argue that they are not really necessary, and that sending them repre-

sents a waste of internetwork bandwidth and a possible additional cost on metered links

(those that charge for each datagram sent.) Their key point is that if the connection is not

presently being used, it doesn’t matter if it is still valid or not; as soon as the connection is

used again, if it has broken in the mean time, TCP can handle that using the reset function

mentioned above.

Worse, sending a “keepalive” can in theory cause a good TCP session to be unnecessarily

broken. This may happen if the “keepalive” is sent during a time when there is an inter-

mittent failure between the client and server, a failure that might otherwise have corrected

itself by the time the next piece of “real” data must be sent. In addition, some TCP imple-

mentations may not properly deal with the receipt of these segments.

Those in favor of using “keepalives” point out that each TCP connection consumes a certain

amount of resources, and this can be an issue especially for busy servers. If many clients

connect to such a server and don’t terminate the TCP connection properly, the server may

sit for a long time with an idle connection, using system memory and other resources that

could be applied elsewhere.

Since there is no wide acceptance on the use of this feature, devices implementing it

include a way to disable it if necessary. Devices are also programmed so they will not

terminate a connection simply as a result of not receiving a response to a single

“keepalive”. They may do so if they do not receive a reply after several such messages

have been sent over a period of time.

TCP Connection Termination

As the saying goes, “all good things must come to an end”… and so it is with TCP connec-

tions. The link between a pair of devices can remain open for a considerable period of time,

assuming that a problem doesn't force the connection to be aborted. Eventually, however,

one or both of the processes in the connection will run out of data to send and will shut

down the TCP session, or will be instructed by the user to do so.

Requirements and Issues In Connection Termination

Just as TCP follows an ordered sequence of operations to establish a connection, it

includes a specific procedure for terminating a connection. As with connection estab-

lishment, each of the devices moves from one state to the next to terminate the connection.

This process is more complicated than one might imagine it needs to be. In fact, an exami-

nation of the TCP finite state machine shows that there are more distinct states involved in

shutting down a connection than in setting one up.

The reason that connection termination is complex is that during normal operation, both of

the devices are sending and receiving data simultaneously. Usually, connection termination

begins with the process on just one device indicating to TCP that it wants to close the

connection. The matching process on the other device may not be aware that its peer wants

to end the connection at all. Several steps are required to ensure that the connection is shut

down gracefully by both devices, and that no data is lost in the process.

Ultimately, shut down of a TCP connection requires that the application processes on both

ends of the connection recognize that “the end is nigh” for the connection and stop sending

data. For this reason, connection termination is implemented so that each device termi-

nates its end of the connection separately. The act of closing the connection by one device

means that device will no longer send data, but can continue to receive it until the other

device has decided to stop sending. This allows all data that is pending to be sent by both

sides of the communication to be flushed before the connection is ended.

Normal Connection Termination

In the normal case, each side terminates its end of the connection by sending a special

message with the FIN (finish) bit set. This message, sometimes called a FIN, serves as a

connection termination request to the other device, while also possibly carrying data like a

regular segment. The device receiving the FIN responds with an acknowledgment to the

FIN to indicate that it was received. The connection as a whole is not considered terminated

until both sides have finished the shut down procedure by sending a FIN and receiving an

ACK.

Thus, termination isn't a three-way handshake like establishment: it is a pair of two-way

handshakes. The states that the two devices in the connection move through during a

normal connection shutdown are different because the device initiating the shutdown must

behave differently than the one that receives the termination request. In particular, the TCP

on the device receiving the initial termination request must inform its application process

and wait for a signal that the process is ready to proceed. The initiating device doesn't need

to do this, since the application is what started the ball rolling in the first place.

Key Concept: A TCP connection is normally terminating using a special procedure

where each side independently closes its end of the link. It normally begins with one

of the application processes signalling to its TCP layer that the session is no longer

needed. That device sends a FIN message to tell the other device that it wants to end the

connection, which is acknowledged. When the responding device is ready, it too sends a

FIN that is acknowledged; after waiting a period of time for the ACK to be received, the

session is closed.

Table 155 describes in detail how the connection termination process works; the

progression of states and messages exchanged can also be seen in Figure 214. The table

is adapted from Table 152, describing the TCP finite state machine, but shows what

happens for both the server and the client over time during connection shutdown. Either

device can initiate connection termination; in this example I am assuming the client does it.

Each row shows the state each device begins in, what action it takes in that state and what

state to which it transitions. I have also shown the send and receive stages of both of the

steps for each of the client and server’s close operations.

Table 155: TCP Connection Termination Procedure

Client Server

Start

State

Action

Transi-

tions To

State

Start

State

Action

Transi-

tions To

State

ESTAB-

LISHED

Client Close Step #1

Transmit: The application

using TCP signals that the

connection is no longer

needed. The client TCP

sends a segment with the

FIN bit set to request that

the connection be closed.

FIN-

WAIT-1

ESTAB-

LISHED

At this stage the server is

still in normal operating

mode.

—

FIN-

WAIT-1

The client, having sent a

FIN, is waiting for it to both

be acknowledged and for

the serve to send its own

FIN. In this state the client

can still receive data from

the server but will no longer

accept data from its local

application to be sent to the

server.

—

ESTAB-

LISHED

Client Close Step #1

Receive and Step #2

Transmit: The server

receives the client's FIN. It

sends an ACK to

acknowledge the FIN. The

server must wait for the

application using it to be told

the other end is closing, so

the application here can

finish what it is doing.

CLOSE-

WAIT

FIN-

WAIT-1

Client Close Step #2

Receive: The client

receives the ACK for its

FIN. It must now wait for the

server to close.

FIN-

WAIT-2

CLOSE-

WAIT

The server waits for the

application process on its

end to signal that it is ready

to close.

—

FIN-

WAIT-2

The client is waiting for the

server's FIN.

—

CLOSE-

WAIT

Server Close Step #1

Transmit: The server's TCP

receives notice from the

local application that it is

done. The server sends its

FIN to the client.

LAST-

ACK

FIN-

WAIT-2

Server Close Step #1

Receive and Step #2

Transmit: The client

receives the server's FIN

and sends back an ACK.

TIME-

WAIT

LAST-

ACK

The server is waiting for an

ACK for the FIN it sent.

—

TIME-

WAIT

The client waits for a period

of time equal to double the

maximum segment life

(MSL) time, to ensure the

ACK it sent was received.

—

LAST-

ACK

Server Close Step #2

Receive: The server

receives the ACK to its FIN

and closes the connection.

CLOSED

TIME-

WAIT

The timer expires after

double the MSL time.

CLOSED CLOSED

The connection is closed on

the server's end.

CLOSED The connection is closed. CLOSED The connection is closed.

The TIME-WAIT State

The device receiving the initial FIN may have to wait a fairly long time (in networking terms)

in the CLOSE-WAIT state for the application it is serving to indicate that it is ready to shut

down. TCP cannot make any assumptions about how long this will take. During this period

of time, the server in our example above may continue sending data, and the client will

receive it. However, the client will not send data to the server.

Figure 214: TCP Connection Termination Procedure

This diagram shows the conventional termination procedure for a TCP session, with one device initiating

termination and the other responding. In this case the client initiates; it sends a FIN which is acknowledged by

the server. The server waits for the server process to be ready to close and then sends its FIN, which is

acknowledged by the client. The client waits for a period of time to ensure that its ACK is received, before

proceeding to the CLOSED state.

Client Server

Receive Close

Signal From App,

Send FIN

FIN

ACK

App Is Ready To

Close, Send FIN

Receive FIN,

Send ACK

Client State

Wait for ACK and

FIN From Server

FIN-WAIT-1

CLOSED

Server State

Normal Operation

CLOSE-WAIT

Receive FIN,

Send ACK,

Tell App To Close

LAST-ACK

Wait for Server FIN

TIME-WAIT

Wait for ACK

to FIN

Receive ACK

EST ABLISHED EST ABLISHED

Receive ACK

FIN-WAIT-2

FIN

ACK

Wait For Double

M aximum Se gment

Life (MSL) Time

CLOSED

(Wait for App)

Eventually, the second device (the server in our example) will send a FIN to close its end of

the connection. The device that originally initiated the close (the client above) will send an

ACK for this FIN. However, the client cannot immediately go to the CLOSED state right after

sending that ACK. The reason is that it must allow time for the ACK to travel to the server.

Normally this will be quick, but delays might result in it being slowed down somewhat.

The TIME-WAIT state is required for two main reasons. The first is to provide enough time

to ensure that the ACK is received by the other device, and to retransmit it if it is lost. The

second is to provide a “buffering period” between the end of this connection and any subse-

quent ones. If not for this period, it is possible that packets from different connections could

be mixed, creating confusion.

The standard specifies that the client should wait double a particular length of time called

the maximum segment lifetime (MSL) before finishing the close of the connection. The TCP

standard defines MSL as being a value of 120 seconds (2 minutes). In modern networks

this is an eternity, so TCP allows implementations to choose a lower value if it is believed

that will lead to better operation.

Simultaneous Connection Termination

Just as it is possible for the normal connection establishment process to be changed if two

devices decide to actively OPEN a connection to each other, it is also possible for two

devices to try to terminate a connection simultaneously. This term “simultaneously” doesn't

mean that they both decide to shut down at exactly the same time—variances in network

delays mean nothing can be simultaneous on an internetwork anyway. It simply means that,

in the example above, the client decides to shut down and sends a FIN, but the server

sends its own FIN before the client's FIN shows up at the server. In that case, a different

procedure is followed, as described in Table 156 and Figure 215.

As you can see, the process is much more symmetric in this case, with both devices transi-

tioning through the same states. In either case the end result is the same, with the

connection in the CLOSED state—meaning no connection. Each TCP will make sure all

outstanding data is sent to the application, sometimes referred to as an implied “push” (see

the description of the “push” function for an explanation of this term). The transmission

control blocks (TCBs) established for the connection in both devices are destroyed when

the connection is closed down.

Table 156: TCP Simultaneous Connection Termination Procedure

Client Server

Start

State

Action

Transi-

tions To

State

Start

State

Action

Transi-

tions To

State

ESTAB-

LISHED

Client Close Step #1

Transmit: The application

using TCP signals that the

connection is no longer

needed. The TCP on the

client sends the next

segment with the FIN bit

set, indicating a request to

close the connection.

FIN-

WAIT-1

ESTAB-

LISHED

Server Close Step #1

Transmit: Before the server

can receive the FIN sent by

the client, the application on

the server also signals a

close. The server also

sends a FIN.

FIN-

WAIT-1

FIN-

WAIT-1

Server Close Step #1

Receive and Step #2

Transmit: The client has

sent a FIN and is waiting for

it to be acknowledged.

Instead, it receives the FIN

sent by the server. It

acknowledges the server's

close request with an ACK

and continues to wait for its

own ACK.

CLOSING

FIN-

WAIT-1

Client Close Step #1

Receive and Step #2

Transmit: The server has

sent a FIN and is waiting for

it to be acknowledged.

Instead, it receives the FIN

sent by the client. It

acknowledges the client's

close request with an ACK

and continues to wait for its

own ACK.

CLOSING

Client Close Step #2

Receive: The client

receives the ACK for its

FIN.

TIME-

WAIT

CLOSING

Server Close Step #2

Receive: The server

receives the ACK for its FIN.

TIME-

WAIT

TIME-

WAIT

The client waits for a period

of time equal to double the

maximum segment life

(MSL) time. This gives

enough time to ensure the

ACK it sent to the server

was received.

—

TIME-

WAIT

The server waits for a period

of time equal to double the

maximum segment life

(MSL) time. This gives

enough time to ensure the

ACK it sent to the client was

received.

—

TIME-

WAIT

The timer expires after

double the MSL time.

CLOSED

TIME-

WAIT

The timer expires after

double the MSL time.

CLOSED

CLOSED The connection is closed. — CLOSED The connection is closed. —

Key Concept: Just as two devices can simultaneously open a TCP session, they

can terminate it simultaneously as well. In this case a different state sequence is

followed, with each device responding to the other’s FIN with an ACK, waiting for

receipt of its own ACK, and pausing for a period of time to ensure that its ACK is received

by the other device before ending the connection.

Figure 215: TCP Simultaneous Connection Termination Procedure

Under certain circumstances both devices may decide to terminate a connection simultaneously, or nearly

simultaneously. In this case each sends a FIN and before getting an ACK for it, receives the other device’s

FIN. Each acknowledges the other’s FIN and waits for a period of time before closing the connection. Note the

transition through the CLOSING state, which is only used as part of simultaneous termination.

Client Server

Receive Close

Signal From App,

Send FIN

Receive FIN From

Client, Send ACK

Client State

Receive FIN From

Server, Send ACK

FIN-WAIT-1

CLOSED

Server State

CLOSING

Receive Close

Signal From App,

Send FIN

TIME-WAIT

Receive ACK

EST ABLISHED EST ABLISHED

Receive ACK

CLOSING

Wait For Double

M aximum Se gment

Life (MSL) Time

CLOSED

FIN-WAIT-1

Wait For Double

M aximum Se gment

Life (MSL) Time

TIME-WAIT

FIN

ACK

FIN

ACK

TCP Message Formatting and Data Transfer

The previous section described how two devices using the Transmission Control Protocol

establish a TCP connection, as well as how that connection is managed and eventually

terminated. While connections are a key part of how TCP works, they are really a means to

the ultimate end of the protocol: sending data. Employing the TCP sliding window

mechanism, a special segment format and several features, TCP devices are able to

package and send data over the connection, enabling applications to communicate.

In this section, I describe the actual mechanism by which TCP messages are formatted and

data is transferred between devices. I begin with a look at the important TCP segment

format, which describes the fields in each TCP message and how they are used. I provide a

description of the method used to calculate the checksum in TCP (as well as UDP)

messages, and the reason why a special “pseudo header” is used. I discuss the Maximum

Segment Size (MSS) parameter and its significance. I then talk about exactly how the

sliding window mechanism is used to transfer and acknowledge data. I conclude with a

description of two special data transfer features: the “push” feature for immediate data

transfer, and the “urgent” feature for priority data transfer.

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

TCP concepts such as sequence numbers, segments, and the basics of the TCP

sliding window mechanism. If you are not, I’d strongly recommend reading the TCP

fundamentals section before proceeding here.

TCP Message (Segment) Format

In the TCP fundamentals section, I described one of the most interesting jobs that TCP

performs: it allows an application to send data as an unstructured sequence of bytes, trans-

parently packaging that data in distinct messages as required by the underlying protocol

that TCP uses (normally the Internet Protocol, of course). TCP messages are called

segments, the name referring to the fact that each segment is a portion of the overall data

stream passing between the devices.

Roles Performed by TCP Segments

TCP segments are very much “jack of all trade” messages—they are flexible and serve a

variety of purposes. A single field format is used for all segments, with a number of header

fields that implement the many functions and features for which TCP is responsible. One of

the most notable characteristics of TCP segments is that they are designed to carry both

control information and data simultaneously. This reduces the number of segments sent,

since they can perform more than one function.

For example, there is no need to send separate acknowledgments in TCP because each

TCP message includes a field for an acknowledgment byte number. Similarly, one can

request that a connection be closed while sending data in the same message. The nature of

each TCP segment is indicated through the use of several special control bits. More than

one bit can be sent to allow a segment to perform multiple functions, such as when a bit is

used to specify an initial sequence number and acknowledge receipt of another such

segment at the same time.

TCP Header Field Functions

The price we pay for this flexibility is that the TCP header is large: 20 bytes for regular

segments and more for those carrying options. This is one of the reasons why some

protocols prefer to use UDP if they don't need TCP's features. The TCP header fields are

used for the following general purposes:

☯ Process Addressing: The processes on the source and destination devices are

identified using port numbers.

☯ Sliding Window System Implementation: Sequence numbers, acknowledgment

numbers and window size fields implement the TCP sliding window system.

☯ Control Bits and Fields: Special bits that implement various control functions, and

fields that carry pointers and other data needed for them.

☯ Carrying Data: The Data field carries the actual bytes of data being sent between

devices.

☯ Miscellaneous Functions: A checksum for data protection and options for

connection setup.

TCP Segment Format

The format for TCP messages (segments) is described fully in Table 157 and Figure 216.

Table 157: TCP Segment Format (Page 1 of 3)

Field Name

Size

(bytes)

Description

Source Port 2

Source Port: The 16-bit port number of the process that originated the

TCP segment on the source device. This will normally be an ephemeral

(client) port number for a request sent by a client to a server, or a well-

known/registered (server) port number for a reply from a server to a client.

Destination Port 2

Destination Port: The 16-bit port number of the process that is the

ultimate intended recipient of the message on the destination device. This

will usually be a well-known/registered (server) port number for a client

request, or an ephemeral (client) port number for a server reply.

Sequence

Number

Sequence Number: For normal transmissions, the sequence number of

the first byte of data in this segment. In a connection request (SYN)

message, this carries the initial sequence number (ISN) of the source TCP.

The first byte of data will be given the next sequence number after the

contents of this field, as described in the topic on sequence number

synchronization.