Web Technologies and HTTP

The World Wide Web (WWW) is a distributed client-server architecture designed to share information across global networks. It relies on standardized protocols and document structures to seamlessly retrieve and display hypertext, hypermedia, and structured data.

1. World Wide Web Architecture

The modern WWW operates on a distributed client-server model. Rather than keeping all documents in a single centralized repository, the service is spread across thousands of physical locations called sites.

Simple vs. Composite Web Pages

A Web page can exist in one of two configurations:

Simple Web Page: Contains plain text or has visual media (such as images) embedded directly within the single retrieved file (e.g., using inline Data URLs). It is retrieved in a single request-response transaction.
Composite Web Page: Contains references (hyperlinks/pointers) to other independent files stored on either the same site or external sites. Rendering a composite page requires the client to initiate multiple subsequent request-response transactions.

text

Simple Page Retrieval:
Client                     Server (Site A)
  | --- Request 1 ---------> | (Get Biography)
  | <--- Response 1 -------- | (Returns Document with inline assets)
 
Composite Page Retrieval:
Client                     Server (Site A)            Server (Site B)
  | --- Request 1 ---------> | (Get Main File A)
  | <--- Response 1 -------- | (Returns File A with pointers to B & C)
  | --- Request 2 ---------> | (Get Image B)
  | <--- Response 2 -------- | (Returns Image B)
  | --- Request 3 ------------------------------------> | (Get Text C)
  | <--- Response 3 ---------------------------------- | (Returns Text C)

Each referenced file (such as File A, File B, or File C) remains a fully independent resource with its own unique identifier and access permissions, meaning any of them can also be retrieved directly on its own.

The Web Client (Browser)

The client application, known as a Web Browser, is responsible for presenting web documents to the user. A browser typically contains three main logical components:

Controller: Receives input from keyboard/mouse devices and uses client-side protocols to coordinate other browser components.
Client Protocols: The implementations of protocols needed to fetch documents (e.g., HTTP, HTTPS, FTP, SMTP).
Interpreters/Parsers: Renderers that parse documents (e.g., HTML, XML, CSS) and execute code (e.g., JavaScript) to display the page correctly on the screen.

text

+-----------------------------------------------------+
|                     BROWSER                         |
|  +-----------------------------------------------+  |
|  |                  Controller                   |  |
|  +----------------------+------------------------+  |
|                         |                           |
|       +-----------------+-----------------+         |
|       |                                   |         |
|  +----+---------+                   +-----+-----+   |
|  | Protocols    |                   |Interpreters|  |
|  | (HTTP, SMTP) |                   | (HTML, JS) |  |
|  +--------------+                   +-----------+   |
+-----------------------------------------------------+

Uniform Resource Locator (URL)

To access any resource across the distributed network, the client needs a standardized identifier. The Uniform Resource Locator (URL) specifies the protocol, host machine, optional port number, and the precise path to the resource:

$\text{URL Format: } \texttt{protocol://host[:port]/path}$

Protocol: Specifies the client-server application protocol (e.g., http, https, ftp).
Host: The domain name or IP address of the target server.
Port: An optional 16-bit integer identifying the server process port (defaults to port 80 for HTTP, port 443 for HTTPS).
Path: The hierarchical directory location of the file on the server.

2. Classification of Web Documents

Web documents are categorized based on when their content is determined:

text

                           Web Documents
                                 |
         +-----------------------+-----------------------+
         |                       |                       |
      Static                  Dynamic                 Active
  (Pre-created,           (Server-side            (Client-side
   fixed files)            computation)            computation)

Static Documents

Definition: Static documents are pre-created files stored on the server's local file system.
Execution: The server does not modify or execute the document. It simply reads the file from disk and transmits it as-is to the client.
Technologies: HTML, CSS, static XML, image files (JPEG, PNG).

Dynamic Documents

Definition: Dynamic documents do not exist as pre-packaged files on disk. Instead, the server generates the document's content on-the-fly when a request is received.
Execution: When a request arrives, the web server executes a program or script. The output of this script is converted into standard HTML/XML and sent back to the client.
Architectures:
- Common Gateway Interface (CGI): A legacy standard defining how a web server communicates with external backend gateway programs. Each request spawns a new process, which can introduce performance overhead.
- Server-Side Scripting: Modern server architectures (e.g., Node.js, PHP, ASP.NET, JSP) load scripting engines directly into the web server process to generate content efficiently.

text

Server-Side Dynamic Document Execution (CGI / Scripting):
Client                     Web Server               Script Engine / DB
  | --- HTTP Request ------> |                             |
  |                          | --- Executes Script ------> |
  |                          | <--- Returns HTML/Data ---- |
  | <--- HTTP Response ----- |                             |

Active Documents

Definition: Active documents shift computational overhead from the server to the client. The server transmits a program or script, which the client's browser then executes locally.
Execution: The client CPU executes the code within the browser's sandbox environment. This makes active documents ideal for real-time user interaction, animations, and local calculations.
Technologies:
- Java Applets: Compiled bytecode executed within a client-side Java Virtual Machine (JVM) sandbox (largely deprecated).
- Client-Side Scripting (JavaScript/WebAssembly): High-performance source code or binary instructions interpreted and compiled on-the-fly by browser engines (e.g., V8, SpiderMonkey).

3. Hypertext Transfer Protocol (HTTP) Protocol Mechanics

The Hypertext Transfer Protocol (HTTP) is an application-layer protocol designed to transfer hypermedia resources across the Internet.

Protocol Characteristics

Transport Layer: Runs on top of TCP using well-known port 80 (or port 443 for TLS-encrypted HTTPS).
In-Band Control: Unlike FTP (which separates control to port 21 and data to port 20), HTTP transmits control headers and payload data through the same TCP connection.
Transaction Model: It is a stateless pull-based protocol. The client initiates a request, and the server returns a response.
Statelessness: By default, the server retains no structural memory of past requests from the same client.

text

HTTP Request Message Format:
+--------------------------------------------------------------+
| Request Line:   [Method] [SP] [Request-URI] [SP] [Version]   |
+--------------------------------------------------------------+
| Header Lines:   [Field Name] : [Value]                       |
|                 ...                                          |
+--------------------------------------------------------------+
| Blank Line:     CRLF                                         |
+--------------------------------------------------------------+
| Entity Body:    [Optional Request Payload Data]              |
+--------------------------------------------------------------+
 
HTTP Response Message Format:
+--------------------------------------------------------------+
| Status Line:    [Version] [SP] [Status Code] [SP] [Phrase]   |
+--------------------------------------------------------------+
| Header Lines:   [Field Name] : [Value]                       |
|                 ...                                          |
+--------------------------------------------------------------+
| Blank Line:     CRLF                                         |
+--------------------------------------------------------------+
| Entity Body:    [Response Resource Data]                     |
+--------------------------------------------------------------+

HTTP Methods (Commands)

The request line specifies an action to perform on the target resource. Common methods include:

Structure of an HTTP Transaction (Examples)

Example A: Standard GET Request & Response

A client wants to retrieve a JPEG image located at /assets/logo.png.

Request Message:

http

GET /assets/logo.png HTTP/1.1
Host: www.kophub.com
User-Agent: Mozilla/5.0
Accept: image/png, image/jpeg
Connection: close

Note the empty line separating the headers from the body. Since this is a GET request, there is no body payload.

Response Message:

http

HTTP/1.1 200 OK
Date: Wed, 15 Jul 2026 14:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: image/png
Content-Length: 4812
Connection: close
 
[Raw Binary Image Data Contents Here]

Example B: POST Request with Payload

A client submits dynamic form data to a CGI script /bin/register.pl.

Request Message:

http

POST /bin/register.pl HTTP/1.1
Host: www.kophub.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 31
 
username=kophub&user_id=10243

4. Connection Management: Persistent vs. Non-Persistent HTTP

How TCP connections are managed has a significant impact on network performance and latency.

Non-Persistent Connections (HTTP/1.0 Default)

In a non-persistent connection, one TCP connection is opened for every single HTTP request/response transaction. Once the server sends the requested object, it closes the connection.

Latency Analysis (Round-Trip Time)

Let RTT (Round-Trip Time) be the time it takes for a small packet to travel from client to server and back.

TCP Connection Setup: $1 \text{ RTT}$ (SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK).
Request/Response Transmission: $1 \text{ RTT}$ (HTTP Request $\rightarrow$ Response Data starts arriving).
Total Delay per Object:

$T_{\text{object}} = 2 \cdot \text{RTT}$

For a base HTML document with $N$ embedded media files:

$T_{\text{total, non-persistent}} = 2 \cdot \text{RTT} + N \cdot (2 \cdot \text{RTT}) = 2(N + 1) \cdot \text{RTT}$

This approach introduces significant overhead due to repeated TCP handshakes and slow-start warmups.

text

Non-Persistent Connection Timeline:
Client                                     Server
  | ------------ TCP SYN --------------------> |  \
  | <----------- TCP SYN-ACK ----------------- |   |-- RTT 1 (TCP Handshake)
  | ------------ HTTP GET (ACK) -------------> |  /
  | <----------- HTTP Response (Data) -------- |     -- RTT 2 (HTTP Transfer)
  X (Connection Closed by Server)

Persistent Connections (HTTP/1.1 Default)

A persistent connection keeps the TCP connection open after sending a response. Subsequent requests can reuse this existing path, avoiding repeated TCP handshakes.

Persistent without Pipelining: The client must wait for a response before sending the next request.
- Total delay:

$T_{\text{no-pipeline}} = 2 \cdot \text{RTT} + N \cdot \text{RTT} = (N + 2) \cdot \text{RTT}$

Persistent with Pipelining: The client sends requests as soon as it encounters a reference, without waiting for outstanding responses.
- Total delay:

$T_{\text{pipelining}} \approx 3 \cdot \text{RTT}$

text

Persistent Connection (Without Pipelining):
Client                                     Server
  | ------------ TCP SYN --------------------> |  \
  | <----------- TCP SYN-ACK ----------------- |   |-- RTT 1 (TCP Handshake)
  | ------------ HTTP GET 1 (HTML) -----------> |  /
  | <----------- HTTP Response 1 ------------- |     -- RTT 2 (HTML Delivered)
  | ------------ HTTP GET 2 (Image) ----------> |  \
  | <----------- HTTP Response 2 ------------- |   |-- RTT 3 (Image Delivered)
  | (Connection Kept Alive for future requests)

5. Advanced HTTP Features: Cookies, Caching, and Conditionals

Stateful Sessions via Cookies

HTTP is inherently stateless, but modern applications need to track user state (e.g., login status, shopping carts). Cookies solve this problem by managing state at the application layer.

Cookie Creation: The client sends an HTTP request. The server generates a unique identifier, updates its backend database, and includes a Set-Cookie header in its response.
Cookie Storage: The client browser saves this identifier on its local storage, mapped to the server's domain.
Automatic Resubmission: On subsequent requests to the same domain, the browser automatically appends the stored identifier in the Cookie header.

text

Cookie Transaction Flow:
Client                                           Server
  | --- GET /index.html -----------------------> |
  |                                              | * Generates ID: 88712
  | <-- HTTP 200 OK (Set-Cookie: ID=88712) ----- | * Stores ID in DB
  |                                              |
  | * Stores Cookie Locally                      |
  |                                              |
  | --- GET /cart.html (Cookie: ID=88712) -----> |
  |                                              | * Matches ID 88712
  | <-- HTTP 200 OK (Personalized Cart Page) --- | * Updates Session State

Web Caching with Proxy Servers

A Proxy Server (Web Cache) is an intermediary entity that satisfies HTTP requests on behalf of an origin web server.

text

                +--------------+
                | Client       |
                +------+-------+
                       | HTTP Request (GET /logo.png)
                       v
                +--------------+  [Cache Hit]  Returns local copy
                | Proxy Server | ------------+
                +------+-------+             |
                       |                     v
                       | [Cache Miss]
                       | HTTP Request
                       v
                +--------------+
                | Origin       |
                | Server       |
                +--------------+

The client browser sends all requests directly to the local proxy server.
Cache Hit: If the proxy has a fresh copy of the resource, it returns it immediately, bypassing the origin server.
Cache Miss: If the resource is missing or stale, the proxy fetches it from the origin server, stores a copy locally, and returns it to the client.

Benefits: Reduces client response times, minimizes WAN bandwidth usage, and lowers the load on origin servers.

Conditional Requests

To prevent proxies or client caches from serving outdated information without unnecessarily re-fetching intact data, HTTP uses Conditional Requests:

The client sends a request containing the If-Modified-Since header, specifying the timestamp of its currently cached version.
If the file has not changed since that date, the server returns an empty-bodied 304 Not Modified status code. The client then safely uses its cached copy.
If the file has changed, the server sends the updated resource with a 200 OK status code.

6. Summary

The World Wide Web (WWW) is a distributed client-server architecture where clients (browsers) request resources from servers located across distinct physical sites using URLs.
Web documents are categorized by when their content is generated: static (pre-created files), dynamic (generated on-the-fly at the server-side, e.g., CGI/PHP), and active (executed on the client-side, e.g., JavaScript).
HTTP is an application-layer protocol running over TCP on port 80 that uses a stateless pull-based model. It transmits control headers and payload data through a single TCP connection (in-band control).
Non-persistent HTTP opens a new TCP connection for every single transaction, resulting in a latency of $2 \cdot \text{RTT}$ per resource. Persistent HTTP keeps the connection open, reducing subsequent object delays to $1 \cdot \text{RTT}$ (and even lower when pipelining is used).
Cookies enable stateful sessions over stateless HTTP, web caches (proxies) improve response times by serving content locally, and conditional requests (If-Modified-Since) optimize bandwidth by avoiding redundant resource downloads.

Assessed progress

Web Technologies and HTTP

Web Technologies and HTTP

1. World Wide Web Architecture

Simple vs. Composite Web Pages

The Web Client (Browser)

Uniform Resource Locator (URL)

2. Classification of Web Documents

Static Documents

Dynamic Documents

Active Documents

3. Hypertext Transfer Protocol (HTTP) Protocol Mechanics

Protocol Characteristics

HTTP Methods (Commands)

Structure of an HTTP Transaction (Examples)

Example A: Standard GET Request & Response

Example B: POST Request with Payload

4. Connection Management: Persistent vs. Non-Persistent HTTP

Non-Persistent Connections (HTTP/1.0 Default)

Latency Analysis (Round-Trip Time)

Persistent Connections (HTTP/1.1 Default)

5. Advanced HTTP Features: Cookies, Caching, and Conditionals

Stateful Sessions via Cookies

Web Caching with Proxy Servers

Conditional Requests

6. Summary

Key Concepts

Web Architecture

Web Documents

HTTP Transactions

Connection Persistence

State Management & Cookies

Quick Check

Computer Networks

Computer Networks