The World Wide Web is a really big place. Really big. There are quite literally hundreds of billions of pieces of data on the web, and in order for the average user of a browser to find them, each requires a unique name that is known to the rest of the web.

So, when the Internet was beginning to form, it became necessary to establish a standard naming system for files, and that system is organized into URLs which are Uniform Resource Locators. A URL has several parts. It's not just a file name, but it is all of the information about that file that makes it unique among all the other billions of files on the web. URLs on the web are usually constructed in two parts: the server name and the file name.

The server name half of a URL starts with something called a "top level domain," which is a set of the largest categories of web servers. Everyone recognizes top-level domains like ".com" and ".net" From those domains, a server is further and further categorized until it becomes absolutely unique on the web. After the top-level domain, there is a domain name like Hubpages, which is sometimes followed by something called a "subdomain."

Subdomains are usually used to identify different servers within a domain name, but the most common is "www" which means "world-wide-web." The combination of the top-level domain, the domain name and the subdomain forms the server name half of the URL.

Domains are written in reverse, with the top-level domain furthest to the right, and the other parts of the name added to the left. Server names are written as "subdomain.domain.top-level domain" or "greatarticles.hubpages.com" All of these names together identify the "webserver" where the file is stored, which means basically those names identify a unique filesystem on the web where the file name half of the URL is guaranteed to be unique.

The best way to visualize how URLs work is to consider they are very similar to a phone number. Phone numbers must be unique throughout the entire telephone network, just like URLs, otherwise dialing a particular number would cause more than one phone to ring. So one possible model is to think of a top-level domain like ".com" as the area code, the domain name as the three-digit prefix, and the file name as the last four numbers.

Once the server has been found, it is from there a simple matter of finding the particular file within that server's file system, but there is one more piece of information that a URL requires in order to function. That is the protocol.

Every URL is written with a protocol preceding the domain and file information, written as "http://" for example. This is because web servers can make information available in a variety of formats and from a variety of services. There is no data in a phone number that can readily be compared to a protocol, but what would be similar would be to consider what language is being spoken during the call. It is the same for web servers. Without the protocol, a web browser might ask for an HTML page, but because it is talking to the e-mail server, it wouldn't be able to make the request or receive the correct data. The protocol requires the browser to speak in the correct language so that the web server can understand its request and find the file.

Once the browser has identified the correct server and has made sure it is speaking the right language, it can then request the particular file it needs. It doesn't really matter what format the data is in. It could be a web page, the latest top 40 hit on iTunes or a satellite map of Antarctica. All file requests follow the same procedure.

Now within the file name half of the URL, it is possible to pass data to a web server. This is most often in order to tell a page what data should be used to operate a service on a PHP page, for example. This data usually follows something called a "delimiter" which is a technical term for "random character that divides the file name from the data." The "?" character is a commonly used delimiter.

Every single file request made by a web browser follows this entire process, starting with the top-level domain. Even on very complex pages made up of hundreds of files, the browser can't take any shortcuts, because if one part of the URL is missing, we're back to the "two ringing phones" problem. Having two files with the same name is something called a "name collision" by programmers, and it can cause all manner of hilarity for servers and operating systems.

Links on web pages also include all of the information required to construct a well-formed URL because again, browsers have to follow the entire process in order to isolate the individual file requested from the billions of files available to it on the web. Links are added to web pages through the use of something called an "anchor element" which is an HTML element that identifies a particular location on a web page.

Just about anything can be an anchor element, from a single word to a sentence to a satellite map of Antarctica. In the early days of the web, individual sections of an illustration could be anchors, making it possible to have clicks on each different region of Antarctica bring up a different page, for example. Anchors can even point at different sections of a web page, meaning a browser would automatically scroll to a particular section of a large document after the original element was clicked.

But none of this changes how URLs work. Organizing the fantastic volume of information on the Internet requires a taxonomy at least as complex as phone numbers, and even that doesn't take into account the nearly infinite possible protocols that can be made available by individual web servers. And, just like the phone system, people still speak many languages.

The URL has been entered. Your browser has found the top level domain and the server. It is using the correct protocol and it has the file name for the glorious Antarctic map as seen from space. Everything is working. Then...

"Site under construction."

Well, nobody said the system was perfect.