Lesson 1:TCP and UDP

The TCP/IP protocol suite has two protocols at the transport layer: the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP is a connection-oriented protocol that provides reliable service with guaranteed delivery, packet acknowledgment, flow control, and error correction and detection. TCP is designed for the transmission of large amounts of data that require perfect bit accuracy, such as program and data files. UDP is a connectionless protocol that provides unreliable service. It is used primarily for short transactions that consist of a single request and reply. Not surprisingly, TCP generates much more control traffic as it provides all of these services, whereas UDP's overhead is quite low.

The term reliable, in the context of a protocol's service, refers to its ability to provide guaranteed delivery of data with acknowledgment from the recipient. It is not a reflection of the protocol's relative value. In fact, unreliable protocols can usually be counted on to deliver their messages to the destination without error.


After this lesson, you will be able to

  • Describe the services provided by TCP and UDP
  • Understand the functions of the various TCP and UDP header fields

Estimated lesson time: 50 minutes


The TCP/IP suite uses two protocols at the transport layer to provide different levels of service for applications. Both TCP and UDP generate protocol data units (PDUs) that are carried inside Internet Protocol (IP) datagrams. TCP provides a variety of services that IP lacks, so the two protocols complement each other without duplicating the network layer functions. The combination of UDP and IP provides a minimal transport service that keeps overhead low.

TCP

The TCP/IP protocol suite gets its name from the combination of the TCP and IP protocols, which together provide the service that accounts for the majority of traffic on a TCP/IP network. Internet applications such as Web browsers, File Transfer Protocol (FTP) clients, and e-mail readers all depend on the TCP protocol to retrieve, without error, large amounts of data from servers. TCP is defined in Request For Comments (RFC) 793, published in 1981 by the Internet Engineering Task Force (IETF).

The TCP Header

Transport layer protocols encapsulate data that they receive from the application layer protocols operating above them by applying a header, just as the protocols at the lower layers do. In many cases, the application layer protocol passes more data to TCP than can fit into a single packet, so TCP splits the data into smaller pieces. Each piece is called a segment, and the segments that comprise a single transaction are known collectively as a sequence. Each segment receives its own TCP header, as illustrated in Figure 7.1, and is passed down to the network layer for transmission in a separate datagram. When all of the segments arrive at the destination, the receiving computer reassembles them into the original sequence.

Figure 7.1  The TCP message format

The functions of the TCP message fields are as follows:

  • Source Port (2 bytes).  This field identifies the process on the transmitting system that generated the information carried in the Data field.
  • Destination Port (2 bytes).  This field identifies the process on the receiving system for which the information in the Data field is intended.
  • Sequence Number (4 bytes).  This field identifies the location of the data in this segment in relation to the entire sequence.
  • Acknowledgment Number (4 bytes).  In acknowledgment (ACK) messages, this field specifies the sequence number of the next segment expected by the receiving system.
  • Data Offset (4 bits).  This field specifies the number of 4-byte words in the TCP header.
  • Reserved (6 bits).  This field is unused.
  • Control Bits (6 bits).  This field contains 6 flag bits that identify the functions of the message.
  • Window (2 bytes).  This field specifies how many bytes the computer is capable of accepting from the connected system.
  • Checksum (2 bytes).  This field contains the results of a cyclical redundancy check (CRC) computation performed by the transmitting system, and is used by the receiving system to detect errors in the TCP header, data, and parts of the IP header.
  • Urgent Pointer (2 bytes).  When the urgent (URG) control bit is present, this field indicates which part of the data in the segment the receiver should treat as urgent.
  • Options (variable).  This field may contain information related to optional TCP connection configuration features.
  • Data (variable).  This field may contain one segment of an information sequence generated by an application layer protocol.

Ports and Sockets

As with data-link and network layer protocols, one of the important functions of a transport layer protocol is to identify the protocol or process that generated the data it carries. Both TCP and UDP do this by specifying the number of a port that has been assigned to a particular process by the Internet Assigned Numbers Authority (IANA). These port numbers are published in RFC 1700—the "Assigned Numbers" RFC—and a list of the most common ports is included with every TCP/IP client in a text file called SERVICES. When a TCP/IP packet arrives at its destination, the transport layer protocol receiving the IP datagram reads the value in the Destination Port field and delivers the information in the Data field to the program or protocol associated with that port.

All of the common Internet applications have particular port numbers associated with them, called well-known ports. A list of the most commonly used well-known ports is found in Table 7.1. For example, Web servers use port 80, and Domain Name System (DNS) servers use port 53. TCP and UDP both maintain their own separate lists of well-known port numbers. FTP uses TCP ports 20 and 21. Because FTP uses only TCP (and not UDP) at the transport layer, it is also possible for a different application layer protocol to use the same ports (20 and 21) with the UDP protocol. However, in some cases, a protocol can use either transport layer protocol. DNS, for example, is associated with both TCP port 53 and UDP port 53.

Table 7.1  Well-Known Port Numbers

Service Name Port Number Protocol Function

ftp-data

20

TCP

FTP data channel; used for transmitting files between systems

ftp

21

TCP

FTP control channel; used for exchanging commands and responses by FTP connected systems

telnet

23

TCP

Telnet; used to execute commands onnetwork-connected systems

smtp

25

TCP

Simple Mail Transport Protocol; used tosend e-mail messages

domain

53

TCP and UDP

DNS; used to receive host name resolu-tion requests from clients

bootps

67

TCP and UDP

Bootstrap Protocol (BOOTP) andDynamic Host Configuration Protocol (DHCP) servers; used to receive TCP/IPconfiguration requests from clients

bootpc

68

TCP and UDP

BOOTP and DHCP clients; used to sendTCP/IP configuration requests to servers

http

80

TCP

Hypertext Transfer Protocol (HTTP); usedby Web servers to receive requests fromclient browsers

pop3

110

TCP

Post Office Protocol 3 (POP3); used toreceive e-mail requests from clients

snmp

161

TCP and UDP

Simple Network Management Protocol (SNMP); used by SNM P agents to transmit status information to a network manage- ment console

When one TCP/IP system addresses traffic to another, it uses a combination of an IP address and a port number. The combination of an IP address and a port is called a socket. To specify a socket in a Uniform Resource Locator (URL), you enter the IP address first and then follow it with a colon and then the port number. The socket 192.168.2.10:21, for example, addresses port 21 on the system with the address 192.168.2.10. Because the port number for the FTP control port is 21, this socket addresses the FTP server running on that computer.

You usually don't have to specify the port number when you're typing a URL because the program you use assumes that you want to connect to the well-known port. Your Web browser, for example, addresses all the URLs you enter to port 80, the HTTP Web server port, unless you specify otherwise. The IANA port numbers are recommendations, not ironclad rules, however. You can configure a Web server to use a port number other than 80, and in fact, many Web servers assign alternate ports to their administrative controls, so that only users who know the correct port number can access them. You can create a semisecret Web site of your own by configuring your server to use port 81, for example, instead of 80. Users would then have to type a URL like http://www.myserver.com:81 into their browsers instead of just http://www.myserver.com.

The well-known ports published in the "Assigned Numbers" RFC mostly refer to servers. Because it is the client that usually initiates communication with the server, and not the other way around, clients don't need permanently assigned port numbers. Instead, a client program typically selects a port number at random, called an ephemeral port number, to use while communicating with a particular server. The IANA only controls port numbers from 1 to 1023, so ephemeral port numbers always have values higher than 1024. A server receiving a packet from a client uses the value in the TCP header's Source Port field to address its reply to the correct ephemeral port in the client system.

Control Bits

The Control Bits field of the TCP header contains six flags that signify particular message functions. In most cases, systems activate the various flags to make a TCP message perform a control function; for example, to participate in the connection establishment process or to acknowledge the proper receipt of a data segment. The functions of the six flags are as follows:

  • URG.  This flag indicates that the segment contains urgent data. When this flag is present, the receiving system reads the contents of the Urgent Pointer field to determine which part of the Data field contains the urgent information.
  • ACK.  This flag indicates that the message is an acknowledgment of a previously transmitted segment. When this flag is present, the system receiving the message reads the contents of the Acknowledgment Number field to determine what part of the sequence it should transmit next.
  • PSH.  This flag indicates that the receiving system should forward the data it has received in the current sequence to the process identified in the Destination Port field immediately, rather than wait for the rest of the sequence to arrive.
  • RST.  This flag causes the receiving system to reset the TCP connection and discard all of the segments of the sequence it has received thus far.
  • SYN.  This flag is used to synchronize the systems' respective Sequence Number values during the establishment of a TCP connection.
  • FIN.  This flag is used to terminate a TCP connection.

Establishing a Connection

TCP is a connection-oriented protocol, which means that before two systems can exchange application layer data, they must first establish a connection. This connection ensures that both computers are present, operating properly, and ready to receive data. The TCP connection remains alive during the entire exchange of data, after which the systems close it in an orderly manner.

In most cases, a TCP connection exists for the duration of a single file transmission. For example, when a Web browser connects to a server on the Internet, it first establishes a connection with the server, then transmits an HTTP request message containing a URL, and finally receives the file specified in the request from the server. Once the file is transferred, the systems terminate the connection. As the browser processes the downloaded file, it may detect links to graphic images, audio clips, or other files needed to display the Web page. The browser then establishes a separate connection to the server for each of the linked files, retrieves them, and displays them as part of the downloaded page. Thus, a single Web page may require the browser to create dozens of separate TCP connections to the server to download the individual files.

The TCP connection establishment process is known as a three-way handshake. The process consists of an exchange of three messages (as shown in Figure 7.2), none of which contain any application layer data. The purpose of these messages, apart from ascertaining that the other computer actually exists and is ready to receive data, is to exchange the sequence numbers that the computers will use to number the messages they will transmit. At the start of the connection establishment process, each computer selects an initial sequence number (ISN) for the first TCP message it transmits. The systems then increment the sequence numbers for each subsequent message. The computers select an ISN using an incrementing algorithm that makes it highly unlikely for connections between the same two sockets to use identical sequence numbers at the same time. Each system maintains its own sequence numbers, and, during the handshake, each informs the other of the numbers it will be using.

Figure 7.2  TCP uses a three-way handshake to establish a connection between two systems

The messages that contain the ISN for each system have the SYN flag set in the Control Bits field. In a typical TCP transaction, a client system generates its SYN message, with its ISN in the Sequence Number field. The server, on receiving this message, generates a response that performs two functions. First, the ACK flag is set, so that the message functions as an acknowledgment of the client's SYN message. Second, the server's response also has the SYN flag set and includes its own ISN in the Sequence Number field. When the client system receives the server's SYN message, it generates a response of its own, which contains the ACK flag. Once the server receives the client's acknowledgment, the connection is established, and the systems are ready to exchange messages containing application data. Thus, a TCP connection is actually two separate connections running in opposite directions. TCP is therefore known as a full-duplex protocol, because the systems establish each connection separately and later terminate each one separately.

It is important to remember that the connection established by two TCP systems is only a logical connection. The individual TCP messages are still carried within IP datagrams, using IP's connectionless service. The messages may take different routes to the destination and may even arrive in a different order from that in which they were transmitted. TCP is designed to account for all of these possibilities, and it rearranges the data segments into the proper sequence.

Run the TCPConnection video located in the Demos folder on the CD-ROM accompanying this book for a demonstration of the TCP connection establishment process.

Another function of the SYN messages generated by the two computers during the three-way handshake is for each system to inform the other of its maximum segment size (MSS). Each system uses the other system's MSS to determine how much data it should include in its upcoming messages. The MSS value for each system depends on which data-link layer protocol is used by the network on which each system resides. The MSS is included as an option in the two SYN packets. This option takes the form of 4 additional bytes in the TCP header's Options field, using the following subfields:

  • Kind (1 byte).  This subfield specifies the option type. The MSS option uses a value of 2.
  • Length (1 byte).  This subfield specifies the length of the option in bytes. For MSS, the value is 4.
  • Maximum Segment Size (2 bytes).  This subfield specifies the MSS for the system in bytes.

Transmitting Data

After the connection has been established, each computer has all of the information it needs for TCP to begin transmitting application data, as follows:

  • Port number.  The client is already aware of the well-known port number for the server, which it needed to initiate the connection. The messages from the client to the server contain the ephemeral port number (in the Source Port field) that the server must use in its replies.
  • Sequence number.  Each system uses the other system's sequence numbers in the Acknowledgment Number field of its own messages.
  • MSS.  Using the information in the MSS option, the systems know how large to make the segments of each sequence.

Whether the client or the server transmits its data first depends on the nature of the application. A transaction between a Web browser client and a Web server begins with the client sending a particular URL to a server, typically requesting a site's home page. Other client/server transactions may begin with the server sending data to the client.

Acknowledging Packets

The Sequence Number and Acknowledgment Number fields are the key to TCP's packet acknowledgment and error correction systems. During the handshake, when the server replies to the client's SYN message, the SYN/ACK message that the server generates contains its own ISN in the Sequence Number field, and it also contains a value in its Acknowledgment Number field. This Acknowledgment Number value is the equivalent of the client's ISN plus one. The function of this field is to inform the other system what value is expected in the next message's Sequence Number field, so if the client's ISN is 1000000, the server's SYN/ACK message contains the value 1000001 in its Acknowledgment Number field. When the client sends its first data message to the server, that message will have the value 1000001 in its Sequence Number field, which is what the server expects.

You may wonder why the client's first data message has the Sequence Number value 1000001 when it previously had to send an ACK message in response to the server's SYN. It may seem that the ACK message should have used Sequence Number 1000001, but in fact, messages that function solely as acknowledgments do not increment the sequence number counter. The server's SYN/ACK message does increment the counter because of the inclusion of the SYN flag.

When the systems begin to send data, they increment their Sequence Number values for each byte of data they transmit. When a Web browser sends its URL request to a Web server, for example, its Sequence Number value is its ISN plus one (1000001), as expected by the server. Assuming that the actual file or Web page requested by the client is 500 bytes (not including the IP or TCP headers), the server will respond to the request message with an ACK message that contains the value 1000501 in its Acknowledgment Number field. This indicates that the server has received 500 bytes of data successfully and is expecting the client's next data packet to have the Sequence Number 1000501. Because the client has transmitted 500 bytes to the server, it increments its Sequence Number value by that amount, and the next data message it sends will use the value that the server expects (assuming there are no transmission errors).

The same message numbering process also occurs simultaneously in the other direction. The server has transmitted no data yet, except for its SYN/ACK message, so the ACK generated by the client during the handshake contains the server's ISN plus one. The server's acknowledgment of the client's request contained no data, so the Sequence Number field was not incremented. Thus, when the server responds to the client's URL request, its first data message will use the same ISN-plus-one value in its Sequence Number field, which is what the client expects (see Figure 7.3).

Figure 7.3  After the Web browser client transmits its URL request message, the server responds with an ACK message, which is followed by a data message containing the requested Web page

In the case described here, the client's URL request is small and requires only one TCP message, but in most cases, the Web server responds by transmitting a Web page, which is likely to require a sequence of TCP messages consisting of multiple segments. The server divides the Web page (which becomes the sequence it is transmitting) into segments no larger than the client's MSS value. As the server begins to transmit the segments, it increments its Sequence Number value according to the amount of data in each message. If the server's ISN is 20000, the Sequence Number of its first data message will be 20001. Assuming that the client's MSS is 1000, the server's second data message will have a Sequence Number of 21001, the third will be 22001, and so on.

Once the client begins receiving data from the server, it is responsible for acknowledging the data. TCP uses a system called delayed acknowledgments, which means that the systems do not have to generate a separate acknowledgment message for every data message they receive. The intervals at which the systems generate their acknowledgments is left up to the individual TCP implementation. Each acknowledgment message that the client sends in response to the server's data messages has the ACK flag, of course, and the value of its Acknowledgment Number field reflects the number of bytes in the sequence that the client has successfully received.

If the client receives messages that fail the CRC check or fails to receive messages containing some of the segments in the sequence, it signals these failures to the server using the Acknowledgment Number field in the ACK messages. The Acknowledgment Number value always reflects the number of bytes from the beginning of the sequence that the destination system has received correctly. If, for example, a sequence consists of 10 segments, and all are received correctly except the seventh segment, the recipient's acknowledgment message will contain an Acknowledgment Number value that reflects the number of bytes in the first six segments only. Segments 8 through 10, even though they were received correctly, are discarded and must be retransmitted along with segment 7. This system is called positive acknowledgment with retransmission because the destination system only acknowledges the messages that were sent correctly. A protocol that uses negative acknowledgement would assume that all messages have been received correctly except for those that the destination system explicitly lists as having errors.

The source system maintains a queue of the messages that it has transmitted and deletes those messages for which acknowledgments have arrived. Messages that remain in the source system's queue for a predetermined period of time are assumed to be lost or discarded, and the system automatically retransmits them.

Once the server has transmitted all of the segments in the sequence that contains the requested Web page and the client acknowledges that it has received all of the segments correctly, the systems terminate the connection. This termination procedure is described in the section entitled "Terminating the Connection," later in this lesson. If the segments have arrived at their destination out of sequence, the receiving system uses the Sequence Number values to reassemble them into the proper order. The client system then processes the data it has received to display the Web page. In all likelihood, the page will contain links to images or other elements, and the client will have to initiate additional connections to the server to download more data. This is the nature of the Web client/server process. However, other types of applications might maintain a single TCP connection for a much longer period of time and perform repeated exchanges of data in both directions. In a case like this, both systems can exchange data messages and acknowledgments, with the error detection and correction processes occurring on both sides.

Detecting Errors

There are basically two things that can go wrong during a TCP transaction: Messages can arrive in a corrupted state, or they can fail to arrive at all. When messages fail to arrive, the lack of acknowledgments from the destination system causes the sender to retransmit the missing messages. If a serious network problem arises that prevents the two systems from exchanging any messages, the TCP connection eventually times out and the entire process must start again.

When messages do arrive at their destination, the receiving system checks them for accuracy by performing the same checksum computation that the sender performed before transmitting the data and comparing the results to the value in the Checksum field. If the values don't match, the system discards the message. This is a crucial element of the TCP protocol, because it is the only end-to-end checksum performed on the actual application layer data. IP includes an end-to-end checksum, but only on its header data, and data-link layer protocols like Ethernet and Token Ring contain a checksum, but only for one hop at a time. If the packets pass through a network that doesn't provide a checksum, such as a Point-to-Point Protocol (PPP) link, there is a potential for errors that can't be detected at the data-link or network layers to be introduced.

The checksum performed by TCP is unusual because it is calculated not only on the entire TCP header and the application data, but also on a pseudo-header. The pseudo-header consists of the IP header's Source IP Address, Destination IP Address, Protocol, and Length fields, plus 1 byte of padding, to bring the total number of bytes to an even 12 (three 4-byte words), as shown in Figure 7.4. The inclusion of the pseudo-header ensures that the datagrams are delivered to the correct computer and the correct transport layer protocol on that computer.

Figure 7.4  TCP computes its checksum on the header, data, and a pseudo-header derived from the IP header

Flow Control

Flow control is the process by which the destination system in a TCP connection provides information to the source system that enables that source system to regulate the speed at which it transmits data. Each system has a limited amount of buffer space in which to store incoming data. The data remains in the buffer until the system generates messages acknowledging that data. If the system transmitting the data sends too much information too quickly, the receiver's buffers could fill up, forcing it to discard data messages. The system receiving the data uses the Window field in its acknowledgment messages to inform the sender of how much buffer space it has available at that time. The transmitting system uses the Window value along with the Acknowledgment Number value to determine what data in the sequence the system is permitted to transmit. For example, if an acknowledgment message contains an Acknowledgment Number value of 150000 and a Window value of 500, the sending system knows that all of the data in the sequence through byte 150000 has been received correctly at the destination, and that it can now transmit bytes 150001 through 150500. If, by the time the sender transmits those 500 bytes, it has received no additional acknowledgments, it must stop transmitting until the next acknowledgment arrives.

This type of flow control is called a sliding window technique. The offered window (shown in Figure 7.5) is the series of bytes that the receiving system has permitted the transmitting system to send. As the receiving system acknowledges the incoming bytes, the left side of the window moves to the right, and as the system passes the acknowledged bytes up to the application layer process indicated by the Destination Port number, the right side of the window moves to the right. Thus the window can be said to be sliding along the incoming byte stream, from left to right.

Figure 7.5  TCP uses a sliding window technique to provide flow control

Terminating the Connection

Once the systems involved in a TCP connection have finished their exchange of data, they terminate the connection using control messages, much like those used in the three-way handshake that established the connection. As with the establishment of the connection, which system initiates the termination sequence depends on the application generating the data. In the case of the Web client/server transaction used as an example in this lesson, the server begins the termination process by setting the FIN flag in the Control Bits field of its last data message. In other cases, the system initiating the termination process might use a separate message containing the FIN flag and no data.

The system receiving the FIN flag transmits an acknowledgment message and then generates its own message containing a FIN flag, to which the other system must respond with an ACK message. This is necessary because, as shown in the establishment process, the connection runs in both directions, and it is necessary for both systems to terminate their respective connections using a total of four messages (see Figure 7.6). Unlike the connection establishment procedure, the computers can't combine the FIN and ACK flags in the same message, which is why four messages are needed instead of three. There are some occasions when only one of the two connections is terminated and the other is left open. This is called a half close.

Figure 7.6  The TCP connection termination process

UDP

UDP is defined in RFC 768, "User Datagram Protocol." Unlike TCP, UDP is a connectionless protocol that provides no packet acknowledgment, flow control, segmentation, or guaranteed delivery. As a result, UDP is far simpler than TCP and generates far less overhead. Not only is the UDP header much smaller than that of TCP—8 bytes as opposed to 20 bytes or more—there are no separate control messages, such as those used to establish and terminate connections. UDP transactions typically consist of only two messages—a request and a reply—with the reply functioning as a tacit acknowledgment. For this reason, most of the applications that use UDP must transport only amounts of data small enough to fit into a single message. DNS and DHCP are two of the most common application layer protocols that use UDP. There are some applications that use UDP to transmit large amounts of data, such as streaming audio and video, but UDP is appropriate for these purposes because this type of data can survive the loss of an occasional packet, whereas a program or data file cannot.

The format of a UDP message is shown in Figure 7.7.

Figure 7.7  The UDP message format

The functions of the UDP message fields are as follows:

  • Source Port (2 bytes).  This field identifies the process on the transmitting system that generated the information carried in the Data field.
  • Destination Port (2 bytes).  This field identifies the process on the receiving system for which the information in the Data field is intended.
  • Length (2 bytes).  This field specifies the length of the UDP header and data in bytes.
  • Checksum (2 bytes).  This field contains the results of a CRC computation performed by the transmitting system and is used by the receiving system to detect errors in the UDP header, data, and parts of the IP header.
  • Data (variable).  This field contains the information generated by the application layer process specified in the Source Port field.

The Source Port and Destination Port fields in a UDP header perform the same function as they do in the TCP header. The Length field specifies how much data is included in the UDP message, and the Checksum value is computed using the message header, data, and the IP pseudo-header, just as in TCP. The UDP standard specifies that the use of the checksum is optional. The transmitting system fills the Checksum field with zeroes if it is unused. There has been a great deal of debate about whether UDP messages should include checksums. RFC 768 requires all UDP systems to be capable of checking for errors using checksums, and most current implementations include the checksum computations.

Exercise 1: TCP Header Fields

Match the TCP header field in the left column with the correct description in the right column.

  1. Source Port
  2. Sequence Number
  3. Checksum
  4. Window
  5. Urgent Pointer
  6. Data Offset
  7. Destination Port
  8. Acknowledgment
  9. Control Bits
  10. Data
  1. Specifies how many bytes the sender can transmit
  2. Specifies the number of bytes in the sequence that have been successfully transmitted
  3. Specifies the functions of messages used to initiate and terminate connections
  4. Contains information for the application layer
  5. Specifies which of the bytes in the message should receive special treatment from the receiving system
  6. Identifies the application or protocol that generated the data carried in the TCP message
  7. Used to reassemble segments that arrive at thedestination out of order
  8. Specifies the length of the TCP header Number
  9. Contains error detection information
  10. Specifies the application that will make use of the data in the message

Exercise 2: TCP and UDP Functions

Specify whether each of the following statements describes TCP, UDP, or both.

  1. It provides flow control.
  2. It is used for DNS communications.
  3. It detects transmission errors.
  4. It is used to carry DHCP messages.
  5. It divides data to be transmitted into segments.
  6. It acknowledges transmitted messages.
  7. It is used for Web client/server communications.
  8. It requires a connection establishment procedure.
  9. It contains a Length field.
  10. It uses a pseudo-header in its checksums.

Lesson Review

  1. In TCP, what does "delayed acknowledgment" mean?
    1. A predetermined time interval must pass before the receiving system can acknowledge a data packet.
    2. Data segments are not acknowledged until the entire sequence has been transmitted.
    3. The receiving system doesn't have to generate a separate acknowledgment message for every segment.
    4. A data segment must be acknowledged before the next segment is transmitted.
  2. What does the Data Offset field in the TCP header specify?
    1. The length of the TCP header
    2. The location of the current segment in the sequence
    3. The length of the Data field
    4. The checksum value used for error detection
  3. What is the combination of an IP address and a port number called?
    1. A sequence number
    2. A checksum
    3. A data offset
    4. A socket
  4. Which of the following TCP/IP systems uses an ephemeral port number?
    1. The client
    2. The server
    3. The system initiating the TCP connection
    4. The system terminating the TCP connection
  5. What flag does the first message transmitted in any TCP connection contain?
    1. ACK
    2. SYN
    3. FIN
    4. PSH
  6. What TCP header field provides flow control?
    1. Window
    2. Data Offset
    3. Acknowledgment
    4. Sequence Number
  7. Which of the following services does the UDP protocol provide?
    1. Flow control
    2. Guaranteed delivery
    3. Error detection
    4. None of the above

Lesson Summary

  • Transmission Control Protocol (TCP) is a connection-oriented protocol that provides services such as packet acknowledgment, flow control, error detection and correction, and segmentation.
  • Establishing a TCP connection between two systems requires a three-way handshake, during which each computer supplies the other with the sequence number it will assign to its messages, plus its maximum segment size (MSS).
  • To transmit large amounts of data over a TCP connection, a system divides a byte stream into multiple segments, each of which is transmitted in a separate message.
  • The system receiving the data segments acknowledges them with occasional messages used for that purpose. Unacknowledged messages are eventually retransmitted.
  • Acknowledgment messages inform the other system how much data it can transmit. This is called flow control.
  • TCP messages contain a checksum that the receiving system uses to detect transmission errors.
  • Closing a TCP connection requires the systems to exchange termination (FIN) messages and acknowledgments.
  • User Datagram Protocol (UDP) is a connectionless protocol that provides error detection through checksums, but it provides none of the other services found in TCP.


Network+ Certification Training Kit
Self-Paced Training Kit Exam 70-642: Configuring Windows Server 2008 Network Infrastructure
ISBN: 0735651604
EAN: 2147483647
Year: 2001
Pages: 105

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net