TCP Connection Management

As we have seen, TCP is connection-oriented. Actually, what this means is that before any communication, TCP establishes a communication between the Browser and the Web Server

We also have seen that there are persistent and non-persistent connections and within those stop and wait and parallel connections.

Connection Establishment

When the browser sends a packet to the socket, TCP starts a connection to the server. In order to do that, it builds a packet with no data indicating its connection port and its sequence number (35 e.g., but randomly chosen for each connection), and sets SYN flag, pointing out that it wants to connect to the web server. Then it sends the message to the server Well Known Port for HTTP, the port 80 (Figure 1 note 1).

When the server realizes that a message has arrived reads it and, by the state of SYN flag, checks that a browser is trying to establish a connection with it. Then the server allocates buffers and variables for this connection, increments the sequence number chosen by the browser and puts it in its recognition number field (35+1=36), randomly chooses its sequence number (57) and populates its sequence number field with it and maintains SYN flag set. Then it sends the message to the browser, also without data (Figure 1 note 2).

When the browser receives this message from the server reads it this way:

“I accept to connect with you, my sequence number is 57 and I expect a package in which the first byte has a sequence number equal to my recognition number”.

Then, the browser allocates buffer and variables to this connection, makes SYN 0, places in its sequence number field the server’s recognition field value (36), places in its recognition field the server’s sequence number field incremented value (57+1=58), and sends a packet to the server (Figure 1 note 3).

What we have described is called a three way hand-shake and is characterized by a SYN → SIN/ACK → ACK sequence:

1. SYN – The client sends a SYN to the server and goes to the state of SYN_SENT.
2. SYN/ACK – The server replies with SYN/ACK and goes to the state of SYN_RCVD.
3. ACK – The client sends an ACK back to the server and the connection goes to the ESTABLISHED state. When the server receives this ACK it too sets the connection in the ESTABLISHED state.

In the 3rd way message (the ACK) the browser can now send data, specifically the HTTP request .

TCP is a point to point connection between two endpoints, in our case Browser and Web Server. This is why this protocol is not appropriated for multicast messages.

Connection Termination

Both the browser and the server can terminate the connection.

Let’s admit that, as in Figure 1 , it’s the browser that closes the connection. Thus, the layer application sends a closing command to the transport layer connection.

In sequence, the transport layer sends the server a packet with the FIN flag set, entering the FIN_WAIT_1 state (Figure 1 note 4).

This message tells the server about browser’s will to close the connection. The server responds with an ACK packet (Acknowledge). The server enters the CLOSE_WAIT state (Figure 1 note 5).

When the Browser receives this packet enters FIN_WAIT_2 state. And does nothing. Just waits.

Then, the server sends a second packet with the FIN flag set, telling the browser that it is going to close the connection, entering LAST_ACK state until it will receive the last ACK from the client (Figure 1 note 6).

When the browser receives this last packet returns an ACK packet to the server and enters TIME_WAIT state. The time during which the browser is kept in this state is typically 30 seconds, 1 or 2 minutes, but depends on the applications specifications. After this period the Browser releases the port connection, the buffer and the state variables and sets this connection to CLOSED.

When the server receives the ACK releases the buffer, the state variables and port, if it is specific for this connection and enters the LISTENING state.

The states described are defined as active fin and passive fin. Active is the one who initiates the termination and passive is the one who accepts it. In the case of Figure 1, the browser is active and the server is passive.

During the connection -The Session

TCP ensures a reliable data transfer, a task of great responsibility, for not only transferred data may require great accuracy as its transmission will be made by an unreliable layer, where packets can be loss, damaged or cluttered.

A packet with ACK set is the confirmation by the recipient that a specific packet was received in good conditions.

TCP uses cumulative acknowledgments, i.e., when it receives an ACK for a specific package, being not acknowledged one or more packets sent before it assumes that those packets have also been received in good conditions.

And why being so sure?

Because TCP protocol was based on GBN (Go-Back-N) protocol.

In GBN protocol, the receiver discards any packet received out of order, i.e. when it receives a packet before receiving the immediately preceding it discards it and sends a repeated ACK for the last ordered received packet.

This ensures the sender, when it receives an ACK for a packet that is in advance to it, because it lacks previous packet ACKs, that the recipient has received those packets.

Repetition of ACK to the same packet, informs the sender about the last ordered packet received.

TCP doesn’t use negative acknowledgments or NACK (Not Acknowledged).

It’s time to look at a graph of a correct transmission in Figure 2, where all packets reach their destination ordered and their ACKs are received by the sender before the timer runs out.

When looking at the graph three concepts that we have not yet talked about stand out: the reception window, the timer (timeout), and how sequential and recognition numbers evolve.

Reception Window

The reception window is used as a TCP packet flow controller. Buffers for temporary storage of data are created on both sides of the connection.

If recipient side application processes the data packets at a rate below its transmission by the sender, a buffer flood in the recipient will result. To prevent this from happening, the sender provides to the recipient, in the packet header, the reception window size, which it calculates, function of speed of delivery and application buffer size, so that buffer never reaches the full state.

The reception window is a value that the sender must take into account when sending packets, in order to not saturate the recipient buffer. This graph reception window value (N) is 4, only as an example. So, once reached 4 packets sent and not yet acknowledged, the sender pauses. As ACKs of sent packets arrive, the reception window will slide, allowing sending more packets that are on a waiting list.

During the session, the value of reception window is constantly adjusted according to several analysis that are being made by both sides, and its value is always placed in the header of sent packets.

The reception window will also be used by the TCP congestion control as a way of regulating the flow of packets according to the indications of the own packets.

 Timeout

Timeout is a time value that, once depleted leads to retry sending a package that has not yet received an ACK. In a TCP session there’s only one timeout which is reset each time the expected recognition arrives, and begins at the next packet.

Timeout is calculated according to the RTT (Round Trip Time), the time which goes from the sending action to the acknowledge of a package. TCP will be permanently calculating RTT mean time, since each packet has a different RTT. It also calculates the standard deviation from RTT mean value.

Finally, timeout is obtained adding the standard deviation multiplied by 4 to mean RTT.

Sequence and Acknowledgment Numbers

We recall that sequence number was chosen randomly by the browser for the first message of handshake and that recognition number was chosen randomly by the Web server for the response to handshake.

Let’s take in account that TCP sees a chain of transmission data bytes instead of segments.

Let’s now try to find the rule of evolution of these numbers during the session.

When the browser finished 3 way handshake, it sent to the server a sequence number 36 and recognition number 58. It just told to the browser:

“My data block starts at byte 36 and I wait a packet from you which I only will recognize if your data block starts at byte 58”.

Let’s figure that this packet includes the GET request for desired web page and that it didn’t contain GET any data, thus having 0 bytes of data.

Let’s figure that the server has a total of 5,000 bytes of useful data (HTTP message) to transmit and that it will divide it into segments each with 500 bytes in the data field. It will therefore have to send 10 segments. The segment size (MSS), to be 520 bytes (with no options), was previously agreed between the two terminals.

Thus the server will number the bytes in the chain of data to transmit. The first packet starts at 0, the second 500, … ,the last 4500.

But as the value of the acknowledgment number 58 was passed by the browser, ie the browser said to the server he expected that the data block of the next package he would send began at byte 58, the server assigns the segments the sequence numbers 58, 558, 1058, … and 4558.

Now the server can answer to the browser. It adds the number of bytes received to the number that the browse says to match the beginning of its data block (36+0=36) and sends the first segment with data. In this segment header it palaces its sequence number 58 and its acknowledgment number 36. The server says to the browser:

“Here’s a packet in which the data field starts at byte 58. I’m waiting for you to send me a package which I only will recognize if the data field starts with byte 36”.

When the browser receives this packet, checks that it contains 500 bytes in the data field. It adds this value to the sequence number it received and obtains 500+58=558, the value it must expect to be the sequence number of the next packet it will received from the server. Then it sends a packet to the server with ACK, sequence number 36 and acknowledgment number 558. It says to the server:

“I received your packet with 500 bytes. My data block starts at byte 36 and I expect a packet from you that I will only recognize if the data field starts at byte 558”.

The server receives this packet and checks that the data block of the packet starts at byte 36. As it has no data, the data next sequence number it expects from the browser will be 36. Then it prepares the second data packet, which had numbered starting at byte 558 and sends it to the browser. The server says to the browser:

“Here’s another data packet that starts at byte 558. I expect a packet from you that I will only recognize if it starts at byte 36.”

And so on until the end of the connection. Thus, let’s try to summarize the rule as follows:

• The sequence number matches the byte of the data stream being sent where the sender data block begins, in one segment.
• The recognition number matches the byte of the data stream being received in which the sender expects to start the data block that will be sent by the recipient. Only if it will be it will recognize the package.

This is the way how TCP protocol identifies the packets of the same communication and their respective ACKs packets, in the middle of multiple streams of packets where packets can walk mixed and disorderly.

GBN or Go-Back-N protocol

Based on the graph shown in Figure 3. we will develop a better analysis of this protocol.

Let’s assume that the reception window is equal or greater than 10 packets. In this case the sender immediately uploads the network with the 10 segments resulting from the message delivered by the application.

Let’s figure that the 2nd package does not arrive at its destination. Based solely on cumulative recognition the recipient has no way to tell the sender that a packet is missing in the chain but through duplicate recognition (in triplicate and we’ll see why) of the last received packet, which is the first. Of course, when that recognition comes to the sender, all packets are in the network and probably received by the recipient.

What protocol Go-Back-N does is in this case is exactly what its name says (goes back N), i.e. the sender resends all packets since the last recognized and in a number below the value of the reception window. Therefore it sends all 9 packets that follow the first.

With reception windows of thousands of packages it’s not difficult to imagine, regarding the current volume of packets circulating in the network, the congestion it would cause.

The graph that illustrates GBN protocol highlights that whenever a packet sent is acknowledged, the timer is reset and its beginning moves to the point of issuance of next packet. In addition to be dynamic in size, it will also be sliding in accordance with recognition.

In this graph we can see that once there is a lost packet the arriving packets are no longer recognized, since ACKs are all made to the package 1, the last good packet received. As the arrow points, after 3 ACKs for packet 1 the sender starts repeating the packets beyond packet 1 (already known) until the size of reception window (in this case higher than packets missing forward).

All packets beyond the missing packet, although properly received by the recipient, are discarded and generate an ACK for the last good packet received in due order.