Client-Server Architecture, HTTP, HTTPS, URLs, DNS, Web Browsers

Client Server Architecture

 

---

Client server architecture is a computing model/ framework where client requests for the service or data and  powerful, centralized running server process the request, manage the resources and send the response back to the client. This computing model is the backbone for modern web applications providing the services likes: ecommerce, mobile apps, e-banking , software as a service etc.

 

Key components of client server architecture:

Client: A device (PC, phone) or software that initiates requests (e.g., clicking a link, sending an email).

Server: A dedicated, powerful computer or system that hosts, processes, and delivers requested resources or services (e.g., web server, database server).

Network: The connection (LAN or Internet) over which clients and servers communicate using standard protocols (like HTTP).

 

 

HTTP: Hyper Text Transfer protocol

 

HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is typically constructed from resources such as text content, layout instructions, images, videos, scripts, and more.

 

Clients and servers communicate by exchanging individual messages (as opposed to a stream of data). The messages sent by the client are called requests and the messages sent by the server as an answer are called responses.

 

 

Designed in the early 1990s, HTTP is an extensible protocol which has evolved over time. It is an application layer protocol that is sent over TCP, or over a TLS-encrypted TCP connection, though any reliable transport protocol could theoretically be used. Due to its extensibility, it is used to not only fetch hypertext documents, but also images and videos or to post content to servers, like with HTML form results. HTTP can also be used to fetch parts of documents to update Web pages on demand.

 

 

Features of HTTP

HTTP is simple

HTTP is generally designed to be human-readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.

 

HTTP is extensible

Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by an agreement between a client and a server about a new header's semantics.

 

HTTP is stateless, but not sessionless

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

 

HTTP and connections

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. HTTP doesn't require the underlying transport protocol to be connection-based; it only requires it to be reliable, or not lose messages (at minimum, presenting an error in such cases). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.

 

Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.

 

In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the Connection header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.

 

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

HTTP Flow

 

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

1. Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example:

 

 

3. Read the response sent by the server, such as:

 

 

4. Close or reuse the connection for further requests.

 

HTTPS: Hyper Text Transfer protocol Secure

 

Hypertext transfer protocol secure (HTTPS) is the secure version of HTTP, which is the primary protocol used to send data between a web browser and a website. HTTPS is encrypted in order to increase security of data transfer. This is particularly important when users transmit sensitive data, such as by logging into a bank account, email service, or health insurance provider.

Any website, especially those that require login credentials, should use HTTPS. In modern web browsers such as Chrome, websites that do not use HTTPS are marked differently than those that are. Look for a padlock in the URL bar to signify the webpage is secure. Web browsers take HTTPS seriously; Google Chrome and other browsers flag all non-HTTPS websites as not secure.

How does HTTPS work?

HTTPS uses an encryption protocol to encrypt communications. The protocol is called Transport Layer Security (TLS), although formerly it was known as Secure Sockets Layer (SSL). This protocol secures communications by using what’s known as an asymmetric public key infrastructure. This type of security system uses two different keys to encrypt communications between two parties:

The private key - this key is controlled by the owner of a website and it’s kept, as the reader may have speculated, private. This key lives on a web server and is used to decrypt information encrypted by the public key.

The public key - this key is available to everyone who wants to interact with the server in a way that’s secure. Information that’s encrypted by the public key can only be decrypted by the private key.

 

 

URL: Uniform Resource Locator

 

A URL (Uniform Resource Locator) is the address of a unique resource on the internet. It is one of the key mechanisms used by browsers to retrieve published resources, such as HTML pages, CSS documents, images, and so on.

 

In theory, each valid URL points to a unique resource. In practice, there are some exceptions, the most common being a URL pointing to a resource that no longer exists or that has moved. As the resource represented by the URL and the URL itself are handled by the Web server, it is up to the owner of the web server to carefully manage that resource and its associated URL.

 

Example of Urls:

https://developer.mozilla.org

https://developer.mozilla.org/en-US/docs/Learn_web_development/

https://developer.mozilla.org/en-US/search?q=URL

 

A URL is composed of different parts, some mandatory and others optional. The most important parts are highlighted on the URL below: 

 

 

DNS: Domain Name System

 

The Domain Name System (DNS) is essentially the phonebook of the internet. Its main job is to translate human-readable domain names (like www.example.com) into computer-readable IP addresses (like 192.0.2.1), which are necessary to locate and connect to a web server.

 

Here is a step-by-step explanation of how DNS works, a process called DNS resolution:

 

The 4 Main Components of DNS

 

The DNS resolution process involves four main types of servers:

 

DNS Recursor (or Resolver): The client's initial contact point. It's usually managed by your Internet Service Provider (ISP) or a third-party service (like Google's 8.8.8.8). Its job is to receive the query and manage the lookup process until it finds the correct IP address.

 

Root Name Server: The very top of the DNS hierarchy (represented by a single dot: .). It receives the initial request from the recursor and directs it to the correct TLD name server.

 

TLD (Top-Level Domain) Name Server: Stores information for all domain names that share a common extension (e.g., .com, .org, .net). It directs the recursor to the specific authoritative name server for the domain.

 

Authoritative Name Server: The final stop. This server holds the actual official records (like the IP address) for a specific domain name (e.g., example.com).

 

The 6 Steps of DNS Resolution

 

 

When you type a website address into your browser, this is what happens behind the scenes:

Step 1: User Initiates a Query

You type a domain name (e.g., www.example.com) into your browser and hit Enter. Your computer first checks its local cache (a temporary storage) for the IP address. If it's found, the process ends here (this is the fastest scenario).

Step 2: The Recursor Receives the Request

If the IP is not in your local cache, your computer sends the request to your configured DNS Recursor (ISP server).

Step 3: Recursor Asks the Root Server

The Recursor asks a Root Name Server: "Where can I find www.example.com?" The Root Server doesn't know the IP, but it knows where to find the server responsible for the .com TLD.

Step 4: Recursor Asks the TLD Server

The Root Server sends back the IP address of the TLD Name Server for .com.The Recursor then asks the .com TLD server: "Where can I find example.com?" The TLD server sends back the IP address of the Authoritative Name Server for example.com.

Step 5: Recursor Asks the Authoritative Server

The Recursor sends the request to the Authoritative Name Server for example.com. The Authoritative Server finally replies with the specific IP address for www.example.com (e.g., 192.0.2.1).

Step 6: Final Connection

The Recursor sends the IP address back to your browser.Your browser can now use this IP address to open a direct connection to the web server, and the website loads.

The Recursor also stores this answer in its own cache, so the next person who asks for www.example.com can skip all the steps and get the answer immediately. This is why DNS resolution is typically very fast.

 

Web Browser

A Web Browser is a software application that acts as an interface between you and the World Wide Web (WWW).Its primary function is to retrieve information (like HTML documents, images, and videos) from a web server and display it in a readable, interactive format on your device.Common examples include: Chrome, Firefox, Safari, Edge, and Opera.

 

How a Web Browser Works ?

 

When you type a Uniform Resource Locator (URL) into the address bar, the browser performs a series of complex steps:

Get the Address: It uses the DNS (Domain Name System) to translate the human-readable domain name (e.g., www.example.com) into a machine-readable IP address (e.g., 192.0.2.1).

Make the Request: It establishes a connection with the server at that IP address (using protocols like TCP/IP) and sends an HTTP/HTTPS request for the page files.

Get the Response: The web server responds by sending the requested files (HTML, CSS, JavaScript, images, etc.) back to the browser.

Render the Page: The browser's core component, the Web Browser Engine, takes these raw files and translates them into the visual, interactive webpage you see.

 

The Web Browser Engine

 

The Web Browser Engine (also known as the Layout Engine or Rendering Engine) is the most crucial software component of a browser. It is the "magic" that takes code and transforms it into a visible webpage.

Key Components of the Engine

A modern browser engine is composed of several specialized parts that work together.

Working of the Web Browser Engine

The engine follows a multi-step process to build the webpage:

Parsing (HTML & CSS):The engine reads the raw HTML code and converts it into a structured tree of nodes called the DOM (Document Object Model).It reads the CSS code and converts it into a similar structure called the CSSOM (CSS Object Model).

Render Tree Construction:The DOM and CSSOM are combined to form the Render Tree.This tree contains only the visible elements on the page, along with their calculated styles.

Layout (or Reflow):The engine calculates the precise geometry and position of every element in the Render Tree (e.g., how wide an image is, where a text block starts and ends on the screen).

Painting:This is the final step where the engine draws the elements onto the screen.It translates the layout and style information into actual pixels, colors, and images that you see.

Script Execution:The JavaScript Engine executes any JavaScript code.This code often modifies the DOM, which can trigger a re-run of the Layout and Painting steps to update the page dynamically (e.g., when you click a button and a menu opens).