0

openssl的调用手册页SSL_read()指出：

SSL_read() 基于 SSL/TLS 记录工作。数据以记录的形式接收（SSLv3/TLSv1 的最大记录大小为 16kB）。只有当一条记录被完全接收时，它才能被处理（解密和完整性检查）。因此，在最后一次调用 SSL_read() 时未检索到的数据仍然可以在 SSL 层内缓冲，并将在下一次调用 SSL_read() 时检索。

鉴于：

  • 始终可以一次性发送单个传出消息的 HTTP 标头
  • 一条 SSL/TLS 记录显然可以保存 16KB 的数据，这对每个人来说都足够了（或者至少是任何非反常的 HTTP 请求）

浏览器几乎没有理由将标头分成多个 SSL 记录，对吗？或者是否有浏览器在延迟方面如此激进，以至于它们甚至会将这些小型有效负载分割成多条记录？

我之所以这样问，是因为能够从一个由单个成功SSL_read()调用填充的单个读取缓冲区解析一整组 HTTP 标头会很好。如果这意味着拒绝少数几个（例如，如果只有所有请求的 0.0000X%），那对我来说可能是值得的。

编辑：Alexei Levenkov提出了 cookie 可以很长的有效观点。但是让我们考虑一下这个特定服务器永远不会设置或期望 cookie 的场景。

edit2：这个问题有点为时过早。同时，我编写的代码可以有效地存储每个客户端状态，以便在解析时接受任意数量的 SSL 记录，而不会导致任何显着的性能损失。在这样做之前，我想知道我是否可以走捷径，但普遍的共识似乎是我最好按照书本行事。点承认。

4

4 回答 4

1

不，仅 cookie 就可能远高于 16K。

根据RFC2109和IE 对 cookie 的实施限制，建议每个域的 cookie 大小最小限制为 80K

RFC 2109 部分“6.3 实施限制”：

  • 每个 cookie 至少 4096 字节（通过在 Set-Cookie 标头的语法描述中组成 cookie 非终结符的字符的大小来衡量）

  • 每个唯一主机或域名至少 20 个 cookie

于 2013-06-08T01:17:45.357 回答
1

你不能做出这样的假设。就像recv()can 返回的字节数少于请求的字节数一样，SSL_read(). 您有责任缓冲入站数据，读取所需的记录数，然后仅在您完成接收预期接收的所有内容后处理缓冲的数据。<CRLF><CRLF>在收到标头末尾的序列之前，您不应该处理 HTTP 标头。

于 2013-06-08T01:23:03.783 回答
1

也许更谨慎的说法是假设是错误的，但我希望在大多数情况下，对于平均情况，您会得到您想要的行为。我不确定答案，但可以做实验来找出答案。

我完全支持无视规则和滥用协议来学习、娱乐和获利的黑客，但除此之外，我认为限制自己阅读单个 SSL 记录没有任何好处。如果您不介意详细说明，我很好奇。

于 2013-06-08T10:07:54.357 回答
1

浏览器几乎没有理由将标头分成多个 SSL 记录，对吗？或者是否有浏览器在延迟方面如此激进，以至于它们甚至会将这些小型有效负载分割成多条记录？

可能有一些原因导致将数据拆分为多个记录。其中之一是缓解 BEAST 攻击。

您通常不能假设数据不会被拆分为多个记录。

我之所以问这个问题，是因为能够从一个由单个成功的 SSL_read() 调用填充的单个读取缓冲区解析一整组 HTTP 标头会很好。如果这意味着拒绝少数几个（例如，如果只有所有请求的 0.0000X%），那对我来说可能是值得的。

这不仅仅是 SSL/TLS 问题，这也适用于 TCP：不将传入数据视为流只会导致错误和错误代码。

于 2013-06-08T15:23:40.390 回答