author begins the chapter by reminding us that there are many protocols
in the TCP/IP suite. This chapter is about several of them. He gives us
two examples of human communication, one more formal than the other.
His point is that we can think of network communications as being of
two similar types.The more formal kind are connection-oriented,
which make sure that connections are established, messages are
confirmed, and and connections are ended. This is the way Transmission
Control Protocol (TCP) works. On page 226, the text describes an HTTP request making a TCP connection with a TCP three-way handshake. Note that only two participants are involved.
The text then describes terminating the TCP session, which could be initiated by either party in the session.
The text does not mention that this process can vary. In this
discussion on the wireshark site, it is noted that a web browser
might send a connection reset
packet (RST) instead of
completing the graceful
closure dialog. Graceful, in IT typically means that something is being
done formally, methodically, and with every party in the transaction
aware and acknowledging what is happening.
User Datagram Protocol (UDP) is much less formal. The text describes three upper layer protocols that use UDP connectionless service:
ICMP is discussed
briefly. We are told that Internet
Control Message Protocol
is connectionless, partly because it typically sends one packet instead
of a stream of them. Remember that ICMP is used to send ping requests,
and it is easy to remember the idea of one packet at a time. If that
doesn't do it for you, try "one ping only".
The text moves on to port numbers on page 228, warning us that we need to know several of them to pass the Network+ test. We saw a few in the last section. A port number is stored in two bytes, so it can be as low as 0 or as high as 65,535. Like many texts, ours tells us that there are three types of port numbers, but it is not sure where to draw the lines, so there may really be only two types, called by several names:
The text tells us that the combination of an IP address and a
port number can be called a socket
or an endpoint.
This is a little pedantic, since we are already talking about devices
on a TCP/IP network, and all those devices have addresses. If you want
to see a list of sockets, open a
command prompt window, and give it the command netstat -n.
In the example above, note that all the local ports are above 5000, while the foreign ports are either 443 (HTTPS) or 445 (Microsoft-ds file sharing) . The text tells us to learn the netstat utility for the Network+ exam, but suggests we may want to use TCPView for everyday use. It is dynamic instead of showing us a moment in time as netstat does.
The text reminds us that we communicate with a web server on port 80, and tells that we do so because the server is listening on that open port, the port it watches for incoming requests. So is it listening or watching? Neither: its a machine. Both verbs are metaphors for what the program waiting for a request is doing. This takes us to another netstat lesson. To see all the open ports on a computer, enter netstat -an. You will get the information from the -n version of the command, plus all the open ports. By the way, since we should be looking at what the netstat command can do, you should know how to ask it. Enter netstat -? to see the help file for that command. I was asked in class about using the dash as the soft switch flag instead of the forward slash. Both work, but the help file for netstat only shows the dash versions of each variation.
Note that all of the connections in the example above are in
the ESTABLISHED state, even
the ones for local host. In the examples in the text, other states are
mentioned that tell you something about the connection.
The text continues with more useful switches for the netstat command.
The rest of the chapter is about various applications that run under TCP or UDP. There is a great deal of discussion, but the facts you need to know are summarized on page 252 like this:
This chapter is mostly about two naming systems that you may
find on networks, DNS and WINS.
Before there was DNS, the Internet was a lot smaller and it was possible to keep one list of host names and the IP addresses that matched them. The list was just called the hosts table, and it was updated at the Stanford Research Institute Network Information Center (SRI-NIC). This was downloaded to each network. It is the ancestor of the hosts file on most computers.
A hosts file is a list, saved as a simple text file, divided into three columns: IP address, official host name, and aliases that are also allowed for this host. In the example on page 259, we see only two columns, meaning that these hosts have one name apiece. Each line in the table describes one IP address and the host names that can be used for it by machines that read this table. This is a fine system for small networks in which changes do not happen often. Each device on the network must have its own copy of the hosts file, or must know where the hosts file is stored, and must read it to make use of host names.
Note that none of the examples uses a file extension. The hosts file itself must be an ASCII file. The # symbol marks the beginning of a remark or comment. Lines that begin with that symbol are not processed by the operating system, they are in the file for internal documentation.
The text reveals to us that every operating system that has a hosts file refers to it for an IP address before it makes a request to get an IP address from a DNS server. This is worth knowing, and essentially it provides a vulnerability that could be exploited. If you want to send traffic to your desired site instead of the real one, you could try planting addresses and host names in a device's host file.
The text turns to DNS on page 260. I have
seen the acronym translated as Domain Name System and
as Domain Name Service. People need help navigating the Internet. Names
are much easier to remember than IP addresses, but we can't put them
all in one file. Instead, they are put in a distributed database,
The information needed to find a host on the Internet is too complex and too fluid to save on any single server. DNS was invented to manage a database that is saved on lots of machines. DNS uses a hierarchy, an inverted tree-shaped structure that branches as you go down the tree.
The text spends several paragraphs getting around to telling you that a domain name can include a host name. Remember that a domain name refers to a hierarchical structure, and as we read from left to right, we are naming layers of the structure as we go toward the root of the DNS hierarchy. Be aware that a domain name that specifies all the layers from a device up to the DNS root is a fully qualified domain name.
DNS is a distributed database system, which means that many servers each hold part of the DNS system. What the system does is provide translation from Domain Names (names of web sites, for instance) to IP addresses. If I tell you to check out the information at server 220.127.116.11 this week, will you remember that address? Thanks to DNS, you don't have to remember the numbers. Its URL (Uniform Resource Locator) name is www.cnn.com. You can enter either the address or the name in the address line of a browser. Either will take you to the same web site.
Back to the distributed idea. The Internet is divided into Domains. Baker College, for example, has been assigned a subdomain (called Baker) in the edu domain, which is for colleges that offer 4-year degrees and more. edu is a top-level domain. A domain name is limited to 255 characters, and each label in it (the parts separated by dots) is limited to 63 characters.
Your book wants you to be familiar with several top-level domains:
Most countries have two letter domain names. Some, like Germany, are not intuitive until you remember what the country is called in the language spoken there.
The DNS hierarchy is meant to be subdivided. Domains are divided into subdomains. A subdomain may be a zone that a company administers. This zone is subdivided into other, smaller zones that are administered by divisions of the company. A DNS server consults higher and higher level authorities, which consult zone authorities under them to resolve a DNS request. The machine asking the server for the translation of a host name to an IP address is called a DNS resolver. This seems odd, since the machine making the request provides no part of the name resolution, but it is the one called the resolver.
On page 272, the text start a discussion of what a DNS server looks like on a Windows Server. Note the three folders shown in the image on that page:
The text has a long discussion about Microsoft complications to DNS, which does not appear to be covered in the LabSim material, so we will move ahead to page 282, to discuss WINS, Windows Internet Name Service.
As you may gather from the text, Microsoft has created competing software not so much to match as to provide an alternative system for everything we have discussed so far. Their version of the HOSTS file is called the LMHOSTS file. It holds IP addresses, like the HOSTS file, but the names in it are NetBIOS names, not domain names.
The text gracefully explains the functions of a system that uses NetBIOS and WINS, but it is a rather dated discussion, hinging on using workstations running Windows 95 or 98, which should be way obsolete at this time. In a marginal note on page 284, the text points out that the same interface we have been using to configure IP settings has a tab for WINS that can be used for that kind of configuration.
One of the confusing things about WINS is its nbtstat utility whose name closely resembles netstat. Remember that NetBIOS is part of the WINS system and nbtstat begins with nb.
The chapter ends with some general advice about troubleshooting TCP/IP problems which you should read for any ideas you have not heard yet.