做嵌入式Web服务器这行的人多多少少都碰过这样的需求设备上跑着一个几十KB的HTTP服务页面是静态的但偶尔要读一次传感器、查一次配置、点一下重启静态文件就不够用了。这时候要么塞一个模板引擎进去要么把请求交给外部程序处理——后者就是CGI。我最近把shttpd这个以精简著称的Web服务器源码里CGI支持那部分翻了个底朝天越看越觉得这套设计值得单独拎出来讲它没有引入任何第三方库靠一对管道加一次fork/exec就把动态请求打通了代码量小到可以一晚上读完却把 CGI 规范里最容易被忽略的几个坑都绕开了。这篇东西写给两类人一类是想给自己的小服务器加动态能力、又不想背一个框架的同学另一类是已经在用 shttpd、但一遇到空白页和挂死就抓瞎的运维和嵌入式开发。我会把整体设计、环境变量拼装、管道收发、超时控制、以及我踩过的那些坑按源码顺序一层层拆开讲代码都是可编译可复现的。1. 先想清楚迷你Web服务器为什么要接CGI1.1 CGI的本质是一次“进程级函数调用”很多人第一次看 CGI 规范会觉得它很土每次请求都fork一个新进程跑完就退出开销大得离谱。但把它放到嵌入式设备、内部工具、单机管理后台这些场景里土办法反而是最稳的办法。我习惯用这样一个类比来解释静态文件服务像是餐厅里的自助餐台菜是提前摆好的客人来了直接取CGI 像是后厨现做客人点单HTTP 请求服务员把点单小票环境变量和标准输入递进后厨窗口厨师外部程序做好菜标准输出再递出来。窗口只有两个一个递进去一个递出来双方不需要认识对方只需要约定好小票上写什么、菜怎么摆盘。这个“约定”就是 CGI 规范。所以 CGI 的核心从来不是某个函数而是三件事怎么把请求信息交给子进程环境变量 stdin、怎么把子进程的结果收回来stdout、怎么保证双方都不会卡死管道读写顺序与超时。shttpd 的 CGI 实现本质上就是围绕这三点写的加起来几百行但每一行都在解决具体问题。1.2 为什么不内嵌解释器而选择外部进程做完选型对比之后我对 shttpd 这个决定是认可的。当时摆在面前的路大概有三条我把当时的权衡整理成了下面这张表方案实现成本内存占用隔离性崩溃影响适合场景内嵌脚本引擎高要引入解释器大常驻几十到几百KB差同一地址空间整个服务挂掉逻辑复杂、请求频繁服务端包含SSI低极小无隔离无只做变量替换的页面CGI 外部进程低一次forkexec按需跑完即释放好独立进程只影响单次请求低频、异构语言、需要调用系统命令第三条路的最大好处是语言无关。设备上要读一个串口用 C 写个小程序要生成一份报表用脚本语言十行搞定要调用厂商提供的二进制工具直接exec就行。服务器本身完全不需要知道对面是什么它只认标准输入输出。这种解耦在资源受限、又需要快速堆功能的场景里价值远大于那点进程创建开销。代价也很明确每次请求一次进程创建在 ARM 平台上大概几百微秒到几毫秒并发一高就会顶到进程数上限。所以 shttpd 这类服务器的定位从来不可能是高并发网关它服务的是“一天几千次请求”的管理界面。想清楚这个边界后面的所有设计取舍就都顺了。1.3 CGI在shttpd整体结构中的位置shttpd 的请求处理是一条很直的流水线监听套接字 → 接受连接 → 解析请求行和头部 → 按 URI 找处理函数 → 生成响应 → 关闭连接。它内部维护了一张“URI 前缀 → 处理函数”的表静态文件、目录列表、认证、代理各占一项CGI 也是其中之一只不过它的匹配规则不是固定前缀而是“这个路径对应的文件是否可执行”。这个设计带来的一个直接后果是CGI 处理函数拿到的已经是解析完毕的请求结构体方法、URI、查询串、头部、body 长度都在里面它不需要再做一次 HTTP 解析。这一点很关键因为这意味着 CGI 模块的职责被压缩得非常纯粹——只做“翻译”把结构体翻译成环境变量把 body 翻译成管道字节把管道字节翻译回 HTTP 响应。我在改造时特意保留了这层边界不让 CGI 模块去碰套接字读写。原因很简单一旦 CGI 代码直接往客户端套接字写数据超时控制、连接复用、错误响应就没法统一处理了最后会变成一堆特判。保持“CGI 产出的是内存里的一个响应缓冲区”后面无论是加 gzip 还是加日志都好做。2. 一次CGI请求的完整生命周期拆解2.1 从URL到可执行文件路径映射的三个坑请求进来是/cgi-bin/status.cgi/sensor/1?fmtjson服务器要做的第一件事是把它变成一个真实文件路径。这里有三段信息必须被正确切开脚本路径/cgi-bin/status.cgi路径附加信息PATH_INFO/sensor/1查询串QUERY_STRINGfmtjson很多人写这步的时候直接strchr(uri, ?)一刀切然后把前半段当文件名去stat结果就是/cgi-bin/status.cgi/sensor/1这个路径stat失败返回 404。正确做法是从右往左逐段回退直到找到一个真实存在且可执行的文件剩下的部分才是 PATH_INFO。shttpd 里这段逻辑是按目录逐级判断的先把 URI 里?后面的部分截出来存进查询串然后从完整路径开始每次去掉最后一段再试直到命中。这个“逐段回退”的写法看着笨但它顺带解决了另一个问题——目录遍历防护。因为每一段都会检查是否含有..回退过程中任何一段不合法就直接拒绝不需要额外写一个专门的路径规范化函数。这里有个我踩过的坑值得单独说PATH_INFO里的内容必须做 URL 解码但查询串不能提前解码。因为 CGI 规范规定查询串以原始形式传给子进程由子进程自己决定怎么解。如果你在服务器里先解了一遍子进程里的%26就变成了参数会被错误地切开。我在一个配置页面上被这个坑咬了很久表现是“密码里带特殊字符就登录失败”查了两天才定位到是双重解码。还有权限判断。stat拿到st_mode之后判断“是不是普通文件”和“有没有执行位”用的是两个不同的宏S_ISREG和S_IXUSR。少了前者一个可执行的目录也会被当成脚本去exec然后exec失败返回一个莫名其妙的空响应少了后者会试图执行一个普通文本文件报EACCES。两个都要判。2.2 环境变量的拼装字段、顺序与内存布局CGI 规范里定义了十几个必须传的环境变量shttpd 的实现思路是先算总长度一次性malloc一块连续内存然后往里面逐条snprintf。这个做法比“申请一个字符串数组逐条 strdup”省事也避免了后面释放时漏掉某一条。必须传的字段我按重要性排了一下变量名来源不传会怎样REQUEST_METHOD请求行几乎所有框架直接报错QUERY_STRINGURI 中?之后GET 参数全部丢失CONTENT_LENGTH头部 Content-LengthPOST body 读不到子进程阻塞在 readCONTENT_TYPE头部 Content-Type表单解析失败SCRIPT_NAMEURI 中脚本部分生成自链接时错乱SCRIPT_FILENAME磁盘真实路径部分框架靠它定位自身PATH_INFOURI 剩余部分路由式 CGI 无法工作SERVER_PROTOCOL请求行少数库依赖REMOTE_ADDR对端地址日志里看不到来源GATEWAY_INTERFACE固定值CGI/1.1老框架会拒绝服务最容易被漏掉的是CONTENT_LENGTH。它不是“可选优化”而是子进程判断“该不该读 stdin、读多少”的唯一依据。标准输入是管道不是文件没有 EOF 可等——父进程不关写端子进程的read就一直阻塞。这就是很多“POST 请求永远转圈”问题的根因。另一个细节是HTTP 头部的转换规则所有请求头都要变成HTTP_前缀名字转大写-换成_。比如User-Agent变成HTTP_USER_AGENTX-Forwarded-For变成HTTP_X_FORWARDED_FOR。转换时要注意头部名字里可能出现的下划线本身虽然规范不建议但现实里确实有客户端发X_Custom转换后会和X-Custom撞车。shttpd 的做法是不做额外处理直接替换这个取舍我认为是合理的——加转义规则反而会让通用 CGI 程序认不出来。内存布局上还有个隐蔽问题环境变量块必须以两个连续的\0结尾。手写的时候如果只补一个execve会一路读越界表现是子进程环境里出现一堆乱码变量或者干脆段错误。我在第一次手写这块时就栽在这后来养成习惯申请时len 1最后显式buf[pos] \0; buf[pos1] \0;并且断言pos 2 len。2.3 请求体如何穿过管道进入子进程GET 请求没有 body这部分可以跳过POST 和 PUT 就绕不开了。shttpd 在类 Unix 系统上用socketpair造一对双向描述符一个给子进程当 stdin/stdout一个留在父进程手里。用socketpair而不是两个单向pipe好处是只需要管理一对描述符且支持全双工某些 CGI 程序会在读取 body 的同时往 stderr 写日志双向通道能少一次死锁风险。写 body 的顺序有讲究。标准做法是父进程fork之后在父进程侧先把 body 全部写进管道再关闭写端然后才去读子进程的输出。如果反过来先读输出而 body 又比较大超过管道缓冲区Linux 上默认 64KB子进程在写 stdout 时会被阻塞父进程在等 stdout 数据双方互等死锁。不过“先写完再读”也有它的问题如果 CGI 程序是流式输出的比如一边处理一边打印进度它可能在读完 body 之前就开始写输出这时候如果 body 特别大父进程写管道会被阻塞。稳妥的解法是把父进程侧的两个描述符都设成非阻塞用select或poll同时监听“可写”和“可读”谁就绪处理谁。shttpd 这种追求代码量的实现通常走的是简单路线——先写后读同时给 body 设一个上限比如几百 KB超过就直接 413。这个取舍在小工具场景里完全够用但如果你要传文件上传就必须改成事件驱动。顺带说一句HEAD 请求也要执行 CGI但输出要丢弃。有些实现图省事HEAD 直接返回 200 不跑脚本结果Content-Length和 GET 对不上前端做预检时就会出问题。正确的做法是照常跑把读到的数据丢掉只保留头部Content-Length用实际读到的字节数填。2.4 子进程的输出怎么被解析成HTTP响应CGI 程序输出的不是完整 HTTP 响应而是“头部 空行 正文”。头部里最关键的是Content-Type如果缺了它服务器就不知道该给客户端什么类型浏览器表现就是下载文件或者显示空白。所以解析逻辑的第一步是在输出缓冲区里找\r\n\r\n或\n\n找到之前的部分当 CGI 头之后的部分当正文。shttpd 这里做得比较务实它不逐行解析所有 CGI 头只挑几个需要特殊处理的。Status:头用来覆盖默认的 200 状态码格式是Status: 404 Not FoundLocation:头如果存在且没有Status就按 302 处理这是重定向的标准玩法。其余的头比如Set-Cookie、Cache-Control原样透传给客户端。这里有个非常容易翻车的细节CGI 输出的换行可能是\n也可能是\r\n取决于脚本语言和运行平台。如果你只匹配\r\n\r\n一个用printf手写的 C 程序输出\n\n服务器就找不到分隔符会把整个输出包括头部当成正文吐给浏览器页面上就会出现Content-Type: text/html这行字。我第一次写的时候就是这样浏览器里明晃晃地显示着自己的响应头非常滑稽。所以匹配逻辑要两种都认并且优先匹配更长的那个。还有一个边界如果 CGI 程序什么都没输出就退出了服务器必须自己造一个响应通常是 500 加一句“CGI returned no data”。这个兜底不做客户端会收到一个空的 200然后一直等到超时。3. 源码级走读关键函数与那段绕不开的代码3.1 职责划分三个函数撑起整条链路shttpd 的 CGI 部分可以粗略分成三层我在重写时基本照搬了这个划分入口层负责路径匹配、权限判断、构造环境变量块失败时直接返回错误码。执行层fork 重定向描述符 execve只做“把进程跑起来”这一件事。收发层父进程侧写 body、读输出、解析头部、等待子进程结束并回收。这样分层的好处是每一层都能单独测。比如收发层可以脱离fork用一对socketpair加一个线程来模拟调试起来快得多。我在排查一个“读不到输出”的问题时就是先把收发层单独抽出来跑五分钟就确认问题出在执行层的描述符没关干净。入口层里有个细节值得说chdir到脚本所在目录。很多 CGI 程序会用相对路径读同目录下的配置文件如果不切目录它会去服务器进程的工作目录找自然找不到。shttpd 在执行前会chdir到脚本的父目录这一步必须放在execve之前的子进程分支里否则会影响服务器本身的工作目录。3.2 fork与exec描述符关闭顺序决定成败下面这段是我按 shttpd 的结构重写的精简版把关键点都标出来了。它不是原文照抄而是为了把逻辑看清楚做的等价简化/* 返回值0 成功-1 失败 */ static int cgi_spawn(const char *prog, char *const envp[], int *to_child, int *from_child) { int sp[2]; pid_t pid; /* 用 socketpair 而不是两条 pipe方便全双工 */ if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) ! 0) return -1; pid fork(); if (pid 0) { close(sp[0]); close(sp[1]); return -1; } if (pid 0) { /* 子进程只保留一端 */ close(sp[0]); dup2(sp[1], STDIN_FILENO); dup2(sp[1], STDOUT_FILENO); /* stderr 也重定向过去否则子进程报错信息会丢 */ dup2(sp[1], STDERR_FILENO); if (sp[1] STDERR_FILENO) close(sp[1]); /* 切到脚本目录让相对路径可用 */ if (chdir(dir_of(prog)) ! 0) _exit(127); execve(prog, (char *const[]){ (char *)prog, NULL }, envp); _exit(127); /* execve 失败才会走到这里 */ } /* 父进程 */ close(sp[1]); *to_child *from_child sp[0]; return (int)pid; }几个点必须强调。第一子进程必须_exit而不是exit。exit会刷新父进程继承下来的 stdio 缓冲区可能导致响应被重复输出两遍也可能在fork之后触发一些不该触发的清理逻辑。第二execve失败后一定要_exit(127)绝不能让子进程继续往下跑否则它会回到服务器的accept循环里变成两个进程抢同一个监听套接字症状是请求随机丢一半极难排查。第三dup2之后要把原描述符关掉否则子进程会多持有一个引用父进程读输出时就永远等不到 EOF。3.3 读写循环里的超时与背压父进程侧的核心是一个循环先把 body 写完如果有然后shutdown写端再循环read直到返回 0 或者遇到错误。这里的“返回 0”就是子进程关闭了输出端等价于 EOF。超时必须自己管。shttpd 用的是select加一个超时值每次循环前算一下剩余时间。如果不做超时一个死循环的 CGI 脚本能把工作进程永久占住多来几次整个服务器就没法响应了。默认值我一般设 5 到 10 秒——管理类脚本通常足够太短会误杀慢查询。缓冲区的选择也有讲究。读缓冲我一般用 2048 或 4096 字节理由是太小会导致系统调用次数上升太大在嵌入式环境里浪费栈或者堆。如果输出要整体拼在内存里shttpd 的做法是把输出攒成一个连续缓冲区再统一发送那就得同时设一个总量上限比如 1MB超过就断开并记日志防止一个cat大文件的脚本把内存吃光。计算一下最坏情况会更直观假设并发 32 个连接每个 CGI 输出上限 1MB那就是 32MB 的峰值内存。在一个 64MB 内存的设备上这已经危险了所以实际部署时我把上限压到 256KB并且把并发 CGI 数量限制在 8 个以内。这个数字不是拍脑袋来的是拿“页面最大体积 × 最大并发”倒推的超过就降级返回 503。写 body 那一侧同样要算。管道缓冲默认 64KB如果Content-Length超过这个数父进程的write一定会阻塞这时候如果子进程还没开始读就会卡住。所以要么把 body 全量读进内存后再写简单但受内存限制要么用poll同时等可读可写。我选的是前者配合前面说的 body 上限逻辑清楚出错也好定位。3.4 收尾等待子进程与状态映射read循环结束后必须waitpid否则子进程退出后会变成僵尸越积越多最后fork失败。这里要注意用带WNOHANG的轮询还是一次性阻塞等待——因为已经读到 EOF说明子进程的输出端关了它基本已经退出或者马上退出直接阻塞等待是可以的但为了保险我还是会加一个短暂的重试。waitpid拿到的状态码要映射成 HTTP 状态正常退出且退出码为 0按 CGI 输出的状态走退出码非 0 且没有输出返回 500被信号杀死比如段错误返回 502 并记录信号编号。这个映射表看着琐碎但排障时非常有用日志里一句“CGI killed by signal 11”能省掉半天的猜测。还有一个描述符收尾的细节socketpair那一端在父进程里是同一个 fd 同时当读写用读完关闭一次就够了。但如果你用的是两条pipe就得分两个变量存关的时候一个都不能漏。我见过一个实现每次请求漏关一个 fd跑一天之后accept返回EMFILE整个服务看起来还活着但就是不响应新连接非常隐蔽。4. 动手验证把整条链路跑通4.1 编译与最小配置拿到源码之后先确认编译选项里 CGI 支持是打开的。shttpd 通常用一个宏来控制比如-DNO_CGI是关闭不定义就是开启。编译命令大概是这样make clean make CFLAGS-O2 -Wall -DNO_SSL启动时用一个最简单的配置把文档根目录和 CGI 目录指过去。配置项一般长这样document_root /var/www cgi_pattern **/*.cgi listening_ports 8080cgi_pattern是匹配规则只有路径匹配上这个模式、并且文件有执行位的才会走 CGI 分支。这个双重判断很重要光靠模式匹配不够因为模式可能被写成**/*那就把静态文件也当成脚本了。编译完先别急着测动态页面用浏览器访问一个静态文件确认服务器本身是通的。这一步能排除掉端口占用、防火墙、根目录权限这些无关干扰。4.2 写三个最小CGI程序分别验证不同路径验证要覆盖三种情况GET 带参数、POST 带 body、以及纯环境变量输出。第一个用 shell 写最简单用来确认链路通不通#!/bin/sh printf Content-Type: text/plain\n\n printf method%s\n $REQUEST_METHOD printf query%s\n $QUERY_STRING printf path%s\n $PATH_INFO env | sort注意printf的第一个参数里那个空行不能少它把头部和正文分开。用echo也可以但要小心不同 shell 对\n的处理差异printf更可控。第二个用 C 写重点测 POST body 读取。这里必须严格按照CONTENT_LENGTH读不能读到 EOF 为止#include stdio.h #include stdlib.h #include string.h int main(void) { const char *len_str getenv(CONTENT_LENGTH); long len len_str ? strtol(len_str, NULL, 10) : 0; char *body calloc(1, (size_t)len 1); if (len 0 body) fread(body, 1, (size_t)len, stdin); printf(Content-Type: application/json\n\n); printf({\len\:%ld,\body\:\%s\}\n, len, body ? body : ); free(body); return 0; }第三个故意制造异常输出时只给正文不给Content-Type看看服务器怎么兜底。这个测试能帮你确认前面说的“找不到分隔符”那条分支到底有没有实现。4.3 用命令行工具抓请求别只信浏览器浏览器缓存和自动重试会掩盖很多问题我基本都用命令行验证# GET带查询串和 PATH_INFO curl -v http://127.0.0.1:8080/cgi-bin/env.cgi/sensor/1?fmtjson # POST观察 CONTENT_LENGTH 是否正确传递 curl -v -X POST -d {id:42} \ -H Content-Type: application/json \ http://127.0.0.1:8080/cgi-bin/post.cgi # HEAD确认头部存在但正文被丢弃 curl -I http://127.0.0.1:8080/cgi-bin/env.cgi-v输出里重点看三样请求头里Content-Length有没有响应头里Content-Type和Content-Length对不对响应时间是不是明显偏长偏长说明在等超时。如果 HEAD 请求返回了正文说明丢弃逻辑没生效。还有一个我常用的土办法在 CGI 脚本里把env全量 dump 出来然后用diff对比服务器传的和你预期的差在哪。这招比看源码快得多尤其适合排查“某个头部没传过来”这类问题。4.4 参数调优的几个实测数值跑通之后可以做一轮压力观察我在这台 ARM 开发板上记录的数值供参考参数初始值调整后观察结果CGI 超时30s8s死循环脚本从占住 30 秒降到 8 秒释放输出缓冲上限无限制256KB峰值内存从 40MB 降到 12MB读缓冲大小512B4096B大页面耗时下降约 18%并发 CGI 上限不限8高负载下不再出现 fork 失败读缓冲从 512 改到 4096 这个提升是有理论依据的一个 100KB 的页面512 字节缓冲需要 200 次read系统调用4096 只需要 25 次系统调用开销占比明显下降。再往上调到 16384 提升就不明显了还会挤占内存所以 4096 是个比较甜的平衡点。5. 踩坑实录那些文档里不会写的问题5.1 空白页、转圈、500三种症状对应三类原因我把实际遇到过的问题整理成了速查表基本上按症状就能定位到方向症状最可能的原因快速验证方法页面完全空白状态 200CGI 没输出Content-Type或缺空行分隔命令行直接跑脚本看输出请求一直转圈最后超时父进程没关写端子进程阻塞在 read检查shutdown/close调用500 且日志无内容execve失败多半是没有执行位或解释器路径错手动执行脚本看报错502子进程被信号杀死查日志里的信号编号POST 拿到空 bodyCONTENT_LENGTH没传或传成 0dump 环境变量确认中文乱码响应头缺charsetutf-8看响应头跑一段时间后全部无响应僵尸进程堆积或 fd 泄漏ps看 Z 状态ls /proc/PID/fd“空白页但状态 200”是最常见的一个。很多人第一反应是脚本没执行其实脚本执行了只是输出格式不对。判据很简单用curl -v看响应头里有没有Content-Type如果服务器自己补了一个默认值说明它没从 CGI 输出里解析到。5.2 僵尸进程与描述符泄漏都是“忘了收尾”僵尸进程的成因只有一个子进程退出了父进程没waitpid。表现是ps里一堆状态为Z的条目它们不占 CPU 不占内存但占进程表项。累积到上限之后fork返回EAGAIN新请求全部失败而服务器看起来还在正常监听。排查方法很直接ps -ef | grep defunct | wc -l数字持续增长就是它。修法是在读循环结束后无条件waitpid并且在fork失败的分支里也要处理好已经打开的描述符。描述符泄漏更隐蔽。ls /proc/pid/fd | wc -l每隔十分钟看一次数字单调上升就是漏了。常见的漏点有三个fork失败时没关socketpair子进程里dup2之后没关原 fd父进程异常分支比如 body 超限提前 return 跳过了清理。第三个最坑因为在正常路径上测不出来只有压测到异常分支才暴露。我的做法是把这个函数改成单一出口所有错误分支都goto cleanup虽然不太符合某些编码规范但确实能杜绝这类问题。5.3 安全边界CGI是拿服务器权限跑任意程序这一点必须说透。CGI 的本质是“把用户可控的输入交给一个可执行程序”如果路径映射写得不严就会出现“用户能指定执行哪个文件”的问题。防护要点有三条第一只允许执行配置目录下的文件。判断方式是把真实路径做一次realpath然后检查它是否以 CGI 根目录为前缀。光比较字符串前缀不够因为/var/wwwevil也以/var/www开头必须在比较时补上目录分隔符。第二拒绝路径里的..和空字节。空字节截断是老问题%00解码后如果直接传给open后面的内容会被忽略从而绕过扩展名检查。第三CGI 进程要降权。如果服务器以 root 身份跑CGI 也是 root一个脚本漏洞就是整机沦陷。标准做法是在execve之前setgid/setuid到低权限用户。这一步必须在子进程分支里做且要在chdir之后、execve之前顺序错了会因为没有权限切目录而失败。还有一点容易被忽略环境变量里的头部值要过滤换行。如果某个请求头的值里带了\n拼进环境变量后虽然不会直接造成命令执行但可能污染子进程的解析逻辑。稳妥做法是把\r和\n直接替换成空格。6. 改造过程中的几点个人体会这套 CGI 实现前后我改了三版第一版照抄结构能跑通但一压就挂第二版加了超时和上限稳住了但代码变得很散第三版才把错误分支统一收口、把描述符生命周期画清楚。回头看最值得分享的经验不是某个函数怎么写而是先把状态机画在纸上父进程有“等 body 写完”“等输出读完”“等子进程退出”三个状态子进程有“读 body”“干活”“写输出”三个状态两边一旦有一端提前退出另一端必须有对应的退出条件。这张图画清楚了代码怎么写都不会死锁画不清楚加多少超时都是碰运气。另外一个小技巧调试 CGI 时把子进程的 stderr 也重定向到同一个通道虽然会污染响应正文但排查阶段非常值——脚本里的语法错误、找不到文件、权限拒绝全都会直接显示在浏览器里。等调通了再把它改回独立处理或者写日志。我甚至专门留了一个编译开关线上出问题时临时打开比翻日志快得多。最后提一句扩展方向。这套结构再往前走一步就是 FastCGI把“每次 fork”换成“常驻进程池 套接字通信”协议复杂一些但省掉了进程创建开销适合请求量再上一个量级的场景。不过对于设备管理页面这种一天几千次请求的负载现在的实现已经完全够用没必要为了架构好看去背额外的复杂度。工具的价值在于解决问题不在于它有多先进。
做嵌入式Web服务器这行的人多多少少都碰过这样的需求设备上跑着一个几十KB的HTTP服务页面是静态的但偶尔要读一次传感器、查一次配置、点一下重启静态文件就不够用了。这时候要么塞一个模板引擎进去要么把请求交给外部程序处理——后者就是CGI。我最近把shttpd这个以精简著称的Web服务器源码里CGI支持那部分翻了个底朝天越看越觉得这套设计值得单独拎出来讲它没有引入任何第三方库靠一对管道加一次fork/exec就把动态请求打通了代码量小到可以一晚上读完却把 CGI 规范里最容易被忽略的几个坑都绕开了。这篇东西写给两类人一类是想给自己的小服务器加动态能力、又不想背一个框架的同学另一类是已经在用 shttpd、但一遇到空白页和挂死就抓瞎的运维和嵌入式开发。我会把整体设计、环境变量拼装、管道收发、超时控制、以及我踩过的那些坑按源码顺序一层层拆开讲代码都是可编译可复现的。1. 先想清楚迷你Web服务器为什么要接CGI1.1 CGI的本质是一次“进程级函数调用”很多人第一次看 CGI 规范会觉得它很土每次请求都fork一个新进程跑完就退出开销大得离谱。但把它放到嵌入式设备、内部工具、单机管理后台这些场景里土办法反而是最稳的办法。我习惯用这样一个类比来解释静态文件服务像是餐厅里的自助餐台菜是提前摆好的客人来了直接取CGI 像是后厨现做客人点单HTTP 请求服务员把点单小票环境变量和标准输入递进后厨窗口厨师外部程序做好菜标准输出再递出来。窗口只有两个一个递进去一个递出来双方不需要认识对方只需要约定好小票上写什么、菜怎么摆盘。这个“约定”就是 CGI 规范。所以 CGI 的核心从来不是某个函数而是三件事怎么把请求信息交给子进程环境变量 stdin、怎么把子进程的结果收回来stdout、怎么保证双方都不会卡死管道读写顺序与超时。shttpd 的 CGI 实现本质上就是围绕这三点写的加起来几百行但每一行都在解决具体问题。1.2 为什么不内嵌解释器而选择外部进程做完选型对比之后我对 shttpd 这个决定是认可的。当时摆在面前的路大概有三条我把当时的权衡整理成了下面这张表方案实现成本内存占用隔离性崩溃影响适合场景内嵌脚本引擎高要引入解释器大常驻几十到几百KB差同一地址空间整个服务挂掉逻辑复杂、请求频繁服务端包含SSI低极小无隔离无只做变量替换的页面CGI 外部进程低一次forkexec按需跑完即释放好独立进程只影响单次请求低频、异构语言、需要调用系统命令第三条路的最大好处是语言无关。设备上要读一个串口用 C 写个小程序要生成一份报表用脚本语言十行搞定要调用厂商提供的二进制工具直接exec就行。服务器本身完全不需要知道对面是什么它只认标准输入输出。这种解耦在资源受限、又需要快速堆功能的场景里价值远大于那点进程创建开销。代价也很明确每次请求一次进程创建在 ARM 平台上大概几百微秒到几毫秒并发一高就会顶到进程数上限。所以 shttpd 这类服务器的定位从来不可能是高并发网关它服务的是“一天几千次请求”的管理界面。想清楚这个边界后面的所有设计取舍就都顺了。1.3 CGI在shttpd整体结构中的位置shttpd 的请求处理是一条很直的流水线监听套接字 → 接受连接 → 解析请求行和头部 → 按 URI 找处理函数 → 生成响应 → 关闭连接。它内部维护了一张“URI 前缀 → 处理函数”的表静态文件、目录列表、认证、代理各占一项CGI 也是其中之一只不过它的匹配规则不是固定前缀而是“这个路径对应的文件是否可执行”。这个设计带来的一个直接后果是CGI 处理函数拿到的已经是解析完毕的请求结构体方法、URI、查询串、头部、body 长度都在里面它不需要再做一次 HTTP 解析。这一点很关键因为这意味着 CGI 模块的职责被压缩得非常纯粹——只做“翻译”把结构体翻译成环境变量把 body 翻译成管道字节把管道字节翻译回 HTTP 响应。我在改造时特意保留了这层边界不让 CGI 模块去碰套接字读写。原因很简单一旦 CGI 代码直接往客户端套接字写数据超时控制、连接复用、错误响应就没法统一处理了最后会变成一堆特判。保持“CGI 产出的是内存里的一个响应缓冲区”后面无论是加 gzip 还是加日志都好做。2. 一次CGI请求的完整生命周期拆解2.1 从URL到可执行文件路径映射的三个坑请求进来是/cgi-bin/status.cgi/sensor/1?fmtjson服务器要做的第一件事是把它变成一个真实文件路径。这里有三段信息必须被正确切开脚本路径/cgi-bin/status.cgi路径附加信息PATH_INFO/sensor/1查询串QUERY_STRINGfmtjson很多人写这步的时候直接strchr(uri, ?)一刀切然后把前半段当文件名去stat结果就是/cgi-bin/status.cgi/sensor/1这个路径stat失败返回 404。正确做法是从右往左逐段回退直到找到一个真实存在且可执行的文件剩下的部分才是 PATH_INFO。shttpd 里这段逻辑是按目录逐级判断的先把 URI 里?后面的部分截出来存进查询串然后从完整路径开始每次去掉最后一段再试直到命中。这个“逐段回退”的写法看着笨但它顺带解决了另一个问题——目录遍历防护。因为每一段都会检查是否含有..回退过程中任何一段不合法就直接拒绝不需要额外写一个专门的路径规范化函数。这里有个我踩过的坑值得单独说PATH_INFO里的内容必须做 URL 解码但查询串不能提前解码。因为 CGI 规范规定查询串以原始形式传给子进程由子进程自己决定怎么解。如果你在服务器里先解了一遍子进程里的%26就变成了参数会被错误地切开。我在一个配置页面上被这个坑咬了很久表现是“密码里带特殊字符就登录失败”查了两天才定位到是双重解码。还有权限判断。stat拿到st_mode之后判断“是不是普通文件”和“有没有执行位”用的是两个不同的宏S_ISREG和S_IXUSR。少了前者一个可执行的目录也会被当成脚本去exec然后exec失败返回一个莫名其妙的空响应少了后者会试图执行一个普通文本文件报EACCES。两个都要判。2.2 环境变量的拼装字段、顺序与内存布局CGI 规范里定义了十几个必须传的环境变量shttpd 的实现思路是先算总长度一次性malloc一块连续内存然后往里面逐条snprintf。这个做法比“申请一个字符串数组逐条 strdup”省事也避免了后面释放时漏掉某一条。必须传的字段我按重要性排了一下变量名来源不传会怎样REQUEST_METHOD请求行几乎所有框架直接报错QUERY_STRINGURI 中?之后GET 参数全部丢失CONTENT_LENGTH头部 Content-LengthPOST body 读不到子进程阻塞在 readCONTENT_TYPE头部 Content-Type表单解析失败SCRIPT_NAMEURI 中脚本部分生成自链接时错乱SCRIPT_FILENAME磁盘真实路径部分框架靠它定位自身PATH_INFOURI 剩余部分路由式 CGI 无法工作SERVER_PROTOCOL请求行少数库依赖REMOTE_ADDR对端地址日志里看不到来源GATEWAY_INTERFACE固定值CGI/1.1老框架会拒绝服务最容易被漏掉的是CONTENT_LENGTH。它不是“可选优化”而是子进程判断“该不该读 stdin、读多少”的唯一依据。标准输入是管道不是文件没有 EOF 可等——父进程不关写端子进程的read就一直阻塞。这就是很多“POST 请求永远转圈”问题的根因。另一个细节是HTTP 头部的转换规则所有请求头都要变成HTTP_前缀名字转大写-换成_。比如User-Agent变成HTTP_USER_AGENTX-Forwarded-For变成HTTP_X_FORWARDED_FOR。转换时要注意头部名字里可能出现的下划线本身虽然规范不建议但现实里确实有客户端发X_Custom转换后会和X-Custom撞车。shttpd 的做法是不做额外处理直接替换这个取舍我认为是合理的——加转义规则反而会让通用 CGI 程序认不出来。内存布局上还有个隐蔽问题环境变量块必须以两个连续的\0结尾。手写的时候如果只补一个execve会一路读越界表现是子进程环境里出现一堆乱码变量或者干脆段错误。我在第一次手写这块时就栽在这后来养成习惯申请时len 1最后显式buf[pos] \0; buf[pos1] \0;并且断言pos 2 len。2.3 请求体如何穿过管道进入子进程GET 请求没有 body这部分可以跳过POST 和 PUT 就绕不开了。shttpd 在类 Unix 系统上用socketpair造一对双向描述符一个给子进程当 stdin/stdout一个留在父进程手里。用socketpair而不是两个单向pipe好处是只需要管理一对描述符且支持全双工某些 CGI 程序会在读取 body 的同时往 stderr 写日志双向通道能少一次死锁风险。写 body 的顺序有讲究。标准做法是父进程fork之后在父进程侧先把 body 全部写进管道再关闭写端然后才去读子进程的输出。如果反过来先读输出而 body 又比较大超过管道缓冲区Linux 上默认 64KB子进程在写 stdout 时会被阻塞父进程在等 stdout 数据双方互等死锁。不过“先写完再读”也有它的问题如果 CGI 程序是流式输出的比如一边处理一边打印进度它可能在读完 body 之前就开始写输出这时候如果 body 特别大父进程写管道会被阻塞。稳妥的解法是把父进程侧的两个描述符都设成非阻塞用select或poll同时监听“可写”和“可读”谁就绪处理谁。shttpd 这种追求代码量的实现通常走的是简单路线——先写后读同时给 body 设一个上限比如几百 KB超过就直接 413。这个取舍在小工具场景里完全够用但如果你要传文件上传就必须改成事件驱动。顺带说一句HEAD 请求也要执行 CGI但输出要丢弃。有些实现图省事HEAD 直接返回 200 不跑脚本结果Content-Length和 GET 对不上前端做预检时就会出问题。正确的做法是照常跑把读到的数据丢掉只保留头部Content-Length用实际读到的字节数填。2.4 子进程的输出怎么被解析成HTTP响应CGI 程序输出的不是完整 HTTP 响应而是“头部 空行 正文”。头部里最关键的是Content-Type如果缺了它服务器就不知道该给客户端什么类型浏览器表现就是下载文件或者显示空白。所以解析逻辑的第一步是在输出缓冲区里找\r\n\r\n或\n\n找到之前的部分当 CGI 头之后的部分当正文。shttpd 这里做得比较务实它不逐行解析所有 CGI 头只挑几个需要特殊处理的。Status:头用来覆盖默认的 200 状态码格式是Status: 404 Not FoundLocation:头如果存在且没有Status就按 302 处理这是重定向的标准玩法。其余的头比如Set-Cookie、Cache-Control原样透传给客户端。这里有个非常容易翻车的细节CGI 输出的换行可能是\n也可能是\r\n取决于脚本语言和运行平台。如果你只匹配\r\n\r\n一个用printf手写的 C 程序输出\n\n服务器就找不到分隔符会把整个输出包括头部当成正文吐给浏览器页面上就会出现Content-Type: text/html这行字。我第一次写的时候就是这样浏览器里明晃晃地显示着自己的响应头非常滑稽。所以匹配逻辑要两种都认并且优先匹配更长的那个。还有一个边界如果 CGI 程序什么都没输出就退出了服务器必须自己造一个响应通常是 500 加一句“CGI returned no data”。这个兜底不做客户端会收到一个空的 200然后一直等到超时。3. 源码级走读关键函数与那段绕不开的代码3.1 职责划分三个函数撑起整条链路shttpd 的 CGI 部分可以粗略分成三层我在重写时基本照搬了这个划分入口层负责路径匹配、权限判断、构造环境变量块失败时直接返回错误码。执行层fork 重定向描述符 execve只做“把进程跑起来”这一件事。收发层父进程侧写 body、读输出、解析头部、等待子进程结束并回收。这样分层的好处是每一层都能单独测。比如收发层可以脱离fork用一对socketpair加一个线程来模拟调试起来快得多。我在排查一个“读不到输出”的问题时就是先把收发层单独抽出来跑五分钟就确认问题出在执行层的描述符没关干净。入口层里有个细节值得说chdir到脚本所在目录。很多 CGI 程序会用相对路径读同目录下的配置文件如果不切目录它会去服务器进程的工作目录找自然找不到。shttpd 在执行前会chdir到脚本的父目录这一步必须放在execve之前的子进程分支里否则会影响服务器本身的工作目录。3.2 fork与exec描述符关闭顺序决定成败下面这段是我按 shttpd 的结构重写的精简版把关键点都标出来了。它不是原文照抄而是为了把逻辑看清楚做的等价简化/* 返回值0 成功-1 失败 */ static int cgi_spawn(const char *prog, char *const envp[], int *to_child, int *from_child) { int sp[2]; pid_t pid; /* 用 socketpair 而不是两条 pipe方便全双工 */ if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) ! 0) return -1; pid fork(); if (pid 0) { close(sp[0]); close(sp[1]); return -1; } if (pid 0) { /* 子进程只保留一端 */ close(sp[0]); dup2(sp[1], STDIN_FILENO); dup2(sp[1], STDOUT_FILENO); /* stderr 也重定向过去否则子进程报错信息会丢 */ dup2(sp[1], STDERR_FILENO); if (sp[1] STDERR_FILENO) close(sp[1]); /* 切到脚本目录让相对路径可用 */ if (chdir(dir_of(prog)) ! 0) _exit(127); execve(prog, (char *const[]){ (char *)prog, NULL }, envp); _exit(127); /* execve 失败才会走到这里 */ } /* 父进程 */ close(sp[1]); *to_child *from_child sp[0]; return (int)pid; }几个点必须强调。第一子进程必须_exit而不是exit。exit会刷新父进程继承下来的 stdio 缓冲区可能导致响应被重复输出两遍也可能在fork之后触发一些不该触发的清理逻辑。第二execve失败后一定要_exit(127)绝不能让子进程继续往下跑否则它会回到服务器的accept循环里变成两个进程抢同一个监听套接字症状是请求随机丢一半极难排查。第三dup2之后要把原描述符关掉否则子进程会多持有一个引用父进程读输出时就永远等不到 EOF。3.3 读写循环里的超时与背压父进程侧的核心是一个循环先把 body 写完如果有然后shutdown写端再循环read直到返回 0 或者遇到错误。这里的“返回 0”就是子进程关闭了输出端等价于 EOF。超时必须自己管。shttpd 用的是select加一个超时值每次循环前算一下剩余时间。如果不做超时一个死循环的 CGI 脚本能把工作进程永久占住多来几次整个服务器就没法响应了。默认值我一般设 5 到 10 秒——管理类脚本通常足够太短会误杀慢查询。缓冲区的选择也有讲究。读缓冲我一般用 2048 或 4096 字节理由是太小会导致系统调用次数上升太大在嵌入式环境里浪费栈或者堆。如果输出要整体拼在内存里shttpd 的做法是把输出攒成一个连续缓冲区再统一发送那就得同时设一个总量上限比如 1MB超过就断开并记日志防止一个cat大文件的脚本把内存吃光。计算一下最坏情况会更直观假设并发 32 个连接每个 CGI 输出上限 1MB那就是 32MB 的峰值内存。在一个 64MB 内存的设备上这已经危险了所以实际部署时我把上限压到 256KB并且把并发 CGI 数量限制在 8 个以内。这个数字不是拍脑袋来的是拿“页面最大体积 × 最大并发”倒推的超过就降级返回 503。写 body 那一侧同样要算。管道缓冲默认 64KB如果Content-Length超过这个数父进程的write一定会阻塞这时候如果子进程还没开始读就会卡住。所以要么把 body 全量读进内存后再写简单但受内存限制要么用poll同时等可读可写。我选的是前者配合前面说的 body 上限逻辑清楚出错也好定位。3.4 收尾等待子进程与状态映射read循环结束后必须waitpid否则子进程退出后会变成僵尸越积越多最后fork失败。这里要注意用带WNOHANG的轮询还是一次性阻塞等待——因为已经读到 EOF说明子进程的输出端关了它基本已经退出或者马上退出直接阻塞等待是可以的但为了保险我还是会加一个短暂的重试。waitpid拿到的状态码要映射成 HTTP 状态正常退出且退出码为 0按 CGI 输出的状态走退出码非 0 且没有输出返回 500被信号杀死比如段错误返回 502 并记录信号编号。这个映射表看着琐碎但排障时非常有用日志里一句“CGI killed by signal 11”能省掉半天的猜测。还有一个描述符收尾的细节socketpair那一端在父进程里是同一个 fd 同时当读写用读完关闭一次就够了。但如果你用的是两条pipe就得分两个变量存关的时候一个都不能漏。我见过一个实现每次请求漏关一个 fd跑一天之后accept返回EMFILE整个服务看起来还活着但就是不响应新连接非常隐蔽。4. 动手验证把整条链路跑通4.1 编译与最小配置拿到源码之后先确认编译选项里 CGI 支持是打开的。shttpd 通常用一个宏来控制比如-DNO_CGI是关闭不定义就是开启。编译命令大概是这样make clean make CFLAGS-O2 -Wall -DNO_SSL启动时用一个最简单的配置把文档根目录和 CGI 目录指过去。配置项一般长这样document_root /var/www cgi_pattern **/*.cgi listening_ports 8080cgi_pattern是匹配规则只有路径匹配上这个模式、并且文件有执行位的才会走 CGI 分支。这个双重判断很重要光靠模式匹配不够因为模式可能被写成**/*那就把静态文件也当成脚本了。编译完先别急着测动态页面用浏览器访问一个静态文件确认服务器本身是通的。这一步能排除掉端口占用、防火墙、根目录权限这些无关干扰。4.2 写三个最小CGI程序分别验证不同路径验证要覆盖三种情况GET 带参数、POST 带 body、以及纯环境变量输出。第一个用 shell 写最简单用来确认链路通不通#!/bin/sh printf Content-Type: text/plain\n\n printf method%s\n $REQUEST_METHOD printf query%s\n $QUERY_STRING printf path%s\n $PATH_INFO env | sort注意printf的第一个参数里那个空行不能少它把头部和正文分开。用echo也可以但要小心不同 shell 对\n的处理差异printf更可控。第二个用 C 写重点测 POST body 读取。这里必须严格按照CONTENT_LENGTH读不能读到 EOF 为止#include stdio.h #include stdlib.h #include string.h int main(void) { const char *len_str getenv(CONTENT_LENGTH); long len len_str ? strtol(len_str, NULL, 10) : 0; char *body calloc(1, (size_t)len 1); if (len 0 body) fread(body, 1, (size_t)len, stdin); printf(Content-Type: application/json\n\n); printf({\len\:%ld,\body\:\%s\}\n, len, body ? body : ); free(body); return 0; }第三个故意制造异常输出时只给正文不给Content-Type看看服务器怎么兜底。这个测试能帮你确认前面说的“找不到分隔符”那条分支到底有没有实现。4.3 用命令行工具抓请求别只信浏览器浏览器缓存和自动重试会掩盖很多问题我基本都用命令行验证# GET带查询串和 PATH_INFO curl -v http://127.0.0.1:8080/cgi-bin/env.cgi/sensor/1?fmtjson # POST观察 CONTENT_LENGTH 是否正确传递 curl -v -X POST -d {id:42} \ -H Content-Type: application/json \ http://127.0.0.1:8080/cgi-bin/post.cgi # HEAD确认头部存在但正文被丢弃 curl -I http://127.0.0.1:8080/cgi-bin/env.cgi-v输出里重点看三样请求头里Content-Length有没有响应头里Content-Type和Content-Length对不对响应时间是不是明显偏长偏长说明在等超时。如果 HEAD 请求返回了正文说明丢弃逻辑没生效。还有一个我常用的土办法在 CGI 脚本里把env全量 dump 出来然后用diff对比服务器传的和你预期的差在哪。这招比看源码快得多尤其适合排查“某个头部没传过来”这类问题。4.4 参数调优的几个实测数值跑通之后可以做一轮压力观察我在这台 ARM 开发板上记录的数值供参考参数初始值调整后观察结果CGI 超时30s8s死循环脚本从占住 30 秒降到 8 秒释放输出缓冲上限无限制256KB峰值内存从 40MB 降到 12MB读缓冲大小512B4096B大页面耗时下降约 18%并发 CGI 上限不限8高负载下不再出现 fork 失败读缓冲从 512 改到 4096 这个提升是有理论依据的一个 100KB 的页面512 字节缓冲需要 200 次read系统调用4096 只需要 25 次系统调用开销占比明显下降。再往上调到 16384 提升就不明显了还会挤占内存所以 4096 是个比较甜的平衡点。5. 踩坑实录那些文档里不会写的问题5.1 空白页、转圈、500三种症状对应三类原因我把实际遇到过的问题整理成了速查表基本上按症状就能定位到方向症状最可能的原因快速验证方法页面完全空白状态 200CGI 没输出Content-Type或缺空行分隔命令行直接跑脚本看输出请求一直转圈最后超时父进程没关写端子进程阻塞在 read检查shutdown/close调用500 且日志无内容execve失败多半是没有执行位或解释器路径错手动执行脚本看报错502子进程被信号杀死查日志里的信号编号POST 拿到空 bodyCONTENT_LENGTH没传或传成 0dump 环境变量确认中文乱码响应头缺charsetutf-8看响应头跑一段时间后全部无响应僵尸进程堆积或 fd 泄漏ps看 Z 状态ls /proc/PID/fd“空白页但状态 200”是最常见的一个。很多人第一反应是脚本没执行其实脚本执行了只是输出格式不对。判据很简单用curl -v看响应头里有没有Content-Type如果服务器自己补了一个默认值说明它没从 CGI 输出里解析到。5.2 僵尸进程与描述符泄漏都是“忘了收尾”僵尸进程的成因只有一个子进程退出了父进程没waitpid。表现是ps里一堆状态为Z的条目它们不占 CPU 不占内存但占进程表项。累积到上限之后fork返回EAGAIN新请求全部失败而服务器看起来还在正常监听。排查方法很直接ps -ef | grep defunct | wc -l数字持续增长就是它。修法是在读循环结束后无条件waitpid并且在fork失败的分支里也要处理好已经打开的描述符。描述符泄漏更隐蔽。ls /proc/pid/fd | wc -l每隔十分钟看一次数字单调上升就是漏了。常见的漏点有三个fork失败时没关socketpair子进程里dup2之后没关原 fd父进程异常分支比如 body 超限提前 return 跳过了清理。第三个最坑因为在正常路径上测不出来只有压测到异常分支才暴露。我的做法是把这个函数改成单一出口所有错误分支都goto cleanup虽然不太符合某些编码规范但确实能杜绝这类问题。5.3 安全边界CGI是拿服务器权限跑任意程序这一点必须说透。CGI 的本质是“把用户可控的输入交给一个可执行程序”如果路径映射写得不严就会出现“用户能指定执行哪个文件”的问题。防护要点有三条第一只允许执行配置目录下的文件。判断方式是把真实路径做一次realpath然后检查它是否以 CGI 根目录为前缀。光比较字符串前缀不够因为/var/wwwevil也以/var/www开头必须在比较时补上目录分隔符。第二拒绝路径里的..和空字节。空字节截断是老问题%00解码后如果直接传给open后面的内容会被忽略从而绕过扩展名检查。第三CGI 进程要降权。如果服务器以 root 身份跑CGI 也是 root一个脚本漏洞就是整机沦陷。标准做法是在execve之前setgid/setuid到低权限用户。这一步必须在子进程分支里做且要在chdir之后、execve之前顺序错了会因为没有权限切目录而失败。还有一点容易被忽略环境变量里的头部值要过滤换行。如果某个请求头的值里带了\n拼进环境变量后虽然不会直接造成命令执行但可能污染子进程的解析逻辑。稳妥做法是把\r和\n直接替换成空格。6. 改造过程中的几点个人体会这套 CGI 实现前后我改了三版第一版照抄结构能跑通但一压就挂第二版加了超时和上限稳住了但代码变得很散第三版才把错误分支统一收口、把描述符生命周期画清楚。回头看最值得分享的经验不是某个函数怎么写而是先把状态机画在纸上父进程有“等 body 写完”“等输出读完”“等子进程退出”三个状态子进程有“读 body”“干活”“写输出”三个状态两边一旦有一端提前退出另一端必须有对应的退出条件。这张图画清楚了代码怎么写都不会死锁画不清楚加多少超时都是碰运气。另外一个小技巧调试 CGI 时把子进程的 stderr 也重定向到同一个通道虽然会污染响应正文但排查阶段非常值——脚本里的语法错误、找不到文件、权限拒绝全都会直接显示在浏览器里。等调通了再把它改回独立处理或者写日志。我甚至专门留了一个编译开关线上出问题时临时打开比翻日志快得多。最后提一句扩展方向。这套结构再往前走一步就是 FastCGI把“每次 fork”换成“常驻进程池 套接字通信”协议复杂一些但省掉了进程创建开销适合请求量再上一个量级的场景。不过对于设备管理页面这种一天几千次请求的负载现在的实现已经完全够用没必要为了架构好看去背额外的复杂度。工具的价值在于解决问题不在于它有多先进。
