What exactly happens when you browse a website in your browser?

Browser: "Ok, so, I have a user requesting this address: www.cnn.com. I figure since there are no slashes or anything, this is a direct request of a main page. There was also no protocol or port defined, so I'll assume it's HTTP and going to port 80... oh well, first things first. Hey DNS, pal, wake up! Where is this www.cnn.com hiding at?"

DNS: "Right... wait a sec, I'll ask the ISP servers. Ok, it looks like 157.166.226.25."

Browser: "Ok. Internet Protocol Suite, your turn! Call 157.166.226.25, please. Send them this HTTP header. It's asking for the basic structure and content of their main page so I know what else to fetch... oh well, not that you'd care about this I guess. "

TCP/IP: "What do you mean my turn? Like I wasn't just working my back off right there for the DNS? God, what does it take to get a bit of appreciation here..."

Browser: ...

TCP/IP: "Yeah, yeah... Connecting... I'll just ask the gateway to forward it. You know, it isn't all that easy, I'll have to divide your pretty request there into multiple parts so it reaches the end, and assemble any stuff they send back from all the thousands of packages I get... ah, right, you don't care. Figures."

Meanwhile, at the CNN headquarters, a message finally ends up at the door of the Web Server.

CNN Web Server: "Nzhôô! A customer! He wants news! The Front Page! How about it?"

CNN Server Side Script Engine: "Right, will do! Front page, right?"

CNN Database Server: "Yey! Work for me! What content do you need?"

CNN Server Side Script Engine: "... um, sorry DB, I have a copy of front page right here in my cache, no need to compile anything. But hey, take this user ID and store it, I'll send it to the customer too, so we know who we're talking to later on."

CNN Database Server: "Yey!"

Back at the user's computer...

TCP/IP: "Ooookay, here comes the reply. Oh boy, why do I have a feeling this'll be a big one..."

Browser: "Uh, wow... this has all sorts of javascript code... bunch of images, couple of forms... Right, this'll take a while to render. Better get to it. Hey, IP system, there's a bunch more stuff you'll need to get. Let's see I need a few stylesheets from i.cdn.turner.com - via HTTP and ask for the file /cnn/.element/css/2.0/common.css. And then get some of those scripts at i.cdn.turner.com too, I'm counting six so far..."

TCP/IP: "I get the picture. Just give me the server addresses and all that. And wrap that file stuff within the HTTP request, I don't want to deal with it."

DNS: "Checking the i.cdn.turner.com... hey, bit of trivia, it's actually called cdn.cnn.com.c.footprint.net. IP is 4.23.41.126"

Browser: "Sure, sure... wait a sec, this'll take a few nsec to process, I'm trying to understand all this script..."

TCP/IP: "Hey, here's the CSS you asked for. Oh, and... yeah, those additional scripts also just came back."

Browser: "Whew, there's more... some sort of video ad!"

TCP/IP: "Oh boy, what fun that sounds like..."

Browser: "There's all sorts of images too! And this CSS looks a bit nasty... right, so if that part goes there, and has this line at the top... how on earth would that fit anymore... no, I'll have to stretch this a bit to make it... Oh, but that other CSS file overrides that rule... Well, this one ain't going to be an easy piece to render, that's for sure!"

TCP/IP: "Ok, ok, stop distracting me for a sec, there's a lot to do here still."

Browser: "User, here's a small progress report for you. Sorry, this all might take a few secs, there's like 140 different elements to load, and going at 16 so far."

One or two seconds later...

TCP/IP: "Ok, that should be all. Hey, listen... sorry I snapped at you earlier, you managing there? This sure seems like quite the load for you too."

Browser: "Phew, yeah, it's all these websites nowdays, they sure don't make it easy for you. Well, I'll manage. It's what I'm here for."

TCP/IP: "I guess it's quite heavy for all of us these days... oh, stop gloating there DNS!"

Browser: "Hey user! The website's ready - go get your news!"

How the web works: HTTP and CGI explained

Also a great explanation from CERN - alma mater of Web: How the web works

• Browser splits what you type (the URL) into a hostname and a path.
• Browser forms an HTTP request to ask for the data at the given hostname and path.
• Browser performs DNS lookup to resolve the hostname into an IP address.
• Browser forms a TCP/IP connection to the computer specified via the IP address. (This connection is actually formed out of many computers, each passing the data along to the next.)
• Browser sends the HTTP request down the connection to the given IP address.
• That computer receives the HTTP request from the TCP/IP connection and passes it to the web server program.
• Web server reads the hostname and path and finds or generates the data that you've asked for.
• Web server generates an HTTP response containing that data.
• Web server sends that HTTP response back down the TCP/IP connection to your machine.
• Browser receives the HTTP response and splits it into headers (describing the data) and the body (the data itself).
• Browser interprets the data to decide how to display it in the browser - typically this is HTML data that specifies types of information and their general form.
• Some of the data will be metadata that specifies further resources that need to be loaded, such as style sheets for detailed layout, or inline images, or Flash movies. This metadata is specified again as a URL, and this whole process repeats for each one until all are loaded.

The first step is the DNS (Domain Name Server) lookup. It uses the DNS servers specified in your network settings (or given to you by DHCP) to lookup the top domain (cnn.com) and then ask that domain's nameserver for the IP address of the subdomain specified (www.cnn.com).

After it has the IP address, your browser begin communications with the web server. This is done using the specified protocol (which usually defaults to HTTP 1.1). A 'GET' request for '/' is made to the server, which responds with the HTML document contents and the appropriate headers (which tell the browser of the document's content-type, HTML, and other information). Then the browser parses the document and finds any URLs which it needs to embed in the page (like images or linked stylesheets) and does GET requests on each of those.

The browser also usually automatically makes a GET request for '/favicon.ico' (to display the little CNN icon next to the site title).

Your browser will also likely specify in its request headers that it wants the response content to be compressed, using the gzip algorithm. This makes the file download much smaller, if the server supports it. This is all transparent to you, even though it's like downloading a ZIP file and unzipping it.

When you reload the page, your browser checks if that page is already cached in your system, and if so, it does an HTTP request just for the header of the document, and checks its modified date. If this date is later than its cached copy, it requests the full document contents again and refreshes the page. Otherwise it just uses your local copy.

Missing so far from the other answers is what happens on the CNN side:

• A machine at CNN receives the message from your computer asking for the page.
• It redirects this request to one of the many computers CNN is using for its web site (the reason for this is that, this way, you can spread the work of putting together the response web pages over many computers)
• The CNN computer gets your request and it responds with a web page that's probably almost entirely precomputed, but maybe it'll change a few things before sending it to you (could be the ad at the top, maybe headline news). Sometimes computers assemble the page from lots of small components every time they get a request; not sure what CNN does
• the response makes its way through the network to your computer, which then displays it.
• the response didn't include the images: your computer then sends another request for the images, and pretty much the same scenario happens.