📘 Tutorial 4: The Web and HTTP Fundamentals

COMP347 (Revision 10) | TrustOpen University

🎯 Learning Objectives

Upon completion of this expanded tutorial, students will be able to:

• Explain the architectural components of the Web: browsers, servers, resources, URIs, and HTTP.
• Formally analyse the performance trade‑offs between non‑persistent and persistent HTTP connections.
• Interpret the syntax and semantics of HTTP request and response messages, including all major header fields.
• Describe the operation of HTTP caching, including expiration, validation, and conditional GET.
• Explain how cookies enable stateful sessions over the stateless HTTP protocol.
• Compare HTTP/1.1, HTTP/2, and HTTP/3 in terms of multiplexing, header compression, and latency.

🔭 Overview

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web. This tutorial provides a rigorous, university‑level examination of HTTP, covering not only the syntax and semantics but also the performance implications of connection management, caching, and the evolution of the protocol.

We begin with the Web's client‑server architecture and the role of URIs and MIME types. We then dissect HTTP request and response messages, paying close attention to header fields and their impact on caching, security, and content negotiation. A significant portion is devoted to connection management: we develop a formal performance model for non‑persistent versus persistent connections, and we explore pipelining and its limitations. We also delve into caching mechanics, conditional requests, and the cookie mechanism that enables session state. Finally, we introduce the innovations in HTTP/2 and HTTP/3 that address the performance bottlenecks of HTTP/1.1.

1. The World Wide Web – Architecture and Components

1.1 Client‑Server Model

The Web is a distributed hypermedia system built on the client‑server paradigm. Clients (web browsers) send requests for resources; servers (web servers) listen for requests and respond with the requested resource or an error. Resources are identified by Uniform Resource Locators (URLs), which specify the scheme (e.g., http, https), hostname, port, path, and optional query parameters.

1.2 URL Structure and Encoding

A generic URL follows:
scheme://[userinfo@]host[:port]/path[?query][#fragment]

Percent‑encoding (URL encoding) is used to represent reserved or unsafe characters (e.g., space → %20). The query string is a sequence of key‑value pairs separated by &, with keys and values also percent‑encoded.

1.3 MIME Types and Content Negotiation

HTTP uses MIME (Multipurpose Internet Mail Extensions) types to indicate the media type of a resource (e.g., text/html, image/png, application/json). Content negotiation allows clients to specify preferences via the Accept header; servers may respond with the best matching representation or a 300 Multiple Choices (or 406 Not Acceptable).

2. HTTP Protocol Fundamentals

2.1 HTTP Versions

• HTTP/0.9 (1991): extremely simple – only GET, no headers, no status codes.
• HTTP/1.0 (1996): introduced headers, status codes, POST, and persistent connections (but optional).
• HTTP/1.1 (1997): made persistent connections default, introduced chunked transfer encoding, content negotiation, host header (required for virtual hosting), and more.
• HTTP/2 (2015): binary framing, multiplexing, header compression, server push.
• HTTP/3 (2022): uses QUIC (UDP‑based) for reduced latency and improved multiplexing.

2.2 HTTP Message Structure

Both requests and responses share a common format:

The request‑line consists of: Method Request‑URI HTTP‑Version.

The response starts with a status‑line: HTTP‑Version Status‑Code Reason‑Phrase.

2.3 HTTP Methods and Idempotence

• GET: retrieve a resource (safe, idempotent).
• HEAD: retrieve only headers (safe, idempotent).
• POST: submit data to a resource; may create a new subordinate resource (not safe, not idempotent).
• PUT: replace a resource at the URI (idempotent).
• DELETE: delete a resource (idempotent).
• PATCH: partial update (not idempotent unless specified).
• OPTIONS: query supported methods (safe, idempotent).

Idempotence means that making the same request multiple times has the same effect as making it once. This is important for retry logic.

3. HTTP Message Formats and Headers

3.1 Request Headers (Selected)

3.2 Response Headers (Selected)

3.3 Status Codes – Detailed Categorisation

• 1xx (Informational): 100 Continue, 101 Switching Protocols, 102 Processing.
• 2xx (Success): 200 OK, 201 Created, 202 Accepted, 204 No Content, 206 Partial Content.
• 3xx (Redirection): 301 Moved Permanently, 302 Found (temporary), 303 See Other, 304 Not Modified, 307 Temporary Redirect, 308 Permanent Redirect.
• 4xx (Client Errors): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 408 Request Timeout, 413 Payload Too Large, 429 Too Many Requests.
• 5xx (Server Errors): 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.

4. Connection Management: Non‑Persistent vs Persistent

4.1 Non‑Persistent Connections (HTTP/1.0 default)

Each request opens a new TCP connection. The overhead is significant: each connection requires a 3‑way handshake (1 RTT) plus possibly a slow‑start penalty. For a page with many embedded objects (images, scripts), this leads to high latency.

Response time formula (ignoring transmission time): \( T_{non-persistent} = (2 \times RTT) \times N \) for \( N \) objects, assuming sequential requests, because each object requires a new TCP connection (SYN, SYN‑ACK) and then the request/response (another RTT). Actually, it's 2 RTT per object: one for handshake, one for request/response. So total = \( 2N \cdot RTT \) (plus transmission).

4.2 Persistent Connections (HTTP/1.1 default)

A single TCP connection can be reused for multiple requests. This eliminates the handshake overhead for subsequent requests. The connection is kept alive (keep‑alive) for a period of idle time, after which it may be closed.

Response time (no pipelining): \( T_{persistent} = (1 \times RTT) + (N \times RTT) \) — but actually, the first request requires handshake (1 RTT) and request/response (1 RTT). Subsequent requests each require 1 RTT (request/response). So total = \( 2 \times RTT + (N-1) \times RTT = (N+1) \times RTT \). That's a reduction.

4.3 Persistent Connections with Pipelining

Pipelining allows multiple requests to be sent without waiting for each response. In theory, this can reduce the total time to just \( 2 \times RTT + \text{transmission} \) for all objects (since responses are sent back‑to‑back). However, pipelining has head‑of‑line blocking at the HTTP layer: if the first request is slow (e.g., a large dynamic response), subsequent responses are delayed. HTTP/2 solved this with multiplexing.

5. HTTP Performance Modelling

5.1 Page Load Time Model

Let there be \( N \) objects on a page. Let \( RTT \) be the round‑trip time, and \( T_{trans} \) be the transmission time per object (assumed equal). For persistent connections without pipelining:

For non‑persistent:

Thus, persistent connections reduce the \( RTT \) term from \( 2N \) to \( N+1 \), which is significant for large \( N \).

5.2 Parallel Connections

Modern browsers open multiple parallel TCP connections (typically 6‑8 per domain) to fetch objects concurrently. This reduces perceived latency but can cause congestion and does not eliminate the handshake overhead for each connection. HTTP/2's multiplexing over a single connection is more efficient.

6. Web Caching and Conditional Requests

6.1 Cache Types

• Browser cache: local to the client.
• Proxy cache: shared cache on the network (e.g., ISP cache, corporate proxy).
• Reverse proxy cache: sits in front of the origin server (e.g., Varnish, Nginx).
• CDN cache: distributed edge caches (e.g., CloudFront, Akamai).

6.2 Cache Control Headers

• Cache‑Control: public (cacheable by any cache), private (only browser cache), no‑cache (must revalidate), no‑store (do not store at all), max‑age=<seconds>, must‑revalidate (stale objects must be revalidated with origin).
• Expires: absolute expiration date (obsolete in HTTP/1.1 but still used).

6.3 Conditional GET

A conditional GET uses If‑Modified‑Since (based on Last‑Modified) or If‑None‑Match (based on ETag) to ask the server if the resource has changed. If not, the server responds with 304 Not Modified (no body), saving bandwidth and latency.

6.4 ETag vs Last‑Modified

• Last‑Modified: based on file modification time. It works well for static files but may have resolution issues (seconds) and cannot detect changes within the same second or changes to metadata that do not affect content.
• ETag: a server‑generated opaque identifier (e.g., hash of content, version number). It is more reliable and can detect content changes even if the timestamp hasn't changed. Strong ETags are byte‑exact; weak ETags allow semantically equivalent content.

7. HTTP State Management: Cookies

7.1 Cookie Attributes

• Name=Value: the data.
• Domain: scope of the cookie (which domain can receive it).
• Path: URL path scope.
• Expires / Max‑Age: lifetime; if absent, it's a session cookie.
• Secure: only sent over HTTPS.
• HttpOnly: not accessible via JavaScript (mitigates XSS).
• SameSite: controls cross‑site request behaviour (Strict, Lax, None).

7.2 Cookie Flow

1. Server sends Set‑Cookie header in response.
2. Browser stores the cookie.
3. Browser includes the cookie in subsequent requests via Cookie header.

Cookies are the primary mechanism for session management, personalisation, and tracking.

8. Introduction to HTTP/2 and HTTP/3

8.1 HTTP/2 (RFC 7540)

• Binary framing: instead of text, it uses binary frames for requests and responses, making parsing faster.
• Multiplexing: multiple streams over a single connection; frames are interleaved, eliminating head‑of‑line blocking at the HTTP layer.
• Header compression: HPACK compresses headers by maintaining a static and dynamic table, reducing overhead.
• Server push: server can proactively send resources (e.g., CSS, JS) that the client will likely request.
• Stream prioritisation: allows clients to assign weights to streams.

8.2 HTTP/3 (RFC 9114)

• Uses QUIC (UDP‑based) instead of TCP.
• Provides 0‑RTT connection resumption for faster startup.
• Multiplexing without head‑of‑line blocking even at the transport layer (because QUIC uses separate streams with independent loss recovery).
• Connection migration – survives IP/port changes (e.g., moving from Wi‑Fi to cellular).
• Built‑in TLS 1.3 encryption, integrated with the transport.

📝 Quiz: Tutorial 4

✏️ Exercises: Tutorial 4

GET /v1/data?limit=5 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 ...
Accept: application/json, text/plain
Accept-Encoding: gzip, deflate
Connection: keep-alive

[blank line]

📚 Homework: Tutorial 4

📌 Summary

This expanded tutorial has provided a rigorous foundation in HTTP and the World Wide Web. Key takeaways:

• HTTP is a stateless, request‑response protocol that uses MIME types and URIs to identify resources.
• HTTP/1.1 introduced persistent connections, chunked encoding, and virtual hosting via the Host header.
• Performance modelling shows that persistent connections significantly reduce page load times, especially for pages with many objects.
• Caching (via Cache‑Control, ETag, and conditional GET) is critical for reducing bandwidth and latency.
• Cookies enable stateful sessions over the stateless HTTP protocol.
• HTTP/2 and HTTP/3 address the limitations of HTTP/1.1 with multiplexing, header compression, and better use of network resources.

These concepts are essential for understanding web performance, security, and the evolution of web applications.