HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0 | Learn System Design

System Design

Learn System Design

Introduction to System Design

How to Learn System Design?

Key Characteristics of Distributed Systems

Scalability

Availability

Latency and Performance

Concurrency and Coordination

Monitoring and Observability

Resilience and Error Handling

Fault Tolerance vs. High Availability

Flashcards Review

Chapter Assessment

Network Essentials

HTTP vs. HTTPS

TCP vs. UDP

HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

URL vs. URI vs. URN

What Happens When You Type a URL into the Browser

Flashcards Review

Chapter Assessment

Long-Polling vs. WebSockets vs. Server-Sent Events

Introduction to Real-Time Communication

What is Long-Polling?

What is WebSocket?

What are Server-Sent Events?

Difference Between Long-Polling, WebSockets, and Server-Sent Events

Flashcards Review

Chapter Assessment

Domain Name System (DNS)

Introduction to DNS

DNS Resolution Process

DNS Load Balancing and High Availability

Flashcards Review

Chapter Assessment

Proxies

What is a Proxy Server?

Uses of Proxies

VPN vs. Proxy Server

Flashcards Review

Chapter Assessment

Load Balancing

Introduction to Load Balancing

Load Balancing Algorithms

Uses of Load Balancing

Load Balancer Types

Stateless vs. Stateful Load Balancing

High Availability and Fault Tolerance

Scalability and Performance

Challenges of Load Balancers

Flashcards Review

Chapter Assessment

API Gateway

Introduction to API Gateway

Usage of API gateway

Advantages and disadvantages of using API gateway

Flashcards Review

Chapter Assessment

API Design

What Is an API?

What Are REST APIs?

Resources, Not Actions

HTTP Methods and Their Semantics

URL Design

Request and Response Shapes

Status Codes and Error Design

Pagination from the Consumer's View

Idempotency Keys

Versioning and Backward Compatibility

Concurrency and Conditional Requests

REST vs gRPC vs GraphQL

Flashcards Review

Chapter Assessment

Rate Limiting and Throttling

What Is Rate Limiting

Rate Limiting Algorithms

Distributed Rate Limiting

Rate Limiting in Practice

Flashcards Review

Chapter Assessment

Caching

Introduction to Caching

Why is Caching Important?

Types of Caching

Cache Replacement Policies

Cache Invalidation

Cache Read Strategies

Cache Coherence and Consistency Models

Caching Challenges

Cache Performance Metrics

Flashcards Review

Chapter Assessment

CDN

What is CDN?

Origin Server vs. Edge Server

CDN Architecture

Push CDN vs. Pull CDN

Flashcards Review

Chapter Assessment

Data Partitioning

Introduction to Data Partitioning

Partitioning Methods

Data Sharding Techniques

Benefits of Data Partitioning

Common Problems Associated with Data Partitioning

Flashcards Review

Chapter Assessment

Redundancy and Replication

What is Redundancy?

What is Replication?

Replication Methods

Data Backup vs. Disaster Recovery

Flashcards Review

Chapter Assessment

CAP & PACELC Theorems

Introduction to CAP Theorem

Components of CAP Theorem

Trade-offs in CAP Theorem

Examples of CAP Theorem in Practice

Beyond CAP Theorem

System Design Trade-offs in Interviews

Flashcards Review

Chapter Assessment

Databases (SQL vs. NoSQL)

Introduction to Databases

SQL Databases

NoSQL Databases

SQL vs. NoSQL

ACID vs BASE Properties

Real-World Examples and Case Studies

SQL Normalization and Denormalization

In-Memory Database vs. On-Disk Database

Data Replication vs. Data Mirroring

Database Federation

Flashcards Review

Chapter Assessment

Indexes

What are Indexes?

How a B-Tree Index Works

Types of Indexes

B-Tree vs. LSM Tree

Indexes in Distributed Systems

Flashcards Review

Chapter Assessment

Bloom Filters

Introduction to Bloom Filters

Benefits & Limitations of Bloom Filters

Variants and Extensions of Bloom Filters

Applications of Bloom Filters

Flashcards Review

Chapter Assessment

Quorum

Why Quorum?

What is Quorum?

Flashcards Review

Chapter Assessment

Leader and Follower

What is Leader and Follower Pattern?

Flashcards Review

Chapter Assessment

Heartbeat

What is Heartbeat?

Flashcards Review

Chapter Assessment

Checksum

What is Checksum?

Uses of Checksum

Flashcards Review

Chapter Assessment

Distributed Messaging System

Introduction to Messaging System

Introduction to Kafka

Messaging patterns

Popular Messaging Queue Systems

RabbitMQ vs. Kafka vs. ActiveMQ

Scalability and Performance

Flashcards Review

Chapter Assessment

Distributed File Systems

What is a Distributed File System?

Architecture of a Distributed File System

Key Components of a DFS

Flashcards Review

Chapter Assessment

Security

What is Security and Privacy?

What is Authentication?

What is Authorization?

Authentication vs. Authorization

OAuth vs. JWT for Authentication

What is Encryption?

What are DDoS Attacks?

Flashcards Review

Chapter Assessment

Misc Concepts

Batch Processing vs. Stream Processing

XML vs. JSON

Synchronous vs. Asynchronous Communication

Push vs. Pull Notification Systems

Microservices vs. Serverless Architecture

Message Queues vs. Service Bus

Stateful vs. Stateless Architecture

Event-Driven vs. Polling Architecture

Flashcards Review

Chapter Assessment

Quiz - System Design Fundamentals

Quiz

System Design Trade-offs

Importance of Discussing Trade-offs

Strong vs Eventual Consistency

Latency vs Throughput

ACID vs BASE Properties in Databases

Read-Through vs Write-Through Cache

Batch Processing vs Stream Processing

Load Balancer vs. API Gateway

API Gateway vs Direct Service Exposure

Proxy vs. Reverse Proxy

API Gateway vs. Reverse Proxy

SQL vs. NoSQL

Primary-Replica vs Peer-to-Peer Replication

Data Compression vs Data Deduplication

Server-Side Caching vs Client-Side Caching

REST vs RPC

Polling vs. Long-Polling vs. WebSockets vs. Webhooks

CDN Usage vs Direct Server Serving

Serverless Architecture vs Traditional Server-based

Stateful vs Stateless Architecture

Hybrid Cloud Storage vs All-Cloud Storage

Token Bucket vs Leaky Bucket

Read Heavy vs Write Heavy System

Quiz

How to Approach a System Design Interview

System Design Interviews - A step by step guide

Functional vs. Non-functional Requirements

What are Back-of-the-Envelope Estimations?

Things to Avoid During System Design Interview

System Design Master Template

Quiz

Designing a URL Shortening Service like TinyURL

Quiz - Designing URL Shortner

Designing Pastebin

Quiz - Designing Pastebin

Designing Instagram

Quiz - Designing Instagram

Designing Dropbox

Quiz - Designing Dropbox

Designing Facebook Messenger

Quiz - Designing Facebook Messenger

Designing Twitter

Quiz - Designing Twitter

Designing Youtube or Netflix

Quiz - Designing Youtube

Designing Typeahead Suggestion

Quiz - Designing Typeahead Suggestion

Designing an API Rate Limiter

Quiz - Designing an API Rate Limiter

Designing Twitter Search

Quiz - Designing Twitter Search

Designing a Web Crawler

Quiz - Designing a Web Crawler

Designing Facebook’s Newsfeed

Quiz - Designing Facebook’s Newsfeed

Designing Yelp or Nearby Friends

Quiz - Designing Yelp or Nearby Friends

Designing Uber backend

Quiz - Designing Uber backend

Designing Ticketmaster

Quiz - Designing Ticketmaster

Dynamo: How to design a key value store?

Dynamo: Introduction

High-Level Architecture

Data Partitioning

Replication

Vector Clocks and Conflicting Data

The Life of Dynamo’s put() & get() Operations

Anti-entropy Through Merkle Trees

Gossip Protocol

Dynamo Characteristics and Criticism

Summary: Dynamo

Quiz: Dynamo

Mock Interview: Dynamo

Designing YouTube Likes Counter (medium)

YouTube Likes Counter

Quiz

Cassandra: How to Design a Wide-column NoSQL Database?

Cassandra: Introduction

High-level Architecture

Replication

Cassandra Consistency Levels

Gossiper

Anatomy of Cassandra's Write Operation

Anatomy of Cassandra's Read Operation

Compaction

Tombstones

Summary: Cassandra

Quiz: Cassandra

Mock Interview: Cassandra

Kafka: How to Design a Distributed Messaging System?

Messaging Systems: Introduction

Kafka: Introduction

High-level Architecture

Kafka: Deep Dive

Consumer Groups

Kafka Workflow

Role of ZooKeeper

Controller Broker

Kafka Delivery Semantics

Kafka Characteristics

Summary: Kafka

Quiz: Kafka

Mock Interview: Kafka

Chubby: How to Design a Distributed Locking Service?

Chubby: Introduction

High-level Architecture

Design Rationale

How Chubby Works

File, Directories, and Handles

Locks, Sequencers, and Lock-delays

Sessions and Events

Master Election and Chubby Events

Caching

Database

Scaling Chubby

Summary: Chubby

Quiz: Chubby

Mock Interview: Chubby

HDFS: How to Design File Storage System?

Hadoop Distributed File System: Introduction

High-level Architecture

Deep Dive

Anatomy of a Read Operation

Anatomy of a Write Operation

Data Integrity & Caching

Fault Tolerance

HDFS High Availability (HA)

HDFS Characteristics

Summary: HDFS

Quiz: HDFS

Mock Interview: HDFS

GFS: How to Design a Distributed File System Storage?

Google File System: Introduction

High-level Architecture

Single Master and Large Chunk Size

Metadata

Master Operations

Anatomy of a Read Operation

Anatomy of a Write Operation

Anatomy of an Append Operation

GFS Consistency Model and Snapshotting

Fault Tolerance, High Availability, and Data Integrity

Garbage Collection

Criticism on GFS

Summary: GFS

Quiz: GFS

Mock Interview: GFS

BigTable: How to Design a Wide Column Storage System?

BigTable: Introduction

BigTable Data Model

System APIs

Partitioning and High-level Architecture

SSTable

GFS and Chubby

Bigtable Components

Working with Tablets

The Life of BigTable's Read & Write Operations

Fault Tolerance and Compaction

BigTable Refinements

BigTable Characteristics

Summary: BigTable

Quiz: BigTable

Mock Interview: BigTable

Designing Reddit (medium)

Design Reddit

Quiz

Designing Notification Service (medium)

Designing a Notification System

Quiz

Design Google Calendar (medium)

Design Google calendar (Medium)

Quiz

Design a Recommendation System (medium)

Design a Recommendation System for Netflix

Quiz

Designing Gmail (medium)

Design Gmail

Quiz

Designing Google News (medium)

Design Google News, a Global News Aggregator System (Medium)

Quiz

Designing Unique ID Generator (medium)

Design Unique ID Generator (Easy)

Quiz

Designing Code Judging System (medium)

Design Code Judging System like LeetCode (Medium)

Quiz

Designing Payment System (hard)

Design Payment System

Quiz

Designing Flash Sale System (hard)

Design a Flash Sale for an E-commerce Site (Hard)

Quiz

Designing Reminder Alert System (hard)

Design a Reminder Alert System

Quiz

System Design Patterns

Introduction: System Design Patterns

1. Bloom Filters

2. Consistent Hashing

3. Quorum

4. Leader and Follower

5. Write-ahead Log

6. Segmented Log

7. High-Water Mark

8. Lease

9. Heartbeat

10. Gossip Protocol

11. Phi Accrual Failure Detection

12. Split Brain

13. Fencing

14. Checksum

15. Vector Clocks

16. CAP Theorem

17. PACELC Theorem

18. Hinted Handoff

19. Read Repair

20. Merkle Trees

Quiz

HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

network protocols

http

tcp

availability

hard

14 min

·Updated Sep 2026·Credit: System Design Fundamentals

You open a product page in an online store. To show it, the browser needs about 80 files: the HTML page, stylesheets, scripts, fonts, and many images.

How the browser fetches those 80 files has changed three times. Each new version of HTTP fixed a delay that the previous version created.

This lesson follows four versions of HTTP in order. For each one, it explains what changed, why it helped, and which problem was left for the next version to solve.

Why Page Loads Were Slow

The previous lesson showed that a TCP connection starts with a handshake. The handshake costs one round trip, which is the time for a message to reach the server and come back. HTTPS adds a TLS handshake on top, which costs at least one more round trip.

A round trip between a user and a server often takes 50 to 150 ms. So every new connection adds a noticeable delay before any file data moves.

This cost matters for everything that follows. Most changes to HTTP were about opening fewer connections and waiting less on each one.

HTTP/1.0

In HTTP/1.0, every request opens a new TCP connection, and the connection closes after the response.

It uses a simple request and response model.
It is stateless, so the server keeps no session information between requests.
Messages are plain text, with basic headers for content type and caching.

For a page that is one document with a few images, this is fine. For a page with 80 files, it is slow.

Here is the cost in numbers. Suppose a round trip takes 100 ms. Opening 80 connections one after another adds 80 x 100 ms, which is 8 seconds of handshakes. And that does not count the time to send the file data.

The problem it left: a new connection for every single file.

HTTP/1.1

HTTP/1.1 fixed the biggest cost of HTTP/1.0, and it added several other features.

Persistent connections. The TCP connection stays open after a response, so the browser can send many requests over it. Setting up one connection replaces setting up 80. This greatly reduces latency for pages with many files.

Chunked transfer encoding. A server can send a response in pieces, called chunks, as it creates them. It does not need to know the total size before it starts sending.

Better caching. New headers, like Cache-Control and ETag, give browsers and servers more control over what to store and when to check for a newer version.

The Host header. Every request now names the website it wants, like Host: shop.example.com. So one server, with one IP address, can host many websites. The server reads the Host header to decide which site to serve. This is called virtual hosting.

HTTP/1.0 opens and closes a new connection for every file, while HTTP/1.1 opens one connection and reuses it for many requests

The Problem HTTP/1.1 Left

On one HTTP/1.1 connection, requests still go one at a time. The browser sends a request, waits for the full response, then sends the next one.

So if one response is slow, like a large image, every request behind it waits. This is called head-of-line blocking: the first item in the line blocks everything behind it.

HTTP/1.1 did allow pipelining, which means sending several requests without waiting for each response. But the responses still had to come back in the same order, and many servers handled it badly. So browsers rarely used it.

Instead, browsers opened about six connections to each domain at the same time. This helped, but every extra connection needed its own handshakes. And each connection still handled only one request at a time.

HTTP/2.0

HTTP/2.0 changed how messages travel over a connection. It kept the same methods, status codes, and headers. It is usually written as HTTP/2.

A binary format. Messages are sent in a binary format instead of plain text. Binary is faster for computers to read, and computers make fewer mistakes reading it than reading text.

Frames and streams. HTTP/2 splits every message into small pieces called frames. Each request and its response form a stream, and each stream has a number.

Multiplexing. Frames from many streams can be mixed together on one connection. Many requests and responses are in progress at the same time, over a single connection. The browser puts the frames back together by stream number.

Under HTTP/1.1 a slow response makes the next requests wait, while under HTTP/2 many streams share one connection and each response arrives when it is ready

Multiplexing ends head-of-line blocking at the HTTP layer. A slow image no longer makes the stylesheet wait. So one connection per domain is enough again.

Header compression with HPACK. Requests to the same site repeat many of the same headers, like cookies and the browser name. HPACK compresses headers and avoids sending the same values again, which saves bandwidth.

Server push. A server can send a file to the browser before the browser asks for it. For example, when the browser requests the HTML page, the server can also push the stylesheet it knows the page needs. In practice, server push was hard to use well, and major browsers later removed support for it.

In practice, browsers use HTTP/2 only over HTTPS. So HTTP/2 almost always runs with TLS encryption.

The Problem HTTP/2 Left

HTTP/2 still runs on TCP. TCP delivers one ordered stream of bytes, and it does not know about HTTP streams.

So when one TCP packet is lost, TCP holds back all the data that arrived after it until the lost packet is sent again. That data may belong to many different HTTP streams. One lost packet stalls every stream on the connection.

HTTP/2 fixed head-of-line blocking at the HTTP layer, but the same problem remains in TCP underneath. On networks that lose packets often, like busy mobile networks, HTTP/2 can even be slower than HTTP/1.1 with six connections.

Over TCP one lost packet stalls every HTTP/2 stream, while over QUIC a lost packet affects only the stream it belongs to

HTTP/3.0

HTTP/3.0, usually written as HTTP/3, replaces TCP with a new transport protocol called QUIC. QUIC runs over UDP. Its name originally stood for Quick UDP Internet Connections.

QUIC rebuilds the parts of TCP that HTTP needs, like reliable delivery and congestion control. But it handles lost data separately for each stream.

Better handling of packet loss. QUIC knows about streams. When a packet is lost, only the stream that the packet belongs to waits for the resend. All other streams keep moving. This is why HTTP/3 handles packet loss better than HTTP/2 on real networks.

Faster connection setup. QUIC combines the connection handshake and the TLS handshake into one step. A new connection needs one round trip before the first request. A browser that has connected to the server before can often use 0-RTT, which means zero round trips: it sends its request immediately.

Encryption built in. QUIC includes TLS 1.3 as part of the protocol. Encryption is always on, not an optional layer added on top.

Header compression with QPACK. QPACK does the same job as HPACK, but it is designed for QUIC's independent streams.

Connection migration. A TCP connection is tied to the IP addresses and ports of both sides. When a phone moves from Wi-Fi to mobile data, its IP address changes, and TCP connections break. QUIC identifies a connection with a connection ID instead, so the connection can continue on the new network.

With a 100 ms round trip, HTTP/2 over TCP and TLS 1.3 waits about 200 ms before the first request, a new HTTP/3 connection about 100 ms, and a resumed one about 0 ms

One caution about 0-RTT. Data sent with 0-RTT can be captured and sent again by an attacker, which is called a replay. So servers accept 0-RTT only for requests that are safe to repeat, like reading a page.

Which Version Is Used Today

Most large websites and CDNs support HTTP/1.1, HTTP/2, and HTTP/3 at the same time.

The browser and the server agree on a version automatically.

During the TLS handshake, they choose between HTTP/1.1 and HTTP/2.
The server can also announce that it supports HTTP/3, with a response header called Alt-Svc. The browser then tries HTTP/3 on later requests.
If UDP traffic is blocked, for example by a company firewall, the browser uses HTTP/2 over TCP instead.

HTTP/1.1 is still very common too. Many simple tools, internal services, and older systems use it, because it is easy to read and debug.

	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	TCP	QUIC over UDP
Connections	New one per request	Persistent, about 6 per domain	One, multiplexed	One, multiplexed
Message format	Text	Text	Binary	Binary
Head-of-line blocking	Yes	Yes, per connection	Only in TCP, on packet loss	No, loss affects one stream
Header compression	No	No	HPACK	QPACK
Encryption	Optional	Optional	In practice, always TLS	Always, TLS 1.3 built in

Read the table from left to right. Each version removed one delay: first repeated connections, then waiting in line on a connection, then waiting on lost TCP packets.

Key Takeaways

HTTP/1.0 opens a new TCP connection for every request and closes it after the response.
HTTP/1.1 adds persistent connections, chunked transfer encoding, better caching, and the Host header, which lets many websites share one IP address.
HTTP/1.1 still handles one request at a time per connection, so slow responses cause head-of-line blocking.
HTTP/2 uses a binary format and multiplexes many streams over one connection. It adds HPACK header compression and server push.
HTTP/2 still runs on TCP, so one lost packet stalls every stream on the connection.
HTTP/3 runs on QUIC over UDP. It handles packet loss per stream, sets up connections faster with 0-RTT for repeat visits, and builds in TLS 1.3.
Browsers and servers agree on a version automatically, and use an older one when needed.

Each version of HTTP kept the same idea of requests and responses, and changed how they travel. The next lesson, URL vs. URI vs. URN, explains three terms for naming the resources that those requests ask for.

Practice Questions

Try each question first, then open the answer.

1. A page needs 30 files, and a round trip takes 50 ms. How much time do TCP handshakes add under HTTP/1.0, if the files load one after another? How much under HTTP/1.1 with one persistent connection?