# TCP

![](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-6a6fe384dba5eafba39bd01ad4848498501641d2%2Ftcp.png?alt=media)

The ***Transmission Control Protocol (TCP)*** is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks

## TCP Packet

![](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-b9ab44fb39d023e59bf11a76630a8a8c81352c41%2Ftcp-packet.png?alt=media)

* ***Source Port*** (16 bits) The source port number
* ***Destination Port*** (16 bits) The destination port number
* ***Sequence Number*** (32 bits) The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.
* ***Acknowledgment Number*** (32 bits) If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent.
* ***Data Offset*** (4 bits) The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long.
* ***Reserved*** (6 bits) Reserved for future use. Must be zero.
* ***Control Bits*** (6 bits - from left to right)

| Bit | Meaning                          |
| --- | -------------------------------- |
| URG | Urgent Pointer field significant |
| ACK | Acknowledgment field significant |
| PSH | Push Function                    |
| RST | Reset the connection             |
| SYN | Synchronize sequence numbers     |
| FIN | No more data from sender         |

* ***Window*** (6 bits) The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept.
* ***Checksum*** (16 bits) The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes.

  The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header.

  This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP.

  The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), and it does not count the 12 octets of the pseudo header.

![](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-3f8fb174394c2ae21b0887e4c0a1edb4dc0a32c6%2Ftcp-pseudo-header.png?alt=media)

* ***Urgent Pointer*** (16 bits) This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set.
* ***Options*** (variable length) Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option:
  * ***Case 1:*** A single octet of option-kind.
  * ***Case 2:*** An octet of option-kind, an octet of option-length, and the actual option-data octets.

The option-length counts the two octets of option-kind and option-length as well as the option-data octets. Note that the list of options may be shorter than the data offset field might imply.

The content of the header beyond the End-of-Option option must be header padding (i.e., zero). A TCP must implement all options. Currently defined options include (kind indicated in octal):

| Kind | Length | Meaning              |
| ---- | ------ | -------------------- |
| 0    | -      | End of option list   |
| 1    | -      | No-Operation         |
| 2    | 4      | Maximum Segment Size |

* ***Padding*** (variable length) The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.

## Connection state diagram

A connection progresses through a series of states during its lifetime, that are:

* ***LISTEN*** waiting for a connection request from any remote TCP and port.
* ***SYN-SENT*** waiting for a matching connection request after having sent a connection request.
* ***SYN-RECEIVED*** waiting for a confirming connection request acknowledgment after having both received and sent a con- nection request.
* ***ESTABLISHED*** an open connection in which data received can be delivered to the user. The normal state for the data transfer phase of the connection.
* ***FIN-WAIT-1*** waiting for a connection termination request from the remote TCP, or an acknowledgment of the connection termination request previously sent.
* ***FIN-WAIT-2*** waiting for a connection termination request from the remote TCP.
* ***CLOSE-WAIT*** waiting for a connection termination request from the local user.
* ***CLOSING*** waiting for a connection termination request acknowledgment from the remote TCP.
* ***LAST-ACK*** waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request).
* ***TIME-WAIT*** waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.
* ***CLOSED*** fictional state that represents no connection state at all.

In connection state diagram, each transition shows the event that generates the transition and the operation done as response to the event.

![Example of transition](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-b6e19abc955eefa05b08439fad1237aa069fc070%2Ftcp-transition.png?alt=media)

Hence the event can be seen like the event for which a callback will be called and the operation is the set of instructions implemented in the code of the callback. The response x indicates that no action is performed.

![Connection state diagram](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-79f0cda809484fe5b9628a35874b71f08b43bddb%2Ftcp-status-transitions.png?alt=media)

## Management of packet loss

The warranty of the delivery of a packet was implemented at lower level. At layer 4, to understand if the packet is arrived to the receiver, the sender receives a packet called Acknowledgment (ACK).

When the sender sends a packet, he waits for a while. During this period, the sender is almost sure that ACK has to arrive. If it doesn't receive the ACK in this period, it sends again the same packet to the receiver. This behaviour is essential in implementation of sender code to receive a loss.

![Timeout for waiting time of ACK](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-52ddcf37cea10da86c9d96db1975952720beb705%2Ftcp-ack-timeout.png?alt=media)

If a loss of the ack occurs, the receiver must be able to handle the duplicate packet. Hence the packets need to have an indentifier that allows the receiver to be aware that packet is the same of the first one.

![Management by receiver of doubled packets.](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-1603a8662637ddf2e07429ecd93562cba30fa91c%2Ftcp-doubled.png?alt=media)

If the ACks arrive with a certain delay, we need to enumerate them. The reason can be found looking to the following figure.

![Problem with delayed ACK](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-f0711edacf90f8e03afd9aaea98da57eb3a14a85%2Ftcp-delayed-ack.png?alt=media)

If the sender sends a packet **PKT 1** and waits for its **ACK** for a timeout w. If the corresponding **ACK** arrives after w seconds, the sender has already resent **PKT 1** thinking that it's been lost. Then suppose that the sender receives **ACK** of first **PKT 1**, so it sends the next packet **PKT 2** but this will be lost. After a while the sender receives the **ACK** of second **PKT 1** but, if **ACK**s are not identified by numbers, the sender can think that the **ACK** is relative to **PKT 2\*\*\*\*PKT 2** because it already receives **ACK** of **PKT 1**.

During the latency, sending a packet and waiting for its ACK before sending the new one causes waste of time and bandwidth capacibity. ![](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-1361e51616a0eaa0338f41e71c2aa4dc39b0134c%2Ftcp-packet-transmission.png?alt=media)

We send in optimistic way more packets to fit the network capacity (pipeline), betting that the whole packet will arrive to destination. The latency becomes negletable with respect to the time needed to send all the packets.

## Segmentation of the stream

The buffer is split into segments of bytes and the numbers identify the byte positions. The identifier of the packet is the offset of the stream. The sequence number is the position (offset of the first byte in the segment). The ACK number is the first empty (not yet received) position in the stream (e.g. in Figure 8.11 if segment 1, segment 2 and segment 4 have been received all the ACK number is 21).

![](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-c245eb639cdde9e9acbfe52921e58555894bca7a%2Ftcp-stream-segmentation.png?alt=media)

## Automatic Repeat-reQuest (ARQ)

ARQ is a control strategy of the errors that detects an error (without correction). Corrupted packets are discarded and there is the request of their retransmissions.

![ARQ strategies.](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-901e2a0c9ec078365349ae9967e876e3d5ecb7a1%2Farq-strategies.png?alt=media)

![Example of ARQ.](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-3959a886e0c13e56784e98b0a739c0e038076410%2Farq.png?alt=media)

## TCP window

A variable window size is usually used and it's increased when there is no packet loss. Variable timeouts are used also in this system. If a packet is lost, the ACK is stopped because it's cumulative and the size of the window is set again to 1.

There are two types of control:

* ***Flow control*** made by receiver
* ***Congestion control*** managing packet losses

There is usually a threshold, called ssthresh, and the actual window size is called cwnd. If cwnd is less than ssthresh the window size will be doubled at next step. After the first increase of the window size up to the double of ssthresh, the window size will increase linearly in the range of \[ssthresh; 2 \* ssthresh].

![Example of window size update.](https://3928478158-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhjMjdRXwO33Lfo7uCpl6%2Fuploads%2Fgit-blob-2d179f2f2c24b35f3fbfa4ecba0045deb616cabf%2Ftcp-window-size.png?alt=media)
