Charles M. Kozierok The TCP-IP Guide

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

Preparation For Connection

Both the client and the server create the TCB for the connection at the time that they

perform the OPEN. The client already knows the IP addresses and port numbers for both

the client process and the server process it is trying to reach, so it can use these to uniquely

identify the connection and the TCB that goes with it.

For the server, the concept of a TCB at this stage of the game is a bit more complex. If the

server is in fact waiting for a particular client, it can identify the connection using its own

socket and the socket of the client for which it is waiting. Normally, however, the server

doesn't know what client is trying to reach it. In fact, it could be contacted by more than one

client nearly at the same time.

In this case, the server creates a TCB with an unspecified (zero) client socket number, and

waits for an active OPEN to be received. It then binds the socket number of the client to the

TCB for the passive OPEN as part of the connection process. To allow it to handle multiple

incoming connections, the server process may in fact perform several unspecified passive

OPENs simultaneously.

The transmission control block for a connection is maintained throughout the connection

and destroyed when the connection is completely terminated and the device returns to the

CLOSED state. TCP does include a procedure to handle the situation where both devices

perform an active OPEN simultaneously. This is discussed in more detail in the next topic

on the connection establishment process.

TCP Connection Establishment Process: The "Three-Way Handshake"

We have discussed in earlier topics in this section the connection orientation of TCP and its

operation. Before TCP can be employed for any actually useful purpose—that is, sending

data—a connection must be set up between the two devices that wish to communicate.

This process, usually called connection establishment, involves an exchange of messages

that transitions both devices from their initial connection state (CLOSED) to the normal

operating state (ESTABLISHED).

Connection Establishment Functions

The connection establishment process actually accomplishes several things as it creates a

connection suitable for data exchange:

☯ Contact and Communication: The client and server make contact with each other

and establish communication by sending each other messages. The server usually

doesn’t even know what client it will be talking to before this point, so it discovers this

during connection establishment.

☯ Sequence Number Synchronization: Each device lets the other know what initial

sequence number it wants to use for its first transmission.

☯ Parameter Exchange: Certain parameters that control the operation of the TCP

connection are exchanged by the two devices.

Control Messages Used for Connection Establishment: SYN and ACK

TCP uses control messages to manage the process of contact and communication. There

aren't, however, any special TCP control message types; all TCP messages use the same

segment format. A set of control flags in the TCP header indicates whether a segment is

being used for control purposes or just to carry data. As I introduced in the discussion of the

TCP finite state machine, two control message types are used in connection setup, which

are specified by setting the following two flags:

☯ SYN: This bit indicates that the segment is being used to initialize a connection. SYN

stands for synchronize, in reference to the sequence number synchronization I

mentioned above.

☯ ACK: This bit indicates that the device sending the segment is conveying an acknowl-

edgment for a message it has received (such as a SYN).

There are also other control bits (FIN, RST, PSH and URG), which aren't important to

connection establishment, so we will set them aside for now. We'll discuss them in other

topics. In common TCP parlance, a message with a control bit set is often named for that

bit. For example, if the SYN control bit is set the segment is often called “a SYN message”.

Similarly, one with the ACK bit set is “an ACK message” or even just “an ACK”.

Normal Connection Establishment: The "Three Way Handshake"

To establish a connection, each device must send a SYN and receive an ACK for it from the

other device. Thus, conceptually, we need to have four control messages pass between the

devices. However, it's inefficient to send a SYN and an ACK in separate messages when

one could communicate both simultaneously. Thus, in the normal sequence of events in

connection establishment, one of the SYNs and one of the ACKs is sent together by setting

both of the relevant bits (a message sometimes called a SYN+ACK). This makes a total of

three messages, and for this reason the connection procedure is called a three-way

handshake.

Key Concept: The normal process of establishing a connection between a TCP

client and server involves three steps: the client sends a SYN message; the server

sends a message that combines an ACK for the client’s SYN and contains the

server’s SYN; and then the client sends an ACK for the server’s SYN. This is called the

TCP three-way handshake.

Table 153 describes in detail how the three-way handshake works (including a summary of

the preparation discussed in the previous topic). It is adapted from the table describing the

TCP finite state machine, but shows what happens for both the server and the client over

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

the state to which it transitions. The transmit and receive parts of each of the three steps of

the handshake process are shown in the table, as well as in Figure 211.

Table 153: TCP “Three-Way Handshake” Connection Establishment Procedure

Client Server

Start

State

Action

Move

State

Start

State

Action

Move To

State

CLOSED

The client cannot do

anything until the server

has performed a passive

OPEN and is ready to

accept a connection. (Well,

it can try, but nothing will be

accomplished until the

server is ready.)

— CLOSED

The server performs a

passive OPEN, creating a

transmission control block

(TCB) for the connection

and readying itself for the

receipt of a connection

request (SYN) from a

client.

LISTEN

CLOSED

Step #1 Transmit: The

client performs an active

OPEN, creating a trans-

mission control block (TCB)

for the connection and

sending a SYN message to

the server.

SYN-

SENT

LISTEN

The server waits for

contact from a client.

—

SYN-

SENT

The client waits to receive

an ACK to the SYN it has

sent, as well as the server's

SYN.

—LISTEN

Step #1 Receive, Step #2

Transmit: The server

receives the SYN from the

client. It sends a single

SYN+ACK message back

to the client that contains

an ACK for the client's

SYN, and the server's own

SYN.

SYN-

RECEIVED

SYN-

SENT

Step #2 Receive, Step #3

Transmit: The client

receives from the server

the SYN+ACK containing

the ACK to the client's

SYN, and the SYN from the

server. It sends the server

an ACK for the server's

SYN. The client is now

done with the connection

establishment.

ESTAB-

LISHED

SYN-

RECEIVED

The server waits for an

ACK to the SYN it sent

previously.

—

ESTAB-

LISHED

The client is waiting for the

server to finish connection

establishment so they can

operate normally.

SYN-

RECEIVED

Step #3 Receive: The

server receives the ACK to

its SYN and is now done

with connection

establishment.

ESTAB-

LISHED

ESTAB-

LISHED

The client is ready for

normal data transfer

operations.

ESTAB-

LISHED

The server is ready for

normal data transfer

operations.

Simultaneous Open Connection Establishment

TCP is also set up to handle the situation where both devices perform an active OPEN

instead of one doing a passive OPEN. This may occur if two clients are trying to reach each

other instead of a client and a server. It is uncommon, however, and only happens under

certain circumstances.Simultaneous connection establishment can also only happen if a

well-known port is used as the source port for one of the devices.

In this case, the steps are different for both devices. Each client will perform an active

OPEN and then proceed through both the SYN-SENT and SYN-RECEIVED states until

their SYNs are acknowledged. This means there isn't a “three-way handshake” any more

as shown in Table 153. Instead, it is like two simultaneous “two-way handshakes”. Each

client sends a SYN, receives the other's SYN and ACKs it, and then waits for its own ACK.

The transaction, simplified, is described in Table 154 and Figure 212.

Figure 211: TCP “Three-Way Handshake” Connection Establishment Procedure

This diagram illustrates how a conventional connection is established between a client and server, showing

the three messages sent during the process and how each device transitions from the CLOSED state through

intermediate states until the session is ESTABLISHED.

Client Server

Wait For Server

SYN

SYN+ACK

Receive SYN,

Send SYN+ACK

Receive SYN+ACK,

Send ACK

CLOSED

Client State

Active Open: Create

TCB, Send SYN

SYN-SENT

CLOSED

Server State

Passive Open:

Create TCB

LISTEN

Wait For Client

SYN- REC EIV ED

Wait for ACK

to SYN

EST ABLISHED

ACK

Wait for ACK

to SYN

Receive ACK

EST ABLISHED

Table 154: TCP Simultaneous Open Connection Establishment Procedure

Client A Client B

Start

State

Action

Move To

State

Start

State

Action

Move To

State

CLOSED

Client A Step #1

Transmit: Client A

performs an active

OPEN, creating a TCB

and sending a SYN

message to the server.

SYN-SENT CLOSED

Client B Step #1

Transmit: Client B

performs an active

OPEN, creating a TCB

and sending a SYN to

the server.

SYN-SENT

Client B Step #1

Receive and Step #2

Transmit: Client A

receives Client B's SYN

and sends it an ACK. It

is still waiting for an ACK

to its own SYN.

SYN-

RECEIVED

SYN-SENT

Client A Step #1

Receive and Step #2

Transmit: Client B

receives Client A's SYN

and sends it an ACK. It is

still waiting for an ACK to

its own SYN.

SYN-

RECEIVED

SYN-

RECEIVED

Client A Step #2

Receive: Client A

receives the ACK from

Client B for its SYN and

is done with connection

establishment.

ESTAB-

LISHED

SYN-

RECEIVED

Client B Step #2

Receive: Client B

receives the ACK from

Client A for its SYN and

is done with connection

establishment.

ESTAB-

LISHED

Figure 212: TCP Simultaneous Open Connection Establishment Procedure

This diagram shows what happens when two devices try to open a connection to each other at the same time.

In this case instead of a three-way handshake, each sends a SYN and receives an ACK. They each follow the

same sequence of states, which differs from both sequences in the normal three-way handshake.

Client A Client B

Receive SYN,

Send ACK

Receive ACK

CLOSED

Client State

Active Open:

Create TCB,

Send SYN

SYN-SENT

CLOSED

Client State

Active Open:

Create TCB,

Send SYN

SYN- REC EIV ED

Receive SYN,

Send ACK

EST ABLISHED

Receive ACK

EST ABLISHED

SYN-SENT

SYN

ACK

SYN- REC EIV ED

ACK

To keep the table size down, I have shown the activities performed by the two devices

occurring simultaneously (in the same row). In “real life” the actions don’t need to occur at

exactly the same time, and probably won’t. All that has to happen for the simultaneous

procedure to be followed is that each device receives a SYN before getting an ACK for their

own SYN, as Figure 212 shows.

Key Concept: If one device setting up a TCP connection sends a SYN and then

receives a SYN from the other one before its SYN is acknowledged, the two devices

perform a simultaneous open, which consists of the exchange of two independent

SYN and ACK message sets. The end result is the same as the conventional three-way

handshake, but the process of getting to the ESTABLISHED state is different.

TCP Connection Establishment Sequence Number Synchronization and

Parameter Exchange

The TCP three-way handshake describes the mechanism of message exchange that allows

a pair of TCP devices to move from a closed state to a ready-to-use, established

connection. Connection establishment is about more than just passing messages between

devices to establish communication. The TCP layers on the devices must also exchange

information about the sequence numbers each device wants to use for its first data trans-

mission, as well as parameters that will control how the connection operates. The former of

these two data exchange functions is usually called sequence number synchronization, and

is such an important part of connection establishment that the messages that each device

sends to start the connection are called SYN (synchronization) messages.

You may recall from the TCP fundamentals section that TCP refers to each byte of data

individually, and uses sequence numbers to keep track of which bytes have been sent and

received. Since each byte has a sequence number, we can acknowledge each byte, or

more efficiently, use a single number to acknowledge a range of bytes received.

The Problem With Starting Every Connection Using the Same Sequence Number

In the example I gave in the topic describing the sliding windows system, I assumed for

“simplicity” (ha ha, was that simple?) that each device would start a connection by giving

the first byte of data sent sequence number 1. A valid question is, why wouldn't we always

just start off each TCP connection by sending the first byte of data with a sequence number

of 1? The sequence numbers are arbitrary, after all, and this is the simplest method.

In an ideal world, this would probably work, but we don't live in an ideal world. ☺ The

problem with starting off each connection with a sequence number of 1 is that it introduces

the possibility of segments from different connections getting mixed up. Suppose we estab-

lished a TCP connection and sent a segment containing bytes 1 through 30. However, there

was a problem with the internetwork that caused this segment to be delayed, and

eventually, the TCP connection itself to be terminated. We then started up a new

connection and again used a starting sequence number of 1. As soon as this new

connection was started, however, the old segment with bytes labeled 1 to 30 showed up.

The other device would erroneously think those bytes were part of the new connection.

This is but one of several similar problems that can occur. To avoid them, each TCP device,

at the time a connection is initiated, chooses a 32-bit initial sequence number (ISN) for the

connection. Each device has its own ISN, and they will normally not be the same.

Selecting the Initial Sequence Number

Traditionally, each device chose the ISN by making use of a timed counter, like a clock of

sorts, that was incremented every 4 microseconds. This counter was initialized when TCP

started up and then its value increased by 1 every 4 microseconds until it reached the

largest 32-bit value possible (4,294,967,295) at which point it “wrapped around” to 0 and

resumed incrementing. Any time a new connection is set up, the ISN was taken from the

current value of this timer. Since it takes over 4 hours to count from 0 to 4,294,967,295 at 4

microseconds per increment, this virtually assured that each connection will not conflict with

any previous ones.

One issue with this method is that it makes ISNs predictable. A malicious person could write

code to analyze ISNs and then predict the ISN of a subsequent TCP connection based on

the ISNs used in earlier ones. This represents a security risk, which has been exploited in

the past (such as in the case of the famous Mitnick attack). To defeat this, implementations

now use a random number in their ISN selection process.

TCP Sequence Number Synchronization

Once each device has chosen its ISN, it sends this value to the other device in the

Sequence Number field in its initial SYN message. The device receiving the SYN responds

with an ACK message acknowledging the SYN (which may also contain its own SYN, as in

step #2 of the three-way handshake). In the ACK message, the Acknowledgment Number

field is set to the value of the ISN received from the other device plus one. This represents

the next sequence number the device expects to receive from its peer; the ISN actually thus

represents the sequence number of the last byte received (fictitious in this case, since the

connection is new and nothing yet has been received). We'll see later on that this is

consistent with how these two fields are used for normal data exchange.

Key Concept: As part of the process of connection establishment, each of the two

devices in a TCP connection informs the other of the sequence number it plans to

use for its first data transmission by putting the preceding sequence number in the

Sequence Number field of its SYN message. The other device confirms this by incre-

menting that value and putting it into the Acknowledgment Number field of its ACK, telling

the other device that is the sequence number it is expecting for the first data transmission.

This process is called sequence number synchronization.

Here's a simplified example of the three-way handshake steps showing how this is done

(see Figure 213 as well). I chose small ISNs for readability but remember that they can be

any 32-bit number:

1. Connection Request By Client: The client chooses an ISN for its transmissions of

4,567. It sends a SYN with the Sequence Number field set to 4,567.

2. Acknowledgment and Connection Request By Server: The server chooses an ISN

for its transmissions of 12,998. It receives the client's SYN. It sends a SYN+ACK with

an Acknowledgment Number field value of 4,568 (one more than the client's ISN). This

message has a Sequence Number field value of 12,998.

3. Acknowledgment By Client: The client sends an ACK with the Acknowledgment

Number field set to 12,999.

With the connection now established, the client will send data whose first byte will be given

sequence number 4,568. The server's first byte of data will be numbered 12,999.

Figure 213: TCP Sequence Number Synchronization

This diagram illustrates the same three-way handshake connection establishment procedure introduced in

Figure 211, except this time I have shown the Sequence Number and Acknowledgment Number fields in each

message so you can see how they are used by each of the two devices to establish initial sequence numbers

for data exchange.

Client Server

Wait For Server

SYN

Seq Num = 4,567

SYN+ACK

Ack Num = 4,568

Seq Num = 12,998

Receive SYN,

Send SYN+ACK

Receive SYN+ACK,

Send ACK

CLOSED

Client State

Active Open: Create

TCB, Send SYN

SYN-SENT

CLOSED

Server State

Passive Open:

Create TCB

LISTEN

Wait For Client

SYN- REC EIV ED

Wait for ACK

to SYN

EST ABLISHED

ACK

Ack Num = 12,999

Wait for ACK

to SYN

Receive ACK

EST ABLISHED

TCP Parameter Exchange

In addition to initial sequence numbers, SYN messages also are designed to convey

important parameters about how the connection should operate. TCP includes a flexible

scheme for carrying these parameters, in the form of a variable-length Options field in the

TCP segment format that can be expanded to carry multiple parameters. Only a single

parameter is defined in TCP 793 to be exchanged during connection setup: Maximum

Segment Size (MSS). The significance of this parameter is explained in the TCP data

transfer section.

Each device sends the other the MSS that it wants to use for the connection, if it wishes to

use a non-default value. When receiving the SYN, the server records the MSS value that

the client sent, and will never send a segment larger than that value to the client. The client

does the same for the server. The client and server MSS values are independent, so a

connection can be established where the client can receive larger segments than the server

or vice-versa.

Later RFCs have defined additional parameters that may be exchanged during connection

setup. Some of these include:

☯ Window Scale Factor: Allows a pair of devices to specify larger window sizes than

would normally be possible given the 16-bit size of the TCP Window field.

☯ Selective Acknowledgment Permitted: Allows a pair of devices to use the optional

selective acknowledgment feature to allow only certain lost segments to be

retransmitted.

☯ Alternate Checksum Method: Lets devices specify an alternative method of

performing checksums than the standard TCP mechanism.

TCP Connection Management and Problem Handling, the Connection Reset

Function, and TCP "Keepalives"

Once both of the devices in a TCP connection have completed connection setup and have

entered the ESTABLISHED state, the TCP software is in its normal operating mode. Bytes

of data will be packaged into segments for transmission using the mechanisms described in

the section on message formatting and data transfer. The sliding windows scheme will be

used to control segment size and to provide flow control, congestion handling and retrans-

missions as needed.

Once in this mode, both devices can remain there indefinitely. Some TCP connections can

be very long-lived indeed—in fact, some users maintain certain connections like Teln et

sessions for hours or even days at a time. There are two circumstances that can cause a

connection to move out of the ESTABLISHED state:

☯ Connection Termination: Either of the devices decides to terminate the connection.

This involves a specific procedure that is covered in the next topic in this section.

☯ Connection Disruption: A problem of some sort occurs that causes the connection to

be interrupted.

The TCP Reset Function

To allow TCP to live up to its job of being a reliable and robust protocol, it includes intelli-

gence that allows it to detect and respond to various problems that can occur during an

established connection. One of the most common is the half-open connection. This

situation occurs when due to some sort of problem, one device closes or aborts the

connection without the other one knowing about it. This means one device is in the ESTAB-

LISHED state while the other may be in the CLOSED state (no connection) or some other

transient state. This could happen if, for example, one device had a software crash and was

restarted in the middle of a connection, or if some sort of glitch caused the states of the two

devices to become unsynchronized.

To handle half-open connections and other problem situations, TCP includes a special reset

function. A reset is a TCP segment that is sent with the RST flag set to one in its header.

Generally speaking, a reset is generated whenever something happens that is

“unexpected” by the TCP software. Some of the most common specific cases in which a

reset is generated include:

☯ Receipt of any TCP segment from any device with which the device receiving the

segment does not currently have a connection (other than a SYN requesting a new

connection.)

☯ Receipt of a message with an invalid or incorrect Sequence Number or Acknowl-

edgment Number field, indicating the message may belong to a prior connection or is

spurious in some other way.

☯ Receipt of a SYN message on a port where there is no process listening for

connections.

Handling Reset Segments

When a device receives a segment with the RST bit sent, it tells the device to reset the

connection so it can be re-established. Like all segments, the reset itself must be checked

to ensure that it is valid (by looking at the value of its Sequence Number field). This

prevents a spurious reset from shutting down a connection. Assuming the reset is valid, the

handling of the message depends on the state of the device that receives it:

☯ If the device is in the LISTEN state, the reset is ignored and it remains in that state.

☯ If the device is in the SYN-RECEIVED state but was previously in the LISTEN state

(which is the normal course of events for a server setting up a new connection), it

returns to the LISTEN state.

☯ In any other situation, the reset causes the connection to be aborted and the device

returns to the CLOSED state for that connection. The device will advise the higher-

layer process using TCP that the connection has been closed.