第11章：网络编程

实现古人"天涯若比邻"的梦想

导读

1969年，ARPANET的第一条消息从加州大学洛杉矶分校发往斯坦福研究院，人类从此踏上了一条不可逆转的互联之路。短短半个多世纪后，互联网已经从一个军事实验网络演变为支撑全球经济、文化、政治运行的基础设施。而这一切的基石，是一套叫做 TCP/IP 的协议族，以及一套叫做 Socket 的编程接口。

从应用程序员的角度来看，网络编程的本质是：让运行在不同机器上的两个进程能够互相交换数据。这个看似简单的目标，背后却涉及了地址编码、路由选择、可靠传输、拥塞控制、数据编码等一系列精巧的设计。CSAPP 第11章从程序员的视角出发，剥离了协议栈中那些复杂的底层细节（那些留给专门的计算机网络课程），聚焦于一个核心问题：如何利用 Socket 接口编写能够通过网络通信的程序？

1983年，BSD 4.2 版本首次实现了 TCP/IP 协议栈。由于 UC Berkeley 强大的技术实力和良好的声誉，BSD 成为最流行的 UNIX 发行版。许多其他操作系统的网络部分都基于 BSD 的源代码开发，因此 BSD 极大地加速了互联网前进的步伐。Socket 的英文原意为"插孔"或"插座"，通常称作"套接字"——它允许两个进程进行通信，这两个进程可能运行在同一台机器上，也可能运行在不同机器上。今天，Socket 甚至已经成为网络编程的同义词。

提及网络编程，W. Richard Stevens 对我们这些学习 Unix/Linux 的程序员的影响是巨大的。他写的《UNIX Network Programming》（UNP）至今仍是网络编程领域的"圣经"。每每捧读他的著作，不仅被他丰富的知识所折服，更被他一丝不苟、严谨治学的态度所感动。"他不清楚的，他下决心要弄明白；他知道的，他要努力传授给所有感兴趣的人们！"——这就是 Stevens。

本章的知识结构处于 L6（操作系统内核）和 L7（应用层协议）两个抽象层级之间。我们将从客户端-服务器模型出发，深入 Socket 接口的使用方式，理解 TCP 与 UDP 的本质区别，剖析 HTTP 协议的基本工作原理，最终动手实现一个简易的 Web 服务器，将前面学到的 I/O、进程管理、信号处理等知识融会贯通。

核心概念详解

一、客户端-服务器模型

客户端-服务器模型（Client-Server Model）是网络应用中最基本、最普遍的架构模式。在这个模型中，应用程序被分为两类：客户端和服务器。服务器是一个长期运行的进程，它等待客户端发来请求，处理请求，然后返回响应。客户端则是一个按需启动的进程，它主动向服务器发起连接请求，发送数据，等待并接收服务器的响应。

这个模型的核心特征是不对称性：服务器永远在等待，客户端主动发起；服务器提供资源或服务，客户端消费资源或服务；服务器的地址必须预先已知（否则客户端无法找到它），客户端的地址则在连接建立时动态确定。这种不对称性贯穿了整个互联网的设计。

让我们用 Web 浏览器来具体说明。当你在浏览器地址栏输入 http://www.example.com 并按下回车键时，浏览器作为客户端，会执行以下步骤：首先通过 DNS 将域名解析为 IP 地址；然后向该 IP 地址的 80 端口发起 TCP 连接；连接建立后发送 HTTP GET 请求；服务器收到请求后，找到对应的 HTML 文件，通过 HTTP 响应发回给浏览器；浏览器解析 HTML，渲染页面，呈现给你。整个过程涉及了 DNS 查询、TCP 连接建立、HTTP 请求/响应等多个网络协议协同工作，但从客户端-服务器模型的角度看，就是"客户端请求 → 服务器响应"这样一个简洁的交互模式。

值得注意的是，客户端-服务器模型中的"客户端"和"服务器"是进程级别的概念，而非机器级别的概念。同一台物理机器上可以同时运行服务器进程和客户端进程。事实上，现代 Web 开发中，一台服务器上往往同时运行着 Web 服务器、数据库服务器、缓存服务器等多个服务进程。此外，一个进程在不同场景下可以扮演不同角色——一个 Web 服务器在处理客户端请求时是服务器，但它向数据库服务器查询数据时又变成了客户端。

客户端-服务器模型的对等替代方案是 P2P（Peer-to-Peer）模型，在 P2P 网络中，每个节点既可以是服务提供者也可以是服务消费者，没有固定的服务器角色。BitTorrent、区块链网络等都是 P2P 模型的典型应用。但不可否认，当今互联网的主流架构仍然是客户端-服务器模型——你正在使用的每一个网站、每一个 App，背后都运行着某种形式的服务器。

从更宏观的视角看，客户端-服务器模型还可以扩展为多层架构。两层架构（Two-Tier）是最简单的形式：客户端直接与服务器通信。三层架构（Three-Tier）引入了中间层：客户端 → Web 服务器 → 应用服务器/数据库服务器。现代微服务架构则进一步将三层架构中的"应用服务器"拆分为多个独立的服务，每个服务负责一个特定的业务功能，它们之间通过 RPC 或消息队列进行通信。但无论架构如何演化，其底层通信模式始终是客户端-服务器模型的变体。

二、Socket 接口

Socket（套接字）是 Unix/Linux 系统中网络编程的核心抽象。从程序员的视角看，Socket 是应用层与 TCP/IP 协议族通信的中间软件抽象层，它用一组 C 函数接口的形式，将复杂的网络协议操作封装成了与文件 I/O 类似的操作方式。这种设计深受 Unix 哲学"一切皆文件"的影响——对 Socket 的读写操作与对文件的读写操作使用相同的 read() 和 write() 系统调用。

一个 Socket 由一个IP 地址和一个端口号唯一标识。IP 地址（如 192.168.1.100）确定了网络中的哪台机器，端口号（如 8080）确定了该机器上的哪个进程。两者的组合（称为 Socket 地址或端点）唯一标识了网络中的一个通信端点。一次完整的网络通信涉及两个 Socket：客户端 Socket 和服务器端 Socket，它们共同组成一个 Socket 对（Socket Pair）。

Socket 接口的使用遵循一个清晰的流程。对于 TCP 服务器端：首先调用 socket() 创建一个 Socket 描述符；然后调用 bind() 将其绑定到一个特定的地址和端口；接着调用 listen() 开始监听连接请求；调用 accept() 阻塞等待客户端连接；连接建立后，使用 read()/write() 进行数据收发；通信结束后调用 close() 关闭连接。对于 TCP 客户端：首先调用 socket() 创建 Socket；然后调用 connect() 向服务器发起连接；连接建立后使用 read()/write() 通信；结束后 close() 关闭。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define PORT 8080
#define BUF_SIZE 1024

int main() {
    int server_fd, client_fd;
    struct sockaddr_in server_addr, client_addr;
    socklen_t client_len = sizeof(client_addr);
    char buf[BUF_SIZE];

    server_fd = Socket(AF_INET, SOCK_STREAM, 0);

    int opt = 1;
    setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = INADDR_ANY;
    server_addr.sin_port = htons(PORT);

    Bind(server_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));
    Listen(server_fd, 128);

    printf("Server listening on port %d...\n", PORT);

    while (1) {
        client_fd = Accept(server_fd, (struct sockaddr *)&client_addr, &client_len);
        printf("New connection from %s:%d\n",
               inet_ntoa(client_addr.sin_addr),
               ntohs(client_addr.sin_port));

        int n = Read(client_fd, buf, BUF_SIZE - 1);
        buf[n] = '\0';
        printf("Received: %s\n", buf);

        Write(client_fd, buf, n);
        Close(client_fd);
    }

    Close(server_fd);
    return 0;
}

上面的代码展示了一个最简单的 TCP 回显服务器（Echo Server）。它接受客户端连接，读取客户端发来的数据，然后原样返回。虽然简单，但它包含了 TCP 服务器编程的完整流程。需要特别注意的是，这里使用了 CSAPP 中定义的包装函数（Wrapper Functions）——首字母大写的 Socket、Bind、Listen、Accept、Read、Write、Close，它们会在底层系统调用出错时自动打印错误信息并终止程序，简化了错误处理。

Socket 接口的设计体现了 Unix 的一贯哲学：提供最小化的原语（primitive），让程序员通过组合这些原语来构建复杂的网络应用。socket() 创建通信端点，bind() 绑定地址，listen() 声明被动打开，accept() 接受连接，connect() 主动打开，read()/write() 收发数据，close() 释放资源。每个函数只做一件事，但它们的组合足以实现任何网络协议。

三、TCP 与 UDP

TCP（传输控制协议）和 UDP（用户数据报协议）是传输层的两大核心协议，它们为应用层提供了两种截然不同的通信服务。理解两者的区别，是选择正确的网络编程方案的基础。

TCP 是面向连接的、可靠的、基于字节流的传输协议。 "面向连接"意味着通信双方在数据传输之前必须先建立连接（三次握手），传输结束后释放连接（四次挥手）。"可靠"意味着 TCP 保证数据无差错、不丢失、不重复、按序到达——它通过序列号、确认应答、超时重传等机制来实现这一承诺。"基于字节流"意味着 TCP 将数据视为一连串无结构的字节，没有消息边界的概念——发送方调用 write(sock, "hello", 5) 和 write(sock, "world", 5)，接收方可能一次 read() 读到 "helloworld"，也可能分两次读到 "hel" 和 "loworld"，TCP 不保留发送时的消息边界。

TCP 的这些特性使其成为文件传输、网页浏览、电子邮件等需要可靠数据传输场景的首选。HTTP、HTTPS、FTP、SMTP、SSH 等应用层协议都构建在 TCP 之上。但可靠性是有代价的：三次握手建立连接需要至少一个 RTT（往返时延）的延迟；确认应答和超时重传引入了额外的开销；拥塞控制机制在网络拥堵时会主动降低发送速率；有序交付可能导致队头阻塞（Head-of-Line Blocking）——一个包的延迟会阻塞后续所有包的交付。

UDP 是无连接的、不可靠的、基于数据报的传输协议。 "无连接"意味着发送数据前不需要建立连接，每个数据报都是独立的。"不可靠"意味着 UDP 不保证数据到达，不保证按序到达，不保证不重复——如果数据报在网络中丢失、乱序或重复，UDP 不会做任何补救。"基于数据报"意味着 UDP 保留了消息边界——发送方发送两个 100 字节的数据报，接收方会收到两个 100 字节的数据报，不会合并也不会拆分。

UDP 的"不可靠"听起来像是缺点，但在很多场景下恰恰是优势。首先，UDP 的开销极小——没有连接建立的延迟，没有确认应答的开销，没有拥塞控制的限制，数据传输的延迟更低、更可控。其次，某些应用对实时性的要求高于对可靠性的要求——视频通话偶尔丢一帧画面只是稍微模糊一下，但如果因为重传导致延迟累积，通话体验会急剧恶化。DNS 查询、视频流媒体、在线游戏、VoIP 等应用都选择使用 UDP。此外，DNS 虽然主要使用 UDP，但在响应数据超过 512 字节时也会回退到 TCP，这体现了协议选择的务实性。

从编程角度看，TCP 和 UDP 的 Socket 使用方式也有显著区别。TCP 使用 SOCK_STREAM 类型，需要 listen()、accept()、connect() 来管理连接；UDP 使用 SOCK_DGRAM 类型，没有连接的概念，使用 sendto() 和 recvfrom() 直接收发数据报，每个数据报都需要携带目标地址。

int udp_sock = Socket(AF_INET, SOCK_DGRAM, 0);

struct sockaddr_in dest_addr;
memset(&dest_addr, 0, sizeof(dest_addr));
dest_addr.sin_family = AF_INET;
dest_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
dest_addr.sin_port = htons(9999);

const char *msg = "Hello, UDP!";
sendto(udp_sock, msg, strlen(msg), 0,
       (struct sockaddr *)&dest_addr, sizeof(dest_addr));

char buf[BUF_SIZE];
struct sockaddr_in from_addr;
socklen_t from_len = sizeof(from_addr);
int n = recvfrom(udp_sock, buf, BUF_SIZE - 1, 0,
                 (struct sockaddr *)&from_addr, &from_len);
buf[n] = '\0';
printf("Received: %s\n", buf);

选择 TCP 还是 UDP，本质上是在可靠性和实时性之间做权衡。如果你的应用不能容忍数据丢失，选 TCP；如果你的应用不能容忍延迟抖动，选 UDP；如果你两者都需要，那就基于 UDP 自己实现可靠性（QUIC 协议就是这么做的——Google 在 UDP 之上实现了可靠的、多路复用的传输协议，后来成为 HTTP/3 的基础）。

四、HTTP 协议基础

HTTP（超文本传输协议）是万维网的数据通信基础，也是程序员最容易观察和理解的应用层协议——因为它完全是文本格式的，你可以用 telnet 或 curl 直接阅读和构造 HTTP 消息。

HTTP 遵循客户端-服务器模型，采用请求-响应模式。客户端（通常是浏览器）向服务器发送一个请求消息，服务器处理后返回一个响应消息。HTTP/1.x 默认使用 TCP 作为传输层协议，这也是为什么你可以通过 telnet www.example.com 80 手动发送 HTTP 请求。

一个 HTTP 请求消息由三部分组成：请求行、请求头部、请求体。请求行的格式为 方法 URI 协议版本，例如 GET /index.html HTTP/1.1。常用的 HTTP 方法包括：GET（请求资源）、POST（提交数据）、PUT（更新资源）、DELETE（删除资源）、HEAD（只请求响应头，不传 body）。请求头部携带了额外的元信息，如 Host: www.example.com、User-Agent: Mozilla/5.0、Accept: text/html 等。请求体用于携带客户端提交的数据（如 POST 表单数据、JSON 数据等）。

一个 HTTP 响应消息同样由三部分组成：状态行、响应头部、响应体。状态行的格式为 协议版本状态码原因短语，例如 HTTP/1.1 200 OK。常见的状态码包括：200 OK（请求成功）、301 Moved Permanently（永久重定向）、304 Not Modified（使用缓存）、400 Bad Request（请求格式错误）、403 Forbidden（禁止访问）、404 Not Found（资源不存在）、500 Internal Server Error（服务器内部错误）。响应头部包含 Content-Type（响应体的 MIME 类型）、Content-Length（响应体的字节长度）、Set-Cookie（设置 Cookie）等信息。响应体就是服务器返回的实际数据，比如 HTML 文件的内容。

GET / HTTP/1.1
Host: www.example.com
User-Agent: curl/7.68.0
Accept: */*

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
</head>
<body>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples...</p>
</body>
</html>

上面展示了一次完整的 HTTP 请求和响应的文本格式。注意请求头和响应头之后有一个空行（\r\n），这个空行标志着头部结束、正文开始。对于 GET 请求，请求体通常为空；对于 POST 请求，请求体中携带提交的数据，Content-Length 头部告诉服务器请求体的字节数。

HTTP 是一个无状态协议——服务器不会在请求之间保留任何关于客户端的记忆。每个请求都是独立的，服务器不会记得上一次请求来自谁。这种设计简化了服务器的实现，也使得 HTTP 天然适合分布式部署（任何服务器都可以处理任何请求）。但无状态也意味着无法实现需要跨请求保持信息的功能（如登录状态），因此引入了 Cookie、Session 等机制来在 HTTP 之上构建"有状态"的交互。

HTTP 的版本演进也值得关注。HTTP/1.0 每次请求都需要建立新的 TCP 连接，开销巨大。HTTP/1.1 引入了持久连接（Keep-Alive），一个 TCP 连接可以复用发送多个请求，大幅减少了连接建立的开销。HTTP/2 在单个 TCP 连接上实现了多路复用，允许同时传输多个请求和响应，解决了 HTTP/1.1 的队头阻塞问题。HTTP/3 则基于 QUIC（UDP 之上构建的可靠传输协议），彻底消除了传输层的队头阻塞。从 HTTP/1.1 到 HTTP/3 的演进，本质上是在不断解决"如何在网络上传输数据更高效"这个问题。

五、网络地址与端口：互联网的门牌号系统

要理解网络编程，首先需要理解互联网如何标识每一台机器和每一个进程。这涉及两个核心概念：IP 地址和端口号。

IP 地址是网络层用来标识主机的逻辑地址。IPv4 地址是一个 32 位的无符号整数，通常用点分十进制表示法书写（如 192.168.1.100），每个十进制数对应 8 位。IPv4 地址分为公网地址和私有地址。私有地址（如 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）不会在互联网上被路由，只在局域网内部使用——这就是为什么你家里的电脑 IP 通常是 192.168.x.x。NAT（网络地址转换）技术使得多台使用私有地址的设备可以共享一个公网地址访问互联网，这是 IPv4 地址耗尽问题的重要缓解措施之一。

IPv6 是互联网协议的下一代版本，使用 128 位地址，理论上可以提供约 3.4×10^38 个地址——足够给地球上的每一粒沙子分配一个 IP 地址。IPv6 不仅解决了地址空间不足的问题，还简化了报头格式、内置了 IPSec 安全支持、取消了 NAT 的必要性。但 IPv6 的部署进展缓慢，目前全球 IPv6 流量占比约 40%（各国差异很大），IPv4 和 IPv6 将在相当长的时间内共存。

端口号是一个 16 位的整数，范围从 0 到 65535。它用于标识主机上的不同服务。端口号分为三类：知名端口（0-1023），由 IANA 分配给标准服务，如 HTTP（80）、HTTPS（443）、SSH（22）、FTP（21）、DNS（53）；注册端口（1024-49151），分配给特定的应用程序，如 MySQL（3306）、PostgreSQL（5432）、Redis（6379）；动态端口（49152-65535），由操作系统在客户端发起连接时随机分配。

一个常见的误解是认为端口号是物理存在的——实际上它只是操作系统内核维护的一个数字标识。当数据包到达主机时，内核根据 TCP/UDP 报头中的目标端口号，将数据交付给对应的 Socket（进而交付给对应的进程）。这就是为什么同一台服务器上可以同时运行 Web 服务器（监听 80 端口）和 SSH 服务（监听 22 端口）——它们通过不同的端口号来区分 incoming 的数据。

在编程中，IP 地址和端口号的组合称为 Socket 地址。在 C 语言中，IPv4 的 Socket 地址用 struct sockaddr_in 表示，它包含地址族（sin_family = AF_INET）、端口号（sin_port，网络字节序）和 IP 地址（sin_addr，网络字节序）。地址转换函数如 inet_addr()（字符串转整数）、inet_ntoa()（整数转字符串）、htons()/htonl()（主机字节序转网络字节序）是网络编程中频繁使用的工具函数。

DNS（域名系统）是互联网的"电话簿"——它将人类可读的域名（如 www.example.com）转换为机器可理解的 IP 地址（如 93.184.216.34）。在 C 语言中，gethostbyname() 或更现代的 getaddrinfo() 函数可以执行 DNS 查询。DNS 本身使用 UDP 协议（端口 53）进行查询，当响应数据过大时回退到 TCP。理解 DNS 的工作原理对于排查网络问题至关重要——很多看似"网络不通"的问题，实际上是 DNS 解析失败导致的。

代码示例

一个简易的 Web 服务器

下面我们来实现一个简易的 Web 服务器，它能接受 HTTP GET 请求，返回对应的静态文件。这个服务器虽然简单，但包含了真实 Web 服务器的核心工作流程。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <fcntl.h>

#define MAXLINE 8192
#define MAXBUF 8192
#define PORT 8080

void rio_readinitb(int fd) { /* 初始化带缓冲的读取 */ }

void serve_static(int fd, char *filename, int filesize) {
    char buf[MAXLINE], header[MAXBUF];
    char *suffix;

    suffix = strrchr(filename, '.');

    snprintf(buf, sizeof(buf), "HTTP/1.1 200 OK\r\n");
    snprintf(header, sizeof(header),
             "Server: Tiny Web Server\r\n"
             "Content-Length: %d\r\n"
             "Connection: close\r\n",
             filesize);

    if (suffix && strcmp(suffix, ".html") == 0) {
        strcat(header, "Content-Type: text/html\r\n");
    } else if (suffix && strcmp(suffix, ".jpg") == 0) {
        strcat(header, "Content-Type: image/jpeg\r\n");
    } else if (suffix && strcmp(suffix, ".png") == 0) {
        strcat(header, "Content-Type: image/png\r\n");
    } else if (suffix && strcmp(suffix, ".gif") == 0) {
        strcat(header, "Content-Type: image/gif\r\n");
    } else if (suffix && strcmp(suffix, ".css") == 0) {
        strcat(header, "Content-Type: text/css\r\n");
    } else if (suffix && strcmp(suffix, ".js") == 0) {
        strcat(header, "Content-Type: application/javascript\r\n");
    } else {
        strcat(header, "Content-Type: text/plain\r\n");
    }
    strcat(header, "\r\n");

    int n = snprintf(buf, sizeof(buf), "%s%s", header, "");
    write(fd, buf, n);

    int srcfd = open(filename, O_RDONLY);
    char filebuf[MAXBUF];
    ssize_t bytes;
    while ((bytes = read(srcfd, filebuf, MAXBUF)) > 0) {
        write(fd, filebuf, bytes);
    }
    close(srcfd);
}

void read_requesthdrs(char *buf) {
    char line[MAXLINE];
    int fd = 0;
    while (1) {
        if (read(fd, line, MAXLINE) <= 0) break;
        if (strcmp(line, "\r\n") == 0) break;
    }
}

void parse_uri(char *uri, char *filename, char *cgiargs) {
    if (strstr(uri, "cgi-bin") != NULL) {
        cgiargs[0] = '\0';
    } else {
        strcpy(filename, ".");
        strcat(filename, uri);
        if (uri[strlen(uri) - 1] == '/') {
            strcat(filename, "index.html");
        }
    }
}

void doit(int connfd) {
    char buf[MAXLINE], method[MAXLINE], uri[MAXLINE], version[MAXLINE];
    char filename[MAXLINE], cgiargs[MAXLINE];

    snprintf(buf, sizeof(buf), "");
    sscanf(buf, "%s %s %s", method, uri, version);

    if (strcasecmp(method, "GET") != 0) {
        char *body = "This server only supports GET requests";
        snprintf(buf, sizeof(buf),
                 "HTTP/1.1 501 Not Implemented\r\n"
                 "Content-Type: text/html\r\n"
                 "Content-Length: %ld\r\n"
                 "\r\n"
                 "<html><body><h1>501 Not Implemented</h1>"
                 "<p>%s</p></body></html>",
                 (long)strlen(body), body);
        write(connfd, buf, strlen(buf));
        return;
    }

    parse_uri(uri, filename, cgiargs);

    struct stat sbuf;
    if (stat(filename, &sbuf) < 0 || !S_ISREG(sbuf.st_mode)) {
        char *body = "File not found";
        snprintf(buf, sizeof(buf),
                 "HTTP/1.1 404 Not Found\r\n"
                 "Content-Type: text/html\r\n"
                 "Content-Length: %ld\r\n"
                 "\r\n"
                 "<html><body><h1>404 Not Found</h1>"
                 "<p>%s: %s</p></body></html>",
                 (long)strlen(body), body, filename);
        write(connfd, buf, strlen(buf));
        return;
    }

    serve_static(connfd, filename, sbuf.st_size);
}

int main(int argc, char **argv) {
    int listenfd, connfd;
    struct sockaddr_in serveraddr;

    listenfd = socket(AF_INET, SOCK_STREAM, 0);

    int opt = 1;
    setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

    memset(&serveraddr, 0, sizeof(serveraddr));
    serveraddr.sin_family = AF_INET;
    serveraddr.sin_addr.s_addr = htonl(INADDR_ANY);
    serveraddr.sin_port = htons(PORT);

    bind(listenfd, (struct sockaddr *)&serveraddr, sizeof(serveraddr));
    listen(listenfd, 128);

    printf("Tiny Web Server listening on port %d\n", PORT);

    while (1) {
        connfd = accept(listenfd, NULL, NULL);
        doit(connfd);
        close(connfd);
    }

    return 0;
}

这个 Tiny Web Server 虽然只有约 100 行代码，但它展示了一个真实 Web 服务器的核心逻辑：监听端口 → 接受连接 → 解析 HTTP 请求 → 定位请求的文件 → 构造 HTTP 响应 → 发送文件内容。当然，它有很多不足：它是串行的（一次只能处理一个请求）、只支持 GET 方法、没有 CGI 动态内容支持、没有安全校验（路径遍历攻击）等。但它是一个很好的学习起点——CSAPP 的实验作业（Web Server Lab）就是在这个基础上逐步扩展的。

字节序问题：一个容易踩的坑

网络编程中有一个经典问题：字节序（Byte Order）。不同的 CPU 架构对多字节整数的存储方式不同——x86 采用小端序（Little-Endian，低位字节在前），而网络传输使用大端序（Big-Endian，高位字节在前，也称"网络字节序"）。因此，在发送 IP 地址和端口号时，必须使用 htonl()（host-to-network long）和 htons()（host-to-network short）进行转换；接收时使用 ntohl() 和 ntohs() 反向转换。忘记字节序转换是网络编程中最常见的 bug 之一，而且往往很难调试——因为它在某些机器上可能恰好能工作（如果主机本身就是大端序的话）。

实验解读

自己动手写一个 Web 服务器

CSAPP 的 Network Lab（Proxy Lab）要求学生实现一个支持 HTTP 的代理服务器。这个实验的精妙之处在于，它把前面学到的几乎所有系统编程知识都用上了：

Socket 编程：代理服务器需要同时扮演服务器（接受浏览器连接）和客户端（向目标服务器发起请求）两个角色，需要管理多组 Socket 连接。

进程与并发：为了同时处理多个浏览器请求，代理服务器必须是并发的。你可以选择基于进程的并发（fork()）、基于 I/O 多路复用的并发（select()）或基于线程的并发（pthread）——这正好引出了第12章的内容。

HTTP 协议解析：需要正确解析 HTTP 请求行、请求头、请求体，理解 GET、POST 等方法，处理 Host、Content-Length、Connection 等头部字段。

I/O 与缓冲：在转发数据时，需要高效地处理 I/O 缓冲。一个请求可能很大（如上传文件），不能一次性全部读入内存；响应可能分多个 TCP 包到达，需要正确处理分块传输。

信号处理：子进程退出会产生 SIGCHLD 信号，需要正确捕获并回收僵尸进程。

这个实验的难点不在于单个知识点，而在于如何将多个知识点整合成一个完整的系统。你需要同时考虑连接管理、数据转发、错误处理、并发控制等多个维度。这正是系统编程的魅力所在——它不是孤立的知识点的堆砌，而是一个有机的整体。

建议的实现步骤：首先实现一个能处理单个 HTTP GET 请求的串行代理；然后添加对 POST 请求的支持；接着实现持久连接（Keep-Alive）；最后引入并发机制，使其能同时处理多个请求。每一步都可以独立测试，逐步构建出完整的代理服务器。