A TCP connection is defined to be a 4-tuple consisting of two IP addresses and two port numbers. More precisely, it is a pair of endpoints or sockets where each end- point is identified by an (IP address, port number) pair.
ptg999 A connection typically goes through three phases: setup, data transfer (called
established), and teardown (closing). As we will see, some of the difficulty in creat- ing a robust TCP implementation is handling all of the transitions between and among these phases correctly. A typical TCP connection establishment and close (without any data transfer) is shown in Figure 13-1.
6<16HT ,61FRSWLRQV
6<1$&.6HT ,61V$&. ,61FRSWLRQV
$FWLYH2SHQHU
&OLHQW
3DVVLYH2SHQHU 6HUYHU
$&.6HT ,61F$&. ,61V
RSWLRQV
&RQQHFWLRQ6HW8S 7KUHH:D\+DQGVKDNH
),1$&.6HT .$&. /RSWLRQV
$&.6HT /$&. .RSWLRQV
),1$&.6HT /$&. .RSWLRQV
$&.6HT
.$&. /RSWLRQV 'DWD7UDQVIHU
(VWDEOLVKHG
&RQQHFWLRQ&ORVH 0RGLILHG7KUHH:D\
+DQGVKDNH
>1R'DWD7UDQVIHUUHGLQ7KLV([DPSOH@
Figure 13-1 A normal TCP connection establishment and termination. Usually, the client initiates a three-way handshake to exchange initial sequence numbers carried on SYN segments for the client and server (ISN(c) and ISN(s), respectively). The connection terminates after each side has sent a FIN and received an acknowledgment for it.
The figure shows a timeline of what happens during connection establish- ment. To establish a TCP connection, the following events usually take place:
1. The active opener (normally called the client) sends a SYN segment (i.e., a TCP/IP packet with the SYN bit field turned on in the TCP header) specify- ing the port number of the peer to which it wants to connect and the client’s
ptg999 Section 13.2 TCP Connection Establishment and Termination 597
initial sequence number or ISN(c) (see Section 13.2.3). It typically sends one or more options at this point (see Section 13.3). This is segment 1.
2. The server responds with its own SYN segment containing its initial sequence number (ISN(s)). This is segment 2. The server also acknowledges the client’s SYN by ACKing ISN(c) plus 1. A SYN consumes one sequence number and is retransmitted if lost.
3. The client must acknowledge this SYN from the server by ACKing ISN(s) plus 1. This is segment 3.
These three segments complete the connection establishment. This is often called the three-way handshake. Its main purposes are to let each end of the connec- tion know that a connection is starting and the special details that are carried as options, and to exchange the ISNs.
The side that sends the first SYN is said to perform an active open. As men- tioned, this is typically a client. The other side, which receives this SYN and sends the next SYN, performs a passive open. It is most commonly called the server. (In Section 13.2.2 we describe a supported but unusual simultaneous open when both sides can do an active open at the same time and become both clients and servers.)
Note
TCP supports the capability of carrying application data on SYN segments. This is rarely used, however, because the Berkeley sockets API does not support it.
Figure 13-1 also shows how a TCP connection is closed (also called cleared or terminated). Either end can initiate a close operation, and simultaneous closes are also supported but are rare. Traditionally, it was most common for the client to initiate a close (as shown in Figure 13-1). However, other servers (e.g., Web servers) initiate a close after they have completed a request. Usually a close operation starts with an application indicating its desire to terminate its connection (e.g., using the close() system call). The closing TCP initiates the close operation by sending a FIN segment (i.e., a TCP segment with the FIN bit field set). The complete close operation occurs after both sides have completed the close:
1. The active closer sends a FIN segment specifying the current sequence num- ber the receiver expects to see (K in Figure 13-1). The FIN also includes an ACK for the last data sent in the other direction (labeled L in Figure 13-1).
2. The passive closer responds by ACKing value K + 1 to indicate its success- ful receipt of the active closer’s FIN. At this point, the application is noti- fied that the other end of its connection has performed a close. Typically this results in the application initiating its own close operation. The passive closer then effectively becomes another active closer and sends its own FIN.
The sequence number is equal to L.
ptg999 3. To complete the close, the final segment contains an ACK for the last FIN.
Note that if a FIN is lost, it is retransmitted until an ACK for it is received.
While it takes three segments to establish a connection, it takes four to termi- nate one. It is also possible for the connection to be in a half-open state (see Section 13.6.3), although this is not common. This reason is that TCP’s data communica- tions model is bidirectional, meaning it is possible to have only one of the two directions operating. The half-close operation in TCP closes only a single direction of the data flow. Two half-close operations together close the entire connection.
The rule is that either end can send a FIN when it is done sending data. When a TCP receives a FIN, it must notify the application that the other end has termi- nated that direction of data flow. The sending of a FIN is normally the result of the application issuing a close operation, which typically causes both directions to close.
The seven segments we have seen are baseline overheads for any TCP connec- tion that is established and cleared “gracefully.” (There are more abrupt ways to tear down a TCP connection using special reset segments, which we cover later.) When a small amount of data needs to be exchanged, it is now apparent why some applications prefer to use UDP because of its ability to send and receive data with- out establishing connections. However, such applications are then faced with han- dling their own error repair features, congestion management, and flow control.
13.2.1 TCP Half-Close
As we have mentioned, TCP supports a half-close operation. Few applications require this capability, so it is not common. To use this feature, the API must pro- vide a way for the application to say, essentially, “I am done sending data, so send a FIN to the other end, but I still want to receive data from the other end, until it sends me a FIN.” The Berkeley sockets API supports half-close, if the application calls the shutdown() function instead of calling the more typical close() func- tion. Most applications, however, terminate both directions of the connection by calling close. Figure 13-2 shows an example of a half-close being used. We show the client on the left side initiating the half-close, but either end can do this.
The first two segments are the same as for a regular close: a FIN by the initia- tor, followed by an ACK of the FIN by the recipient. The operation then differs from Figure 13-1, because the side that receives the half-close can still send data.
We show only one data segment, followed by an ACK, but any number of data segments can be sent. (We talk more about the exchange of data segments and acknowledgments in Chapter 15.) When the end that received the half-close is done sending data, it closes its end of the connection, causing a FIN to be sent, and this delivers an end-of-file indication to the application that initiated the half-close.
When this second FIN is acknowledged, the connection is completely closed.
ptg999 Section 13.2 TCP Connection Establishment and Termination 599
13.2.2 Simultaneous Open and Close
It is possible, although highly improbable unless specifically arranged, for two applications to perform an active open to each other at the same time. Each end must have transmitted a SYN before receiving a SYN from the other side; the SYNs must pass each other on the network. This scenario also requires each end to have an IP address and port number that are known to the other end, which is rare (except for the firewall “hole-punching” techniques we saw in Chapter 7). If this happens, it is called a simultaneous open.
For example, a simultaneous open occurs when an application on host A using local port 7777 performs an active open to port 8888 on host B, while at the same time an application on host B using local port 8888 performs an active open to port 7777 on host A. This is not the same as connecting a client on host A to a server on host B, while at the same time having a client on host B connect to a conventional server on host A. In that case, both servers perform passive opens, not active opens, and the clients assign themselves different ephemeral port num- bers. This results in two distinct TCP connections. Figure 13-3 shows the segments exchanged during a simultaneous open.
$FWLYH2SHQHU
&OLHQW
3DVVLYH2SHQHU 6HUYHU
),1$&.6HT
.$&. /RSWLRQV
$&.6HT /$&. .RSWLRQV
),16HT /$&. .RSWLRQV
$&.6HT
.$&. /RSWLRQV
&RQQHFWLRQ,V +DOI&ORVHG
&RQQHFWLRQảV
³2WKHU+DOI´&ORVHV
>'DWD7UDQVIHU@
>0RUH'DWD6HQW@
>'DWD$FNQRZOHGJHG
@
&OLHQW,QLWLDWHV&ORVH
Figure 13-2 With the TCP half-close operation, one direction of the connection can terminate while the other continues until it is closed. Few applications use this feature.
ptg999
A simultaneous open requires the exchange of four segments, one more than the normal three-way handshake. Also note that we do not call either end a cli- ent or a server, because both ends act as client and server. A simultaneous close is not very different. We said earlier that one side (often, but not always, the client) performs the active close, causing the first FIN to be sent. In a simultaneous close, both do. Figure 13-4 shows the segments exchanged during a simultaneous close.
6<16HT ,61F RSWLRQV
6<16HT
,61FRSWLRQV
$FWLYH2SHQHU F
$FWLYH2SHQHU F
&RQQHFWLRQ6HWXS 6LPXOWDQHRXV2SHQ
>'DWD7UDQVIHU0D\%HJLQ+HUH@
6<1$&.
6HT ,61F$&. ,61
FRSWLRQV 6<1$&.6HT
,61F$&. ,61F RSWLRQV
Figure 13-3 Segments exchanged during simultaneous open. One additional segment is required compared to the ordinary connection establishment procedure. The SYN bit field is on in each segment until an ACK for it is received.
),1$&.6HT
.$&.
/RSWLRQV ),1$&.6(4
/$&. .
$FWLYH&ORVHU F
$FWLYH&ORVHU F
&RQQHFWLRQ 7HUPLQDWLRQ
$&.
6HT /$&. .RSWLRQV
$&.6HT
.$&.
/RSWLRQV
Figure 13-4 Segments exchanged during simultaneous close work like a conventional close, but the segment ordering is interleaved.
ptg999 Section 13.2 TCP Connection Establishment and Termination 601
With a simultaneous close the same number of segments are exchanged as in the normal close. The only real difference is that the segment sequence is inter- leaved instead of sequential. Later we will see that simultaneous open and close operations use particular states in the TCP implementation that are not commonly exercised.
13.2.3 Initial Sequence Number (ISN)
When a connection is open, any segment with the appropriate two IP addresses and port numbers is accepted as valid provided the sequence number is valid (i.e., within the window) and the checksum is OK. This brings up the question of whether it might be possible to have TCP segments being routed through the net- work that could show up later and disrupt a connection. This concern is addressed by careful selection of the ISN, which we now investigate.
Before each end sends its SYN to establish the connection, it chooses an ISN for that connection. The ISN should change over time, so that each connection has a different one. [RFC0793] specifies that the ISN should be viewed as a 32-bit counter that increments by 1 every 4às. The purpose of doing this is to arrange for the sequence numbers for segments on one connection to not overlap with sequence numbers on a another (new) identical connection. In particular, new sequence numbers must not be allowed to overlap between different instantiations (or incarnations) of the same connection.
The idea of different instantiations of the same connection becomes clear when we recall that a TCP connection is identified by a pair of endpoints, creat- ing a 4-tuple of two address/port pairs. If a connection had one of its segments delayed for a long period of time and closed, but then opened again with the same 4-tuple, it is conceivable that the delayed segment could reenter the new connec- tion’s data stream as valid data. This would be most troublesome. By taking steps to avoid overlap in sequence numbers between connection instantiations, we can try to minimize this risk. It does suggest, however, that an application with a very great need for data integrity should employ its own CRCs or checksums at the application layer to ensure that its own data has been transferred without error.
This is generally good practice in any case, and it is commonly done for large files.
As we shall see, knowing the connection 4-tuple as well as the currently active window of sequence numbers is all that is required to form a TCP segment that is considered valid to a communicating TCP endpoint. This represents a form of vul- nerability for TCP: anyone can forge a TCP segment and, if the sequence numbers, IP addresses, and port numbers are chosen appropriately, can interrupt a TCP connection [RFC5961]. One way of repelling this is to make the initial sequence number (or ephemeral port number [RFC6056]) relatively hard to guess. Another is encryption (see Chapter 18).
In modern systems, the ISN is typically selected in a semirandom way. An interesting discussion of the subtleties of doing this properly is contained in CERT Advisory CA-2001-09 [CERTISN]. Linux goes through a fairly elaborate process to
ptg999 select its ISNs. It uses a clock-based scheme but starts the clock at a random offset
for each connection. The random offset is chosen as a cryptographically hashed function on the connection identifier (4-tuple). A secret input to the hash func- tion changes every 5 minutes. Of the 32 bits in the ISN, the top-most 8 bits are a sequence number of the secret, and the remaining bits are generated by the hash.
This produces an ISN that is difficult to guess, but also one that increases over time. Windows reportedly uses a similar scheme based on RC4 [S96].
13.2.4 Example
Now that we have a basic idea of how a TCP connection is established and cleared, let us look at the packet-level details. To do so we make a TCP connection to a nearby Web server running on the machine with IPv4 address 10.0.0.2. The cli- ent is the Telnet application on Windows:
C:\> telnet 10.0.0.2 80
Welcome to Microsoft Telnet Client Escape Character is 'CTRL+]' ... wait about 4.4 seconds ...
Microsoft Telnet> quit
The telnet command establishes a TCP connection with the host having IPv4 address 10.0.0.2 on the port corresponding to the http or Web service (port 80).
When the Telnet program connects to a port other than 23 (the well-known port for the Telnet protocol [RFC0854]), it does not engage in the application protocol.
Instead, it merely copies bytes from its input to its TCP connection and vice versa.
When a Web server receives the incoming connection request, the first thing it does is await a request for a Web page. In this case, we do not provide one, so the server does not produce any data. This is ideal for us, because for now we are interested only in the connection establishment and termination packet exchange. Figure 13-5 shows the Wireshark output for the segments generated by this command.
In the figure, we can see that the client begins with a SYN segment contain- ing an ISN of 685506836 and window advertisement of 65535. This segment also contains several options we discuss in Section 13.3. The second segment is both a SYN from the server and an ACK for the client. The sequence number (server’s ISN) is 1479690171 and the ACK number is 685506837, 1 more than the client’s ISN.
This indicates successful receipt of the client’s ISN. This segment also includes a window advertisement indicating that the server is willing to accept up to 64,240 bytes. Completion of the three-way handshake takes place with segment 3, which contains ACK number 1479690172. Remember that ACK numbers are cumulative and always indicate the sequence number the sender of the ACK expects to see next (not the one that it last received).
After a pause of about 4.4s, the Telnet application is instructed to close the connection. This results in the client’s TCP sending the FIN in segment 4. The sequence number of the FIN is 685506837, which is ACKed in segment 5 (with
ptg999 Section 13.2 TCP Connection Establishment and Termination 603
ACK number 685506838). Shortly thereafter the server sends its own FIN with sequence number 1479690172. This segment also (redundantly) ACKs the client’s FIN once again. Note that the PSH bit field is on. This has no real effect on the closing of the connection but usually indicates that the server has no additional data to send. The final segment ACKs the server’s FIN by including ACK number 1479690173.
Note
[RFC1025] calls a segment with the maximum number of features enabled (e.g., flags and options) a “Kamikaze” packet. Other colorful terms include “nastygram,”
“Christmas tree packet,” and “lamp test segment.”
One thing we can see in Figure 13-5 is that the SYN segments contain one or more options. These take up additional space in the TCP header. For example, the length of the first TCP header is 44 bytes, 24 bytes greater than the minimum size. TCP
Figure 13-5 A TCP connection between 192.168.35.130 and 10.0.0.2 is established and cleared without sending any data. The PSH (Push) bit indicates that segment 6 is sending all data from its buffer (which is none).
ptg999 has several supported options, which we detail after we see what happens when a
connection cannot be established.
13.2.5 Timeout of Connection Establishment
There are several circumstances in which a connection cannot be established. One obvious case is when the server host is down. To simulate this scenario, we issue our telnet command to a nonexistent host in the same subnet. If we do this without modifying the ARP table, the client exits with a “No route to host” error message, generated because no ARP reply is ever returned for the ARP request (see Chapter 4). If, however, we place an ARP entry for a nonexistent host in the ARP table first, the ARP request is not sent, and the system immediately attempts to contact the nonexistent host with TCP/IP. First, the commands:
Linux# arp -s 192.168.10.180 00:00:1a:1b:1c:1d Linux% date; telnet 192.168.10.180 80; date Tue June 7 21:16:34 PDT 2009
Trying 192.168.10.180...
telnet: connect to address 192.168.10.180: Connection timed out Tue June 7 21:19:43 PDT 2009
Linux%
Here the MAC address 00:00:1a:1b:1c:1d was chosen simply as a MAC address not being used on the LAN; it is of no special consequence. The timeout occurs about 3.2 minutes after the initial command. Because there is no host to respond, all of the segments generated are from the client. Listing 13-1 shows the output using Wireshark in packet summary (text) mode.
Listing 13-1 Wireshark output for connection establishment that times out No. Time Source Destination Protocol Info
1 0.000000 192.168.10.144 192.168.10.180 TCP 32787 > http 2 2.997928 192.168.10.144 192.168.10.180 TCP 32787 > http 3 8.997962 192.168.10.144 192.168.10.180 TCP 32787 > http 4 20.997942 192.168.10.144 192.168.10.180 TCP 32787 > http 5 44.997936 192.168.10.144 192.168.10.180 TCP 32787 > http 6 92.997937 192.168.10.144 192.168.10.180 TCP 32787 > http
The interesting point in this output is how frequently the client’s TCP sends a SYN to try to establish the connection. The second segment is sent 3s after the first, the third is sent 6s after the second, the fourth is sent 12s after the third, and so on. This behavior is called exponential backoff, and we saw something like it before when we discussed the behavior of Ethernet’s CSMA/CD media access control protocol (see Chapter 3). In that case, it was a little different, however, because here each backoff is deterministically (i.e., always) twice the previous backoff, whereas in Ethernet, the maximum backoff is doubled and the actual backoff is chosen randomly.