Precise Networking's

THE INTERNET...
HOW IT REALLY WORKS

By
DAwn McGatney And Dog Wolf!^©

Dr. Steve Goldbloom, Technical Consultant

This Web page contains no artificial ingredients...
It is 100% pure old-fashioned hand-crafted HTML.

Last Updated 29 January 2006

Introduction

There is no mistaking it.
Dog Wolf is grumpy this night, and yet he insists on having a go at the PC. The weather, hot and cold, hot and cold, and then rainy, is really irritating his arthritis, despite the mash of aspirin and beta carotene we add to his daily Mighty Dog. But on this damp night, this wet and yet dry night, dog Wolf has determined that he shall write this page, in its entirety, in one sitting; a page in which he shall reveal "How The Internet REALLY Works."
"Wolf, have you a clue as to just how many introductions to the Internet for bozos are out there, many of them very fine in fact? C'mon... let's just place a link to some willing site and be done with it."
Dog Wolf is silent for a long time. And when finally he speaks, his every word is a carefully measured frown, his patience at a minimum this night... His intellect editing every thought before he speaks it... "The others to whom you make reference... the others treat the Internet as something incredibly complicated, sonething that needs to be mashed down into pabulum. I on the other hand shall show that the Internet is inherently logical and elegant; and above all, that it is easily understood by ANY intelligent Netizen. And I shall show that the Net requires no reduction to pabulum, no reduction to absurdity.
"I want to explain to folks how and why the Internet REALLY got started, and how it REALLY works... no pabulum for the masses." Meat for the intelligent Netizen.
And so what follows here is the Internet according to our dog Wolf (who looks nothing at all like a wolf, save perhaps for his white eyes... and his penchant for howling at the most inappropriate of times)...

Thank you. First, for ever after, we'll just call the Internet the Net... too much to type otherwise. Now, looking at the Net is kinda like looking under the hood of your car... seems like a jumble of belts and hoses and pipes and wires and things of no name. But really, it's a few necessary things; simple things... an air conditioner, a battery, etc.
The big bad Net also is a just a collection of small, simple things... simpler than air conditioners or power steering motors or engines. But so much is mashed together under one heading, "The Net" (Why, it even was a movie displaying Sandra Bullock in a bikini, if you would believe), that we now have created a huge bowl of confusing mish-mash. Like my breakfast, when DAwn mish-mashes in aspirin and whatever, thinking I'm unaware.
So as I told DAwn, what I write for you this night is intended neither for dummies nor for bozos. This Bud's for you, the intelligent Netizen... seeking networking solutions... wanting to learn the Internet.
This is not everything you might need to know or might want to know... but these are the essentials that *I* think you should know... The things that you, the intelligent Netizen, really should know about the Net. The real Net, and how the real Net really works. Really works... the key words.
And no spoon feeding... it's already simple stuff, and I kid you not. (Does dog Wolf ever kid?) IT'S EASY STUFF. We're not launching a rocket here or attempting to decipher the internal revenue code unraveling the secrets of the universe or making spaghetti or trying (unsuccessfully) to talk a police officer out a speeding ticket (as Dr. DAwn unsuccessfully attempted recently... "I have to see a kid with a really bad nosebleed" just didn't hack it, did it DAwn?)
But enough of my chatter... let's begin... this is very cool stuff. (If you find the text size too small for your liking, simply go to the view menu on your browser, select text size, and crank it to 120% (or higher). OR, more simply, if your browser permits, use cntl+[ (that is, press the Ctrl button and the [ button (or the ] button) on your keyboard both at the same time... some browsers permit this, others require you to go to the VIEW menu at the top of the screen.
And if you're ever confused by a term, press the NET GLOSSARY button at the top of this page. In fact, use the Net glossary frequently. It's cool. (It should be cool, I wrote it.)

The History Of The Net

Ok, the Net. No one owns it. No one edits it. There are no rules governing its shape. To understand it, you've gotta know where it came from and why. So... where DID it come from?
Back in the early '60s, it was springtime for computers... they were just beginning to bloom. And at first, computers exchanged information with each other by 80 byte punch cards... boxes and boxes of punch cards ("IBM cards"), carried about in long card carriers; and then, by big reels of tape. And this was cool, if you didn't need to communicate with another computer 3,000 miles away (except that sometimes you did); and if no one ever dropped the punch cards (except that sometimes they did); and if the tape didn't get all jammed up on the tape drive or placed near a magnet (except that sometimes it did).
Folks soon came up with a bright idea... Let's connect our computers together with wires... telephone wires, wires in the walls and ceilings and floors, whatever. So they did, and it worked; and these computers, now networked together by wires, were called a network of computers... a computer network... or just a network. (Lower case "n" because it's a LITTLE NETWORK.) Since we rarely connect more than a few thousand computers together in a network, we call these networks "little networks."
Now, imagine a fish net. Imagine that we place coloured knots at some of the points where the cords intersect (nodes). What do we notice? Fish? Ok... What else? That we can get from one knot (or node) to another by more than one path along the cords. And on a computer net, we often can get from computer A to computer B by more than one path.
And this is all that we mean when we say we've connected computers into a network. Folks do it today in homes and offices and call the little networks "local area networks" or LANS.
Anyway, back to the past. Now when an organization had several computers, computer A could send data files to computer B. And people at Computer C could talk to people at computer ZZ, all just by typing on their keyboard. Worked pretty well, actually.
So first we had lonely, isolated computers; and then they were connected together with wires into networks; and they could converse with each other. They could exchange files, exchange data. In the '60s, you began to see lots of computer networks springing up. (I mean, like it was a cool idea, after all... lots of networks, lots of different kinds of networks.)
And almost every network had its own set of rules that stated how its computers communicated... its own PROTOCOLS... its own agreed upon standards... some rules explaining just how any two computers on the network could exchange data. (Like, in the US, driving on the right side of the road is part of the "driving protocol." So is not exceeding the speed limit. DAwn? Listening?)
The '60s were surely a time for dreaming; we thought we could do almost anything back in those days... lots of computers were connected together into little networks. Lots and lots of different protocols for these little networks. Usually, the hardware and the software that allowed computers to connect in a network worked only for one vendor's computers. And the little networks weren't flexible enough so that you could connect the computers on two different little networks together simply and cheaply.

The problem of connecting these little computer networks together was eventually solved by 1.) a thing called TCP/IP... and 2.) a special little piece of hardware required by TCP/IP called a ROUTER. (Usually it's pronounced "RAL-ter," though we've heard "ROO-ter" from some very knowledgeable folks.) A router routes data through a network. Much more on this coming... just wanted to get your toes wet here.

Suddenly, some bright folks realized that it would be intensely cool if they could find some way to connect all the different little networks TOGETHER... if they could find some way to connect all the different protocols together... if a computer on the little network at Aardvark, Inc in Key West, FL, could talk to a computer on the little network at Gerbil, LTD in Essex, UK... if they could chat and exchange data.
But this was not going to be easy... it was exactly like making all the train tracks in the US the same size, so that any train or car or whatever that had just the right size wheels could go anywhere the tracks went.
Yet the idea was intensely cool... because instead of 2 or 10 or 100 computers exchanging data on some little network, we could have 10,000 or 100,000 computers all capable of exchanging data and talking to one other, computers all over the world.
(But oh boy... little did they dream of what they were starting... no one had a clue about spamming or EBAY or annoying Pop-Ups or "Make Money Fast" or viruses or hackers... computers were big and manly and expensive and robust machines in these early days 35 years ago... used only by universities and scientific installations and big businesses and such... the PC still lay 15 years future-ward, just a dream of "Someday, a computer will be so small that it'll fit on your desktop." <Insert Laughter Here>).
The dream of interconnecting different little networks, of connecting networks speaking with different protocols, was dubbed (guess...)--> INTER-NETWORKING. (Why does that word sound vaguely familiar?) But the name makes sense, yes? Yes.

Now, guess who really became interested in inter-networking? Hackers? Nah. It was the US Defense Department (the DOD). And the DOD had an additional special requirement for inter-networking. Because back in the '60s, nuke-phobia stalked the land.
So, not only was the US Defense Department interested in getting many of the separate little networks inter-connected, it wanted at least a part of the inter-connected little networks to be able to survive a nuking. This is a very important fact, because it shaped the way the Net works today, 35 years later.
And it wasn't an altogether bad idea; it's nice to have a giant inter-network that still keeps working when some of its pieces break down. The DOD wanted an inter-network that was so distributed and so de-centralized that even a nuking would leave at least some of it still running.

REALITY CHECK...
And so runs the folklore. The FACT is that even in the US itself, there's NOT as much redundant cabling for the Net as many folks think. Like in the autumn of 1996, most of Minnesota was Net-less for much of a day, because a backhoe snagged ONE cable. Back in 2001, parts of Maryland were disconnected from the Net when a train caught fire in a tunnel in Baltimore.
Outside of the US, things are more fragile... low capacity cables (low compared to Internet requirements) barely connect many trans-oceanic sites. Things will improve a bit if we ever have zillions of low-orbiting satellites, originally planned for 2006. But as for now, after a catastrophe, a lot of the Net will be inoperable. And a lot will still work.
But anyway, the DOD's heart was in the right place, and the survivability requirement did make the Net cooler... Nuke-proof, at least in theory. And best of all, it did dictate the Net's design. And THAT is important. Because the US DOD wanted the Net to be nuke-proof, its design became truly elegant, a thing of beauty.
Because now, the Net regards any attempt to block or censor its content as if part of the Network had been nuked out; and it does its best to route its packets around the area of censorship.

Thanks to prodding by the US Defense Department, a group called ARPA (the Advanced Research Projects Agency... later renamed DARPA) began prodding folks (by giving them $$$) to come up with STANDARDS for hardware and software so that computers on different little networks speaking in different protocols could speak to each other. ARPA wanted to join the "little" networks all over the world that were used for scientific stuff into one big inter-network.
And so, in the late '60s, ARPA began a parternship with US universities and other research organizations to investigate new networking technologies that would allow connecting the little networks.
Ultimately, the thing that ARPA (and the folks it was giving $$$ to) came up with... the thing that would allow all the little nets to combine into one big Net... was TCP/IP, a magic box brimming with new protocols. Ultimately, the tie that bound the "little networks" into "THE NET" would be TCP/IP. But not just yet.
Again, it was like... Gee, if all the train tracks in the US were the same size, any train that could run on one rail line could run on all of them. And we could then drive a train between any two points that had tracks.
In 1969, there was an experimental inter-network operating with three computers in California and one in Utah... four computers. By 1971, our Network of Networks really began to take shape. Was it called "The Net?" Nah... it was called ARPAnet. (Some ego thing here, I suspect)
ARPAnet was the first experimental inter-network, the first Network of Networks, funded by the US government. They wanted it to be nuke resistant. And they also wanted it to be easy to add and remove new computers from the ARPAnet. (Thank goodness for that requirement.) And they wanted lots of different types of computers from lots of different vendors to be able to talk on the ARPAnet.
Unfortunately, the early ARPAnet was slooow as a slug in Hunt Valley in January of 2006; plus it was subject to frequent "crashes." (As is DAwn.)
But the cool thing about the young and growing ARPAnet was that a dog on one little network could now connect to a dog on a totally different little network. And then they could then exchange programs. Or pictures. Or whatever.
(No, they didn't ask for age, sex, and location as AOLers do today; these were scientific, university-based dogs; and they were quite serious... ARPAnet was a wonderful tool for their work, and for their research... they didn't want to muck it up by getting TOSsed :) )
But the ARPAnet, though it did work, was not yet exactly the dog's bark. And so ARPA gave folks more $$$, especially a bunch of people interested in this thing called TCP/IP. (TCP/IP stands for Transmission Control Protocol/ Internet Protocol... WHEW).
And so, with more $$$ for research, by 1974, Vinnie Cerf and Bobbie Kahn proposed a new set of protocols for the ARPAnet. The Cerf/Kahn design became the basis for TCP/IP. (We should have a world-wide holiday on their birthdays, you say?)

TIMELINE #1...

1969... BBN installs the beginning of ARPANet at UCLA.
1971... ARPANET in regular service, but it's slow and unstable.
1973... TCP/IP first proposed.
1974... Cerf and Kahn present their paper on TCP/IP protocols.
1975... 100 little nets World-Wide are now inter-connected on ARPAnet.

Ok, just a quick REVIEW... because this is IMPORTANT stuff...
A computer network is just a bunch of computers connected together by wires into a "little net." (Yes, today we can connect computers together by satellites and by radio waves, etc; but way back then, folks happily stuck to wires.) And "THE NET" is a bunch of little networks connected together... allowing zillions of computers all over the world to speak to each other. And the little networks speak to each other in the TCP/IP language.
Little network at Yale <-----> TCP/IP <-----> Little Network at Harvard.
The little networks belong to businesses, universities, governments, individuals, ISPs, bulletin boards, whatever... all over the world.
Now... In the late '60s, the US Department Of Defense built ARPAnet in an attempt to connect the little networks of (mostly military) computers, in such a way that some could continue to talk to each other if others got knocked out of service.

Ok, end of review. Moving right along...
We're in the early '70s now, and TCP/IP is about to become the foundation that makes it possible to connect millions of computers worldwide on the Net of Nets... So--> ARPANET + TCP/IP = THE NET. Tada #1.
(Notice how we keep approaching TCP/IP and backing away from it? Like getting into a cool pool of water on a hot, sunny day. Gradually is how we do it. Eventually, the water starts to feel good.)
Now pay attention, because this is the most important thing I have to say on this page. TCP/IP is very very closely linked with the Net. You cannot understand the Net without understanding TCP/IP.
TCP/IP is the super-glue that makes all the little networks look like one big network, THE NET. Oh sure, when the little networks are chatting among themselves, they can use whatever protocol they like, maybe 48-bit Ethernet, maybe IPX, maybe Swahili, maybe AOLian, who knows? (Who cares?) Roll-yer-own is fine... on the little nets.
BUT... when you want to send data onto THE NETWORK OF NETWORKS (THE NET), when you want to sent data BETWEEN two little networks, you WILL use the TCP/IP protocolS. (PLURAL... Protocols... it's a box full of them, recall?)

REALITY CHECK... Forward to the present (2006) for a moment. Where is that box of TCP/IP protocols today, where is it when we connect our PC to the Net through some ISP like Earthlink or MSN or AOL to read gems like this page of mine?
OK... Let's say we want to access the Net from our PC. Running Windows on our PC are we? We'd better have that box brimming with TCP/IP protocols handy... maybe we should even have some little program for each TCP/IP protocol, some little program module. Do you know what a WINSOCK really is? A Tasmanian marsupial, you say?
Close. A winsock is just the box full of TCP/IP protocols. It runs on our PCs, and it converts Windows-speak to TCP/IP-speak for stuff going out onto the Net (and back again for stuff coming in).
(Prior to Windows 95, you had to add your own winsock; Trumpet Winsock was a very popular winsock program... and well it should have been, it came from Australia. (Did you know that most of Australia's imports come from overseas? Keppel Enderberry even said so... no, don't ask.) But.. starting with Windows 95 (the NET was starting to become hot in 1995 among the general public) and thereafter, the winsock program(s) has/have been included with Windows.)
We connect our winsock program running on our PC (through our modem, through some ISP) to the Net. Then, when some client program on our PC like Netscape wants a page from my Web site, it simply tells the winsock what it wants, using the "Windows-speak" language.
Our PC's winsock program translates Windows-speak to TCP/IP-SPEAK, and it passes along our browser's request to some distant Web server that holds my Web pages. The server then (almost always) returns the page which our browser has requested to our PC and to our winsock... where it gets converted back again to Windows-speak and displayed on our monitor.
And this is why we can do wonderful things with our browsers, like opening windows and having colors and clicking on things. (No, it's not rocket science; I told you this stuff was simple.)
Netscape <---> Winsock <---> Modem <---> Phone line <---> ISP <---> The Net
Windows-speak ......>| TCP/IP-speak.........................>

Now back to the past. The one thing that finally made the Net happen happened. The Defense Communications Agency got into the act. (There are a LOT of agencies, no? YES. Trying to follow these agencies is FAR more complicated than understanding TCP/IP and the Net that they ultimately gave birth to.) The Defense Communications Agency laid down the law in no uncertain terms...
You wanna hook up your little net to the ARPAnet network of networks? Well, after January 1983, you have to be using the TCP/IP protocols to connect; and ONLY TCP/IP.

TIMELINE #2...

1980... ARPANET begins converting to TCP/IP.
1982... A standardized version of TCP/IP is adopted.
1983... Berkeley releases a UNIX with TCP/IP; it's very popular.
1983... US Defense Department adopts TCP/IP as its standard.
1983... Now all connections to ARPANET MUST be TCP/IP.
1983... ARPANET now has more than 300 host computers.
1984... Military stuff removed from ARPAnet.
1985... National Science Foundatation creates a separate network to link University supercomputers... it's called "the NSF backbone."

This mandate of the Defense Communications Agency transformed the ARPAnet into the mother of today's Net. And through the '80s, the ARPAnet grew, connecting many BIG computers. If you were anybody in academia, your computers now connected to the ARPAnet. And in the '80s, if you connected to the ARPAnet using TCP/IP, well cool... welcome to THE NET; you've just joined the world's biggest club.
What was so intensely elegant about TCP/IP? It could (and still can) glue lots of little networks together into one large network, THE NET. And to any user, THE NET appeared to be one single network, composed of ALL the hosts on all the little networks. From the perspective of THE NET, every computer on every little net was equal.
AND... TCP/IP was independent of what kind of computers it was connecting, and what kind of software they were running. TCP/IP was a robust, manly set of protocols... able to survive high network error rates... able to leap around tall network problems in a single bound.
And as a reward, the ARPANET got retired. By 1990, like some old rusted railroad tracks, ARPAnet was retired... obsolete it was, they said.
Why was the ARPAnet retired? Glad you asked. In 1985, the National Science Foundation wanted to connect a few "Super" Computers. (Super computers were computers that cost a lot of money.) While at first it seemed that the ARPAnet could be used to connect the Super Computers, it soon became apparent that the now 15 year old ARPAnet had some technical problems. (And there were also some political considerations; but as an Aussie, I try to stay out of US politics and political considerations.)
And so the NSF, never one to dawdle, started building a new "backbone" to connect its Super Computers. (A backbone is a very fast data line with very fast router switches on it.) The new NSF backbone was young and sexy, and folks liked it better than the aging ARPAnet. Every dog has his day. But the same TCP/IP that was by now standard on ARPAnet remained.
So... what did the NSF build? Would you believe NSFNET? NSFNET, with the TCP/IP protocols that it "borrowed" from ARPAnet, now became VERY popular... it was soon connecting together all kinds of computers. By 1987, NSFNET was so busy, the NSF backbone got an enhancement, a face-lift.
And what did we see when the face-lift bandages were removed? It was (tada #2) THE NET!

ROUGHLY...
ARPAnet --> ARPAnet + TCP/IP --> NSFNET -->

SEVEN COMPANIES --> TODAY'S NET.

And yes... finally, back in the '90s, The Net opened its doors to home users. Many companies (called ISPs... Internet Service Providers) began offering Net access to individuals... individuals with dial-in modems. Now, anyone with a PC and a WINSOCK and a MODEM and an ISP could connect to the Net.

TIMELINE #3...

1990... ARPAnet declared obsolete and phased out; NSF backbone replaces it.
1991... The Net begins accepting commercial traffic.
1995... NSF shuts down its backbone; THE NET backbone is now run by private companies.
1996... THE NET now consists of 100,000 interconnected little nets.

So fast did the Net grow that in 1995, the NSF shut down NSFNET. The job of providing a backbone service (in the US) was given to seven companies (some of which are still solvent and have not declared bankruptcy)...

ANS

AGIS

BBN

MCI

PSINet

SPRINT

UUNet

So what exactly was this Net (Capital "N") supposed to be able do? I mean, yeah, it connected all the little networks... but what specifically? Well, at a minimum, folks decided that it would be intensely cool if THE NET could...

Send mail between individual computers. (E-MAIL, yeah.)
Transfer files (pictures, programs, whatever) between computers. (Uh, huh... FTP.)
And third, allow my local terminal to logon to some remote host computer and execute commands. (Ah... TELNET.)

Now, computers on the Net that provide some service for others are called HOSTS... host computers.
So like, maybe a host has files it'll let people "download." Napster ran a bunch of hosts that let folks download songs (until the record companies decided that this was less than expedient for them).
(Whenever you copy a file from some computer out on the Net to your PC, you're downloading.) In the early '80s, there were about 200 hosts... 200 computers on the Net that performed services for other computers, for other folks.
But no one dreamed that just 15 years later, there would be millions of hosts on the Net, connected all around the world. And the one thing that made the Net grow so very fast was that, in the early '90s, it was agreed to allow commercial traffic on the Net. (But you already knew that.)
Servers, Workstations, Minicomputers, Mainframes... all could run TCP/IP... and all could be hosts. And so could PCs... and that's the second thing that has caused the traffic on the Net to balloon.
Remember... in the early '80s, PCs were but toys for playing games; no one worried about connecting PCs to The Net. The computers on The Net were mainframes, or at least big mini-frames... manly and robust computers. No matter that today's desktops are faster and have far more RAM (real memory) and disk space than many of these giants that filled rooms (and budgets).
The secret of how PCs became servers on the Net? By using just one additional protocol, named PPP (which was also included in that Tasmanian marsupial, the winsock), by the '90s even lowly PCs dialing into the Net on an ordinary phone line through a modem could be hosts. Oh, and look... the PCs aren't just toys anymore (though they're still fine for playing games).
And so in the '90s, businesses took over the Net from ARPA and NSF. And PCs with modems proliferated.

A QUICK REVIEW AND QUICKER PREVIEW...
The Net evolved over the past 35 years. The Net was initiated by the US Department Of Defense; then Universities got involved; then businesses got involved. And finally, folks with PCs in their homes and offices got involved in The Net. What is the Net?
The Net is a combination of software (TCP/IP) and hardware (routers) that today (2006) allows exchanging files and communicating (e.g., real-time chatting) between millions of computers.
All the computers on the Net speak to each other in the same language... TCP/IP. And every computer on the Net, from my lowly Dell (sorry Michael) to the giant super-computers at the US atomic energy labs... they all have a unique Net "phone number" called an "IP address." (Yeah, a hint of what is to follow.)
And so today, using the Net, I can send and receive information on quantum mechanics to a delightful beagle at the Oakland "Dark Matter" government facility. (And I even sent her my photo, just to impress the lady a bit. (Ok, so it was taken a few years back, whatever.) ) And sometimes, my beagle luv lets me log onto her massive computer from my humble Dell; like when I have lots of nonlinear 5th-order differential equations to solve.
So the Net was developed to let computers of every breed chat. And it does... it actually works (we'll see how in just a moment). Oh, but there's even MORE...
Not only can I, from my lowly PC, talk to my beagle luv's computer... I can also can talk to Meg Beagle (not her real name) directly. Because if you're connected to the Net, as my PC here is, you can exchange letters (e-mail) with ANYONE who has an account at ANY computer connected to the Net. Cool. (Yeah, more hints of what is to follow.)
END OF REVIEW AND PREVIEW.

Now, all this good Net-stuff was in place ten years ago, but it didn't attract much attention outside of geekdom... until a bright fellow in a lab in Europe came up with a wonderful idea... the WORLD WIDE WEB.
His idea was simple. Certain host computers, called "Web Servers" would store documents, called "Pages." And anyone with a special program on their computer, called a "BROWSER", could then ask for and retrieve a page from one of these Web servers out there on the Net.
Today, Internet Explorer and Netscape are the most popular browser programs. (Can you imagine all the great stuff that dog Wolf will soon be delving into?)
But this World Wide Web ("WWW") thing (now usually just called the "Web", and even called by some "The Net" (as in, "I'll be in there in a minute, honey; I'm surfing the Net") ) gets better and better. Because the page you retrieve from a Web server can have LINKS on it... click on a link with your mouse and you'll get another page... maybe a page from a different Web server a zillion miles distant from the first.
Thus, on the Web, you could go from page to page, getting information or pictures or even music and sounds and movies... spreading out, all over the known world... just like... a Web. (See the four buttons at the top of this page? Each is really a link. You press the button, you retrieve a new page. (These are surely exciting times in which to live.) )
So what? So this... The Web made the Net easy for everyone to use. And easy to use means POPULAR. Commercial enterprises took note and began offering access to the Net for PCs, for the masses; these businesses allowed PCs to connect through a modem to the Net. No longer did you have to be a beagle at some huge government facility to access the Net.
Businesses that allow you to connect to them through a modem (dialup or cable) and then connect you to the Net are called "Internet Service Providers" (ISPs). Earthlink and Comcast and MSN are three examples of ISPs.

SO WE HAVE...
BUSINESSES NOW OPERATING THE NET ITSELF AND ALLOWING COMMERCIAL TRAFFIC +
PCs WITH TCP/IP AND MODEMS NOW CONNECTING TO THE NET +
THE EASY-TO-USE WEB =
THE INTERNET POPULARITY EXPLOSION OF THE 21st CENTURY.

And that's how we got here.
And now that we know where The Net came from, it's now time at last for us to examine how this wonderful Net thing REALLY works... because it really does work magically well... and that means TCP/IP. (The water in the pool really feels great now, yes? Yes.)

The Net Works

Back to the '70s again for just a moment... to the days when TCP/IP was first being developed.
In order for inter-networking to work, in order to solve this big conundrum of how to connect little networks to one another, folks knew that they needed to resolve three problems...

How could one computer specify exactly which other computer it wanted to communicate with, so that it could send e-mail to it, or so that it could get a file from it?
Why was this such a problem? Because every "little network" had its own little way of referring to its own computers. One little network might refer to it's computers as Charlie, Dena, Seymour, etc. Another little network might call it's computers #1, #2, #3, etc.
Officially, the problem was called ADDRESSING... just like you need to put something in some standard format on the front of an envelope for it to end up where you'd like after you drop it in the mailbox; the stamp alone won't cut it, not without that envelope address in some standard format.
In the '50s, when The Bell Telephone Company (remember them?) wanted to let folks dial their own long distance calls, they had the very same "Addressing" problem. How could folks using the Eureka, California, phone system make a call to the New York City phone system, when Eureka had only 5-digit phone numbers and NY City had 7-digit phone numbers? There was simply no standard.
The answer ended up being--> Everybody gets a 3-digit area code (at least until the year 2006), and all numbers are required to be 7-digit for long distance calls. You live in Eureka, CA... you want to call someone in Eureka, CA... great! Use 5-digits, knock yourself out.
But when you want to call NYC (or NYC wants to call you), you both need some common addressing scheme... a unique 10-digit number, where the first three digits are the area code. (In the '50s, no one foresaw that cell phones and modems and fax machines and the Bell breakup and Identa-ring and ... would delete the supply of available 10-digit addressing codes faster than anyone ever expected. This same problem (ruuning out of numbers) is now stalking the Net.)
Direct Distance Dialing (Bell's system of letting you dial your own long distance calls) solved addressing for the phone system. Now TCP/IP had to solve it for computer networks.
Ok... ADDRESSING was problem #1 for TCP/IP to tackle.

Problem #2 for TCP/IP to solve was... How do you transfer blocks of data or messages from a computer on one little network to some computer on another little network?
Why is THIS such a big deal? Because different networks can handle different maximum message sizes. If one weak, puny, little baby girl little network can handle only 100-byte messages at most, and another robust, manly little network can handle 1,000-byte messages... Oy... problems, problems, problems all day long. Because the 1,000-byte messages will NEVER get through the tiny network's 100-byte "pipes" to one of its computers. (A byte is roughly a character. This sentence is 31 bytes long.)
This second problem that TCP/IP was up against was called FRAGMENTATION... If the maximum message sizes are different on several little networks, you're going to have to break, or FRAGMENT, the messages into fragments or PACKETS no bigger than the size of the smallest network they'll be passing through... in order to send them from a computer on my little network to a computer on a different little network.
And so, mates, "fragmentation" was problem #2 that TCP/IP was expected to solve.
(Are you now beginning to see now why the Net didn't really get cranked up until the '80s? These are not such easy nuts to crack.)

And finally... Problem #3 for TCP/IP to resolve... How are you going to exchange data in a RELIABLE way, so that I know whether or not my photo *really* reached that cute Irish setter at Harvard? RELIABILITY was problem #3 for TCP/IP.

The solutions to all three of these problems are cool and very elegant, and you just know that some really bright folks were involved in this stuff. And here's exactly how they did it, here's how they made the Net possible...
They designed TCP/IP as a layer cake, a cake with many layers.
TCP/IP Layer Cake

WWW Usenet FTP Mail Telnet NFS DNS SNMP
TCP UDP
IP
Ethernet Token Ring FDDI Frame Relay ATM Point-To-Point (PPP)

Application programs, like our Netscape Web (WWW) browser (to get commercial for a minute... it's the one dog Wolf uses... yes, I know most of the rest of the world uses Internet Explorer, but it's very hard for an old dog to learn new(er) browsers), sit on the very top of the big TCP/IP layer cake.
To insure RELIABLE communications, we go DOWN one layer in our TCP/IP cake to the "TCP" layer.
Then, to break the data into PACKETS of the right size and to handle ADDRESSING, we go DOWN another layer in the cake to the "IP" layer.
And finally, when everything is cool, our packets go out onto the Net. And when they reach their destination, they work their way back UP through the same yummy TCP/IP layer cake... the IP layer puts the fragements back together. The TCP layer makes sure that all of the packets arrived in the right order. And finally, at the top of the cake, a Web server is waiting to send us some pages.
TCP/IP... just some big old layer cake.

Now breathe slowly and deeply. What did we just say? TCP/IP has two BIG parts... two BIG protocols, two very important layers, TCP and IP. (Big surprise, huh?)
IP is one set of rules... a PROTOCOL... for ROUTING data. And TCP is a set of rules... a PROTOCOL... for RELIABLY delivering data.
When we go from our computer out to the Net, we go DOWN the layers of TCP/IP. And when we receive packets of data coming in from the Net, we go UP the layers of TCP/IP.

TCP... It handles RELIABLE data exchange. It's a reliable protocol. You can depend on TCP. It makes sure that data gets where it's going. Intact. The Web (WWW), Usenet (NNTP), FTP, E-mail (SMTP), and Telnet programs on your PC all use the TCP layer to communicate with servers out there on the Net. They all use the RELIABLE TCP protocol. That's what TCP does. It transfers data reliably. TCP solves the RELIABILITY problem for TCP/IP.
The TCP layer of TCP/IP contains everything needed... all of the tools... that make absolutely sure that data is delivered... from us or to us... without any errors, without any pieces missing, the packets all in the right sequence.
And TCP *IS* cool... it's smart enough so that both ends of a connection can send and receive data at the same time... like your PC and some server... TCP sends and receives data at the same time.
What a protocol.

Now, in response to considerable feedback on the above (controversial?) comments on TCP (there are folks who live and breathe this stuff), your dog Wolf wants to comment here VERY briefly on exactly what he means when he says "reliable and unreliable." You can skip this explanation, no problems, if you like (though of course, it IS a treasure trove).
Ok, TCP, sitting on top of IP in our layer cake, a good, trustworthy, reliable protocol... just WHAT does he do for us?

TCP Establishes Connections- When you call your Aunt Biddie on the phone, you make CERTAIN that she's on the other end of the line and that she can hear you before you begin chatting away, blah blah blah.
In the very same way, before any of your data is sent, TCP establishes a data connection that will be used for your entire transmission. (And this is why you can't use a reliable service like TCP to "broadcast" data to more than one computer out there at a time... like when Victoria's Secret broadcasts a fashion show to the Web... not that I would watch such goings on anyway.)

TCP Acknowledges Packets- Every packet of my e-mail that IS received at the other end is acknowledged. If I don't get an acknowledgement within a certain amount time from the computer out there that I'm talking to, TCP will assume that my packet got lost, and it will tell my e-mail program. And that packet will then be sent again; and again... until I get an acknowledgement. TCP, he looks out for me... no missing pieces in MY e-mail.

TCP Validates Sequences- TCP sends extra bits of data that he uses to send "checksums" back and forth, along with the actual data; checksums check for errors. Often a transmission error can be fixed at the other end. If not, TCP will notify my program on my PC, asking it to send the packet with the error (or all of my data) again.

TCP Controls Flow- The remote server dictates the amount of data that it feels comfortable receiving. Thus, its data buffers are kept full, but they don't overflow... because overflows will cause packet losses... and losses aren't reliable. TCP sends my data at a rate that the computer at the other end of the connection can handle.

TCP... I can depend on him.

BUT... With an Unreliable Protocol like IP...

IP Never Establishes A Connection- Think of it as dialing a telephone number, waiting 10 seconds, and starting to speak no matter what... without even listening to see if anyone at the other end has even answered the phone or if the line was busy. (But since there is no end-to-end connection, IP *CAN* be used to broadcast data to more than one address... it CAN be used to broadcast Victoria's Secret across the entire Web.)

IP Doesn't Receive An Acknowledgement- IP makes its best effort to deliver your packets, but there are no guarantees... you never know if your data reached its destination, or if the destination was even ABLE to receive data. (Maybe it was broken and out of service; IP couldn't care less.)

IP Does No Data Correction- If any checksums are implemented by IP, they're simple-minded and not very comprehensive... errors can leak through, and they DO.

IP Has No Flow Control- If a packet gets lost because some buffer overflowed... well, times are tough.

Ok, IP... It's a layer way down in the TCP/IP cake, but it's also the engine that makes everything run.
IP handles both ADDRESSING and FRAGMENTATION. It moves our packets around the Net. And it selects the route that our packets will take to get from here to there.
And when moving from one little network to another, IP routes our packets... these fragments of messages, these fragments of data files... through special hardware devices that regulate traffic on the Net and decide the most efficient path for our packets... wonderous devices called ROUTERS...
IP routes the data on the Net between the "little networks". Data may go from one litlle network directly to another... or it may pass through lots of other little networks on its journey to (or from) us.
And the data that IP sends is always sent in tiny packets.

MORE ON PACKETS...
On the Net, we send and receive things in packets. If we want to send an e-mail, the IP layer of the TCP/IP cake tears up our e-mail into tiny packets. IP writes the destination address on each packet. And as a result, TCP/IP can send each packet separately over the Net... like thousands of cars on the Interstates, each holding up some big sign saying, "Key West or Bust."
The Net is a lonely place. Each packet travels the Net alone. The many packets from our one e-mail may each take a different route across the Net. In going from Hunt Valley in Maryland to Santa Cruz in California, one packet of my e-mail may go through Dallas; another may pass through Chicago.
My e-mail's packets may even arrive at their destination at different times and out of sequence... but the receiving computer is able to reconstruct our original e-mail as the packets travel upward in the TCP/IP layer cake from the IP layer to the TCP layer.
Routers (intelligent hardware devices... our friendly traffic cops along the Interstate backbones) read each packet's destination and forward each of them along the best route available at that moment. And packets are small... usually only a few hundred bytes in size.
Why? Well... you can ship all of your watermelons on a one mile-long freight train. Or you can load the melons onto hundreds of trucks. And if one truck breaks down, it's a lot easier to fix or reload than cleaning up after our train runs off the tracks.
In other words, if there's an error in transmission, it's a lot easier and faster just to resend one small packet. PLUS... small packets tie up routers only for short periods of time. They're in and out fast.

So... each little packet contains a destination address that IP inserts. And as the packet bounces about the Net, like tiny steel balls in some huge worldwide pinball machine, each "bouncer" (called a "router") reads the address that IP has inserted into the packet... so that it can route the packet to its destination as quickly as possible.
And things change fast on the Net. The best way to route one packet may not be the best way to send another... your data may take more than one path on its way around the world.
This kind of arrangement is called "connectionless." Say it with me... it's one of those words that folks will try to confuse you with... CONNECTIONLESS.
The IP layer of the TCP/IP cake is called connectionless because EVERY TINY PACKET of your data... a web page, an e-mail, whatever it may be... is routed about the Net independently.

IN SUMMARY--> IP... he doesn't guarantee anything. IP does not guarantee reliable, or in-sequence delivery of packets.
TCP... he's the one who cares!

Now... BECAUSE A PACKET MAY PASS THROUGH SO MANY ROUTERS... IP was made very simple... he just focuses on routing data from its source to its destination.
The task of turning IP's connectionless exchange of packet traffic into a solid, trustworthy, reliable data connection is handled by TCP. You can think of IP as the glue that connects the little networks, and you can think of TCP as residing on the computers at each end of an exchange.
E-Mail, the Web, FTP, Usenet, Telnet... they're all applications on the very top of the TCP/IP cake that talk ONLY to TCP... because they all want reliable connections.

A few more details here you can skip with no problems... but careful, they're treasures...
How do routers know how to route your packets? Answer--> Routers have tables. And routers keep their tables up to date by talking to each other. Again... routers talk to one another. And they love to gossip.
A router can discover... on the fly... that a new little network has been added to the Net... or that an existing path has been disrupted, and there's no way to reach some destination at this time... or that a new router has been added to the Net that provides a shorter path to some place.
(Can you also see why hackers and crackers love ROUTERS? No? Good for you... you're a good person. But you CAN see the influence here of the US military's "Survive a nuking" philosophy from the 1960's.)

DOG WOLF'S PROBLEM WITH ROUTERS...
Ok... we talked about how IP tears messages into packets... how your packets can take different paths before arriving at their destination and being reassembled. But for every piece of our message passing through a router, that router may have to scan about 40,000 entries in its tables to decide which way our packet should go to get to our destination address via the fastest route.
And so, routers often get steamed and overloaded and lose packets. (We told you that IP was an unreliable protocol... that we needed some icing from the TCP layer of our cake smeared on our data first.)
TCP can detect the fact that our data was lost, and it can tell computers to resend the lost packets. But THIS makes the routers even busier, because about one out of every ten packets gets lost. (Starting to see a pattern here?)
Why so busy? Why are over 10% of packets lost? Because this beautiful and elegant Net was designed to carry small volumes of text data between government and research and university facilities. NOT millions of Web pages with pictures and sounds and animations and RealVideo and Virtual Reality and groceries and chat.
And when over 10% or 11% of the packets get lost, TCP/IP just about stops working.
Why not just make the routers bigger and faster? Because the Net is growing everyday, FASTER than the routers can grow. That's why it often takes sooo long when you try to access a Web page. (To be fair, that's just one of the reasons... the cables that make up the backbones and the Web servers are overloaded too... but the routers are, in my dog Wolf opinion, the #1 culprit when the Net slows WAY down.)
One day, it may be blackout time. Or not.

So, to repeat the very important concept which I've just shared with you, each layer of TCP/IP was designed to solve one of the three problems associated with creating The Net (recall ADDRESSING and FRAGMENTATION and RELIABILITY?) And addressing (IP) and fragmentation (IP) + reliable data transfer (TCP) = the biggies.
Think of it as a candy bar. When you bite into it, you expect *something* to be inside... it could be hard (might even chip your tooth) or sticky (pull out a filling), etc. That's IP in the middle of that candy bar.
But if you want it to be pretty and sweet (reliable communications), you'd better cover the center (IP) with chocolate (TCP). If you want IP, the transmission engine that moves stuff around the Net to be reliable... you'd better apply a healthy coating of TCP on top of it.

(Like this color? I just mixed it; it's #552371. Yeah, whoop.)
Trust me... I'm very correct in what I've just said above... but just so some "purist" doesn't jump these old arthritic bones of mine in anger, I want to go into just a tad more detail here on TCP/IP, which you may well skip with no problems. (But you'll miss yet another treasure trove... UDP.)
TCP/IP actually has another secret "transport" protocol in addition to TCP... and they are as different as night and day in terms of reliability. If you want reliable communications on the Net, you use TCP and pay the price of overhead. FTP is an example of a service on the Net that uses old reliable TCP. So is the Web (WWW). Ok...
BUT... If you want "bare-bones" service, if you want to handle reliabilty yourself in your own software, you can use the UDP protocol in place of TCP. (See UDP in our layer cake picture above?)
UDP is low overhead, but it's highly unreliable. It's really just IP with a very, very thin coating of chocolate (to recycle our candy bar analogy). And it's hardly better than naked IP... no frills, no reliability... it dials Aunt Biddie's phone number, it waits 10 seconds, and it starts talking.
Does she understand you? Did she even answer? Was the line busy? Is she home? Is her hearing aid turned on? Do you have a good connection? Did she miss some of your words? UDP, he doesn't care. End of UDP discussion.

Now, moving right along, on the Net we have two VERY DIFFERENT kinds of communication...

I can communicate with another computer on MYown little network, perhaps a PC in an an office on my LAN, my Local Area Network. Perhaps those of us on the LAN call the computer we're trying to communicate wth "Seymour;" perhaps it lives in Seymour's office, whatever.

Or, I can communicate with a computer on ANOTHER little network... like with, say, baltimore.maryland.gov.
baltimore.maryland.gov is a called a host name, because it's the name of some host computer that I might want to contact to perform some service for me. (Maybe it'll return Web pages to me, who knows?)

Communicating with computers on other little networks means that we have to know how to call them. (No, "C'mere Seymour" won't do.) So... here is how computers are named on the Net... the REAL way they are named on the Net. I have taken this very slowly and put in lots of examples, because there is so much misinformation out there... AND, many of the terms are similar... DOMAINS are not DOMAIN NAMES, etc, etc, etc. (Remember what we were taught in grade school... We don't run with scissors... and how computers on the Net are named can be a lot like running with scissors... we don't do it, we take it slowly, we move ahead one step at a time.)
Looking above at the paragraph before the last, what do we see? Right, words. Anything else? Right... the Net likes to use dots; lots and lots of dots. (Without dots, there would be no Net today.) And the dots separate a series of LABELS. It's not too far out to find NAMES on the Net with 5 (or more) labels...
www.troubleshooting.ethernet.networks.com
MY.wireless.networking.help.routers.cable.yale.edu
ftp.install.ROUTER.washington.DC.gov
www.dawn.MCGATNEY.dog.WOLF.wireless.com, etc.
Labels on the Net can be up to 63 characters in length. Total name size can be up to 255 characters in length. And case does not count... uppercase and lowercase are the same.

NOW... ALL NAMES on the Net are structured like a TREE-
-----------------------------------------------> | | | | EDU COM GOV NET | | ------------------------------------- | | | | IBM EARTHLINK COMCAST YAHOO ... | | --------------------------------- | | | | WWW FTP CAMEL MAIL ...

Every label in the Net Name Tree is associated with what is called a DOMAIN NAME. And there is only ONE Domain Name associated with every label on the Net.
The Domain Name is the name of the label PLUS every other label you touch going upward until you hit the top of the tree.
EXAMPLE... In the tree above, the label EARTHLINK has a DOMAIN NAME of of EARTHLINK + COM, which we write as...
earthlink.com
(We just climbed up the tree, starting at EARTHLINK, we hit COM, we were at the top, that's all. C'mon, tree-climbing can be fun.)
ANOTHER EXAMPLE... FTP, in our tree above, has a Domain Name of...
ftp.earthlink.com

(Careful here now, mate, downshift to low gear in your reading... I want you to get this right... because most of the known (and unknown) world has it wrong.)
A DOMAIN is something else... it's almost the OPPOSITE of a Domain Name... to get a Domain Name, we worked UP the tree from some label.
BUT... to get a DOMAIN, we work DOWN the tree. A DOMAIN is A DOMAIN NAME PLUS ALL THE DOMAIN NAMES ASSOCIATED WITH EVERY LABEL UNDER IT. And there may be millions of names in a Domain.
EXAMPLE... In the naming tree above, a DOMAIN would be...
earthlink.com
PLUS all the names under it... that is... all the possible names ending in
earthlink.com
Thus the Domain of
earthlink.com
would consist of...
earthlink.com
ftp.earthlink.com
www.earthlink.com
camel.earthlink.com
mail.earthlink.com
ANOTHER EXAMPLE... EDU and every label under it (that is, every name ending in .EDU) would be the "EDU Domain." And so on. A Domain is a collection of all the names on the Net with a common ending.
(Yes... This is correct. Read it several times carefully. �Est� claro? Great... you are now among the 0.05% of Netizens who correctly understand what a "Domain Name" and a "Domain" REALLY are.)
Great, so what? So this...
The .COM part... the rightmost label in any domain name... is called the TOP-LEVEL DOMAIN. If the computer I'm trying to reach out there somewhere on the Net has a top-level domain of ".COM", it means that that the host computer that I'm looking for is in the commercial top-level domain. (.COM = Commercial.)
If the rightmost label were .EDU, that would mean the server that we want is in the "Educational" (4 year college) top-level domain. (Like...
baltimore.maryland.computers.jhu.edu
would have a top-level domain of .EDU. (Saying this another way,
baltimore.maryland.computers.jhu.edu
is in the .EDU Domain.
Where did these top-level domains come from? From ARPANET (remember our old friend ARPANET?) About 1984, Jon Postel and Joyce Reynolds of ARPANET created top-level domains of .COM, .NET, .ORG, .EDU, .GOV, .MIL, and .ARPA.
What do you think .AU at the end of a name would mean? Nah, wrong. It means the machine I'm after is in the Australian top-level domain... it lives in Australia, lucky host computer.

Now... let's start to tie this together with reality...
Domain names with ONLY TWO LABELS, like...
precisenetworking.com
earthlink.com
whitehouse.gov
harvard.edu
melbourne.au
att.net
are called SECOND-LEVEL DOMAINS. (Starting to see a pattern here? No? Ok, let's continue...)
Now let's examine the name
dog.wolf.com.
Yes, it's in the .com domain, correct. Now move one label to the left--> .wolf.
That's the name of the OWNER of the host computer. It's owned by Wolf (by me... hey, since I've concocted this example, why shouldn't I own a host computer?) (In the example just above, the computers would be owned by precisenetworking, earthlink, whitehouse, harvard, melbourne, and att, respectively.)
And together,
wolf.com
is called a Second-Level Domain (but you already knew that... just reviewing for a moment).
EXAMPLE...
ftp.harvard.edu
...The owner is harvard.
The top-level domain is .edu.
And the second-level domain is
harvard.edu
Second-level domain names are also called the SITE. It's the PLACE where the host lives. Like... all the host computers in the second-level domain (at the site) earthlink.com are host computers AT Earthlink. Cool.
So what do they almost never tell you? A second-level domain = the name of a little network. Little networks... Remember them? On the Net, we give each little network a second-level domain-name.
wolf.com and earthlink.com are both little networks. Or second-level domains. Or sites. All the same.

Return again to our previous example...
dog.wolf.com
Now move left yet again; the leftmost label here is
dog.
You see, Wolf actually owns several computers, and the particular one that we're after is named dog.
In a host name, the leftmost label (or labels) is the name of a particular, specific, unique machine... a unique host on the little network, a unique server on the little network.
The SECOND-LEVEL DOMAIN NAME tells us which little network we want to access. Like...
wolf.com
And the HOST NAME...
dog
or
dog.teaches.you.the.internet
whatever... everything to the left of the second-level domain... tells us which computer on that little network we want to access. �Est� claro? Excellent. Let's try yet another one...
ftp.college.park.maryland.edu
...says that we want to access a server named...
ftp.college.park
(hmmm... it might be their FTP server, you think?) And it lives on the little network (at the site) named...
maryland.edu
And maryland.edu is just one of many, many second-level domains in the .EDU domain.
BUT... it gets even better...
You can add the name of a USER who uses a particular host computer, and you'll have...
dawn@dog.wolf.com
Well sure... it points to ONE USER (dawn) on ONE SPECIFIC COMPUTER (dog) at ONE SPECIFIC SITE (wolf.net). Voila. Simple, right? Right.

HERE IT IS ALL TOGETHER...
If we have dog.wolf.net, then...
Tree Structure --------------------- | NET | -------------------- | WOLF | ---------------------- | DOG

AND...
Host Name = dog.wolf.net
Domain Name for dog = dog.wolf.net
Domain Name for wolf = wolf.net
Domain Name for net = net
Domains = .net, wolf.net, dog.wolf.net
Top-Level Domain = .net
Second-Level Domain/ Site/ Little Network = wolf.net
Owner = wolf
Host Name = dog

OK... with that 32 ounce steak under our belts. we now know exactly how nodes on the Net are named; and we now can make a shocking confession... a computer's true address on the Net is NOT specified by a DOMAIN NAME, but by a NUMBER. The DOMAIN NAME is merely a mechanism that makes the true numeric site address easier to remember.
To move anything from computer A to computer B across the Net, TCP/IP needs an IP ADDRESS. The IP Address is a number, generated by looking up the HOST NAME in a table. (Like on the phone, we have "Aunt Biddie" as the name and 908-789-9987 as the number.
So... now we look at exactly HOW we move a message from one computer to another on the Net. Exactly what does TCP/IP do to accomplish this wondrous task?
We saw earlier that every computer on the Net had a unique host and domain name. Similarly, every computer on the Net also has at least one unique IP address. Because TCP/IP cannot deal with names; only with IP addresses
The IP address number specifies BOTH the host computer name AND the little network that this host computer lives on. The IP address is a number from 0 to 16.7 million. It's used to uniquely identify the computer that we want to talk to... just like a phone number specifies the exact person or business somewhere in the world that we want to call.
Every computer on the Net has (at least) one unique IP address. (If you dialup an Internet Service Provider (ISP) using the PPP protocol, YOU'LL also have an IP address, at least while you're connected. If you have a cable modem or a DSL phone line connection, you'll have a permanent IP address.)
Let me say the same thing slightly differently... every host computer on the Net has at least one unique Net address.
The IP address is written as n.n.n.n, where each "n" is a number from 0 to 255. Some of the four n's define the DOMAIN NAME (the "little network"). Other n's define the HOST COMPUTER (the name of the computer we want to reach on that particular little net).
EXAMPLE...
dog.wolf.com
might translate into an IP Address of...
206.51.32.5
Part of this number specifies the little network, or...
wolf.com
...and part of this number specifies the host computer that we want to reach at that little network...
dog
The name and the number are interchangeable... BUT... Before we can transfer data to or from a host, we have to have the host's address as an IP address, written as dotted decimal numbers like...
207.12.3.2.
TCP/IP requires it. It's not just a good idea, IT'S THE LAW.
Why convert an easy to remember and elegant name like
dog.wolf.com
to an impossible to remember number like...
207.12.3.2?
Because, by doing so (and trust your dog Wolf on this one), all computers on the Net become equal. Since every computer on the Net has the same format IP number, we don't worry about routers or hardware or types of networks. We have one big happy family, and the Net has become a single network.
Why convert "Hunt Valley, Md." to 21030? Dunno, but if I don't, the mail comes late (if at all) with stickers all over the envelope. The Zip Code is USUALLY required to send and receive mail. And the IP address is ALWAYS required to send and receive data on the Net.
So how do we convert a domain name to an IP address, dog Wolf? Stay tuned... Here are the amazing details of DNS...

Ok, let's assume that you want to browse
www.dogwolf.edu
Well... you can't... because www.dogwolf.edu is a DOMAIN NAME, and IP (the part of TCP/IP that actually moves stuff around the Net) can only work with IP ADDRESSES.
SO you can't get a Web page from...
www.dogwolf.edu ...an easy-to-remember domain name, until it gets translated into an impossible to remember "IP Address," like...
216.163.77.8.
So... just who translates these DOMAIN NAMES into IP ADDRESSES? TADA... DNS to the rescue. (DNS = Domain Name System.) How does DNS translate a domain name into an IP address? (This is the kind of stuff that will make your SO think of marriage for sure; or you may just scare him or her with the power of your mind.)
When any ISP or organization (like precisenetworking.com) wants to connect to the Internet, it first has to register with some organization, like InterNIC. And as a part of this registration process, the organization or ISP has to provide the addresses of at least TWO "DNS Servers;" these DNS servers are host computers which are located at the ISP or organization.
These DNS servers will return an IP address for every host computer AT that organization. And it's the organization's job to keep the data on its DNS servers current. Hold that thought.
Now... every TCP/IP product contains a special little program called "The Resolver." (Great title for some movie.) When you want to browse or FTP or telnet or whatever, you specify the host computer name that you want to go out to, and the resolver converts that domain name into an IP address.
You want to browse www.dogwolf.edu? The resolver program in TCP/IP on your PC converts that domain name to 207.65.74.114. How does it perform this modern miracle, you ask your dog Wolf? Stay tuned.
STEP ZERO. The Resolver looks in one of our local DNS server. If we're on an ISP, it looks in one of the ISP's two (or more) DNS servers. How does the Resolver program on our computer know the address of the LOCAL DNS SERVER?
1.) You may have to code two IP addresses of your local DNS servers in your "Network" settings on your computer before you first go out onto the Net. Or...
2.) Cable ISPs will store the IP addresses of your local DNS servers in your cable modem; the Resolver program running on your PC will retrieve them from here.
(Note that DNS uses the UDP protocol... it's a candy bar with a VERY THIN layer of chocolate... UDP doesn't mind trying several times if it has to, to get the IP addresses of your LOCAL DNS SERVERS.)
STEP ONE. Now assume that the host computer's name that we want to convert to an IP address belongs to our local domain... that is, if it's on OUR DNS SERVER... then the Resolver reads the record for it, retrieves the IP address, we're done. Not very exciting.
EXAMPLE... we want to resolve ftp.dogwolf.edu, and we're in the dogwolf.edu domain name (little network). Then our LOCAL DNS servers will have the IP address of ftp.dogwolf.edu.
STEP TWO. Pay attention here, because this stuff is MUCHO importante. When the Resolver asks our local DNS server for an IP address, and the domain name of the host we want is NOT on our local DNS server, then OUR LOCAL DNS server goes "out there" onto the Net for help. (We'll tell you precisely how in just a minute.)
When our local DNS server finally gets the IP address we need from "out there," it not only gives it TO THE RESOLVER PROGRAM RUNNING ON OUR COMPUTER, but it also stores the domian name AND the IP ADDRESS on a local hard drive at our LOCAL DNS SERVER, called a cache.
In STEP TWO, the Resolver checks our local cache on our LOCAL DNS SERVER to see if the name and address are already stored in there. If it finds a match, we're in business, we're done.
(BUT NOT ALWAYS. Ever try to reach a bunch of Web sites and find some of them giving you "Resolving host www.aardvark.edu" ...and never getting any further? Then in a few hours, all is well again? Think your ISP's local DNS cache may be having problems? Uh Huh. (Or maybe your cable modem lost the IP addresses of your local DNS servers.) But let's assume that STEP TWO here goes Ok, and the Resolver just doesn't find a match in our local cache. To review and preview the whole process-->
NEED IP---------RESOLVER-------1) DOMAIN NAME ADDRESS PROGRAM ON LOCAL DNS--------Get it. SERVER? yes | |no | 3) GO TO A ROOT SERVER---------2) DOMAIN NAME "OUT THERE." GET ADDRESS no IN LOCAL DNS---------Get it. OF DNS SERVER FOR DESIRED CACHE? yes DOMAIN NAME | | | 4) GO TO THIS REMOTE DNS SERVER. GET IP ADDRESS. RETURN IT TO RESOLVER PROGRAM. ALSO CACHE IT ON LOCAL DNS SERVER.

STEP THREE. We're still trying to resolve www.dogwolf.edu. Our local DNS server now sends the dogwolf portion of the name to be resolved to one of the .EDU Root Servers "out there" on the Net somewhere. The .EDU root servers know all about dogwolf.edu (and every other domain name ending in .EDU).
(There are multiple identical root servers "out there" on the Net for .EDU, and for .COM and for .ORG and so on... for every top-level domain.)
The .EDU Root Server has information in its tables that tells it the address of dogwolf.edu's DNS server. It sends that address to OUR DNS server. OUR DNS SERVER then queries the dogwolf.edu REMOTE DNS SERVER, and it gets from that remote DNS server the IP address of www.dogwolf.edu. And now you can rock 'n' roll and start actually browsing www.dogwolf.edu.
As we said, your local DNS server (the one at YOUR ISP, or at your organization) also caches this IP address on a disk drive, so the lookup process usually goes pretty fast. The next time your ISP sees www.dogwolf.edu, it ALREADY has the IP address, it "remembers" it from the DNS query that it did on that domain name the first time.
The long process described above with the DNS root server only happens when your ISP has never been asked about a certain remote domain name before (or if a locally cached entry has expired).

(IMPRESS JOHN NASH--> How, pray tell, does your local DNS server know how long to keep an entry in its cache? A deep secret--> when the remote DNS server sent the entry with the IP address, recall? Well, it also included in its entry the MAXIMUM TIME that the entry can be cached (one day is a common value). Of course, the organization running the DNS server may de-cache the entry earlier than recommended, perhaps because cache is running out of disk space, or because there are too many entires in its cache, and things are running slowly, OR... the ISP/ Organization may be getting angry calls and realize that its cache is mucked up. (Aussie term for "corrupted", sorry.) ...is it common to worry about unmatched parentheses in prose?)

Yeah, there ARE a few steps to it. But it's not rocket science. (More like meeting a beautiful woman and chatting with her and courting her and... and...) And this DNS system, a system where there is actually a "distributed database of IP addresses," almost always works... millions of times each hour. And it's pretty much transparent. And this is how the DNS (Domain Name System) REALLY does its thing, no hooey.
And you're now among the 0.03% of Netizens who know and understand this.
And once YOU know that Aunt Biddie's phone number is 410-936-1212... uh, sorry... that www.dogwolf.edu's IP address is 216.163.77.8, you're free to bypass the whole DNS lookup process and simply give your browser http://216.163.77.8, which will work just fine, and may even save you a second or two.

So, always remember that the host computer name, dog.wolf.edu, gets converted to a number (an IP address) before TCP/IP can use it.
This "addressing" is handled by the IP layer of the TCP/IP layer cake, also called the NETWORK LAYER of TCP/IP. (IP = THE NETWORK LAYER.)
To go back and review for just a tiny moment, TCP/IP is built in layers. The IP layer (or "network layer") is pretty close to the bottom of the cake. The TCP layer (or "transport layer") is one layer above the IP layer and is more sophisticated and provides reliable communications, recall? (And the "transport layer" also has UDP for "unreliable" communications.) It all looks like the cake that I've again drawn for you below... see the DNS application sitting over the UDP protocol now?
NOTE--> (Very important factoid.) The TCP/IP network layer = IP = the only part of TCP/IP that can actually move data between hosts on the Net. If TCP wants to move data reliably, it can supervise, but it must call on IP, down in the Network layer, to do the actual data move.
TCP/IP Layer Cake
WWW Usenet FTP Mail Telnet NFS DNS SNMP TCP (Transport Layer) UDP IP (Network Layer) Ethernet Token Ring FDDI Frame Relay ATM Point-To-Point (PPP) Since your dog Wolf first wrote this page for the intelligent Netizen (seems like a million years ago) intelligent Netizens have feedbacked to us two requests... Tell us, dog Wolf, how does it ALL fit togther? Tell us, dog Wolf, tell us a bit more about protocols. And so above, I have yet once again displayed the Entire TCP/IP Layer Cake, in all its luscious glory. Let's stop here for a minute and talk about it, yes? Yes. TCP/IP is designed in four layers. We say it has a four-layer architecture, or a "stacked architecture" (much like my collie friend at Harvard). On each layer are components and protocols, all interacting, like some grand four-ring circus. BUT... it's not so bad. The components on any layer can only interact with components on an adjacent layer. Thus in the nice picture I've created for you above, for example, FTP cannot call upon IP for some service... their layers are separated by TCP/ UDP (the transport layer). Ok... The bottom layer, often called the DATA LINK layer (because that IS its name), takes care of transferring data packets between the host that's running this TCP/IP layer cake and the Net's maze of cables and routers. See PPP on the bottom layer? That's how most folks today connect to their ISPs. It's a little protocol that let's you dial up your ISP, and, once connected, you look to all the world like you are permanently hard-wired into the Net. Now go up one layer. See "IP?" No? Look again. Got it? Super. Recall IP doing great things like breaking data into packets and handling IP addresses? Right. Well, after IP does his thing, he calls one of the protocols on the bottom layer to actually move a packet out onto the Net. Physically. Now go up to the "TCP/UDP" layer. He doesn't route anything through the Net. (IP does that for him, if he asks, nicely.) The TCP layer on my PC talks to the TCP layer on some distant host; like mates, they are. The routing and the physical aspects are handled by the two lower layers. No dirty hands for TCP, just reliability. My TCP and the remote TCP will together assure reliable data transfer. On the same layer as TCP, we see UDP, a bare-bones Yugo (no Cadillac here). If we want an IP address that corresponds to some name like dogwolf.seagull.net, DNS will find that address for us. IP loses packets on the first try? Just try again. And finally at the top, we have the application layer. Applications like FTP are included with most TCP/IP implementations. (FTP is great for downloading goodies from distant hosts; and it can also upload stuff from your PC to some Web server, if you have your own Web site.) FTP tells TCP it has a need to send. TCP tells IP to start fragmenting and routing. And IP tells PPP to crank up your modem and start sending. When you send data from your PC onto the Net, it goes down the layers. Your E-mail program talks to TCP, who makes sure that (eventially) everything ends up where you planned. TCP taps IP on the shoulder, telling him to fragment and create packets. And the bottom layer converts the packets into a stream of bits and shoots them out into your modem (telephone or cable). Receiving data is exactly the reverse... we go up through the layers. A data stream from your modem becomes packets, becomes TCP segments (with TCP making sure they're all there and in the right order). And last, but far from least, TCP proudly delivers the .gif or .jpg picture of my Harvard collie luv to my browser, up on the lofty application layer. Voila. Simple, yes? Yes. Oh, yes. This simple but efficient TCP/IP four layer-cake makes possible all the Hot.Bots and EBay.Coms and Amazon.Coms and all the other other great companies that once had billions of $$$ in valuation. Quick review--> Two main parts of TCP/IP--> IP = Network Layer--> Handles Addressing and Fragmentation. Responsible for moving everything on The Net. TCP = Transport Layer--> Handles Reliable, Verifiable Data Exchange. But calls down to IP to actually move data. TCP is connection oriented... you call someone on the phone, you make sure it rings, that they answer, that it's the person you're calling, that you have a good connection, that they understand every word you say... that's connection oriented. That's what FTP and Telnet and the Web use. (IMPRESS YOUR SATURDAY NIGHT DATE--> TCP uses PAR (positive Ack with re-transmission), and it treats data as a stream. Whoop. (DAwn actually dates men who are impressed by stuff like this.) ) (Smile. Big smile. You're now among the 0.05% of all Netizens who know and understand all this great stuff.) Now, this TCP part of TCP/IP, this ever-mysterious "transport layer," uses something called a PORT NUMBER. This is a number from 0 to 32,768 that identifies a particular application on a host. What's so cool about a port? (You can use any one of them in a storm? BZZZT. Sorry, but thanks for playing.) Ok... If I'm running Netscape's browser on my PC, I need some way to tell a host computer out there just what I want and expect from it. TCP does this with a port number. TCP just tacks the port number onto the IP address. If I want to Telnet to some host, then I want to access port 23 on the remote host. Why? Because it's the standard port for Telnet. It works because most Telnet SERVERS "listen" at port 23 for requests. REVIEW... dog.wolf.com is the name of a HOST COMPUTER. The name has to be converted to an IP address before TCP/IP can use it. This is called ADDRESSING and is handled by the IP layer (also called the "Networking Layer"). So we have an IP address of, say, 207.23.201.53. AND... TCP adds 23 to the IP address, if we want to do Telnet. WHY? Because one host computer might be willing to do several things for us... play chess, return Web pages, and do Telnet, for example. The Port number tells THAT specific host computer what we'd like (we may or may not get it... it's up to the host). The IP address + the port number, like 204.192.78.125,25, taken together, is called the SOCKET NUMBER. Thus, I can communicate with another computer in Bali (have a great friend, an Aussie kelpie, really lovely lady, in Bali, and we exchange e-mail often) using the socket number... The IP number part gets me to the correct domain site (little network) and to the proper host computer at that site, AND the PORT part tells the host computer there what I'd like it to do for me. E-mail (Port 25) in this case. BRIEF SUMMARY--> Through the magic of TCP/IP, we communicate identically with computers on our own little network or on other distant little networks. TO TCP/IP, IT DOESN'T MATTER. Nor does it matter what kinds of computers we have... I can be running a tiny laptop, and using TCP/IP I can download data from the most potent IBM mainframe. My Windows PC can send E-Mail to a UNIX machine, or to a Mac, etc... TO TCP/IP, IT JUST DOESN'T MATTER. Can you now see a beauty in TCP/IP that goes even beyond making inter-networking work? Yes? Yes? Yes? YES. Mission accomplished. You have now (almost) earned The Dog Wolf Certificate Of Net Education... your Net Knowledge now ranks you in the top 0.01% of all Netizens. The Net Services Ok, onward and upward now... (Pay attention, because this is the most important part of what I have to share with you.) So what... what, dog Wolf... can we do with this wondrous thing... the Net, which we have followed from birth up to age 35 now... including puberty (TCP/IP... when the Net came of age)? Well, over the years, different "services" have evolved (and waned) to help us share information on the Net. Today, we have a bunch; we will explore just a few... FTP FTP allows us to browse files on host computers all over the Net, and to download the ones that interest us. (Download means to copy files from "out there" on the Net to our computers.) Cool... everyone likes to copy files... free programs (freeware), pictures, books... how can this possibly be difficult? Every dog has his day, every cat is a different color (I have observed), and it seems that every computer vendor has its own file format. Sheesh... sometimes I even have trouble copying files between computers from the SAME vendor. ENTER FTP... You connect to a host computer out on the Net, using an FTP CLIENT program on your PC; you browse through that host's files (programs, pictures, games, whatever) that are available to you, and you download the files that you want. FTP (File Transfer Protocol) was one of the first "services" that was added to TCP/IP. FTP allows you to copy entire files from one computer to another... both text files and binary files (programs and pictures). FTP even lets you rename files, delete files, and create new directories on a remote host computer... and if you have your own Web site, you will frequently want to delete and rename files... FTP to the rescue. And FTP is THE way to get stuff from your PC out to your Web site. WS_FTP is a popular client for doing... FTP, of course; buy it, use it... at one time it was free, now it's a few dollars; it's worth it. (MAC users, use a program called "Fetch" to do FTP.) See how I slipped in the word "client" in the paragarph above? That's because FTP is a great example of a CLIENT-SERVER system. A WHO-HUH WAH-HUH? A Client-Server. You install a program on your PC, called the "client;" he requests some service from a remote host computer called the "server." With FTP, a willing server then lets you download (and sometimes even upload) files. (I just installed this neat client on my PC that gives me updated weather radar and satellite photos whenever I like... my client program connects to a weather server out on the Net. (Yeah, there are only a few of these serevers, but they work just fine.) ) And there are servers that let you talk across the Net just like a telephone, only minus the long distance charges. Now, what does a host computer need to have before you can connect your FTP client to it? ANSWER--> The remote host-computer needs to have an FTP SERVER PROGRAM running on it. Technically speaking, the FTP SERVER is really the PROGRAM that's running on some host that allows it to do FTP for you. Interestingly (well, I find it interesting) FTP actually establishes TWO connections out to the remote server... one used for commands and responses, and one dedicated to data. FTP is thus a bandwidth hog, but once he double-connects (especially if we're running a 32-bit client, and there's a robust server at the other end), the data really MOVES. FTP is faster than the Web. TCP locks the two connections in place for FTP. Fast, but a bandwidth piggie he be. FTP is often used to provide public access to a set of files, like some new version of Netscape; this is called ANONYMOUS FTP. From an anonymous FTP server, you can download goodies (files) and upload your files (sometimes) without even having an account on the server machine... without even having a password. You log on with a user name of "anonymous," and you use your e-mail address for the password (as a courtesy). And, unlike e-mail, where your e-mail client first has to encode binary files before you can send them, FTP has no problem sending or receiving binary files. (Binary files are files with 8-bit bytes; text files are files with 7-bit bytes, each of which is some ASCII character. Just be sure you first tell your FTP client program what you're transferring... ASCII or binary.) SECRET--> You can also use your FTP client to exchange files between two remote FTP servers. So... you can copy files at high speed from some host out on the Net to YOUR FTP srever also out on the Net, without ever needing to download the files. (Many ISPs like Comcast give you a chunk of FTP space out on the Net on their FTP server.) If you like to collect freeware, shareware, whateverware, .gifs, .jpgs, research data, etc, you'll go wild with a decent ISP and an FTP client. ANOTHER SECRET--> You can do FTP with your Web browser. There is a LOT of great anonymous FTP stuff out there, a huge amount. I mean books and music and beer recipes and programs... and the cool thing is that the programs you retrieve can be Net apps, so you can start doing even more things on the Net. Whew. Telnet Back in the '70s, most vendors gave you proprietary terminals that could only be used with their own computers. This bothered the US Dept of Defense, because they bought computers from LOTS of vendors... and they wanted to be able to connect from a single terminal to ANY host on any of thie networks. TELNET to the rescue. BECAUSE... what good is the NET... full of intensely cool applications... if folks can't LOG ON to different computers and USE these apps? Well, with Telnet, a user at ANY host on the Net can log onto ANY other host on the Net. (IMPRESS YOUR AARDVARK--> Telnet was the very first application developed on the Net.) While the telnet terminal access protocol was developed to meet this need of the US DOD, Telnet has grown over the years... it will now connect a WIDE variety of terminals (and PCs) to hosts running a WIDE variety of software. So telnet is a program that lets you log onto a remote computer. So what's that good for? You're a college student who sends and receives e-mail. When you're away for break, you can check your computer on campus for e-mail; and you can even send replies. All remotely, by using telnet from your home PC to connect you to the host computer back on campus. Yeah, you might be able to dial the remote host directly through your modem, but then you'd have a long distance charge. And Telnet is easy to use... put a Telnet client on your PC (Windows has one built in), put in the remote computer's name, and VOILA... you're there. Your PC's screen looks just like the screen you'd get if you were in a room next to the remote host, using a terminal connected to it... often better, because the Mac and Windows Telnet clients let you play with fonts and colors and stuff. Ok, another example. There is a golden retriever who lives near Ocean City, Maryland, and who is a very fine chess player. So... she and I log onto PORT 4201 on a distant computer using telnet, and it allows us to play chess with each other. Now, unlike my retriever friend, Telnet isn't very flashy. Telnet gives you only a command line access to remote machines... you type a line or two, it gives you back something... maybe a screen of information. Like entering DOS commands on the DOS command line. You can give Telnet a name or an IP number for the host you want to access remotely. Almost any computer can be set up to run a program when you telnet to it. Find the right computer, and he'll play a game of chess with you, or give you updated information on Australian dogs, or let you log in. It's kind of like dialing into a bulletin board; but instead of a modem and phone line, you're using the Net. Some ISPs (Interenet Service Providers)... folks you dialup on your modem and who connect you to the Net... will allow you to access a "shell account" remotely, via telnet... but yeah, shell accounts on ISPs are very rare now in 2006. AND... although the default port for Telnet is 23 (a Telnet server "listens" at port 23 until it receives some request), you can divert telnet to other services, such as mail or FTP. And then you can use Telnet to give commands to the mail and FTP servers. Say what? Ok... Telnet was over-designed; it was designed to be a tool that actually let ANY two applications on the Net communicate. And so, Telnet contains a bit of secret magic that can take your client to ANY port. Maybe the popular medical service at Johns Hopkins Uni runs on port 3000 and requires no login or password. You just type telnet medical.jhu.edu 3000 and Voila... you're into a huge medical datbase. (We're professionals, don't try this at home... mainly because I've pulled this example out of the air... and Hopkins was wondering why they were getting so many hits on port 3000 :) ) But the ability to Telnet to any port is intensely cool. (Unfortunately, computer crackers also seem to think so :( ). World Wide Web (Also called WWW or The Web.) The Web has text, TV, formatted documents, pictures, chat, multiplayer games, movies, files, programs for downloading, audio, animation, scrolling... Everytime I tune in, there's a new plug-in for my browser that does something new and wondrous. The Web consists of a huge collection of "documents" stored on millions of computers the world over. And the Web has links... Oh, does it ever have links. You can start with one document (or "file" or "page"), click on a link, and jump to a new Web server 12,000 miles from the first, and on and on... some folks start at a page, click on a link, click on another link, and they're still following links five hours later... though they've covered 27 topics and downloaded 123 programs and 57 pictures of Lassie. Like FTP, the Web is an example of a "Client-Server" system. This means, it has two parts... a Client and a Server. The server is the remote part at some Web hosting service. When your browser (the client program running on your PC) sends a request for a page to a Web server, the server (usually) fetches the page from its hard drive and sends it back across the Net to your browser. And your browser then displays it. To access a Web server, you have to run a client browser program on your PC. Only with a browser can you interpret and display all the stuff that you'll find at a Web site. And an ISP connects your browser (the "Client") and the Web server (the "Server") together. Like... Netscape <-----> ISP <-----> www.precisenetworking.com You can also hear audio in real time, so you can listen to radio shows from around the world on the Web. Or display TV camera pictures that change on your monitor every few seconds. Or, if you have a broadband connection to the Net (cable, DSL, or satellite are known as "broadband"), you can even watch TV via the Web. And browsers usually can access Gopher servers and FTP servers and Usenet news servers and do remote Telnet logins. Whew. The nicely formatted documents I mentioned who live out on Web servers are made possible by HTML (Hyper-Text Markup Language), the stuff I'm typing in as I write this for you. So, a very simple thing that WWW is. Simple and potent. It just leads into a LOT of other topics, just like the Net. And some mean souls like to make the Web seem complexicated, just as they do with the Net. Actually, it's VERY simple, the Web is. The Web contains... Hypertext... links that you can click on with your mouse pointer to get other pages, and Multimedia... pictures, sound, whatever. So how's the Web work? Every file available for browsing on every Web server computer has a unique name, called a URL. URL stands for Uniform Resource Locator. You can type a URL directly into your browser, or you can click on some link to that Web page. (A file on the Web is often called a "Page".) So what happens when you click on a URL for a page? First, your PC has to find the computer (called a Web server) that the page is stored on. To do this, it taps a special computer on the shoulder, called a Domain Name Server (or DNS). We have already covered DNS in GREAT detail. Thus you already know that DNS looks up the Web server you've specified in the URL. It replies with the IP address of that server, a unique number like 205.3.27.107. Now, armed with that IP address, your request for your page routes about the Net... until finally it reaches www.whatever.com. This Web server then looks to see which file you want and retrieves it. So then what? How does the file get back to your browser, so that it can display on your monitor?" Well, when you sent out the URL onto the Net in the beginning, you sent it in TCP/IP, the language of the Net. (Ring a bell?) Your request for the page went out in little packets. And not only did the packets contain the IP address returned by DNS (the address of the Web server you want the packets to reach), they also contained YOUR IP address. (Surprise.) Now it's the server's turn. It puts the file you've requested onto the Net, and, knowing your IP address, it sends this page to your IP address... to your PC, for your browser to display for you. Of course, there's most likely no direct link from the Web server to your PC, and so your page bounces about the Net a bit first. It goes through special devices called routers, which connect different little networks. (Routers are kind of like the "pathfinders" of the Net. See now how the Web is different from FTP, who grabs two dedicated connections?.) So once again, what's this HTML thing? The page that you see now on your Web browser is written in HTML. It's not a fancy language, but it's a step up from plain text. It allows formatting text and displaying pictures. As browsers become more sophisticated, HTML continues to grow. And many pages are enhanced by a language called Javascript; or the pages may contain Java Applets. Can you have your own Web site for all the world to see? Sure. Many ISPs throw in 20-25 Meg of disk space free, adequate for many Web sites. Then, just create some Web pages with an HTML editor (like FrontPage) and upload them (using FTP) to your ISP. Hundreds of millions of people about the world will then be able to explore your site, surely a rare treat for them. E-MAIL Of all the services available on the Net, the one service by far that the most people use (as of 2006) is e-mail. You know what e-mail is and how it works, right? Wrong. So let's you and dog Wolf have a brief chat about what you REALLY should know about e-mail. Mail is transferred over the Net by a protocol we've not discussed yet (is that possible?), SMTP, the Simple Mail Transfer Protocol... it's been used to transmit mail about the Net since its earliest days. (Now if anything makes sense, it makes sense that this is what we'd use to transmit e-mail about the Net. SMTP is an OLD creaky protocol... been here since about 1982... but it gets the job done.) Actually, SMTP is a little like FTP... they're both simple, to be totally honest. There's far too much e-mailing and FTP-ing to make these protocols complex. When the Orioles play downtown, they charge $3 for a ticket, not $2.98... lots of folks buying tickets... you want to keep things simple, sell 'em fast, move the crowd right along. (Yes, it's been a while since I've been to the ballpark.) So... you write a message for me on your e-mail client (Eudora, Outlook Express, whatever it may be), you address it to... wolf@comcast.net ...and you press SEND. And our old faithful friend, TCP/IP, moves your letter from your PC to the mail server at YOUR ISP. Here, it's placed in a queue, often called a "spool." Then (hopefully within seconds) SMTP reads the header on your e-mail and moves it to the SMTP server at... comcast.net ...my ISP, and the destination for your e-mail. To get from your ISP to my ISP, your e-mail bounces about the interconnected computers that make up the Net, courtesy of TCP/IP. And there are lots of "hellos" and "handshakes" before the actual message is sent. The PATH from your originating mail server to my receiving mail server is very much ad lib. (Ever look at the header of the e-mail you receive? See the received by (recipient's server) and received from (senders's server)? The ID and arrival and departure times at each leg are recorded here. Just yet another tidbit of Net knowledge for you.) Your message is then queued (spooled) in my password protected mailbox out there on the Net at my ISP in what's called a "POP Mail Server." To retrieve your letter (and all the others that have accumulated for me), I'll log onto the e-mail server at MY ISP, using MY e-mail client; and, using the POP3 protocol, I'll check for messages, download any that are there, and delete them from my ISP's POP mail server. POP enables my desktop client, like Eudora, to download my mail from my ISP's mail server "out there" on the Net. OR... perhaps my ISP has the newer "IMAP mail server and archive," instead of a POP mail server. IMAP servers can store mail just about forever. And I can view the headers first before downloading my mail, and I can download only what I want to read, using an "IMAP Session," instead of POP3. You can also send me binary files along with your letters... programs, photos, whatever. Eudora, at your end, will code binary (non-text) files using text characters; and my e-mail client will decode the text (or ASCII) characters back to binary. It's easy, as long as the e-mail clients at both ends support the MIME coding scheme (stands for Multipurpose Internet Mail Extensions). (How does AOL (America Online) do the e-mail thing? Since AOL doesn't have SMTP servers out on the Net, you can't get your mail from any PC that doesn't have AOL installed. AOL uses special servers called "SMTP Gateways" to exchange e-mail with the SMTP servers out on the Internet. (Unfortunately, these special gateways are slow, expensive, hard to set up, and notoriously unreliable.) As of 2006, you CAN look at your AOL e-mail on any PC that has a Web browser; but you need a PC with AOL installed to actually download the mail.) With POP3, I download all the mail. Actually, once I log onto my ISP, I set my e-mail client program on my PC (Eudora) to query my ISP's mail server every 15 minutes to see if I have any new mail and to download any new mail to my PC and delete it from my ISP's server once I've downloaded it. And as for SMTP, I don't want to say much more about it. It works, but so does citrate of magnesium; and neither one really makes for a pleasant reading experience. IRC IRC. Internet Relay Chat allows people in a channel (room) to converse by typing. It also allows two people to have a private conversation using what is called DCC. (DCC is an extremely private method of having converstaions on the Net.) DCC also allows two people to exchange files, again with great privacy. There are many different "Universes" of IRC chat, each with hundreds, thousands, or tens of thousands of chat channels. Go wild. Download mIRC and play with IRC for a few days; if you like it, pay a few dollars and buy mIRC. IRC is just too rich and diverse and cool and complex to cover decently on this page; soon your dog Wolf may write an entire page devoted to IRC. For now, we'll just say that IRC is very very cool. And if you like to dabble in Net things, IRC is for you. Usenet Now we're coming down to the home stretch. UseNet (usually written as Usenet), stands for Users' Network... and it's not a network. It's a way to post messages (articles). Such posted messages allow online discussions in over 50,000 newsgroups, where related topics are discussed. UseNet is a potent way to reach a LOT of people fast. Next to the Web and e-mail, it's the most popular part of the Net. Usenet is probably the greatest way in the world to get information. Post a question to the appropriate group, and you're certain to get a response from someone, often the ultimate guru on the subject. DAwn posted an article on networking and Turing machines and received a response from a professor at M.I.T., one of the world's foremost authorities on computability. And when I had what appeared to be algae in my water bowl? Right, a post to animals.dogs.waterbowls ended that problem. Questions about taking a cruise? The folks who read and post to rec.travel.cruise will surely have the answers. The client that runs on your PC to make Usenet possible is called a newsreader. It does lots of things (like sending mail), but mainly what it does is allow you to read articles in newsgroups and post new ones (or... respond to old ones). Where did Usenet come from? Back in the '70s, a version of UNIX came out with a program called UNIX to UNIX copy, or UUCP. Two gurus at Duke used UUCP to exchange messages between their hosts, and Usenet was born. When I post an article to my ISP's news server, it's stored on disk, then sent to other news servers that have agreed to exchange articles with my ISP. These in turn send my article to still other news servers, and a chain reaction builds. Finally, every host that participates in Usenet has my article, and folks all about the world are saying, "Hey, dog Wolf has posted; he always makes such great and cool points... let's see what the old fella has to share with us this day." Posted articles are given headers, which, for one things, allow them to be sorted into the right newsgroups. Or, perhaps my article applies to both rec.pets.dogs and alt.aol-sucks, and I select both for it? Then it's placed in both (or a pointer to it is). Such multi-newsgroup posting is called cross-posting. Usenet relies on the NNTP (Network News Transfer Protocol). Your newsreader client uses NNTP to read existing articles and to post new ones. And Usenet uses NNTP to distrubute articles among all the participating news servers around the world. Now news servers... very efficient servers they be. Current messages are stored locally on each server. Your retrievals and posts go quickly to and from the local server, minimizing the amount of traffic on the Net. A news server only needs to receive and store a message once, no matter how many people subsequently want to retrieve it. Compare this with the Web, where every request has to send pages from the originating server across the whole Net to your browser; if 1,000 folks request the same Web document, it has to be sent over the Net 1,000 times. The same for e-mail messages. But NNTP, he's very efficient. ...And that, my friends, is all that I think you need to know for now, this incredibly mild January of 2006.

We love your comments... want to send your feedback to us? Our E-Mail link is...

comments@precisenetworking.com

The technical consultant for this article holds a graduate degree from The Whiting School Of Engineering of The Johns Hopkins University, along with an FCC first-class radiotelephone license with ship radar endorsement. Numerous years ago (when just a "youngster"), he was employed as an FM transmitter engineer and a color TV broadcast engineer. He curremtly holds an executive position with Precise Networking Solutions.

The text on this Web page, along with its HTML representation, are copyrighted by Precise Networking Solutions and other authors; appearance on this Web site constitutes this work's publication under Law, in accordance with both US Federal Law and all applicable international agreements. No part of this work may be reproduced in any manner without the express written consent of the authors. Any unauthorized reproduction constitutes a violation of copyright. External hypertext links appearing in this article are copyright of their respective authors.