Understanding the End-to-End Process of a Web Request: IP, DNS, CDN, TCP, Protocol Design, CGI/FastCGI, Server Models, and Database Evolution

When you type a URL like qq.com in a browser, the request goes through several layers: IP addressing, DNS resolution, CDN selection, TCP transport, protocol framing, and finally server‑side processing.

IP, DNS and CDN – IPv4 provides 4‑byte addresses, but due to limited address space private address ranges (10.x.x.x, 172.16‑31.x.x, 192.168.x.x) are used inside LANs. NAT translates private to public IPs. DNS maps domain names to IPs; browsers first check the local hosts file, then query DNS servers. Multiple A records enable simple DNS‑based load balancing, while CDN nodes close to the client reduce latency.

TCP and message framing – TCP is a stream‑oriented protocol; the receiver may get data from several logical messages in one read or a partial message. Application protocols must define boundaries, e.g., HTTP uses \r\n\r\n to separate headers and body and a Content‑Length or chunked transfer encoding to delimit the body.

Protocol design – Common techniques include length‑prefixed binary messages, fixed headers, checksums, and version fields. Text protocols are easy to debug but incur parsing overhead; binary protocols are more efficient for machines.

CGI and FastCGI – Classic CGI spawns a new process per request, passing data via environment variables and stdio. Example CGI program:

#include
#include
int main()
{
    printf("Content-type: text/html\r\n\r\n");
    printf("your name is:%s\n", getenv("QUERY_STRING"));
    return 0;
}

FastCGI keeps worker processes alive and communicates over a socket, eliminating the fork overhead and allowing connection pooling.

Server models – “Web mode” (stateless request‑response) versus “Svr mode” (stateful long‑living connections, push). Synchronous vs asynchronous communication, and the trade‑offs between simplicity and performance.

Database evolution – From simple MySQL tables for point queries, to parameter tuning, to sharding (分库分表) for horizontal scaling, and finally to caching layers such as Redis to offload read traffic. The article explains why Redis is faster (in‑memory, simple key‑value) and the limits imposed by hardware.

The article ties all these layers together to give a holistic view of how a web request travels from the browser to the database and back.