HTTP (Hypertext Transfer Protocol)

Every time you open a website, watch a video, shop online, or search on Google, your browser is quietly exchanging messages with a web server using a protocol called HTTP — the Hypertext Transfer Protocol. It is the language that web browsers and web servers use to talk to each other, and it is the foundation the entire World Wide Web is built on.

What Is HTTP?

HTTP is an Application Layer protocol in the TCP/IP protocol suite that defines how a client (typically a web browser) and a web server exchange information over the Internet. It is responsible for transferring web pages, images, videos, stylesheets, scripts, and other resources between servers and the devices that request them.

HTTP works using a client-server architecture:

• The client sends a request.
• The server processes that request.
• The server sends back a response.

This pattern — request, then response — is called the Request-Response Model, and it is the core idea behind everything HTTP does.

Simple definition: HTTP is a communication protocol that allows web browsers and web servers to exchange information over the Internet.

Where the Name Comes From: "Hypertext"

Hypertext is text that contains hyperlinks — clickable references that connect one document to another. For example, if you're reading an article about computer networks and it contains a link such as "Learn more about TCP/IP," clicking that link takes you to another page. That clickable text is hypertext.

HTTP was originally designed specifically to transfer these linked hypertext documents across the Internet — hence the name "Hypertext Transfer Protocol." Today it carries far more than just linked text (images, video, JSON data, and more), but the name has stuck.

HTTP vs. the Internet vs. the World Wide Web

Beginners often use "the Internet" and "the Web" interchangeably, but they are different things:

In short: the Internet provides connectivity, and HTTP is one of the protocols that uses that connectivity to move web content around.

Why Do We Need HTTP?

Imagine there were no standard rules for how browsers and servers communicate. Chrome might format its requests one way, Firefox another way, and Edge yet another. Every server would need to understand every browser's own private "dialect," which would make the Web unworkable.

HTTP solves this by giving every browser and every server a single, shared set of rules: how a request should be formatted, how a response should be formatted, and what the possible outcomes (status codes) mean. As long as both sides speak HTTP, it doesn't matter which browser, server software, or operating system either side is running.

Analogy: Think of a restaurant. The customer doesn't walk into the kitchen — they tell a waiter what they want, the waiter relays it to the kitchen, and the waiter brings the food back. In HTTP terms:

Browser → HTTP Request → Web Server → HTTP Response → Browser

HTTP is the "waiter" — a standardized go-between that lets the client and server communicate without needing to know the internal details of the other side.

A Brief History of HTTP

HTTP was invented by Tim Berners-Lee at CERN in 1989–1991 to support the newly proposed World Wide Web. Since then, it has evolved through several major versions, each aimed at improving speed, efficiency, or security.

HTTP/0.9 Example

The earliest version of HTTP had no headers or metadata — a request was just a single line:

GET /index.html

The server would simply return the raw HTML with no status code or headers attached.

Why HTTP/1.0 Needed a New Connection Per Request

In HTTP/1.0, every single request-response exchange required opening a fresh TCP connection, which is slow because of the TCP handshake overhead. HTTP/1.1's persistent connections fixed this by letting multiple requests and responses reuse the same connection.

Why HTTP/3 Uses QUIC Instead of TCP

TCP guarantees reliable, ordered delivery, but if a single packet is lost, TCP blocks all the data behind it until that packet is retransmitted — a problem known as "head-of-line blocking." QUIC (built on UDP) manages multiple independent data streams so that a lost packet on one stream doesn't stall the others, which is especially useful on mobile and Wi-Fi connections where packet loss is common.

The Components of HTTP Communication

HTTP communication involves four main components working together:

1. The Client The client is the application making the request — usually a web browser (Chrome, Firefox, Edge, Safari) or a mobile app. Its responsibilities are to send HTTP requests, receive responses, and render or process the content it gets back.

2. The Web Server The web server stores website files and application logic, and it processes incoming client requests. Common web server software includes Apache HTTP Server, Nginx, and Microsoft IIS. Its responsibilities are to receive requests, process them (which may involve running application code or querying a database), and send back an HTTP response.

3. The Internet (Transport Path) Between the client and server, the request and response travel across the physical and logical infrastructure of the Internet — routers, switches, fiber-optic cables, wireless links, and the networks of Internet Service Providers (ISPs).

4. The HTTP Protocol Itself HTTP is the rulebook both sides agree to follow. It defines the request format, the response format, the set of headers that can carry metadata, the methods (like GET and POST) that describe an action, and the status codes that describe an outcome.

How HTTP Works: The Request-Response Cycle

When you load a web page, HTTP goes through the following steps:

1. You enter a URL, for example https://www.example.com.

2. DNS resolution — the browser looks up the domain name to find the server's IP address.

3. Connection setup — the browser opens a connection to that server (a TCP handshake for HTTP/1.1 and HTTP/2, or a QUIC handshake for HTTP/3).

4. The browser sends an HTTP request, for example:

   GET / HTTP/1.1
   Host: www.example.com

5. The server processes the request — it locates the requested resource, runs any necessary application logic, and prepares a response.

6. The server sends back an HTTP response, for example:

   HTTP/1.1 200 OK
   Content-Type: text/html
   
   <html>
     ...
   </html>

7. The browser renders the response — it parses the HTML and displays the page.

Example: Loading a Real Page

Suppose you type https://www.wikipedia.org into your browser. The browser sends a request for the homepage, and the server responds with the HTML document. But that HTML almost never arrives alone — it references additional resources such as images, CSS stylesheets, JavaScript files, and web fonts. Each of these is fetched with its own separate HTTP request and response, which is why a single page load can trigger dozens of individual HTTP exchanges behind the scenes.

Key Features of HTTP

1. Client-Server Architecture

HTTP cleanly separates the client (which presents information) from the server (which stores and processes it). This separation means the two sides can be developed, scaled, and maintained independently — a server can be rewritten entirely without requiring any change to how browsers behave, as long as it still speaks HTTP correctly.

2. Connectionless by Design

HTTP is traditionally described as a connectionless protocol: conceptually, the client sends a request, the server sends a response, and that logical exchange is then complete — HTTP itself does not keep an ongoing "conversation" open the way a phone call does.

In practice, HTTP/1.1 and later versions use persistent (keep-alive) connections to reuse the same underlying TCP connection for multiple requests, purely as a performance optimization. This is a transport-level efficiency, not a change to HTTP's fundamentally request-and-response nature — each request-response pair is still handled as a discrete exchange.

3. Stateless Protocol

This is one of HTTP's most important — and most often misunderstood — characteristics. HTTP is stateless, meaning the protocol itself does not retain any memory of previous requests. Each request is processed as if it were the very first one the server has ever seen from that client.

Why this matters: Suppose you log in at example.com/login, then navigate to example.com/profile. Because HTTP has no built-in memory, the server has no native way of knowing that the request to /profile came from the same user who just logged in — as far as raw HTTP is concerned, it's a brand-new, unrelated request.

This is precisely why web applications rely on additional mechanisms — cookies, server-side sessions, and authentication tokens — layered on top of HTTP to simulate a continuous, logged-in experience.

4. Media Independent

HTTP is not limited to transferring HTML. It can carry virtually any kind of data — images, video, audio, PDFs, JSON, XML, and more. The MIME type (specified in the Content-Type header) tells the receiving side what kind of data is in the body of the message, so the browser knows whether to render it as a web page, play it as a video, or download it as a file.

5. Extensible

New HTTP headers, methods, and features can be introduced without breaking the core protocol. This is how HTTP has been able to grow — from serving static HTML in 1991 to powering real-time web applications, streaming media, and APIs today — without requiring a complete redesign each time.

How Cookies Solve the Statelessness Problem

Since HTTP itself cannot remember users between requests, websites need another way to recognize a returning visitor. This is done with HTTP cookies.

A cookie is a small piece of data that a server asks the browser to store. Once stored, the browser automatically attaches that cookie to every subsequent request it sends to the same website, until the cookie expires or is deleted.

Common uses of cookies:

• Keeping users logged in across page loads
• Remembering user preferences (like language or theme)
• Maintaining the contents of a shopping cart
• Tracking a browsing session for analytics
• Personalizing content shown to a specific visitor

Example flow:

1. You log in to an online store.
2. The server includes a Set-Cookie header in its response, and your browser stores that cookie.
3. When you click to view another page, your browser automatically sends the stored cookie back with the new request.
4. The server reads the cookie, recognizes you, and keeps you logged in — without you having to re-enter your credentials.

Analogy: This works much like a wristband at a movie theater. You show your ticket once at the entrance and receive a wristband; after that, staff only need to glance at the wristband to know you've already been let in — they don't ask to see your original ticket again at every doorway. A cookie plays the same role for a web server: it's a small token that lets the server recognize you on later requests without you having to prove who you are every single time.

Note: Cookies are a mechanism built on top of HTTP to work around its statelessness — they are not part of the core HTTP request-response mechanism itself.

Key Points to Remember

• HTTP stands for Hypertext Transfer Protocol and operates at the Application Layer of the TCP/IP model.
• It follows a client-server, request-response model.
• HTTP is stateless — it does not remember previous requests on its own.
• Cookies, sessions, and tokens are used on top of HTTP to maintain user state across requests.
• HTTP is media independent and can transfer HTML, images, video, JSON, PDFs, and more.
• HTTP has evolved through several versions — HTTP/1.1, HTTP/2, and HTTP/3 — each improving performance, and HTTP/3 notably moves from TCP to QUIC over UDP.