TCP Connection Management (1)

Introduction

Recall that TCP's service model is a byte stream.

TCP detects and repairs essentially all the data transfer problems so may is introduced by packet loss, duplication, or Errors at the IP layer (or below).

UDP is a connectionless protocol that involves no con-nection establishment or termination.

Some options allowed to being sent only if the connection is established, and others can sent later.

Recall from Chapter the TCP header have a limited space for holding options (+ bytes)

TCP Connection Establishment and termination

A TCP connection is defined to be a 4-tuple consisting of the IP addresses and port numbers.

More precisely, it was a pair of endpoints or sockets where each end-point was identified by an (IP address, port Number) pair.

A connection typically goes through three phases:setup, data transfer (called established), and teardown (Closin g).

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 fie LD turned on the TCP header)

Specify-ing the port number of the peer to which it wants to connect

And the client ' s initial sequence number or ISN (c) (see section 13.2.3).

It typically sends one or more options on 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.

This is often called the three-way handshake.

Its main purposes, is-let each end of the connec-tion know, a connection is starting and

The special details that is carried as options, and to exchange the ISNs.

In sections 13.2.2 we describe a supported but unusual simultaneous open when

both sides can do a active open at the same time and become both clients and servers.

either end can initiate a close operation, and simultaneous closes is also supported but is rare.

Usually a close operation starts with an application indicating their desire to terminate their 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).

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 C Loser ' s FIN.

At this point, the application (server) is noti-fied, and the other end of it 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 (server not waste sn yet).

3 to complete the close, the final segment contains a ACK for the last FIN.

Note that if a FIN is lost, it's retransmitted until an ACK to it is received.

This reason was that TCP's data communica-tions model is bidirectional, meaning it was possible to has only one O f the directions operating.

The half-close operation in TCP closes is a single direction of the data flow.

Half-close operations together close the entire connection.

There is more abrupt ways to tear down a TCP connection using special reset segments, which we cover LA ter.

When a small amount of the data needs to be exchanged, it's now apparent what some applications prefer to use UDP because of its ability to send and receive data With-out establishing connections.

TCP Half-close

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 of the half-close, but either end can does this.

When the end that received the half-close was done sending data, it closes its end of the connection, causing a FI N to is sent,

And this delivers a end-of-file indication to the application that initiated the half-close.

Simultaneous Open and Close

It is possible, although highly improbable unless specifically arranged, for the applications to perform an Activ e open to all other at the same time.

The only real difference is and the segment sequence is inter-leaved instead of sequential.

Initial Sequence Number (ISN)

This brings up the question of whether it might being possible to has TCP segments being routed through the net-work that C Ould show up later and disrupt a connection.

This concern was addressed by careful selection of the ISN.

before each end sends its SYN-to-establish the connection, it chooses an ISN for that connection.

The ISN should change-over time, so-connection has a different one.

[RFC0793] Specifies that the ISN should is viewed as a 32-bit counter that increments by 1 every 4μs.

The purpose of doing this was 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 being allowed to overlap between different instantiations (or Incarnati ONS) of the same connection.

The idea of different instantiations of the same connection becomes clear if we recall that a TCP connection is IdentiFi Ed by a pair of endpoints, creat-ing a 4-tuple of the 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 dat A.

This would is most troublesome. By taking steps to avoid overlap in sequence numbers between connection instantiations, we can try to minimize th is risk.

It does suggest, however, a application with a very great need for data integrity should employ its own CRCs or CHEC Ksums at the application, layer to ensure, and its own data have been transferred without error.

This was generally good practice in any case, and it was commonly done for large files.

As we shall see, knowing the connection 4-tuple as well as the currently active window of sequence numbers are all That's required to form a TCP segment that's 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, I P addresses, and port numbers is chosen appropriately, can interrupt a TCP connection [RFC5961].

One-to-repelling-is-to-make the initial sequence number (or ephemeral port number [RFC6056]) relatively hard to guess. Another is encryption (see Chapter 18).

Example

Second segment:

...

This segment also includes a window advertisement indicating that the server was willing to accept up to 64,240 by Tes.

...

Finish Third segment:
...

This segment also (redundantly) ACKs the client ' s FIN once again.

...

Note that the PSH bit field was on. This have no real effect on the closing of the connection but usually indicates so the server has no additio NAL data to send.

...

One thing we can see in Figure 13-5 is, 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 bytes, the bytes greater than the minimum size.

...

Timeout of Connection Establishment

There is several circumstances in which a connection cannot is established. One obvious case was when the server host was down.

If, however, we place an ARP entry for a nonexistent host with the ARP table first, the ARP request is not sent,

The system immediately attempts to the nonexistent host with TCP/IP.

The interesting point in this output are how frequently the client's TCP sends a SYN to try to establish the Conne Ction.

The second segment is sent 3s after the first, the third are sent 6s after the second, the fourth are sent 12s after the thi Rd, and so on.

This behavior is called exponential backoff.

The number of times to retry An initial SYN can is configured on some sys-tems and usually have a fairly small VA Lue such as 5.

In Linux, the system configura-tion variable net.ipv4.tcp_syn_retries gives the maximum number of times to a Ttempt to Resend a SYN segment during an active open.

A corresponding value called net.ipv4.tcp_synack_retries gives the maximum number of times to attempt to Rese nd a SYN + ACK segment when responding to a peer ' s active Open request.

It can also is used on a individual connection basis by setting the linux-specific tcp_syncnt socket option< /c4>.

Its default value was five retries, as we see here.

The exponential backoff timing between these retransmissions is part of the TCP ' s congestionmanagement response.

We shall examine it in detail if we discuss Karn ' s algorithm (see Chapter 16).

TCP Connection Management (1)