Scribd
Upload
43 views

TCP (Transmission Control Protocol) : - Originally Defined in RFC 793 (September 1981) - UDP Features

TCP provides reliable, ordered, and error-checked delivery of a stream of bytes between applications running on hosts communicating over an IP network. It establishes connections using a 3-way handshake, transfers data reliably through an adaptive sliding window protocol, and closes connections through a 4-way termination sequence. TCP handles issues like flow control, congestion control, and retransmission of lost packets to ensure reliable in-order data delivery.

Uploaded by

FatiLily
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
43 views

TCP (Transmission Control Protocol) : - Originally Defined in RFC 793 (September 1981) - UDP Features

TCP provides reliable, ordered, and error-checked delivery of a stream of bytes between applications running on hosts communicating over an IP network. It establishes connections using a 3-way handshake, transfers data reliably through an adaptive sliding window protocol, and closes connections through a 4-way termination sequence. TCP handles issues like flow control, congestion control, and retransmission of lost packets to ensure reliable in-order data delivery.

Uploaded by

FatiLily
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

TCP (Transmission Control Protocol)

Originally defined in RFC 793 (September 1981)


UDP features: multiplexing + protection against bit errors
Ports, checksum

Connection-oriented
Establishment and teardown of the connections

Reliable
Missing or corrupt segments are detected and retransmitted

Stream-based, in-order delivery


The sender writes bytes into a TCP connection and the receiver reads bytes
out of the TCP connection

Full duplex
Each TCP connection supports a pair of byte streams, one flowing in each
direction

Flow control
Keep sender from overrunning receiver (end-to-end issue)

Congestion Control
Keep sender from overrunning network
Algorithm tries to fill available capacity

Data Link vs. Transport


At the heart of TCP is the sliding window algorithm
TCP runs over the Internet rather than a point-to-point link

Many important differences

TCP potentially connects many different hosts

Explicit connection establishment and teardown


Some shared information to enable the sliding window algorithm to start

Different RTT (Round Trip Times)

LANs vs. satellite networks, peak hour


Variations in the RTT are even possible during a single TCP connection that lasts only
a few minutes
Adaptive timeout mechanism

Potentially long delay in network

Packets may be reordered as they cross the Internet


TCP has to be prepared for very old packets to suddenly show up at the receiver,
potentially confusing the sliding window algorithm
Maximum Segment Lifetime (MSL)
Since IP throws packets away after their TTL expires, TCP assumes that each packet has a
maximum lifetime
The current recommended setting is 120 s (conservative estimation)

Different capacity at destination

Multiple TCP connections supported at the same time


TCP must include a mechanism that each side uses to learn what resources (e.g., how
much buffer space) the other side is able to apply to the connection

Different network capacity

The sender has no idea what links will be traversed to reach the destination

TCP Overview
Application
process

Client
The client process
passes a stream of
data through the
socket

The application
reads the stream
of data from the
receive buffer

TCP

TCP
Send Buffer

Application
process

Server

TCP Segments

Receive Buffer

Basic Data Transfer (RFC 793): The TCP is able to transfer a continuous stream of octets in each
direction between its users by packaging some number of octets into segments for transmission
through the internet system. In general, the TCPs decide when to block and forward data at
their own convenience.
Current status of the sliding window mechanism
Maximum Segment Size (MSS): MTU of the directly connected network, minus the size of the
TCP and IP headers
standard MSS for TCP = 536 bytes (576 20 -20)
push operation
timer

Source Port

TCP Header

Destination Port

Sequence Number
Acknowledgment

Source Port: 16 bits


The source port number
Destination Port: 16 bits
The destination port number

HLen Resrvd Flags

AdvertisedWindow

The SrcPort and DstPort, plus the SRc and


Dst IP addresses, combine to uniquely
identify each TCP connection

Checksum

UrgPtr

(SrcPort, SrcIPAddr,DstPort,DstIPAddr)

Options (variable)

TCP demux key


HdrLen (Data Offset): 4 bits
The number of 32 bit words in the TCP
Header.
This indicates where the data begins.

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 TCP header, TCP data
and the pseudo header.
Required in both IPv4 and IPv6.

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.

TCP Header: Sliding window algorithm


Sequence Number: 32 bits

Acknowledgment Number: 32 bits

The sequence number of the first data octet


in this segment (except when SYN is
present).

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.

If SYN is present the sequence number is the


initial sequence number (ISN) and the first
data octet is ISN+1.

Once a connection is established this is


always sent.

Advertised Window: 16 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.

Sequence Number (Data)


Acknowledgment +
AdvertisedWindow

Sequence Number (Data)


Acknowledgment +
AdvertisedWindow

TCP Flags
Control Bits: 6 bits (from left to right)

URG: Urgent Pointer field significant


This flag is used to identify incoming data as 'urgent'. Such incoming segments do not have to
wait until the previous segments are consumed by the receiving end but are sent directly and
processed immediately
Out-of-band signalling

Interrupt/abort character sequence in remote login session

ACK: Acknowledgment field significant


PSH: Push Function
A push causes the TCP to promptly forward and deliver data up to that point to the receiver
The Push flag is usually set on the last segment of a file to prevent buffer deadlocks

RST: Reset the connection


if a packet is sent to a host in order to establish a connection, and there is no such service
waiting to answer at the remote host, then the host would automatically reject the request
and then send a reply with the RST flag set

SYN: Synchronize sequence numbers


the SYN flag is set when establishing the classical 3-way handshake between two hosts

FIN: No more data from sender


This flag is used to tear down the virtual connections

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.

TCP Connection Management


Connection establishment (Three-Way handshake)
TCP sender, receiver establish connection before exchanging data
segments
initialize TCP variables:
seq. #s
buffers, flow control info (e.g. RcvWindow)
Connection setup is an asymmetric activity: one side does a passive open
and the other side does an active open
client: connection initiator
server: contacted by client

The two sides begin sending data only after this connection
establishment phase is over
Connection termination
Connection teardown is symmetric: each side has to close the connection
independently
As soon as a participant is done sending data, it closes one direction of the
connection
The other side can keep the other half of the bidirectional connection open
and continue sending data

Initial Sequence Number (ISN)

The protocol places no restriction on a particular connection being used over and over again.

How does the TCP identify duplicate segments from previous incarnations of the connection?

The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented
roughly every 4 microseconds.
Thus, the ISN cycles approximately every 4.55 hours.
Since TCP assumes that segments will stay in the network no more than the Maximum Segment
Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be
unique.

For a connection to be established or initialized, the two TCPs must synchronize on each
other's initial sequence numbers.

The connection is being opened and closed in quick succession,


The connection breaks with loss of memory and is then reestablished

To avoid confusion TCP must prevent segments from one incarnation of a connection from
being used while the same sequence numbers may still be present in the network from an
earlier incarnation.
When new connections are created, an initial sequence number (ISN) generator is employed
which selects a new 32 bit ISN

New instances of a connection will be referred to as incarnations of the connection.

This is done in an exchange of connection establishing segments carrying a control bit called "SYN"
(for synchronize) and the initial sequence numbers.
As a shorthand, segments carrying the SYN bit are also called SYNs

The solution requires a suitable mechanism for picking an initial sequence number and a
slightly involved handshake to exchange the ISN's.

Three-Way Handshake
active
participant
(client)
A timer is scheduled for
each of the first two
segments, and if the
expected response is not
received, the segment is
retransmitted

SYN
SeqNum=x
SYN+ACK,
SeqNum=y
Ack=x+1
ACK,
SeqNum=x+1
Ack=y+1

ACK,
SeqNum=x+1
Ack=y+1

passive
participant
(server)
The Acknowledgement Field
identifies the next sequence
number expected, thereby
implicitly acknowledging all
earlier sequence numbers

First data
segment

TCP State-Transition diagram


States involved in
opening a
connection

States involved in
closing a
connection

TCP State-Transition diagram


All Connections start in the CLOSED state
As the connection
progresses, the
connection moves
from state to state
according to the arcs
States of the
connection

The local application process


invokes an operation on TCP
Each arc is labelled
with a tag of the form
event/action

A segment arrives from the peer

TimeOut based
Retransmissions are
NOT shown in the
diagram

client

server
SYN
SYN+ACK
ACK

Three-Way Handshake

Normal Connection Termination


The application process on both sides of the
connection must independently close its half of
the connection
If only one side closes the connection, it is still
available to receive data from the other side

Initiator
Sequence

FIN
ACK

FIN

ACK

Responder
Sequence

TIME_WAIT State
The TIME-WAIT state is required since the local side of the
connection does not know if its ACK was successfully delivered
Retransmission of the FIN segment
Delayed packets

FIN
ACK
FIN

ACK
SYN
FIN

Connection Termination Simultaneous Close


It is also possible for two devices to try to terminate a
connection simultaneously.
This term simultaneously does not mean that they both decide
to shut down at exactly the same time. It simply means that one
host decides to shut down and sends a FIN, but the other host
sends its own FIN before receiving it.

Both devices crosses


the same states

FIN
FIN
ACK
ACK

Connection Termination- Rare transition


Initiator
Sequence

FIN
FIN+ACK

ACK

Responder
Sequence

Connection Termination - Summary

You might also like