openssl的{{1}}来电状态的手册页：
SSL_read（）基于SSL / TLS记录工作。数据以记录形式接收（SSLv3 / TLSv1的最大记录大小为16kB）。只有在完全接收到记录时，才能对其进行处理（解密和完整性检查）。因此，在最后一次调用SSL_read（）时未检索到的数据仍然可以在SSL层内缓冲，并在下次调用SSL_read（）时检索。
鉴于：
浏览器几乎没有理由将标题分成多个SSL记录，对吧？或者是否存在那些在延迟方面如此积极的浏览器，它们甚至会将这些小型有效载荷切割成多个记录？
我问这个是因为能够从一个成功的SSL_read()调用填充的单个读缓冲区解析整个HTTP头集合会很好。如果这意味着拒绝奇怪的少数（例如，如果只有0.0000X％的所有请求），那对我来说可能是值得的。
编辑：Alexei Levenkov提出了Cookie可能非常长的有效点。但是，让我们考虑一下这个特定服务器从未设置或预期cookie的情况。
edit2 ：这个问题还为时过早。我同时编写的代码可以有效地存储每个客户端状态，以便在解析时接受任意数量的SSL记录，而不会产生任何重要性能损失。在这样做之前，我想知道我是否可以采取捷径，但普遍的共识似乎是我更好地阅读这本书。点了承认。
答案 0 :(得分：1)
不，仅饼干可能远高于16K。
根据RFC2109和IE implementation for cookie limits，建议的每个域的Cookie大小限制为80K
RFC 2109“6.3实施限制”部分：
每个cookie至少4096个字节（以大小为单位来衡量） 在语法中包含非终端cookie的字符 Set-Cookie标题的描述）
每个唯一的主机或域名至少有20个Cookie
答案 1 :(得分：1)
你无法做出这样的假设。就像recv()可以返回的字节少于请求的字节数，SSL_read()也可以。您有责任缓冲入站数据，读取所需的大量记录，然后仅在收到您希望收到的所有内容后处理缓冲的数据。在标题末尾收到<CRLF><CRLF>序列之前，您不应该处理HTTP标头。
答案 2 :(得分：1)
也许更谨慎的说法是假设是错误的，但我希望大多数情况下，平均情况下你会得到你想要的行为。我肯定不知道答案，但可以通过实验来找出答案。
我全都是因为黑客无视规则并滥用学习，娱乐和利润的协议，但除此之外，我认为限制自己阅读单一SSL记录没有任何好处。如果你不介意阐述我很好奇。
答案 3 :(得分：1)
浏览器没有理由将标题分成多个SSL 记录，对吗？或者那里的浏览器是如此具有侵略性 关于延迟，他们甚至会砍掉这些类型的 小型有效载荷分成多个记录？
可能有一些原因会导致将数据拆分为多个记录。其中之一是mitigation against the BEAST attack。
通常不能假设数据不会被分成多个记录。
我问这个，因为能够解析一个整体会很好 来自单个读缓冲区的HTTP标头集由单个填充 成功的SSL_read（）调用。如果这意味着否认奇怪的少数（例如，如果 只有0.0000X％的所有请求），这对我来说可能是值得的。
这不仅仅是一个SSL / TLS问题，但这也适用于TCP：不将传入数据视为流只会导致错误和错误代码。