I will be describing the lifecycle using the ASP.Net MVC framework hosted on IIS on Windows. I will be describing the case under the assumption that the application is using .Net Framework 4.7.2 and not .Net Core. I am doing this based on what I have worked on in my current role.
https://webapplication.com/
- The browser expects the URL to be in the format : scheme://host:port/path?query#fragment
- In this case the scheme is https which determines the default port to be used is 443. In this case the host is webapplication
- The URL format above is adhered in this case and now the browser knows the hostname which it needs to resolve to an IP Address.
The browser will start to find the IP Address from the cache of browser or the next is to lookup in the host file of the machine, Windows has a local host file.
- Once the cache lookup fails the browser sends a DNS request which using UDP. The request is forwarded to the ISP's DNS Server.
- Assuming that the request message is received by a DNS Server the server looks for the IP address associated with the requested hostname, if the address is found then the response is sent back else DNS recursively forwarded to the next configured DNS server until the address is found.
- Assuming that the response of the UDP request is back the requesting client will now have a target IP Addressed which will be cached so that next set of requests do not have to go through multiple DNS hops.
- Now that the client has an IP Address, browser can send the https request which is a application level protocol and uses transport layer security. The request at lower level uses the TCP which is a transport layer protocol which ensures the delivery of data in the same order as it was sent.
- The browser in this case opens a TCP connection which is a 3 way hand shake, here's an example of how this interaction looks like
First Step: Browser: ---(Sends SYN=1234) ---> :Server
Second Step: Server: ---(Sends SYN=4011 ACK=1235)--> :Browser
Third Step : Browser: -- (Sends ACK=4012) --> :Server
- Now that a 3 way handshake is completed an connection is established, now we are ready to send a https request. Ahh wait, Not quite yet because we are using https here.
- Since the scheme in the URL was https After the TCP handshake there's a TLS HandShake, with TLS the client and server
adhere to the common ground of secure communitcation. Here's a small snippet of what a TLS HandShake looks like :
Client Hello ---(TLS Version, Cipher Suites, Client Random) --> Server
Server Hello --- (SSL Certificate, Cipher, Server Random) --> Client
Authentication --> Client verifies the SSL Certficate
Client --> Sends a premaster secret which is encrypted using the cipher and public key
Server --> decrypts the premaster secret using the private key.
Both Client and server generate session key using the information exchanged above, the result should be the same.
Client sends a finished message with SessionKey
Server sends finished message with a sessionKey.
Symmertic encryption is acheived and communication can continue using the session keys.
- The client now sends a https request which contains http Method (GET, PUT, POST or DELETE), in this case its a GET since the browser is requesting a resource from the server.
In this case the http request may look like
GET http/1.1
Host: webapplication.com
- Assuming that the web application is hosted by an IIS Server and is build using the ASP.Net MVC.
- The httpRequest reaches the IIS Server which based on the domain identifies the correct web application to service the request.
- I will not go into the detail of how IIS processes the request, instead we will assume that IIS makes sure that the request reaches the correct the web application.
- Now we will dive into begining from receiving the http request from the browser to sending the http response back within the the ASP.Net MVC pipeline.
- At a highlevel MVC Pipeline has the following processes in order : Routing --> Controller Initializtion --> Action Execution --> Result Execution --> View Initializtion and Rendering.
- https://webapplication/ , assuming there's no overriding of the default route map, UrlRoutingModule starts matching the perfect URL pattern from the RouteTable,
the request will be routed to https://webapplication.com/home/Index, Controller which will be Initialzed is HomeController and the Action is Index
- Once the URLRoutingModule finds the controller the appropriate controller is instantiated, appropriate action on the controller is invoked in this case Index.
- Assuming the browser requested a resource which does not require authentication or authorization to access. Hence no authentication and authorization filters will be called.
- As stated earlier in assumption that this is a GET operation the model binders will not play a role.
- After the execution of Action the ActionResult is generated. This step completes the action execution.
- ActionResult can be of many times for example ViewResult, RedirectToRoute, JsonResult. Let's make an assumption that we get a ViewResult back.
- ViewEngine along with HTMLTagHelpers render the view and create a http Response with Body and applicable httpHeaders.
- Once the response is generated At TCP layer the client receives the data which contains the httpResponse Header.
- Assuming that the response is fully received by the client then there's a way 4 handshake to close the connection between the browser and the server.
(FIN <--> ACK)
Above discription is a simple interaction in a non-persistance interaction.
Sources:
https://github.com/hardikvasa/http-connection-lifecycle
https://dev.to/dangolant/things-i-brushed-up-on-this-week-the-http-request-lifecycle-#fnref10
https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
https://www.cloudflare.com/learning/ssl/keyless-ssl/
https://www.c-sharpcorner.com/article/mvc-architecture-its-pipeline4/
No comments:
Post a Comment