Charles M. Kozierok The TCP-IP Guide

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

In fact, we can have multiple connections from the same client to the same server. Each

client process will be assigned a different ephemeral port number, so even if they all try to

access the same server process (such as the Web server process at 41.199.222.3:80),

they will all have a different client socket and represent unique connections. This is what

lets you make several simultaneous requests to the same Web site from your computer.

Again, TCP keeps track of each of these connections independently, so each connection is

unaware of the others. TCP can handle hundreds or even thousands of simultaneous

connections. The only limit is the capacity of the computer running TCP, and the bandwidth

of the physical connections to it—the more connections running at once, the more each one

has to share limited resources.

Key Concept: Each device can handle simultaneous TCP connections to many

different processes on one or more devices. Each connection is identified by the

socket numbers of the devices in the connection, called the connection’s endpoints.

Each endpoint consists of the device’s IP address and port number, so each connection is

identified by the quadruple of client IP address and port number, and server IP address and

port number.

TCP Common Applications and Server Port Assignments

We saw in the overview of TCP that the protocol originally included the functions of both

modern TCP and the Internet Protocol. TCP was split into TCP and IP to allow applications

that didn't need TCP's complexity to bypass it, using the much simpler UDP instead as a

transport layer protocol instead. This was an important step in the development of the TCP/

IP protocol suite, since there are several important protocols for which UDP is ideally

suited, and even some where TCP is more of a nuisance than a benefit.

Most commonly, however, UDP is only used in special cases. The UDP applications topic

describes the two types of protocols that may be better suited to UDP than TCP: ones

where speed is more important than reliability, and ones that send only short messages

infrequently. The majority of TCP/IP applications do not fall into these categories. Thus,

even though the layering of TCP and IP means most protocols aren't required to use TCP,

most of them do anyway. The majority of the protocols that use it employ all or at least most

of the features it provides. The establishment of a persistent connection is necessary for

many interactive protocols, such as Telnet, as well as for ones that send commands and

status replies, like HTTP. Reliability and flow control are essential for protocols that send

large files, like FTP or the e-mail protocols.

Table 151 shows some of the more significant application protocols that run on TCP. I have

shown for each the well-known or registered port number reserved for that protocol's server

process (clients use ephemeral ports, not the port numbers in the table). I have also shown

the special “keyword” shortcut for each port assignment, and provided brief comments on

why the protocol is well-matched to TCP.

Table 151: Common TCP Applications and Server Port Assignments (Page 1 of 2)

Port # Keyword Protocol Comments

20 and 21 ftp-data / ftp

File Transfer Protocol

(FTP, data and control)

Used to send large files, so ideally suited for TCP.

23 telnet Telnet Protocol

Interactive session-based protocol. Requires the

connection-based nature of TCP.

25 smtp

Simple Mail Transfer

Protocol (SMTP)

Uses an exchange of commands, and sends

possibly large files between devices.

53 domain

Domain Name Server

(DNS)

An example of a protocol that uses both UDP and

TCP. For simple requests and replies, DNS uses

UDP. For larger messages, especially zone

transfers, TCP is used.

70 gopher Gopher Protocol

A messaging protocol that has been largely

replaced by the WWW.

80 http

Hypertext Transfer

Protocol (HTTP / World

Wide Web)

The classic example of a TCP-based messaging

protocol.

110 pop3

Post Office Protocol

(POP version 3)

E-mail message retrieval protocols; use TCP to

exchange commands and data.

119 nntp

Network News Transfer

Protocol (NNTP)

Used for transferring NetNews (USEnet)

messages, which can be lengthy.

139 netbios-ssn NetBIOS Session Service

A session protocol, clearly better suited to TCP

than UDP.

143 imap

Internet Message Access

Protocol (IMAP)

Another e-mail message retrieval protocol.

179 bgp

Border Gateway Protocol

(BGP)

While interior routing protocols like RIP and OSPF

use either UDP or IP directly, BGP runs over TCP.

This allows BGP to assume reliable communi-

cation even as it sends data over potentially long

distances.

194 irc Internet Relay Chat (IRC)

IRC is like Telnet in that it is an interactive protocol

that is strongly based on the notion of a persistent

connection between a client and server.

A couple of the protocols in the table above use both TCP and UDP, to get the “best of both

worlds”. Short, simple messages can be sent with UDP, while larger files are moved with

TCP. Many of the protocols that use both TCP and UDP are actually utility/diagnostic

protocols (such as Echo, Discard and the Time Protocol). These are a special case,

because they were designed to use both UDP and TCP specifically to allow their use for

diagnostics on both protocols.

I haven't included an exhaustive list of TCP applications above; see the topic on common

TCP/IP applications and port numbers, which also contains a pointer to the full (massive)

list of TCP well-known and registered server ports.

2049 nfs

Network File System

(NFS)

NFS was original implemented using UDP for

performance reasons. Given that it is responsible

for large transfers of files and UDP is unreliable,

this was probably not the best idea, and TCP

versions were created. The latest version of NFS

uses TCP exclusively.

6000 -

6063

TCP x11

Used for the X Window graphical system. Multiple

ports are dedicated to allow many sessions.

Table 151: Common TCP Applications and Server Port Assignments (Page 2 of 2)

Port # Keyword Protocol Comments

TCP Basic Operation: Connection Establishment, Management and

Termination

While I have described the Transmission Control Protocol as connection-oriented, this term

isn't "just any old characteristic" of TCP. The overall operation of the entire protocol can be

described in terms of how TCP software prepares, negotiates, establishes, manages and

terminates connections. TCP implementations certainly do more than handle connections,

but the other major tasks they perform, such as data handling and providing reliability and

flow control, can only occur over a stable connection. This makes connections the logical

place to begin in exploring the details of how TCP does its thing.

In this section I describe TCP connections from start to finish. I begin with an overview of

TCP's operation by providing a summary of the finite state machine that formally defines the

stages of a connection. State machines can be a bit mind-boggling when you read about

them in standards, but a simplified version provides an excellent high-level view of the "life"

of a connection, so it is a good place to start.

From there, I move on to provide details about TCP's handling of connections. I described

how connections are prepared and transmission control blocks (TCBs) set up, and the

difference between a passive and an active socket open. I explain the three-way

handshake used to create a connection, and the method by which parameters are

exchanged and sequence numbers synchronized. I talk about how an established

connection is managed, including the method by which TCP handles problem conditions

and resets the connection when necessary. Finally, I describe how a connection can be

terminated when it is no longer needed.

Background Information: The detailed topics in this section assume your famil-

iarity with the concepts in the previous fundamentals section, especially the notion

of sequence numbers.

TCP Operational Overview and the TCP Finite State Machine (FSM)

It is essential that all devices that implement any networking protocol do so in a consistent

manner. Otherwise, one device might behave in a manner the other wouldn't expect.

Naturally, this is why there are standards that describe the operation of each protocol. The

problem with a protocol like TCP is that it performs so many tasks that it is difficult to specify

the exact operation of all aspects of the protocol succinctly.

Using A Finite State Machine to Explain Complex Protocols

One way that computer scientists explain how a complex protocol works is through a

theoretical tool called a finite state machine (FSM). An FSM attempts to describe a protocol

or algorithm by considering it like a virtual “machine” that progresses through a series of

stages of operation in response to various happenings. You need to understand four

essential concepts to comprehend the workings of a finite state machine:

☯ State: The particular “circumstance” or “status” that describes the protocol software on

a machine at a given time.

☯ Transition: The act of moving from one state to another.

☯ Event: Something that causes a transition to occur between states.

☯ Action: Something a device does in response to an event before it transitions to

another state.

A FSM describes the protocol by explaining all the different states the protocol can be in,

the events that can occur in each state, what actions are taken in response to the events

and what transitions happen as a result.The protocol usually starts in a particular beginning

state when it is first run. It then follows a sequence of steps to get it into a regular operating

state, and moves to other states in response to particular types of input or other circum-

stances. The state machine is called finite because there are only a limited number of

states.

Key Concept: A tool used by many computer scientists to describe the operation of

a protocol or algorithm is the finite state machine. It describes the different actions

taken by a piece of software over time by defining a finite number of operating states,

events that can cause transitions between states, and actions taken in response to events.

The Simplified TCP Finite State Machine

In the case of TCP, the finite state machine can be considered to describe the “life stages”

of a connection. Each connection between one TCP device and another begins in a null

state where there is no connection, and then proceeds through a series of states until a

connection is established. It remains in that state until something occurs to cause the

connection to be closed again, at which point it proceeds through another sequence of

transitional states and returns to the closed state.

The full description of the states, events and transitions in a TCP connection is lengthy and

complicated—not surprising, since that would cover much of the entire TCP standard. For

our purposes, that level of detail would be a good cure for insomnia but not much else.

However, a simplified look at the TCP FSM will help give us a nice overall feel for how TCP

establishes connections and then functions when a connection has been created.

Table 152 briefly describes each of the TCP states in a TCP connection, and also describes

the main events that occur in each state, and what actions and transitions occur as a result.

For brevity, three abbreviations are used for three types of message that control transitions

between states, which correspond to the TCP header flags that are set to indicate a

message is serving that function. These are:

☯ SYN: A synchronize message, used to initiate and establish a connection. It is so

named since one of its functions is to synchronizes sequence numbers between

devices.

☯ FIN: A finish message, which is a TCP segment with the FIN bit set, indicating that a

device wants to terminate the connection.

☯ ACK: An acknowledgment, indicating receipt of a message such as a SYN or a FIN.

Again, I have not shown every possible transition, just the ones normally followed in the life

of a connection. Error conditions also cause transitions but including these would move us

well beyond a “simplified” state machine. The FSM is also illustrated in Figure 210, which

you may find easier for seeing how state transitions occur.

Table 152: TCP Finite State Machine (FSM) States, Events and Transitions

(Page 1 of 2)

State State Description Event and Transition

CLOSED

This is the default state that each

connection starts in before the process

of establishing it begins. The state is

called “fictional” in the standard. The

reason is that this state represents the

situation where there is no connection

between devices—it either hasn't been

created yet, or has just been

destroyed. If that makes sense. ☺

Passive Open: A server begins the process of

connection setup by doing a passive open on a

TCP port. At the same time, it sets up the data

structure (transmission control block or TCB)

needed to manage the connection. It then

transitions to the LISTEN state.

Active Open, Send SYN: A client begins

connection setup by sending a SYN message,

and also sets up a TCB for this connection. It

then transitions to the SYN-SENT state.

LISTEN

A device (normally a server) is waiting

to receive a synchronize (SYN)

message from a client. It has not yet

sent its own SYN message.

Receive Client SYN, Send SYN+ACK: The

server device receives a SYN from a client. It

sends back a message that contains its own

SYN and also acknowledges the one it

received. The server moves to the SYN-

RECEIVED state.

SYN-SENT

The device (normally a client) has sent

a synchronize (SYN) message and is

waiting for a matching SYN from the

other device (usually a server).

Receive SYN, Send ACK: If the device that

has sent its SYN message receives a SYN from

the other device but not an ACK for its own

SYN, it acknowledges the SYN it receives and

then transitions to SYN-RECEIVED to wait for

the acknowledgment to its SYN.

Receive SYN+ACK, Send ACK: If the device

that sent the SYN receives both an acknowl-

edgment to its SYN and also a SYN from the

other device, it acknowledges the SYN received

and then moves straight to the ESTABLISHED

state.

SYN-

RECEIVED

The device has both received a SYN

(connection request) from its partner

and sent its own SYN. It is now waiting

for an ACK to its SYN to finish

connection setup.

Receive ACK: When the device receives the

ACK to the SYN it sent, it transitions to the

ESTABLISHED state.

ESTABLISHED

The “steady state” of an open TCP

connection. Data can be exchanged

freely once both devices in the

connection enter this state. This will

continue until the connection is closed

for one reason or another.

Close, Send FIN: A device can close the

connection by sending a message with the FIN

(finish) bit sent and transition to the FIN-WAIT-1

state.

Receive FIN: A device may receive a FIN

message from its connection partner asking that

the connection be closed. It will acknowledge

this message and transition to the CLOSE-

WAIT state.

CLOSE-WAIT

The device has received a close

request (FIN) from the other device. It

must now wait for the application on

the local device to acknowledge this

request and generate a matching

request.

Close, Send FIN: The application using TCP,

having been informed the other process wants

to shut down, sends a close request to the TCP

layer on the machine upon which it is running.

TCP then sends a FIN to the remote device that

already asked to terminate the connection. This

device now transitions to LAST-ACK.

LAST-ACK

A device that has already received a

close request and acknowledged it,

has sent its own FIN and is waiting for

an ACK to this request.

Receive ACK for FIN: The device receives an

acknowledgment for its close request. We have

now sent our FIN and had it acknowledged, and

received the other device's FIN and acknowl-

edged it, so we go straight to the CLOSED

state.

FIN-WAIT-1

A device in this state is waiting for an

ACK for a FIN it has sent, or is waiting

for a connection termination request

from the other device.

Receive ACK for FIN: The device receives an

acknowledgment for its close request. It transi-

tions to the FIN-WAIT-2 state.

Receive FIN, Send ACK: The device does not

receive an ACK for its own FIN, but receives a

FIN from the other device. It acknowledges it,

and moves to the CLOSING state.

FIN-WAIT-2

A device in this state has received an

ACK for its request to terminate the

connection and is now waiting for a

matching FIN from the other device.

Receive FIN, Send ACK: The device receives

a FIN from the other device. It acknowledges it

and moves to the TIME-WAIT state.

CLOSING

The device has received a FIN from

the other device and sent an ACK for

it, but not yet received an ACK for its

own FIN message.

Receive ACK for FIN: The device receives an

acknowledgment for its close request. It transi-

tions to the TIME-WAIT state.

TIME-WAIT

The device has now received a FIN

from the other device and acknowl-

edged it, and sent its own FIN and

received an ACK for it. We are done,

except for waiting to ensure the ACK is

received and prevent potential overlap

with new connections. (See the topic

describing connection termination for

more details on this state.)

Timer Expiration: After a designated wait

period, device transitions to the CLOSED state.

Table 152: TCP Finite State Machine (FSM) States, Events and Transitions

(Page 2 of 2)

State State Description Event and Transition

Figure 210: The TCP Finite State Machine (FSM)

This diagram illustrates the simplified TCP FSM. The color codings are not an official part of the definition of

the FSM; I have added them to show more clearly the sequences taken by the two devices to open and close

a link. For both establishment and termination there is a regular sequence, where the initiating and responding

devices go through different states, and a simultaneous sequence where each uses the same sequence.

CLOSED

LISTEN

SYN-SENTSYN-RECEIVED

ESTABLISHED

CLOSE-WAIT

LAST-ACK

FIN-WAIT-1

FIN-WAIT-2 CLOSING

TIM E-WAIT

Passive Open

Set Up TCB

Active Open

Set Up TCB

Send SYN

Receive SYN

Send SYN+ACK

Receive SYN

Send ACK

Receive FIN

Send ACK

Wait for Application

Close, Send FIN

Receive FIN

Send ACK

Receive ACK for FIN

Timer Expiration

Receive ACK for FINReceive FIN

Send ACK

Receive ACK Receive SYN+ACK

Send ACK

Receive ACK for FIN

Simultaneous Open

Open - Initiator SequenceOpen - Responder Sequence

Close - Initiator Sequence Close - Responder Sequence

Simultaneous Close

Close, Send FIN

Tap tap… still awake? Okay, I guess even with serious simplification, that FSM isn't all that

simple. It may seem a bit intimidating at first, but if you take a few minutes with it, you can

get a good handle on how TCP works. The FSM will be of great use in making sense of the

connection establishment and termination processes later in this section—and conversely,

reading those sections will help you make sense of the FSM. So if your eyes have glazed

over completely, just carry on and try coming back to this topic later.

Finite State Machine Steps Represent the Stages of a Connection

It's important to remember that this state machine is followed for each connection. This

means at any given time TCP may be in one state for one connection to socket X, while in

another for its connection to socket Y. Also, the typical movement between states for the

two processes in a particular connection is not symmetric, because the roles of the devices

are not symmetric: one device initiates a connection, the other responds; one device starts

termination, the other replies. There is also an alternate path taken for connection estab-

lishment and termination if both devices initiate simultaneously (which is unusual, but can

happen). This is shown by the color codings in Figure 210.

Thus, for example, at the start of connection establishment, the two devices will take

different routes to get to ESTABLISHED: one device (the server usually) will pass through

the LISTEN state while the other (the client) will go through SYN-SENT. Similarly, one

device will initiate connection termination and take the path through FIN-WAIT-1 to get back

to CLOSED; the other will go through CLOSE-WAIT and LAST-ACK. However, if both try to

open at once, they each proceed through SYN-SENT and SYN-RECEIVED, and if both try

to close at once, they go through FIN-WAIT-1, CLOSING and TIME-WAIT roughly

simultaneously.

Key Concept: The TCP finite state machine describes the sequence of steps taken

by both devices in a TCP session as they establish, manage and close the

connection. Each device may take a different path through the states since under

normal circumstances the operation of the protocol is not symmetric—one device initiates

either connection establishment or termination, and the other responds.

TCP Connection Preparation: Transmission Control Blocks (TCBs) and

Passive and Active Socket OPENs

In the TCP fundamentals topic describing ports and connections, I raised an important point

about TCP operation: it must be capable of handling many connections simultaneously. It is

for this reason that we uniquely identify each connection using the quadruple of the socket

identifiers (IP address and port number) for each of the two devices on the connection. The

process of setting up, managing and terminating a connection is performed independently

for each connection.

Storing Connection Data: the Transmission Control Block

Since each connection is distinct, we must maintain data about each connection separately.

TCP uses a special data structure for this purpose, called a transmission control block

(TCB). The TCB contains all the important information about the connection, such as the

two socket numbers that identify it and pointers to buffers where incoming and outgoing

data are held. The TCB is also used to implement the sliding window mechanism. It holds

variables that keep track of the number of bytes received and acknowledged, bytes

received and not yet acknowledged, current window size and so forth. Of course, each

device maintains its own TCB for the connection.

Before the process of setting up a TCP connection can begin, the devices on each end

must perform some “prep work”. One of the tasks required to prepare for the connection is

to set up the TCB that will be used to hold information about it. This is done right at the very

start of the connection establishment process, when each device just transitions out of the

CLOSED state.

Active and Passive OPENs

TCP/IP is based on the client/server model of operation, and TCP connection setup is

based on the existence of these roles as well. The client and server each prepare for the

connection by performing an OPEN operation. However, there are two different kinds of

OPEN:

☯ Active OPEN: A client process using TCP takes the “active role” and initiates the

connection by actually sending a TCP message to start the connection (a SYN

message).

☯ Passive OPEN: A server process designed to use TCP, however, takes a more “laid-

back” approach. It performs a passive OPEN by contacting TCP and saying “I am

here, and I am waiting for clients that may wish to talk to me to send me a message on

the following port number”. The OPEN is called passive because aside from indicating

that the process is listening, the server process does nothing.

A passive OPEN can in fact specify that the server is waiting for an active OPEN from a

specific client, though not all TCP/IP APIs support this capability. More commonly, a server

process is willing to accept connections from all comers. Such a passive OPEN is said to be

unspecified.

Key Concept: A client process initiates a TCP connection by performing an active

OPEN, sending a SYN message to a server. A server process using TCP prepares

for an incoming connection request by performing a passive OPEN. Both devices

create for each TCP session a data structure used to hold important data related to the

connection, called a transmission control block (TCB).