关于HTTP解析的一点思考

原文

似乎已经很久没有提到关于服务器的消息了，其实我一直都在写，只是有时事情比较多，会耽搁一点时间。

在使用C重写前，我就已经用Dlang实现了近2个版本的HTTP解析器，换成C之后，又换了几种思路，期间也参考现有的几种实现，可以说是有点积累，现总结成文，记录一下。

注：如下所指的HTTP均指代HTTP/1.1，不涉及HTTP/2的内容。

HTTP协议特征分析

HTTP/1.1是目前使用最为广泛的应用层协议之一，当然如今HTTP/2的标准已经出来，但是尚未普及，有些特性有待考验，我就不吃螃蟹了。。

HTTP协议是典型的Key-Value类型的文本协议，当然还有first-line和body，总体而言解析并不复杂，并且我们也不要求规整的错误提示和文法验证，因此LL(1)和LALR(1)在这里基本无用武之地。HTTP的大致格式如下：

HTTP请求：

method path version\r\n
key: value\r\n
key: value\r\n
...
key: value\r\n
\r\n
body

HTTP响应:

version status desc\r\n
key: value\r\n
key: value\r\n
...
key: value\r\n
\r\n
body

和redis的协议类似，HTTP协议中first-line和headers之间以及header与header之间均通过CRLF('\r''\n')分割，这个需要特别注意，解析的时候可能会带来一定的麻烦。我一直想不通为何不直接用LF分割，因为http-version，header-key，header-value内部并不允许出现LF，因此选择LF完全可以更加简单的解决问题，或许作者当初只用windows吧。

关于header的key和value的具体语义，才是HTTP协议的关键，内容繁杂，需要参考rfc文档，不过这个和HTTP协议并没有太大的关系(下文解释理由)，因此这里不再提及。

HTTP解析器的职责

在进一步描述HTTP解析器之前，我们有必要先弄明白HTTP的职责，需要符合哪些约束条件。以下，以问答的形式进行阐述。

1. HTTP解析器在web server中处于什么位置？

   简单来说，它位于TCP服务器和应用框架之间，负责两者之间的数据转换。具体场景为：当HTTP请求到达时，解析器需要根据获取到的buf，对数据进行解析，并最终转换成应用框架能够识别的数据结构，比如HttpRequest、HttpResponse等；反之，它需要将数据结构的内容转换成字符串，并存储在buf中，提交给TCP服务器。

2. HTTP解析器是否需要处理header完整的语义？

   准确地说，这个问题没有标准答案，和性能指标相关，具体体现在服务器的并发模型。如果HTTP解析是在一个独立的线程中进行，那么可以适当解析header的具体语义；如果HTTP解析是main loop中进行的，那么应该避免进一步的解析，应该将这个过程充分延迟。

   总体来说，将header的语义解析延后是相对理性的做法，因为我们未必需要获取某些header的值，且总的解析时间都是包括在响应时间内的。我的选择是解析标准(有一定扩充)中指定的header的key，至于value，只做字符的合法性检查。

3. HTTP解析器是否应该处理body？

   对于这个问题，我曾经思考了很久，至少我目前的答案是不需要，也不应该。理由大致如下：其一，为了支持multi-part，这部分的解析应该充分延迟；其二，为了应对巨大的body，相对合理的做法是采用类似java中stream之类的做法，而不是一次性分配一大块内存，然后存储起来慢慢解析。

4. 常见的约束条件

   对于服务器的benchmark而言，尤其是只输出hello world的那种，HTTP解析器在很大程度上决定了性能，可以说，一个性能优异的解析器是高性能web服务器的必要条件，关于这点，大致可以从h2o server中看到点什么。简单来说，如果你想做一款能够应对C10K问题的server，那么解析器的吞吐量至少应该是1w/s，这个指标，对于C语言实现的模块而言，是相对容易的。

   除此之外，可用性和安全性，同样是不可忽视的需求，从HTTP解析器的角度考虑可用性，要求HTTP解析器能够应处理任何输入，做到不崩溃，这是最基本的要求。附带上安全性，那么就要求解析器能够识别非法的输入，并提供准确的错误信息。

HTTP解析器编写的几种方法

本节，我将从现存的几个开源实现进行分析，它们分别是http-parser(nodejs)，picohttpparser(h2o server)，以及本人的实现。

1. picohttpparser

picohttpparser作为h2o的HTTP解析器，拥有比较出色的性能，当然这也正是h2o的目标。

pico项目的代码并不难理解，不到1000行，就是常规的线性解析，没有任何状态，所做的也只是“断句”，将HTTP请求/响应的各个成分断开，然后存储到用户指定的buf中。值得注意的是，如果我们的机器支持SSE4.2指令，那么可以使用pico的加速功能，关于这条指令，我会专门写一篇博客进行介绍。

然后，作者在README中给出了一张很给力的benchmark图，号称性能超过http-parser 3倍，开启加速后，结果是快5倍。

确实是很惊人的成绩，我粗略总结了下原因：

1. 只进行断句，对header不做字符检查，不识别任何header-key；
2. 不在解析器内部分配任何内存，即不调用任何malloc；
3. 对buf的内容有一定假设，不判断buf是否读完。

大家确实可以在程序中用pico，但前提是需要做一些额外的工作：你需要在buf中存有足够的内容，因为pico对于非阻塞的适应性不好；你需要分配足够大的buf来存储header、path，谁都不知道到底会有多少条header；你需要在pico处理后，进一步识别数组中保存的是什么header，当然也免不了合法性检查。

漂亮的分数是有代价的，或许pico是为 单进程main loop + 线程池 这种模型准备的，但我肯定不会用它。

2. http-parser

http-parser是nodejs的HTTP解析器，比较成熟，代码量在2000+，能够识别主要的method，header-key，能够在解析时完成path和host的解析，使用回调注册的方式进行方法触发(作者又写了个没有回调的版本，hl)，包括内存分配，整体风格和libuv差不多。

话说作者原本的目标就是开发一个web server，然后加了v8引擎后，就成了nodejs。。。

整体的实现方式是添加大量状态，switch语句，比如如下形式：

H
HT
HTT
HTTP
HTTP1
HTTP1/

这种做法的优点是对非阻塞API的支持比较好，缺点是过于冗长，代码可读性不太高，对此作者采用了一些技巧，比如method根据第一个字母进行识别，貌似曾今见过有人拿这个黑nodejs。。

从性能指标上来看，http-parser的性能还是很优秀的，毕竟功能加强了很多。

不过，需要注意，switch的开销是存在的，尤其是在编译时不开优化，此时swich和if-else无异，即使开了优化，还是存在一定的开销，比如计算偏移，goto等。

3. 基于协程的实现

协程的作用就是将非阻塞API的问题去除，那么基于协程的实现是最简单的，在使用Dlang开发的时候，我实现过对应的版本，代码量不足300行，不需要任何状态。

基于协程的实现，性能不会太低，虽然协程的resume和yield的开销介于普通调用和系统调用之间，但是时间比重占的并不高。不过使用协程有个致命的问题，那就是内存占用过大，大量应用是不太现实的，貌似lwan就用了这种方法，不知道基于ucontext的协程实现性能开销如何。

4. 基于表驱动的实现

表驱动这个词，是我在看完《code complete》(代码大全)后，记得最牢的一个，因为它确实很有用，个别同学可别再把它和转移表或者跳转表的概念搞混了。

我当前的做法就是大量应用表驱动，主要体现在：

1. 实现记录合法的ascii表，解析式的查询开销为O(1)，而且是严格的；
2. 事先对各个header-key做hash处理，在处理时，只需要对每个相关的字符做hash处理，并在读到分割符后，进行查表，开销为O(1)，基本严格。

当然这也是http-parser的做法，只不过它并未使用hash来处理header-key。值得一体的是，我觉得可能hash在计算时，开销并不比switch小，有待进一步验证。

从目前的数据来看，当前实现的总体性能大概是http-parser的1.3倍，我使用了特殊的数据结构来尽可能避免在解析时分配内存，用time统计运行时间时，sys的开销基本为0。无论是出于时间开销，还是内存碎片的角度考虑，都应尽量避免大量分配小块内存。

优化建议

开发完原型后，我做了下简单的benchmark，对比pico，竟然被完爆。。。然后花了2天时间进行分析优化，总结了点内容，或许对各位有一定帮助。

1. switch的开销

   这个在上文中已经提及，一定要开优化，尽可能使case后的数字连续分布，主流的做法是写在enum内。总体而言，对于不是很复杂的if-else语句，使用switch替换，并不能带来显著提升，反而会使代码变得比较难读。

2. 避免分配内存

   尤其是在循环内部，应该尽量避免分配频繁分配内存，这么做会造成内存碎片，并且malloc最终会使用系统调用，当初我的benchmark中，malloc就“贡献”了近1/4的时间开销。

3. 如果你的程序适合用SSE4.2中的指令加速，那么可以一试，运用得当，应该能够加速3倍左右(intel官方给的数据)

4. 对结构体中的内容做“本地化处理”

   尤其是需要在循环中大量操作结构体时，一定要注意，因为它也会“贡献”很大比重的开销。这里所谓“本地化”，即使用函数的局部变量代替结构体中的数据，在函数返回时，写入。示例如下：

struct XXX {
    int anum;
    ...
};
void foobar(struct XXX* x) {
    int anum = x->anum;
    for(int i = 0; i < 10000000; ++1) {
        ++anum;
    }
    x->anum = anum;
}

我还尚未仔细对比过gcc开-O2后是否会做相关工作(或许未来可以描述一下)，所谓的本地化，一定要确保数据源和临时副本一致，切记。