We network to get work done. Okay, sometimes that “work” involves a mad gaming session in which I lay some smack down on my editors, but you know what I mean. Thus far in the book, everything you’ve read about networking involves connecting computers together. This chapter moves further up the OSI seven-layer model and the TCP/IP model to look at applications such as Web browsers, e-mail messaging, and more.

To understand the applications that use TCP/IP networks, a tech needs to know the structures below those applications. Have you ever opened multiple Web pages on a single computer? Have you ever run multiple Internet apps, such as a Web browser, an e-mail client, and a remote connectivity app, all at the same time? Clearly, a lot of data is moving back and forth between your computer and many other computers. With packets coming in from two, three, or more computers, there has to be a mechanism or process that knows where to send and receive that data.

In this chapter, you’ll discover the process used by TCP/IP networks to ensure the right data gets to the right applications on your computer. This process uses very important Transport and Network layer protocols—TCP, UDP, and ICMP—and port numbering. When used together, TCP and UDP along with port numbers enable you to get work done on a network.

Historical/Conceptual

Transport Layer and Network Layer Protocols

I hate to tell you this, but you’ve been lied to. Not by me. Even though I’ve gone along with this Big Lie, I need to tell you the truth.

There is no such thing as TCP/IP. TCP over IP is really many other things, such as HTTP, DHCP, POP, and about 500 more terms over TCP, plus UDP and ICMP over IP. Given that this overly complex but much more correct term is too hard to use, the people who invented this network protocol stack decided to call it TCP/IP, even though that term is way too simplistic to cover all the functionality involved. A common way to refer all the aspects and protocols that make up TCP/IP is to call it the TCP/IP suite.

NOTE  There is a strong movement toward using the term Internet Protocol instead of the term TCP/IP. This movement has not yet reached the CompTIA Network+ certification.

This chapter explores many of the protocols used in TCP/IP networks and shows how they help make applications work. This section looks at the big three—TCP, UDP, and ICMP, plus IGMP for fun. (Subsequent sections of this chapter explore many more TCP/IP protocols.) Let’s start the process with an analogy, by considering how human beings communicate. You’ll see some very interesting commonalities between computers and people.

How People Communicate

Imagine you walk into a school cafeteria to get some lunch. You first walk up to the guy making custom deli sandwiches (this is a great cafeteria!) and say, “Hello!” He says, “How may I help you?” You say, “I’d like a sandwich please.” He says, “What kind of sandwich would you like?” and you order your sandwich. After you get your sandwich you say, “Thanks!” and he says, “You’re welcome.” What a nice guy! In the networking world, we would call this a connection-oriented communication. Both you and the lunch guy first acknowledge each other. You then conduct your communication; finally, you close the communication.

While you’re in line, you see your friend Janet sitting at your usual table. The line is moving fast so you yell out, “Janet, save me a seat!” before you rush along in the line. In this case, you’re not waiting for her to answer; you just yell to her and hope she hears you. We call this a connectionless communication. There is no acknowledgment or any closing.

In networking, any single communication between a computer and another computer is called a session. When you open a Web page, you make a session. When you call your buddy (using the Internet, not the cellular networks), you create a session. All sessions must begin and eventually end.

Test Specific

TCP

The Transmission Control Protocol (TCP) enables connection-oriented communication in networks that use the TCP/IP protocol suite. TCP is by far the most common type of session on a typical TCP/IP network. Figure 8-1 shows two computers. One computer (Server) runs a Web server and the other (Client) runs a Web browser. When you enter a computer’s address in the browser running on Client, it sends a single SYN (synchronize) segment to the Web server. If Server gets that segment, it returns a single SYN, ACK (synchronize, acknowledge) segment. Client then sends Server a single ACK (acknowledge) segment and immediately requests that Server begin sending the Web page. This process is called the TCP three-way handshake.

Figure 8-1 A connectionoriented session starting

Once Server finishes sending the Web page, it sends a FIN (final) segment. Client responds with an ACK segment and then sends its own FIN segment. The server then responds with an ACK; now both parties consider the session closed (Figure 8-2).

Figure 8-2 A connection-oriented session ending

Most TCP/IP applications use TCP because connection-oriented sessions are designed to check for errors. If a receiving computer detects a missing segment, it just asks for a repeat as needed.

UDP

User Datagram Protocol (UDP) runs a distant second place to TCP in terms of the number of applications that use it, but that doesn’t mean UDP is not important. UDP is perfect for the types of sessions that don’t require the overhead of all that connection-oriented stuff.

NOTE  Domain Name System (DNS) protocol traffic uses UDP. That’s the protocol that enables (among other things) people to use names rather than IP addresses to access resources on TCP/IP networks like the Internet. DNS is so important that most of Chapter 9, “Network Naming,” is devoted to how it works and what network techs need to know to support it.

DHCP

Dynamic Host Configuration Protocol (DHCP) uses UDP and provides a good example of connectionless communication. DHCP can’t assume another computer is ready on either side of the session, so each step of a DHCP session just sends the information for that step without any confirmation (Figure 8-3). Sending a connectionless packet also makes sense because the client won’t have an IP address to begin the three-way handshake. Plus, if the server doesn’t respond, the client can simply ask again.

Figure 8-3 DHCP steps

As you learned in Chapter 6, “TCP/IP Basics,” DHCP uses two port numbers. DHCP clients use port 67 for sending data to and receiving data from the DHCP server, and DHCP servers use port 68 for sending and receiving data to and from DHCP clients.

NTP/SNTP

Two popular applications that use UDP are Network Time Protocol (NTP) and his lightweight little brother, Simple Network Time Protocol (SNTP). These protocols synchronize the clocks of devices on a network. Computers need to use the same time so things like Kerberos authentication work properly. If a device requires NTP/SNTP, you will be able to enter the IP address for an NTP/SNTP server. NTP/SNTP uses port 123.

TFTP

You might also be tempted to think that UDP wouldn’t work for any situation in which a critical data transfer takes place—untrue! Trivial File Transfer Protocol (TFTP) enables you to transfer files from one machine to another. TFTP, using UDP, doesn’t have any data protection, so you would never use TFTP between computers across the Internet. The typical scenario for using TFTP is moving files between computers on the same LAN, where the chances of losing packets is very small. TFTP uses port 69.

EXAM TIP  Expect to get a question that compares connection-oriented vs. connectionless communication in general, or the protocols commonly used in each.

ICMP

While TCP and UDP differ dramatically—the former connection-oriented and the latter connectionless—both manage and modify packets in the classic sense with a destination IP address, source IP address, destination port numbers, and source port numbers. A single session might be one packet or a series of packets.

On the other hand, sometimes applications are so simple that they’re always connectionless and never need more than a single packet. The Internet Control Message Protocol (ICMP) works at Layer 3 to deliver connectionless packets. ICMP handles mundane issues such as host unreachable messages.

Ping is one place where you’ll see ICMP in action. Ping is an ICMP application that works by sending a single ICMP packet called an echo request to an IP address you specify. All computers running TCP/IP (assuming no firewall is involved) respond to echo requests with an echo reply, as shown in Figure 8-4.

Figure 8-4 Ping in action

NOTE  A firewall is a device or software that filters all the packets between two computers (or groups of computers) and acts like a club bouncer deciding who gets in and who gets blocked. Firewalls are vital for securing modern networks and will be discussed in Chapter 11, “Advanced Network Devices.”

Ping provides a couple of responses that indicate problems locating the remote computer. If your computer has no route to the address listed, ping will display destination host unreachable. You might get the same message from a router upstream if that router can’t go forward. If you ping a device and no echo reply comes back before the default time, ping will respond with request timed out. (The default time varies by platform, but within a few seconds.) This can be caused by a slow network, excess traffic, a downed router, and more. Ping responses could be disabled on the target computer.

EXAM TIP  CompTIA has used the term unreachable default gateway as an ICMP-related issue. If you ping the default gateway and get a destination host unreachable response, you could infer that the default gateway is unreachable.

Many years ago, ping had a bug that allowed malicious users to send malformed ping packets to a destination. This ping of death would cause the recipient computer to crash. Ping was long ago fixed and you’ll only hear this term from ancient techs—and perhaps see it on the CompTIA Network+ exam.

IGMP

Do you remember the idea of IP multicast addresses, described in Chapter 6? The challenge to multicasting is determining who wants to receive the multicast and who does not. The Internet Group Management Protocol (IGMP) enables routers to communicate with hosts to determine a “group” membership. As you might remember from Chapter 6, multicast is in the Class D range (224.0.0.0–239.255.255.255). Multicast addresses only use a subset of the Class D range. Multicast also doesn’t assign IP addresses to individual hosts in the same manner as you’ve seen thus far. Instead, a particular multicast (called an IGMP group) is assigned to an address in the Class D range, and those who wish to receive this multicast must tell their upstream router or switch (which must be configured to handle multicasts) that they wish to receive it. To do so, they join the IGMP group (Figure 8-5).

Figure 8-5 IGMP in action

The Power of Port Numbers

If you want to understand the power of TCP/IP, you have to get seriously into port numbers. If you want to pass the CompTIA Network+ exam, you need to know how TCP/IP uses port numbers and you have to memorize a substantial number of common port numbers. As you saw in the previous chapter, port numbers make NAT work. As you progress through this book, you’ll see a number of places where knowledge of port numbers is critical to protect your network, make routers work better, and address a zillion other issues. There is no such thing as a network administrator who isn’t deeply into the magic of port numbers and who cannot manipulate them for his or her network’s needs.

EXAM TIP  TCP/IP port numbers between 0 and 1023 are the well-known port numbers. You’ll find them at every party.

Let’s review and expand on what you learned about port numbers in Chapters 1 and 7. Thus far, you know that every TCP/IP application requires a server and a client. Clearly defined port numbers exist for every popular or well-known TCP/IP application. A port number is a 16-bit value between 0 and 65535. Web servers, for example, use port number 80. Port numbers from 0 to 1023 are called well-known port numbers and are reserved for specific TCP/IP applications.

When a Web client (let’s say your computer running Firefox) sends an HTTP ACK to a Web server to request the Web page, your computer’s IP packet looks like Figure 8-6.

Figure 8-6 HTTP ACK packet

As you can see, the destination port number is 80. The computer running the Web server reads the destination port number, telling it to send the incoming segment to the Web server program (Figure 8-7).

Figure 8-7 Dealing with the incoming packet

The Web client’s source port number is generated pseudo-randomly by the Web client computer. This value has varied by operating system over the decades, but generally falling within the values 1024–5000 (the port numbers classically assigned as ephemeral port numbers) and 49152–65535 (the dynamic port numbers or private port numbers).

In the early days of the Internet, only ports 1024–5000 were used, but modern computers can use up all of those. More port numbers were added later.

The Internet Assigned Numbers Authority (IANA) today recommends using only ports 49152–65535 as ephemeral port numbers. That’s what current versions of Windows use as well. Let’s redraw Figure 8-6 to show the more complete packet (Figure 8-8).

Figure 8-8 A more complete IP packet

When the serving system responds to the Web client, it uses the ephemeral port number as the destination port to get the information back to the Web client running on the client computer (Figure 8-9).

Figure 8-9 Returning the packet

Registered Ports

The port numbers from 1024 to 49151 are called registered ports. Less-common TCP/IP applications can register their ports with the IANA. Unlike well-known ports, anyone can use these port numbers for their servers or for ephemeral numbers on clients. Most operating systems steer away (or are in the process of steering away) from using these port numbers for ephemeral ports, opting instead for the dynamic/private port numbers. Here’s the full list of ports:

Each computer on each side of a session must keep track of the status of the communication. In TCP/IP, the session information (a combination of the IP address and port number) stored in RAM is called a socket or endpoint. When discussing the data each computer stores about the connection between two computers’ TCP/IP applications, the term to use is socket pairs or endpoints. A session or connection refers to the connection in general, rather than anything specific to TCP/IP. Many people still use the term session, however. Here’s a summary of the terms used:

•  Terms for the session information (IP address and port number) stored on a single computer— socket or endpoint

•  Terms for the connection data stored on two computers about the same connection— socket pairs or endpoints

•  Terms for the whole interconnection— connection or session

As two computers begin to communicate, they store the information about the session—the endpoints—so they know where to send and receive data. At any given point in time, your computer probably has a large number of communications going on. If you want to know who your computer is communicating with, you need to see this list of endpoints. As you’ll recall from Chapter 7, “Routing,” Windows, Linux, and macOS come with netstat, the universal “show me the endpoint” utility. Netstat works at the command line, so open one up and type netstat –n to see something like this:

When you run netstat –n on a typical computer, you’ll see many more than just two connections! The preceding example is simplified for purposes of discussing the details. It shows two connections: My computer’s IP address is 192.168.4.27. The top connection is an open Web page (port 80) to a server at http://216.40.231.195. The second connection is an open Windows Network browser (port 445) to my file server (192.168.4.8). Looking on my Windows Desktop, you would certainly see at least these two windows open (Figure 8-10).

Figure 8-10 Two open windows

NOTE  Even though almost all operating systems use netstat, there are subtle differences in options and output among the different versions.

Don’t think that a single open application always means a single connection. The following example shows what netstat –n looks like when I open the well-known www.microsoft.com Web site (I removed lines unrelated to the Web browser’s connections to www.microsoft.com):

A single simple Web page needs only a single connection, but this Web page is very complex. Different elements in the Web page, such as advertisements, each have their own connection.

EXAM TIP  Netstat enables you to see active TCP/IP connections at a glance.

Netstat is a powerful tool, and you will see it used throughout this book. The CompTIA Network+ exam also tests your netstat skills. On the other hand, connections come and go constantly on your computer, and netstat, being a command-line utility, can’t update to reflect changes automatically. All of the cool, hip, network techs use graphical endpoint tools. Take a moment right now and download the popular, powerful, and completely free TCPView, written by Mark Russinovich, the Guru of Windows utilities. Just type TCPView into your search engine to find it or try going here:

https://docs.microsoft.com/en-us/sysinternals/

Click the Networking Utilities icon to get the latest copy. Figure 8-11 shows TCPView in action. The bars are colored, though you can’t tell from this screen shot: red is for closing connections and green shows new connections as they appear.

Figure 8-11 TCPView in action

TCPView won’t work on anything but Windows, but other operating systems have equivalent programs. Linux folks often use the popular Net Activity Viewer (Figure 8-12), available here: http://netactview.sourceforge.net.

Figure 8-12 Net Activity Viewer in action

Connection Status

Connection states change continually, and it’s helpful when using tools such as netstat or TCPView to understand the status of a connection at any given moment. Let’s look at the various connection statuses so you understand what each means—this information is useful for determining what’s happening on networked computers.

NOTE  The –a switch tells netstat to show all used ports, including “listening” ports not engaged in active communications. The –n switch instructs netstat to show raw port numbers and IP addresses.

A socket that is prepared to respond to any IP packets destined for that socket’s port number is called an open port or listening port. Every serving application has an open port. If you’re running a Web server on a computer, for example, it will have an open port 80. That’s easy enough to appreciate, but you’ll be amazed at the number of open ports on just about any computer. Fire up a copy of netstat and type netstat –an to see all of your listening ports. Running netstat –an gives a lot of information, so let’s just look at a small amount:

First look at this line:

This line shows a listening port ready for incoming packets that have a destination port number of 445. Notice the local address is 0.0.0.0. This is how Windows tells you that the open port works on all NICs on this PC. In this case, my PC has only one NIC (192.168.4.27), but even if you have only one NIC, netstat still shows it this way. This computer is sharing some folders on the network. At this moment, no one is connected, so netstat shows the Foreign Address as 0.0.0.0. Incoming requests use port number 445 to connect to those shared folders. If another computer on my network (192.168.4.83) was accessing the shared folders, this line would look like

Established ports are active, working endpoint pairs. Over time all connections eventually close like this one:

This line shows a Web browser making a graceful closure, meaning each side of the conversation sees the session closing normally.

If data’s going to move back and forth between computers, some program must always be doing the sending and/or receiving. Take a look at this line from netstat –an:

You see the 80 and might assume the connection is going out to a Web server. But what program on the computer is sending it? Enter the command netstat –ano (the –o switch tells netstat to show the process ID). Although you’ll see many lines, the one for this connection looks like this:

Every running program on your computer gets a process ID (PID), a number used by the operating system to track all the running programs. Numbers aren’t very helpful to you, though, because you want to know the name of the running program. In most operating systems, finding this out is fairly easy to do. In Windows, type netstat –b:

In Linux, you can use the ps command:

If you want to find out the PID of a process, you can use the trusty Task Manager. The PIDs are hidden, by default, in versions of Windows prior to 8, but they are easy to enable. Simply fire up Task Manager, select the Processes tab, select the View menu, and click the Select Columns... option. The first option in the list will be PID (Process Identifier). Check the box and then click OK. Task Manager will now show you the PID for all running programs. In Windows 8 or later, open Task Manager and select More Details (if you haven’t already), then jump over to the Details tab to see the PIDs.

Another great tool for discovering a PID (and a whole lot more) is Mark Russinovich’s Process Explorer; it is a perfect tool for this. Figure 8-13 shows Process Explorer scrolled down to the bottom so you can see the program using PID 456—good old Firefox!

Figure 8-13 Process Explorer

NOTE  To get Process Explorer, enter “Process Explorer” in your search engine to find it or try going here:

https://docs.microsoft.com/en-us/sysinternals/

Click the Process Utilities icon to get the latest copy.

You might be tempted to say “Big whoop, Mike—what else would use port 80?” Then consider the possibility that you run netstat and see a line like the one just shown, but you don’t have a browser open! You determine the PID and discover the name of the process is “Evil_Overlord.exe.” Something is running on your computer that should not be there.

Understanding how TCP/IP uses ports is a base skill for any network tech. To pass the CompTIA Network+ exam, you need to memorize a number of different well-known ports and even a few of the more popular registered ports. You must appreciate how the ports fit into the process of TCP/IP communications and know how to use netstat and other tools to see what’s going on inside your computer.

The biggest challenge is learning what’s supposed to be running and what’s not. No one on Earth can run a netstat command and instantly recognize every connection and why it’s running, but a good network tech should know most of them. For those connections that a tech doesn’t recognize, he or she should know how to research them to determine what they are.

Rules for Determining Good vs. Bad Communications

Here is the general list of rules I follow for determining good versus bad communications (as far as networking goes, at least!):

1. Memorize a bunch of known ports for common TCP/IP applications. The next section in this chapter will get you started.

2. Learn how to use netstat to see what’s happening on your computer. Learn to use switches such as –a, –n, –o, and –b to help you define what you’re looking for.

3. Take the time to learn the ports that normally run on your operating system. When you see a connection using ports you don’t recognize, figure out the process running the connection using a utility such as Linux’s ps or Process Explorer for Windows.

4. Take the time to learn the processes that normally run on your operating system. Most operating systems have their own internal programs (such as Windows’ svchost.exe) that are normal and important processes.

5. When you see a process you don’t recognize, just enter the filename of the process in a Web search. Hundreds of Web sites are dedicated to researching mystery processes that will tell you what the process does.

6. Get rid of bad processes.

Common TCP/IP Applications

Finally! You now know enough about the Transport layer, port numbering, and sockets to get into some of the gritty details of common TCP/IP applications. There’s no pretty way to do this, so let’s start with the big daddy of them all, the Web. The rest of this section tackles Telnet and SSH, e-mail protocols, and FTP.

The World Wide Web

Where would we be without the World Wide Web? If you go up to a non-nerd and say “Get on the Internet,” most of them will automatically open a Web browser, because to them the Web is the Internet. The Internet is the infrastructure that enables the Web to function, but it’s certainly more than just the Web. I think it’s safe to assume you’ve used the Web, firing up your Web browser to surf to one cool site after another, learning new things, clicking links, often ending up somewhere completely unexpected . . . it’s all fun! This section looks at the Web and the tools that make it function, specifically the protocols that enable communication over the Internet.

The Web is composed of servers that store specially formatted documents using languages such as Hypertext Markup Language (HTML). Figure 8-14 shows the Web interface built into my wireless access point.

Figure 8-14 My wireless access point’s Web interface

HTML has been around for a long time and, as a result, has gone through many versions. Today many developers use the latest HTML version called HTML5. See Figure 8-15.

Figure 8-15 HTML5 source code

EXAM TIP  HTML is the most well-known markup language, but many others roam the Web today, adding to HTML’s capabilities. Expect to see the Extensible Markup Language (XML) on the exam. XML provides the basic format or markup language for everything from RSS feeds to Microsoft Office documents.

Web browsers are designed to request HTML pages from Web servers and then open them. To access a Web page, you enter http:// plus the IP address of the Web server. When you type the address of a Web server, such as http://192.168.4.1, you tell the browser to go to 192.168.4.1 and ask for a Web page. All Web servers have a default Web page that they open unless you enter something more complex like http://192.168.4.1/status.

NOTE  Some Web browsers are pretty forgiving. If you only type in 192.168.4.1, forgetting the “http://” part, they just add it for you.

Granted, most people don’t enter IP addresses into browsers, but rather enter text like www.totalsem.com or www.google.com. Memorizing text addresses is much easier than memorizing IP addresses. Web site text addresses use a naming protocol called Domain Name System (DNS), which you will learn about in the next chapter. For now, just enter the IP address as shown.

HTTP

The Hypertext Transfer Protocol (HTTP) is the underlying protocol used by the Web, and it runs, by default, on TCP port 80. When you enter http:// at the beginning of a Web server’s IP address, you are identifying how messages are formatted and transmitted, requesting and responding to the transfer of HTML-formatted files. HTTP defines what actions Web servers and browsers should take in response to various commands.

HTTP has a general weakness in its handling of Web pages: it relays commands executed by users without reference to any commands previously executed. The problem with this is that Web designers continue to design more complex and truly interactive Web pages. HTTP is pretty dumb when it comes to remembering what people have done on a Web site. Luckily for Web designers everywhere, other technologies exist to help HTTP relay commands and thus support more-interactive, intelligent Web sites. These technologies include JavaScript/AJAX, server-side scripting, and cookies.

EXAM TIP  Before connections to the Web became fast, many people used a completely different Internet service for swapping information, ideas, and files. USENET enjoyed great popularity for some years, though it barely survives today. Clients used the Network News Transfer Protocol (NNTP) to access USENET over TCP port 119. It might show up as an incorrect answer choice on the exam.

Publishing a Web Site

In the simplest sense, a Web site consists of a Web page hosted by a Web server. To share an HTML document—a Web page—with the rest of the world, find a Web server that will “host” the page. You most certainly can install a Web server on a computer, acquire a public IP address for that computer, and host the Web site yourself. Self-hosting is a time-consuming and challenging project, though, so most people use other methods.

NOTE  Many Web site developers today use premade customizable templates and some sort of Web technology, such as WordPress. These Web technologies enable powerful and dynamic Web site experiences for your visitors. The questions you’ll see on the CompTIA Network+ exam focus on the concepts, rather than modern implementations, of Web sites.

Most Internet service providers (ISPs) provide Web servers of their own, or you can find relatively inexpensive Web hosting service companies. The price of Web hosting usually depends on the services and drive space offered. Web hosts typically charge around US$10 a month for simple Web sites.

One option that has been available for a while is free Web hosting. Usually the services are not too bad, but free Web hosts have limitations. Nearly all free Web hosts insist on the right to place ads on your Web page. Third-party ads are not as much of an issue if you are posting a basic blog or fan Web page, but if you do any sort of business with your Web site, ads can be most annoying to your customers. The worst sort of free Web host services place pop-up ads over your Web page. Beyond annoying!

Once you have uploaded HTML pages to a Web host, the Web server takes over. What’s a Web server? I’m glad you asked!

Web Servers and Web Clients

A Web server is a computer that delivers (or serves up) Web pages. Web servers listen on port 80, fetching requested HTML pages and sending them to browsers. You can turn any computer into a Web server by installing server software and connecting the machine to the Internet, but you need to consider the operating system and Web server program you’ll use to serve your Web site. Microsoft’s server is Internet Information Services (IIS), shown in Figure 8-16.

Figure 8-16 IIS in action

IIS enables you to set a maximum connection limit on your Web server based on available bandwidth and memory. This enables you to protect your network against an overwhelming number of requests due to a particularly popular page or a type of malicious attack called a denial of service (DoS) attack (more on DoS attacks in Chapter 19, “Protecting Your Network”).

Microsoft builds an artificial 20-connection limit into Windows client versions, so you should only run IIS on Server versions of Windows (unless you don’t expect too many people to visit your Web site at one time).

A majority of UNIX/Linux-based operating systems run Apache HTTP Server. As of this writing, Apache serves ~44 percent of the active Web sites on the Internet. Apache is incredibly popular, runs on multiple operating systems (including Windows), and, best of all, is free! In comparison, even with the weight of Microsoft behind it, IIS only commands about 7 percent market share of active Web sites. [The other big players are nginx (free and open source with ~21 percent active sites) and Google (used for Google’s online services with ~9 percent active sites)].

NOTE  An active site is a Web site that’s functioning by serving Web pages. The percent of market share mentioned here changes a lot when you add in parked sites, domain names that have been registered but don’t really do anything, like Web or e-mail servers.

Apache is nothing more than an executable program and a bunch of text files, so it isn’t much to look at. To ease configuration, many Web administrators use add-on graphical user interfaces (GUIs) such as Webmin that make administering Apache a breeze. Figure 8-17 illustrates the wonderful simplicity that is Webmin.

Figure 8-17 Webmin Apache module

Other common Web servers on the Internet include nginx, which is ranked second for active sites, and Google Web Server (GWS), which is in fourth place. GWS, used only by Google’s servers, has about 8 percent of the total active Web server market! There are literally hundreds of other Web servers, but you’ll rarely see them outside of small personal Web sites.

Web clients are the programs used to surf the Web. A client program (a Web browser) reads Web pages supplied by the Web server. To access a server, type either an IP address or, more commonly, the complete name of the Web server in the address bar. The complete name is often referred to as the uniform resource locator (URL).

The most popular Web browsers are Microsoft Edge, Mozilla Firefox, Apple Safari, and Google Chrome. (You might also see mention of Microsoft’s old and discontinued browser, Internet Explorer (IE), on the CompTIA Network+ exam. Microsoft recommends not using IE in real Web surfing today.)

SSL/TLS and HTTPS

Any nosy person who can plug into a network can see and read the HTTP packets moving between a Web server and a Web client. Less than nice people can easily create a fake Web site to trick people into thinking it’s a legitimate Web site and then steal their user names and passwords.

EXAM TIP  HTTP is a perfect example of a common network vulnerability and threat, an unsecure protocol. Other vulnerabilities include open ports, like we discussed earlier, and other unsecure protocols that we’ll hit next. For more in-depth coverage of vulnerabilities, see Chapter 19.

For an Internet application to be secure, it must have the following:

•  Authentication User names and passwords

•  Encryption Stirring up the data so others can’t read it

•  Nonrepudiation Source is not able to deny a sent message

While all of Chapter 10, “Securing TCP/IP,” is dedicated to these concepts, I can’t mention HTTP without at least touching on its secure counterpart, HTTPS. The Web has blossomed into a major economic player, requiring serious security for those who wish to do online transactions (e-commerce). In the early days of e-commerce, people feared that a simple credit card transaction on a less-than-secure Web site could transform their dreams of easy online buying into a nightmare of being robbed blind and ending up living in a refrigerator box. I can safely say that it was never as bad as all that.

Nowadays, many tools can protect your purchases and your anonymity. One early safeguard was called Secure Sockets Layer (SSL), a protocol developed by Netscape for transmitting private documents securely over the Internet. Transport Layer Security (TLS) is the latest version of SSL, although techs use the terms interchangeably. SSL/TLS uses encryption to set up a secure private connection. All the popular Web browsers and Web servers support SSL/TLS, and many Web sites use the protocol to obtain confidential user information, such as credit card numbers. One way to tell if a site is using SSL/TLS is by looking at the Web page address. By convention, Web pages that use an SSL/TLS connection start with https instead of http. Read Chapter 10 for more details on SSL and TLS.

EXAM TIP  HTTP enables you to access the Web, but HTTPS gets you there securely. HTTPS uses TLS to provide the security.

HTTPS stands for Hypertext Transfer Protocol over SSL. HTTPS uses TCP port 443. You can also look for a small lock icon in the address bar of your browser. Figure 8-18 shows a typical secure Web page. The https: in the address and the lock icon are circled.

Figure 8-18 Secure Web page

EXAM TIP  Many techs refer to HTTPS as Hypertext Transfer Protocol Secure, probably because it’s easier to explain to non-techs that way. Don’t be surprised to see it listed this way on the CompTIA Network+ exam.

Telnet and SSH

Roughly one billion years ago, there was no such thing as the Internet or even networks.… Well, maybe it was only about 40 years ago, but as far as nerds like me are concerned, a world before the Internet was filled with brontosauruses and palm fronds. The only computers were huge monsters called mainframes and to access them required a dumb terminal like the one shown in Figure 8-19.

Figure 8-19 WANG dumb terminal

NOTE  A dumb terminal is a local system—generally a monitor, keyboard, and mouse—that enables you to access a distant system that has all the computing power. The dumb terminal can’t do any work on its own, even though it might look like a personal computer.

Operating systems didn’t have windows and pretty icons. The interface to the mainframe was a command line, but it worked just fine for the time. Then the cavemen who first lifted their heads up from the computer ooze known as mainframes said to themselves, “Wouldn’t it be great if we could access each other’s computers from the comfort of our own caves?” That was what started the entire concept of a network. Back then the idea of sharing folders or printers or Web pages hadn’t been considered yet. The entire motivation for networking was so people could sit at their dumb terminals and, instead of accessing only their local mainframes, access totally different mainframes. The protocol to do this was called the Telnet Protocol or simply Telnet.

Modern PCs can (but shouldn’t) use Telnet to connect remotely to another computer via the command line (Figure 8-20). Telnet runs on TCP port 23, enabling you to connect to a Telnet server and run commands on that server as if you were sitting right in front of it.

Figure 8-20 Telnet client

Telnet enables you to remotely administer a server and communicate with other servers on your network. As you can imagine, this is sort of risky. If you can remotely control a computer, what is to stop others from doing the same? Thankfully, Telnet does not allow just anyone to log on and wreak havoc with your network. You must enter a user name and password to access a Telnet server.

Unfortunately, Telnet does not have any form of encryption. If someone intercepted the conversation between a Telnet client and Telnet server, he or she would see all of the commands you type as well as the results from the Telnet server. As a result, in no scenario should you use Telnet on the Internet. Instead, use Secure Shell (SSH), a terminal emulation program that looks exactly like Telnet but encrypts the data and the authentication.

NOTE  Telnet only enables command-line remote access; it does not enable GUI access. If you want to access another computer’s desktop remotely, you need another type of program.

Telnet/SSH Servers and Clients

The oldest Telnet server, found on UNIX and Linux systems, is telnetd. Like most UNIX/Linux servers, telnetd isn’t much to look at, so let’s move over to Windows. Since the halcyon days of Windows NT, Windows has come with a basic Telnet server. It is disabled, by default, in modern Windows systems, because Telnet is a gaping security hole. The built-in server is very limited and Microsoft discourages its use. I prefer to use a great little third-party server called freeSSHd (Figure 8-21). Note the name—freeSSHd, not “freeTelnet.” As Telnet fades away and SSH becomes more dominant, finding a Telnet-only server these days is hard. All of the popular Telnet servers are also SSH servers.

Figure 8-21 FreeSSHd

A Telnet or SSH client is the computer from which you log into the remote server. Most operating systems have a built-in Telnet client that you run from a command prompt. Figure 8-22 shows the Telnet client built into macOS. Just open a terminal window and type telnet and the IP address of the Telnet server.

Figure 8-22 macOS Telnet

Command-prompt clients lack a number of handy features. They can’t, for example, remember the IP addresses, user names, or passwords for Telnet or SSH servers, so every time you use Telnet or SSH, you have to enter all that information again. Third-party Telnet/SSH clients, such as the very popular PuTTY, which you saw in Chapter 7, store all this information and much more (Figure 8-23).

Figure 8-23 PuTTY

Configuring a Telnet/SSH Client

When you configure a Telnet or SSH client, you must provide the host name, a valid login name, and the password. As I mentioned previously, you must have permission to access the server to use Telnet or SSH. A host name is the name or IP address of the computer to which you want to connect. For instance, you might connect to a Web server with the host name websrv.mhteched.com. The user login name you give Telnet or SSH should be the same login name you’d use if you logged into the server at its location.

Some computers, usually university libraries with online catalogs, have open systems that enable you to log in with Telnet. These sites either display a banner before the login prompt that tells you what login name to use, or they require no login name at all. As with the login name, you use the same password for a Telnet login that you’d use to log into the server directly. It’s that simple. Computers with open access either tell you what password to use when they tell you what login name to use, or they require no login name/password at all.

EXAM TIP  Telnet and SSH enable you to control a remote computer from a local computer over a network.

SSH and the Death of Telnet

From the earliest days of the Internet, Telnet has seen long and heavy use in the TCP world, but it suffers from lack of any security. Telnet passwords as well as data are transmitted in cleartext and are thus easily hacked. To that end, SSH has now replaced Telnet for every serious terminal emulation. In terms of what it does, SSH is extremely similar to Telnet in that it creates a terminal connection to a remote host. Every aspect of SSH, however, including both login and data transmittal, is encrypted. To get the full SSH understanding, we need to talk about encryption standards, which we’ll get to in Chapter 10. SSH uses TCP port 22 instead of Telnet’s port 23.

EXAM TIP  SSH enables you to control a remote computer from a local computer over a network, just like Telnet. Unlike Telnet, SSH enables you to do it securely!

E-mail

Electronic mail (e-mail) has been a major part of the Internet revolution, and not just because it has streamlined the junk mail industry. E-mail provides an extremely quick way for people to communicate with one another, letting them send messages and attachments (like documents and pictures) over the Internet. It’s normally offered as a free service by ISPs. Most e-mail client programs provide a rudimentary text editor for composing messages, but many can be configured to let you edit your messages using more sophisticated editors.

E-mail consists of e-mail clients and e-mail servers. When a message is sent to your e-mail address, it is normally stored in an electronic mailbox on your e-mail server until you tell the e-mail client to download the message. Most e-mail client programs can be configured to signal you in some way when a new message has arrived or to download e-mails automatically as they come to you. Once you read an e-mail message, you can archive it, forward it, print it, or delete it. Most e-mail programs are configured to delete messages from the e-mail server automatically when you download them to your local machine, but you can usually change this configuration option to suit your circumstances.

E-mail programs use a number of application-level protocols to send and receive information. Specifically, the e-mail you find on the Internet uses SMTP to send e-mail, and either POP3 or IMAP4 to receive e-mail.

SMTP, POP3, and IMAP4, Oh My!

The following is a list of the different protocols that the Internet uses to transfer and receive mail:

SMTP   The Simple Mail Transfer Protocol (SMTP) is used to send e-mail. SMTP travels over TCP port 25 and is used by clients to send messages.

POP3   Post Office Protocol version 3 (POP3) is one of the two protocols that receive e-mail from SMTP servers. POP3 uses TCP port 110. POP3 is on its way out today, though you’ll see it on the exam.

IMAP4   Internet Message Access Protocol version 4 (IMAP4) is a preferred alternative to POP3. Like POP3, IMAP4 retrieves e-mail from an e-mail server. IMAP4 uses TCP port 143 and supports some features that are not supported in POP3. For example, IMAP4 enables synchronization of mail among many devices, meaning you can access e-mail messages at your Windows desktop, your macOS portable, and your Android smartphone. (It works for any combination; I used those three as an example.) IMAP4 also supports the concept of folders that you can place on the IMAP4 server to organize your e-mail. Some POP3 e-mail clients have folders, but that’s not a part of POP3, just a nice feature added to the client.

NOTE  A zillion smartphone users access e-mail through Exchange ActiveSync, a proprietary Microsoft protocol. Like IMAP4, ActiveSync enables synchronization of e-mail among devices, so you can access mail via a desktop Microsoft Outlook client and on your smartphone with an e-mail app. Although it’s not on the CompTIA Network+ exam, we’ll explore Exchange ActiveSync in more detail in Chapter 16 because it’s in widespread use today.

Alternatives to SMTP, POP3, and IMAP4

Although SMTP, POP3, and IMAP4 are the traditional tools for sending and receiving e-mail, two other options are widely popular: Web-based e-mail and proprietary solutions. (Plus, as I mentioned earlier, Exchange ActiveSync is widely used with mobile devices.)

Web-based mail, as the name implies, requires a Web interface. From a Web browser, you simply surf to the Web-mail server, log in, and access your e-mail. The cool part is that you can do it from anywhere in the world where you find a Web browser and an Internet hookup! You get the benefit of e-mail without even needing to own a computer. Some of the more popular Web-based services are Google’s Gmail (Figure 8-24), Microsoft’s Outlook.com/Outlook Mail, and Yahoo!’s Yahoo! Mail.

Figure 8-24 Gmail in action

EXAM TIP  The CompTIA Network+ exam has viewed Web-based e-mail as one of many Web services. Web services also include applications that you access on the Internet, like Google Docs and Google Sheets, online word processing and spreadsheet programs, respectively. You might run into a question that uses this phrase, though most likely you’ll see Cloud-based services. See Chapter 15 for more on the Cloud.

The major contrast between Web services and local services involves access. Web services offer access from any machine, as long as that machine is connected to the Internet. Local applications (usually) require local access, but don’t need any other connectivity.

The key benefits of Web-based e-mail services are as follows:

•  You can access your e-mail from anywhere.

•  They’re free.

•  They’re handy for throw-away accounts (like when you’re required to give an e-mail address to download something, but you know you’re going to get spammed if you do).

E-mail Servers

Two mail server types dominate the once-fragmented e-mail server space: Exim and Postfix. With well over 50 percent market share, Exim runs on just about everything, from Unix/Linux to Windows. It even runs on the tiny Raspberry Pi! Exim, at heart, is a configuration file that you can manage by hand or through a graphical tool like cPanel (Figure 8-25).

Figure 8-25 cPanel used to manage Exim mail server

Microsoft, of course, has its own e-mail server, Microsoft Exchange Server, and like IIS, it only runs on Windows. Figure 8-26 shows the Exchange admin center for Office 365. Exchange Server is both an SMTP and a POP3/IMAP4/Exchange ActiveSync/MAPI/etc. server in one package.

Figure 8-26 Microsoft Exchange Server

E-mail servers accept incoming mail and sort out the mail for recipients into individual storage area mailboxes. These mailboxes are special separate holding areas for each user’s e-mail. An e-mail server works much like a post office, sorting and arranging incoming messages, and kicking back those messages that have no known recipient.

E-mail servers are difficult to manage. E-mail servers store user lists, user rights, and messages, and are constantly involved in Internet traffic and resources. Setting up and administering an e-mail server takes a lot of planning, although it’s getting easier. Most e-mail server software runs in a GUI, but even the command-line-based interface of e-mail servers is becoming more intuitive.

E-mail Client

An e-mail client is a program that runs on a computer and enables you to send, receive, and organize e-mail. The e-mail client program communicates with the SMTP e-mail server to send mail and communicates with the IMAP4 or POP3 e-mail server to download the messages from the e-mail server to the client computer. There are hundreds of e-mail programs, two of the most popular of which are Microsoft Outlook (Figure 8-27) and Mozilla Thunderbird.

Figure 8-27 Microsoft Outlook

Configuring an E-mail Client   Configuring a client is an easy matter. Your mail administrator will give you the server’s domain name and your mailbox’s user name and password. You need to enter the POP3 or IMAP4 server’s domain name and the SMTP server’s domain name to the e-mail client (Figure 8-28). Every e-mail client has a different way to add the server domain names or IP addresses, so you may have to poke around, but you’ll find the option there somewhere! In many cases, this may be the same name or address for both the incoming and outgoing servers—the folks administering the mail servers will tell you. Besides the e-mail server domain names or addresses, you must also enter the user name and password of the e-mail account the client will be managing.

Figure 8-28 Entering server information in Microsoft Outlook

FTP

File Transfer Protocol (FTP) is the original protocol used on the Internet for transferring files. The old active FTP used TCP ports 21 and 20 by default, although passive FTP only uses port 21 for a default. See the discussion on active versus passive FTP later in this chapter.

FTP sites are either anonymous sites, meaning that anyone can log on, or secured sites, meaning that you must have a user name and password to access the site and transfer files. A single FTP site can offer both anonymous access and protected access, but you’ll see different resources depending on which way you log in.

FTP Servers and FTP Clients

The FTP server does all the real work of storing the files, accepting incoming connections and verifying user names and passwords, and transferring the files. The client logs onto the FTP server (either from a Web site, a command line, or a special FTP application) and downloads the requested files onto the local hard drive.

FTP Servers   We don’t set up servers for Internet applications nearly as often as we set up clients. I’ve set up only a few Web servers over the years, whereas I’ve set up thousands of Web browsers. FTP servers are the one exception, as we nerds like to exchange files. If you have a file you wish to share with a lot of people (but not the entire Internet), a reliable, old-school method is to put up a quick FTP server. Most versions of Linux/UNIX have built-in FTP servers, but many third-party applications offer better solutions. One of the simpler ones for Windows, especially for those “let me put up an FTP server so you guys can get a copy” type of scenarios, is the open source FileZilla Server (Figure 8-29).

Figure 8-29 FileZilla Server

NOTE  Most Web servers are also FTP servers. These bundled versions of FTP servers are robust but do not provide all the options one might want.

FTP is not very secure because data transfers are not encrypted by default, so you don’t want to use straight FTP for sensitive data. But you can add user names and passwords to prevent all but the most serious hackers from accessing your FTP server. I avoid using the anonymous login because unscrupulous people could use the server for exchanging illegal software.

Another thing to check when deciding on an FTP server setup is the number of clients you want to support. Most anonymous FTP sites limit the number of users who may download at any one time to around 500. This protects you from a sudden influx of users flooding your server and eating up all your Internet bandwidth.

FTP Clients   FTP clients, as noted before, can access an FTP server through a Web site, a command line, or a special FTP application. Usually special FTP applications offer the most choices for accessing and using an FTP site.

NOTE  Every operating system has a command-line FTP client. I avoid using them unless I have no other choice, because they lack important features like the ability to save FTP connections to use again later.

You have many choices when it comes to FTP clients. For starters, some Web browsers handle FTP as well as HTTP, although they lack a few features. For example, Firefox only supports an anonymous login. To use your Web browser as an FTP client, type ftp:// followed by the IP address or domain name of the FTP server (Figure 8-30).

Figure 8-30 FTP in a Web browser

The best way to use FTP is to use a dedicated FTP client. So many good ones are available that I find myself using a different one all the time. FileZilla comes in a client version, for example, but these days, I’m using CyberDuck (Figure 8-31).

Figure 8-31 CyberDuck dedicated FTP client

Active vs. Passive FTP

FTP has two ways to transfer data: active and passive FTP. Traditionally, FTP used the active process—let’s see how this works. Remember that FTP uses TCP ports 20 and 21? Well, when your client sends an FTP request, it goes out on port 21. When your FTP server responds, however, it sends the data back using an ephemeral destination port and port 20 as a source port.

Active FTP works great unless your client uses NAT. Since your client didn’t initiate the incoming port 20, your NAT router has no idea where to send this incoming packet. Additionally, any good firewall sees this incoming connection as something evil because it doesn’t have anything inside the network that started the link on port 20. No problem! Good FTP clients all support passive FTP. With passive FTP, the server doesn’t use port 20. Instead, the client sends an FTP request on port 21, just like active FTP. But then the server sends back a random port number, telling the client which port it’s listening on for data requests. The client, in turn, sends data to the port specified by the FTP server. Because the client initiates all conversations, the NAT router knows where to send the packet.

The only trick to passive FTP is that the client needs to expect this other incoming data. When you configure an FTP client for passive, you’re telling it to expect these packets.

NOTE  Trivial File Transfer Protocol (TFTP) is used for transferring files and has a similar-sounding name to FTP, but beyond that it is very different. TFTP uses UDP port 69 and does not use user names and passwords, although you can usually set some restrictions based on the client’s IP address. TFTP is not at all secure, so never use it on any network that’s less than trustworthy.

Internet Applications

Use Table 8-1 as a review tool to help you remember each Internet application.

Table 8-1 Internet Application Ports and Protocols

SIM  Check out the excellent Chapter 8 “Ports and Protocols” Challenge! over at http://totalsem.com/007. It’ll help greatly in memorizing the port numbers that each protocol uses.

Chapter Review

Questions

1. The protocol developed by Netscape for transmitting private documents over the Internet is known as

A. SSS

B. SSA

C. SSL

D. NSSL

2. Which of the following are key benefits of Web-based mail? (Select two.)

A. You can use a third-party application, like Microsoft Outlook, to download your e-mail.

B. You can access your e-mail from anywhere in the world using a Web browser and an Internet connection.

C. It is completely spam-free.

D. It is great for creating throw-away accounts.

3. An SSL/TLS URL connection starts with which prefix?

A. http

B. www

C. ftp

D. https

4. Which statements about SSH and Telnet are true? (Select two.)

A. Windows comes with preinstalled SSH and Telnet clients.

B. SSH is more secure than Telnet because it encrypts data.

C. Telnet is a command-line tool, whereas SSH is a GUI tool.

D. SSH uses port 22, and Telnet uses port 23.

5. Why might you use the netstat utility?

A. To see the route an IP packet takes across multiple routers

B. To see your IP address and configuration details

C. To see the endpoints of your sessions

D. To issue commands to a remote server

6. Why might you use a Telnet client?

A. To see the route an IP packet takes across multiple routers

B. To see your IP address and configuration details

C. To see the endpoints of your sessions

D. To issue commands to a remote server

7. Port 110 (POP) is what kind of port?

A. Well-known

B. Registered

C. Ephemeral

D. Reserved

8. What ports does FTP use traditionally? (Select two.)

A. 20

B. 21

C. 23

D. 25

9. Which of the following protocols are used to receive e-mail from servers? (Select two.)

A. IMAP

B. ICMP

C. IGMP

D. POP

10. Which statements about netstat switches (in Windows) are true? (Select three.)

A. –a shows all used ports.

B. –n shows raw port numbers and IP addresses.

C. –o shows the process ID.

D. –s shows the application name.

Answers

1. C. Secure Sockets Layer (SSL) is a protocol that was developed by Netscape for transmitting private documents over the Internet securely.

2. B and D. You can access a Web-based e-mail account from any browser on any machine connected to the Internet. These accounts are great for creating throw-away e-mail addresses.

3. D URLs that use an SSL/TLS connection start with https instead of http.

4. B and D. SSH encrypts data and is more secure than Telnet. Also, SSH uses port 22, whereas Telnet uses port 23.

5. C Use netstat to see the endpoints of your sessions.

6. D Telnet is used to issue commands to a remote server. Aside from the CompTIA Network+ exam, though, use SSH instead.

7. A Ports 0–1023 are well-known ports.

8. A and B. Active FTP used ports 20 and 21. Passive FTP only uses port 21 and a random port.

9. A and D. IMAP and POP are used to receive e-mail.

10. A, B, and C. –a shows all used ports; –n shows raw port numbers and IP addresses; and –o shows the process ID.