HTTP/1.1请求能否拆分为多个TCP消息？

我正在阅读有关Slowloris的文章，我不知道为什么攻击会起作用，因为客户端一次向服务器发送一个头。难道服务器不希望只有一条TCP消息/请求，不包括第二条消息/请求，如果使用分块编码，则第二条消息/请求可能在100个continue或2个以上continue之后随正文出现？HTTP请求是否可以一次发送一个字节？如果是，我应该在read（）调用后的每个字节后发送100 continue吗？我很难找到这是在哪里记录的。这对我来说尤其重要，因为我正在尝试用C从头开始构建HTTP服务器，我想知道是否需要逐个字符的解析。

从TCP获取数据 TCP不传递消息。它传递一个字节流，并且它可以在包裹中传递这些字节，这些包裹的大小不需要与发送者编写的包裹的大小有任何相似之处。因此，无论何时从TCP读取数据流，都必须准备好通过套接字上的多个

read（）

调用以小包裹的形式获取数据

通常，接收器会将这些包裹中的数据累积到缓冲区中，直到收集到足够的数据来构建某种有意义的数据单元，然后进行处理。根据数据的格式和含义，可操作数据的单位可以是一定数量的字节，或一行的字符，或（可能是多字节的）字符，或其他

对于HTTP服务器，可操作单元可以合理地是一组完整的头，可以通过标记头块末尾的空行识别。或者您可以决定第一个可操作单元是一行（HTTP请求行），第二个可操作单元是剩余的一组头。（如果您决定处理标题时的可操作单元始终是一行，则必须准备好处理多行标题。这可能需要额外的缓冲层。）

在通常情况下，如果指定的缓冲区足够大，HTTP连接上的TCP数据将以相当大的块到达，即单个

read（）

中的数百甚至数千字节。因此，可能所有的头都是由新连接上的第一个

read（）

收集的。但你不能指望这种情况发生。您必须准备好发出多个

read（）

调用以获取所需的数据

即使您必须进行多个

read（）

调用才能获取所有的头文件，但这样做的时间通常非常短，然后您可以继续处理此请求并继续下一个请求

资源耗竭 每当HTTP服务器处理一个请求时，它都会有一定数量的资源专用于该请求——它有连接套接字、数据缓冲区、可能分配用于跟踪请求状态的某些结构、可能一个或多个专用于该连接或请求的线程、TLS上下文（如果这是HTTPS请求），等等。如果可以快速处理请求，那么这些资源可以被释放、回收或应用于其他请求和连接。如果无法快速处理请求，则这些资源仍然被占用，如果服务器必须处理大量长期请求，则其资源需求可能会上升到服务器变得迟钝、无法接受新连接、甚至崩溃的程度

如果服务器的负载不足，则在正常操作中可能会发生资源耗尽，但攻击者也可能故意使服务器耗尽资源。这种攻击有许多变种。第一个HTTP服务器耗尽攻击涉及恶意客户端发送非常大（可能无限大）的请求体，和/或非常缓慢地发送这些请求体，和/或在根本不发送任何请求数据的情况下保持连接打开。服务器对此类攻击的防御措施是限制其将消耗的请求体的大小，限制其等待请求体完全交付的时间长度，以及限制其等待接收一定增量的请求数据的时间长度

还有一种攻击，即客户端打开与服务器的连接，但根本不发送任何头数据。服务器的防御措施是限制等待报头数据开始到达的时间，以及限制等待其他报头数据到达的时间

蜂猴 Slowloris攻击是基于报头的耗尽攻击过程中的下一步。它不是不发送头，而是发送头，但发送速度非常慢，只是足够慢，以避免服务器断开连接

Slowloris发送一系列无休止的组合头，这样服务器就不会进入防御荒谬的请求体攻击的模式。如果攻击者想在服务器上浪费更多CPU，甚至可以一次发送一个字节的这些头；我不知道最初的Slowloris是否做到了这一点，但如果后来的一些变体做到了这一点，我一点也不会感到惊讶

针对Slowloris的服务器端防御通常采用与针对恶意请求机构相同的策略。也就是说，在请求头上设置到达完成时间和总头大小限制

100继续

100 Continue

这件事是不相关的。在处理请求头之后，服务器应准备发送

100 Continue

临时响应，但前提是客户端明确指定（通过发送请求

100 Continue

的

Expect

头）它需要临时响应。以我的经验，这是罕见的，所以如果你只是一个普通人，我不会太担心