0% found this document useful (0 votes)
24 views

Connection-Oriented Transport TCP

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views

Connection-Oriented Transport TCP

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

Connection-Oriented Transport: TCP

 Now that we have covered the underlying principles of reliable data transfer, let’s turn

to TCP—the Internet’s transport-layer, connection-oriented, reliable transport

protocol.

 we’ll see that in order to provide reliable data transfer, TCP relies on many of the

underlying principles discussed in the previous section, including error detection,

retransmissions, cumulative acknowledgments, timers, and header fields for sequence

and acknowledgment numbers.

The TCP Connection

 TCP is said to be connection-oriented because before one application process can

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

the parameters of the ensuing data transfer.

 As part of TCP connection establishment, both sides of the connection will initialize

many TCP state variables associated with the TCP connection.

 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

network elements (routers and link-layer switches), the intermediate network

elements do not maintain TCP connection state.

Dr. T V Rama Krishna Page 1


 In fact, the intermediate routers are completely oblivious to TCP connections; they see

datagrams, not connections.

 A TCP connection provides a full-duplex service: If there is a TCP connection between

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

single send operation—is not possible with TCP.

 With TCP, two hosts are company and three are a crowd! Let’s now take a look at how

a TCP connection is established.

 Suppose a process running in one host wants to initiate a connection with another

process in another host.

 Recall that the process that is initiating the connection is called the client process,

while the other process is called the server process.

 The client application process first informs the client transport layer that it wants to

establish a connection to a process in the server.

 where serverName is the name of the server and serverPort identifies the process on

the server.

Dr. T V Rama Krishna Page 2


 TCP in the client then proceeds to establish a TCP connection with TCP in 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

with a third special segment.

 The first two segments carry no payload, that is, no application-layer data; the third of

these segments may carry a payload.

 Because three segments are sent between the two hosts, this connection-

establishment procedure is often referred to as a three-way handshake.

 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),

Dr. T V Rama Krishna Page 3


 Once the data passes through the door, the data is in the hands of TCP running in the

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

data to the network layer.

 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

by the maximum segment size (MSS).

 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

MSS based on the path MTU value.

Dr. T V Rama Krishna Page 4


 Note that the MSS is the maximum amount of application-layer data in the segment,

not the maximum size of the TCP segment including headers. (This terminology is

confusing, but we have to live with it, as it is well entrenched.)

 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

encapsulated within network-layer IP datagrams.

 The IP datagrams are then sent into the network.

 When TCP receives a segment at the other end, the segment’s data is placed in the

TCP connection’s receive buffer, as shown in Figure 3.28.

 The application reads the stream of data from this buffer.

 Each side of the connection has its own send buffer and its own receive buffer. (You

can see the online flow-control applet at http://www.awl.com/kurose-ross, which

provides an animation of the send and receive buffers.)

 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

socket connection to a process in another host.

 As mentioned earlier, no buffers or variables are allocated to the connection in the

network elements (routers, switches, and repeaters) between the hosts.

TCP Segment Structure

 Having taken a brief look at the TCP connection, let’s examine the TCP segment

structure.

 The TCP segment consists of header fields and a data field.

Dr. T V Rama Krishna Page 5


 The data field contains a chunk of application data.

 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

TCP segment is often only one byte.

 Because the TCP header is typically 20 bytes (12 bytes more than the UDP header),

segments sent by Telnet may be only 21 bytes in length.

Dr. T V Rama Krishna Page 6


 Figure 3.29 shows the structure of the TCP segment.

 As with UDP, the header includes source and destination port numbers, which are

used for multiplexing/demultiplexing data from/to upper-layer applications.

 Also, as with UDP, the header includes a checksum field.

 A TCP segment header also contains the following fields:

 • 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

used to indicate the number of bytes that a receiver is willing to accept.

 • 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

high-speed networks. A time-stamping option is also defined.

 • 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

Dr. T V Rama Krishna Page 7


last byte of this urgent data is indicated by the 16-bit urgent data pointer field. TCP

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.)

Sequence Numbers and Acknowledgment Numbers

 Two of the most important fields in the TCP segment header are the sequence number

field and the acknowledgment number field.

 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

first explain what exactly TCP puts in these fields.

 TCP views data as an unstructured, but ordered, stream of bytes.

 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

byte in the segment.

 Let’s look at an example.

 Suppose that a process in Host A wants to send a stream of data to a process in Host B

over a TCP connection.

 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.

Dr. T V Rama Krishna Page 8


 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

appropriate TCP segment.

 Now let’s consider acknowledgment numbers.

 These are a little trickier than sequence numbers.

 Recall that TCP is full-duplex, so that Host A may be receiving data from Host B while it

sends data to Host B (as part of the same TCP connection).

 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

of the next byte Host A is expecting from Host B.

 It is good to look at a few examples to understand what is going on here.

 Suppose that Host A has received all bytes numbered 0 through 535 from B and

suppose that it is about to send a segment to Host B.

Dr. T V Rama Krishna Page 9


 Host A is waiting for byte 536 and all the subsequent bytes in Host B’s data stream.

 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

B’s data stream.

 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

said to provide cumulative acknowledgments.

 This last example also brings up an important but subtle issue.

 Host A received the third segment (bytes 900 through 1,000) before receiving the

second segment (bytes 536 through 899).

 Thus, the third segment arrived out of order.

 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

the decision up to the people programming a TCP implementation.

 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.

Dr. T V Rama Krishna Page 10


 Clearly, the latter choice is more efficient in terms of network bandwidth, and is the

approach taken in practice.

 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

network from an earlier, already-terminated connection between two hosts is

mistaken for a valid segment in a later connection between these same two hosts.

Dr. T V Rama Krishna Page 11

You might also like