我目前正在编写一个低级 HTTP 解析器并遇到以下问题：
我正在逐个数据包地接收 HTTP 数据，即一次接收一个 TCP 有效负载。在解析这些数据时，我使用搜索 CRLF 的 HTTP 协议标准来描绘标题行、块数据（在分块编码的情况下）和双重 CRLF 从正文中描绘标题。
我的问题是：我是否需要担心 CRLF 可能会在两个 TCP 数据包有效负载之间拆分？例如，HTTP 标头将以 CRLFCRLF 结尾。有没有可能后面的两个TCP包先有CR，后有LFCRLF？
我假设是的；这是一个需要担心的情况，因为应用程序 (HTTP) 和 TCP 层彼此相当独立。
任何对此的见解将不胜感激，谢谢！
【问题讨论】：
是的，CRLF 有可能被拆分为不同的 TCP 数据包。想想单个 HTTP 标头比 TCP MTU 长一个字节的可能性。在这种情况下，只有 CR 有空间，NL 没有空间。
因此，无论您的代码多么棘手，它都必须能够处理这种拆分情况。
【讨论】：
您使用什么语言工作？它没有某种形式的套接字缓冲读取功能，所以你没有这个问题吗？
您的问题的简短回答是肯定的，理论上您确实必须担心它，因为数据包可能会这样到达。这是不太可能的，因为大多数 HTTP 端点倾向于在一个数据包中发送标头，在后续数据包中发送正文。这不是惯例，而是大多数基于套接字的程序/语言工作方式的性质。
要记住的一点是，虽然协议标准对 CRLF 分离非常清楚，但许多实现 HTTP 的人（尤其是客户端，但在某种程度上也包括服务器）并不知道/关心它们是什么做和不会遵守规则。他们倾向于仅用 LF 分隔行 - 特别是头部和主体之间的空白行，我在这个问题上看到的代码段数量我无法快速计算。虽然这在技术上是违反协议的，但大多数服务器/客户端都会接受这种行为并解决它，因此您也需要这样做。
如果您不能执行某种缓冲读取功能，那么有一些好消息。您需要做的就是一次将一个数据包读入内存并将数据标记到前一个数据包上。每次读取数据包时，扫描数据以查找双 CRLF 序列，如果没有找到，则读取下一个数据包，依此类推，直到找到头部的末尾。这将是相对较小的内存使用量，因为任何请求的头部都不应该超过 5-6KB，这给定以太网 MTU（平均大约）1450 字节意味着您不需要加载超过 4 或5个数据包进入内存以应付它。
【讨论】：