定义

所谓“嵌入式HTTP服务器”包含这么几个意思：

（1）TA首先是微型的，不能太庞大。往往成为其他应用程序的一个组成部分，提供HTTP接口（包括RESTful接口）或者HTTP服务（例如WWW服务）。

（2）功能有欠缺，不是全功能服务器。比如，肯定不能像Apache、Nginx这样提供全面的HTTP支持。只能提供一个最小化的、需要定制化的功能集。

现状

在miniSIPServer中，我们以前采用mongoose这个轻量级http服务器来提供web接口。mongoose基本符合要求，但也很难让人感觉满意。主要存在以下一些问题：

（1）代码凌乱。是的，这个问题比较严重。实际上我们花了不少时间来清理TA的代码，但是效果不太好。TA的实现方式有不少问题，各逻辑层次之间解耦不充分，因此在编写应用层代码（尤其是ajax接口代码）时，不得不大量重复使用一些要求的宏定义，造成代码繁杂紊乱。

（2）定位不清晰。如果单纯定位为嵌入式服务器，可能mongoose的发展会好很多。但是我们看到，ta的代码之所以凌乱，有一个重要原因就在于：试图成为一个全功能集的http服务器。大量功能集堆积在一起，又没有处理好模块关系，结果就和意大利面一样绞成一团。

（3）原维护者似乎已经放弃这个产品。从代码库看，更新不是很频繁，缺乏关注。后续一些问题看不到解决的希望。在具体实现时，不得不小心翼翼地规避一些问题。

（4）IPv6支持不足，尤其不能适应IPv4和IPv6混合组网的情况。

新版的miniSIPServer设计中彻底抛开mongoose代码，重新实现自己的嵌入式HTTP服务。从效果看很不错：不考虑服务器自身的代码，仅仅看应用层的代码，就从原来近7K行，直接砍到了3K行。

新设计

当然，设计一个Apache或者Nginx是很复杂而且艰难的事，但设计一个嵌入式HTTP服务器的确很容易。简单来讲只有以下几个步骤而已：（1）打开TCP端口；（2）接受客户端连接；（3）收客户端的HTTP请求；（4）返回HTTP响应消息；（5）关闭TCP连接。

TCP网络编程是通用的，windows平台可以用IOCP，linux平台可以用epoll等。MSS作为SIP服务器，早就封装好了底层的通信库，因此仅仅需要关注步骤（3）和（4），读一读HTTP协议，根据HTTP的要求进行相应处理即可。

HTTP协议

最新的HTTP协议已经定义到HTTP/2.0，但现网大部分都还是HTTP/1.1，另外考虑到2.0主要是在SPDY以及加密等方面的修改，而这些对嵌入式HTTP设计而言不是很必要的，因此支持HTTP/1.1就好。

原HTTP协议定义在RFC2616，目前已经修改为多个RFC文档共同定义：RFC7230~RFC7235。实际上我们只需要关注前三个RFC文档：

• RFC7230 “Message Syntax and Routing”。这是最基础的协议。定义了HTTP的基本交互模式，基本消息结构等。
• RFC7231 “Semantics and Content”，定义了HTTP消息语法，包括RequestLine以及各Header等定义。SIP的语法就是基于这类定义。
• RFC7232 “Conditional Requests”。主要是考虑一些有条件的请求及响应。最普遍的就是重复请求网页时，可以判断是否需要每次都返回内容，也可以要求客户端直接使用cache内容，节省网络流量，节约处理能力。

HTTP请求

与SIP的startLine是完全一致的，由method、requestTarget以及HTTP协议号三部分组成。method有多种，例如GET、POST、PUT、DELETE等。我们仅仅支持GET即可。

在请求消息的各项Header（头域）中，我们仅关心以下两个Header：

• “Cookie”头域。用来传递Cookie参数。在web管理系统中，我们需要设置cookie确保用户登录系统后能继续使用各项管理界面。而没有cookie或者设置不正确的用户，将被视为非法用户。
• “If-Modified-Since”头域。这是个非常有必要的域。一旦服务器发现客户端请求的内容没有变更，可以直接返回304响应，要求客户端直接用以前的结果就好。

HTTP响应

响应消息和SIP一样，也是定义1xx～6xx。实际设计中我们仅需要关心1xx、2xx、3xx以及4xx即可。响应消息没什么好说的，无非就是各种ContentType等，读取文件，通过TCP连接发给客户端即可。

与SIP比较而言，HTTP最大的特点是无状态。一个“请求-响应”即构成了一个完整的HTTP动作过程。因此HTTP可以利用LVS、HAProxy等技术支持大规模并发。而SIP受限于对话状态，多个“请求-响应”之间是可以关联的（例如INVITE和reINVITE），只能通过ALG、Proxy等呼叫分发来支持大规模的应用。

HTTP路由

具体内部实现时，采用action模式，根据HTTP请求的URL进行索引，用URL对应action即可。服务器本身可以设置一些过滤接口，也可以向应用层提供action接口，由应用层决定各URL对应的处理过程。这点在处理AJAX请求或者提供RESTful接口时尤其有用。

其他

我们的设计目前只支持HTTP。对于HTTPS，理论上而言也不是很困难，无非就是加载CA文件，在TCP建立时进行TLS/SSL鉴权，后续处理与HTTP没有差别。

另外就是安全防护问题，例如防DDOS攻击等，我们没有考虑这方面。虽然应用层可以利用过滤接口或者action接口进行一定程度的防护，但主要的保护依赖于边界网关，毕竟嵌入式HTTP服务器只是用来方便设备管理和配置，不是提供通用HTTP服务的。