Let's start with the basics of networking.

Because networks require all the devices to follow the rules, this part starts with a discussion of networking models, which gives you a big-picture view of the networking rules.

You can think of a networking model as you think of a set of architectural plans for building a house. A lot of different people work on building your house, such as framers, electricians, bricklayers, painters, and so on.

The blueprint helps ensure that all the different pieces of the house work together as a whole.

Similarly, the people who make networking products, and the people who use those products to build their own computer networks, follow a particular networking model.

That networking model defines rules about how each part of the network should work, as well as how the parts should work together, so that the entire network functions correctly.

Transmission Control Protocol/Internet Protocol (TCP/IP). TCP/IP is the most pervasively used networking model in the history of networking.

You can find support for TCP/IP on practically every computer operating system (OS) in existence today, from mobile phones to mainframe computers.

Every network built using Cisco products today supports TCP/IP.

TCP/IP is compared to a second networking model, called the Open Systems Interconnection (OSI) reference model.

Historically, OSI was the first large effort to create a vendor-neutral networking model. Because of that timing, many of the terms used in networking today come from the OSI model.

So, you are new to networking. Like many people, your perspective about networks might be that of a user of the network, as opposed to the network engineer who builds networks.

For some, your view of networking might be based on how you use the Internet, from home, using a high-speed Internet connection like digital subscriber line (DSL) or cable TV, as shown in the diagram below.

The top part of the figure shows a typical high-speed cable Internet user.

The PC connects to a cable modem using an Ethernet cable. The cable modem then connects to a cable TV (CATV) outlet in the wall using a round coaxial cable—the same kind of cable used to connect your TV to the CATV wall outlet.

Because cable Internet services provide service continuously, the user can just sit down at the PC and start sending email, browsing websites, making Internet phone calls, and using other tools and applications.

The lower part of the figure uses two different technologies.

First, the tablet computer uses wireless technology that goes by the name wireless local-area network (wireless LAN), or Wi-Fi, instead of using an Ethernet cable. In this example, the router uses a different technology, DSL, to communicate with the Internet.

Both home-based networks and networks built for use by a company make use of similar networking technologies. The Information Technology (IT) world refers to a network created by one corporation, or enterprise, for the purpose of allowing its employees to communicate, as an enterprise network.

The smaller networks at home, when used for business purposes, often go by the name small office/home office (SOHO) networks.

Users of enterprise networks have some idea about the enterprise network at their company or school. People realize that they use a network for many tasks.

PC users might realize that their PC connects through an Ethernet cable to a matching wall outlet, as shown at the top of diagram below. Those same users might use wireless LANs with their laptop when going to a meeting in the conference room as well. The diagram shows these two end-user perspectives on an enterprise network.

NOTE: In networking diagrams, a cloud represents a part of a network whose details are not important to the purpose of the diagram. In this case, the above diagram ignores the details of how to create an enterprise network.

Some users might not even have a concept of the network at all.

Instead, these users just enjoy the functions of the network—the ability to post messages to social media sites, make phone calls, search for information on the Internet, listen to music, and download countless apps to their phones—without caring about how it works or how their favorite device connects to the network.

In the building business, much work happens before you nail the first boards together. The process starts with some planning, an understanding of how to build a house, and some architectural blueprints of how to build that specific house.

Similarly, the journey toward building any computer network does not begin by installing devices and cables, but instead by looking at the architectural plans for those modern networks: the TCP/IP model.

A networking model, sometimes also called either a networking architecture or networking blueprint, refers to a comprehensive set of documents.

Individually, each document describes one small function required for a network; collectively, these documents define everything that should happen for a computer network to work.

Some documents define a protocol, which is a set of logical rules that devices must follow to communicate.

Other documents define some physical requirements for networking. For example, a document could define the voltage and current levels used on a particular cable when transmitting data.

You can think of a networking model as you think of an architectural blueprint for building a house.

Sure, you can build a house without the blueprint.

However, the blueprint can ensure that the house has the right foundation and structure so that it will not fall down, and it has the correct hidden spaces to accommodate the plumbing, electrical, gas, and so on.

Also, the many different people that build the house using the blueprint—such as framers, electricians, bricklayers, painters, and so on—know that if they follow the blueprint, their part of the work should not cause problems for the other workers.

Similarly, you could build your own network—write your own software, build your own networking cards, and so on—to create a network.

However, it is much easier to simply buy and use products that already conform to some well-known networking model or blueprint.

Because the networking product vendors build their products with some networking model in mind, their products should work well together.

Today, the world of computer networking uses one networking model: TCP/IP.

However, the world has not always been so simple.

Once upon a time, networking protocols didn’t exist, including TCP/IP.

Vendors created the first networking protocols; these protocols supported only that vendor’s computers.

For example, IBM published its Systems Network Architecture (SNA) networking model in 1974.

Other vendors also created their own proprietary networking models.

As a result, if your company bought computers from three vendors, network engineers often had to create three different networks based on the networking models created by each company, and then somehow connect those networks, making the combined networks much more complex.

The left side of the diagram below shows the general idea of what a company’s enterprise network might have looked like back in the 1980s, before TCP/IP became common in enterprise internetworks.

Although vendor-defined proprietary networking models often worked well, having an open, vendor-neutral networking model would aid competition and reduce complexity.

The International Organization for Standardization (ISO) took on the task to create such a model, starting as early as the late 1970s, beginning work on what would become known as the Open Systems Interconnection (OSI) networking model.

ISO had a noble goal for the OSI model: to standardize data networking protocols to allow communication among all computers across the entire planet.

ISO worked toward this ambitious and noble goal, with participants from most of the technologically developed nations on Earth participating in the process.

A second, less-formal effort to create an open, vendor-neutral, public networking model sprouted forth from a U.S. Department of Defense (DoD) contract.

Researchers at various universities volunteered to help further develop the protocols surrounding the original DoD work. These efforts resulted in a competing open networking model called TCP/IP.

During the 1990s, companies began adding OSI, TCP/IP, or both to their enterprise networks. However, by the end of the 1990s, TCP/IP had become the common choice, and OSI fell away.

The center part of diagram above shows the general idea behind enterprise networks in that decade—still with networks built upon multiple networking models but including TCP/IP.

Here in the twenty-first century, TCP/IP dominates.

Proprietary networking models still exist, but they have mostly been discarded in favor of TCP/IP.

The OSI model, whose development suffered in part because of a slower formal standardization process as compared with TCP/IP, never succeeded in the marketplace.

And TCP/IP, the networking model originally created almost entirely by a bunch of volunteers, has become the most prolific network model ever, as shown on the right side of diagram above.

The TCP/IP model both defines and references a large collection of protocols that allow computers to communicate.

To define a protocol, TCP/IP uses documents called Requests For Comments (RFC). (You can find these RFCs using any online search engine.)

The TCP/IP model also avoids repeating work already done by some other standards body or vendor consortium by simply referring to standards or protocols created by those groups.

For example, the Institute of Electrical and Electronic Engineers (IEEE) defines Ethernet LANs; the TCP/IP model does not define Ethernet in RFCs, but refers to IEEE Ethernet as an option.

An easy comparison can be made between telephones and computers that use TCP/IP. You go to the store and buy a phone from one of a dozen different vendors.

When you get home and plug in the phone to the same cable in which your old phone was connected, the new phone works.

The phone vendors know the standards for phones in their country and build their phones to match those standards.

Similarly, when you buy a new computer today, it implements the TCP/IP model to the point that you can usually take the computer out of the box, plug in all the right cables, turn it on, and it connects to the network. You can use a web browser to connect to your favorite website.

How?

Well, the OS on the computer implements parts of the TCP/IP model.

The Ethernet card, or wireless LAN card, built in to the computer implements some LAN standards referenced by the TCP/IP model.

In short, the vendors that created the hardware and software implemented TCP/IP.

To help people understand a networking model, each model breaks the functions into a small number of categories called layers.

Each layer includes protocols and standards that relate to that category of functions. TCP/IP actually has two alternative models, as shown in the diagram below.

The model on the left shows the original TCP/IP model listed in RFC 1122, which breaks TCP/IP into four layers.

The top two layers focus more on the applications that need to send and receive data.

The bottom layer focuses on how to transmit bits over each individual link, with the Internet layer focusing on delivering data over the entire path from the original sending computer to the final destination computer.

The TCP/IP model on the right shows the more common terms and layers used when people talk about TCP/IP today.

It expands the original model’s link layer into two separate layers: data link and physical (similar to the lower two layers of the OSI model). Also, many people commonly use the word “Network” instead of “Internet” for one layer.

NOTE: The original TCP/IP model’s link layer has also been referred to as the network access and network interface layer.

Many of you will have already heard of several TCP/IP protocols, like the examples listed in the table below.

TCP/IP application layer protocols provide services to the application software running on a computer.

The application layer does not define the application itself, but it defines services that applications need.

For example, application protocol HTTP defines how web browsers can pull the contents of a web page from a web server. In short, the application layer provides an interface between software running on a computer and the network itself.

Arguably, the most popular TCP/IP application today is the web browser. Many major software vendors either have already changed or are changing their application software to support access from a web browser.

And thankfully, using a web browser is easy: You start a web browser on your computer and select a website by typing the name of the website, and the web page appears.

HTTP Overview

What really happens to allow that web page to appear on your web browser?

Imagine that Bob opens his browser. His browser has been configured to automatically ask for web server Larry’s default web page, or home page. The general logic looks like the diagram below.

So, what really happened?

Bob’s initial request actually asks Larry to send his home page back to Bob.

Larry’s web server software has been configured to know that the default web page is contained in a file called home.htm.

Bob receives the file from Larry and displays the contents of the file in Bob’s web browser window.

HTTP Protocol Mechanisms

Taking a closer look, this example shows how applications on each endpoint computer—specifically, the web browser application and web server application—use a TCP/IP application layer protocol.

To make the request for a web page and return the contents of the web page, the applications use the Hypertext Transfer Protocol (HTTP).

HTTP did not exist until Tim Berners-Lee created the first web browser and web server in the early 1990s.

Berners-Lee gave HTTP functionality to ask for the contents of web pages, specifically by giving the web browser the ability to request files from the server and giving the server a way to return the content of those files.

The overall logic matches what was shown in above diagram.

Diagram below shows the same idea, but with details specific to HTTP.

NOTE: The full version of most web addresses—also called Uniform Resource Locators (URL) or Universal Resource Identifiers (URI)—begins with the letters http, which means that HTTP is used to transfer the web pages.

To get the web page from Larry, at Step 1, Bob sends a message with an HTTP header.

Generally, protocols use headers as a place to put information used by that protocol. This HTTP header includes the request to “get” a file.

The request typically contains the name of the file (home.htm, in this case), or if no filename is mentioned, the web server assumes that Bob wants the default web page.

Step 2 in the diagram above shows the response from web server Larry. The message begins with an HTTP header, with a return code (200), which means something as simple as “OK” returned in the header.

HTTP also defines other return codes so that the server can tell the browser whether the request worked.

(Here is another example: If you ever looked for a web page that was not found, and then received an HTTP 404 “not found” error, you received an HTTP return code of 404.)

The second message also includes the first part of the requested file.

Step 3 in the diagram shows another message from web server Larry to web browser Bob, but this time without an HTTP header.

HTTP transfers the data by sending multiple messages, each with a part of the file. Rather than wasting space by sending repeated HTTP headers that list the same information, these additional messages simply omit the header.

Although many TCP/IP application layer protocols exist, the TCP/IP transport layer includes a smaller number of protocols.

The two most commonly used transport layer protocols are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).

Transport layer protocols provide services to the application layer protocols that reside one layer higher in the TCP/IP model.

How does a transport layer protocol provide a service to a higher-layer protocol? 

TCP Error Recovery Basics

To appreciate what the transport layer protocols do, you must think about the layer above the transport layer, the application layer.

Why?

Well, each layer provides a service to the layer above it, like the error-recovery service provided to application layer protocols by TCP.

For example, in the previous diagram, Bob and Larry used HTTP to transfer the home page from web server Larry to Bob’s web browser.

But what would have happened if Bob’s HTTP GET request had been lost in transit through the TCP/IP network?

Or, what would have happened if Larry’s response, which included the contents of the home page, had been lost?

Well, as you might expect, in either case, the page would not have shown up in Bob’s browser.

TCP/IP needs a mechanism to guarantee delivery of data across a network. Because many application layer protocols probably want a way to guarantee delivery of data across a network, the creators of TCP included an error-recovery feature.

To recover from errors, TCP uses the concept of acknowledgments.

The diagram below outlines the basic idea behind how TCP notices lost data and asks the sender to try again.

Diagram above shows web server Larry sending a web page to web browser Bob, using three separate messages.

The TCP header shows a sequence number (SEQ) with each message.

In this example, the network has a problem, and the network fails to deliver the TCP message (called a segment) with sequence number 2.

When Bob receives messages with sequence numbers 1 and 3, but does not receive a message with sequence number 2, Bob realizes that message 2 was lost.

That realization by Bob’s TCP logic causes Bob to send a TCP segment back to Larry, asking Larry to send message 2 again.

Same-Layer and Adjacent-Layer Interactions

The example in above diagram also demonstrates a function called adjacent-layer interaction, which refers to the concepts of how adjacent layers in a networking model, on the same computer, work together.

In this example, the higher-layer protocol (HTTP) wants error recovery, and the higher layer uses the next lower-layer protocol (TCP) to perform the service of error recovery; the lower layer provides a service to the layer above it.

The diagram also shows an example of a similar function called same-layer interaction.

When a particular layer on one computer wants to communicate with the same layer on another computer, the two computers use headers to hold the information that they want to communicate.

For example, Larry set the sequence numbers to 1, 2, and 3 so that Bob could notice when some of the data did not arrive.

Larry’s TCP process created that TCP header with the sequence number; Bob’s TCP process received and reacted to the TCP segments.

The table below summarizes the key points about how adjacent layers work together on a single computer and how one layer on one computer works with the same networking layer on another computer.

The application layer includes many protocols. The transport layer includes fewer protocols, most notably, TCP and UDP.

The TCP/IP network layer includes a small number of protocols, but only one major protocol: the Internet Protocol (IP).

In fact, the name TCP/IP is simply the names of the two most common protocols (TCP and IP) separated by a /.

IP provides several features, most importantly, addressing and routing. 

Internet Protocol and the Postal Service

Imagine that you just wrote two letters: one to a friend on the other side of the country and one to a friend on the other side of town.

You addressed the envelopes and put on the stamps, so both are ready to give to the postal service. Is there much difference in how you treat each letter?

Not really.

Typically, you would just put them in the same mailbox and expect the postal service to deliver both letters.

The postal service, however, must think about each letter separately, and then make a decision of where to send each letter so that it is delivered.

For the letter sent across town, the people in the local post office probably just need to put the letter on another truck.

For the letter that needs to go across the country, the postal service sends the letter to another post office, then another, and so on, until the letter gets delivered across the country. At each post office, the postal service must process the letter and choose where to send it next.

To make it all work, the postal service has regular routes for small trucks, large trucks, planes, boats, and so on, to move letters between postal service sites.

The service must be able to receive and forward the letters, and it must make good decisions about where to send each letter next, as shown in the diagram below.

Still thinking about the postal service, consider the difference between the person sending the letter and the work that the postal service does.

The person sending the letters expects that the postal service will deliver the letter most of the time. However, the person sending the letter does not need to know the details of exactly what path the letters take. 

In contrast, the postal service does not create the letter, but it accepts the letter from the customer. Then, the postal service must know the details about addresses and postal codes that group addresses into larger groups, and it must have the ability to deliver the letters.

The TCP/IP application and transport layers act like the person sending letters through the postal service.

 These upper layers work the same way regardless of whether the endpoint host computers are on the same LAN or are separated by the entire Internet.

To send a message, these upper layers ask the layer below them, the network layer, to deliver the message.

The lower layers of the TCP/IP model act more like the postal service to deliver those messages to the correct destinations.

To do so, these lower layers must understand the underlying physical network because they must choose how to best deliver the data from one host to another.

So, what does this all matter to networking?

Well, the network layer of the TCP/IP networking model, primarily defined by the Internet Protocol (IP), works much like the postal service.

IP defines that each host computer should have a different IP address, just as the postal service defines addressing that allows unique addresses for each house, apartment, and business.

Similarly, IP defines the process of routing so that devices called routers can work like the post office, forwarding packets of data so that they are delivered to the correct destinations.

Just as the postal service created the necessary infrastructure to deliver letters—post offices, sorting machines, trucks, planes, and personnel—the network layer defines the details of how a network infrastructure should be created so that the network can deliver data to all computers in the network.

NOTE: TCP/IP defines two versions of IP: IP version 4 (IPv4) and IP version 6 (IPv6). The world still mostly uses IPv4

Internet Protocol Addressing Basics

IP defines addresses for several important reasons.

First, each device that uses TCP/IP—each TCP/IP host—needs a unique address so that it can be identified in the network.

IP also defines how to group addresses together, just like the postal system groups addresses based on postal codes (or ZIP codes).

To understand the basics, examine the diagram below, which shows the familiar web server Larry and web browser Bob; but now, instead of ignoring the network between these two computers, part of the network infrastructure is included.

First, note that the diagram above shows some sample IP addresses. Each IP address has four numbers, separated by periods.

In this case, Larry uses IP address 1.1.1.1, and Bob uses 2.2.2.2. This style of number is called a dotted-decimal notation (DDN).

The diagram also shows three groups of addresses.

In this example, all IP addresses that begin with 1 must be on the upper left, as shown in shorthand in the figure as 1.__.__.__.

All addresses that begin with 2 must be on the right, as shown in shorthand as 2.__.__.__.

Finally, all IP addresses that begin with 3 must be at the bottom of the diagram.

In addition, the diagram introduces icons that represent IP routers.

Routers are networking devices that connect the parts of the TCP/IP network together for the purpose of routing (forwarding) IP packets to the correct destination.

Routers do the equivalent of the work done by each post office site: They receive IP packets on various physical interfaces, make decisions based on the IP address included with the packet, and then physically forward the packet out some other network interface.

IP Routing Basics

The TCP/IP network layer, using the IP protocol, provides a service of forwarding IP packets from one device to another.

Any device with an IP address can connect to the TCP/IP network and send packets. This section shows a basic IP routing example for perspective.

NOTE: The term IP host refers to any device, regardless of size or power, that has an IP address and connects to any TCP/IP network.

The diagram below repeats the familiar case in which web server Larry wants to send part of a web page to Bob, but now with details related to IP.

On the lower left, note that server Larry has the familiar application data, HTTP header, and TCP header ready to send.

In addition, the message now contains an IP header. The IP header includes a source IP address of Larry’s IP address (1.1.1.1) and a destination IP address of Bob’s IP address (2.2.2.2).

Step 1, begins with Larry being ready to send an IP packet.

Larry’s IP process chooses to send the packet to some router—a nearby router on the same LAN—with the expectation that the router will know how to forward the packet.

(This logic is much like you or me sending all our letters by putting them in a nearby mailbox.)

Larry doesn’t need to know anything more about the topology or the other routers.

At Step 2, Router R1 receives the IP packet, and R1’s IP process makes a decision.

R1 looks at the destination address (2.2.2.2), compares that address to its known IP routes, and chooses to forward the packet to Router R2.

This process of forwarding the IP packet is called IP routing (or simply routing).

At Step 3, Router R2 repeats the same kind of logic used by Router R1.

R2’s IP process will compare the packet’s destination IP address (2.2.2.2) to R2’s known IP routes and make a choice to forward the packet to the right, on to Bob.

The TCP/IP model’s original link layer defines the protocols and hardware required to deliver data across some physical network.

The term link refers to the physical connections, or links, between two devices and the protocols used to control those links.

Just like every layer in any networking model, the TCP/IP link layer provides services to the layer above it in the model.

When a host’s or router’s IP process chooses to send an IP packet to another router or host, that host or router then uses link-layer details to send that packet to the next host/router.

Because each layer provides a service to the layer above it, take a moment to think about the IP logic related to above diagram.

In that example, host Larry’s IP logic chooses to send the IP packet to a nearby router (R1), with no mention of the underlying Ethernet.

The Ethernet network, which implements link-layer protocols, must then be used to deliver that packet from host Larry over to router R1.

The diagram below shows four steps of what occurs at the link layer to allow Larry to send the IP packet to R1.

NOTE: Above diagram depicts the Ethernet as a series of lines. Networking diagrams often use this convention when drawing Ethernet LANs, in cases where the actual LAN cabling and LAN devices are not important to some discussion, as is the case here. The LAN would have cables and devices, like LAN switches, which are not shown.

The diagram shows four steps.

The first two occur on Larry, and the last two occur on Router R1, as follows:

• Step 1. Larry encapsulates the IP packet between an Ethernet header and Ethernet trailer, creating an Ethernet frame.
• Step 2. Larry physically transmits the bits of this Ethernet frame, using electricity flowing over the Ethernet cabling.
• Step 3. Router R1 physically receives the electrical signal over a cable, and re-creates the same bits by interpreting the meaning of the electrical signals.
• Step 4. Router R1 de-encapsulates the IP packet from the Ethernet frame by removing and discarding the Ethernet header and trailer.

By the end of this process, the link-layer processes on Larry and R1 have worked together to deliver the packet from Larry to Router R1.

NOTE: Protocols define both headers and trailers for the same general reason, but headers exist at the beginning of the message and trailers exist at the end.

The link layer includes a large number of protocols and standards.

For example, the link layer includes all the variations of Ethernet protocols, along with several other LAN standards that were more popular in decades past.

The link layer includes wide-area network (WAN) standards for different physical media, which differ significantly compared to LAN standards because of the longer distances involved in transmitting the data.

This layer also includes the popular WAN standards that add headers and trailers as shown generally in the diagram—protocols such as the Point-to-Point Protocol (PPP) and Frame Relay. 

In short, the TCP/IP link layer includes two distinct functions:

• functions related to the physical transmission of the data 
• the protocols and rules that control the use of the physical media

The five-layer TCP/IP model simply splits out the link layer into two layers (data link and physical) to match this logic.

Comparing the Original and Modern TCP/IP Models

The original TCP/IP model defined a single layer—the link layer—below the Internet layer.

The functions defined in the original link layer can be broken into two major categories:

• functions related directly to the physical transmission of data
• funstions indirectly related to the physical transmission of data

For example, in the four steps shown in the above diagram, Steps 2 and 3 were specific to sending the data, but Steps 1 and 4—encapsulation and de-encapsulation—were only indirectly related.

Today, most documents use a more modern version of the TCP/IP model, as shown in below. 

Comparing the two, the upper layers are identical, except a name change from Internet to Network.

The lower layers differ in that the single link layer in the original model is split into two layers to match the division of physical transmission details from the other functions. 

Data Encapsulation Terminology

As you can see from the explanations of how HTTP, TCP, IP, and Ethernet do their jobs, each layer adds its own header (and for data-link protocols, also a trailer) to the data supplied by the higher layer.

The term encapsulation refers to the process of putting headers (and sometimes trailers) around some data.

The process by which a TCP/IP host sends data can be viewed as a five-step process.

The first four steps relate to the encapsulation performed by the four TCP/IP layers, and the last step is the actual physical transmission of the data by the host.

In fact, if you use the five-layer TCP/IP model, one step corresponds to the role of each layer.

The steps are summarized in the following list:

• Step 1. Create and encapsulate the application data with any required application layer headers. For example, the HTTP OK message can be returned in an HTTP header, followed by part of the contents of a web page.
• Step 2. Encapsulate the data supplied by the application layer inside a transport layer header. For end-user applications, a TCP or UDP header is typically used.
• Step 3. Encapsulate the data supplied by the transport layer inside a network layer (IP) header. IP defines the IP addresses that uniquely identify each computer.
• Step 4. Encapsulate the data supplied by the network layer inside a data link layer header and trailer. This layer uses both a header and a trailer.
• Step 5. Transmit the bits. The physical layer encodes a signal onto the medium to transmit the frame.

The numbers in the diagram below correspond to the five steps in this list, graphically showing the same concepts. Note that because the application layer often does not need to add a header, the figure does not show a specific application layer header.

Names of TCP/IP Messages

Finally, take particular care to remember the terms segment, packet, and frame and the meaning of each.

Each term refers to the headers (and possibly trailers) defined by a particular layer and the data encapsulated following that header.

Each term, however, refers to a different layer: segment for the transport layer, packet for the network layer, and frame for the link layer.

The diagram below shows each layer along with the associated term.

The letters LH and LT stand for link header and link trailer, respectively, and refer to the data link layer header and trailer.

The diagram also shows the encapsulated data as simply “data.”

When focusing on the work done by a particular layer, the encapsulated data typically is unimportant.

For example, an IP packet can indeed have a TCP header after the IP header, an HTTP header after the TCP header, and data for a web page after the HTTP header.

However, when discussing IP, you probably just care about the IP header, so everything after the IP header is just called data.

So, when drawing IP packets, everything after the IP header is typically shown simply as data.

At one point in the history of the OSI model, many people thought that OSI would win the battle of the networking models discussed earlier.

If that had occurred, instead of running TCP/IP on every computer in the world, those computers would be running with OSI.

However, OSI did not win that battle.

In fact, OSI no longer exists as a networking model that could be used instead of TCP/IP, although some of the original protocols referenced by the OSI model still exist.

So, why OSI? Terminology.

During those years in which many people thought the OSI model would become commonplace in the world of networking (mostly in the late 1980s and early 1990s), many vendors and protocol documents started using terminology from the OSI model.

That terminology remains today.

So, while you will never need to work with a computer that uses OSI, to understand modern networking terminology, you need to understand something about OSI.

The OSI model has many similarities to the TCP/IP model from a basic conceptual perspective. It has (seven) layers, and each layer defines a set of typical networking functions.

As with TCP/IP, the OSI layers each refer to multiple protocols and standards that implement the functions specified by each layer.

In other cases, just as for TCP/IP, the OSI committees did not create new protocols or standards, but instead referenced other protocols that were already defined.

For example, the IEEE defines Ethernet standards, so the OSI committees did not waste time specifying a new type of Ethernet; it simply referred to the IEEE Ethernet standards.

Today, the OSI model can be used as a standard of comparison to other networking models.

Below diagram compares the seven-layer OSI model with both the four-layer and five-layer TCP/IP models.

Even today, networking documents often describe TCP/IP protocols and standards by referencing OSI layers, both by layer number and layer name.

For example, a common description of a LAN switch is “Layer 2 switch,” with “Layer 2” referring to OSI layer 2.

Because OSI did have a well-defined set of functions associated with each of its seven layers, if you know those functions, you can understand what people mean when they refer to a product or function by its OSI layer.

For another example, TCP/IP’s original Internet layer, as implemented mainly by IP, equates most directly to the OSI network layer.

So, most people say that IP is a network layer protocol, or a Layer 3 protocol, using OSI terminology and numbers for the layer.

Of course, if you numbered the TCP/IP model, starting at the bottom, IP would be either Layer 2 or 3, depending on what version of the TCP/IP model you care to use.

However, even though IP is a TCP/IP protocol, everyone uses the OSI model layer names and numbers when describing IP or any other protocol for that matter.

The claim that a particular TCP/IP layer is similar to a particular OSI layer is a general comparison, but not a detailed comparison.

The comparison is a little like comparing a car to a truck: Both can get you from point A to point B, but they have many specific differences, like the truck having a truck bed in which to carry cargo.

Similarly, both the OSI and TCP/IP network layers define logical addressing and routing.

However, the addresses have a different size, and the routing logic even works differently.

So the comparison of OSI layers to other protocol models is a general comparison of major goals, and not a comparison of the specific methods.

Today, because most people happen to be much more familiar with TCP/IP functions than with OSI functions, one of the best ways to learn about the function of different OSI layers is to think about the functions in the TCP/IP model and to correlate those with the OSI model.

For the purposes of learning, you can think of five of the OSI layers as doing the same kinds of things as the matching five layers in the TCP/IP model.

For example, the application layer of each model defines protocols to be used directly by the applications, and the physical layer of each defines the electro-mechanical details of communicating over physical connections.

Table below briefly describes each OSI layer.

While the table below lists a sampling of the devices and protocols and their comparable OSI layers.

Note that many network devices must actually understand the protocols at multiple OSI layers, so the layer listed in the table actually refers to the highest layer that the device normally thinks about when performing its core work.

For example, routers need to think about Layer 3 concepts, but they must also support features at both Layers 1 and 2.

Besides remembering the basics of the features of each OSI layer, and some protocol and device example at each layer, you should also memorize the names of the layers.

You can simply memorize them, but some people like to use a mnemonic phrase to make memorization easier.

In the following phrases, the first letter of each word is the same as the first letter of an OSI layer name, in the order specified in parentheses:

• All People Seem To Need Data Processing (Layers 7 to 1)
• Please Do Not Take Sausage Pizzas Away (Layers 1 to 7)

While networking models use layers to help humans categorize and understand the many functions in a network, networking models use layers for many reasons.

For example, consider another postal service analogy.

A person writing a letter does not have to think about how the postal service will deliver a letter across the country.

The postal worker in the middle of the country does not have to worry about the contents of the letter.

Likewise, networking models that divide functions into different layers enable one software package or hardware device to implement functions from one layer, and assume that other software/hardware will perform the functions defined by the other layers.

The following list summarizes the benefits of layered protocol specifications:

• Less complex: Compared to not using a layered model, network models break the concepts into smaller parts.
• Standard interfaces: The standard interface definitions between each layer allow multiple vendors to create products that fill a particular role, with all the benefits of open competition.
• Easier to learn: Humans can more easily discuss and learn about the many details of a protocol specification.
• Easier to develop: Reduced complexity allows easier program changes and faster product development.
• Multivendor interoperability: Creating products to meet the same networking standards means that computers and networking gear from multiple vendors can work in the same network.
• Modular engineering: One vendor can write software that implements higher layers—for example, a web browser—and another vendor can write software that implements the lower layers—for example, Microsoft’s built-in TCP/IP software in its operating systems.

Like TCP/IP, each OSI layer asks for services from the next lower layer.

To provide the services, each layer makes use of a header and possibly a trailer. The lower layer encapsulates the higher layer’s data behind a header.

OSI uses a more generic term to refer to messages, rather than frame, packet, and segment. OSI uses the term protocol data unit (PDU).

A PDU represents the bits that include the headers and trailers for that layer, as well as the encapsulated data.

For example, an IP packet using OSI terminology, is a PDU, more specifically a Layer 3 PDU (abbreviated L3PDU) because IP is a Layer 3 protocol.

OSI simply refers to the Layer x PDU (LxPDU), with x referring to the number of the layer being discussed, as shown in the diagram below.

The OSI transport layer (Layer 4) defines several functions, the most important of which are error recovery and flow control.

Likewise, the TCP/IP transport layer protocols also implement these same types of features.

Note that both the OSI model and the TCP/IP model call this layer the transport layer.

But as usual, when referring to the TCP/IP model, the layer name and number are based on OSI, so any TCP/IP transport layer protocols are considered Layer 4 protocols.

The key difference between TCP and UDP is that TCP provides a wide variety of services to applications, whereas UDP does not.

For example, routers discard packets for many reasons, including bit errors, congestion, and instances in which no correct routes are known.

As you have learned already, most data-link protocols notice errors (a process called error detection) but then discard frames that have errors.

TCP provides retransmission (error recovery) and helps to avoid congestion (flow control), whereas UDP does not.

As a result, many application protocols choose to use TCP.

However, do not let UDP’s lack of services make you think that UDP is worse than TCP.

By providing fewer services, UDP needs fewer bytes in its header compared to TCP, resulting in fewer bytes of overhead in the network. UDP software does not slow down data transfer in cases where TCP can purposefully slow down. 

Also, some applications, notably today Voice over IP (VoIP) and video over IP, do not need error recovery, so they use UDP.

So, UDP also has an important place in TCP/IP networks today.

Table below lists the main features supported by TCP/UDP. Note that only the first item listed in the table is supported by UDP, whereas all items in the table are supported by TCP.

Each TCP/IP application typically chooses to use either TCP or UDP based on the application’s requirements.

For example, TCP provides error recovery, but to do so, it consumes more bandwidth and uses more processing cycles. 

UDP does not perform error recovery, but it takes less bandwidth and uses fewer processing cycles.

Regardless of which of these two TCP/IP transport layer protocols the application chooses to use, you should understand the basics of how each of these transport layer protocols works.

TCP, as defined in Request For Comments (RFC) 793, accomplishes the functions listed in table above through mechanisms at the endpoint computers.

TCP relies on IP for end-to-end delivery of the data, including routing issues. In other words, TCP performs only part of the functions necessary to deliver the data between applications.

Also, the role that it plays is directed toward providing services for the applications that sit at the endpoint computers.

Regardless of whether two computers are on the same Ethernet, or are separated by the entire Internet, TCP performs its functions the same way.

The diagram below shows the fields in the TCP header.

The message created by TCP that begins with the TCP header, followed by any application data, is called a TCP segment. Alternatively, the more generic term Layer 4 PDU, or L4PDU, can also be used.

Multiplexing Using TCP Port Numbers

TCP and UDP both use a concept called multiplexing. ​

Multiplexing by TCP and UDP involves the process of how a computer thinks when receiving data.

The computer might be running many applications, such as a web browser, an email package, or an Internet VoIP application (for example, Skype).

TCP and UDP multiplexing tells the receiving computer to which application to give the received data.

Some examples will help make the need for multiplexing obvious. The sample network consists of two PCs, labeled Hannah and Jessie. Hannah uses an application that she wrote to send advertisements that appear on Jessie’s screen.

The application sends a new ad to Jessie every 10 seconds. Hannah uses a second application, a wire-transfer application, to send Jessie some money.

Finally, Hannah uses a web browser to access the web server that runs on Jessie’s PC.

The ad application and wire-transfer application are imaginary, just for this example.

The web application works just like it would in real life.

The diagram shows the sample network, with Jessie running three applications:

• A UDP-based advertisement application
• A TCP-based wire-transfer application
• A TCP web server application

Jessie needs to know which application to give the data to, but all three packets are from the same Ethernet and IP address.

You might think that Jessie could look at whether the packet contains a UDP or TCP header, but as you see in the figure, two applications (wire transfer and web) are using TCP.

TCP and UDP solve this problem by using a port number field in the TCP or UDP header, respectively.

Each of Hannah’s TCP and UDP segments uses a different destination port number so that Jessie knows which application to give the data to.

The diagram below shows an example.

Multiplexing relies on a concept called a socket. A socket consists of three things:

• An IP address
• A transport protocol
• A port number

So, for a web server application on Jessie, the socket would be (10.1.1.2, TCP, port 80) because, by default, web servers use the well-known port 80.

When Hannah’s web browser connects to the web server, Hannah uses a socket as well—possibly one like this: (10.1.1.1, TCP, 1030).

Why 1030?

Well, Hannah just needs a port number that is unique on Hannah, so Hannah sees that port 1030 is available and uses it.

In fact, hosts typically allocate dynamic port numbers starting at 1024 because the ports below 1024 are reserved for well-known applications.

In diagram above, Hannah and Jessie use three applications at the same time—hence, three socket connections are open.

Because a socket on a single computer should be unique, a connection between two sockets should identify a unique connection between two computers.

This uniqueness means that you can use multiple applications at the same time, talking to applications running on the same or different computers.

Multiplexing, based on sockets, ensures that the data is delivered to the correct applications.

The diagram below shows the three socket connections between Hannah and Jessie.

Port numbers are a vital part of the socket concept. Well-known port numbers are used by servers; other port numbers are used by clients.

Applications that provide a service, such as FTP, Telnet, and web servers, open a socket using a well-known port and listen for connection requests.

Because these connection requests from clients are required to include both the source and destination port numbers, the port numbers used by the servers must be well-known.

Therefore, each service uses a specific well-known port number.

The well-known ports are listed at www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt.

On client machines, where the requests originate, any locally unused port number can be allocated.

The result is that each client on the same host uses a different port number, but a server uses the same port number for all connections.

For example, 100 web browsers on the same host computer could each connect to a web server, but the web server with 100 clients connected to it would have only one socket and, therefore, only one port number (port 80, in this case).

The server can tell which packets are sent from which of the 100 clients by looking at the source port of received TCP segments.

The server can send data to the correct web client (browser) by sending data to that same port number listed as a destination port.

The combination of source and destination sockets allows all participating hosts to distinguish between the data’s source and destination.

Although the example explains the concept using 100 TCP connections, the same port-numbering concept applies to UDP sessions in the same way.

Popular TCP/IP Applications

Some of the applications that can be used to help manage and control a network are:

• The World Wide Web (WWW) application exists through web browsers accessing the content available on web servers. Although it is often thought of as an end-user application, you can actually use WWW to manage a router or switch. You enable a web server function in the router or switch and use a browser to access the router or switch.
• The Domain Name System (DNS) allows users to use names to refer to computers, with DNS being used to find the corresponding IP addresses. DNS also uses a client/server model, with DNS servers being controlled by networking personnel and DNS client functions being part of most any device that uses TCP/IP today. The client simply asks the DNS server to supply the IP address that corresponds to a given name.
• Simple Network Management Protocol (SNMP) is an application layer protocol used specifically for network device management.
  • For example, Cisco supplies a large variety of network management products, many of them in the Cisco Prime network management software product family.
  • They can be used to query, compile, store, and display information about a network’s operation. To query the network devices, Cisco Prime software mainly uses SNMP protocols.
• Traditionally, to move files to and from a router or switch, Cisco used Trivial File Transfer Protocol (TFTP). TFTP defines a protocol for basic file transfer—hence the word trivial. Alternatively, routers and switches can use File Transfer Protocol (FTP), which is a much more functional protocol, to transfer files.
  • Both work well for moving files into and out of Cisco devices.
  • FTP allows many more features, making it a good choice for the general end-user population.
  • TFTP client and server applications are very simple, making them good tools as embedded parts of networking devices.

Some of these applications use TCP, and some use UDP.

For example, Simple Mail Transfer Protocol (SMTP) and Post Office Protocol version 3 (POP3), both used for transferring mail, require guaranteed delivery, so they use TCP.

Regardless of which transport layer protocol is used, applications use a well-known port number so that clients know which port to attempt to connect to.

The table below lists several popular applications and their well-known port numbers.

Connection Establishment and Termination

TCP connection establishment occurs before any of the other TCP features can begin their work.

Connection establishment refers to the process of initializing Sequence and Acknowledgment fields and agreeing on the port numbers used.

Diagram below shows an example of connection establishment flow.

This three-way connection establishment flow (also called a three-way handshake) must complete before data transfer can begin.

The connection exists between the two sockets, although the TCP header has no single socket field.

Of the three parts of a socket, the IP addresses are implied based on the source and destination IP addresses in the IP header.

TCP is implied because a TCP header is in use, as specified by the protocol field value in the IP header.

Therefore, the only parts of the socket that need to be encoded in the TCP header are the port numbers.

TCP signals connection establishment using 2 bits inside the flag fields of the TCP header.

Called the SYN and ACK flags, these bits have a particularly interesting meaning.

SYN means “synchronize the sequence numbers,” which is one necessary component in initialization for TCP.

Diagram below shows TCP connection termination.

This four-way termination sequence is straightforward and uses an additional flag, called the FIN bit. (FIN is short for “finished,” as you might guess.)

One interesting note: Before the device on the right sends the third TCP segment in the sequence, it notifies the application that the connection is coming down.

It then waits on an acknowledgment from the application before sending the third segment in the figure.

Just in case the application takes some time to reply, the PC on the right sends the second flow in the figure, acknowledging that the other PC wants to take down the connection. Otherwise, the PC on the left might resend the first segment repeatedly.

TCP establishes and terminates connections between the endpoints, whereas UDP does not.

Many protocols operate under these same concepts, so the terms connection-oriented and connectionless are used to refer to the general idea of each. More formally, these terms can be defined as follows:

• Connection-oriented protocol: A protocol that requires an exchange of messages before data transfer begins, or that has a required pre-established correlation between two endpoints.
• Connectionless protocol: A protocol that does not require an exchange of messages and that does not require a pre-established correlation between two endpoints.

Error Recovery and Reliability

TCP provides for reliable data transfer, which is also called reliability or error recovery.

To accomplish reliability, TCP numbers data bytes using the Sequence and Acknowledgment fields in the TCP header.

TCP achieves reliability in both directions, using the Sequence Number field of one direction combined with the Acknowledgment field in the opposite direction.

Diagram below shows an example of how the TCP sequence and acknowledgment fields allow the PC to send 3000 bytes of data to the server, with the server acknowledging receipt of the data.

The TCP segments in the figure occur in order, from top to bottom.

For simplicity’s sake, all messages happen to have 1000 bytes of data in the data portion of the TCP segment.

The first Sequence number is a nice round number (1000), again for simplicity’s sake.

The top of the figure shows three segments, with each sequence number being 1000 more than the previous, identifying the first of the 1000 bytes in the message. (That is, in this example, the first segment holds bytes 1000–1999; the second holds bytes 2000–2999; and the third holds bytes 3000–3999.)

The fourth TCP segment in the figure—the only one flowing back from the server to the web browser—acknowledges the receipt of all three segments.

How?

The acknowledgment value of 4000 means “I received all data with sequence numbers up through one less than 4000, so I am ready to receive your byte 4000 next.”

(Note that this convention of acknowledging by listing the next expected byte, rather than the number of the last byte received, is called forward acknowledgment.)

This first example does not recover from any errors, however; it simply shows the basics of how the sending host uses the sequence number field to identify the data, with the receiving host using forward acknowledgments to acknowledge the data.

The more interesting discussion revolves around how to use these same tools to do error recovery.

TCP uses the sequence and acknowledgment fields so that the receiving host can notice lost data, ask the sending host to resend, and then acknowledge that the re-sent data arrived.
Many variations exist for how TCP does error recovery.

Below diagram shows just one such example, with similar details compared to the previous diagram. The web browser again sends three TCP segments, again 1000 bytes each, again with easy-to-remember sequence numbers. However, in this example, the second TCP segment fails to cross the network.

The figure points out three sets of ideas behind how the two hosts think.

First, on the right, the server realizes that it did not receive all the data. The two received TCP segments contain bytes numbered 1000–1999 and 3000–3999.

Clearly, the server did not receive the bytes numbered in between. The server then decides to acknowledge all the data up to the lost data—that is, to send back a segment with the acknowledgment field equal to 2000.

The receipt of an acknowledgment that does not acknowledge all the data sent so far tells the sending host to resend the data.

The PC on the left may wait a few moments to make sure no other acknowledgments arrive (using a timer called the retransmission timer), but will soon decide that the server means “I really do need 2000 next—resend it.” The PC on the left does so, as shown in the fifth of the six TCP segments in the diagram.

Finally, note that the server can acknowledge not only the re-sent data, but any earlier data that had been received correctly.

In this case, the server received the re-sent second TCP segment (the data with sequence numbers 2000–2999), but the server had already received the third TCP segment (the data numbered 3000–3999).

The server’s next acknowledgment field acknowledges the data in both those segments, with an acknowledgment field of 4000.

Flow Control Using Windowing

TCP implements flow control by using a window concept that is applied to the amount of 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 window—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 diagram below, uses the same basic rules as the examples in the previous few diagrams. In this case, none of the TCP segments have errors, and the discussion begins one TCP segment earlier than in the previous two figures.

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 realizes 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 window is exhausted, a new window begins, and the sender continues sending data until the 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.

UDP provides a service for applications to exchange messages.

Unlike TCP, UDP is connectionless 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 example, the Network File System (NFS), a remote file system application, performs recovery with application layer code, so UDP features are acceptable to NFS.

Diagram below 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. UDP needs a shorter header than TCP simply because UDP has less work to do.

The whole goal of building an enterprise network, or connecting a small home or office network to the Internet, is to use applications such as web browsing, text messaging, email, file downloads, voice, and video.

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 browsers 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 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 electronic commerce (e-commerce) applications, the transfer of data, particularly sensitive financial data, needs to be secure.

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.

In common speech, many people use the terms web address or the similar related term Universal 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 commentary to that effect.

From a practical perspective, the URIs used to connect to a web server include three key components, as noted in the diagram below. The diagram 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.

In this case, the protocol is Hypertext Transfer Protocol (HTTP), the hostname is www.certskills.com, and the name of the web page is blog.

A host can use DNS to discover the IP address that corresponds to a particular hostname.

URIs typically list the name of the server—a name that can be used to dynamically learn the IP address used by that same server.

The web browser cannot send an IP packet to a destination name, but it can send a packet to a destination IP address.

So, before the browser can send a packet to the web server, the browser typically needs to resolve the name inside the URI to that name’s corresponding IP address.

To pull together several concepts, the diagram below shows the DNS process as initiated by a web browser, as well as some other related information.

From a basic perspective, the user enters the URI (in this case, http://www.cisco.com/go/learningnetwork), resolves the www.cisco.com name into the correct IP address, and starts sending packets to the web server.

The steps shown in the figure are as follows:

1. The user enters the URI, http://www.cisco.com/go/learningnetwork, into the browser’s address area.
2. The client sends a DNS request to the DNS server. Typically, the client learns the DNS server’s IP address through DHCP. Note that the DNS request uses a UDP header, with a destination port of the DNS well-known port of 53.
3. The DNS server sends a reply, listing IP address 198.133.219.25 as www.cisco.com’s IP address. Note also that the reply shows a destination IP address of 64.100.1.1, the client’s IP address. It also shows a UDP header, with source port 53; the source port is 53 because the data is sourced, or sent by, the DNS server.
4. The client begins the process of establishing a new TCP connection to the web server. Note that the destination IP address is the just-learned IP address of the web server. The packet includes a TCP header, because HTTP uses TCP. Also note that the destination TCP port is 80, the well-known port for HTTP. Finally, the SYN bit is shown, as a reminder that the TCP connection establishment process begins with a TCP segment with the SYN bit turned on (binary 1).

At this point in the process, the web browser is almost finished setting up a TCP connection to the web server. 

After a web client (browser) has created a TCP connection to a web server, the client can begin requesting the web page from the server.

Most often, the protocol used to transfer the web page is HTTP.

The HTTP application layer protocol, defined in RFC 7230, defines how files can be transferred between two computers.

HTTP was specifically created for the purpose of transferring files between web servers and web clients.

HTTP defines several commands and responses, with the most frequently used being the HTTP GET request.

To get a file from a web server, the client sends an HTTP GET request to the server, listing the filename.

If the server decides to send the file, the server sends an HTTP GET response, with a return code of 200 (meaning OK), along with the file’s contents.

NOTE: Many return codes exist for HTTP requests. For example, when the server does not have the requested file, it issues a return code of 404, which means “file not found.” Most web browsers do not show the specific numeric HTTP return codes, instead displaying a response such as “page not found” in reaction to receiving a return code of 404.

Web pages typically consist of multiple files, called objects.

Most web pages contain text as well as several graphical images, animated advertisements, and possibly voice or video.

Each of these components is stored as a different object (file) on the web server. To get them all, the web browser gets the first file.

This file can (and typically does) include references to other URIs, so the browser then also requests the other objects.

The diagram below shows the general idea, with the browser getting the first file and then two others.

In this case, after the web browser gets the first file—the one called “/go/ccna” in the URI—the browser reads and interprets that file.

Besides containing parts of the web page, the file refers to two other files, so the browser issues two additional HTTP get requests.

Note that, even though it isn’t shown in the figure, all these commands flow over one (or possibly more) TCP connection between the client and the server.

This means that TCP would provide error recovery, ensuring that the data was delivered.

The concept revolves around the process by which a host, when receiving any message over any network, can decide which of its many application programs should process the received data.

As an example, consider host A shown on the left side of diagram below. The host happens to have three different web browser windows open, each using a unique TCP port.

Host A also has an email client and a chat window open, both of which use TCP.

Both the email and chat applications use a unique TCP port number on host A as well (1027 and 1028) as shown in the diagram.

Transport layer protocols use the destination port number field in the TCP or UDP header to identify the receiving application.

For instance, if the destination TCP port value in below figure is 1024, host A will know that the data is meant for the first of the three web browser windows.

Before a receiving host can even examine the TCP or UDP header, and find the destination port field, it must first process the outer headers in the message.

If the incoming message is an Ethernet frame, that encapsulates an IPv4 packet, the headers look like the details in the above diagram.

The receiving host needs to look at multiple fields, one per header, to identify the next header or field in the received message.

For instance, host A uses an Ethernet NIC to connect to the network, so the received message is an Ethernet frame.

The Ethernet Type field identifies the type of header that follows the Ethernet header—in this case, with a value of hex 0800, an IPv4 header.

The IPv4 header has a similar field called the IP Protocol field. The IPv4 Protocol field has a standard list of values that identify the next header, with decimal 6 used for TCP and decimal 17 used for UDP.

In this case, the value of 6 identifies the TCP header that follows the IPv4 header. Once the receiving host realizes a TCP header exists, it can process the destination port field to determine which local application process should receive the data.