HTTP
The complete HTTP request flow can be divided into the following steps:
- DNS Resolution
When a client (usually a browser) enters a URL (such as https://www.example.com), it first needs to resolve the corresponding IP address.
This process involves the DNS (Domain Name System). The browser will query the local cache, system cache, or send a request to the DNS server, and finally obtain the IP address of www.example.com (such as 192.168.1.1).
- Establishing a TCP Connection
Establish a TCP connection with the server through a three-way handshake:
The client sends a SYN (synchronization) request.
The server returns SYN + ACK (synchronization acknowledgment).
The client sends an ACK (acknowledgment), and the connection is successfully established.
- Sending an HTTP Request
The client sends an HTTP request, which mainly includes:
Request Line:
GET /index.html HTTP/1.1
Headers:
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive
Body:
Only present in request methods such as POST and PUT, such as JSON data, form data, etc.
- Server Processing the Request
The server parses the request:
Checks the URL route
Verifies permissions
Queries the database
Processes business logic
The server generates an HTTP response.
- Server Returning the HTTP Response
The server returns an HTTP response, which mainly includes:
Status Line:
HTTP/1.1 200 OK
Response Headers:
Content-Type: text/html; charset=UTF-8
Content-Length: 1024
Set-Cookie: sessionId=abc123; Path=/
Response Body:
Such as HTML page content, JSON data, etc.
- Browser Parsing & Rendering
The browser parses HTML, CSS, JavaScript, and starts rendering the page.
If additional resources (such as CSS, JS, images) are encountered, the browser will initiate another HTTP request to obtain these resources.
- Connection Closure
HTTP/1.1 uses Keep-Alive by default, allowing TCP connections to be reused.
If Connection: close, the server and client will perform a four-way handshake to close the TCP connection.
- User Interaction & Further Requests
Users may click on links on the page, triggering new HTTP requests and repeating the above process.
That’s a complete HTTP request flow! 🚀
HTTPS
The Complete HTTPS Request Flow
HTTPS (HyperText Transfer Protocol Secure) adds SSL/TLS encryption to the basis of HTTP to ensure data security. Compared with HTTP, HTTPS mainly adds the SSL/TLS handshake process. The complete HTTPS request flow is as follows:
- DNS Resolution
Function: Resolve the domain name to an IP address, the same as HTTP.
Process:
The browser first queries the local DNS cache
If there is no result, initiate a query to the system DNS server or public DNS (such as 8.8.8.8)
The DNS server returns example.com -> 192.168.1.1
- Establishing a TCP Connection
Establish a TCP connection through a three-way handshake (same as HTTP).
The client sends SYN
The server responds with SYN + ACK
The client sends ACK
Purpose: Ensure that both the client and the server can send and receive data.
- SSL/TLS Handshake (Unique to HTTPS)
After the TCP connection is established, the client and server communicate securely through TLS (Transport Layer Security)/SSL (Secure Sockets Layer):
The client sends ClientHello
Specify the supported TLS version (such as TLS 1.2 / TLS 1.3)
Supported encryption algorithms (Cipher Suites)
Generated random number (used for subsequent key calculation)
The server responds with ServerHello
Determine the TLS version
Select the encryption algorithm
Generate a random number
Send the SSL certificate (including the server’s public key)
The client verifies the server certificate
Check if the certificate is trusted (whether it is issued by a trusted CA)
Whether the certificate has expired
Whether the domain name of the certificate matches
Key Exchange
The client encrypts a symmetric key (used for data encryption) with the server’s public key
The server decrypts with its own private key to obtain the symmetric key
Subsequent communications will use this symmetric key for encryption
Handshake Completion
The client and server send Finished messages, indicating that the handshake is completed
Subsequent HTTP requests/responses are transmitted through the TLS encrypted channel
- Sending an HTTPS Request
The request format is the same as HTTP, but the data is encrypted:
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Bearer token
- Server Processing the Request
Decrypt the HTTPS request
Parse the HTTP request
Process business logic (such as database query, identity verification)
Generate an HTTP response
- Server Returning the HTTPS Response
The response data is transmitted after being encrypted with a symmetric key
Response format (encrypted transmission):
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionId=abc123
Body: …
- Browser Parsing & Rendering
The browser decrypts the HTTPS response and parses HTML/CSS/JS
When additional resources (such as CSS, JS, images) are found, initiate another HTTPS request (repeat the above process)
- Connection Closure
Keep-Alive mode: TCP connections can be reused to reduce handshake overhead
Closing the connection:
If Connection: close, the TCP connection is closed through a four-way handshake
Advantages of HTTPS over HTTP
✅ Data encryption (prevents eavesdropping)
✅ Identity authentication (prevents counterfeit servers)
✅ Data integrity (prevents man-in-the-middle tampering with data)
HTTPS is more secure than HTTP, but it also has handshake overhead, resulting in a slightly slower first request. However, modern optimization technologies (such as TLS 1.3, Session Resumption) have greatly reduced this impact.