Introduction to HTTP protocol: from network requests to protocol specifications
What is the core support for web development? The answer must not be around HTTP (HyperText Transfer Protocol, Hypertext Transfer Protocol). It is like an "information bridge" that allows the browser (client) and server to smoothly exchange all web resources such as HTML, CSS, images, API data, etc.
This article starts from the actual operation of the browser, combined with the visual analysis of Chrome DevTools, to help you quickly master the basic process and core specifications of HTTP, as well as very practical debugging skills in daily development.
1. First clarify a few basic relationships
1.1 HTML ≠ HTTP! Stop mixing it up
When you first come into contact with web development, it is easy to confuse these two concepts. In fact, their division of labor is completely different:
- HTML (HyperText Markup Language, Hypertext Markup Language): It is the carrier of content, through
<h1>、<p>、<img>This type of tag defines the structure and content of a web page; - HTTP: is the content transmission rule, responsible for packaging HTML, CSS, JavaScript, images and other resources, and securely transmitting them from the server to the browser. It also transmits the user's operations in the browser (such as submitting a form) back to the server.
Summary in one sentence: HTML is responsible for "what it looks like", and HTTP is responsible for "how to transport it".
1.2 Choose the right browser to double your development efficiency
Modern web development is almost inseparable from the developer tools of the browser. It is recommended to use Google Chrome first. The reason is very straightforward:
- The built-in DevTools has the most comprehensive functions: network, performance, memory, security and other panels are all available;
- Best standards compatibility: support for new W3C features is usually the fastest;
- Rich plug-in ecosystem: Essential extensions such as Vue DevTools and React DevTools have the most stable experience on Chrome.
All debugging demonstrations in this article use Chrome as an example, please make sure you have a working Chrome browser at hand.
2. Use Chrome DevTools to capture a real HTTP request
Just looking at the text is too abstract, so let's do it in practice - capture the HTTP request sent when accessing the "Sina Home Page" to see what the client sent and what the server returned.
2.1 3 ways to open the DevTools network panel
- Windows/Linux: Press
Ctrl + Shift + I, switch to the Network label; - Mac: Press
Cmd + Opt + I, switch to the Network label; - Common method: Right-click on a blank space on the page → select "Inspect" → switch to the Network tab.
💡 Tips: Make sure the "red dot" in the upper left corner of the panel is lit (indicating that network requests are being recorded), then refresh the page and you will see the waterfall flow of all requests.
2.2 Zoom in to view key requests (withsina.com.cnHTML request as an example)
Find the first status code in the Network panel:200, type isdocumentRequest **, click it, and there will be aHeaders、Responseand other details tags. Let’s focus on the core firstHeaderspart.
🔍 Key request headers issued by the client
Here are a few field interpretations that you will definitely encounter during daily development:
- First line (request line):
GETis the request method,/is the request path (root path),HTTP/1.1is the protocol version. - Host: The domain name to be accessed (and port, the default is 80/443 and can be omitted). Virtual hosts (one server hosts multiple websites) rely on this field to distinguish different sites.
- Accept: Tell the server "which content types I can understand", arranged in order of priority, after the semicolon
q=0.9is the weight, the higher the weight, the priority. - Accept-Encoding: Tells the server "supported compression algorithms". When compression is enabled, transfer sizes tend to be 3–5x smaller, significantly speeding up loading times.
- User-Agent: The client's "identity card", including browser, operating system, kernel and other information. The backend sometimes uses it for device adaptation or statistics.
🔍 Part of the response header returned by the server
Also select a few core fields to explain:
- First line (status line):
200 OKIt is the status code and reason phrase, which means "the request was successful and the data has been returned normally". - Content-Type: Returns the type and encoding of the content. The browser will decide how to render the page based on it (such as displaying it as HTML or triggering a download).
- Cache-Control: The core instruction of cache control. Here's
max-age=60It means "this HTML can be cached locally for 60 seconds, and refreshed again within 60 seconds without re-requesting the server." - Connection: keep-alive: Tell the client "Don't close the TCP connection first, there may be resources to be transmitted using the same connection later", thereby avoiding the delay caused by repeatedly establishing connections (HTTP/1.1 is enabled by default).
3. 3 core knowledge points of HTTP protocol
After understanding what a real request looks like, let's sort out the most commonly used basic knowledge in the protocol. These contents will be used repeatedly whether in interviews or actual development.
3.1 Common HTTP request methods
HTTP defines many methods, but in daily front-end and back-end interactions, 99% of scenarios only use the following 4:
⚠️ Special Note: The parameters of the GET request will be directly exposed in the URL and browser history. Never use GET to transmit sensitive information such as passwords and mobile phone numbers!
3.2 HTTP status codes that can be understood at a glance
Status code is the "feedback code" sent by the server to the client. It is divided into 5 major categories. It is enough to remember the following high-frequency ones:
3.3 Common format of HTTP messages
Whether it is a request or a response, the structure of an HTTP message has a fixed three parts:
- Start line: Request line (such as
GET / HTTP/1.1) or status line (e.g.HTTP/1.1 200 OK); - Header field: one or more key-value pairs, one per line, in the format
字段名: 字段值; - Blank line: Must be a pure blank line, used to separate the header and message body;
- Message body (optional): stores actual data. GET and DELETE requests usually do not have a body, while POST and PUT requests often contain a body.
Here is a simulated POST login request format:
As you can see, the blank line is followed by
{"username":"admin","password":"123456"}It is the main content of the request.
4. 2 practical tips in daily development
4.1 Quickly debug API with DevTools
In projects with separate front-end and back-end, there is no need to write code every time you test the interface. DevTools can help you quickly generate reusable request commands:
- Open the Network tab of DevTools;
- Find the target API request and right-click;
- Select Copy → Copy as cURL (bash);
- Paste the copied content into the terminal and you can run it directly; you can also import it into Postman or Apifox and modify the parameters to continue debugging.
4.2 Simulate weak network environment to test page performance
Sometimes users report that "the page loads very slowly", but when you test it on the Gigabit network in your company, it is very fast. At this time, you can use the network speed simulation function of DevTools to restore the real scene:
- Open the Network tab of DevTools;
- Find the Online drop-down box at the top;
- Select
Fast 3G、Slow 3GevenOffline, you can immediately see the actual performance of the page under a weak network, helping to locate loading bottlenecks.
5. Summary
The HTTP protocol is the "stepping stone" to web development. You don't need to memorize all the headers and status codes from the beginning. First firmly grasp the three core contents of "request method, status code, and common format", and then use Chrome DevTools to capture real requests and practice repeatedly to get started quickly.
If you want to learn more in depth, we recommend the following resources:
- Introductory Book: "HTTP Illustrated" - explained in comic form, easy to understand;
- Authoritative Document: MDN Web Docs - HTTP;
- API testing tools: Postman/Apifox, making interface debugging more efficient.

