TCP

TCP is defined in RFC 793, RFC 1122, RFC 2018, RFC 5681, RFC 7323.

The TCP connection

TCP is connection-oriented because two processes must first establish a connection via a handshake before exchanging data.

During this setup, they exchange preliminary segments to agree on connection parameters, and both sides initialize TCP state variables.

A TCP connection:

• consists of:
  1. buffers (send and receive)
  2. variables (state information, sequence numbers, congestion control state, timers, connection endpoints)
  3. sockets
• is point-to-point, between a single sender and a single receiver
• provides full-duplex communication, so data can flow simultaneously in both directions (A → B and B → A)
• does not support multicasting (transfer of data from one sender to many receivers in a single send operation)

Once a TCP connection is established:

• the client writes a stream of data to the socket
• TCP places the data in the connection's send buffer
• TCP periodically takes data from the send buffer and sends it to the network layer as segments
• segment size is limited by the Maximum Segment Size (MSS):
  • the maximum application-layer data in a TCP segment
  • derived from the link-layer Maximum Transmission Unit (MTU) and negotiated during the TCP handshake
  • typical MTU (Ethernet, PPP) ≈ 1500 bytes
  • typical MSS ≈ 1460 bytes

The network layer encapsulates TCP segments into IP datagrams and sends them across the network.

At the receiver:

• incoming segment data is stored in the TCP connection's receive buffer
• the application reads the stream of data from this buffer

TCP header

Header fields:

Byte stream:

    SEQ:        0               1000            2000             3000
                |---------------|---------------|---------------|
    bytes:      ABCDEFGHI       JKLMNOPQR       STUVWXYZ        ...

TCP segments:

    Segment 1
    SEQ=0
    bytes=ABCDEFGHI
    carries bytes 0–999

                    Segment 2
                    SEQ=1000
                    bytes=JKLMNOPQR
                    carries bytes 1000–1999

                                Segment 3
                                SEQ=2000
                                bytes=STUVWXYZ
                                carries bytes 2000–2999

RTT estimation and timeout

How large should TCP timeout intervals be?

They should be larger than the round-trip time (RTT) to avoid premature retransmissions.

TCP estimates RTT using three measurements:

Sample (in ms)	Description
SampleRTT	The time between sending a TCP segment and receiving its ACK. TCP does not use SampleRTT measurements for retransmitted segments because it cannot know whether the ACK acknowledges the original transmission or the retransmission, making the RTT measurement ambiguous: Time 0 ms: send segment (original) Time 100 ms: retransmit segment Time 150 ms: receive ACK Measured time: send → ACK = 150 ms Possible RTT: - original transmission: 150 ms - retransmission: 50 ms
EstimatedRTT	Network conditions vary due to congestion in the routers and/or load on the end systems. So TCP smooths SampleRTT values using a running average called EstimatedRTT: EstimatedRTT = (1- α) * EstimatedRTT + α * SampleRTT where α = 1/8 = 0.125 (RFC 6298) EstimatedRTT is an exponential weighted moving average (EWMA): recent measurements have more influence than older ones this is natural because recent values better reflect current network conditions For the first RTT measurement, TCP initializes EstimatedRTT with SampleRTT.
DevRTT	The deviation in the RTT measures how far SampleRTT deviates from EstimatedRTT. DevRTT = (1- β) * DevRTT + β * |SampleRTT - EstimatedRTT| where β = 1/4 = 0.25 (RFC 6298) Intuition: if SampleRTT values have little fluctuation → DevRTT will be small if there is a lot of fluctuation → DevRTT will be large

Then, it uses these RTT measurements to estimate the timeout interval:

• timeout is set:
  • above EstimatedRTT to avoid unnecessary retransmissions
  • but not too much larger than EstimatedRTT, otherwise:
    • when a segment is lost
    • TCP would not quickly retransmit the segment
    • leading to large data transfer delays
• so TCP adds a safety margin to the EstimatedRTT using DevRTT, which is:
  • large when there is a lot of fluctuation in the SampleRTT values
  • small when there is little fluctuation
• TimeoutInterval = EstimatedRTT + 4 * DevRTT
  • an initial TimeoutInterval value of 1 second is recommended (RFC 6298)
• when a timeout occurs:
  • TCP doubles TimeoutInterval (exponential backoff) to reduce the chance of repeated premature retransmissions during congestion
• when an ACK provides a valid SampleRTT measurement:
  • TCP updates EstimatedRTT and DevRTT
  • TimeoutInterval is computed again using the formula

Reliable data transfer

IP is unreliable:

• datagrams may be lost (e.g., buffers can overflow)
• datagrams may arrive out of order
• datagrams may be corrupted (bits can flip)

Because of this, IP only offers a "best effort" service.

TCP adds reliability on top of IP. It ensures that data received by an application is:

• uncorrupted
• without gaps
• without duplication
• in sequence (the byte stream is exactly the same byte stream that was sent)

TCP timer mechanism

TCP uses timers for reliability:

• associating a single timer for each segment would be too costly
• instead, TCP (per RFC 6298) uses a single retransmission timer (RTO) per connection
• this timer tracks the oldest unacknowledged data

If the timer expires, TCP retransmits unacknowledged data and adjusts its timeout estimate.

Simplified interesting scenarios:

Scenario	Diagram
One segment is sent: its ACK is lost Host A retransmits after a timeout Host B recognizes that the sequence number corresponds to data already received Host B discards the retransmitted data and resends the ACK
Two segments are sent: both arrive correctly at Host B, which sends cumulative ACKs the ACKs are delayed and do not reach Host A before the timeout Host A assumes loss and retransmits only the oldest unacknowledged segment, because TCP assumes later data may already have been received and buffered Host A restarts its timer before the new timeout expires, the delayed ACKs finally arrive at Host A, acknowledging both segments since the second segment is now acknowledged, it is not retransmitted
Two segments are sent: one ACK is lost, but a later cumulative ACK confirms all data was received Host A does not retransmit anything

Doubling the timeout interval

Most TCP implementations change how the timeout is calculated after a timeout occurs:

When TCP retransmits a packet:

• the next timeout is set to twice the previous timeout rather than deriving it from the last EstimatedRTT and DevRTT
• this causes the timeout interval to grow exponentially after repeated retransmissions

When there is no retransmission:

• TimeoutInterval is derived from the most recent values of EstimatedRTT and DevRTT

This acts as a simple form of congestion control, because timeouts are usually caused by network congestion.

By waiting longer between retransmissions, TCP avoids making congestion worse.

Fast retransmit (retransmission before timeout)

Timeout-based retransmissions introduce delay because the sender detects a lost segment only after the retransmission timeout (RTO) expires.

To detect loss earlier, TCP uses duplicate ACKs:

• when the receiver detects a gap in the sequence numbers, it sends another ACK for the last in-order byte received
• after three duplicate ACKs, the sender assumes the missing segment was lost and retransmits it immediately, without waiting for the timeout

This mechanism is called fast retransmit.

Is TCP a GBN or a SR protocol?

Instead of acknowledging every segment it receives, the TCP receiver acknowledges the longest in-order sequence of data received.

This is similar to the acknowledgment strategy used in Go-Back-N (GBN).

However, TCP differs from GBN:

• TCP receivers buffer out-of-order segments
• if one ACK is lost, TCP usually retransmits only the missing segment, not everything after it
• example:
  • segments 1, 3, 4 are sent successfully but the ACK for segment 2 is lost
  • GBN retransmits segment 2 and all later segments
  • TCP retransmits at most segment 2 and may not retransmit anything if a later ACK arrives in time

With Selective Acknowledgment (SACK), TCP becomes even closer to Selective Repeat (SR):

• the receiver can explicitly report which out-of-order segments were received
• the sender retransmits only the missing data

Thus, TCP's error-recovery mechanism is best viewed as a hybrid of GBN and SR.

Flow control

TCP is full-duplex, so each host maintains a receive buffer for every connection (each socket has its own send and receive buffer):

• incoming TCP data is stored in the receive buffer
• the receiving application reads from this buffer
• if the receiving application reads slowly, the sender may overflow the buffer by sending too fast

To prevent this, TCP provides flow control, a speed-matching service between:

• rate at which the sender is sending
• rate at which the receiving buffer is read

This is different from congestion control, which slows the sender due to network congestion. Both throttle the sender, but for different reasons.

How TCP flow control works:

• each TCP receiver has a buffer of size RcvBuffer
• the free space in this buffer is the receive window rwnd:
  • it changes dynamically as data is read
  • initially, rwnd = RcvBuffer

Example:

• Host A sends data to Host B
• Host B advertises its current rwnd in TCP segments sent back to Host A
• this tells Host A how much buffer space is available
• Host A:
  • tracks LastByteSent – LastByteAcked = unacknowledged data in flight
  • ensures unacknowledged data in flight ≤ rwnd to guarantee the receiver buffer is never overflowed

Zero window problem:

• Host B's receive buffer becomes full and advertises rwnd = 0
• Host A stops sending data
• later, Host B's application frees buffer space, but Host B has nothing more to send, so Host A is not informed that rwnd has increased

TCP solution:

• Host A periodically sends small probe 1-byte segments when rwnd = 0
• Host B acknowledges each probe
• once buffer space becomes available, acknowledgments include a nonzero rwnd, allowing Host A to resume sending

In contrast, UDP does not provide flow control, so receiver buffers can overflow and data may be lost.

TCP connection life

During the life of a TCP connection, the TCP protocol running in each host makes transitions through various TCP states.

TCP connection establishment

TCP connection establishment can add delay because it requires a three-way handshake before a connection is fully established:

1. the client-side TCP sends a special SYN segment to request a connection with a server:

   1. SYN = 1 (flag bit)
   2. Sequence number = client_isn
      • isn = initial sequence number
      • chosen randomly to avoid certain security attacks (CERT 2001–09, RFC 4987)

2. upon receiving the SYN segment, the server-side TCP:

   • extracts the TCP SYN segment
   • allocates the TCP buffers and variables to the connection
   • sends back a special SYN-ACK "connection-granted" segment:
     1. SYN = 1 (flag bit)
     2. ACK = client_isn + 1 (flag bit)
     3. Sequence number = server_isn (the server chooses its own initial sequence number)

   • the "connection-granted" segment is referred to as a SYN-ACK segment:

     I received your SYN packet to start a connection with your initial sequence number, client_isn.
     I agree to establish this connection.
     My own initial sequence number is server_isn

3. upon receiving the SYN-ACK segment, the client-side TCP:

   • allocates buffers and variables to the connection
   • sends the server another segment to acknowledge the server's connection-granted segment:
     • ACK = server_isn + 1
     • SYN = 0 (since the connection is established)
   • this segment may carry application-layer data

This process uses three messages, so it's called the three-way handshake:

This process is also sometimes targeted by attacks such as SYN floods.

TCP connection closing

Either of the two processes participating in a TCP connection can end the connection.

When a connection ends, the "resources" (buffers and variables) in the hosts are deallocated.

If the client decides to close the connection:

• the client application process issues a close command
• this causes the client TCP to send a special TCP segment to the server process
  • the FIN bit is set to 1 in the segment's header
• when the server receives this segment
  • it sends the client an acknowledgment segment in return
  • then it sends its own shutdown segment
  • the FIN bit is set to 1 in the segment's header
• the client acknowledges the server's shutdown segment
• at this point, all the resources in the two hosts are now deallocated

Reset segment

If a host receives a TCP SYN packet for port 443, but nothing is listening on that port (for example, no web server is running), it replies with a reset (RST) segment:

• the RST flag bit is set to 1

• this tells the sender:

  I don't have a socket for that segment. Please do not resend the segment.

How Nmap leverages TCP for port-scanning

To explore a specific TCP port (say port 6789) on a target host, nmap will send a TCP SYN segment with destination port 6789 to that host.

There are three possible outcomes for the source host:

1. it receives a TCP SYNACK segment
   • this means an application is running with TCP port 6789
   • nmap returns "open"
2. it receives a TCP RST segment
   • this means that the SYN segment reached the target host
   • but the target host is not running an application with TCP port 6789
   • the attacker at least knows that the segments destined to the host at port 6789 are not blocked by any firewall on the path between source and target hosts
3. it receives nothing
   • this likely means that the SYN segment was blocked by an intervening firewall
   • and never reached the target host

Most the things nmap can do are done by manipulating TCP connection-management segments.