Connection-Oriented Transport TCP
Connection-Oriented Transport TCP
Now that we have covered the underlying principles of reliable data transfer, let’s turn
protocol.
we’ll see that in order to provide reliable data transfer, TCP relies on many of the
begin to send data to another, the two processes must first “handshake” with each
other—that is, they must send some preliminary segments to each other to establish
As part of TCP connection establishment, both sides of the connection will initialize
The TCP “connection” is not an end-to-end TDM or FDM circuit as in a circuit switched
network.
Nor is it a virtual circuit , as the connection state resides entirely in the two end
systems.
Because the TCP protocol runs only in the end systems and not in the intermediate
Process A on one host and Process B on another host, then application layer data can
flow from Process A to Process B at the same time as application layer data flows from
Process B to Process A.
A TCP connection is also always point-to-point, that is, between a single sender and a
single receiver.
So-called “multicasting” --the transfer of data from one sender to many receivers in a
With TCP, two hosts are company and three are a crowd! Let’s now take a look at how
Suppose a process running in one host wants to initiate a connection with another
Recall that the process that is initiating the connection is called the client process,
The client application process first informs the client transport layer that it wants to
where serverName is the name of the server and serverPort identifies the process on
the server.
At the end of this section we discuss in some detail the connection- establishment
procedure.
For now it suffices to know that the client first sends a special TCP segment; the server
responds with a second special TCP segment; and finally the client responds again
The first two segments carry no payload, that is, no application-layer data; the third of
Because three segments are sent between the two hosts, this connection-
Once a TCP connection is established, the two application processes can send data to
each other.
Let’s consider the sending of data from the client process to the server process.
The client process passes a stream of data through the socket (the door of the
process),
client.
As shown in Figure 3.28, TCP directs this data to the connection’s send buffer, which is
one of the buffers that is set aside during the initial three-way handshake.
From time to time, TCP will grab chunks of data from the send buffer and pass the
Interestingly, the TCP specification is very laid back about specifying when TCP should
actually send buffered data, stating that TCP should “send that data in segments at its
own convenience.”
The maximum amount of data that can be grabbed and placed in a segment is limited
The MSS is typically set by first determining the length of the largest link-layer frame
that can be sent by the local sending host (the so-called maximum transmission unit,
MTU), and then setting the MSS to ensure that a TCP segment (when encapsulated in
an IP datagram) plus the TCP/IP header length (typically 40 bytes) will fit into a single
link-layer frame.
Both Ethernet and PPP link-layer protocols have an MSS of 1,500 bytes.
Approaches have also been proposed for discovering the path MTU—the largest link-
layer frame that can be sent on all links from source to destination —and setting the
not the maximum size of the TCP segment including headers. (This terminology is
TCP pairs each chunk of client data with a TCP header, thereby forming TCP segments.
The segments are passed down to the network layer, where they are separately
When TCP receives a segment at the other end, the segment’s data is placed in the
Each side of the connection has its own send buffer and its own receive buffer. (You
We see from this discussion that a TCP connection consists of buffers, variables, and a
socket connection to a process in one host, and another set of buffers, variables, and a
Having taken a brief look at the TCP connection, let’s examine the TCP segment
structure.
As mentioned above, the MSS limits the maximum size of a segment’s data field.
When TCP sends a large file, such as an image as part of a Web page, it typically breaks
the file into chunks of size MSS (except for the last chunk, which will often be less than
the MSS).
Interactive applications, however, often transmit data chunks that are smaller than
the MSS; for example, with remote login applications like Telnet, the data field in the
Because the TCP header is typically 20 bytes (12 bytes more than the UDP header),
As with UDP, the header includes source and destination port numbers, which are
• The 32-bit sequence number field and the 32-bit acknowledgment number field are
used by the TCP sender and receiver in implementing a reliable data transfer service,
as discussed below.
• The 16-bit receive window field is used for flow control. We will see shortly that it is
• The 4-bit header length field specifies the length of the TCP header in 32-bit words.
The TCP header can be of variable length due to the TCP options field.
• The optional and variable-length options field is used when a sender and receiver
negotiate the maximum segment size (MSS) or as a window scaling factor for use in
• The flag field contains 6 bits. The ACK bit is used to indicate that the value carried in
the acknowledgment field is valid; that is, the segment contains an acknowledgment
for a segment that has been successfully received. The RST, SYN, and FIN bits are used
for connection setup and teardown, as we will discuss at the end of this section.
Setting the PSH bit indicates that the receiver should pass the data to the upper layer
immediately. Finally, the URG bit is used to indicate that there is data in this segment
that the sending-side upper-layer entity has marked as “urgent.” The location of the
must inform the receiving- side upper-layer entity when urgent data exists and pass it
a pointer to the end of the urgent data. (In practice, the PSH, URG, and the urgent
data pointer are not used. However, we mention these fields for completeness.)
Two of the most important fields in the TCP segment header are the sequence number
These fields are a critical part of TCP’s reliable data transfer service.
But before discussing how these fields are used to provide reliable data transfer, let us
TCP’s use of sequence numbers reflects this view in that sequence numbers are over
the stream of transmitted bytes and not over the series of transmitted segments.
The sequence number for a segment is therefore the byte-stream number of the first
Suppose that a process in Host A wants to send a stream of data to a process in Host B
The TCP in Host A will implicitly number each byte in the data stream.
Suppose that the data stream consists of a file consisting of 500,000 bytes, that the
MSS is 1,000 bytes, and that the first byte of the data stream is numbered 0.
As shown in Figure 3.30, TCP constructs 500 segments out of the data stream.
The first segment gets assigned sequence number 0, the second segment gets assigned
sequence number 1,000, the third segment gets assigned sequence number 2,000, and
so on.
Each sequence number is inserted in the sequence number field in the header of the
Recall that TCP is full-duplex, so that Host A may be receiving data from Host B while it
Each of the segments that arrive from Host B has a sequence number for the data
flowing from B to A.
The acknowledgment number that Host A puts in its segment is the sequence number
Suppose that Host A has received all bytes numbered 0 through 535 from B and
So Host A puts 536 in the acknowledgment number field of the segment it sends to B.
As another example, suppose that Host A has received one segment from Host B
containing bytes 0 through 535 and another segment containing bytes 900 through
1,000.
For some reason Host A has not yet received bytes 536 through 899.
In this example, Host A is still waiting for byte 536 (and beyond) in order to re-create
Thus, A’s next segment to B will contain 536 in the acknowledgment number field.
Because TCP only acknowledges bytes up to the first missing byte in the stream, TCP is
Host A received the third segment (bytes 900 through 1,000) before receiving the
The subtle issue is: What does a host do when it receives out-of-order segments in a
TCP connection? Interestingly, the TCP RFCs do not impose any rules here and leave
There are basically two choices: either (1) the receiver immediately discards out-of-
order segments (which, as we discussed earlier, can simplify receiver design), or (2)
the receiver keeps the out-of-order bytes and waits for the missing bytes to fill in the
gaps.
In Figure 3.30, we assumed that the initial sequence number was zero.
In truth, both sides of a TCP connection randomly choose an initial sequence number.
This is done to minimize the possibility that a segment that is still present in the
mistaken for a valid segment in a later connection between these same two hosts.