如何在非阻塞Socket Web服务器中高效处理HTTP流水线请求？

问题背景 #

我正在开发一个可响应静态网页GET请求的Web服务器，目前使用非阻塞Socket实现，当前的read()循环代码仅能处理非流水线请求，存在繁琐且易出错的问题，代码如下：

while(1){
    ssize_t bytesRcv = read(connfd, buff, buff_len);
    if( bytesRcv < 0 ){
        if( bytesRcv == 0 ){
            /*  
                Client closed his side of connection, put it in a disconnected state.
                Note : We can still send messages to the client, thus we will parse this
                request and send a message and then close the client.
            */
            client.state = DISCONNECTED | PENDING_REPLY;
            break;
        }
        if( bytesRcv == -1 ){
            if( errno == EAGAIN || errno == EWOULDBLOCK ){
                /*  
                    We have read all that we could, now the client is waiting for our reply.
                    We will put the client into pending_reply state.
                 */
                
                client.state = PENDING_REPLY;
            }
        }

        buff[bytesRcv] = '\0';
        buff += bytesRcv;
        buff_len -= bytesRcv;

        /*  
            If the message ends with two CRLF, we have gotten 1 full request. Break out of the loop
            put the client in pending reply state 
            Note, it is an assumption that the request is not pipelined, therefore, we will have \r\n\r\n
            at the end of the message.
            How do I make it so that piplined request can be handled?
        */
        if( strcmp(buff - 4, "\r\n\r\n") == 0 ){
            client.state = PENDING_REPLY;
            break;
        }
    }
}

想请教两个问题：

1. 如何在不大幅损失性能的前提下处理HTTP流水线请求？
2. 应先读取全部消息还是在每次read()调用后立即调用parse_http_header()函数？

一、处理HTTP流水线请求的实现思路 #

要支持流水线请求，核心是在一个连接上区分出多个独立的HTTP请求，同时保持非阻塞IO的性能优势，具体可按以下步骤调整：

• 维护客户端专属的请求缓冲区
  不要每次读取后直接移动指针丢弃已处理数据，为每个客户端保留一个可扩容的缓冲区（比如动态数组或环形缓冲区），将每次read到的数据追加到缓冲区末尾。这样即使一次read返回了多个请求的片段，也能后续逐步解析。

• 实现增量式的请求边界识别
  不再依赖\r\n\r\n作为单次循环的终止条件，而是每次读取后，在缓冲区中循环扫描完整请求：

  1. 扫描缓冲区，找到第一个\r\n\r\n的位置，该位置之前的内容为一个完整的GET请求头（GET无请求体，头结束即请求结束）。
  2. 处理该完整请求，生成响应并加入响应队列，然后将缓冲区中已处理的部分移除（或用偏移量标记已处理位置，避免内存拷贝）。
  3. 重复扫描，直到找不到完整的请求边界为止。

• 调整客户端状态管理逻辑

  • 当缓冲区中还有未处理的请求片段时，即使遇到EAGAIN/EWOULDBLOCK，也不要直接进入PENDING_REPLY，而是保持客户端的可读状态，等待下一次IO事件触发时继续读取数据。
  • 只有当缓冲区中无未处理请求，且当前所有响应都已发送完毕时，才将客户端标记为等待状态。

• 利用HTTP Connection头管理连接生命周期
  解析每个请求的Connection头：如果是close，则处理完该连接上的所有流水线请求后关闭连接；如果是keep-alive（HTTP/1.1默认），则保持连接，继续等待后续请求。

二、读取与解析的时机选择：每次read后立即解析 #

先读取全部消息再解析的方式在非阻塞IO场景下存在明显问题：无法提前判断"全部消息"的长度（尤其是流水线请求包含多个请求时），会导致缓冲区占用过大，同时阻塞后续IO处理。正确的做法是每次read()调用后立即调用parse_http_header()进行增量解析，原因如下：

• 性能更优
  增量解析能及时处理已收到的完整请求，避免缓冲区堆积过多数据，减少内存占用。同时，一旦解析出完整请求，就可以提前开始生成响应（比如读取静态文件），和后续的IO读取并行处理，提升整体吞吐量。

• 适配非阻塞IO模型
  非阻塞IO的核心是"有数据就处理，没数据就等待"，每次read后立即解析符合这个模型，不会因为等待"全部消息"而浪费IO事件循环的时间。

• 避免数据丢失或重复处理
  如果等到读取全部消息再解析，当客户端发送的流水线请求被拆分成多次read返回时，很容易出现缓冲区溢出或重复扫描的问题，增量解析能逐步处理每个片段，避免这类错误。

增量解析的关键细节 #

parse_http_header()函数需要设计成可重入的：

• 接收当前缓冲区的起始地址、已处理的偏移量、剩余长度作为参数。
• 返回解析出的完整请求数量，以及更新后的偏移量。
• 如果遇到不完整的请求头，直接返回，等待下一次read后继续解析。

内容的提问来源于stack exchange，提问作者Cardinal