Web System Architecture and Protocols
Introduction to Web Protocols
The Language of the Web
When you visit a website, your browser and the website's server have a conversation. They speak a specific language to understand each other: the Hypertext Transfer Protocol, or HTTP. Think of it as a set of rules for asking for and receiving information online.
This process is based on a client-server model. Your browser is the client, and the computer hosting the website is the server. The client sends a request for a resource, like a webpage or an image, and the server sends back a response containing that resource.
Every time you click a link or type a URL, your browser crafts an HTTP request. This request is a text message that tells the server exactly what you want. The server then processes this request and sends back an HTTP response, which includes the content you asked for and some extra information about the response itself.
Crafting the Request
An HTTP request has a few key parts, but the most important is the method. The method tells the server what kind of action the client wants to perform. While there are several methods, a few do most of the work on the web.
| Method | Purpose |
|---|---|
| GET | Requests a specific resource, like a webpage. This is the most common method. |
| POST | Submits data to be processed, like filling out a contact form. |
| PUT | Updates a specific resource with new data. |
| DELETE | Removes a specific resource from the server. |
Along with the method, the request includes the path to the resource (e.g., /products/shoes) and headers, which provide additional context, like the type of browser making the request. Here's a simplified look at a GET request for a homepage.
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
The server's response also has a clear structure. It starts with a status code, a three-digit number that signals the outcome of the request. You’ve likely seen a 404 error before, which means the requested resource was not found. Status codes are grouped into categories.
200s: Success! The request was completed. (e.g.,
200 OK) 300s: Redirection. You're being sent somewhere else. 400s: Client Error. The request was bad. (e.g.,404 Not Found) 500s: Server Error. Something went wrong on the server's end.
Upgrading the Conversation
The long-standing version of the protocol, HTTP/1.1, had a significant limitation. It could only handle one request at a time over its connection. If you requested a webpage with many images and scripts, the browser had to ask for each one sequentially. This created a bottleneck known as "head-of-line blocking," where a slow request could hold up all the others behind it.
To solve this, HTTP/2 was introduced. It's a major upgrade that allows for multiplexing, which means multiple requests and responses can travel at the same time over a single connection. The data for different files is broken down and interleaved, then reassembled by the browser. This eliminates the head-of-line blocking problem and makes websites load much faster.
HTTP/2 also brought other improvements:
- Header Compression: Request headers for a single site are often repetitive. HTTP/2 compresses them, reducing the amount of data sent with each request.
- Server Push: A server can proactively “push” resources to the browser that it knows will be needed, without waiting for the browser to ask. For example, when you request a webpage, the server can push the associated stylesheet at the same time, saving a round trip.
Ready to check your understanding of how the web communicates?
In the client-server model of HTTP, what is the primary role of a web browser?
What major limitation of HTTP/1.1, known as "head-of-line blocking," was solved by the introduction of multiplexing in HTTP/2?
These protocols are the invisible foundation of our daily web browsing, constantly evolving to deliver information faster and more efficiently.