TCP
TCP is a
process-to-process (program-to-program) protocol. TCP is called a
connection-oriented, reliable transport protocol. TCP uses flow and error
control mechanisms at the transport level.
1. TCP Services
The
services offered by TCP to the processes at the application layer.
Process-to-Process
Communication
TCP
provides process-to-process communication using port numbers. Table 4.2 lists
some well-known port numbers used by TCP.
2. Stream Delivery Service
TCP is a
stream-oriented protocol. TCP allows the sending process to deliver data as a
stream of bytes and allows the receiving process to obtain data as a stream of
bytes. TCP creates an environment in which the two processes seem to be
connected by an imaginary "tube" that carries their data across the
Internet. This imaginary environment is depicted in Figure 4.13. The sending
process produces (writes to) the stream of bytes, and the receiving process
consumes (reads from) them.
Sending
and Receiving Buffers:
Because
the sending and the receiving processes may not write or read data at the same
speed, TCP needs buffers for storage. There are two buffers, the sending buffer
and the receiving buffer, one for each direction. One way to implement a buffer
is to use a circular array of I-byte locations as shown in Figure 4.14. For
simplicity, we have shown two buffers of 20 bytes each; normally the buffers
are hundreds or thousands of bytes, depending on the implementation. We also
show the buffers as the same size, which is not always the case.
Figure 4.14
shows the movement of the data in one direction. At the sending site, the
buffer has three types of chambers. The white section contains empty chambers
that can be filled by the sending process (producer). The gray area holds bytes
that have been sent but not yet acknowledged. TCP keeps these bytes in the
buffer until it receives an acknowledgment. The colored area contains bytes to
be sent by the sending TCP.
Segments
Segments
although buffering handles the disparity between the speed of the producing and
consuming processes, we need one more step before we can send data. The IP
layer, as a service provider for TCP, needs to send data in packets, not as a
stream of bytes. At the transportlayer, TCP groups a number of bytes together
into a packet called a segment. Figure 4.15 showshow segments are created from
the bytes in the buffers.
3. Full-Duplex Communication
TCP
offers full-duplex service, in which data can flow in both directions at the
same time. Each TCP then has a sending and receiving buffer, and segments move
in both directions.
4. Connection-Oriented Service
TCP is a
connection-oriented protocol. When a process at site A wants to send and
receive data from another process at site B, the following occurs:
1.
The two TCPs establish a connection between them.
2.
Data are exchanged in both directions.
3.
The connection is terminated.
Reliable
Service
TCP is a
reliable transport protocol. It uses an acknowledgment mechanism to check the
safe and sound arrival of data.
5. TCP Features
TCP has
several features.
Numbering
System
Although
the TCP software keeps track of the segments being transmitted or received,
there is no field for a segment number value in the segment header. Instead,
there are two fields called the sequence number and the acknowledgment number.
These two fields refer to the byte number and not the segment number.
Byte
Number
TCP
numbers all data bytes that are transmitted in a connection. Numbering is
independent in each direction. When TCP receives bytes of data from a process,
it stores them in the sending buffer and numbers them.
The bytes of data being transferred in each
connection are numbered by TCP. The numbering starts with a randomly generated
number.
Sequence
Number
After the
bytes have been numbered, TCP assigns a sequence number to each segment that is
being sent. The sequence number for each segment is the number of the first
byte carried in that segment.
The value in the sequence number field of a segment
defines the number of the first data byte contained in that segment.
When a
segment carries a combination of data and control information (piggybacking),
it uses a sequence number. If a segment does not carry user data, it does not
logically define a sequence number. The field is there, but the value is not valid.
However, some segments, when carrying only control information, need a sequence
number to allow an acknowledgment from the receiver. These segments are used
for connection establishment, termination, or abortion.
Acknowledgment
Number
Communication
in TCP is full duplex; when a connection is established, both parties can send
and receive data at the same time. Each party numbers the bytes, usually with a
different starting byte number.
The
sequence number in each direction shows the number of the first byte carried by
the segment. Each party also uses an acknowledgment number to confirm the bytes
it has received. However, the acknowledgment number defines the number of the
next byte that the party expects to receive. In addition, the acknowledgment
number is cumulative, which means that the party takes the number of the last
byte that it has received, safe and sound, adds I to it, and announces this sum
as the acknowledgment number.
6. Flow Control
TCP
provides flow control. The receiver of the data controls the amount of data
that are to be sent by the sender. This is done to prevent the receiver from
being overwhelmed with data. The numbering system allows TCP to use a
byte-oriented flow control.
Error
Control
To
provide reliable service, TCP implements an error control mechanism. Although
error control considers a segment as the unit of data for error detection (loss
or corrupted segments), error control is byte-oriented.
Congestion
Control
TCP,
unlike UDP, takes into account congestion in the network. The amount of data
sent by a sender is not only controlled by the receiver (flow control), but is
also determined by the level of congestion in the network.
7. Segment
A packet
in TCP is called a segment.
8. Format
The
format of a segment is shown in Figure 4.16
The
segment consists of a 20- to 60-byte header, followed by data from the
application program. The header is 20 bytes if there are no options and up to
60 bytes if it contains options.
·
Source
port address. This is a 16-bit field that defines the port
number of the applicationprogram in the host that is sending the segment. This
serves the same purpose as the source port address in the UDP header.
·
Destination
port address. This is a 16-bit field that defines the port
number of theapplication program in the host that is receiving the segment.
This serves the same purpose as the destination port address in the UDP header.
·
Sequence
number. This 32-bit field defines the number assigned to the first byte of
datacontained in this segment. As we said before, TCP is a stream transport
protocol. To ensure connectivity, each byte to be transmitted is numbered. The
sequence number tells the destination which byte in this sequence comprises the
first byte in the segment.
·
Acknowledgment
number. This 32-bit field defines the byte number that the receiver ofthe
segment is expecting to receive from the other party.
·
Header
length. This 4-bit field indicates the number of 4-byte words in the TCP
header.The length of the header can be between 20 and 60 bytes. Therefore, the
value of this field can be between 5 (5 x 4 =20) and 15 (15 x 4 =60).
·
Reserved. This is
a 6-bit field reserved for future use.
·
Control. This
field defines 6 different control bits or flags as shown in Figure 4.17.One or
more of these bits can be set at a time.
These
bits enable flow control, connection establishment and termination, connection
abortion, and the mode of data transfer in TCP. A brief description of each bit
is shown in Table 4.3
·
Window
size. This
field defines the size of the window, in bytes, that the other partymust
maintain. Note that the length of this field is 16 bits, which means that the
maximum size of the window is 65,535 bytes. This value is normally referred to
as the receiving window (rwnd) and is determined by the receiver. The sender
must obey the dictation of the receiver in this case.
·
Checksum. This
16-bit field contains the checksum. The inclusion of the checksum forTCP is
mandatory. For the TCP pseudoheader, the value for the protocol field is 6.
·
Urgent
pointer. This l6-bit field, which is valid, only if the urgent flag is set, is
usedwhen the segment contains urgent data. It defines the number that must be
added to the sequence number to obtain the number of the last urgent byte in
the data section of the segment.
·
Options. There can
be up to 40 bytes of optional information in the TCP header.
9. A TCP Connection
TCP is
connection-oriented. A connection-oriented transport protocol establishes a
virtual path between the source and destination. All the segments belonging to
a message are then sent over this virtual path. Using a single virtual pathway
for the entire message facilitates the acknowledgment process as well as
retransmission of damaged or lost frames.
a. Connection
Establishment
TCP
transmits data in full-duplex mode. When two TCPs in two machines are
connected,
they are
able to send segments to each other simultaneously. This implies that each
party must initialize communication and get approval from the other party
before any data are transferred.
Three-Way
Handshaking:
The
connection establishment in TCP is called three way handshaking. In our
example, an application program, called the client, wants to make a connection
with another application program, called the server, using TCP as the transport
layer protocol.
The
process starts with the server. The server program tells its TCP that it is
ready to accept a connection. This is called a request for a passive open.
Although the server TCP is ready to accept any connection from any machine in
the world, it cannot make the connection itself.
The
client program issues a request for an active open. A client that wishes to
connect to an open server tells its TCP that it needs to be connected to that
particular server. TCP can now start the three-way handshaking process as shown
in Figure 4.18.
To show
the process, we use two time lines: one at each site. Each segment has values
for all its header fields and perhaps for some of its option fields, too.
However, we show only the few fields necessary to understand each phase. We
show the sequence number, the acknowledgment number, the control flags (only
those that are set), and the window size, if not empty. The three steps in this
phase are as follows.
1. The client sends the first segment, a SYN
segment, in which only the SYN flag is set. This segment is for synchronization
of sequence numbers. It consumes one sequence number. When the data transfer
start, the sequence number is incremented by 1. We can say that the SYN segment
carries no real data, but we can think of it as containing 1 imaginary byte.
A SYN segment cannot carry data, but it consumes
one sequence number.
2. The server sends the second segment, a SYN +ACK
segment, with 2 flag bits set: SYN and ACK. This segment has a dual purpose. It
is a SYN segment for communication in the other direction and serves as the
acknowledgment for the SYN segment. It consumes one sequence number.
A SYN +ACK segment cannot carry data, but does
consume one sequence number.
3. The client sends the third segment. This is just
an ACK segment. It acknowledges the receipt of the second segment with the ACK
flag and acknowledgment number field. Note that the sequence number in this
segment is the same as the one in the SYN segment; the ACK segment does not
consume any sequence numbers.
An ACK segment, if carrying no data, consumes no
sequence number.
Simultaneous
Open
A rare
situation, called a simultaneous open, may occur when both processes issue an
active open. In this case, both TCPs transmit a SYN + ACK segment to each
other, and one single connection is established between them.
SYN
Flooding Attack
The
connection establishment procedure in TCP is susceptible to a serious security
problem called the SYN flooding attack. This happens when a malicious attacker
sends a large number of SYN segments to a server, pretending that each of them
is corning from a different client by faking the source IP addresses in the
datagrams.
b. Data Transfer
After
connection is established, bidirectional data transfer can take place. The
client and server can both send data and acknowledgments. The acknowledgment is
piggybacked with the data. Figure 4.19 shows an example.
In this
example, after connection is established (not shown in the figure), the client
sends 2000 bytes of data in two segments. The server then sends 2000 bytes in
one segment.
The
client sends one more segment. The first three segments carry both data and
acknowledgment, but the last segment carries only an acknowledgment because
there are no more data to be sent. Note the values of the sequence and
acknowledgment numbers. The data segments sent by the client have the PSH
(push) flag set so that the server TCP knows to deliver data to the server
process as soon as they are received. The segment from the server, on the other
hand, does not set the push flag. Most TCP implementations have the option to
set or not set this flag.
Pushing
Data
The
sending TCP uses a buffer to store the stream of data coming from the sending
application program. The sending TCP can select the segment size. The receiving
TCP also buffers the data when they arrive and delivers them to the application
program when the application program is ready or when it is convenient for the
receiving TCP. This type of flexibility increases the efficiency of TCP.
However, on occasion the application program has no need for this flexibility.
TCP can
handle such a situation. The application program at the sending site can
request a push operation. This means that the sending TCP must not wait for the
window to be filled. It must create a segment and send it immediately. The
sending TCP must also set the push bit (PSH) to let the receiving TCP know that
the segment includes data that must be delivered to the receiving application
program as soon as possible and not to wait for more data to come.
Although
the push operation can be requested by the application program, most current
implementations ignore such requests. TCP can choose whether or not to use this
feature.
Urgent
Data
TCP is a
stream-oriented protocol. This means that the data are presented from the
application program to TCP as a stream of bytes. Each byte of data has a
position in the stream. However, on occasion an application program needs to
send urgent bytes. This means that the sending application program wants a
piece of data to be read out of order by the receiving application program. As
an example, suppose that the sending application program is sending data to be
processed by the receiving application program. When the result of processing
comes back, the sending application program finds that everything is wrong. It
wants to abort the process, but it has already sent a huge amount of data. If
it issues an abort command, these two characters will be stored at the end of
the receiving TCP buffer. It will be delivered to the receiving application
program after all the data have been processed.
c. Connection Termination
Any of
the two parties involved in exchanging data (client or server) can close the
connection, although it is usually initiated by the client. Most
implementations today allow two Options for connection termination: three-way
handshaking and four-way handshaking with a half-close option.
Three-Way
Handshaking
Most implementations
today allow three-way handshaking for connection termination as shown in Figure
4.20.
1. In a
normal situation, the client TCP, after receiving a close command from the
client process, sends the first segment, a FIN segment in which the FIN flag is
set. Note that a FIN segment can include the last chunk of data sent by the
client, or it can be just a control segment as shown in Figure 4.20. If it is
only a control segment, it consumes only one sequence number.
The FIN segment consumes one sequence number if it
does not carry data.
2. The
server TCP, after receiving the FIN segment, informs its process of the
situation and sends the second segment, a FIN +ACK segment, to confirm the
receipt of the FIN segment from the client and at the same time to announce the
closing of the connection in the other direction. This segment can also contain
the last chunk of data from the server. If it does not carry data, it consumes
only one sequence number.
The FIN +ACK segment consumes one sequence number if
it does not carry data.
3. The
client TCP sends the last segment, an ACK segment, to confirm the receipt of
the FIN segment from the TCP server. This segment contains the acknowledgment
number, which is 1 plus the sequence number received in the FIN segment from
the server. This segment cannot carry data and consumes no sequence numbers.
Half-Close
In TCP,
one end can stop sending data while still receiving data. This is called a
half-close. Although either end can issue a half-close, it is normally initiated
by the client. It can occur when the server needs all the data before
processing can begin. A good example is sorting. When the client sends data to
the server to be sorted, the server needs to receive all the data before
sorting can start. This means the client, after sending all the data, can close
the connection in the outbound direction. However, the inbound direction must
remain open to receive the
sorted
data. The server, after receiving the data, still needs time for sorting; its
outbound direction must remain open.
Figure
4.21 shows an example of a half-close. The client half-closes the connection by
sending a FIN segment. The server accepts the half-close by sending the ACK
segment. The data transfer from the client to the server stops. The server,
however, can still send data. When the server has sent all the processed data,
it sends a FIN segment, which is acknowledged by an ACK from the client.
After
half-closing of the connection, data can travel from the server to the client
and acknowledgments can travel from the client to the server. The client cannot
send any more data to the server. Note the sequence numbers we have used. The
second segment (ACK) consumes no sequence number. Although the client has
received sequence number y - 1 and is expecting y, the server sequence number
is still y - 1. When the connection finally closes, the sequence number of the
last ACK segment is still x, because no sequence numbers are consumed during
data transfer in that direction.
10. Flow Control
TCP uses
a sliding window to handle flow control. The sliding window protocol used by
TCP, however, is something between the Go-Back-N and Selective Repeat sliding
window. The sliding window protocol in TCP looks like the Go-Back-N protocol
because it does not use NAKs; it looks like Selective Repeat because the
receiver holds the out-of-order segments until the missing ones arrive.
The
window is opened, closed, or shrunk. These three activities, as we will see,
are in the control of the receiver (and depend on congestion in the network),
not the sender. The sender must obey the commands of the receiver in this
matter.
Opening a
window means moving the right wall to the right. This allows more new bytes in
the buffer that are eligible for sending. Closing the window means moving the
left wall to the right. This means that some bytes have been acknowledged and
the sender need not worry about them anymore. Shrinking the window means moving
the right wall to the left. This is strongly discouraged and not allowed in
some implementations because it means revoking the eligibility of some bytes
for sending. This is a problem if the sender has already sent these bytes. Note
that the left wall cannot move to the left because this would revoke some of
the previously sent acknowledgments.
A sliding window is used to make transmission more
efficient as well as to control the flow of data so that the destination does
not become overwhelmed with data. TCP sliding windows are byte-oriented.
The size
of the window at one end is determined by the lesser of two values: receiver
window (rwnd) or congestion window (cwnd). The receiver window is the value
advertised by the opposite end in a segment containing acknowledgment. It is
the number of bytes the other end can accept before its buffer overflows and
data are discarded. The congestion window is a value determined by the network
to avoid congestion.
Some points about TCP sliding windows:
·
The size of the window is the lesser of rwnd and cwnd.
·
The source does not have to send a full window's
worth of data.
·
The window can be opened or closed by the receiver,
but should not be shrunk.
·
The destination can send an acknowledgment at any
time as long as it does not result in a shrinking window.
·
The receiver can temporarily shut down the window;
the sender, however, can always send a segment of 1 byte after the window is
shut down.
11. Error Control
TCP is a
reliable transport layer protocol. This means that an application program that
delivers a stream of data to TCP relies on TCP to deliver the entire stream to
the application program on the other end in order, without error, and without
any part lost or duplicated.
TCP
provides reliability using error control. Error control includes mechanisms for
detecting corrupted segments, lost segments, out-of-order segments, and
duplicated segments. Error control also includes a mechanism for correcting
errors after they are detected. Error detection and correction in TCP is
achieved through the use of three simple tools: checksum, acknowledgment, and
time-out.
a. Checksum
Each
segment includes a checksum field which is used to check for a corrupted
segment. If the segment is corrupted, it is discarded by the destination TCP
and is considered as lost. TCP uses a 16-bit checksum that is mandatory in
every segment. The 16-bit checksum is considered
inadequate
for the new transport layer, SCTP. However, it cannot be changed for TCP
because this would involve reconfiguration of the entire header format.
b. Acknowledgment
TCP uses
acknowledgments to confirm the receipt of data segments. Control segments that
carry no data but consume a sequence number are also acknowledged. ACK segments
are never acknowledged.
ACK segments do not consume sequence numbers and
are not acknowledged.
c. Retransmission
The heart
of the error control mechanism is the retransmission of segments. When a
segment is corrupted, lost, or delayed, it is retransmitted. In modern
implementations, a segment is retransmitted on two occasions: when a
retransmission timer expires or when the sender receives three duplicate ACKs.
In modern implementations, a retransmission occurs
if the retransmission timer expires or three duplicate ACK segments have
arrived.
Note that
no retransmission occurs for segments that do not consume sequence numbers. In
particular, there is no transmission for an ACK segment.
No retransmission timer is set for an ACK segment.
i. Retransmission After RTO
A recent
implementation of TCP maintains one retransmission time-out (RTO) timer for all
outstanding (sent, but not acknowledged) segments. When the timer matures, the
earliest outstanding segment is retransmitted even though lack of a received
ACK can be due to a delayed segment, a delayed ACK, or a lost acknowledgment.
Note that no time-out timer is set for a segment that carries only an
acknowledgment, which means that no such segment is resent.
ii. Retransmission After Three Duplicate ACK
Segments
The
previous rule about retransmission of a segment is sufficient if the value of
RTO is not very large. Sometimes, however, one segment is lost and the receiver
receives so many out-of-order segments that they cannot be saved (limited
buffer size).
iii. Out-of-Order Segments
When a
segment is delayed, lost, or discarded, the segments following that segment
arrive out of order. Originally, TCP was designed to discard all out-of-order
segments, resulting in the retransmission of the missing segment and the
following segments. Most implementations today do not discard the out-of-order
segments. They store them temporarily and flag them as out-of-order segments
until the missing segment arrives.
Some
Scenarios
In these
scenarios, we show a segment by a rectangle. If the segment carries data, we
show the range of byte numbers and the value of the acknowledgment field. If it
carries only an acknowledgment, we show only the acknowledgment number in a
smaller box.
a. Normal Operation
The first
scenario shows bidirectional data transfer between two systems, as in Figure .
The
client TCP sends one segment; the server TCP sends three. The figure shows
which rule applies to each acknowledgment. There are data to be sent, so the
segment displays the next byte expected. When the client receives the first
segment from the server, it does not have any more data to send; it sends only
an ACK segment
b. Lost Segment
In this
scenario, we show what happens when a segment is lost or corrupted. A lost
segment
and a corrupted segment are treated the same way by the receiver. A lost
segment is discarded somewhere in the network; a corrupted segment is discarded
by the receiver itself. Both are considered lost. Figure 4.24 shows a situation
in which a segment is lost and discarded by some router in the network, perhaps
due to congestion.
We are
assuming that data transfer is unidirectional: one site is sending and the
other is receiving. In our scenario, the sender sends segments 1 and 2, which
are acknowledged immediately by an ACK. Segment 3, however, are lost. The
receiver receives segment 4, which
is out of
order. The receiver stores the data in the segment in its buffer but leaves a
gap to indicate that there is no continuity in the data. The receiver
immediately sends an acknowledgment to the sender, displaying the next byte it
expects. Note that the receiver stores bytes 801 to 900, but never delivers
these bytes to the application until the gap is filled.
The receiver TCP delivers only ordered data to the
process.
c. Fast Retransmission
In this
scenario, we want to show the idea of fast retransmission. Our scenario is the
same as the second except that the RTO has a higher value (see Figure 4.25).
When the
receiver receives the fourth, fifth, and sixth segments, it triggers an
acknowledgment. The sender receives four acknowledgments with the same value
(three duplicates). Although the timer for segment 3 has not matured yet, the
fast transmission requires that segment 3, the segment that is expected by all
these acknowledgments, be resent immediately.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.