HTTP (HyperText Transfer Protocol)

🧭

On this page — click any heading below to jump straight to it. ⬅️ Back to P-II.II. Computer Communications & Networks

---

OSI Layer: Application Layer (L7)

Definition

HTTP (HyperText Transfer Protocol) is the application-layer protocol that governs how web clients (browsers) and web servers exchange requests and responses to fetch and render web resources (HTML, images, etc.). It uses request-response semantics. HTTP/1.1 and HTTP/2 use TCP; HTTP/3 uses QUIC over UDP. HTTP conventionally uses port 80 and HTTPS port 443.

Key Characteristics

• Client-server, request-response cycle
• Stateless — each request is independent, with no memory of prior requests by itself
• Text-based protocol (headers + optional body)
• Uses reliable delivery: TCP in HTTP/1.1 and HTTP/2, or reliable QUIC streams over UDP in HTTP/3.

HTTP Methods

• GET — retrieve a resource, no body
• POST — submit data to be processed (e.g., a form), body carries the payload
• PUT — replace a resource entirely
• DELETE — remove a resource
• HEAD — like GET but returns headers only, no body

Persistent vs Non-Persistent Connections

• Non-persistent HTTP (HTTP/1.0 default) — a new TCP connection per object requested; the connection closes after each response, adding significant overhead for pages with many embedded objects
• Persistent HTTP (HTTP/1.1 default, "keep-alive") — a single TCP connection reused for multiple requests/responses in sequence; pipelining allows several requests to be sent before responses return
• HTTP/2 multiplexes many streams over one connection, removing head-of-line blocking at the application layer

Cookies and State

HTTP is stateless, but cookies (set via a Set-Cookie response header, echoed back via a Cookie request header) let a server track a user's session or preferences across otherwise independent requests.

Caching

• Web caches / proxy servers store copies of recently requested objects to reduce response time and backbone traffic
• Conditional GET (If-Modified-Since) lets a cache check whether its stored copy is still fresh without re-downloading the object

Request/Response Message Format

• Request: Request line (Method + URL + HTTP version) → Header lines (Host, User-Agent, Accept, …) → blank line → optional body (e.g., POST data)
• Response: Status line (version + status code + phrase) → headers → body
• Common status codes: 200 OK, 301 Moved Permanently, 404 Not Found, 500 Internal Server Error

CSS Exam Angle

• A staple Application Layer topic — expect a "define + methods + persistent vs non-persistent" style question
• Draw the request-response message format with labelled fields
• Contrast HTTP with FTP: HTTP is stateless and uses one connection; FTP uses two separate connections (control + data)

Example

When a browser loads a page with 10 embedded images, non-persistent HTTP with no parallel connections would need 11 separate TCP handshakes (1 for the HTML + 10 for images); persistent HTTP reuses one connection for all 11 requests, cutting both latency and server load — the reasoning behind HTTP/1.1 defaulting to keep-alive.

Likely Questions

1. Define HTTP and explain its request-response message format.
2. Differentiate persistent and non-persistent HTTP connections with their performance implications.
3. What is a web cache/proxy server, and how does conditional GET make it efficient?
4. Explain the role of cookies in maintaining state over a stateless protocol.

📜 Past-Paper Questions & Structured Answers

Questions are paraphrased; answer focus is suggested guidance, not an official marking scheme.

2017 · Paper-II · Q3(a)(i) · HTTP/SIP component · 8 marks

Question (paraphrased): Explain HTTP and SIP; the full subquestion also asks about TCP and UDP.

Answer focus: Eight marks are shared across all four protocols, with no separate HTTP-only allocation.

HTTP: an application-layer request/response protocol for web resources. A browser sends a method, target and headers; the server returns a status, headers and usually a body. HTTP is stateless at protocol level; cookies can support application sessions. HTTP/1.1 and HTTP/2 use TCP; HTTP/3 uses QUIC over UDP.

SIP: application signalling for setting up, modifying and ending multimedia sessions; INVITE/200 OK/ACK establishes a session and BYE ends it. Media typically travels separately using RTP.

TCP/UDP portion: TCP supplies a reliable ordered byte stream with connection setup and control; UDP supplies lightweight independent datagrams without built-in reliability or congestion control. See the complete four-protocol table in Connectionless Transport with UDP (2017).

2025 · Paper-II · Q3(b)(i) · 4 marks

Question (paraphrased): Why use conditional GET, and how does it differ from regular GET?

Answer focus: Purpose, validator, both responses and benefit.

Regular GET requests a representation without a condition tied to the client’s stored version. Conditional GET adds a validator, such as If-None-Match with an ETag or If-Modified-Since with a modification date.

If the cached representation remains valid, the server can return 304 Not Modified without retransmitting its body. If it changed, it normally returns 200 OK and the updated representation.

Benefit: the client checks freshness while saving the bandwidth and transfer time of an unchanged object. A fresh cache entry may also be reused without contacting the origin, so regular GET does not always mean a complete origin download. HTTP semantics

2025 · Paper-II · Q3(b)(ii) · 6 marks

Question (paraphrased): Estimate caching delay using 100 Kbit objects, 15 requests/s, 2 s origin RTT, 100 Mbps LAN, 1.54 Mbps access link and 50% hits.

Answer focus: State queueing approximation, calculate miss load, then weight hit/miss delays.

Assumptions: decimal K/M; model mean access-link service-plus-queue delay as Δ/(1−aΔ), where Δ=L/R and a is the rate crossing that link. The paper does not specify an arrival/service distribution; this is the common textbook queueing approximation. Ignore origin processing and request transmission sizes.

1. Miss rate: a=(1−0.5)×15=7.5 requests/s. Access offered load=7.5×100,000=750,000 bits/s.

2. Link utilisation: ρ=750,000/1,540,000=0.487013.

3. Access delay: Δ=100,000/1,540,000=0.064935 s. Daccess=0.064935/(1−0.487013)=0.126582 s. This already includes object transmission on that link.

4. LAN: object transmission=100,000/100,000,000=0.001 s; utilisation=0.015, so queueing is small.

5. Weighted mean: hits avoid the origin trip; misses incur it. D≈DLAN+0.5×(2+Daccess)=0.001+0.5×2.126582=1.064291 s ≈1.06 seconds.

Using the same queue approximation for the LAN gives 0.001015 s and essentially the same result. Without cache, the access utilisation is 1.5/1.54≈97.4% and the approximation gives 2.5 s access delay, illustrating the benefit. Different delay models can produce a different estimate; state yours.

2026 · Paper-II · Q1 item 12 · 1 mark

Question: Why can HTTP/3 outperform HTTP/2 when packets are lost?

Answer: C — QUIC avoids TCP’s cross-stream head-of-line blocking. Loss on one QUIC stream need not stall independent streams, although that stream still waits for its missing data. HTTP/3 does not replace TLS with an unrelated encryption scheme. Paper; HTTP/3 specification.