An Overview of HTTP: Various Concepts and Protocols Related to HTTP

What is HTTP?

HTTP stands for Hypertext Transfer Protocol, which is an application layer protocol used for transmitting information between network devices. It is the foundation of the World Wide Web, enabling communication between browsers and servers to load web pages. In simple terms, when you open a browser and enter a URL, HTTP acts like a courier, delivering content from the server to you. In daily life, for example, when you browse news on your phone, HTTP works silently in the background to ensure articles and images are displayed quickly.

The Basic Process of Request and Response

HTTP operates on a client-server model: the client (such as a browser) initiates a request, and the server processes it and returns a response. The request includes a method (such as GET to retrieve a webpage), a URL, and header information; the response contains a status code and content. For example, when you search for “cat pictures”, the browser sends a GET request, and the server replies with 200 OK along with the images, just like asking a friend for photos and they send them to you.

Common Methods and Status Codes

Methods define actions: GET retrieves data, while POST submits forms. Status codes provide feedback on the result: 2xx indicates success, while 4xx indicates client errors. In everyday life, POST is like sending an email attachment, while 404 is like dialing the wrong number and no one answers.

Evolution of Versions

From HTTP/1.0 to HTTP/3, each version optimizes connection and speed. HTTP/2 allows multiple requests to be sent in parallel, like a multi-lane highway reducing congestion.

HTTP (Hypertext Transfer Protocol) is an indispensable part of the internet, responsible for transmitting data between your device and remote servers, allowing us to easily browse web pages, send emails, or watch videos. This article will provide a comprehensive overview of the concepts and protocols related to HTTP, explained in simple and understandable language, avoiding overly technical details, and using everyday examples to aid understanding. Just like the design philosophy of HTTP itself—simple and extensible—we will start from the basics and gradually expand the discussion.

The Origin and History of HTTP

The birth of HTTP can be traced back to 1989, developed by Tim Berners-Lee at CERN (the European Organization for Nuclear Research). It was initially designed to make it easier for scientists to share research documents. The first version, HTTP/0.9, appeared in 1991 and only supported the simple GET method for retrieving HTML pages, without headers or complex features. At that time, the internet was still very primitive, like the early telephone system, which could only dial and say a few words.

With the explosive growth of the internet, HTTP rapidly evolved:

• HTTP/1.0 (1996): Introduced header information, more methods (such as POST), and support for various file types. Each connection was closed after a request, like sending a letter and hanging up the phone.
• HTTP/1.1 (1997): Added persistent connections (keep-alive), allowing the reuse of the same connection to send multiple requests, avoiding the need to establish connections repeatedly. It also supported chunked transfer and range requests, allowing for resuming downloads of large files. In daily life, this is like chatting with a friend without hanging up the phone after every sentence.
• HTTP/2 (2015): Based on Google’s SPDY protocol, it uses binary frames, multiplexing (multiple requests transmitted simultaneously over a single connection), and header compression, significantly improving speed. The server can also “push” content, such as when the browser requests a webpage, the server proactively sends related CSS files. Imagine driving: HTTP/1.1 is a single lane prone to traffic jams, while HTTP/2 is multi-lane allowing parallel traffic.
• HTTP/3 (2022): Uses the QUIC protocol based on UDP for transmission instead of traditional TCP, reducing latency and performing better, especially in unstable networks. Tests show it may be up to 3 times faster than HTTP/1.1, but its adoption rate is controversial due to compatibility issues. Currently, the usage rates are approximately 33.8% for HTTP/1.1, 35.3% for HTTP/2, and 30.9% for HTTP/3.

These versions are all backward compatible, meaning new browsers can handle old protocols. The evolution of HTTP reflects the transition of the internet from static pages to dynamic applications, but it has also sparked debates about compatibility and security. Some experts argue that the inefficient connections of older versions lead to energy waste, while the complexity of new versions may increase implementation difficulties.

The Basic Working Principle of HTTP: Client-Server Model

HTTP is a client-server protocol: the client (such as your browser, mobile app, or debugging tool) initiates a request, and the server processes and responds. There may be intermediaries, such as proxies (like cache servers or load balancers), which act like transfer stations, helping to accelerate or filter content.

• Connection Methods: HTTP relies on reliable transport layers like TCP (port 80 for unencrypted, 443 for encrypted). HTTP/1.0 opened a new connection for each request, while HTTP/1.1 introduced persistent connections, and HTTP/2 multiplexed multiple requests over a single connection. HTTP/3 uses UDP with QUIC to reduce handshake time.
• Statelessness: HTTP does not remember previous interactions; each request is processed independently. However, state can be simulated through Cookies, such as e-commerce sites remembering your shopping cart. In daily life, this is like shopping at a supermarket: stateless is introducing yourself from scratch every time, while stateful is remembering your preferences through a membership card.

Example: You open a browser and enter “www.example.com”, the browser, as the client, opens a TCP connection, sends a request, and the server responds before closing or reusing the connection. If there is a proxy, it may cache the page, retrieving it directly from the cache next time, saving time.

HTTP Message Structure: Request and Response

The core of HTTP communication is the message, which includes requests (sent from the client) and responses (returned from the server). HTTP/1.1 messages are human-readable text, while HTTP/2 uses binary frames for optimization, but the semantics remain the same.

Request Message

A request includes:

• Start Line: Method + Path + Version, for example, “GET /index.html HTTP/1.1”.
• Headers: Key-value pairs providing additional information, such as “Host: www.example.com” (specifying the server), “User-Agent: Mozilla/5.0” (browser type), and “Accept: text/html” (accepted formats).
• Body (optional): Data, such as username and password during form submission.

Common Methods:

Method	Description and Example
GET	Retrieves resources without changing the server. Example: browsing a webpage, like asking a friend, “Show me your photos”.
POST	Submits data to create a new resource. Example: logging into a website, sending username and password, like mailing a letter to a friend.
HEAD	Retrieves only header information, not the body. Example: checking file size first by asking, “How big is this video?”
PUT	Updates a resource. Example: editing a profile, like replacing an old photo.
DELETE	Deletes a resource. Example: removing items from a shopping cart, like throwing away an unwanted list.
PATCH	Partially updates. Example: changing only the password without altering other information, like mending a hole in clothing.

Response Message

Includes:

• Start Line: Version + Status Code + Phrase, for example, “HTTP/1.1 200 OK”.
• Headers: Such as “Content-Type: text/html” (content type) and “Content-Length: 1024” (length).
• Body: Actual data, such as HTML code.

Classification of Status Codes:

Category	Examples and Explanations
1xx	Informational, such as 100 Continue: The server says, “Continue sending data”.
2xx	Success, such as 200 OK: The request is complete; 201 Created: A new resource has been created.
3xx	Redirection, such as 301 Moved Permanently: The resource has moved, go to the new address.
4xx	Client errors, such as 404 Not Found: The page does not exist, like a wrong address; 403 Forbidden: No permission.
5xx	Server errors, such as 500 Internal Server Error: The server has malfunctioned, like a chef getting sick in a restaurant.

Example: You submit a form (POST request), and the server replies with 200 OK and a confirmation page; if the URL is wrong, it replies with 404, like going to the wrong restaurant address.

Key Concepts: Headers, Caching, Cookies, and Sessions

• Headers: Like labels on an envelope, providing context. Request headers inform the server of your needs, while response headers describe the returned content. Example: Cache-Control headers control caching, like telling a courier, “Don’t rush to throw this package away, keep it for backup”.
• Caching: Browsers or proxies store resources to avoid repeated downloads. Example: Frequently visited news pages load faster after being cached by the browser, like a refrigerator storing commonly used food.

• Cookies: Small pieces of data stored in the browser for tracking state. Example: Websites remember your login, like a supermarket membership card tracking points. However, Cookies raise privacy concerns, as some believe they can be misused to track user behavior.
• Sessions: Maintain state using Cookies or hidden variables. Example: Online shopping, from adding items to the cart to checkout, is like a conversation where you don’t have to repeat your needs each time.

These concepts make HTTP more flexible, but security must also be considered: headers may leak information, and caches may store outdated data.

Related Protocols: Extending the Functionality of HTTP

HTTP is not isolated; it collaborates with other protocols to form a more powerful system.

• HTTPS: The secure version of HTTP, using TLS to encrypt connections (port 443). It protects data from eavesdropping, with over 85% of websites adopting it. Example: Logging into online banking using HTTPS is like sending a password in an encrypted envelope; not using it could allow a man-in-the-middle to spy.HTTPS is not perfect, as certificate forgery poses a potential risk.
• HTTP/2 and HTTP/3: As mentioned above, they optimize performance. HTTP/2‘s multiplexing reduces latency, while HTTP/3‘s QUIC handles packet loss better. Example: Watching high-definition videos, HTTP/3 is like a high-speed train, faster than older versions of regular trains.
• WebSocket: A persistent bidirectional communication protocol based on HTTP for real-time applications. Example: Chatting in an App is like making a phone call instead of sending a text message and waiting for a reply.
• QUIC: The underlying protocol for HTTP/3, using UDP to reduce latency. Example: Browsing on weak WiFi signals, QUIC is like an off-road vehicle, more stable than a car using TCP.
• Others: Such as Gopher (an outdated predecessor of HTTP) and Gemini (a lightweight protocol focused on privacy). These protocols address the limitations of HTTP, such as unidirectionality and lack of encryption.

Controversies: Some believe that HTTP/3‘s use of UDP may increase security vulnerabilities, but supporters emphasize its speed advantages, especially in mobile networks.

Security and Challenges of HTTP

HTTP itself has no built-in security, making it vulnerable to eavesdropping or tampering. This has led to the popularity of HTTPS, but issues remain:

• Authentication: Verifying users using basic or digest schemes, often combined with Cookies. Example: Logging into a website is like swiping a key card.
• Vulnerabilities: Such as head-of-line blocking (a slow request in HTTP/1.1 blocking subsequent requests) or cache poisoning. In daily life, this is like a package being swapped during delivery.
• Attacks: DDoS attacks flood servers with a large number of HTTP requests, like a crowd blocking a door.

To balance this, browsers enforce HTTPS, and developers use headers like Strict-Transport-Security to enforce encryption. Overall, the security of HTTP relies on implementation: a good configuration is like a sturdy lock, while a poor one is like a door left ajar.