CHAPTER 8

TRANSMISSION CONTROL
PROTOCOL (TCP)

You will learn about the following in this chapter:

• TCP Header and Fields • Connection Setup and Teardown

• TCP Operation • Sequencing and

Acknowledgements

Introduction to TCP
Originally, Vinton Cerf and Robert Kahn designed TCP to provide reliable data transmission
between remote hosts communicating over a packet-switched network. Before the invention of
TCP, data transmission over packet-switched network infrastructures proved somewhat unreli-
able. The quality of delivery (or lack of reliability), different media types, and the potential for
congestion to impede data delivery made it necessary for a connection-oriented protocol to
provide end-to-end reliable services to processes and applications communicating between
remote hosts. The DoD (Department of Defense) adopted TCP as its primary protocol for reli-
able delivery of information over the ARPA network. Since its invention, TCP has become a
standard protocol for the Internet, providing guaranteed delivery of data between hosts.
TCP maps to the Host-to-Host layer within the DoD and Transport layer of the OSI model.
Only TCP and UDP function at these layers. Vendors can implement TCP when they need
guaranteed delivery of data or use UDP when they require speed more than guaranteed deliv-
ery. Figure 8.1 shows how TCP maps to the OSI and DoD reference models.
212 TCP/IP PRIMER PLUS

FIGURE 8.1 DOD OSI

TCP guarantees the deliv-
Application
ery of data at the Host-to- Process/
Application Presentation
Host or Network layer.
Session

Host to Host TCP or UDP Transport

Internet Network

Network Data Link

Access
Physical

TCP Header
Now that you understand the general functions and implementations of connection-oriented
TCP let’s explore the fields within the TCP header futher. Figure 8.2 gives an example of a TCP
header as defined in RFC 793. Figure 8.3 shows a tangible TCP header as it actually appears
during implementation. The TCP header specifies the source and destination ports, sequencing
and acknowledgement (ACK) values, and TCP flags used by a host to identify how to process
the information. A description of each item contained in the TCP header will appear following
the figures.

FIGURE 8.2 Source Port Destination Port

This figure shows the for- Sequence Number
mat of a TCP header. A
Acknowledgement Number
TCP header normally
Offset Reserved U A P R S F Window
contains 20 bytes unless
Checksum Urgent Pointer
options are being used.
Note that a header can Options + Padding

contain no options or
data.

Data
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 213

Destination port Acknowledgement number

Source port Sequence number

FIGURE 8.3
Note that in this particu-
lar TCP header no
options are being used
and the reserved bits and
urgent pointer fields are
not present.

Data offset

Control flags

Window
Checksum

TCP options

Source Port
The 2-byte source port field identifies the sending host’s communicating process (socket). An
example of this is a client port 1024–65,535 or server port 1–1023. Because TCP supports
bidirectional communication, the value in this field depends on from which direction the com-
munication comes. If the client initiates the request, the port falls within the client range. If a
server responds to the client request, the port falls within the server range.

Destination Port
The two-byte destination port identifies the receiving host’s communicating process (socket).
The port that appears in this field depends on who is communicating with whom: client to
server or server to client.

Note
Remember that each TCP segment has a source and destination port number. These port numbers
identify the sending and receiving devices. These two values, along with the source and destination
IP addresses in the IP header, make a socket pair. A socket pair indicates the two end points that
uniquely identify each TCP connection in an internet.
214 TCP/IP PRIMER PLUS

Sequence Number
TCP uses sequencing to keep track of each byte of data. Every octet of data sent over a TCP
connection has a sequence number. An algorithm calculates the initial sequence number,
which is included in the synchronization frame during session setup and is contained within
the 4-byte sequence number field. This sequence number identifies the first byte within each
datagram being sent. Think of the sequence number being expressed as “I am now sending
data starting with this number.” If the receiver does not acknowledge (ACK) the data sent, the
sender assumes the data is lost and retransmits it.

Note
Note that TCP does not sequence every byte of data, but guarantees delivery of each byte by
sequencing each octet. It merely acknowledges (ACKs) the particular sequence number within each
packet being sent. TCP also utilizes windowing to control the transmission of datagrams. We discuss
acknowledgements (ACKs) and windowing later in this chapter.

Acknowledgement Number
The 4-byte acknowledgement number field contains the value that identifies the next sequence
value the host expects to receive from the other side. The ACK number should equal the other
side’s previously sent sequence number plus the length value. The receiver implies that it
received all the data sent up to that point. This is called an implied acknowledgement. The
receiver can acknowledge receipt of multiple frames with a single acknowledgement (ACK).
This process operates more efficiently than individually acknowledging each frame and its pay-
load of bytes.
Remember that the window size determines the maximum number of bytes a sending host can
transmit. The sending host can send multiple frames if the receiver has a window size large
enough to accept them. When the receiver meets the window size, it stops and waits for per-
mission (acknowledgement) from the receiver before sending more. To calculate the acknowl-
edgement, add the first frame within this burst’s sequence number to the total of all
subsequent frame length fields; for example,
• A sending host sends 5 frames.
• The sequence number of the first frame within this stream has a sequence number of 10.
• Each frame contains 10 bytes of data.
The receiving host acknowledges this with a value of 60 (starting sequence number 10 + 50 (5
frames multiplied by the total length in bytes). The receiving host then acknowledges the
receipt of all 50 bytes of data and expects the 60th byte from the sending host. You can think
of the acknowledgement as stating, “Next I expect to receive…”
Figure 8.4 shows an output screen taken from a Sniffer of a file transfer between hosts and
how the calculation works for this particular example. Note the starting sequence number,
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 215

number of frames sent, amount of data in each frame, and the acknowledged value. To calcu-
late the acknowledgement, add the starting sequence number to the number of frames, multi-
plied by their length in bytes.

Acknowledged value
Starting sequence number Number of frames sent

FIGURE 8.4
Note that the Sniffer out-
put details information
from frame two, which is
highlighted.

Amount of data
in each frame

In the first frame shown in the top pane of the Sniffer summary screen, you can see that two
FTP hosts (client 192.42.252.20, FTP port 2918, and FTP server 192.42.252.1, port 20)
already have a functioning TCP session. In this frame the server now expects the client to now
send data beginning with sequence number 46348289, indicated by the ACK value in this
frame.
Notice that the next four frames sent by the client carry FTP data. Look in the detail pane. As
expected, the starting sequence number is 46348289, and the total amount of FTP data con-
tained within each of these four frames is 1024 bytes (indicated at the end of the TCP header).
Apply the formula and check the math (starting sequence number plus the number of frames
sent multiplied by the amount of data in each frame). If the starting sequence number is
46348289 (frame 2) and the client sends four frames with a length of 1024 bytes (frames 2–5),
the server expects 46352385 as the next sequence number. You can verify the formula with the
acknowledgement value sent by the server. It appears in the last frame (frame 6) as 46352385.

Data Offset
The 4-bit data offset field indicates where the start of upper-layer data that follows the TCP
header begins. Because the length of a TCP header can vary in size when it has certain options
216 TCP/IP PRIMER PLUS

present, data offset is necessary. TCP uses it to accurately predict where the first byte of upper-
layer data is to be expected within the frame.

Reserved
The six-bit reserved field is reserved for future use and is always represented by zeros.

Control Flags—6 Bits

The 6-bit control flags field indicates to the receiver the purpose of the frame. Figure 8.5
shows the six different control flag fields.

FIGURE 8.5
TCP uses control flags to
indicate to the receiver
how to process the data.

URG
ACK
PSH
RST
SYN
FIN

The following describes the functions of the six one-bit control flag fields:
• URG (Urgent) Set by sending host to indicate that data contained within this frame
has high priority. When the sending host sets this bit, the Urgent Pointer, which appears
under the URG bit, identifies (or points to) the next byte in the frame following the
urgent data.
• ACK (Acknowledgement) The sending host sets this bit to indicate that this frame
includes an acknowledgement of previously received data.
• PSH (Push) Each TCP session controls when data received is passed to upper-layer
applications for processing. When the sending host sets this bit, the receiver must not
wait; instead it must send the data (push) immediately to the upper-layer process. By set-
ting this bit the sending TCP host forces the receiving TCP host to pass the data up with-
out delay.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 217

• RST (Reset) Set when user aborts a session or an error occurs in a connection to indi-
cate the session should be reset.
• SYN (Synchronization) Establishes a session between ports/sockets by synchronizing
sequence numbers.
• FIN (Finish) Closes an established session and indicates that the sender has finished
sending data.

Window
The amount of data that a host can receive varies, depending on the host’s resources and how
many transmissions that host is currently receiving. The two-byte window field defines the
maximum amount of data in bytes that a TCP host can receive. A host uses this field for flow
control. A window size of zero indicates that this host cannot receive data at this time. This
typically indicates congestion or a lack of resources.

Checksum—2 Bytes
The two-byte checksum field is used to detect bit damage that might have occurred during
transit. The checksum verifies the bits within the TCP header, a pseudo IP header, and the
upper-layer data. The checksum is calculated by the sending host and compared to the receiv-
ing host for validity. If the checksum does not match, the receiving host trashes the frame and
gives no notification to the sending host. The sending host assumes responsibility for detecting
the lost frame and retransmits. TCP keeps track of information contained within the IP header,
such as source and destination addresses, to assist in detecting problems such as improperly
routed frames.

Urgent Pointer
The 2-byte Urgent Pointer field exists only when the urgent (URG) bit has been set. When the
sending host sets the urgent bit, the Urgent Pointer identifies the byte in the frame that follows
the urgent data to clearly identify where nonurgent data begins.

TCP Options—Variable Length

TCP options field can be variable lengths, depending on the options chosen by the sending
host. For example, the sending host could choose maximum segment size, which indicates the
largest segment size this TCP host will accept. Without this option, the host would accept any
segment size. The maximum segment size (MSS) option is the most commonly used option. A
complete discussion of options is well beyond the scope of this book.

TCP
The length field (which is a variable length field) identifies the total length of the TCP header
and subsequent data, and does not include the TCP pseudo header information. Because the
218 TCP/IP PRIMER PLUS

size of the TCP header and its subsequent data varies, this value also varies. Although TCP
includes the TCP length field as part of its header, the TCP length field does not actually
appear in the TCP header in a Sniffer (protocol analysis) detail output.
The TCP pseudo header provides error control on the IP header and detects misdirected
frames. It ensures that the correct destination host receives a sent datagram. TCP does not
include the information contained in the pseudo header. TCP stores this information in a TCP
memory buffer called a TCB (transmission control block). Figure 8.6 shows an example of a
TCP pseudo header.

FIGURE 8.6 IP Source Address

The TCP pseudo header IP Destination Address
allows TCP to double-
Zero IP Protocol TCP Length
check that the datagram
has arrived at the correct
destination.

Fundamentals of TCP Operation

TCP provides a bidirectional communication pipe between remote host processes, identified
by ports. As described within RFC 793, TCP controls the communications between these
processes by providing the following:
• Connection setup and teardown
• Multiplexing
• Data transfer
• Flow control
• Reliability
• Precedence and security
TCP can be thought of as the Fed-Ex of protocols, which boasts “When it absolutely, positively
has to get there overnight!” In other words, it guarantees delivery of packets. TCP actually can
boast a speedier delivery of packets than Fed-EX; however, TCP still remains slower than UDP
(which provides no reliability).
Achieving such a high standard of delivery involves overhead in the form of establishing,
maintaining, and terminating sessions between hosts. Unlike connectionless protocols, TCP
does not rely on lower layers to track data. TCP does not limit itself by only identifying the
sending and receiving host process, placing data on the wire, and hoping it arrives at its desti-
nation without any follow-up. TCP uses sequencing and acknowledgements to guarantee the
delivery of packets.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 219

Unlike its counterpart UDP, when TCP receives a stream of data (messages), it breaks the
streams into segments and assigns sequence numbers to each byte prior to delivery by IP
within a datagram. These sequence numbers require corresponding acknowledgements to be
returned from the destination to ensure it has received from the sender each segment within
the datagram. TCP maintains a copy of the segments contained within a buffer at the host,
known as a TCB (transmission control block). If it does not receive an acknowledgement, it
assumes the datagram has been lost and retransmits it. We discuss this in more detail later in
this chapter.

Connection Setup and Teardown

To provide reliable data delivery between processes, TCP must make a connection before the
upper-layer applications can exchange any meaningful data. To accomplish this, TCP estab-
lishes a connection known as a logical circuit between the remote host ports first. This connec-
tion links ports or processes running within each host. TCP maintains this connection
throughout the entire conversation and tears down the connection when it is no longer
needed.
Once IP learns the logical address of the destination host, TCP sets up a session that provides
the reliable foundation for the upper-layer protocols to deliver data. When the user or one of
the hosts requests to close a session, TCP tears the session down. We discuss the session setup
and teardown procedures and exchanges in more detail later in this chapter.

Multiplexing
Multiplexing capability enables TCP to establish and maintain multiple communication paths
between two hosts simultaneously. Multiplexing also allows a single host to distinguish and
maintain sessions with many hosts simultaneously. Hosts need this capability because usually
they run multiple applications or services such as Telnet, FTP (File Transfer Protocol), or other
services. TCP has to distinguish one process from another, and manage and maintain the com-
munications for these processes.
To accomplish this, TCP utilizes ports to differentiate communications and manage them (see
RFC 1078 TCP port service Multiplexer TCPMUX). As mentioned in Chapter 6, “Routing
Protocols,” there are two main port types: server ports and client ports. Server ports identify
major applications or services; for example, Telnet (port 23), SMTP (port 25), and FTP (ports
20, 21). Client ports vary; they are chosen on the fly and dynamically applied, ranging
1024–65535.
Each time a host starts a process it causes a port to open, allocating resources to that process.
When the process no longer needs the port it closes the port, releasing the resources associated
with that port for reallocation. TCP uses these ports to identify which process on the sending
host should be linked to which process on the destination host. The port on the host, along
with the Network layer (DoD Internet) logical IP address, identifies a unique process on a
host, referred to as a socket. Once the established TCP connection between hosts links them
together, these two sockets, referred to as a socket pair (see Figure 8.7), form a connection.
This pairing enables a host to distinguish among multiple connections from the same host or
different hosts.
220 TCP/IP PRIMER PLUS

FIGURE 8.7
Client Port Socket Pair Telnet Server
Note that the client’s IP 1004 Port 23
address, client port,
server’s IP address and 192.16.1.5 192.16.1.1
server port make up what
is called a socket pair. A

192.16.1.8
Client Port
6000
B

Data Transfer
TCP receives and organizes streams of data (messages) from upper-layer processes or applica-
tions as segments and passes them down to be formatted as datagrams by IP (Network layer)
for addressing, packing, and delivery. When IP receives datagrams from a remote host, it
inspects the protocol address within the IP header to determine whether to send the informa-
tion through TCP or UDP for processing. Figure 8.8 shows an IP header referencing TCP as
the upper-layer protocol.

FIGURE 8.8
TCP passes down seg-
ments to IP (Network
layer) for conversion to
datagrams.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 221

TCP runs on top of the Internet Protocol that provides Network Layer addressing and connec-
tionless delivery of datagrams between hosts. The protocol type value 06 identifies TCP within
the IP header. The protocol type value 17 identifies UDP within the IP header.
When TCP receives segments within datagrams from IP it reassembles them into organized
data streams (messages), identifies the receiving client or server port, and passes them on to
the appropriate (upper-layer) application for processing. The upper (applications) and lower
(Internet Protocol) layers have a bidirectional relationship depending on the direction of the
data flow. TCP provides the same fundamental services to all upper-layer protocols. This is a
simplistic view of how TCP operates; we will discuss TCP operation in more detail later in this
chapter.

Flow Control
TCP needs a method of controlling the inbound flow of data. Flow control guarantees that
incoming traffic does not overwhelm a host’s receive buffer and that the receiving host can ade-
quately process and respond to the sending host’s requests. The window mechanism identified
within the TCP header provides this function. We will take a detailed look at flow control and
the TCP header later in this chapter.
Each end host maintains its own window and advertises this window to the other side. When
congestion occurs, a host reduces its window size and advertises it to the other side. In effect,
the host asks the other side to slow down its transmissions.
When congestion no longer exists, a host can increase the size, alerting the other side that it
can send more data. The capability to dynamically increase or decrease the window as needed
is referred to as a sliding window. An administrator can configure the initial window size at the
host. This configuration varies depending on the operating system used.

Reliability
Reliability comes from TCP’s guaranteed delivery of packets. TCP requires the sequencing of
each byte sent and a corresponding acknowledgement of each byte from the other side. This
enables a host to detect whether information has been lost or sent out of order.
The receiving host does not send an ACK if datagrams become lost in transit. The transmitting
(sending) host has the task of detecting lost or missing frames and retransmits if necessary. If
the sending host does not receive an acknowledgement within a specified period of time, it
retrieves a copy of the previously sent information from its TCB buffer and retransmits the lost
data. The sending host uses a timer based on a round-trip delay calculation to detect a lost
frame and retransmit. If a timer expires before receiving an acknowledgement of sent data, the
sending host assumes the datagram is lost and retransmits.
TCP deals with damaged frames through a CRC field contained within the TCP header. The
sending host performs a CRC calculation before transmitting. The receiving host performs a
CRC check upon receipt to determine whether a datagram has been damaged while in transit.
222 TCP/IP PRIMER PLUS

If the receiving host detects a damaged datagram it simply trashes the frame without notifying
the source host. Eventually, the source host realizes something has happened to this frame
because it has not received a corresponding acknowledgement from the receiving host. At this
point the TCP timer expires, causing this host to retransmit the data.

Precedence and Security

The DoD mandates that all protocols implemented within its networks support a multilevel
security model and precedence levels. TCP can utilize the service and security options within
IP to provide this level of service to upper-layer applications. Figure 8.9 shows the options
available within the Type of Service field. TCP offers these types of services to upper-layer
applications:
• Precedence
• Delay
• Throughput
• Reliability
The options within the Type of Service field of the IP header indicate how a datagram should
be handled. When implemented, the Type of Service options, precedence delay, throughput,
and reliability influence route selection when delivering datagrams. For example, if an applica-
tion requires a datagram to be sent by a fast path when there is more than one path to a desti-
nation, it can request routers to send the frame over the path offering the lowest delay.

FIGURE 8.9
ToS bits influence how a
datagram should be han-
dled.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 223

The first option, known as precedence, indicates whether this datagram carries routine or high-
priority (precedence) information; the higher the precedence level, the higher the security
level. A host with a mismatched or lower precedence (security level) cannot establish a con-
nection to a process with another host having a higher security level. Thus a host rejects a con-
nection request based on a multilevel security basis.
Although the IP header contains the Type of Service options, TCP can make use of these func-
tions on a per-connection basis through bi-directional communication. TCP can store these
options in its TCP memory buffer to provide increased security and more efficient delivery of
application data.

Connection-oriented Characteristics
As we discussed in Chapter 6, protocols fall into one of two categories: connection-oriented or
connectionless. As a connection-oriented protocol, TCP implements all six of these basic char-
acteristics:
• Session setup
• Teardown
• Sequencing
• Acknowledgements
• Keepalives
• Flow control
The following sections detail how each of these basic characteristics work.

Session Setup
Before any data transmission can occur, a reliable connection-oriented logical circuit needs to
be established between remote hosts communicating processes or applications. Session estab-
lishment remains the same regardless of the process. TCP identifies all upper-layer processes
and applications using a port or socket address. TCP uses these port addresses to distinguish
one process from another within the same host, which ensures proper delivery and processing.
For example, when a user wants to initiate a Telnet client session with a remote Telnet server,
the user starts a local Telnet client process. This initiation causes the local host to open a
source client port identifying this Telnet process using a variable port value within the range
1024–65,535. TCP uses this source port along with a destination port (well-known port 23 for
Telnet), which indicates the intended recipient of this message. Using both the source port and
the destination port enables TCP to keep track of a pair of communicating processes and know
the processes between which it is opening a session.
224 TCP/IP PRIMER PLUS

If a user initiates a session with a remote host using a host name rather than an IP address,
some type of name resolution must occur that maps the host name to a Network layer address
of either the ultimate destination (if on the same subnet) or the gateway. After learning the
Network layer address of the destination IP host, ARP resolves this address to a MAC address
for local delivery.

Socket Pairing
Once the address resolution process has been completed, TCP has enough information to
begin the session setup process. The source Network layer address, client port/socket, and des-
tination Network layer address and server port/socket make up what is called a socket pairing.
Because the same client or multiple clients connecting to the same remote server port/socket
can request multiple TCP connections, socket pairing separates the different requests, uniquely
identifying and handling the communication between pairs. Because of the potential multitude
of connections, socket pairing remains critical to TCP’s success.
Session setup begins by the TCP client setting a bit, known as the SYN bit, within the TCP
header indicating a request for synchronization with the destination TCP process. The receiv-
ing host’s TCP session must ACK the receipt of this SYN request and send its own SYN
request. This SYN also must be acknowledged by the previous host.
Figures 8.10, 8.11, and 8.12 comprise an example of a session setup. The summary screen
shows two hosts (192.42.252.20 and 192.42.252.1) in the process of establishing a TCP con-
nection. The first frame indicates that host 192.42.252.20, using a client port of 2921,
requests a TCP connection by sending the initial SYN to the Telnet server, indicated by port 23
and IP address 192.42.252.1.

Frame 1

FIGURE 8.10
The first part of a TCP
session setup starts by the
client sending the server a
SYN. Notice this frame
does not contain an ACK
field because neither
client nor server has sent
any previous data to
acknowledge.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 225

The Telnet server sends the second frame, which serves as an ACK of the previous SYN sent by
the client and a new SYN request sent by this host. Notice this frame carries an ACK field,
which acknowledges the initial SYN by the client. Because TCP can communicate in full-
duplex mode, which means it can send and acknowledge receipt of data within the same
frame instead of requiring a separate frame to perform this function, this host can include its
SYN request within the same frame. This allows TCP to operate more efficiently

Frame 2

FIGURE 8.11
The second part of a TCP
session setup is the
server’s acknowledgement
(ACK) of the client’s SYN
and sending its own SYN
request to the client.

The client sends the third frame as an ACK of the previous SYN sent by the Telnet server. Now
that the two hosts have established a TCP session they can transmit Telnet data. Note that no
matter what type of upper-layer applications a host requests (Telnet, SMTP, FTP, and so forth),
this three-frame exchange process always occurs.
The requests and acknowledgements found in the frame exchange are known as the three-way
handshake. Because TCP has the capability of full-duplex communication, it needs only three
frames instead of four to complete this process. When the destination receives the first SYN
request from the sender, the destination responds by acknowledging the sender with its own
SYN request within the same frame.
To complete the transaction, the sender sends its ACK that it has received the destination’s SYN
request in the next and final frame of the three-way handshake. Figures 8.13, 8.14, and 8.15
comprise a detailed example of a three-way handshake. As you can see within the TCP header,
the host has set the SYN bit (indicated by a value of 1). In addition, the host has stated several
starting parameters, such as its ISN (initial sequence number 1545216000), window size
(4096 bytes), and maximum segment size (1024 bytes). We will discuss these values in more
detail later in this chapter.
226 TCP/IP PRIMER PLUS

Frame 3

FIGURE 8.12
The third part of a TCP
session setup is the client
acknowledging (ACK) the
server’s SYN.

FIGURE 8.13
Note the SYN sent by the
client in the first part of
the three-way handshake.

Figure 8.14 shows the response frame from the Telnet server (IP address 192.42.252.1, source
port 23). Notice the server includes its ACK indicating that it has received the client’s initial
request (sequence number 1545216000). The acknowledgement states that this host next
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 227

expects sequence number 1545216001, which implies that it received all sequence numbers
up to, but not including this value. You also can see the Telnet server’s ISN of 49856000. The
server has set the SYN bit indicating that it would like to synchronize with the client, setting
its window size to 4096 bytes and maximum segment size to 1024 bytes.

FIGURE 8.14
Note the ACK and SYN
sent by the server in the
second part of the three-
way handshake.

The client sends the last frame of the three-way handshake to acknowledge receipt of the
server’s previous SYN request. This host acknowledges receipt of the Telnet server’s previously
sent sequence number by indicating that it next expects to receive sequence number
49856001. Both hosts have synchronized and know each other’s starting parameters.
Within the SYN request frames TCP includes starting parameters that must be agreed upon by
both ends to successfully synchronize their sessions and begin the process of sending mean-
ingful user data. These parameters include their receive buffer size (which is elastic), initial
sequence number to be used when data transmission begins, and the optional maximum seg-
ment size this TCP host can accept. We will discuss these parameters in more detail later in
this chapter.

Session Teardown
The user or TCP can request a session teardown. If a user no longer wishes or needs the ser-
vices of the remote application, he or she can exit the local application, causing a session tear-
down request to be sent. The TCP session teardown process is similar to the session setup. It
utilizes a three-frame exchange to close the session. Either side can request a teardown. Host
192.42.252.1, sequence number 49856607, sends the initial teardown request in the first
frame, indicated by the FIN (Finish) request. Figures 8.16, 8.17, and 8.18 illustrate an exam-
ple of a session teardown request.
228 TCP/IP PRIMER PLUS

FIGURE 8.15
Note the ACK sent by the
client in the second part
of the three-way hand-
shake.

Frame 1

FIGURE 8.16
A FIN is sent as the first
part of the session tear-
down.

The recipient sends the second frame acknowledging the previous FIN request and expects to
receive a subsequent sequence number 49856608. Additionally, this host sends its own FIN
request with sequence number 1545216061. The host that initially requested the teardown
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 229

sends the final frame, acknowledging the previous FIN. This closes the connection and the
hosts cannot exchange upper-layer information until they establish a new TCP session.

Frame 2

FIGURE 8.17
As the second part of the
session teardown, the
host sends an ACK and
its own FIN request.

Frame 3

FIGURE 8.18
As the third and final part
of the session teardown,
the host acknowledges
(ACK) the other host’s
FIN request.
230 TCP/IP PRIMER PLUS

TCP sends a similar request when an unrecoverable error or denial of access occurs in a TCP
session setup. When one of these problems occurs, it causes either the client or server TCP
process to issue the teardown request. Whatever the reason for the teardown, it uses a three-
way handshake to accomplish the session teardown. Just like the session setup sequence, the
teardown process uses a three-frame sequence.
The host requesting session closure sets a FIN bit within the TCP header indicating a request
to close the session; it then sends the FIN bit to the other side. The recipient must in turn
acknowledge receipt of the initial FIN and send its own FIN, which then is acknowledged by
the original host requesting to close the session. At this point both sides release the allocated
resources and make them available for other processes.

Sequencing and Acknowledgements

The cornerstone of TCP’s services is to provide the most reliable transmission of data. To guar-
antee the delivery of datagrams, TCP sequences each byte of data it sends. This might seem
like overkill because many protocols sequence each datagram regardless of the byte size; how-
ever, this guarantees that all sent data is tracked. Tracking all the sent data can detect and cor-
rect lost data, duplicated data, and data delivered out of order.
Each time a host sends data, TCP assigns a sequence number to each byte and waits for a posi-
tive ACK of the assigned sequence numbers from the other side within a specific amount of
time. (An algorithm, which we will discuss later in the chapter, calculates this time.) If the
receiver does not respond within that specific amount of time, the sending host retransmits the
data.
The receiver utilizes the same sequence numbers to acknowledge receipt of data to detect
missing, sent out of order, or duplicated data sent by the other side. Once the receiver has the
sequenced data it can reorder these segments into data streams (messages) to be passed to the
upper-layer process or application for processing. The receiving host buffers incoming TCP
segments before passing this information up to the application and uses sequence numbers to
detect whether it has received data out of order.
Because datagrams might take very different paths before reaching their destinations, a signifi-
cant delay can occur for some of these segments. The receiving host acknowledges data
received in sequential order. For example, if a sending host sends sequence numbers 1, 2, 3,
and 4 but the destination receives only 1, 2, and 4, the receiver acknowledges only segments 1
and 2 by sending ACK=3.
The receiver buffers segment 4 in hopes that segment 3 will appear shortly. If segment 3 does
not arrive at the destination, the sending host has to retransmit the data. Hopefully, segment 3
arrives and the receiver puts the segments in order, acknowledging receipt of 3 and 4 and
passing this information up for processing.
During the session setup process each end host’s TCP session uses an algorithm to derive a
starting sequence value to be used for data exchange. Within their initial SYN frames, each
host advertises its own starting sequence value. Figure 8.19 shows an example of a TCP ses-
sion setup with the initial sequence number and SYN bit set.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 231

FIGURE 8.19
Note this host advertises
an initial sequence value
of 1545216000 during
the SYN request
exchange.

Each side of the connection can send and acknowledge data within the same datagram. This
datagram has a sequence field and an acknowledgement field. The sequence field indicates the
starting sequence of the first byte of data being transmitted within this datagram. The
acknowledgement field indicates the receipt of data from the other side up to, but not includ-
ing the sequence number reflected, which represents the value expected in the next datagram
sent.
Once both sides establish a session, the sender sequences each byte and the receiver acknowl-
edges each byte. Every TCP header has a length field indicating in bytes how much data has
been transmitted within this datagram. The destination adds this value to the starting sequence
number sent by the source to determine what the acknowledgement value should be upon the
return.
For example, if the sending host has a sequence number of 100, he sends 100 bytes of data
(representing the length in bytes). The receiving host would then send in the response frame
an ACK of 200, which represents the starting sequence number expected in the next datagram.
To figure the formula during sequencing, the starting sequence number (in this case 100) plus
length in bytes sent (in this case 100) equals acknowledgement (200). Apply this formula to
the frames in Figures 8.20 and 8.21. Telnet provides a great example, as it typically sends data
only one byte at a time, making it easy to understand how sequencing and acknowledgements
work.
The first frame shows that host 192.42.252.20 has sent the one byte of Telnet data by looking
at the Telnet header. You can see the character being transmitted as 1. Look at the end of the
TCP header and note in brackets [1 byte(s) of data] is being transmitted. This is the length
field. Also note the sequence number of this frame, 1545216045. Use the formula to anticipate
232 TCP/IP PRIMER PLUS

what ACK value the recipient should respond with. Sequence number (1545216045) plus
length (1) equals 1545216046. The second frame shows the response to the first frame. The
Telnet server acknowledges receipt of the 1 (length field) sent by sending an ACK value of
1545216046, just as we expected.

FIGURE 8.20
TCP sequences every
octet.

FIGURE 8.21
TCP acknowledges each
octet.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 233

Retransmission
The sending host determines whether a datagram needs to be retransmitted. Because data-
grams can take separate paths and might get lost, the sending device keeps a copy in case it
needs to retransmit a datagram to a destination host. When the source host sends data it places
a copy of the data into a retransmission queue in case this information needs to be resent and
starts a timer. If the sending host receives a corresponding acknowledgement in response to
the previously sent information, it deletes the copy from its queue. If the sending host does
not receive a response, or if the timer expires, it assumes the datagram is lost in transit and
retransmits the datagram from the queue.

Timers
An algorithm calculates the value of the retransmission timer based on the amount of time it
takes between sent datagrams and receipt of the corresponding acknowledgements. This algo-
rithm dynamically calculates the retransmission timer by evaluating the time between a trans-
mitted datagram and its subsequent acknowledgement. It then uses this result to compute an
SRTT (smooth round trip timer). The SRTT uses this value and a base value configured on the
host to calculate an RTO (retransmit timeout) value used by the host. An administrator can
change the base value to affect the RTO of a TCP host. The configuration of this parameter
varies depending on the operating system in use.
It’s not critical that you know the exact algorithm the host uses; only that this value controls
how long a TCP host waits for an acknowledgement before it assumes a previously sent data-
gram has been lost and needs retransmission. Figure 8.22 shows an example of TCP’s timeout
and retransmission. In it host A sends sequence #11 and #12 to host B. Host B acknowledges
receipt of those sequence numbers with ACK=12 and ACK=13. By sending ACK=13, host B
next expects to receive sequence #13 from host A. Host A sends sequence #13 and a transmis-
sion error occurs somewhere in the path, causing the frame to be lost. Because host A does not
receive an acknowledgement from host B, the transmit timer expires. At this point host A
assumes that the frame was lost in transit and retransmits sequence #13.

FIGURE 8.22 Timeout

and
If a host does not receive Retransmission
Host A Host B
an acknowledgement, it
retransmits the data.

Sequence #11 11
Ack = 12
Sequence #12 12
Ack = 13
Sequence #13 13 Lost
Transmit Timer Expires!!
Retransmission 13
of Sequence #13
Ack = 14
234 TCP/IP PRIMER PLUS

Because of the wide fluctuations in bandwidth and transmission speeds of networks, some-
times the retransmission timer cannot keep up with the transmissions. This situation occurs
when the base value on a host needs adjusting. If the retransmission timer is too low in value,
a host might retransmit a datagram too quickly.
In this case, a destination host sends an acknowledgement for the previous frame but before
the host actually receives it, the retransmission timer expires. The source host then assumes
that the destination host did not receive previously sent frame and retransmits another copy.
This scenario causes duplicate datagrams to be sent, adding more traffic and congestion (need-
less traffic) to the network load. This type of needless traffic tends to be especially problematic
on slow WAN links because resources are at a premium.
If the opposite is true (the base value of the timer is too high), it could slow so much that con-
nections drop. If the sending host cannot detect and retransmit lost datagrams within a timely
manner, applications might give up and close the connection.

Keepalives
Every connection-oriented protocol needs some way to maintain the logical circuit between
communicating processes even when no data is being exchanged; TCP is no exception. To
maintain the logical circuit TCP sends a datagram called a keepalive in which no upper-layer
data is present. It uses these types of datagrams to keep the session alive; hence the name.
Because the frame contains no data, the length field value is zero, which means the subsequent
ACK number does not advance.

Congestion
TCP uses keepalives as a normal part of session maintenance; however, this adds overhead to
the network. Depending on how many open TCP connections you have on your network,
keepalives can cause a large amount of unnecessary overhead to an already congested link.
Note that connections to remote hosts, if unused, should be released (closed) and opened only
when needed.
Think about all the users you have on your network. Now think about all the shortcuts and
mapped drive connections they have on their local computers that point to remote hosts.
These shortcuts and mapped drives provide a quick and easy way for users to connect to
remote hosts using their resources effortlessly. However, consider that for each of these quick
references to exist each of these connections needs to be opened and maintained by TCP, even
when they are not in use. Now go and disconnect them. Unmap drives that are not currently
in use or after use. Limit the amount of desktop shortcut connections users can maintain. This
cuts down on tons of needless TCP traffic and frees up critical bandwidth, especially on slower
WAN links.

Flow Control
Flow control is a function of TCP’s window feature. TCP uses flow control to manage the flow
of data into a receiver’s buffer to avoid overrunning the receiver. If a sending host transmits
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 235

data faster than a receiver can process it, the receiver asks the sender to throttle back and send
less data until the receiver can accept more.
Sometimes the receiver receives an overwhelming amount of data. If this occurs, it sends a
choke packet to tell the sender to stop sending entirely. If the situation grows to a critical level,
it might even close the TCP session.
The TCP header contains a field known as the window (see Figures 8.2 and 8.3 for an example
within a TCP header). With each frame exchange, including the initial session setup (the SYN
frame), each side of the conversation advertises to the other end the current size of its receive
buffer. Figure 8.23 shows an example of a window advertisement.

FIGURE 8.23
Notice that both hosts
advertise a window size
of 4096, or WIN=4096.

For example, if a host claims in its initial SYN frame that it can receive 4096 bytes of data by
stating WIN=4096, the peer host cannot send more than 4096 bytes of data. Each host’s win-
dow size becomes the peer host’s send window, which means that a sender cannot send more
than a receiver says it can receive. After the initial synchronization each frame carries the cur-
rent host’s receive window size, which is measured in bytes.
Hosts can adjust the window size within subsequent frames to indicate a smaller buffer when
they have congestion or expand when congestion alleviates. For example, if a host attempts to
maintain several client sessions, it could quickly find it is running out of resources and needs
to control the flow of data by decreasing the TCP window size advertised on some of these
connections. By doing this it allows the host to properly and efficiently process the data it
receives from all hosts in a timely manner.
236 TCP/IP PRIMER PLUS

If TCP had no mechanism for congestion control, some sessions could monopolize the host’s
resources, causing other client sessions to time out and close. The window mechanism enables
TCP to control the influx of traffic from a TCP session like a traffic cop. It increases the win-
dow size when it has plenty of resources to process requests (giving the green light to incom-
ing traffic). It decreases the window size when it starts to experience congestion, asking
sending hosts to slow down (giving the yellow light to incoming traffic). It stops traffic entirely
when overloaded and advertises a window of zero, referred to as a choke packet (giving the red
light to the sending host to stop transmitting entirely).
Figure 8.24 shows the various stages of windowing. Initially host B gives host A the green
light, advertising that it can accept 4096 bytes as its window size. Host A responds by sending
four frames containing 1024 bytes each. Host B, now experiencing congestion, advertises 1024
bytes as its window size, telling host A to slow down its transmissions (yellow light). Host A
responds by sending the maximum window amount 1024 bytes of data. Host B, overwhelmed
by the amount of transmissions it has received, responds by advertising a window of zero. By
advertising Window=0, host B gives host A the red light, asking host A to stop sending data
until it can accept more transmissions.

FIGURE 8.24 Sliding Window Operation

Host A Host B
A host can control flow
by telling the other the
host to slow down, speed
up or stop the transmis-
sion of frames. Window = 4096 bytes
Segment #1 1024 I can accept up to
4096 bytes!
Segment #2 1024

Segment #3 1024

Segment #4 1024
Window = 1024
Slow down!
Segment #5 1024
Window = 0
Stop sending!

The sender uses the window as an indication of how much data it can send before the receiver
must give it permission (by sending an ACK) to send more. If a zero window condition contin-
ues for a lengthy period of time without transitioning to a positive window size, eventually it
forces the connection to close. Note that even if a zero window condition exists on a host, that
host can still transmit data but can receive only critical frames such as ACKs and those carry-
ing the RST (reset) or URG bits.
Figure 8.25 shows an example of a zero window condition. When a host advertises a zero win-
dow, it indicates to the sending host to stop sending data until it advertises a positive window
size. When a host advertises a zero window, usually this indicates it has limited resources or is
busy servicing other hosts and might be overwhelmed.
 Chapter 8 • TRANSMISSION CONTROL PROTOCOL (TCP) 237

FIGURE 8.25
A host can stop the send-
ing host from transmit-
ting any more data with a
choke packet.

A zero window does not pose a problem unless it occurs frequently. When a host continuously
advertises a zero window, this usually indicates that a host needs more memory, CPU power,
or applications offloaded to other hosts. A zero window that persists for a lengthy period of
time will cause connections to close.

TCP Ports
TCP uses well-known ports to establish a client-server relationship. TCP uses these ports at
the Transport layer to identify which upper-layer processes have sent or should receive data
streams. Table 8.1 lists many of the well-known TCP port numbers.

TABLE 8.1 Well-known TCP Port Numbers

Decimal Keyword Protocol(s) Description

20 FTP-Data TCP File Transfer Protocol (Data)

21 FTP TCP File Transfer Protocol (Control)

23 Telnet TCP Telnet

25 SMTP TCP Simple Mail Transfer Protocol

49 LOGIN TCP Login Host Protocol

238 TCP/IP PRIMER PLUS

TABLE 8.1 Continued

Decimal Keyword Protocol(s) Description

53 DNS TCP/UDP Domain Name Service

63 VIA-FTP TCP VIA-Systems-FTP

70 Gopher TCP Gopher File Service

80 WWW TCP World Wide Web Services

Summary
RFC 793 defines TCP. Since its invention, TCP has become a standard protocol used on the
Internet, providing guaranteed delivery of data between hosts. It provides a bidirectional com-
munication pipe between remote host processes, identified by ports. TCP controls the commu-
nications between these processes by providing connection setup and teardown, multiplexing,
data transfer, flow control, reliability and precedence and security.
Because TCP guarantees delivery of data, it requires the sequencing of each byte sent and a
corresponding acknowledgement of each byte from the other side. TCP accomplishes this in
what is called a three-way handshake.
To manage the flow of data into a receiver’s buffer, TCP utilizes flow control. Through the win-
dow mechanism contained in the TCP header, a receiver can ask the sender to slow down,
speed up, or stop transmitting depending on how much data its buffer can accept. This
process is called a sliding window, or windowing.

Review Questions
1. During TCP operation, what six fundamental functions does TCP use to control the
communications between remote host process?
2. What must occur before upper-layer applications can exchange meaningful data?
3. What allows TCP the capability to establish and maintain multiple communication paths
between two hosts simultaneously?
4. TCP receives ___________ from upper-layer applications and organizes them into
__________ to be passed down to the Network layer to become __________.
5. What mechanism controls the inbound flow of data?
6. How does TCP provide reliable delivery of packets?
7. What are the six basic characteristics of connection-oriented protocols?