13

I've had interviews with 5 separate people over the past two weeks and three of those five have all asked me this question: Explain what happens between hitting "Google.com" and the page coming up on the screen. Basically, how the Internet works. I figure after three times that I better be prepared if I ever get this question again.

I know some things, but I'm not fully convinced that my answer is good enough. Basically, I mention that the DNS server translates "google.com" into an IP address. I kinda gloss over TCP/IP, then talk about the web server literally serving up requested pages that get sent back to the browser which the browser then interprets and displays.

As I said before, I'm not convinced my answer is technical enough. What are the steps that I'm leaving out?

For what it's worth, two of those three times have been with the same company and I'm being called back for a third interview with them, so I can't have bombed it too hard.

gnat
  • 21,442
  • 29
  • 112
  • 288
Megacannon
  • 239
  • 1
  • 2
  • 5
  • 1
    What is the nature of the positions you were interviewing for? – smp7d Sep 11 '13 at 19:42
  • 3
    If three out of five interviewers asked this question, it's time for you to *do some study/research and obtain a good answer that demonstrates that you fully understand it.* If you are being called for a third interview at the same company and you are asked the question again, you will either demonstrate that you cared enough to shore up your knowledge, or you didn't. – Robert Harvey Sep 11 '13 at 20:04
  • 1
    In addition, I would try to narrow the scope of the question by asking which part of the process are they most interested in. They may not care that you know deeply about things like the [seven layers of the OSI model](http://en.wikipedia.org/wiki/OSI_model), for example, but you should still have a working knowledge. – Robert Harvey Sep 11 '13 at 20:10
  • 1
    On the other hand, maybe the answer is too technical. Perhaps they are looking to see how you can relate information to people in a non-technical way? – hookenz Sep 11 '13 at 21:32
  • 1
    If the question is asked to see how well you communicate, then perhaps it's good to ask questions back regarding the question rather than just give a answer to a very broad question. You could give a very detailed technical answer and take all day to explain it. I don't think that's the purpose of the question. – hookenz Sep 11 '13 at 21:35
  • 1
    It's worth pointing out that this question is a good measure of how well you understand a particular part of the stack. They're not looking for a complete description of the process, but rather they're trying to find out where the gaps in your knowledge are and whether the knowledge you have is relevant to the position they're hiring you for. – greyfade Sep 11 '13 at 21:50
  • 1
    [Related: What Happens When](https://github.com/alex/what-happens-when) – kojiro Jan 04 '15 at 03:21

2 Answers2

30
  1. Your browser first has the OS look in its "hosts" file for an entry that will translate the domain name to an IP address. This is a legacy feature inherited from ARPANET, when it was possible for a single text file to contain intelligible names for every computer accessible via the ARPANET, and for each computer connected to it to have a relatively recent copy. It used to have some remaining value in small networks of computers that didn't have NetBIOS or similar node-naming protocols, but nowadays it's as likely to be a target for hackers (who can use it to bypass DNS and point your computer to sites they control) as to have any legitimate use to a client computer or its user/owner.
  2. Assuming your computer doesn't have a HOSTS entry for this domain, your browser sends a UDP request to the DNS server configured in the OS's Internet settings for the connection being used, passing the "host name" aka domain name of the request (everything between "http://" and the first colon or forward slash following what comes next; i.e. "www.google.com"). This DNS server typically belongs either to your company or to your local Internet Service Provider.
    • UDP stands for "Universal Datagram Protocol", and is a "transport-layer" protocol in the same class as TCP (above the "network-layer" IP protocol, below the "application-layer" protocols like HTTP, FTP, SMTP etc). While TCP provides for a lot of error-checking and fault-tolerance capabilities (adding extra data and so increasing the overhead), UDP takes a much more lightweight approach, increasing net data bandwidth; the tradeoff is that the protocol doesn't support features available in TCP like splitting up large data into multiple packets (so messages have to be small) or re-sending packets lost in transit. It's good for small, simple messages (like DNS) and streaming, telemetry-type data where it doesn't matter if one packet is lost.
  3. This DNS server will know one of three things: how to translate that domain name directly into an IP address (meaning it's the "authoritative name server" or ANS for that domain); the IP address of the ANS or a parent of it; or its own parent nameserver which is more likely to know how to reach the ANS. If the server does not translate the request itself, it will forward the request either "down" toward a known ANS, or "up" to its parent NS, and this process repeats recursively.
    • The "root" of this tree structure is a single server which does nothing but forward any requests it receives to one of a number of "top-level domain" or TLD servers. There is, for instance, a ".com" nameserver, who knows how to find the IP address of any ".com" domain on the planet (by forwarding these requests down to ISP-level nameservers). These TLDs forward requests for domain name servers that aren't known by any DNS within a specific "branch" of the internet belonging to an ISP.
  4. Once the authoritative name server is found and has translated the domain name into an IP address, this address is returned to the client and its browser. If an ANS cannot be found within the request's "time to live" (TTL; the maximum number of times the request should be forwarded between servers, to avoid infinite cycling between misconfigured servers), an error is returned to the client by the node at which the request "times out" (or the node that is the authoritative server for the domain but that cannot translate the particular domain prefix).
  5. The browser, for an HTTP connection, then sends a "TCP SYN" request to the IP address and specified port (or the default HTTP port of 80) to establish a connection. This is a protocol-level request, layered on top of the "network-level" IP header, that contains information such as the client's preferred response port (the "source port"), preferences for TCP communication such as segment size, window scale, and use of optional protocol features.
  6. The request is routed at the "link level" (governing how the actual electrical circuits are manipulated to transmit the data contained at the network, transport and application layers) through the structure of the Internet; typically the data will travel along a wire or fiber to your home's or business's "Central Office" (this is called the "last mile" and is typically the circuit representing the biggest bottleneck to bandwidth) which is more or less the "onramp" to the Information Superhighway. The CO then has access to high-bandwidth pipes (T-carriers, SONET, etc) that transmit your request, along with billions of others, across the globe to the CO of the destination, which forwards it to the destination server or network.
    • This "IP routing" works in a conceptually similar way as DNS resolution; "top-tier" ISPs are assigned entire "class A" IP networks (every address possible given a known first byte) by ICANN, and other ISPs know who owns that Class A network and how to get the data to that network's nearest "front door", using information in a "routing table". This top-tier ISP then leases blocks of addresses, some to local ISPs, others directly to corporate users, and these ISPs and corporations have routers that use the IP address (and their own routing tables) to determine whether to send packets down to other nearby circuits, sideways to other local ISP routers, or up to higher-tier trunks and routers.
  7. The server receives this request (provided it isn't rejected at a lower abstraction layer like the socket or a firewall), and if it decides to accept the connection it will send a "SYN-ACK" request-response step, both acknowledging the request and specifying its own preferences (including any of the clients' preferences that it can accomodate, but changing any that it cannot or that were not specified).
  8. If the client supports communication using the option set the server has provided, it will send an ACK response, and now the connection is "established".
  9. The browser next sends an "HTTP GET" request. The request includes the full URI of the resource requested by the browser (even though we know we're talking to www.google.com, we send that string as part of the request so that the server can, if it wishes, further interpret the domain name to direct the request). This request may include "cookies"; data stored on the client that can be given to the server to assist in processing the request efficiently and conveniently (such as identifying the preferences of the user).
  10. The server receives the GET request, and first decides if it wishes to honor it (the server may have been listening for requests to TCP port 80, but expecting messages from a different application protocol like FTP or VoIP; this is rare for port 80 but more common for other types of ports). We will assume it does accept it; the server then returns an HTTP response containing the resource requested (in this case, the HTML for the default page which is Google's ubiquitous search page). The response may also include "cookies", which the server asks the client to store (the client may or may not do so).
  11. The HTML is digested by the browser and rendered to draw the page in the browser window. While this happens, more HTTP GET requests for Javascript, style sheets, images, and other data that are needed to display all the content of the page in the manner prescribed by the HTML are sent by the client and the resulting data is provided by the server.
  12. In a bygone age, Google was based on static forms; you typed what you wanted to search for into the textbox and hit "Search" (or "I'm Feeling Lucky"). When you do this, an HTTP POST request is sent by the client to the server; the request contains the location, specified by the client, that the information should be sent to, and of course the information itself. This information is digested by the server, which uses it to find search results, and the server builds a page of these results which it sends to you. Or, it can transform the search terms into a "query string", and respond with a "redirect"; a request for the browser to send another request to a different URI specified in the message. The browser will do so, and then the server will build and transmit that page.
  13. In modern times, Google's front page is much more dynamic. As you type, JavaScript that executes on the client side within the browser sends what you're typing in to Google along a "side channel" (it uses the same protocols for communication, but because it's not the browser itself sending requests for entire pages, the browser screen is not cleared completely and re-drawn). For the front page, this is used to provide query hints (auto-complete suggestions for things you might be searching for because other people have done so recently); on the results page, it does the same thing but can also be used to provide real-time search results and completely redraw the page, without requiring a full page reload by the browser. These types of tricks fall under the general heading of AJAX (Asynchronous JavaScript and XML, although the competing JSON standard is used just as often for data formatting) and they are nearly ubiquitous in modern "web applications" to provide dynamic content over the relatively static, stateless call-and-answer model of the Internet.

This movie, which is the one they showed my freshman "Intro to IT" class in college, has the basics illustrated in friendly, analogous format. It's not technical by any means, but it provides a good conceptual overview of the pieces of this puzzle.

KeithS
  • 21,994
  • 6
  • 52
  • 79
  • 1
    This is a good answer, but glosses over a lot of details that most people would consider unnecessary. (I'm not saying you need to add these details; I'm only pointing out that there is a lot more going on than your post suggests.) – greyfade Sep 11 '13 at 21:48
  • 1
    Yes, you need to go into TCP vs UDP for DNS lookups. If TCP, you should go into the TCP 3-way handshake. It's probably safe to assume the system somehow has domain name servers defined (by DHCP or network configuration beforehand).... – Alan Shutko Sep 11 '13 at 22:06
  • 1
    @AlanShutko - I *do* mention the 3-way handshake; the back-and-forth SYN/SYN-ACK/ACK. I didn't mention UDP though it is the primary protocol for DNS. – KeithS Sep 11 '13 at 22:21
  • @KeithS, oops, you're right, I was looking for it when checking on DNS, not later on. DNS might fallback to TCP if there's a response larger than 512 bytes and it gets truncated. – Alan Shutko Sep 11 '13 at 22:33
  • Can anyone tell me what does ANS,ALD stands for in the above description? – John Oct 07 '15 at 22:32
  • 1
    ANS - "Authoritative Name Server", the DNS server that has direct knowledge of and responsibility for the endpoints of a particular domain name. ALD was a typo. The post has been edited to be more clear on both counts. – KeithS Oct 08 '15 at 14:38
1

Leaving out mentions of cookies and firewalls would be a couple of things missing here. There is something to be said for cookies being sent so that "Google.com" may recognize a user and serve up a page that may be different for someone not logged into Google. There is also the question of where is the person looking this up: Smartphone, tablet or regular computer(laptop or desktop)?

I wonder if there may be some side questions that you were meant to ask but didn't that could be a factor here. This is more of a question of how the Web works as the Internet would be a bit broader and include e-mail and other stuff I'd think.

My guess is that was more a test of your communication capabilities. Can you take a rather technical question and break it down so that technical and non-technical would understand it? What kind of questions would you return in being asked to explain someone bringing up the "Google.com" home page on their browser? Do you make a bunch of assumptions or ask the questions? In some ways I see this as a parallel to a white board question where things are left vague enough that either you'll ask questions so that you can give a precise correct answer or you make assumptions in giving an answer.

JB King
  • 16,795
  • 1
  • 40
  • 76
  • 5
    A question about the internet would in my mind be more asking about networking in general; how are routes found? What is the purpose and meaning of a packet and how do they transmit information? How is the TCP abstraction over packets work and why? But the question is really vague, maybe it's asking about HTTP, or HTML, or network switches, or ISPs and backbones or anything, maybe it wants to know how your NIC frame buffer is scraped and if the OS, CPU or the NIC does it... – Jimmy Hoffa Sep 11 '13 at 19:21
  • @JimmyHoffa: Indeed, it is a broad question. The interviewers who asked it worded it in such a way that I believe the focus is on the networking side of things--from page request to page get. There's a lot that goes on and I suspect that they'd be happy no matter which route I took so long as it was technical enough and I knew what I was talking about. – Megacannon Sep 11 '13 at 19:29
  • 1
    I too think they are after a non-technical answer to see how well you can communicate ideas. Often we lose the forest for the trees, can't see the broad picture. – hookenz Sep 11 '13 at 21:32
  • @JimmyHoffa, good point. You probably should start with the IP address of your DNS servers and determining whether they're on the same subnet via net mask, and if so, using ARP to find them. Otherwise a packet is sent to the gateway. – Alan Shutko Sep 11 '13 at 22:07