HTTP Protocol

Webpage

A webpage typically consists of multiple objects:

• A base HTML file
• Images
• JavaScript files
• Audio or video
• etc

These objects can be stored on different web servers.
Therefore, displaying one page may require multiple network requests to multiple hosts.

HTTP Protocol

HTTP stands for Hypertext Transfer Protocol. It is the Web’s application-layer protocol.

HTTP defines how browsers and web servers request and transfer web objects.

HTTP Client

• Initiates communication
• Sends HTTP requests
• Receives HTTP responses

HTTP Server

• Waits for HTTP requests
• Locates or generates requested objects
• Sends HTTP responses

Two Types of HTTP Connection

Non-persistent HTTP

With non-persistent HTTP:

1. Open a TCP connection.
2. Transfer at most one web object.
3. Close the TCP connection.

If a page contains ten objects, the browser needs ten multiple TCP connections.

Connection 1 → base HTML → close
Connection 2 → image 1   → close
Connection 3 → image 2   → close
...

Persistent HTTP (aka HTTP/1.1)

With persistent HTTP, the server leaves the TCP connection open after sending a response.

The client can request multiple objects over that same connection:

TCP connection setup
        ↓
Request HTML → response
Request image → response
Request CSS → response
Request script → response
        ↓
TCP connection close

Benefits

• Fewer TCP connection setups
• Less operating-system overhead
• Existing TCP connection state is reused
• Subsequent requests can be sent quickly
• Referenced objects can be retrieved with fewer RTTs

Stateless HTTP and Cookies

HTTP interaction is stateless.

Web sites and client browsers use cookies to maintain some state between transactions:

Cookies and privacy

Cookies can allow a site to record extensive information about user activity. Third-party persistent cookies can also support tracking across multiple sites when those sites communicate with a common third party.

Web Caching (aka Proxy Server)

A web cache, also called a proxy server, stores copies of web objects closer to clients.

Web cache acts as both client and server:

• Server for original requesting client
• Client to origin server
  

The origin server uses headers such as Cache-Control to specify whether and for how long an object may be cached.

Benefits

• reduced response time
• reduced origin-server load
• reduced access-link traffic
• better content delivery

Conditional GET

Cached content may become stale.
A conditional GET allows the cache to ask whether its stored copy is still current without downloading the entire object again.

The client or cache sends:

If-Modified-Since: <date>

Object has not changed

The server responds:

HTTP/1.0 304 Not Modified

No object body is needed.

Benefits:

• No object transmission time
• Less bandwidth consumption
• Reduced server and network work

Object has changed

The server responds:

HTTP/1.0 200 OK

<new object data>

The cache stores the updated object.

HTTP/2 and HTTP/3

HTTP/1: HOL (head-of-line) problem

Client requests 1 large object and 3 smaller objects:

HTTP/2: mitigates application-level HOL blocking

HTTP/2 divides objects into smaller frames. Frames belonging to different objects can be interleaved:

This allows the client to receive small or high-priority objects before a large object has completely finished.

HTTP/3:

HTTP/2 normally multiplexes many object streams over one TCP connection.

However, TCP exposes one ordered byte stream. If a TCP segment is lost, TCP cannot deliver later bytes to the application until the missing bytes are recovered.

Here, ordered byte stream means:

• If byte 1 is sent before byte 2, the application receives byte 1 before byte 2.
• Network packets may physically arrive out of order.
• TCP buffers and rearranges them before exposing the bytes to the application.
• If an earlier byte is missing, TCP normally withholds later bytes until the missing data is retransmitted.

Therefore, one lost packet can temporarily stall all HTTP/2 streams sharing one TCP connection. This is transport-level HOL blocking.

HTTP/3 uses a transport constructed over UDP so that modern transport behavior can be implemented without inheriting TCP’s single-stream ordering limitation.