By Gail Seymour
When Internet users type in a URL or click on a link in their browsers, the browser generates a request for a file. Before that file can be delivered, many things have to happen. Let’s use a request for https://www.hostway.com/web-resources/ as an example.
Resolving the Domain Name
First, the browser has to determine where to send the request. Although humans use memorable names to distinguish between domains, those names are no good to computers. Computers recognize each other through IP addresses, a series of numbers separated by dots.
In our example, www.hostway.com resolves to 84.40.33.30. When a computer requests this page for the first time, however, it won’t know the address of the hostway.com domain’s Web server, so it has to ask another machine that specializes in pairing up human and machine addresses, a Domain Name Server (DNS). The DNS will either return an error message if the domain is invalid, or return the IP address to forward the request.
Sending the Request
To get the request from one machine to another across phone lines or wireless networks, the request has to be translated into binary data for transmission. In order to prevent large chunks of data blocking the communication channels, this data is broken down into “packets.”
These packets are then forwarded to the target computer using the Internet Protocol to direct traffic and the Transmission Control Protocol to reconstitute the packets at the other end. Internet traffic is based on this TCP/IP protocol.
Routing Tables and Hops
Each routing machine receiving a packet through the TCP/IP protocol has to decide what to do with that packet. First, it will look in its routing tables to see if the IP is listed there, meaning the target machine is within its network. If it is, it will use the routing tables to determine the quickest route to the target, and direct the packets to it that way.
If the target machine is not in the router’s routing tables, it will pass the request through a default path, further up the hierarchy, closer to the Internet backbone, to a router with a wider network and larger routing database. Thus, the request will travel “upstream” until a router that recognizes the IP address is located, and directs it “downstream” to the target machine.
Each of these redirects is known as a "hop," and increases the distance the request has to travel, and the time taken for the request to reach its destination. You have no control over how far away from the Internet backbone your visitors’ machines are, and thus have no control over the number of upstream hops required. So, as a website owner, the best thing you can do is ensure your site is hosted on a machine near the top of this hierarchy, and thereby reduce the number of downstream hops required to reach your machine. We’ll look at this in more detail in later articles. For now, let’s take a brief look at what happens to the request once it reaches the server.
How the Web Server Handles Your Request
When the server receives the information packets, they are reconstituted using the TCP protocol, and recognized as a request for an http file. In our example, everything so far has dealt with the handling of the https://www.hostway.com part of the request. The server now looks at everything that comes after that, in this case “/web_resources/.” That translates into a request to serve the index file of the folder “web_resources” on the hostway.com Web server. The request can then be handled in one of two ways:
Static files
If the request is for a static html file, the Web server will fetch the file, translate it into binary code and return the file to the requesting IP address.
Dynamic files
When the request includes server side scripts, such as .asp or .php pages, the Web server will pass those requests to the relevant script interpreter. The interpreter will execute the code, and translate the output into static html before returning it to the Web server. The Web server will then return the file to the requesting machine.
The download speed of your pages will depend more on their content than on the location of your Web server, with cumbersome scripts adding seconds as opposed to the extra milliseconds of a few extra hops. However, the benefits of hosting your website on a server close to the Internet backbone are not limited to the speed of an individual connection.
Connections closer to the backbone are higher capacity, often fiber optic or satellite connections rather than copper wire phone lines. This means they can handle more simultaneous connections with degradation of service.
Data centers close to the backbone are also more likely to have multiple connections, so if one fails, your website does not go offline while repairs are made, the connection is simply switched to an alternative route for the duration.
About the Author:
Gail Seymour has been a website designer for more than 10 years. During that time she has won three design awards and has provided the content and copy for dozens of Web sites and more than 50,000 Web pages.