一个轻量级Httpd服务器项目总结

目录

1 相关说明

2 运行注意

3 运行效果

4 项目流程

4.1 主要代码框架图

4.2 程序流程解析图

5 主要知识点

5.1 Socket通信

5.1.1 概述

5.1.2 Socket通信

5.2 HTTP协议

5.2.1 HTTP概述

5.2.2 HTTP流程

5.3 CGI接口

5.3.1 概述

5.3.2 CGI流程

5.4 进程间通信--管道

5.4.1 管道概述

5.4.2 父子进程交互--管道

5.4.3 管道读取数据的四种的情况

5.4.4 管道特点

1 相关说明

（1）此博客并非完全原创，但此为个人学习后的心得总结。

（2）github项目链接：https://github.com/tkllcoder/Myhttpd_server.git

（3）参考链接

Tinyhttpd——搭建轻量型webserver - 望舒L - 博客园 (cnblogs.com)

TinyHTTPd开源项目总结 - Caso_卡索 - 博客园 (cnblogs.com)

Tinyhttpd精读解析 - nengm - 博客园 (cnblogs.com)

HTTP服务器的本质:tinyhttpd源码分析及拓展 - 七夜的故事 - 博客园 (cnblogs.com)

（4）借鉴如有不妥之处，望大佬谅解，谢谢。

2 运行注意

我的项目运行环境：Linux-CentOS7, gcc, perl-cgi.

（1）需要本机安装perl，同时安装perl-cgi，sudo yum install perl-CGI.

（2）需要修改htdocs文件夹下的.cgi代码首行路径为本机perl所在路径。在Linux终端可用指令which perl查看本机perl的路径。

（3）index.html必须没有执行权限，否则看不到内容，并且会产生Program received signal SIGPIPE, Broken pipe，因为程序中如果有可执行权限会当cgi脚本处理。所以假如html有执行权限先把它去除了，chmod 600 index.html ，此外，color.cgi、check.cgi必须要有执行权限。

3 运行效果

 

 

 

4 项目流程

4.1 主要代码框架图

int startup(int* port);//服务器端套接字初始化，socket通信流程

void accept_request(void *arg);//创建线程函数处理客户端请求，HTTP协议，
void serve_file(int client, const char *filename);//GET请求执行。

void execute_cgi(int client, const char *path, const char *method, const char *query_string);//POST请求通过 执行 CGI 管道父子进程

4.2 程序流程解析图

5 主要知识点

TinyHTTPd 虽是迷你 Web 服务器程序，代码简短，但完整涉及到 HTTP、TCP（socket）、CGI等基本协议，先来看一下这三者对于Web服务的作用。

Web客户端与服务器之间通过HTTP协议交互，传输层使用TCP协议来进行可靠性传输。

5.1 Socket通信

5.1.1 概述

我知道IP协议对应于网络层，TCP协议对应于传输层，而HTTP协议对应于应用层。

TCP/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP协议（超文本传输协议）是应用层协议，主要解决如何包装、解析数据。

Socket：socket实际上是对TCP/IP协议的封装，它的出现只是使得程序员更方便地使用TCP/IP协议栈而已。socket本身并不是协议，它是应用层与TCP/IP协议族通信的中间软件抽象层，是一组调用接口（TCP/IP网络的API函数）

5.1.2 Socket通信

Socket通信流程图如下：

简单描述一下Socket的通信流程：

（1）服务端这边首先创建一个Socket（Socket()），然后绑定IP地址和端口号（Bind()），之后注册监听（Listen()），这样服务端就可以监听指定的Socket地址了；

（2）客户端这边也创建一个Socket（Socket()）并打开，然后根据服务器IP地址和端口号向服务器Socket发送连接请求（Connect()）；

（3）服务器Socket监听到客户端Socket发来的连接请求之后，被动打开，并调用Accept()函数接收请求，这样客户端和服务器之间的连接就建立好了；

（4）成功建立连接之后就可以你侬我侬了，客户端和服务器进行数据交互（Receive()、Send()）；

（5）在腻歪完之后，各自关闭连接（Close()），交互结束；

5.2 HTTP协议

计算机网络五层结构

计算机网络五层结构是指应用层、传输层、网络层、数据链路层、物理层。OSI参考模型是最早的网络结构模型，目前多见于教科书中，实际使用更多的是五层结构模型。

1、应用层

应用层是网络结构中的最高层，在互联网中，我们最先接触的就是各种应用程序，如web，app等等，它们就是处于网络最高层的存在，所以应用层的实体就是这些应用程序。

应用层的协议包括http，ftp，smtp，pop等，这些协议规定了应用程序接收的数据格式，应用程序能够根据规定的数据格式将数据解析后呈现到页面（数据的包装与解析）上，供用户观看。

2、传输层

在操作系统中，每一个应用程序都有一个端口号，用于对外界发送或者接收数据。

那么应用程序如何将数据从自己的端口发送到另一个应用程序的端口呢？这里就需要传输层了。

传输层就是要解决端到端的传输问题，比如对方的主机地址是多少、端口号是多少、对方是否是否在线并处于可传输数据的状态、什么时候传输完成、怎么知道传输成功没有等等，这些都是传输层要解决的问题。而传输层协议就能解决这些问题，它规定了到达端口时数据的格式（无论是应用程序给到端口的数据，还是从外界传输到端口的数据），这里的数据在应用层数据的基础上添加了一些新的数据，这些新的数据就包含了主机地址、端口号、传输是否成功等信息。

简而言之，传输层是为了解决不同主机间应用程序（进程）传输数据的问题。

我们常见的传输层协议就是TCP、UDP两种，其中TCP可提供安全可靠的数据传输，能保证数据完整到达目的地，而UDP不能，可能会出现数据丢失的情况。

3、网络层

数据在传输层封装好后，怎么送到达目的地呢？我（数据包）从端口出发，走出主机后就一条路，就是主机连接路由器的那条路，那到达路由器后，我该怎么走呢？

众所周知，互联网中两台主机间的路径有无数条，怎么选择合适的路径将数据送到目的地？这就是网络层要解决的问题，而解决这个问题的实体就是路由器。

路由器把数据包里面的目的主机地址读取拿出来，根据网络层协议进行路由选择，决定要往哪个方向传输。

所以，网络层IP协议就是规定了怎么进行传输路径选择的。

4、数据链路层

路由器选择好了路径，数据信号沿着路径传输出去，可是，路途过于遥远，在路上信号衰减怎么办？路上有信号干扰怎么办？数据信号到达目的地主机还能不能解析成完整的数据？这就要靠数据链路层了。

应用数据链路层的实体有交换机、集线器、中继器等，目的是为了将路径上传输的信号无差错的传输到目的地，信号衰减了就给它增强，信号出差错了就给它回复，这些操作都根据数据链路层协议来完成。

所以，数据链路层协议就是规定了如何检测信号是否有差错、如何修复信号、增强信号等，以确保信号可以完好的到达目的地。

5、物理层

数据传输最终都要转化成比特流，在物理介质上传输，如双绞线、同轴电缆、光纤、无线电波等；

物理层指的就是这些物理传输介质，物理层协议规定了这些介质的规格，如双绞线的接口应做成什么样，无线电的载波频率应该是多少等等。简而言之，物理层就是传输比特流的物理介质。

值得注意的是，计算机网络虽然分为五层结构，但每一层可能用到的协议不止一种，应用层可能需要五种都用到，而数据链路层可能只需要用到数据链路层和物理层协议。每层结构采用需要的协议，完成每一层的责任，五层共同协作，构建了一个数据稳定可靠传输的互联网。

5.2.1 HTTP概述

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。

HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（规定数据标准），利用TCP协议作为其传输层协议。

通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

5.2.2 HTTP流程

（1）请求--响应过程

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是 HTTP 请求/响应的步骤：

1. 客户端连接到Web服务器 一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接（Socket）。

2. 发送HTTP请求 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3. 服务器接受请求并返回HTTP响应 Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4. 释放连接TCP连接 若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5. 客户端浏览器解析HTML内容 客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址; 
2. 解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接; 
3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器; 
4. 服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器; 
5. 释放 TCP连接; 
6. 浏览器将该 html 文本并显示内容;

（2）HTTP特点

• HTTP协议是基于TCP/IP协议之上的应用层协议。

• 是基于请求-响应的模式，即肯定是先从客户端开始建立通信的,服务器端在没有 接收到请求之前不会发送响应。

• 无状态保存，HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管理状态了。

• 无连接，早期的http协议是一个请求一个响应之后，直接就断开了，但是现在的http协议1.1版本不是直接就断开了，而是等几秒钟。

（3）HTTP请求方法

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求，主要用于测试或诊断。

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

（4）HTTP状态码

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

1xx消息——请求已被服务器接收，继续处理 2xx成功——请求已成功被服务器接收、理解、并接受 3xx重定向——需要后续操作才能完成这一请求 4xx请求错误——请求含有词法错误或者无法被执行 5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，“404 Not Found”，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

（5）HTTP请求格式

　　　

URL包含：/index/index2?a=1&b=2；路径和参数都在这里。

请求头里面的内容举个例子：这个length表示请求体里面的数据长度，其他的请求头里面的这些键值对，陆续我们会讲的，大概知道一下就可以了，其中有一个user-agent，算是需要你记住的吧，就是告诉你的服务端，我是用什么给你发送的请求。

以京东为例，看一下user-agent

看一个爬虫的例子，爬京东的时候没问题，但是爬抽屉的时候必须带着user-agent，因为抽屉对user-agent做了判断，来判断你是不是一个正常的请求，算是反扒机制的一种。

打开我们保存的demo.html文件，然后通过浏览器打开看看就能看到页面效果。

写上面这些内容的意思是让你知道有这么个请求头的存在，有些是有意义的，请求头我们还可以自己定义，就在requests模块里面那个headers={}，这个字典里面加就行。

（6）HTTP响应格式

　　

（7）url统一资源定位符

超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：

http://www.luffycity.com:80/news/index.html?id=250&page=1

• 传送协议。 层级URL标记符号(为[//],固定不变) 访问资源需要的凭证信息（可省略）http://

• 服务器。（通常为域名，有时为IP地址）www.luffycity.com

• 端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略） 路径。（以“/”字符区别路径中的每一个目录名称）

• 查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）

• 片段。以“#”字符为起点

以http://www.luffycity.com:80/news/index.html?id=250&page=1 为例, 其中：

http，是协议； www.luffycity.com，是服务器； 80，是服务器上的默认网络端口号，默认不显示； /news/index.html，是路径（URI：直接定位到对应的资源）； ?id=250&page=1，是查询。 大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。

5.3 CGI接口

5.3.1 概述

早期的Web服务器，只能响应浏览器发来的HTTP静态资源的请求，并将存储在服务器中的静态资源返回给浏览器。随着Web技术的发展，逐渐出现了动态技术，但是Web服务器并不能够直接运行动态脚本，为了解决Web服务器与外部应用程序（CGI程序）之间数据互通，于是出现了CGI（Common Gateway Interface）通用网关接口。简单理解，可以认为CGI是Web服务器和运行其上的应用程序进行“交流”的一种约定。通常所说的CGI指代其实是CGI程序，也就是实现了CGI接口标准的程序。

5.3.2 CGI流程

（1）CGI是Web服务器和一个独立的进程之间的协议，它会把HTTP请求Request的Header头设置成进程的环境变量，HTTP请求的Body正文设置成进程的标准输入，进程的标准输出设置为HTTP响应Response，包含Header头和Body正文。

（2）CGI程序通过标准输入（STDIN）和标准输出（STDOUT）进行数据的输入输出，此外CGI程序还通过环境变量来得到输入，操作系统提供了许多环境变量，它们定义了程序的执行环境，应用程序可以存取它们。Web服务器和CGI接口又另外设置了一些环境变量，用来向CGI程序传递一些重要的参数。CGI的GET方法还通过环境变量QUERY_STRING向CGI程序传递Form表单中的数据。

（3）对于一个CGI程序，主要的工作是从环境变量和标准输入中读取数据，然后处理数据，最后向标准输出中输出数据。

• 环境变量 环境变量中存储的叫做Request Meta-Variables，也就是诸如QUERY_STRING、PATH_INFO之类的，这些都是由Web服务器通过环境变量传递给CGI程序的，CGI程序也是从环境变量中读取的。

• 标准输入 中存放的往往是用户通过PUTS或POST提交的数据，这些数据也是由Web服务器传递过来的。

为了处理动态请求，Web服务器会根据请求的内容，Fork创建一个新进程来运行外部C程序或Perl脚本等，这个进程会把处理完的数据返回给Web服务器，然后Web服务器把内容发送给用户，Fork创建出来的进程也会随之退出。如果下次用户请求为动态脚本，那么Web服务器会再次Fork创建一个新进程，如此周而复始的运行。

5.4 进程间通信--管道

每个进程各自有不同的用户地址空间,任何一个进程的全局变量在另一个进程中都看不到，所以进程之间要交换数据必须通过内核,在内核中开辟一块缓冲区,进程A把数据从用户空间拷到内核缓冲区,进程B再从内核缓冲区把数据读走,内核提供的这种机制称为进程间通信。

不同进程间的通信本质：进程之间可以看到一份公共资源；而提供这份资源的形式或者提供者不同，造成了通信方式不同，而 管道pipe就是提供这份公共资源的形式的一种。除了管道，还有信号量、消息队列、共享内存等方式进行进程间通信。

5.4.1 管道概述

管道是由调用pipe()函数来创建

#include<unistd.h>
int pipe(int fd[2]);
//成功返回0，出错返回-1
//fd参数包含两个文件描述符，f[0]指向管道的读端，
//f[1]指向管道的写端，且f[1]的输出是f[0]的输入

5.4.2 父子进程交互--管道

（1）父进程创建管道，得到两个⽂件描述符指向管道的两端

（2）父进程fork出子进程，⼦进程也有两个⽂件描述符指向同⼀管道。

（3）父进程关闭fd[0],子进程关闭fd[1]，即⽗进程关闭管道读端,⼦进程关闭管道写端（因为管道只支持单向通信）。父进程可以往管道⾥写,子进程可以从管道⾥读,管道是⽤环形队列实现的,数据从写端流⼊从读端流出,这样就实现了进程间通信。

项目的父子进程通信流程

 创建进程则有一个读端0和一个写端1，注意创建管道时分辨清楚。

#include<unistd.h>

pid_t fork(void);

//fork调用一次，返回两次。在父进程返回一次，返回子进程的进程ID号；
//在子进程返回一次，值为0；出错返回-1。

注意：fork之后管道都复制了一份，因此需要关闭无用端口，避免浪费。

程序的父子进程间通信--管道示意图如下：

5.4.3 管道读取数据的四种的情况

（1）读端不读，写端一直写

（2）写端不写，但是读端一直读

（3）读端一直读，且fd[0]保持打开，而写端写了一部分数据不写了，并且关闭fd[1]。

如果一个管道读端一直在读数据，而管道写端的引⽤计数⼤于0决定管道是否会堵塞，引用计数大于0，只读不写会导致管道堵塞。

（4）读端读了一部分数据，不读了且关闭fd[0]，写端一直在写且f[1]还保持打开状态。

5.4.4 管道特点

1.管道只允许具有血缘关系的进程间通信，如父子进程间的通信。
​
2.管道只允许单向通信。
​
3.管道内部保证同步机制，从而保证访问数据的一致性。
​
4.面向字节流
​
5.管道随进程，进程在管道在，进程消失管道对应的端口也关闭，两个进程都消失管道也消失。

管道容量大小 测试管道容量大小只需要将写端一直写，读端不读且不关闭fd[0],即可。

可以看到写到65520之后管道堵塞了，而65536即为64K大小即为管道的容量（由于代码问题，少统计一次数据）。