Skip to main content

DNS Resolution and Web Request & Response Architecture

748 words·
IT Theory Mermaid Flowchart
Table of Contents

DNS Resolution Process
#

  • Domain Name System (DNS) resolution process allows the translation from a domain name to an IP address

1. Query Initiation
#

  • The browser checks its local cache to see if the entered domain was recently requested and already knows the corresponding IP address

  • If the IP address is cached locally, the browser uses it and skipps the rest of the DNS resolution process

  • If the IP address is not found in the local cache, the browser sends a query to a recursive DNS resolver


2. Recursive DNS Resolver (ISP, Google, Cloudflare)
#

  • This is the DNS server configured in the network settings on the host or the router

  • If the recursive resolver does not have the IP address cached, it forwards the query to one of the root name servers


3. Root Name Server
#

  • There 13 root name server clusters globally are the highest level in the DNS hierarchy and manage queries for top-level domain (TLD) information

  • The root name servers do not directly provide the IP address of the requested domain, instead they point the recursive resolver to the appropriate Top-Level Domain (TLD) name server


4. TLD Name Server
#

  • The TLD name server is responsible for the specific top-level domain

  • For the example query “example.com”, the TLD name server for “.com” will be queried

  • The TLD server does not have the IP address of “example.com” but knows which authoritative DNS server has that information


5. Authoritative DNS Server
#

  • The authoritative DNS server holds the DNS records for the domain

  • They are typically managed by the domain owner or their DNS hosting provider

  • The authoritative DNS server return an A record (IPv4) or an AAAA record (IPv6)


6. Response and Caching
#

  • The recursive resolver finally returns the IP address to the browser

  • The browser then uses the IP address to establish a connection with the web server hosting the site using the HTTP or HTTPS protocol



HTTP Request & Response Flow
#

URL Architecture
#

Example URL (Uniform Resource Locator): https://www.google.com

  • https Protocol

  • :// Separator between the protocol and the rest of the URL.

  • www Subdomain

  • google Domain

  • com Top-level domain


Establishing a TCP Connection
#

  • Before sending an HTTP request, a TCP connection is created between the client (browser) and the server. The client initiates a TCP handshake with the web server:
sequenceDiagram participant Client participant Server Client->>Server: SYN (SYNchronize request) Server->>Client: SYN-ACK (SYNchronize-ACKnowledgement request) Client->>Server: ACK (ACKnowledge confirmation)
  1. The client sends a TCP SYN packet to the server

  2. The server receives the SYN and sends back a SYN-ACK

  3. The client receives SYN-ACK from the server and sends an ACK. The server receives ACK and the TCP socket connection is established.


HTTPS: TLS/SSL Handshake
#

If HTTPS is used, a TLS/SSL handshake occurs before the HTTP request, here is a simplified version:

sequenceDiagram participant Client participant Server Client->>Server: Request Secure Connection (TLS Handshake) Server->>Client: Sends SSL Certificate Client->>Server: Verifies & Establishes Encrypted Connection

Sending a HTTP Request
#

  • Once the TCP connection and TLS Handshakes are established, the client (browser) sends an HTTP request:
sequenceDiagram participant Client participant Server Client->>Server: HTTP Request (GET /index.html) Note over Client: Includes headers: Accept, User-Agent,... Server->>Client: Response (200 OK + HTML Content) Note over Server: Includes headers: Content-Type, Cache-Control,...

HTTP Request Structure
#

  • Request Line: GET /index.html

  • Headers (metadata about the request)

  • Optional Body (for POST/PUT requests)


HTTP Request Header Examples:

  • Accept Defines the media types that the client is able to accept from the server. For example Accept: application/json, text/html indicates that the client prefers JSON or HTML responses.

  • User-Agent Identifies the web browser or client application that’s making the request and enables the server to response specific to the client. For example CSS prefixes that are compatible with Chrome.

  • Authorization Used to send the client’s credentials to the server

  • Cookie Sends session data to the server. The server then uses these cookies to associate the request with a specific user or session.


Server Processes the Request
#

  • The server checks the request like valid URL, method, authentication, etc.

  • Finds the requested resource, for example a HTML file, API response, etc.

  • Generates a HTTP response and sends it back


Server Sends the HTTP Response
#

The server responds with:

  • Status Code: For example 200 OK, 404 Not Found

  • Headers (metadata about the response)

  • Body (HTML, JSON, etc.)


Resonse Headers Examples:

  • Cache-Control: Defines caching behavior in the client’s browser

  • Content-Type: Specifies the MIME type of the response body. For example Content-Type: text/html; charset=UTF-8