Google.com <enter> interview question

gistfile1.md

This was my very first take with no research on what happens when you press in Chrome with Google.com in the address bar:

• press enter on keyboard
  • some switch gets connected
  • hardware encodes signal for key to go over USB
  • sends signal over USB
• computer gets enter signal
  • driver gets signal from keyboard
  • signal translated into an OS-level event probably was pressed
  • OS knows what program has focus, dispatches event to that program
• chrome gets signal
  • validates URL
    • probably a regex, to make sure it needs to get looked up vs. searched for in omnibar
  • DNS lookup
    • OS cache first, can expire with TTLs per domain
    • OS has an entry for what DNS server to use
    • UDP packet goes out, contains the domain to lookup
    • DNS server returns an IP for the server you asked about
  • TCP connection to IP address established
    • syn -> ack handshake starts to make connection and set boundaries like congestion window
    • request is sent over TCP, and the packets contain enough information to be an HTTP request (GET google.com)
• google servers receive GET request
  • http headers come with cookies to establish identity
  • return IP address indicates geolocation
  • servers to personalization of the document to return, maybe DB lookups, fancy string concatenation
  • servers send back document
    • numbered TCP packets again, resend where necessary
• chrome receives HTTP response
  • packets are ordered, verified for completeness (during transfer, lack of ACK means resend that packet), and compiled into an HTTP 'response'
  • HTML document is parsed
    • string response has a doctype on line 1, this says what parser to use to understand the document
      • used to be xhtml strict wouldn't spend time on edgeless and error correction. this area seems so fast now though that no one cares
    • using that ruleset, document is parsed into the DOM, a tree of nodes in javascript (and maybe somewhere in C land also?)
    • additional resources indicated in document requested
      • as the document is parsed, link and script tags generate additional HTTP requests for those documents
        • if they're on the same server, the same established TCP connection gets reused by the browser, much faster
      • scripts are run in the global scope as they are downloaded
        • additionally, parsing of the HTML document stops while downloading, hence (usually) scripts at the bottom
      • CSS styles are parsed and made into a set of styles for the page
  • page is drawn to the screen
    • chrome goes through a compositing and a painting phase
      • compositing I think is where CSS gets applied to the DOM, so you get a non-rendered tree of nodes with styles
      • painting is where all of those styled nodes get turned into pixels to be send to the OSs 'make pixels' API