What happens when we type a URL in the browser (In Depth)?

If you are reading this then i would recommend to read this  article first for a clear visibility that what we will understand in depth 🙂

https://jogendras.wordpress.com/2017/07/17/what-happens-when-we-type-a-url-in-the-browser/

Have you ever wondered, precisely – 

• What happens in the background when we type a URL in the browser?
• How does a web page life-cycle sequence work?
• How browser knows, where to send request for the requested page?
• What happens on the Web Server when a request for a web page comes in?
• How does the Web server handle the incoming request?
• How is the HTML that is emitted to the client generated?
• How browser renders the page on the screen?
• Etc…

If you are also looking answers of above mentioned questions then this article is definitely for you. In this article, we will take a deeper look at the sequence of events that take place when we visit a ASP.NET page URL –

1. URL is typed in address bar of the browser
2. The browser parses the URL to find the protocol, host, port, and path. Ex- http://www.jogendras.com/about/ will be parsed as-
   • Protocol – http
   • Hostname – http://www.jogendras.com
   • URL path – /about
3. Browser checks cache, if requested object is in cache and is fresh then return response from cache.
4. The browser looks up the IP address for the entered domain name.  When we want to connect to www. google.com, we actually want to reach out to a server where web application is hosted. One such server is having an IP address of XX.XXX.XXX.XX. Now, if we type http:// XX.XXX.XXX.XX in the browser, this will take us to www. google.com itself. Which means, www. google.com and http://XX. XXX.XXX.XX are nothing but same stuff. But, it is not so. 
   As google has multiple servers in multiple locations to cater to the huge volume of requests. Thus we should let application decide which server is best suited to our needs. Using www. google.com does the job for us. When we type www. google.com DNS services comes into play and resolves the URL to a proper IP address. The DNS lookup proceeds as follows-
   • Browser cache – The browser maintain cache of DNS records for some time. So, this is the first place to resolve DNS queries. If not found in browser’s cache then it makes a system call to underlying OS to fetch the record.
   • OS makes a DNS lookup and replies the IP address to the browser: OS uses the DNS client service to find the IP address- win + r => services.mscIt first checks in Hosts file and then-
     • OS cache – If not found in hosts file then it checks in OS local DNS cache.
     • Router cache – If above steps fail to get a DNS record, the search continues to your router which has its own cache
     • ISP DNS cache – If above also fails then search moves on to ISP’s DNS server, first, it tries in its cache if not found then ISP’s DNS recursive search comes into the picture.
     • Recursive search – If everything fails then recursive search begins from the root level namesever.  For the DNS enthusiasts – here is a great guide worth reading
5. As, now browser knows the domain’s IP address so a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
6. When a connection is open browser sends the HTTP request to the host server.
7. On the server protocol listeners receive protocol-specific requests. In this case we have http request so HTTP/S listener i.e http.sys (Hypertext Transfer Protocol Stack) first listen the http request from network. Now, HTTP.SYS is Responsible to pass the request to the particular web server application i.e IIS or Apache etc.. and send response back to the client browsers… Let’s assume we have .net web application request so request will go to IIS.
   • HTTP.sys contacts WAS to obtain information from the configuration store
   • WAS requests configuration information from the configuration store, applicationHost.config
   • The WWW Service receives configuration information, such as application pool and site configuration
   • Now we know the application pool so WAS starts a worker process(w3wp.exe) for the application pool to which the request was made.
   • The worker process “w3wp.exe” looks up the URL of the request to load the correct ISAPI (Internet Server Application Programming Interface => a low level unmanged Win32 API) extension. ASP.NET interfaces with IIS through an ISAPI extension. ISAPI is the first and highest performance entry point into IIS. 
   • Depending on the extension ASP.NET routes the request to an appropriate handler that is responsible for picking up requests.

Coming Soon….. 🙂

 

https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture

Beginner’s Guide: How IIS Process ASP.NET Request

 

Programming is Easy…