TCP (Transmission Control Protocol, Fundamentals of TCP)

Kaviyarasu
31 min readMar 7, 2021
  1. What is TCP Protocol (Protocol 6)?

TCP is a connection-oriented byte-stream protocol, which provides Flow control, Error control, and Congestion control. The main functionalities of TCP are establishing a connection, Data transfer, and Terminating a connection. TCP numbers every byte it sends to provide reliable data transfer.

TCP Header

The TCP header size can be 20- 60. However, the fixed size of the TCP header is 20 bytes which includes Port number, Sequence number, Acknowledgement, Header size, Flags, Window size, Checksum, and Urgent pointer. The next 40 bytes are options.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Header Format

Note that one tick mark represents one bit position.

Port:

Port is a communication endpoint that identifies a specific process.

  1. well-known ports — 0–1023
  2. Registered ports — 1024–49151
  3. Dynamic or Private ports — 49152–65535

Source port: 16 bit

The source port number.

Destination Port: 16 bits

The destination port number.

Sequence number

TCP assigns a sequence number to each byte it sends, which is used to identify duplicate segments, out-of-order segments, and lost segments.

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.

Acknowledgement number

This field tells the sender that the next byte of data that the receiver is expecting.

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.

Header length

Shows the size of the TCP header

Reserved Bit

Reserved for future use. Must be zero.

Flags

Indicates a connection state and a type of packet.

    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 size

The received window size is advertised here. It indicates to the sender that the sender can send the amount of data at once before receiving an ACK.

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

To maintain the integrity of the data….

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.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
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.

Urgent pointer

This field is valid if the URG flag is set =1…indicates where exactly the urgent data begins and ends in a segment.

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.

TCP Three-way Handshake

TCP is a connection-oriented protocol, to establish connections, TCP has to perform a three-way handshake process. First, the client sends a SYN segment with a random sequence number to establish a connection. Then, the server sends a SYN+ACK segment with a random sequence number and also an acknowledgement for the received SYN. Finally, the client sends an ACK to the server for the SYN.

Three-way Handshake
This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

If the SYN segment carries no data, consumes one sequence number (x+1).

If the ACK segment carries no data, it consumes zero sequence number (x+0). Even if it consumes one sequence number, it will not be considered valid in the calculation.

Note that, in three-way handshake the SYN segment doesn’t have any acknowledgment number.

The window size in the SYN segment is not the true value. The one in the ACK segment is the legitimate value.

The ACK segment can be sent alone or piggybacked. Piggybacking is a method, two flags are set in a single segment to avoid latency, for instance, SYN+ACK, FIN+ACK, and PSH+ACK.

Some important things that have to be noticed in the Options field are. (Maximum segment size, Window Scale, and SACK permitted).

Sequencing

TCP uses sequence numbers to identify each segment it sends and receives, also used by the receiving TCP for reassembling the out-of-order segments. Sequencing also helps in Error control. Initially, TCP starts a random sequence number, but for the intermediate segments (if they carry any data) DATA + SEQ, for example, if TCP receives a segment with seq 100 and 1400 bytes of data, it will send the ACK with 1500.

Sequence and Acknowledgement numbers are primarily used to prevent duplicate segments.

Acknowledgement = received DATA (bytes) + Received Sequence number

1500 = 1400 bytes + 100

Starting sequence number is always random, the range is 0–4294967296 because the size of the sequence field is 32 bits in the header, hence 2³²= 4294967296.

Segmentation

TCP groups bits into bytes and bytes into segments, because TCP handles bytes only. TCP receives data from the upper layer and divides them into smaller segments. The MSS (Maximum Segment Size) determines the maximum size of a single segment. The MSS can be 0– 65535, but the MSS for TCP is 1460 bytes since the MTU of the ethernet frame is 1500 bytes.

MTU (1500) — IP header (20) — TCP header (20)= MSS (1460)

1500–20–20 = 1460

Out-of-Order Segments

Nowadays, TCP does not discard any out-of-order segments. Instead, it temporarily stores them and flags them as out-of-order segments until the missing segment arrives. , TCP uses these sequence numbers from the TCP header to place data in the right position inside the receive buffer. Therefore, even if packets arrive out of order, they are always arranged in the right order. For example, data in Packet 2 will never be sent to the application before data in Packet 1, even though Packet 2 may arrive first.

TCP Flags

In TCP, flags are used to indicate a particular connection state or to provide additional information. The most commonly used flags are SYN, ACK, FIN, RST, PSH, and URG.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

i) Synchronization (SYN)

It is used in the first step of connection establishment by sending sequence numbers during the three-way handshake to initiate a connection. Only the first segment of the client and server will always have this flag set.

ii) Acknowledgment (ACK)

It is used to acknowledge segments that are successfully received by the receiver.

ACK
A control bit (acknowledge) occupying no sequence space, which indicates that the acknowledgment field of this segment specifies the next sequence number the sender of this segment is expecting to receive, hence acknowledging receipt of all previous sequence numbers.

No ACK will be sent for ACK segments If they don’t carry any data.

Cumulative acknowledgement and Selective acknowledgement

Cumulative ACK

The acknowledgement always announces the next sequence number that is expected by the receiver. TCP can send acknowledgements for individual segments or one ACK for a group of segments.

Selective ACK

SACK does not replace ACK but, provides additional information. Such as fast retransmission, duplicate segments, Duplicate ACKs, and Out-of-order segments.

Duplicate ACKs

TCP sends duplicate ACKs for Out-of-order segments and missing segments. Whenever TCP receives Out-of-order segments, it stores them and flags them as Out-of-order segments. However, it will continuously send duplicate ACKs, until it receives the missing segment.

iii) Finish (FIN)

It is used to request connection termination. When the sending TCP has no more data for the receiver, it requests connection termination. After the FIN segment is sent, the sending TCP will not send any data, but it will continuously receive segments and send ACKs until it receives a FIN.

FIN
A control bit (finis) occupying one sequence number, which
indicates that the sender will send no more data or control occupying sequence space.

FIN can be sent alone or piggybacked (FIN+ACK).

The FIN segment might carry data.

iv) Reset (RST)

It is used to terminate, deny, and abort connections. If TCP detects any unauthorized access or sequence mismatch, it sends an RST segment and closes the connection, and throws away all the queued data. On the other side, TCP receives the RST and closes the connection, and throws away all the queued data.

As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection.  A reset must not be sent if it is not clear that this is the case.

The RST flag can be sent alone or piggybacked, for example, RST+ACK.

The RST segment will not carry any data.

Note that, no ACK segment is generated in response to the RST segment.

Denying a connection

The TCP on one side may request a connection, but the server port on the other side may not be in the active state at the moment, so the receiving TCP sends an RST segment. Then, brings the port to the active state.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

Aborting a connection

One TCP may want to abort an existing connection due to an abnormal situation, so it terminates the connection by sending an RST+ACK and throws away all the data in the queue.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

Terminating an IDLE connection

If sending TCP sends some data and goes silent, the receiving TCP on the other side may send an RST segment to terminate the idle connection.

v) Push (PSH)

It is used to send data immediately. If a segment is set PSH = 1, the sending buffer doesn’t wait to get filled (doesn’t wait to reach the MSS), so it just forwards the data to the destination. It prevents latency.

Data should be immediately pushed through to the receiving user by the setting of the PUSH flag.

The purpose of the push function and the PUSH flag is to push data from the sending TCP to the receiving TCP. It does not provide a
recorded service. When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process.

vi) Urgent (URG)

If URG is set = 1, the data in the segment is important and needs to be delivered to the application process as soon as it reaches the receiving TCP. Even though it is a URG segment, it is also treated like other segments, except it has some urgent data.

The general thought is that the receiving process will take action to process the urgent data quickly.

The URG control flag indicates that the urgent field is meaningful and must be added to the segment sequence number to yield the urgent pointer. The absence of this flag indicates that there is no urgent data outstanding

The URG flag indicates that only it has some urgent data and that data must be processed immediately.

Flow Control

TCP has windows for flow control. Both TCPs advertise their respective receive window sizes. The receive window size refers to the number of bytes that the receiver can receive at any given time. It prevents the receiver from getting overwhelmed. By advertising, the window size the receiver announces that it can receive this amount of data at a time.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

TCP buffer

Buffer is a memory location where data can be stored before they are processed, TCP on both sides will have buffers. The receiving TCP stores the received data in its receive buffer until the application reads the entire data. Once the application reads the data in the buffer, it will start receiving new data. When an application needs to send data out, it does not construct a packet directly; instead, it places data into the TCP send buffer. The TCP code inside the operating system decides when to send data out. To avoid sending packets with small data and therefore waste network bandwidth, TCP usually waits for a little bit, such as 200 milliseconds, or until the data are enough to put into one packet without causing IP fragmentation. However, the sent data will be kept in the send buffer until they are acknowledged, once the data are acknowledged, the buffer will remove the data and receives new data from the application layer.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

The receiving TCP receives segments and sends ACK. Although, the received data will be stored in the receive buffer until they are processed completely.

Window size — the amount of free space available in the receive buffer. The size of the TCP receive-buffer can be 0–65535.

However, TCP can increase the window size (more than 65535) with the help of Window size scaling factor, by multiplying the window size by the Scaling factor.

The receiving TCP delivers only the ordered data to the process.

TCP WINDOW

TCP uses windows for storing data and send them later. There are two types of windows available in TCP that are Receive Window and Send Window. The window size field refers to the amount of free space available in the TCP window. TCP window is used for Flow control, Error control, and Congestion control. The window size can be 0–65535 but the original window size can be more than that.

Original window size = Window size multiply by Window size scaling factor

i) Receive Window

TCP Receive window receives data, sends acknowledgements, and also stores the received data in its receive buffer for the application to process the entire data. After the data in the buffer are processed, it will start receiving new data. Sometimes the sending window size is determined by the receiving TCP. If the receive buffer is overwhelmed, it sends a flow control message (Window size 0) to the sender TCP to stop sending data. After the data in the buffer are processed, it sends an ACK to the sender to send the next byte.

The receiving TCP advertises its window size. It tells the sender that the amount of data that the sender can send before receiving an ACK.

When the receive buffer gets enough data (or waiting time is enough), TCP will make the data available to the application. Normally, applications would read from the receive buffer, and get blocked if no data is available. Making data available will unblock the application. TCP will not unblock the application as soon as data have arrived, it waits until there are enough data or enough waiting time has elapsed.

Received Window= Buffer size — stored bytes

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

ii) Send Window

The send Window can store data and send them later. The Sending TCP sends data, also keeps the sent data in its buffer until they are acknowledged. Once the data are acknowledged, it sends the next byte of data and pulls data from the application process.

The sending window is flexible.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

iii) Shrinking of Windows

According to the receiver's window size, the sending TCP can shrink its window size by moving the right wall to the left. However, it is strictly discouraged.

iv) Pushing or Pulling

The segment delivery in TCP connection can occur in one of two ways, Pushing or Pulling.

If the sender sends data whenever they are produced; without any acknowledgement (request) from the receiver, it is referred to as Pushing.

If the sender sends data after it has received an acknowledgement (request) from the receiver, it is referred to as Pulling.

v) Sliding Window

The sliding window adjusts its window size by sliding the buffer. For example, The sending TCP sends bytes 0,1,2,3,4,5,6 and the window is full which means no more data can be accepted from the application process. When it receives an ACK for 0, it slides the window by 1. Whenever the sliding window receives an ACK, it slides or increases the window size.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

vi) Opening and closing window

TCP forces sender and receiver to adjust their window sizes, even though the buffer size of both parties is fixed during the three-way handshake. Receiving window closes (moves its left wall to the right) when more bytes arrive from the sender; it opens (moves the right wall to the right) when the application pulls some data. Remember, the window does not shrink (moves the right wall to the left).

vii) Window Shutdown

The receiving TCP can temporarily shut down the sending window by sending a Received window size 0 if the receiving TCP does not have enough storage to receive data from the sender. The sending TCP does not shut its window but stops sending data until a new advertisement has arrived. However, it sends Probes to avoid deadlock.

Silly Window Syndrome

A Silly window syndrome is a serious problem in TCP. This problem occurs either when the sender produces more data slowly than usual or the receiver consumes data slowly. For example, If the sender sends 1 byte of data, it means a 41-byte datagram (20 byte TCP header, 20 byte IP header). Which indicates that the capacity of the network is being used inefficiently.

i) Syndrome created by the sender

The sending application may create a silly syndrome by slowly producing data, for example, 1 byte at a time. Which leads the TCP to send 1-byte segments. The sending TCP must be forced to wait until it gets enough data to construct a segment to prevent this. How long the TCP has to wait? If it doesn’t, it may end up sending small segments. To solve this problem Nagle found an elegant solution.

Nagle’s Algorithm

1. The sending TCP sends the first piece of data it receives from the sending application program even if it is only 1 byte.

2. After sending the first segment, the sending TCP accumulates data in the output buffer and waits until either the receiving TCP sends an acknowledgement or enough data has accumulated to fill the maximum- segment size. At this time, the sending TCP can send the segment.

3. Step 2 is repeated for the rest of the transmission. Segment 3 is sent immediately if an acknowledgement is received for segment 2, or if enough data have accumulated to fill a maximum-size segment.

The elegance of Nagle’s algorithm is in its simplicity and in the fact that it takes into account the speed of the application program that creates the data and the speed of the network that transports the data. If the application program is faster than the network, the segments are larger (maximum-size segments). If the application program is slower than the network, the segments are smaller (less than the maximum segment size).

ii) Silly syndrome created by the receiver

The receiving TCP may create a silly syndrome if the application on the receiving side consumes data slowly. For example, the consumer consumes 1 byte at a time and the sender sends 10 bytes at a time. The window size of the receiving TCP is 50 bytes, after receiving 50 bytes of data, the receiving TCP sends receive-window -zero therefore, the sender has to stop sending data. Later the consumer consumes 2 bytes, now 2 bytes of free space in the buffer, so, it sends receive window size 2 and the sender sends 2 bytes of data. To solve this problem there are two solutions available.

Clark’s Solution

Clark’s solution is to send an acknowledgement as soon as the data arrive but to announce a window size of zero until accumulating enough space to accommodate a maximum size segment or until at least half of the receive buffer is free.

Delayed Acknowledgement

The second solution is to delay sending an acknowledgement. This means when a segment has received, it is not acknowledged immediately, but waits for the buffer to get sufficient space, after the TCP gets some space it sends an ACK. By delaying acknowledgement the sender TCP is prevented from sliding its window, which reduces traffic and kills silly syndrome, but delayed acknowledgement may cause spurious retransmission. To prevent this the acknowledgement should not be delayed by more than 500 ms.

TCP sub-protocols

i) Simple protocol

A simple protocol is a connectionless protocol with neither flow control nor error control. We assume that the receiver can immediately handle any packets it receives. The transport layer at the sender side receives data from the application layer and encapsulates it, and sends it. The transport layer at the receiver side receives the data and decapsulates it, and delivers it to the application layer. The transport layers of the sender and receiver provide the transmission services.

ii) Stop-and-wait Protocol

The Stop-and-wait protocol is connection-oriented, which uses both flow and error control. Both sender and receiver use sliding window size 1. The sender sends one packet at a time and waits for an ACK before sending the next one. The sending TCP adds checksum to every segment it sends. The receiving TCP on the other side receives the packet and does the checksum calculation if the checksum is incorrect, the receiver silently discards the corrupted packet. This silence indicates to the sender that the packet might have been discarded or corrupted, so it resends the segment (TCP uses a Retransmission timer for this). When the sender sends a segment, it starts a timer. If an ACK doesn’t arrive before the time expires, the sender resends the lost or corrupted segments. If the sender receives an ACK, it stops the timer, sends the next segment, and starts a new timer. This means the receiver has to keep the sent data in the buffer until they are acknowledged.

In Stop-and-wait protocol, the sender is forced to wait for acknowledgments.

All calculation in the Stop-and-wait protocol is in modulo of 2.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

Ready state

When the sender is in this state, it is only waiting for one event to occur. If the sending TCP receives data from the application process, it creates a packet with a sequence number set to O. A copy of the packet is stored and the packet is sent. The sender starts the timer and moves to the blocking state.

Blocking state

When the sender is in this state, three events occur.

1.If an error-free ACK arrives with ackNo related to the next sequence number to be sent which means ackNO=O+1, it stops the timer and slides the window size.

2. If a corrupted ACK or an error-free ACK arrives with ackNO=O+0, the ACK is discarded.

3. If the timer expires, it resends the outstanding segments and restarts the timer.

iii) Go-Back-N Protocol

Go-back-N protocol is a connection-oriented protocol that uses Error control and Flows control. The sending window uses a window size of 2^m-1 and the receiving window uses a window size of 1. The sending TCP sends some segments and keeps the copies in its buffer until they are acknowledged. The receiving TCP receives only the ordered segments, also discards the out-of-order segments.

Ready state

When sending TCP is in this state three events happen.

  1. If the sending TCP receives a request from the application, it creates a packet and sends it.
  2. Keeps the copies in the buffer for acknowledgements to arrive.
  3. TCP moves to block state and wait for an ACK.

Block state

When TCP is in this state three events happen.

  1. If an error-free ACK arrives, it slides the window.
  2. If a corrupted segment arrives, it is discarded.
  3. If the time expires, the outstanding bytes are retransmitted.

Error control

TCP is reliable because it provides Error control. TCP uses Sequence numbers and acknowledgement numbers to provide reliable data delivery. Mostly, TCP uses Error control for

  1. Detect and discard corrupted segments.
  2. Keep track of lost and discarded segments and resend them.
  3. Recognize duplicate segments and discard them.
  4. Buffer out-of-order segments until the missing segment arrives.

TCP's error control is achieved by using three simple tools; Checksum, Sequence & acknowledgement, and timers.

i) Checksum

Each segment contains a 16-bit checksum field which is used for error checking. The checksum calculation is done by sending TCP. When a segment arrives at the destination, the receiving TCP does the checksum calculation if the values don’t match, the segment is considered a corrupted segment, so it is discarded.

Checksum= TCP header + Pseudo header ( source IP, destinatin IP, protocol number, and payload)

ii) Sequence numbers

TCP assigns a sequence number to every segment it sends to provide reliable data delivery. Sequence number helps to identify lost and corrupted segments, so they can be retransmitted. Also helps to identify duplicate segments, by looking at the sequence field TCP can identify duplicate segments that have already been received. Sequence numbers are also used to identify and reassemble out-of-order segments.

iii) Acknowledgement numbers

TCP uses ACK numbers to acknowledge the received segments. Either it can send an ACK for each segment or a bunch of segments. The sending TCP sends some segments and starts a timer and waits for an ACK. If the sender receives an ACK before the time expires, it sends the next byte. If it doesn’t, it retransmits the segments.

The ACK number always announces the next sequence number that the receiver is expecting, also indicates to the sender that the segments before the Acknowledgement number are successfully received.

Timers

TCP has four timers for reliable data transfer. Those are Retransmission timer, Persistent timer, Keepalive timer, and TIME-WAIT timer.

i) Retransmission timer (RTO)

TCP sets a retransmission time-out for every segment it sends. The sending TCP sends data and starts an RTO timer. If an ACK does not arrive before the time expires, the segment is considered a lost or corrupted segment and the sender retransmits the segment, but this time the RTO is doubled. This process continues up to three or many times until it receives an ACK.

for each retransmission, the RTO is doubled.

The initial RTO value is 3 sec.

Two minutes is recommended for the retransmission interval when the window is zero.

The lowest RTO in windows is 300 ms and in Linux, it is 200 ms.

TCP retransmits only the Outstanding segments (in-flight).

RTO=RTTs + 4*RTTd

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

ii) Fast Retransmission

Whenever TCP receives three or more duplicate ACKs (except the first, others are duplicates) it will not wait for the time to expire, it just resends the previous segment (the lost segment).

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

iii) Spurious Retransmission

This type of retransmission is suspected retransmission because the ACK may not reach on time or be discarded. If a TCP receives the segment again (Duplicate segment), it will mark it as Spurious retransmission.

TCP sends a segment and receives an ACK for the sent segment, but the received ACK is corrupted, so the TCP discards the ACK and resends the segment, this retransmission is also called spurious retransmission.

The valid range is 1–3, the default value is 2.

An Example Retransmission Timeout Procedure

Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number (segments sent do not have to match segments received). This measured elapsed time is the Round Trip
Time (RTT).
Next compute a Smoothed Round Trip Time (SRTT) as:

SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)

and based on this, compute the retransmission timeout (RTO) as:

RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]

where UBOUND is an upper bound on the timeout (e.g., 1 minute),
LBOUND is a lower bound on the timeout (e.g., 1 second),
ALPHA is a smoothing factor (e.g., .8 to .9), and BETA is a delay variance factor (e.g., 1.3 to 2.0).

iv) Persistent Timer

TCP uses the persistent timer to deal with the zero-window-size deadlock situation. When the receive buffer has no space, it sends a received window zero to the sender to stop sending data. After the receiving TCP gets some free buffer space, it sends an ACK with a non-zero received window size. If this segment is lost, both TCPs have to be waiting for a long time (ACK segments are not retransmitted unless they carry any data). To prevent this situation, TCP sets the persistent timer, when this timer goes off, the sending TCP sends a Probe. This segment contains 1 byte of data and a sequence number, but this sequence will not be calculated and acknowledged. The receiving TCP receives the Probe and resends the ACK which was lost. If the sender did not receive the ACK again, it resends the Probe and doubles the persist timer (usually 60s) until it receives an ACK.

Persistent time for 1st probe 5 sec

Persistent time for 2nd probe 10 sec (2*5= 10)

Will continue to increase up to 60 sec, because the persistent timer is always bounded between 5 and 60 seconds. After reaching 60sec, Window probes continue to be sent at 60-second intervals until the window opens up or either of the applications using the connection is terminated.

v) Keep alive timer (keep TCP alive)

TCP uses a keep-alive timer to prevent a long idle connection between two TCPs. When a TCP sends some data and goes silent for a while, the receiving TCP sends keep-alive messages to check whether the sending TCP is active or crashed. Sometimes, it is also used to prevent Deadlock.

Keep-alive
  1. Checking for dead peers

2. Preventing disconnection due to network inactivity.

Keepalive messages are sent every 45 sec.

vi) TIME-WAIT Timer (2MSL)

It is used during connection termination. (Normally 4 min)

If the time-wait timeout expires on a connection delete the TCB,
enter the CLOSED state and return.

MSL
Maximum Segment Lifetime, the time a TCP segment can exist in the internetwork system. Arbitrarily defined to be 2 minutes.

vii) USER TIMEOUT

if the user timeout expires, flush all queues, signal
the user "error: connection aborted due to user timeout" in general
and for any outstanding calls, delete the TCB, enter the CLOSED
state and return.

The default user timeout is 5 min.

viii) Lost Segments

Lost segments are discarded somewhere in the network, due to network congestion.

ix) Corrupted segments

Corrupted segments are discarded by the receiver itself, due to checksum mismatch.

TCP States

TCP has several States to provide reliable connections. In TCP, the server is always in Listen state passively; waiting for SYN.

The client issues an active open by sending SYN and goes to SYN-SENT state; waiting for ACK.

The server that is in passive open receives the SYN, sends SYN+ACK, and goes to SYN-RECVD state; waiting for ACK.

The client sends the ACK and goes to the Established state. The server receives the ACK and goes to the Established state.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

After data transfer, the client sends a FIN or FIN+ACK and goes to FIN-WAIT-1 state: waiting for FIN or ACK.

The server receives the first FIN, sends an ACK, and goes to CLOSE-WAIT state; waiting for the application to close (if the server also wants to terminate the connection, it will send a FIN+ACK and goes to the LAST-ACK state). The server TCP remains in this state until the application initiates a close command.

The client receives the ACK and goes to FIN-WAIT-2; waiting for a second FIN (if the client receives a FIN+ACK, it will go to the TIME-WAIT state).

The server sends a FIN and goes to the LAST-ACK; waiting for ACK.

The client receives the FIN, sends an ACK and doubles the MSL timer (Maximum segment Lifetime), goes to TIME-WAIT state.

MSL (2 min) = 2 min + 2 min= 2MSL (4 minutes)

The server receives the ACK and both terminate the connection simultaneously.

TCP states

Congestion Control

Congestion occurs when a node or link carries more data than it can handle, thus, the quality of service is reduced. Whenever TCP queues data due to some problem, it creates congestion. When the queued packets reach the gateway, it may create congestion because the router may not be able to handle all the packets at the moment, so this may create congestion.

i) Open-loop congestion control

In open-loop congestion control, Policies are applied to prevent congestion before it occurs. In this mechanism, congestion control is handled by either the source or the destination.

Retransmission policy

Retransmission may create network congestion. However, a good retransmission policy can solve this issue.

Acknowledgement Policy

Delayed acknowledgements may create network congestion by slowing down the sender. A good acknowledgement policy can resolve this issue.

ii) Closed-loop Congestion Control

The Closed-loop congestion mechanism tries to reduce the congestion after it happens. The size of the sending window can be flexible. One factor that can determine the sending window size, is congestion in the network. The sending Transport layer can monitor the congestion in the network by looking at the lost packets and uses this strategy to decrease the window size if the congestion increases and vice versa.

iii) Full-duplex communication

TCP offers a full-duplex connection, thus, data can flow bi-directionally (both directions) at the same time.

iv) Multiplexing and Demultiplexing

To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.

The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed
through the known addresses. Establishing and learning the port
addresses of other processes may involve more dynamic mechanisms.
Multiplexing and Demultiplexing

Whenever a device or computer receives data from more than one source, it is referred to as Demultiplexing (Many-to-one); Whenever a device or computer sends data to more than one destination, it is referred to as Multiplexing (One-to-many). The transport layer at the sender side performs Multiplexing and the transport layer at the receiving side performs Demultiplexing.

TCP Four-way handshake

i) Simultaneous open

TCP performs a four-way handshake process to establish a connection between two Peers (Peer to Peer) that know their port numbers. In the three-way handshake, the client sends SYN and the server sends SYN+ACK but in the four-way handshake, both the clients send SYNs simultaneously at the same time and go to the SYN-SENT state. Both receive SYNs, send the SYN+ACKs at the same time and go to SYN+RCVD state. Then, both receive SYN+ACKs and go to an ESTABLISHED state for data transfer.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

ii) Simultaneous close

For connection termination, they perform a Four-way handshake. First, the client sends a FIN and at the same time, the server sends an ACK. Then, both go to FIN-WAIT 1. Secondly, the client receives an ACK and sends an ACK; at the same time, the server receives the FIN and sends a FIN, go to the Closing state. Finally, both receive the segments and go to the TIME-WAIT state.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

iii) Connection Termination

TCP performs a Three-way or Four-way handshake for connection termination. If the sending TCP doesn’t have any data for the receiver, it will send a FIN segment by announcing that it has no more data for the receiving TCP, and it is closing the connection, but it will still receive data and send an ACK until it receives a FIN. The server receives the FIN and sends an ACK for the FIN. If the server also wants to terminate the connection, it will send a FIN+ACK and wait for the ACK, after the ACK is received, both will terminate the connection simultaneously.

This picture is taken from a TCP/IP book written by Behrouz A. Foruzan.

Options

The size of the TCP options field is 40 bytes which include MSS, Window scale, SACK permitted, and Timestamps.

i) MSS

The MSS (Maximum Segment Size) determines the maximum amount of data that an IP packet can carry. Which has been negotiated during the Three-way handshake.

The MSS value is flexible because in-flight any middle router can decrement this value according to its MTU, also if the options increase, the MSS value decreases.

If the SYN segment doesn’t have an MSS value, it will send 536-byte segments.

ii) Window scale

The maximum window size can be 65535. However, TCP can increase the window size (more than 65535) by multiplying the window size by the Scaling factor.

If the server can not use a window scale, the client also can not use a window scale.

iii) SACK Permitted

This field tells the receiver that it can support Selective Acknowledgement.

If SACK is not present in the Three-way-handshake. They can not support Fast retransmissions, Duplicak segments, .etc

iv) Timestamps

TCP uses this field to measure latency (TTL).

v) No-Operation

It is just padding.

vi) Stream Index

It identifies a specific TCP connection, there can be many TCP connections at a time. starting from 0.

Attacks on TCP

i) SYN flooding attack

The SYN flooding attack is executed, by sending a large number of SYN packets with random Source IP and Port numbers. When a server receives the duplicate SYN packets, it creates TCB (Transmission Control Block) and sends SYN+ACKs to the fake clients (the connection between Client and server is only confirmed so it is called half-open), by this time if a legitimate client requests for a TCP connection, it is rejected due to lack of resource.

Solution

The server uses SYN Cookies to solve this issue. When a server receives a SYN packet, it calculates a keyed hash (H) from the information in the packet using a secret key that is only known to the server. This hash (H) is sent to the client as the initial sequence number from the server. The H is called SYN cookie. Meanwhile, the server will not store the half-open connection in its queue. If the client is an attacker, H will not reach the attacker. If the client is not an attacker, it sends H+1 in the acknowledgement field. The server checks if the number in the acknowledgement field is valid or invalid by recalculating the cookie.

With the SYN cookies mechanism, SYN flooding attacks can be effectively defeated. Although attackers can still flood the server with many SYN packets, they will not be able to consume the server’s resources, because nothing is saved. Attackers can also flood the server with many ACK packets, but because they do not have valid SYN cookies in the acknowledgement field, they will not trigger resource allocation on the server.

ii) RST attack

The objective of the TCP RST attack is to break up the active legitimate TCP connections. When two devices establish a TCP connection to share data, the attacker may send RST packets to break up the TCP connection.

To execute the attack, the following fields need to be set correctly:

● Source IP address, Source Port

● Destination IP address, Destination Port

● Sequence number (within the receiver’s window)

Solution

You can use the tcp ack-rst-and-syn command to help protect the router from DoS attacks.

When you enable the tcp ack-rst-and-syn command, the router challenges any RST or SYN messages that it receives by sending an ACK message back to the expected source of the message. The source reacts in one of the following ways:

  • If the source did send the RST or SYN message, it recognizes the ACK message to be spurious and resends another RST or SYN message. The second RST or SYN message causes the router to shut down the connection.
  • If the source did not send the RST or SYN message, the source accepts the ACK message as part of an existing connection. As a result, the source does not send another RST or SYN message and the router does not shut down the connection.
  • (config)#tcp ack-rst-and-syn

This solution is also suitable for SYN flooding attacks.

TCP Sission Hijacking Attack

When a connection is established between two hosts, the connection is supposed to be used only by these two hosts. If an attacker can inject his/her own data into this connection, the connection can essentially be hijacked by the attacker, and its integrity will be compromised.

It allows attackers to inject spoofed data into an existing TCP connection between two target peers.

TCP session hijacking attacks can be decreased using encryption, but the other two attacks cannot benefit from encryption. Some improvements have been made to the TCP protocol to make the attacks difficult, including randomizing the source port number, randomizing the sequence number, and adoption of the SYN cookies mechanism. However, completely solve the security problems faced by TCP without changing the protocol is difficult.

--

--

Kaviyarasu
0 Followers

My name is Kaviyarasu and I have completed CCNA. Currently, I'm looking for a job in Marketing and Sale. Contact kavi943b@gmail.com for further information