当使用SSLStream将“大”数据块（1兆）发送到（已经过身份验证的）客户端时，我看到的数据包碎片/分解比使用时强
在客户端上使用异步读取（即BeginRead（）），重复调用ReadCallback，使用完全相同大小的数据块，直到最后一个数据包（数据的其余部分）。对于我发送的数据（它是一个zip文件），段的长度恰好是16363个字节。 注意：我的接收缓冲区比这大得多，改变它的大小没有效果
据我所知，SSL以不超过18Kb的块加密数据，但由于SSL位于TCP之上，我不认为SSL数据块的数量与TCP数据包碎片有任何关联吗？
基本上，客户端完全读取数据的时间比使用标准NetworkStream要长20倍（都在localhost上！）
我错过了什么？
修改
我开始怀疑SSLStream的接收（或发送）缓冲区大小是有限的。即使我使用同步读取（即SSLStream.Read（）），也不再有可用的数据，无论我在尝试读取之前等待多长时间。这与我将接收缓冲区限制为16363字节的行为相同。设置底层NetworkStream的SendBufferSize（在服务器上）和ReceiveBufferSize（在客户端上）无效。
答案 0 :(得分：0)
这看起来像是由私有成员定义的SslStream应用的数据包数据大小限制：
SSLStream._SslState.MaxDataSize
我很难理解为什么要应用此限制，或者是否可以更改，并且问了here