Chapter 1: Introduction to TCP/IP Transport and Applications 15
Flow Control Using Windowing
TCP implements flow control by using a window concept that is applied to the amount of
1
data that can be outstanding and awaiting acknowledgment at any one point in time. The
window concept lets the receiving host tell the sender how much data it can receive right
now, giving the receiving host a way to make the sending host slow down or speed up. The
receiver can slide the window size up and down—called a sliding window or dynamic win-
dow—to change how much data the sending host can send.
The sliding window mechanism makes much more sense with an example. The example,
shown in Figure 1-9, uses the same basic rules as the examples in the previous few figures.
In this case, none of the TCP segments have errors, and the discussion begins one TCP seg-
ment earlier than in the previous two figures.
Web Browser Web Server
ACK=1000
Window=3000
I Received a New 1
Window: 3000 SEQ=1000
SEQ=2000
SEQ=3000
I Must Wait 2 3 Send an ACK = 4000
for an ACK Grant a New
Window: 4000
ACK=4000
Window=4000
I got an ACK! 4
I also got a Larger
Window: 4000
Figure 1-9 TCP Windowing
Begin with the first segment, sent by the server to the PC. The Acknowledgment field
should be familiar by now: it tells the PC that the server expects a segment with sequence
number 1000 next. The new field, the window field, is set to 3000. Because the segment
flows to the PC, this value tells the PC that the PC can send no more than 3000 bytes over
this connection before receiving an acknowledgment. So, as shown on the left, the PC real-
izes it can send only 3000 bytes, and it stops sending, waiting on an acknowledgment, after
sending three 1000-byte TCP segments.
Continuing the example, the server not only acknowledges receiving the data (without
any loss), but the server decides to slide the window size a little higher. Note that second
message flowing right to left in the figure, this time with a window of 4000. Once the PC
receives this TCP segment, the PC realizes it can send another 4000 bytes (a slightly larger
window than the previous value).
Note that while the last few figures show examples for the purpose of explaining how the
mechanisms work, the examples might give you the impression that TCP makes the hosts
sit there and wait for acknowledgments a lot. TCP does not want to make the sending host
have to wait to send data. For instance, if an acknowledgment is received before the win-
dow is exhausted, a new window begins, and the sender continues sending data until the
16 CCNA 200-301 Official Cert Guide, Volume 2
current window is exhausted. Often times, in a network that has few problems, few lost
segments, and little congestion, the TCP windows stay relatively large with hosts seldom
waiting to send.
User Datagram Protocol
UDP provides a service for applications to exchange messages. Unlike TCP, UDP is connec-
tionless and provides no reliability, no windowing, no reordering of the received data, and
no segmentation of large chunks of data into the right size for transmission. However, UDP
provides some functions of TCP, such as data transfer and multiplexing using port numbers,
and it does so with fewer bytes of overhead and less processing required than TCP.
UDP data transfer differs from TCP data transfer in that no reordering or recovery is
accomplished. Applications that use UDP are tolerant of the lost data, or they have some
application mechanism to recover lost data. For example, VoIP uses UDP because if a voice
packet is lost, by the time the loss could be noticed and the packet retransmitted, too much
delay would have occurred, and the voice would be unintelligible. Also, DNS requests use
UDP because the user will retry an operation if the DNS resolution fails. As another exam-
ple, the Network File System (NFS), a remote file system application, performs recovery
with application layer code, so UDP features are acceptable to NFS.
Figure 1-10 shows the UDP header format. Most importantly, note that the header includes
source and destination port fields, for the same purpose as TCP. However, the UDP has
only 8 bytes, in comparison to the 20-byte TCP header shown in Figure 1-1. UDP needs a
shorter header than TCP simply because UDP has less work to do.
4 Bytes
Source Port Destination Port
Length Checksum
Figure 1-10 UDP Header
TCP/IP Applications
The whole goal of building an enterprise network, or connecting a small home or office net-
work to the Internet, is to use applications such as web browsing, text messaging, email, file
downloads, voice, and video. This section examines one particular application—web brows-
ing using Hypertext Transfer Protocol (HTTP).
The World Wide Web (WWW) consists of all the Internet-connected web servers in the
world, plus all Internet-connected hosts with web browsers. Web servers, which consist of
web server software running on a computer, store information (in the form of web pages)
that might be useful to different people. A web browser, which is software installed on an
end user’s computer, provides the means to connect to a web server and display the web
pages stored on the web server.
NOTE Although most people use the term web browser, or simply browser, web brows-
ers are also called web clients, because they obtain a service from a web server.
For this process to work, several specific application layer functions must occur. The user
must somehow identify the server, the specific web page, and the protocol used to get
Chapter 1: Introduction to TCP/IP Transport and Applications 17
the data from the server. The client must find the server’s IP address, based on the server’s
name, typically using DNS. The client must request the web page, which actually consists
of multiple separate files, and the server must send the files to the web browser. Finally, for 1
electronic commerce (e-commerce) applications, the transfer of data, particularly sensitive
financial data, needs to be secure. The following sections address each of these functions.
Uniform Resource Identifiers
For a browser to display a web page, the browser must identify the server that has the web
page, plus other information that identifies the particular web page. Most web servers have
many web pages. For example, if you use a web browser to browse www.cisco.com and you
click around that web page, you’ll see another web page. Click again, and you’ll see another
web page. In each case, the clicking action identifies the server’s IP address as well as the
specific web page, with the details mostly hidden from you. (These clickable items on a web
page, which in turn bring you to another web page, are called links.)
The browser user can identify a web page when you click something on a web page or when
you enter a Uniform Resource Identifier (URI) in the browser’s address area. Both options—
clicking a link and typing a URI—refer to a URI, because when you click a link on a web
page, that link actually refers to a URI.
NOTE Most browsers support some way to view the hidden URI referenced by a link.
In several browsers, hover the mouse pointer over a link, right-click, and select Properties.
The pop-up window should display the URI to which the browser would be directed if you
clicked that link.
In common speech, many people use the terms web address or the similar related terms
Universal Resource Locator (or Uniform Resource Locator [URL]) instead of URI, but URI
is indeed the correct formal term. In fact, URL had been more commonly used than URI for
more than a few years. However, the IETF (the group that defines TCP/IP), along with the
W3C consortium (W3.org, a consortium that develops web standards) has made a concerted
effort to standardize the use of URI as the general term. See RFC 7595 for some commen-
tary to that effect.
From a practical perspective, the URIs used to connect to a web server include three key
components, as noted in Figure 1-11. The figure shows the formal names of the URI fields.
More importantly to this discussion, note that the text before the :// identifies the protocol
used to connect to the server, the text between the // and / identifies the server by name,
and the text after the / identifies the web page.
Formal: URI Scheme Authority Path
http://www.certskills.com/blog
Example: Web Protocol Server’s Name Web Page
Figure 1-11 Structure of a URI Used to Retrieve a Web Page
