18、HTTP协议解析：从原始字节到结构化请求
HTTP协议解析，说白了就是让服务器能看懂客户端发来的数据。你想想看，浏览器发过来一堆字节流，服务器得知道：这是GET还是POST？路径是什么？有没有带Cookie？这些信息都藏在HTTP报文里。
我个人习惯把HTTP解析看作一个"翻译"过程——把无结构的字节流，翻译成有结构的数据对象。今天我们就来聊聊这个翻译过程怎么实现。
HTTP请求/响应格式：你得先知道长什么样
HTTP报文的结构其实很简单，就三部分：
- 起始行：请求行或状态行
- 头部字段：一堆key: value
- 消息体：可选，比如POST提交的数据
一个典型的HTTP请求长这样：
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
User-Agent: Mozilla/5.0\r\n
Accept: */*\r\n
\r\n注意那个\r\n\r\n，这是头部结束的标志。我在项目中遇到过不少新手，解析时忘了检查这个空行，结果一直卡在头部读取阶段。
响应报文也类似，只是起始行变成了状态行：
HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
Content-Length: 128\r\n
\r\n
<html>...</html>HTTP解析器设计：核心思路
设计一个HTTP解析器，核心要解决两个问题：
- 边界识别：哪里是头部结束？哪里是消息体结束？
- 状态管理：解析到哪一步了？下一步该做什么？
我建议把解析器设计成"流式"的——来一点数据就解析一点，而不是等全部数据收齐再解析。为什么？因为网络数据是分片到达的，你永远不知道下一个包什么时候来。
核心设计原则：解析器应该是无状态的（或者说状态保存在解析器内部），每次调用只处理当前可用的数据，返回"已处理了多少字节"和"当前状态"。
解析器的接口设计，我个人习惯这样：
enum class HttpParseState {
kParseRequestLine, // 解析请求行
kParseHeaders, // 解析头部
kParseBody, // 解析消息体
kParseDone, // 解析完成
kParseError // 解析出错
};
class HttpParser {
public:
// 返回本次解析了多少字节
size_t Parse(const char* data, size_t len);
HttpParseState state() const;
const HttpRequest& request() const;
private:
HttpParseState state_;
std::string buffer_; // 暂存未处理完的数据
};状态机解析：这才是工业级做法
用状态机解析HTTP，说白了就是画一张"状态转移图"，然后照着图写代码。每个状态只做一件事，做完就跳到下一个状态。
我画了一张状态机图，你看一眼就明白了：
状态机解析的好处是：每个状态的处理逻辑是独立的，出错了能精确知道是在哪一步出的问题。我曾经在一个网关项目里用状态机解析HTTP，调试起来特别方便——打日志看状态流转，一眼就能定位问题。
代码实现上，核心就是一个switch-case：
size_t HttpParser::Parse(const char* data, size_t len) {
size_t parsed = 0;
while (parsed < len && state_ != kParseDone && state_ != kParseError) {
switch (state_) {
case kParseRequestLine:
parsed += ParseRequestLine(data + parsed, len - parsed);
break;
case kParseHeaders:
parsed += ParseHeaders(data + parsed, len - parsed);
break;
case kParseBody:
parsed += ParseBody(data + parsed, len - parsed);
break;
default:
break;
}
}
return parsed;
}小技巧：每个Parse函数返回"本次消费了多少字节"，而不是"是否解析完成"。这样上层调用者可以精确知道数据消耗情况，方便处理"数据不够"的场景。
HTTP长连接与管道化：性能的关键
HTTP/1.1默认支持长连接，也就是Keep-Alive。这意味着一个TCP连接可以发送多个请求，不用每次请求都重新建立连接。你想想看，省掉了三次握手和四次挥手，性能提升是立竿见影的。
长连接的解析要注意一点：连接复用后，解析器要能重置状态。每个请求解析完，状态机要回到起始状态，准备解析下一个请求。
void HttpParser::Reset() {
state_ = kParseRequestLine;
buffer_.clear();
// 注意：不要清空已解析出的请求数据
// 上层应该在处理完请求后主动拷贝走
}管道化（Pipelining）就更进一步了：客户端可以不等待前一个请求的响应，直接连续发送多个请求。服务器按顺序处理，按顺序返回。
注意：管道化虽然能提升性能，但实现起来坑很多。我曾经在一个高并发项目里踩过管道化的坑——客户端发了3个请求，服务器处理完第2个时出错了，第3个请求的结果怎么返回？这涉及到"队头阻塞"问题。实际项目中，我建议谨慎使用管道化，优先考虑HTTP/2的多路复用。
长连接和管道化对解析器的影响，主要体现在：
- 缓冲区管理：一个连接上可能有多个请求的数据混在一起，解析器要能正确切分
- 状态重置：每个请求解析完，状态机要干净地重置
- 超时处理：长连接空闲太久要断开，防止资源泄漏
总结一下
HTTP解析看起来简单，但要做好并不容易。我个人的经验是：
- 用状态机来管理解析流程，清晰且易调试
- 解析器要设计成流式的，能处理数据分片到达的情况
- 长连接下注意状态重置，管道化下注意请求边界
- 性能敏感的场景，考虑用零拷贝（如Linux的splice）来避免数据拷贝
嗯，HTTP解析就聊到这里。下一节我们会深入解析器的具体实现，包括缓冲区设计、性能优化等实战内容。