A

SEQ=1000

Web Client

SEQ=2000

Web Server

SEQ=3000

ACK=4000

In Figure 5-4, the acknowledgment field in the TCP header sent by the Web server implies the next byte to be received; this is called forward acknowledgment. The sequence number reflects the number of the first byte in the segment. In this case, each TCP segment is 1000 bytes in length; the sequence and acknowledgment fields count the number of bytes.

Figure 5-5 depicts the same scenario, but the second TCP segment was lost or in error. The Web server's reply has an ACK field equal to 2000, implying that the Web server is expecting byte number 2000 next. The TCP function at the Web client could then recover lost data by resending the second TCP segment. The TCP protocol allows for resending just that segment and then waits, hoping that the Web server will reply with an acknowledgment that equals 4000. TCP also allows the resending host to begin with a segment in error and resend all TCP segments.

Figure 5-5 TCP Acknowledgment with Errors

SEQ=1000

Client Server

SEQ=2000

Flow Control Using Windowing

TCP implements flow control by taking advantage of the sequence and acknowledgment fields in the TCP header, along with another field called the window field. This window field implies the maximum number of unacknowledged bytes outstanding at any instant in time. The window starts small and then grows until errors occur. The window then "slides" up and down based on network performance. When the window is full, the sender will not send, which controls the flow of data. Figure 5-6 shows windowing, with a current window size of 3000. Each TCP segment has 1000 bytes of data.

Notice that the Web client must wait after sending the third segment because the window is exhausted. When the acknowledgment has been received, another window can be sent. Because there have been no errors, the Web server grants a larger window to the client, so now 4000 bytes can be sent before an acknowledgment is received by the client. In other words, the window field is used by the receiver to tell the sender how much data it can send before the next acknowledgment. As with other TCP features, windowing is symmetrical—both sides send and receive, and in each case the receiver grants a window to the sender using the window field.

Figure 5-6 TCP Windowing

Windowing does not require that the sender stop sending in all cases, as is shown in Figure 5-6. If an acknowledgment is received before the window is exhausted, the sender continues to send data until the current window is exhausted. With no errors or congestion, the sender can send continually after the initially small window has been increased.

Connection Establishment and Termination

Connection establishment is the last TCP function reviewed in this section, but it occurs before any of the other TCP features can begin their work. Connection establishment refers to the process of initializing sequence and acknowledgment fields and agreeing to the port numbers used. Figure 5-7 shows an example of connection establishment flow.

Figure 5-7 TCP Connection Establishment

SEQ=200 SYN, DPORT=80, SPORT=1027

SEQ=1450, ACK=201 SYN, ACK, DPORT=1027, SPORT=80

Client SEQ=201, ACK=1451 Server

ACK, DPORT=80, SPORT=1027

This three-way connection establishment flow must complete before data transfer can begin. The connection exists between the two sockets, although there is no single socket field in the TCP header. Of the three parts of a socket, the IP addresses are implied based on the source and destination IP addresses in the IP header. TCP is implied because a TCP header is in use, as implied by the protocol field value in the IP header. Therefore, the only parts of the socket that need to be encoded in the TCP header are the port numbers.

Two single-bit portions of the flags field of the TCP header are used to signal the three-step process for connection establishment. Called the SYN and ACK flags, these bits have a particularly interesting meaning. SYN means, "Synchronize the sequence numbers," which is one necessary component in initialization for TCP. The ACK field means "the acknowledgment field is valid in this header." Until the sequence numbers are initialized, the acknowledgment field cannot be very useful. Also notice that in the initial flow in Figure 5-7, no acknowledgment number is shown—this is because that number is not valid yet. Because the ACK field must be present in all the ensuing segments, the ACK bit will continue to be set until the connection is terminated.

The sequence and acknowledgment number fields are initialized to any number that fits into the 4-byte fields; the actual values shown in Figure 5-7 are simply example values. The initialization flows are each considered to have a single byte of data, as reflected in the acknowledgment number fields in the example.

Figure 5-8 shows TCP connection termination.

Figure 5-8 TCP Connection Termination

Figure 5-8 shows TCP connection termination.

This four-way termination sequence is straightforward and uses an additional flag, called the FIN bit. (FIN is short for "finished," as you might guess.) One interesting note: Before the device receiving the first FIN segment sends the third flow in the sequence, TCP notifies the application that the connection is coming down. TCP waits on an acknowledgment from the application before sending the segment. That's why the second flow is required: To acknowledge the first so that the side taking down the connection doesn't start resending the first TCP segment.

TCP Function Summary

Table 5-3 summarizes TCP functions.

Table 5-3 TCP Function Summary

Function

Description

Data transfer

Continuous stream of ordered data.

Multiplexing

Function that allows receiving hosts to decide the

correct application for which the data is destined,

based on the port number.

Error recovery (reliability)

Process of numbering and acknowledging data

with sequence and acknowledgment header fields.

Flow control using windowing

Process that uses window sizes to protect buffer

space and routing devices.

Connection establishment and termination

Process used to initialize port numbers and

sequence and acknowledgement fields.

User Datagram Protocol

The CCNA exam requires that you be able to compare and contrast the User Datagram Protocol (UDP) with TCP. UDP was designed to provide a service for applications in which messages could be exchanged. Unlike TCP, UDP provides no reliability, no windowing, and no function to ensure that the data is received in the order in which it was sent. However, UDP provides some functions of TCP, such as data transfer and multiplexing, and it does so with fewer bytes of overhead in the UDP header.

UDP multiplexes use port numbers in an identical fashion to TCP. The only difference in UDP (compared to TCP) sockets is that instead of designating TCP as the transport protocol, the transport protocol is UDP. An application could open identical port numbers on the same host but use TCP in one case and UDP in the other. This is not typical but certainly is allowed. Servers that allow use of TCP and UDP reserve the use of the same port number for each, as shown in the assigned numbers RFC (currently RFC 1700—www.isi.edu/in-notes/rfc1700.txt).

UDP data transfer differs from TCP in that no reordering or recovery is accomplished. Applications using UDP are tolerant of the lost data, or they have some application mechanism to recover lost data. For example, Domain Name System (DNS) requests use UDP because the user will retry an operation if the DNS resolution fails. The Network File System (NFS) performs recovery with application layer code, so UDP features are acceptable to NFS.

Table 5-4 contrasts typical transport layer functions as performed (or not performed) by UDP or TCP.

Table 5-4 TCP and UDP Functional Comparison

Table 5-4 contrasts typical transport layer functions as performed (or not performed) by UDP or TCP.

Table 5-4 TCP and UDP Functional Comparison

Function

Description (TCP)

Description (UDP)

Data transfer

Continuous stream of ordered data

Message (datagram) delivery

Multiplexing

Receiving hosts decide the correct application for which the data is destined, based on port number

Receiving hosts decide the correct application for which the data is destined, based on port number

Reliable transfer

Acknowledgment of data using the sequence and acknowledgment fields in the TCP header

Not a feature of UDP

Flow control

Process used to protect buffer space and routing devices

Not a feature of UDP

Connections

Process used to initialize port numbers and other TCP header fields

UDP is connectionless

Figure 5-9 shows TCP and UDP header formats. Note the existence of both source and destination port number fields in the TCP and UDP headers, but the absence of sequence acknowledgment fields in the UDP header, as shown in Figure 5-9. UDP does not need these fields because it makes no attempt to number the data for acknowledgments or resequencing.

Figure 5-9 TCP and UDP Headers

2

2

4

4

4 bits

6 bits

6 bits

2

2

2

3

1

Source Port

Dest. Port

Sequence Number

Ack. Number

Offset

Reserved

Flags

Window size

Checksum

Urgent

Options

PAD

TCP Header

2

2

2

2

Source Port

Dest. Port

Length

Checksum

UDP Header

* Unless specified, lengths shown are the numbers of bytes

UDP gains some advantages over TCP by not using the sequence and acknowledgment fields. The most obvious advantage of UDP over TCP is that there are fewer bytes of overhead. Not as obvious is the fact that UDP does not require waiting on acknowledgments or holding the data in memory until it is acknowledged. This means that UDP applications are not artificially slowed by the acknowledgment process, and memory is freed more quickly.

0 0

Post a comment