简介Tiny-WebServer-master是一款用纯C语言实现的轻量级Web服务器项目面向学习HTTP协议、socket编程以及服务器架构的开发者、计算机专业学生和求职者。资源压缩包共13个文件其中tiny.c、csapp.c等C源码承担服务器主体与基础工具库Makefile用于一键构建配套头文件声明接口home.html与faye.jpg方便本地模拟静态资源请求cgi-bin下的adder示例演示动态处理README则给出使用指引整个包仅103KB无冗余依赖。项目基于经典CSAPP课程框架代码按网络连接、请求解析、资源定位、响应构造、错误处理等模块展开由浅入深地展示了一次HTTP请求从进入端口到返回页面的完整链路。目前已有786人学习下载适合课程设计、面试复习或在此基础上扩展HTTPS、并发模型等功能。初学者可从主循环入手逐行跟踪accept、read、parse与write快速建立服务器知识图景有经验的开发者则能参考其精炼结构优化自身网络工具。这份小巧的源码将网络编程理论与工程实践紧密结合是高效提升底层功底的优质素材。 做Tiny-WebServer这个项目的时候我开始以为只是个练手的小玩具不就监听个端口、回个HTTP响应吗写完之后才发现一个“能用”的HTTP服务和“能扛住一点压力”的HTTP服务之间隔着好几层窗户纸。这篇东西不是源码逐行讲解更像是我把这个项目从骨架到填肉、再到踩坑修复的一整套记录适合刚学完C语言和Socket编程、想拿一个完整小项目练手的朋友。如果你是那种喜欢拿着代码一点点抠的人这篇东西同样能帮你少走不少弯路。1. 整体设计与思路拆解1.1 为什么选C语言写一个Web服务器现在的Web服务器领域Nginx、Apache这些老大哥早就把市场占完了随便写一个玩具服务器性能肯定比不上它们那为什么还要用C语言自己写说白了这是学网络编程和系统编程成本最低的一条路。C语言写服务器你面对的是最底层的系统调用socket、bind、listen、accept、read、write每一行代码都在直接和操作系统对话。换成Python、Java很多细节被语言运行时给你屏蔽掉了你看到的只是抽象好的Request和Response。写C你必须自己处理缓冲区、字节序、粘包半包、连接状态管理这些东西才是网络编程的真正基本功。Tiny-WebServer这类项目之所以在C语言学习圈子里长盛不衰就是因为它麻雀虽小但把HTTP服务器的主干脉络都打通了。这个项目适合谁一是刚学完C语言基础、想从“写算法题”过渡到“写工程代码”的人二是熟悉某个高级语言、想回头补底层网络知识的人。不适合谁如果你只是想快速搭个站点服务静态文件那直接装Nginx就好真的没必要自己造轮子。造轮子的意义在于理解轮子。1.2 架构选型先跑通还是先上并发动手之前有个绕不开的选择题单线程版本、多进程版本、多线程版本、还是事件驱动版本。最原始的版本只需要一个循环accept一个连接处理完请求关闭连接再回去accept。这种模型的优点是逻辑极其简单调试方便一晚上就能跑通。缺点是同一时间只能服务一个客户端如果某个客户端发来一个请求后迟迟不关闭后面的连接全部排队等着这在真实网络环境下体验非常差。Tiny-WebServer通常的进化路线是先写单线程串行版然后改成多线程版每个连接来一个线程去处理最后如果有兴趣再去研究epoll或者线程池。我这个项目最终改成了每连接一线程的版本加了一个简单的互斥锁保护全局统计数据。为什么没直接上epoll因为epoll的核心难点不在API本身而在于状态机管理对于几千行的小项目来说有点用力过猛。每连接一线程虽然在高并发下会被线程切换拖垮但作为教学项目它能把并发模型讲清楚也足够把HTTP处理逻辑练明白。2. 核心细节解析与实操要点2.1 HTTP请求解析的隐藏难点看起来解析HTTP请求不就是读取字符串然后按空格切分吗真上手做就会发现坑比想象中多得多。首先是“收不全”的问题。客户端的请求可能分好几个TCP报文到达你第一次recv到的可能只有请求行甚至只有半个请求行。如果你拿着半截数据直接去解析很大概率得到一堆乱码或者解析失败。正确姿势是先读进缓冲区然后尝试解析如果发现数据不够继续recv再拼接。这里比较实用的做法是一次性开一个足够大的缓冲区比如4096字节然后循环recv直到读到\r\n\r\n——这是HTTP头部的结束标志。但注意缓冲区大小是有限的如果请求头特别大比如某些变态的Cookie可能还没有等来结束符缓冲区就满了这时候要么返回413 Request Entity Too Large要么设计一个可扩容的缓冲区。小项目里直接定一个上限超出就报错关闭连接更省心。其次是请求行的格式。标准格式是METHOD SP URL SP VERSION\r\n比如GET /index.html HTTP/1.1\r\n。看起来用strtok或者sscanf就能拆但有一个坑URL里面可能带查询参数比如/search?keywordhello而请求的其实是/search这个东西。如果直接把整段URL拿去打开文件那search?keywordhello这个文件名是绝对不存在的。必须先按?把路径和查询串拆开。还有URL编码问题浏览器提交的路径里空格会变成%20中文会变成一堆%E4%B8%AD所以还得写一个URL解码函数把%XX还原成字符。2.2 响应的格式和头字段服务器响应的第一行叫状态行HTTP/1.1 200 OK\r\n。后面跟响应头最后跟一个空行和响应体。很多初学者在这一步最容易犯的错是忘记写状态行和头部之间的空行或者头部字段结尾少了\r\n导致浏览器要么直接白屏要么报“格式错误”。响应头里几个必须带的关键字段Content-Length响应体的字节数。没有这个字段浏览器不知道内容到哪里算完对于静态文件来说这个值就是文件大小。Content-Type告诉浏览器返回的是HTML、CSS、图片还是普通文本。这个是根据文件后缀名映射出来的所以服务器里要维护一张MIME映射表。Connection如果是close告诉浏览器响应发完就断开连接如果是keep-alive连接可以复用。小项目建议一开始就老老实实用close可以省掉一堆连接复用的麻烦。一个容易踩的坑是Content-Length的计算。如果你用一个char数组拼接响应头Content-Length的值必须在发送前就确定好所以得先拿到文件大小再组合响应头最后把文件内容发出去。顺序不能反否则你填进去的长度是错的客户端会一直卡在“加载中”。2.3 静态文件服务的路径安全这个点很容易被忽略但特别重要。当请求路径是/../etc/passwd时如果你直接用open(. 请求路径)去打开文件那服务器就把不该暴露的文件发给客户端了。这就是路径穿越漏洞。正确做法是先把请求路径规范化去掉所有..和.片段再拼接到网站根目录下。我用的方法是把URL按/切分逐段压栈遇到..就弹栈遇到.就跳过最后再把栈里的路径片段拼回去。这样即使请求里带了..最终解析出来的路径也不会跳出网站根目录。代码不多但项目里有这个处理和没有这个处理安全等级完全不一样。3. 实操过程与核心环节实现3.1 服务端骨架从socket到accept这部分是整个服务器的地基。流程非常固定很多同学在书上都看过但自己写的时候还是会漏掉一些步骤。下面是我这个项目里最核心的初始化代码片段int server_fd socket(AF_INET, SOCK_STREAM, 0); if (server_fd 0) { perror(socket); exit(EXIT_FAILURE); } int opt 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8080); if (bind(server_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); exit(EXIT_FAILURE); } if (listen(server_fd, 128) 0) { perror(listen); exit(EXIT_FAILURE); }几个细节说明一下。SO_REUSEADDR一定要加。不加的话服务器程序重启的时候如果之前的连接还处于TIME_WAIT状态bind会报Address already in use。我当时第一次遇到这个问题第一反应是端口被别的程序占了排查了半天才发现是重启太频繁导致的。加上这个选项开发体验能好一个档次。htonl(INADDR_ANY)表示监听所有网卡地址这样本机IP、127.0.0.1都能访问到。如果你写死成127.0.0.1那局域网里的其他机器就访问不到你的服务器了。accept循环通常写成这样while (1) { struct sockaddr_in client_addr; socklen_t addr_len sizeof(client_addr); int client_fd accept(server_fd, (struct sockaddr *)client_addr, addr_len); if (client_fd 0) { perror(accept); continue; } pthread_t tid; pthread_create(tid, NULL, handle_client, (void *)client_fd); pthread_detach(tid); }注意我用了pthread_detach。如果创建了线程又不分离线程结束后它的资源不会被自动回收运行一段时间后就会出现“资源不足无法创建新线程”的报错。用detach告诉系统这个线程结束之后直接清理我不需要等它。3.2 请求读取与解析流程每个连接线程里核心逻辑就是读取请求、解析请求行、解析请求头、根据方法处理、返回响应、关闭连接。我的读取方式很简单先开一个4KB的栈缓冲区然后循环recv每次把读到的那段加起来判断缓冲区里是否出现\r\n\r\n。找到后就停下开始解析。char buf[4096]; int total 0; while (total sizeof(buf) - 1) { ssize_t n recv(client_fd, buf total, sizeof(buf) - 1 - total, 0); if (n 0) { break; } total n; buf[total] \0; if (strstr(buf, \r\n\r\n)) { break; } }这里有三个注意点一是recv的第三个参数要用sizeof(buf) - 1 - total防止越界写。新手最容易犯的错误就是每次固定读sizeof(buf)结果上一次的残留数据把缓冲区撑爆了。二是strstr找\r\n\r\n只是最简方案。如果请求头正好跨了两个TCP报文第一次recv只有半个头循环继续读等到第二次recv之后再去判断逻辑上是没问题的。三是解析请求行的时候我先把缓冲区的头部复制到一个单独数组里然后用strtok_r切分。为什么不用strtok因为strtok不是线程安全的在多线程版本里两个线程同时解析请求就会互相覆盖内部状态。strtok_r是它的可重入版本多线程环境必须用这个。3.3 响应发送与静态文件读取响应发送分两段先发响应头和空行再发文件内容。我写的时候把“发送头部”和“发送文件”封装成两个函数。头部类似这样char header[512]; int header_len snprintf(header, sizeof(header), HTTP/1.1 200 OK\r\n Content-Type: %s\r\n Content-Length: %ld\r\n Connection: close\r\n \r\n, mime_type, file_size); send(client_fd, header, header_len, 0);文件发送部分有个性能问题要提前避开不要一次性把整个文件读进内存再send。图片、视频这些大文件动辄几十兆一次性读进内存既不安全也浪费。正确姿势是开一个8KB或者16KB的缓冲区循环读文件循环sendFILE *fp fopen(path, rb); char file_buf[8192]; size_t n; while ((n fread(file_buf, 1, sizeof(file_buf), fp)) 0) { size_t offset 0; while (offset n) { ssize_t sent send(client_fd, file_buf offset, n - offset, 0); if (sent 0) { break; } offset sent; } } fclose(fp);为什么要内层再套一个while因为send并不保证一次把所有数据发完它返回的是“这次实际上发送的字节数”可能小于你传入的长度。很多同学第一次写网络程序默认send一次就发完了压测的时候会发现有时候文件传输不完整其实就是没处理“部分发送”的情况。这个内层循环的作用就是保证所有数据最终都被发送出去。404页面的处理同样不能漏。文件不存在的时候也要返回标准的404状态行和错误页面不能让连接直接断掉。我返回的错误页是固定的一小段HTML内容为HTTP/1.1 404 Not Found Content-Type: text/html Content-Length: ... Connection: close htmlbodyh1404 Not Found/h1/body/html状态码必须写对。很多人会漏掉“404 Not Found”里的空格或者直接写成HTTP/1.1 404这样浏览器也能识别但不符合规范最好还是严格按照RFC格式来。3.4 压测验证能用和好用是两回事代码写完之后我用两个工具做验证一是浏览器直接访问二是用curl看响应头三是用abApacheBench做简单压测。curl -v http://127.0.0.1:8080/index.htmlcurl -v可以打印完整的请求和响应报文能看到响应头每个字段是排查格式问题最趁手的工具。比如如果Content-Length和实际发送字节数不一致curl通常会提示transfer closed with outstanding read data remaining。压测命令ab -n 1000 -c 50 http://127.0.0.1:8080/index.html表示总共1000个请求每次并发50个。跑完之后重点看两个指标Failed requests和Requests per second。我第一次跑的时候除了并行度不高之外还有不少连接被重置后来排查发现是线程创建和销毁的开销太大而且客户端主动断开时服务器还在往旧的连接上写数据触发SIGPIPE信号把整个进程干掉了。SIGPIPE这个坑很经典。当一个连接已经被客户端关闭但你还在往这个socket上write/send操作系统会向进程发送SIGPIPE信号默认行为是终止进程。解决办法有两种一是调用signal(SIGPIPE, SIG_IGN)把这个信号忽略掉让send返回-1然后自己处理错误二是send的时候加上MSG_NOSIGNAL标志。两种我都试过更推荐第二种因为它只影响当前这次send不影响全局。4. 常见问题与排查技巧实录4.1 高频报错与排查思路现象可能原因排查方法bind报Address already in use端口被占用或处于TIME_WAIT设置SO_REUSEADDR用netstat -tlnp查看端口占用curl一直转圈不返回Content-Length与实际发送字节数不一致用curl -v看响应头核对长度浏览器显示空白页响应头缺少空行或Content-Type不对用curl -v打印原始报文检查每行结尾是否有\r\n压测时Failed requests很多线程创建销毁频繁或没处理部分send给线程加detach检查send返回值访问不存在的文件时进程崩了没处理fopen返回NULL先判断文件是否存在再走404分支访问含中文或空格的路径找不到文件URL没有进行百分号解码解析时先调用url_decode服务运行一段时间后线程创建失败线程资源没回收检查pthread_join或pthread_detach是否调用4.2 调试时我踩过的一些独家坑第一个坑是缓冲区边界的处理。我的请求缓冲区是4KB但某个请求头稍微大一点就超了。等出现问题的时候我先加断言检查越界运行后马上崩了顺着报错一看原来是strstr找到了缓冲区的末尾后面却还试图读取越界访问堆栈。从那以后我写网络代码都会格外小心“缓冲区到底还剩多少字节”这个问题。第二个坑是日志打印不够多。一开始我没在关键节点打日志出问题的时候只能靠猜。后来我在accept、收到完整请求、解析完成、发送头部、发送文件这几个节点都打了带时间戳的日志排查问题的效率直线上升。比如有一次页面加载特别慢通过日志发现文件发送循环卡了很久后来定位到是本地磁盘IO慢项目本身并没有问题。第三个坑是路径拼接时忘记处理/。比如网站根目录是/var/www/html请求路径是/index.html我直接用strcat(root, path)拼接结果拼出来/var/www/html/index.html吗不对/var/www/html没有末尾斜杠拼出来变成/var/www/htmlindex.html文件自然找不到。正确做法是先判断根目录末尾有没有/或者统一用snprintf拼接。第四个坑是fopen的权限问题。如果服务器进程是以普通用户跑的而网站根目录下的某个文件权限是600或者属主是root打开就会失败。这时候不一定是你代码的问题但排查起来很容易怀疑到代码头上。所以我习惯在404分支里临时打印一下strerror(errno)能准确区分是文件不存在还是权限不足。4.3 一次Keep-Alive尝试的教训我中途试着实现过Keep-Alive就是在一个连接上循环读取多个请求减轻TCP握手的开销。想法很简单但实现起来问题很多处理完第一个请求后缓冲区里可能还残留了第二个请求的数据如果直接丢弃第二个请求就丢了如果把残留数据和下一次recv的数据拼起来又得维护一个跨循环的缓冲区状态。调试了两三天最后还是决定先去掉Keep-Alive老老实实Connection: close。这个功能对理解HTTP协议很重要但对一个教学性质的项目来说复杂度提升太多了。如果想深入学习建议单独开一个分支去折腾。最后再分享一个小技巧做完这个项目之后我有一个特别深刻的体会如果你想让这个服务器看起来更像个“正经项目”日志系统一定要做好。不需要引入什么日志库就用fprintf(stderr, [%ld] %s %s ..., time(NULL), method, path)这种格式把每个请求的访问时间、客户端IP、请求路径、响应状态码记录下来运行一段时间再看日志你会对自己写的服务器产生一种“这玩意儿还真能干活”的成就感。我后来甚至把这个日志功能扩展成了简单的访问计数用互斥锁保护一下全局变量顺便把线程同步的基本操作也练了。如果你的时间比较充裕做完基础版之后可以沿着这几个方向继续扩展支持POST请求和表单解析、支持目录浏览、用非阻塞IO加epoll重写并发模型、加一个简单的LRU缓存来缓存热门文件。每一条路由走下去都会遇到完全不同的新问题但只要你把基础版的请求解析、响应构造、文件发送这三件事做扎实了后面再怎么扩展都会顺手很多。至少对我来说这个几百行的C语言小服务器比很多花架子框架带给我的收获都要大。本文还有配套的精品资源点击获取