This article explains how a single web request traverses HTTP, TLS, TCP/IP, and the link layer. It clarifies message structure, encryption boundaries, and addressing behavior to resolve common confusion around who a request is sent to, which layer parses it, and where encryption applies. Keywords: HTTP, TLS, TCP/IP.
The technical specification snapshot summarizes the scope
| Parameter | Details |
|---|---|
| Source Language | Chinese technical analysis |
| Languages Involved | HTTP messages, JSON, Shell |
| Core Protocols | HTTP, TLS, TCP, UDP, IP, Ethernet/Wi-Fi |
| Source Format | Reconstructed from original CSDN Markdown |
| Star Count | Not provided |
| Core Dependencies | Browser, server, TLS certificate system, TCP/IP protocol stack |
HTTP at the application layer defines what a message looks like
HTTP defines the structure of requests and responses. It does not securely deliver data to a remote endpoint, and it does not choose routes across the Internet. It focuses on how to write the request line, how to declare headers, how to separate sections with a blank line, and how to carry content in the message body.
A standard HTTP request can be summarized as: request line + headers + blank line + body. When developers debug APIs, most errors come from inconsistencies in these four parts rather than from the network layer itself.
POST /api/login?from=web HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 40
Cookie: sid=abc123
{"username":"alice","password":"123"}This message shows the four-part structure of an HTTP request. The blank line marks the end of the headers, and the JSON payload is carried in the body.
The request line determines how the resource is accessed and how the target is expressed
When a client connects directly to the origin server, the request line usually contains only the path and query string, such as /path?query=1. Because the connection is already established to the target server, the application only needs to know which resource to retrieve.
When a proxy is involved, the request line may contain a full URL. In that case, the message must identify not only the resource path but also the external target location, so the proxy can establish a new connection to the target host or forward the request.
GET /docs?id=1 HTTP/1.1
GET http://example.com/docs?id=1 HTTP/1.1The first line is common when connecting directly to an origin server. The second line is common in proxy scenarios. The difference is not the request content itself, but whether the target is expressed in a complete form.
URL encoding solves the placement of reserved and invalid characters
A URL is not an arbitrary string container. Characters such as ?, &, =, /, and # have syntactic meaning. Spaces, Chinese characters, and control characters also cannot appear in a URL as raw text. To solve this, the HTTP ecosystem uses percent-encoding.
The encoding process is straightforward: first encode the text as UTF-8 bytes, then write each byte in hexadecimal form and prefix it with %. This allows Chinese characters, spaces, and reserved characters to be transmitted safely and consistently.
from urllib.parse import quote
text = "网络 协议/HTTP" # Original string containing spaces and a slash
encoded = quote(text, safe="") # Force percent-encoding for special characters
print(encoded) # %E7%BD%91%E7%BB%9C%20%E5%8D%8F%E8%AE%AE%2FHTTPThis code shows how URL encoding converts unsafe characters into a byte representation that can be safely placed in a URL.
Common request headers handle routing, type declaration, and state persistence
Host allows a server to determine which site or virtual host the current request targets after the request arrives. In particular, when multiple sites share a single IP address, Host becomes the key field for application-layer dispatch.
Content-Type describes the format of the request body. It tells the receiver whether to interpret the payload as JSON, HTML, CSS, or binary image data. It does not decide where the data goes; it decides how the data should be interpreted.
Content-Length indicates the size of the body and helps the receiver determine where the body ends. User-Agent exposes browser and operating system information, while Referer indicates the source page and is commonly used for analytics and security policy decisions.
Cookies provide browser-managed local state that is returned automatically for a site
A cookie is essentially a site-scoped key-value pair stored by the browser. The server sends it through Set-Cookie, and the browser automatically includes it in later requests when the domain, path, and expiration rules match.
Cookies are often used to implement login state, but the actual identity data is usually not stored directly in the cookie. Instead, the cookie typically stores a session identifier such as sessionId, and the server uses that identifier to look up the session data.
HTTP/1.1 200 OK
Set-Cookie: sessionId=xyz789; Path=/; HttpOnly
GET /profile HTTP/1.1
Host: example.com
Cookie: sessionId=xyz789This example shows that the browser stores only the session identifier, and the server uses it to restore the user’s authenticated state instead of requiring the password to be submitted again.
HTTP defines message boundaries at the application layer, but TCP does not preserve them
In HTTP/1.1, the end of the headers is determined by a blank line, and the body length is often determined by Content-Length. In other words, HTTP defines where a message ends.
TCP, however, is only a byte-stream protocol. It does not know the boundary of a single request or response. One HTTP request may be split across multiple TCP packets, or data from multiple requests may arrive within the same TCP byte stream segment.
This is the root cause of a common mistake in packet analysis and programming
If a developer assumes that one recv() call equals one complete HTTP request, the code will usually fail. The correct approach is to parse according to HTTP rules: read the headers first, then continue reading the body based on the declared length or chunked transfer rules.
def parse_http_message(raw: bytes):
head, body = raw.split(b"\r\n\r\n", 1) # Split headers and body at the blank line first
headers = head.decode().split("\r\n")
return headers, body # Then continue processing the body based on Content-LengthThis code emphasizes that HTTP must be parsed according to protocol-defined boundaries rather than by assuming TCP delivers a complete message in a single read.
TLS sits between HTTP and the transport layer and encrypts data in transit
TLS does not define the structure of a web page. Its job is to wrap plaintext HTTP into an encrypted stream before handing it to TCP for transmission. That is why HTTPS can be understood as HTTP over TLS over TCP.
Encryption protection applies between the two endpoints of a TLS connection. Data is not directly readable while it is in transit, but once it reaches the TLS termination point, it is decrypted and exposed again as plaintext HTTP.
Proxy-based traffic inspection relies on TLS termination and re-encryption
If the browser trusts a root certificate installed by a proxy, the proxy can establish a trusted TLS connection with the browser. At the same time, the proxy can establish another TLS connection with the real server. Because the proxy sits between these two encrypted links, it can see the decrypted HTTP content.
This does not mean TLS has failed. It means the endpoint of encryption is not always only the origin server; it can also be an intermediate proxy that the user explicitly trusts.
TCP/IP and the link layer work together to provide reachability and hop-by-hop forwarding
After the application layer constructs the HTTP message, the request still must be sent through the TCP/IP stack. The transport layer uses source and destination ports to identify process-level communication endpoints, while the network layer uses source and destination IP addresses to identify host locations.
As a result, what actually delivers data to the target program on the target machine is the combination of destination IP + destination port. This is also the foundation of the socket four-tuple used to establish and identify a connection.
Client: 10.0.0.5:51520
Server: 93.184.216.34:443This combination shows that the IP address determines which machine receives the traffic, while the port determines which service on that machine handles it.
The link layer is responsible only for delivery over the current hop
Link-layer protocols such as Ethernet and Wi-Fi do not care about the final URL, cookies, or TLS certificates. They only move frames from the current device to the next hop and use MAC addresses for local-link addressing.
AI Visual Insight: This diagram shows the per-layer encapsulation flow from the application layer down to the link layer. Higher-layer HTTP data is wrapped by TLS, then passed to TCP/IP, and finally mapped into link-layer frames for transmission. The key point is the division of responsibility: higher layers define semantics, while lower layers deliver data. Each layer processes only the headers and payload visible to that layer.
Developers should understand a complete request through a layered model
A single HTTPS request can be summarized as follows: HTTP defines the message format, TLS protects data in transit, TCP provides a reliable byte stream, IP handles cross-network addressing, and the link layer handles hop-by-hop transmission. These layers do not replace one another; they stack on top of one another.
Once you separate the five responsibilities of semantics, encryption, transport, addressing, and hop-by-hop forwarding, many networking problems become much easier to diagnose.
FAQ provides structured answers to common questions
1. Why do we still need Host if we already have an IP address and a port?
An IP address and port can only deliver the request to a specific service process on a specific machine. The Host header lets that service further distinguish which website the request is for, especially when multiple domains are hosted on the same IP address.
2. After HTTPS encrypts the traffic, can the server still see the HTTP content?
Yes. TLS only protects against eavesdropping during transmission. Once the data reaches the TLS termination point, it is decrypted, so the server or a trusted proxy can read the plaintext HTTP content.
3. What is the relationship between cookies and sessions?
A cookie usually stores only a session identifier, while the session data itself is typically stored on the server side. The browser automatically returns the cookie, and the server uses the sessionId inside it to restore the corresponding login state.
Core Summary: This article uses a single web request as the main thread to reconstruct how the HTTP application layer, the TLS security layer, the TCP/IP transport and network layers, and the link layer work together. It explains the request line, Host, cookies, Content-Type, message boundaries, and the encryption path in HTTPS to help developers build a layered yet coherent understanding of networking.