If you can read this, you might want to skip straight to the content. Also, kindly take a moment to read my rant about Web design—especially if you’re wondering why this site looks a bit…dull.

Internet Protocols

by Ben Goren

Introduction

When you communicate with another person, you both act in a pre-defined manner that sets the framework for how your conversation works. For example, one person will say “Hi” followed by the other person’s name; the other person will respond similarly. At this point, you’ve both agreed that you’re going to be talking to each other, and that you’re who each of you thinks you are. Next, one person is likely to ask the other, “How’s it going?” or something similar—well, you’re a human being, a member of society, so you know the routine. Eventually, the two people exchange meaningful information. At the end, they both say, “Goodbye,” and they know that the conversation is over.

Computers have similar routines that they go through. These rules for communication are called protocols. Any time two electronic devices are exchanging information, they’re using a protocol. For example, certain CPUs will talk to certain hard drives using the SCSI, or Small Computer Serial Interface protocol. When multiple hard drives are connected to a single computer with the same piece of wire, the SCSI protocol specifies how the computer can talk to one of the individual drives without confusing the others. Similarly, if you’re at a party, the way that people stand close to each other and only one person talks at a time lets everybody hear the conversation they’re interested in.

Layers upon layers

In Internet communications, there are multiple layers of protocols all working at the same time. At the party, one person might be trying to make a business deal, impress a significant other, and intimidate a rival—all at the same time in the same conversation. Internet protocols aren’t quite so dramatic; the layers involved are all designed to handle different aspects of the delivery process.

Network Access Layer

Internet protocols don’t carry any information about the physical method by which the information is carried. The Internet is made up of many different kinds of media, including modems using telephone lines, Ethernet, fiber optic cables, and even carrier pigeons. Each of those methods have their own ways of ensuring that the various devices physically work as advertised and that the information makes it from one device to the next. Descriptions of such systems often get quite technical, involving discussions of voltages, S/N ratios, wire resistance and capacitance, and other topics only an electrical engineer can love. We’ll leave them to it.

Internet Layer

This is where IP, the Internet Protocol comes into play. It controls information on what computers are talking to each other and some other details about how they’re doing it.

Datagrams

The Internet Protocol specifies that information should be broken up into small pieces, called packets or datagrams. The two terms are often used interchangeably, although there are distinct and precise definitions of each. Don’t worry about the difference unless you’ve got a test on the subject, but a packet is a block of data with the information necessary to deliver it, and a datagram is a packet as defined by the Internet Protocol.

If you were to send letters the IP way, you’d write everything on a postcard. If your message was too long to fit on a single postcard, you’d split up over two (or dozens, or millions) of postcards, and send each of them separately. Each postcard, of course, has its own pair of addresses (yours and your friends) and postage, all properly formatted. Your friend can read the message when enough of the postcards have arrived.

The United States Postal Service has a perhaps-undeserved reputation for being unreliable. Some of those postcards might get lost. IP packets routinely get lost, and that’s fine. Others might get garbled—just like a postcard might get munched by a sorting machine. That’s okay, too, with IP. Finally, you don’t need anything other than your friend’s address to send a message; your friend doesn’t need to know that you’re about to start sending a bunch of postcards. IP datagrams work like that, too. If you need to know that your friend is actually there and receiving your postcards—or datagrams—there are ways of ensuring that, but not at the IP layer.

You know what a postcard looks like: message on the left, address on the right in the middle, stamp in the upper-right corner, etc. Here’s what an IP datagram looks like:

		<—Bits-->
		0	4	8	12	16	20	24	28
^ \| W o r d s \| v	1	Version	IHL	Type of Service		Total Length				^ \| H e a d e r \| v
	2	Identification				Flags	Fragmentation Offset
	3	Time to Live		Protocol		Header Checksum
	4	Source Address
	5	Destination Address
	6	Options						Padding
		data begins here…

Now, that needs a bit of explanation. First, the columns represents blocks of four bits. That is, the very first thing in an IP datagram is a combination of four one’s and zero’s which identifies the version of IP that this datagram conforms to. (That’s vital: different versions of IP can use radically different and incompatible datagram formats. For example, IPv4, which this document discusses, uses 32 bits for addresses; IPv6 uses 128 bits. An IPv6 packet on an IPv4 network might have computers thinking that the second quarter of the source address was really the destination address, never even see the real destination address, and, in general, choke.)

So, some parts of the header of an IP datagram take up four bits, sometimes called a nybble. Others, like the protocol, take up eight bits. You know eight bits as a byte, the amount of information usually used to store a single character. Thirty-two bits, the amount devoted to the source and destination addresses, is commonly called a word. Each row in the chart above represents one word. An IP datagram header is six words long, or 192 bits. Even if you only have one bit of data to transmit, you’re going to need another 192 bits just to get it there.

All that said, here’s a description of the pieces.

Version

The version field, as mentioned above, identifies the version of IP that the datagram conforms to. That, in turn, specifies which fields are present, in what order, and how long they are. Different versions of IP can have radically different datagram formats.

IHL

That sixth word—the one with Options and Padding—is optional and often left out. The Internet Header Length field indicates the number of words in the datagram header. Most often, it will have a value of “0101,” meaning the header is five words long. (Recall that 101 binary equals 5 decimal.) If the header is six words long, the IHL field will be “0110.”

Type of Service

The TOS field is rather a controversial one. For the most part, it’s ignored, but it’s intended to be used to indicate the kind of data and its priority. The idea is that one value, for example, would indicate the datagram is part of an email note; another type would indicate it’s part of a real-time video broadcast. Video is much more time-sensitive than mail, so the video packet should get preferential treatment over the email packet. Various proposals have included means of charging more money to transport higher-priority packets. In practice…it’s only used in certain internal firewalls in a manner beyond the scope of this document to describe.

Total Length

Because you can have long packets and short packets, you need some way of knowing just how long this individual packet is. That’s the purpose of the Total Length field: it measures the number of bytes of data in the datagram. The longest possible IP datagram would have a Total Length field of “1111111111111111” and would be 65,536 bytes long—more than enough to store this entire document. More common would be “0000000000011100,” meaning the packet is 1500 bytes long, and you’d need a few dozen packets for this document.

Identification, Flags, and Fragmentation Offset

If you created an IP datagram that was 65,536 bytes long, it would be much too big to be carried over almost any kind of network in common use. Most networks can’t handle data packets (of any protocol) larger than a given size. Many networks which can handle large packets work faster with smaller ones. Therefore, it’s often necessary to break IP datagrams into fragments. The Post Office, for example, has a maximum size for a postcard; if you want to send a larger one, you could cut it in two, send both halves, and include instructions for putting it back together again. That’s the purpose of the second word of the datagram.

The Identification field has some sort of a unique number to identify the original packet. The Fragmentation Offset field specifies which fragment this is—that is, when you put the packet back together again, where it belongs in the overall order. The Flags field has information on, among other things, whether or not there are any more fragments after this one.

Time to Live

Because a packet might take a while to reach its destination, you need a way to say that it’s been too long and you’re not going to wait any more. The TTL field specifies the number of seconds the packet should be considered viable. Packets that are too old are silently discarded.

Protocol

The Protocol field specifies the IP Protocol of the packet. This will be the subject of the next major portion of this document, but the most common protocol—one you’ve probably heard of—is TCP, or Transmission Control Protocol.

Header Checksum

A bit of noise on a telephone line can flip a 1 into a 0 or vice-versa. That could have disastrous results; if you’ve got a fragmented packet, and the Flags bit that says there’re no more packets is flipped, you could lose all the rest of the pieces of the packet. The Header Checksum is a certain kind of mathematical distillation of the rest of the packet. If one (or, in most circumstances, more than one) bit in the header of the packet gets flipped, the calcualation of the checksum won’t match the value stored in this field. Therefore, the packet is corrupted and should be thrown out.

Source and Destination Addresses

Every computer on the Internet has a unique address. (That’s a gross lie, but it’ll greatly simplify explanations.) That address is a 32-bit number, meaning that there are a little over four billion possible IP addresses. (If you consider that the Earth’s population is over five billion and the next generation of toaster ovens and wristwatches are likely to have Internet connections, and you can see why the move to IPv6, with its 128-bit addresses—that’s more than 340,000,000,000,000,000,000,000,000,000,000,000,000 possibilities—is moving ahead.

Each address is broken up into four eight-bit parts which designate different parts of the network. The "address space"—the sum total of all the addresses—is broken up into networks. If the first three bytes of two IP addresses are the same, it’s probably reasonably safe to assume that the two computers are connected with only one or two pieces of wire.

The Source Address would be like the return address on your post card. The Destination address is where the packet should get delivered to.

Options

The Options field is rarely used, and there’s nothing defined as to what it should have. Somebody writing an IP program can decide to use it for anything imaginable…but not many people have imagined much of anything interesting.

Padding

The IP specifications say that the header of a datagram must be some multiple of 32 bits long. If the Options field isn’t a multiple of 32 bits, the Padding field has enough zeros to make a complete word.

Transport Layer

Remember the Protocol field of the IP datagram header? That’s the subject of this section.

Transmission Control Protocol

It’s okay if the Post Office loses a postcard if it’s one frame of a thirty-frames-per-second video stream—nobody’ll notice anything more than a nearly-imperceptible jerk in the motion—but it’s not okay if it loses one packet out of a dozen that makes up a crucial email note. More important, you need to know if that packet (postcard) is part of the video or email, and, if you’ve got multiple videos playing at the same time and are receiving multiple emails, which is which. That’s the job of TCP.

If the Protocol bit of the IP header says that this is a TCP packet, then the first six words of the data part of the IP datagram will be a TCP header. That is, you’ll have six words of IP header followed by six words of TCP header. Here’s what the TCP header looks like:

		<—Bits-->
		0	4	8	12	16	20	24	28
^ \| W o r d s \| v	1	Source Port				Destination Port				^ \| H e a d e r \| v
	2	Sequence Number
	3	Acknowledgment Number
	4	Offset	Reserved	Flags		Window
	5	Checksum				Urgent Pointer
	6	Options						Padding
		data begins here…

How It Works

I won’t analyze the fields the same way as with the IP header, but instead discuss TCP in action.

Let’s assume that a computer named Alice wants to communicate with another computer named Bob. Alice sends a TCP/IP packet to Bob with a particular bit in the Flags field set to one: the SYN bit, for “Synchronize Sequence Numbers.” This says that the number in the Sequence Number field is the first one used to ensure the proper order of the packets. The computers can start counting with any number they like; it’s the presence of the SYN bit that tells Bob that Alice is sarting with this particular number.

Bob gets the packet and sends a new packet back to Alice (remember, the IP datagram has Alice’s return address, which is what Bob uses) with his own first Sequence Number, the SYN bit set to one, and an Acknowledgment Number and the ACK bit also set to one. The Acknowledgment Number is the same as the last Sequence Number Bob recieved; it tells Alice that he got the packet okay. The ACK bit indicates that this packet is in response to one that Alice sent, and not the start of a new communication.

Up to this point, Alice and Bob haven’t said anything other than the TCP equivalent of “Hello.” Alice’s second packet, sent in response to Bob’s response, only has the ACK bit set and also contains the first actual bunch of data. From this point on, only the ACK bit will be set in both directions, and the Sequence (and corresponding Acknowledgment) Numbers will increase by one for each packet exchanged.

Of course, either Alice or Bob will likely have more to say. If Alice is very talkative and Bob doesn’t have much to say, he might only send one packet for every several that Alice sends. Bob still needs to send an occasional packet with an Acknowlegment number of one of Alice’s packets so that she knows that he got that one and all the preceeding ones. Bob doesn’t need to send one packet for every one that Alice sends, just one every once in a while. It’s rather like saying, “Uh-huh” every little while to let the other person know you’re still paying attention to them.

Alice and Bob might have a number of conversations all going on at the same time. For example, Alice might be requesting a number of different web pages from Bob, or Alice might be getting both mail and news from Bob at the same time. To help Alice and Bob keep things straight, they use port numbers. Different computers have different IP addresses; different connections on a single computer have different port numbers.

Any kind of communication can occur over any port number; however, there are certain conventions that are generally followed: Web page requests use port 80; mail uses port 25, and so on. These numbers will be discussed further in the Application Layer below.

Those well-known port numbers are used as the destination port in the original packet. For example, if Alice were requesting a Web page from Bob, her destination port would be 80. Bob, when he responds, will use port 80 as his source port. Just as Alice’s destination IP address becomes Bob’s source address, Alice’s destination port becomes Bob’s source port. Alice’s source port (and Bob’s destination port) will be some random large number. No other connection between Alice and Bob will use this same random large number, so it’s a way for the two of them to keep their separate conversations…well…separate.

There’s another field worth mentioning: the Window. It says how many more bytes the sender is willing to receive. A fast, powerful computer can easily overwhelm a small, slow one; Alice and Bob will only send as many packets as the other has said it’s okay to send.

If either Alice or Bob don’t get confirmation that a packet was sent—and remember that it’s the Acknowledgment Number field that does that—they’ll just re-send the missing packet.

User Datagram Protocol

TCP is great when you want to be certain that everything goes through in the right order, but there’re a lot of extra bits being thrown around. Sometimes, it’s not as important that everything comes through okay, or you might have some higher-level protocol (just as IP is a lower-level protocol) which will take care of all that stuff for you. UDP is about as simple a Transport Layer protocol as you’ll find. The first sixteen bits are the Source Port; the next sixteen the Destination Port, the next the Length of the packet, and the last a checksum. That’s it.

Other Protocols

There are a bunch of other protocols. ICMP, the Internet Control Message Protocol, is used for certain types of network maintenance tasks, such as “pinging” another host. Most of the others are proprietary ones used for special applications.

Application Layer

Up ’til now, all these different protocols have just allowed the computers to talk to each other—there hasn’t been any actual exchange of meaningful information. Now, the postcards have arrived at their destination, and it’s time to start actually reading them to see what they say.

Telnet

Telnet is perhaps the oldest and simplest of the Application Layer protocols. It permits remote login; that is, when you telnet to another computer, your keyboard and monitor act as if they were physically connected to the remote computer. Every keystroke is sent to the remote computer. The remote computer sends information back to be displayed the same way as if the monitor were directly attached.

Most commonly, the information being sent back to be displayed on the screen is formatted with yet another protocol, usually vt100. Digital Equipment Corporation made a very popular "dumb" terminal that would be directly connected to a mainframe computer. The mainframe would send a special sequence of characters that meant, for example, clear everything on the screen.

The originating, remote computer uses TCP port 23 for the destination port.

Electronic Mail

There are two popular protocols used for exchanging email, one for transfering the email around the ’Net, and the other for downloading received mail from an ISP’s mailbox.

SMTP

The Simple Mail Transport Protocol, SMTP (pronounced "simptee"), is used to route messages from one computer to another on the ’Net, in a manner similar to the Pony Express. Once the TCP/IP connection has been made, the computer sending the mail sends a series of well-defined commands and, eventually, the content of the message. Here’s an example session. Local commands are in italics.

[ben@glantz ben]$ telnet reiche 25
Trying 192.168.0.1…
Connected to reiche.trumpetpower.com.
Escape character is ’^]’.
220 reiche.trumpetpower.com ESMTP
helo glantz.trumpetpower.com
250 reiche.trumpetpower.com
mail from: ben@trumpetpower.com
250 ok
rcpt to: reynolds_john@yahoo.com
250 ok
data
354 go ahead
Subject: Greetings!

John,

I hope you don’t mind—I’m using you as a Guinea pig for my CIS105 class. To
demonstrate SMTP to them, I’m sending this message by telnetting to port 25.

Any plans for this weekend?

Yours,

b&
.
250 ok 974479932 qp 24768
quit
221 reiche.trumpetpower.com
Connection closed by foreign host.
[ben@glantz ben]$

My computer will then make a similar connection to some other computer—most likely mx1.mail.yahoo.com, but it could be any computer willing to relay mail—and carry out basically the same conversation. Eventually, the mail will get transferred to its final destination, where it will stay until the recipient reads and deletes it.

SMTP uses port TCP port 25.

POP

In the Olde Days, people would telnet to the computer that held the mail and read it there. Now, mail usually goes to a computer owned by the ISP. When you’re ready to read your mail, you tell your computer to make a Post Office Protocol (POP) connection to your ISP’s computer and download the mail so that some fancy program, like Eudora or Outlook or Netscape can display it for you. Here’s a POP session:

[ben@glantz ben]$ telnet miles 110
Trying 192.168.1.1…
Connected to miles.trumpetpower.com.
Escape character is ’^]’.
+OK
user ben
+OK
pass obkbe0LU3a0T
+OK
list
+OK
1 1452
.
retr 1
+OK
Received: from reiche.trumpetpower.com (reiche.trumpetpower.com [192.168.0.1])
        by miles.trumpetpower.com (8.10.1/8.10.1) with SMTP id eAHH3Bs03959
        for ; Fri, 17 Nov 2000 10:03:13 -0700 (MST)
Received: (qmail 24795 invoked by alias); 17 Nov 2000 17:03:08 -0000
Delivered-To: alias-trumpetpower-ben@trumpetpower.com
Received: (qmail 24792 invoked from network); 17 Nov 2000 17:03:08 -0000
Received: from web1405.mail.yahoo.com (128.11.23.169)
  by reiche.trumpetpower.com with SMTP; 17 Nov 2000 17:03:08 -0000
Received: (qmail 28165 invoked by uid 60001); 17 Nov 2000 17:05:06 -0000
Message-ID: <20001117170506.28164.qmail@web1405.mail.yahoo.com>
Received: from [63.110.34.78] by web1405.mail.yahoo.com; Fri, 17 Nov 2000 09:05:06 PST
Date: Fri, 17 Nov 2000 09:05:06 -0800 (PST)
From: John Reynolds 
Reply-To: Reynolds_John@yahoo.com
Subject: Re: Greetings!
To: ben@trumpetpower.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Here is the test back at you

—-  wrote:
> John,
>
> I hope you don’t mind—I’m using you as a Guinea pig for my CIS105
> class. To
> demonstrate SMTP to them, I’m sending this message by telnetting to
> port 25.
>
> Any plans for this weekend?
>
> Yours,
>
> b&


__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

.
dele 1
+OK
quit
+OK
Connection closed by foreign host.
[ben@glantz ben]$

As a side note, you can see six lines beginning with “Received.” Each time one computer accepts, via SMTP, a message from another computer, it puts its own postmark on the message in form of a Received: header. The header includes the sending and receiving computer, the date and time, and usually some sort of unique ID number. John’s reply to me went from one unidentified computer to a Yahoo computer to one of my computers to another unidentified computer to another unidentified computer to another of my computers.

POP originally used TCP port 109, but now has been standardized to TCP port 110.

FTP

The File Transfer Protocol, or FTP. is about as old as telnet. Being able to control a computer remotely is fine, but everything stays on that remote computer. FTP allows you to get files from the other comptuer to yours or vice-versa.

Unlike SMTP and POP, people regularly use FTP directly. Here’s an FTP session.

[ben@glantz ben]$ ftp reiche
Connected to reiche.trumpetpower.com.
220 ftp.trumpetpower.com FTP server (Version wu-2.6.0(1) Thu Jun 29 02:42:43 EDT 2000) ready.
Name (reiche:ben): ben
331 Password required for ben.
Password:
230 User ben logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for directory listing.
total 90472
-rw-r—r—   1 root     root      5480244 Jan 25  2000 CIS133DA-fall-1999.tgz
-rw———-   1 500      500          2678 Mar 19  2000 Mailbox
-rw-r—r—   1 500      500         20672 Oct 12  1999 Mailbox-cis133da
-rw-r—r—   1 500      500          1389 Oct 12  1999 Mailbox-cis133da7060
-rw-r—r—   1 500      500         21339 Apr  1  2000 Mailboxes.tgz
-rw-r—r—   1 500      500      38573165 Mar 31  2000 NEW.tgz
-rw-rw-r—   1 500      500           933 Sep 25 09:57 Students
-rw-r—r—   1 500      500          1127 Oct  5 17:27 a2grade.txt
-rw-r—r—   1 100      238           456 Oct 17 16:47 a5gradesummary.txt
-rw-r—r—   1 100      238           408 Oct 17 16:47 a6gradesummary.txt
drwxrwxr-x   2 500      500          1024 Nov  5 09:51 a7v
-rw-r—r—   1 500      500        385024 Nov  1 10:56 addressbook.mdb
drwxrwxr-x   2 500      500          1024 Jun  8  2000 archive
drwxrwxr-x   2 500      500          1024 Nov 15 18:23 bin
-rw-r—r—   1 root     root        56832 Dec 17  1999 carolina.doc
-rw-rw-r—   1 500      500       1474560 Aug 24  2000 floppy27.fs
-rw-r—r—   1 root     root        99328 Dec 17  1999 franklin.doc
drwx———   2 500      500          1024 Oct 13  1999 mail
-rw-rw-r—   1 500      500             0 Sep 20 15:48 minicom-1.82.1-1.i386.rpm
drwxrwxr-x   7 500      500          1024 Sep 25 09:38 projects
drwxr-xr-x   8 500      500          1024 Jul  9  2000 public_html
-rwxr-xr-x   1 root     root          379 Apr  4  2000 qmail
drwxrwxr-x   2 500      500          1024 Apr 17  2000 taxes
226 Transfer complete.
ftp> get a2grade.txt
local: a2grade.txt remote: a2grade.txt
200 PORT command successful.
150 Opening BINARY mode data connection for a2grade.txt (1127 bytes).
226 Transfer complete.
1127 bytes received in 0.0416 secs (26 Kbytes/sec)
ftp> put message.asc
local: message.asc remote: message.asc
200 PORT command successful.
150 Opening BINARY mode data connection for message.asc.
226 Transfer complete.
1669 bytes sent in 0.0126 secs (1.3e+02 Kbytes/sec)
ftp> quit
221-You have transferred 2796 bytes in 2 files.
221-Total traffic for this session was 3526 bytes in 2 transfers.
221-Thank you for using the FTP service on ftp.trumpetpower.com.
221 Goodbye.
[ben@glantz ben]$

First, I got a listing of the files on the remote computer; next, I copied a2grade.txt from the remote computer to the local computer; and, finally, I copied message.asc in the opposite direction.

FTP is a bit of a peculiar protocol: it uses TCP port 20 for all of the commands, but TCP port 21 for all of the data transfers. Behind the scenes, my computer issued a command on port 20 to tell the other computer which source port it planned to use for the data connections. Most people regard this as a flaw in the protocol, but it still is used widely.

NNTP

The Network News Transfer Protocol is used to transfer Usenet news across the ’Net. By now you can imagine what the protocol itself looks like, but you might not have any idea of what Usenet news is.

Usenet news was once described as “The Mother of All Bulletin Boards.” Not surprisingly, this discussion came around the time of the Gulf War. There are currently tens of thousands of discussion groups on Usenet.

Somebody with an interest in, say, the computer language PostScript, might use newsreader software—the software will look much like mail software—to post a message to the comp.languages.postscript newsgroup. The newsreader software will make an NNTP connection to that person’s ISP’s news server. That server will save a copy of the message, marked as belonging to comp.languages.postscript, and send a copy of the message to at least one other ISP’s news server. That other news server will, in turn, save a copy and send copies out to one or more news servers until, eventually, every news server on the ’Net has a copy of the person’s message.

To read a message, your newsreader software will ask your ISP for a list of newsgroups. You’ll then pick a newsgroup to read; your newsreader software will ask your ISP for a list of the messages in that group. You’ll then pick a message to read, and your newsreader software will ask your ISP for a copy of that one message. You can then choose to reply, in which case your message will get propogated throughout the ’Net in the same way as the original.

NNTP has mechanisms for restricting who can submit messages to a group, but they’re not widely used. Generally, anybody can read any and all messages posted to Usenet, but not all ISPs choose to carry all newsgroups. Especially, some ISPs and businesses choose to not carry the pornography-related newsgroups.

There is an organization to newsgroups: computer-related groups start with comp; science-realted groups with sci; recreation-related groups with rec; and so on. Within each top-level group, there will be a number of sub-groups. Computer languages are discussed in comp.language; opera is discussed in rec.arts.opera. The largest top-level group is alt, which is a veritable free-for-all. Very little self-regulation or moderation takes place in alt groups.

NNTP servers use port 119.

HTTP

The World Wide Web uses the Hypertext Transfer Protocol to get documents from one computer to another. HTTP superficially resembles FTP, but the connection part of the protocol is greatly streamlined. Especially, there’s no need for usernames and passwords.

HTTP usually uses port 80, but it’s not uncommon for certain Web servers to use port 8000, port 8080, or some other port.

HTTPS

Communications on the ’Net are about as private and confidential as postcards. Less so, actually, as postcards spend most of their time in the Post Office’s hands, where stiff Federal legislation protects them; there’s no comparable legislation for the ’Net, and the people who maintain the ’Net are not Federal employeed.

The mathematical branch of encryption can come to the rescue, however. HTTPS works exactly the same was as HTTP, but, first, the two computers agree on a way to encrypt the information so that nobody else can understand what they’re saying to each other. The manner in which that encryption happens is beyond the scope of this document.

HTTPS communications usually use port 443.

DNS

The Domain Name System is responsible for turning computer names, such as www.trumpetpower.com, into IP addresses, such as 204.181.17.250. When you tell your computer to connect to www.trumpetpower.com, your computer first asks your ISP’s DNS server for the matching IP address. After all, the IP header just has room for IP addresses, not numan-readable names. Your ISP’s DNS server, if it doesn’t already know the answer, will in turn ask one of the root DNS servers for information about www.trumpetpower.com. The root DNS server will tell your ISP that it needs to get the information from either ns.fastq.com or ns2.fastq.com, and provide your ISP with their IP addresses. Your ISP’s DNS server next asks one or the other of those computers for the IP address, and, finally, gets a response. Your ISP’s DNS server sends the answer back to your computer, which then is able to make the connection.

The root DNS servers for .com, .net, and .org domains are run by a company called Network Solutions. A consortium of educational institutions run the root DNS servers for .edu domains; the Federal government and U.S. military run the .gov and .edu root DNS servers, respectively. Root servers for other countries are run by their governments or corporations designated by those governments.

Network administrators might occasionally make inquiries directly to the DNS network. Here’s what such a session might look like.

[ben@glantz ben]$ nslookup
Default Server:  miles.trumpetpower.com
Address:  192.168.1.1

> set q=any
> www.mc.maricopa.edu
Server:  miles.trumpetpower.com
Address:  192.168.1.1

Non-authoritative answer:
www.mc.maricopa.edu     canonical name = mcweb.mc.maricopa.edu

Authoritative answers can be found from:
maricopa.edu    nameserver = names.maricopa.edu
maricopa.edu    nameserver = fdurt1.fdu.edu
names.maricopa.edu      internet address = 140.198.8.15
fdurt1.fdu.edu  internet address = 132.238.1.200
> server names.maricopa.edu
Default Server:  names.maricopa.edu
Address:  140.198.8.15

> www.mc.maricopa.edu
Server:  names.maricopa.edu
Address:  140.198.8.15

www.mc.maricopa.edu     canonical name = mcweb.mc.maricopa.edu
maricopa.edu    nameserver = names.maricopa.edu
maricopa.edu    nameserver = fdurt1.fdu.edu
names.maricopa.edu      internet address = 140.198.8.15
fdurt1.fdu.edu  internet address = 132.238.1.200
> mcweb.mc.maricopa.edu
Server:  names.maricopa.edu
Address:  140.198.8.15

mcweb.mc.maricopa.edu   internet address = 140.198.64.46
maricopa.edu    nameserver = names.maricopa.edu
maricopa.edu    nameserver = fdurt1.fdu.edu
names.maricopa.edu      internet address = 140.198.8.15
fdurt1.fdu.edu  internet address = 132.238.1.200
> exit
[ben@glantz ben]$

Therefore, www.mc.maricopa.edu is really a nickname for mcweb.mc.maricopa.edu; the IP address of mcweb.mc.maricopa.edu is 140.198.64.46.

DNS queries use either TCP port 53 or UDP port 53.

Other protocols

There are lots and lots and lots of other Application Layer protocols. One, in fact, for each kind of communication that goes over the ’Net. There are protocols for different kinds of real-time chat; there are ones for broadcast of video; just as there’s an encrypted version of HTTP, there’s SSH, an encrypted version of telnet and SFTP, an encrypted version of FTP. There are obscure protocols that hardly ever uses, and others, like Gopher, which once were popular but which now are all but abandoned. New protocols are also always being developed. Some will become popular, and others will never see the light of day.

Site Map