Overview of HTTP and

Related Technologies
Lecture 01
Learning Outcomes
After completing this lesson, you should be able to

Explore different versions of HTTP protocol

Explain the basic features of each of HTTP protocol versions

Explain the limitations of each of the HTTP protocol versions

Explain the HTTP Request/Response message components

Explain the difference between safe and idempotent HTTP Request

Methods
HTTP
HTTP (HyperText Transfer Protocol) is the underlying protocol of the World
Wide Web

HTTP is an extensible protocol which has evolved over time

It allows the fetching of resources, such as HTML documents, images and

videos

it is a client-server protocol

requests are initiated by the recipient, usually the Web browser

HTTP
It is built over TCP and IP protocols

or over a TLS-encrypted TCP connection, or any reliable transport

protocol

It is used to not only fetch resources, but also 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
HTTP

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
HTTP is a client-server protocol including the following high-level components

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
Question: List example clients

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
Requests are sent by the user-agent (or a proxy on behalf of it)

Most of the time the user-agent is a Web browser

Other user-agents

Web crawlers

Programs used by Web developers to debug their applications

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
The server serves the documents requested by the client

A server is not necessarily a single machine, but several server software

instances can be hosted on the same machine

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
Between the client and the server there are numerous entities, collectively
called proxies

Proxies perform functions such as

Caching, filtering, load balancing, authentication, logging

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
 HTTP
HTTP is stateless but not sessionless

there is no link between two requests being successively carried out on

the same connection

HTTP cookies allow the use of stateful sessions

Using HTTP cookies allows you to link requests with the state of the server

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
Evolution of HTTP
List of different version of HTTP

HTTP/0.9

HTTP/1.0

HTTP/1.1

HTTP/2

HTTP/3
HTTP/0.9
Client-server, request-response protocol

ASCII protocol, running over a TCP/IP link

Designed to transfer hypertext documents (HTML)

The connection between server and client is closed after

every request and response
HTTP/0.9
Example

The request consists of a single line

GET method and the path of the

requested document

The response is a single hypertext

document

No headers or any other metadata,

just the HTML
Question
Can you identify some of the limitations of the HTTP/0.9 protocol ?
HTTP/0.9: Limitations
Could not serve more documents than hypertext documents

It has GET request method only

Unable to provide metadata about the request and the response

Unable to negotiate content

New connection establishment for each request

HTTP/1.0
HTTP Working Group (HTTP-WG) published RFC 1945, which documented the
"common usage" of the many HTTP/1.0 implementations already in use
HTTP/1.0
Versioning information is now sent within each request (HTTP/1.0 is
appended to the GET line)

The notion of HTTP headers has been introduced

both for the requests and the responses, allowing metadata to be

transmitted and making the protocol extremely flexible and extensible

Request and response headers were ASCII encoded

HTTP/1.0
With the help of the new HTTP headers, the ability to transmit other
documents than plain HTML files has been added

using the Content-Type header

In addition to media type negotiation it included capabilities such as content

encoding, character set support, multi-part types, authorization, caching,
proxy behaviors, date formats, and more

The connection between server and client is closed after every request and
response
HTTP/1.0: Example
Request line with HTTP
1
version number, followed by
request headers

Response status, followed by

2
response headers
Question
Identify the

Request Line

Request Header

Response Line

Response Header
Question
What do you think are the limitations of the HTTP/1.0 protocol ?
HTTP/1.0: Limitations
Requiring a new TCP connection per request
imposes a significant performance penalty
HTTP/1.1
Standardized protocol

The official HTTP/1.1 standard is defined in RFC 2068, which was released in
January 1997

In June of 1999, a number of improvements and updates were incorporated

into the standard and the second version were released as RFC 2616

The HTTP/1.1 standard resolved a lot of the protocol ambiguities found in

earlier versions
HTTP/1.1
It introduced critical performance optimizations:

Keepalive Connections

a connection can be reused, saving the time to

reopen it numerous times to display the resources
embedded into the single original document
retrieved
HTTP/1.1
It introduced critical performance optimizations:

Request Pipelining

sending several successive requests without

waiting for an answer, reducing much of the
latency in the network
HTTP/1.1
It introduced critical performance optimizations:

Transfer Encoding

specifies the form of encoding used to safely transfer the payload

body to the user, e.g. chunked, compress

Byte-range Requests

Host header

allowed to host different domains at the same IP address (allowing

server colocation)
HTTP/1.1: Example
1 Request for HTML file, with encoding metadata
HTTP/1.1: Example
2 Chunked response for original HTML request
HTTP/1.1: Example
3 Number of octets in the chunk expressed as an
ASCII hexadecimal number

4 End of chunked stream response

HTTP/1.1: Example
Request for an icon file made
5
on same TCP connection

6
Inform server that the
connection will not be reused
HTTP/1.1: Example
7 Icon response, followed by connection close
Question
What is the name of the header part that is added on HTTP/1.1 version to
improve the limitation of HTTP/1.0 (requiring a new TCP connection for each
request)
Question
What do you think are the limitations of the HTTP/1.X protocol ?
Limitations of HTTP/1.x
Clients need to use multiple connections to achieve concurrency and
reduce latency

Does not compress request and response headers, causing unnecessary

network traffic

Does not allow effective resource prioritization, resulting in poor use of the
underlying TCP connection
SPDY
SPDY was an experimental protocol, developed at Google and announced in
mid-2009

Its primary goal was to try to reduce the load latency of web pages by
addressing some of the well-known performance limitations of HTTP/1.1
SPDY
The specific project goals were the following

Target a 50% reduction in page load time (PLT)

Avoid the need for any changes to content by website authors

Minimize deployment complexity, avoid changes in network infrastructure

Develop this new protocol in partnership with the open-source

community

Gather real performance data to (in)validate the experimental protocol

SPDY
SPDY in lab condition has shown 55% reduction in page load time

As a result SPDY was supported in Chrome, Firefox, and Opera, and a rapidly
growing number of sites e.g., Google, Twitter, Facebook
SPDY and HTTP/2
Observing the trend, the HTTP Working Group (HTTP-WG) kicked off a new
effort

to take the lessons learned from SPDY,

to build and improve on them, and

to deliver an official "HTTP/2" standard

HTTP/2
HTTP/2 is a protocol designed for low-latency transport of content over the
World Wide Web

Improve end-user perceived latency

Address the "head of line blocking"

Not require multiple connections

Retain the semantics of HTTP/1.1

Question
How can you improve page load time performance?
Latency vs Bandwidth impact on Page Load Time

Single digit %
perf improvement
after
5 Mbps

Linear
improvement in
page load time!
Latency vs Bandwidth impact on Page Load Time
Decreasing latency has more impact than increasing bandwidth

For Example

Decreasing RTTs from 150 ms to 100 ms have a larger effect on the speed
of the internet than increasing a user’s bandwidth from 3.9 Mbps to 10
Mbps or even 1 Gbps
HTTP/2:Streams, Messages, and Frames
The introduction of the new binary framing mechanism changes how the data
is exchanged between the client and server

Stream

A bidirectional flow of bytes within an established connection, which may

carry one or more messages

Message

A complete sequence of frames that map to a logical request or response

message
HTTP/2: Streams, Messages, and Frames
Frame

The smallest unit of communication in HTTP/2, each containing a

frame header, which at a minimum identifies the stream to which the
frame belongs
HTTP/2: Streams, Messages, and Frames
The frame is the smallest unit of communication that carries a specific
type of data—e.g., HTTP headers, message payload, and so on.

Frames from different streams may be interleaved and then reassembled

via the embedded stream identifier in the header of each frame

HTTP/2 breaks down the HTTP protocol communication into an exchange

of binary-encoded frames, which are then mapped to messages that belong
to a particular stream, and all of which are multiplexed within a single TCP
connection
HTTP/2: Main Characteristics
One TCP connection
Streams are multiplexed
Streams are prioritized
HTTP/2: Main Characteristics
Binary framing layer
Prioritization
Flow control
Server push
Header compression (HPACK)
HTTP/2: Binary framing
HTTP messages are decomposed
into one or more frames

HEADERS for meta-data

DATA for payload

RST_STREAM to cancel
HTTP/2: Binary framing
Each frame has a common header

9-byte, length prefixed

Easy and efficient to parse

HTTP/2: Basic data flow
How many streams are there in the diagram?

How many frames?

HTTP/2: Stream Multiplexing
Streams are multiplexed because frames can be interleaved
HTTP/2: Stream Prioritization
Streams are prioritized based on their weight and dependency
HTTP/2: Stream Multiplexing
What are the advantages of stream multiplexing?
HTTP/2: Stream Multiplexing
Advantages

Interleave multiple requests in parallel without blocking on any one

Interleave multiple responses in parallel without blocking on any one

Use a single connection to deliver multiple requests and responses in

parallel
HTTP/2: Stream Multiplexing
Advantages

Remove unnecessary HTTP/1.x workarounds for optimization, such as

concatenated files, image sprites, and domain sharding

Deliver lower page load times by eliminating unnecessary latency and

improving utilization of available network capacity
HTTP/2: Header Compression
Each HTTP transfer carries a set of headers that describe the transferred
resource and its properties

In HTTP/1.x, this metadata is always sent as plain text and adds anywhere
from 500–800 bytes of overhead per transfer, and sometimes kilobytes
more if HTTP cookies are being used

To reduce this overhead and improve performance, HTTP/2 compresses

request and response header metadata using the HPACK compression
format
HTTP/2
Header Compression

Uses HPACK algorithm

HTTP/2: Server Push
The ability of the server to send multiple responses for a single client request,
without the client having to request each one explicitly
HTTP/2: Server Push
Benefits

Pushed resources can be cached by the client

Pushed resources can be reused across different pages

Pushed resources can be multiplexed alongside other resources

Pushed resources can be prioritized by the server

HTTP/2: Flow Control
A mechanism to prevent the sender from overwhelming the receiver with
data it may not want or be able to process as

the receiver may be busy,

under heavy load, or

may only be willing to allocate a fixed amount of resources for a particular

stream
HTTP/2
Summary

Single TCP

Multiple Stream
Browsers Supporting HTTP/2
https://caniuse.com
Limitations of HTTP/2
What are the limitations of HTTP/2 protocol?
Limitations of HTTP/2
One of the larger issues with HTTP/2 on top of TCP is the issue of
head-of-line blocking

When a TCP packet is lost, no streams on that HTTP2 connection can make
forward progress until the packet is retransmitted and received by the other
side - not even when the packets with data for these streams have arrived and
are waiting in a buffer
QUIC
QUIC (Quick UDP Internet Connections) is a new transport protocol for the
internet, developed by Google

QUIC solves a number of transport-layer and application-layer problems

experienced by modern web applications, while requiring little or no change
from application writers.

QUIC is very similar to TCP+TLS+HTTP2, but implemented on top of UDP

QUIC
Key advantages of QUIC over TCP+TLS+HTTP2 include:

Low connection establishment latency

Improved congestion control

Multiplexing without head-of-line blocking

Forward error correction

Connection migration
QUIC: Low Connection establishment latency
QUIC handshakes frequently require zero roundtrips before sending
payload, as compared to 1-3 roundtrips for TCP+TLS
QUIC: Congestion Control
QUIC has pluggable congestion control, and provides richer information to
the congestion control algorithm than TCP

Currently, Google’s implementation of QUIC uses a reimplementation of TCP

Cubic
QUIC:Multiplexing
Lost packets carrying data for an individual stream generally only impact that
specific stream

Each stream frame can be immediately dispatched to that stream on arrival,

so streams without loss can continue to be reassembled and make forward
progress in the application
QUIC: Forward Error Correction
QUIC can complement a group of packets with an FEC packet, In order to
recover from lost packets without waiting for a retransmission.

If one of the packets in the group is lost, the contents of that packet can be
recovered from the FEC packet and the remaining packets in the group
QUIC: Connection Migration
QUIC connections are identified by a 64 bit connection ID, randomly
generated by the client.

In contrast, TCP connections are identified by a 4-tuple of source address,

source port, destination address and destination port.
QUIC: Connection Migration
QUIC connections are identified by a 64 bit connection ID, randomly
generated by the client.

This means that if a client changes IP addresses (for example, by moving out
of Wi-Fi range and switching over to cellular) or ports (if a NAT box loses and
rebinds the port association), any active TCP connections are no longer valid

When a QUIC client changes IP addresses, it can continue to use the old
connection ID from the new IP address without interrupting any in-flight
requests
HTTP/3: HTTP over QUIC
Instead of using TCP as the transport layer for the session, it uses QUIC

QUIC introduces streams as first-class citizens at the transport layer

QUIC streams share the same QUIC connection, so no additional

handshakes and slow starts are required to create new ones

QUIC streams are delivered independently such that in most cases packet
loss affecting one stream doesn't affect others
HTTP/3: HTTP over QUIC
The transport security used in QUIC is using TLS 1.3 (RFC 8446) and there are
never any unencrypted QUIC connections
HTTP Messages
HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable

In HTTP/2, these messages are embedded into a binary structure, a frame,

allowing optimizations like compression of headers and multiplexing.

Even if only part of the original HTTP message is sent in HTTP/2, the
semantics of each message is unchanged and the client reconstitutes the
original HTTP/1.1 request

HTTP messages typically contain, request/response line, request/response

headers, and/or request/response body
HTTP Messages
HTTP/1.X vs HTTP/2
HTTP Request Message
HTTP Response Message
HTTP Request Methods
GET

The GET method requests a representation of the specified resource

Requests using GET should only retrieve data

POST

The POST method is used to submit an entity to the specified resource,

often causing a change in state or side effects on the server
HTTP Request Methods
PUT

The PUT method replaces all current representations of the target

resource with the request payload

DELETE

The DELETE method deletes the specified resource

PATCH

The PATCH method is used to apply partial modifications to a resource

HTTP Request Methods
HEAD

The HEAD method asks for a response identical to that of a GET request,
but without the response body

OPTIONS

The OPTIONS method is used to describe the communication options for

the target resource
HTTP (Un)Safe Request Methods
A method is considered safe if it doesn’t change the state of the server

GET , HEAD , and OPTIONS are safe methods

POST , PUT , and DELETE methods are not safe as they change the state of the
server
HTTP Idempotent Request Methods
A method is considered idempotent if the state of the server doesn’t
change the second time the method is called with the same data

Safe methods by definition are considered idempotent

PUT and DELETE are idempotent but not safe

POST is neither a safe nor an idempotent method

HTTP Response Status Codes
1xx series – Informational Message

2xx – Success Message

3xx – Redirection Message

4xx – Error Messages Related to Client

5xx – Error Messages Related to Server

Reading Assignments
The WebSocket Protocol

Progressive Web Applications (PWAs)

WebAssembly (Wasm)

https://webassembly.org/
Reference
https://hpbn.co/

https://developers.google.com/web/fundamentals/performance/http2

https://developer.mozilla.org/en-US/docs/Web/HTTP/