Netty SSL 模式奇怪的行为

Question

我想了解，为什么 Netty SSL 模式以奇怪的方式工作？ 此外，问题如下，当任何 SSL 客户端（https 浏览器、使用 ssl 的 java 客户端，以及任何 ssl 客户端应用程序）连接到 Netty 服务器时，我都会开始完整的消息，在那里我可以正确识别所使用的协议，但只要频道保持连接，任何以下消息都有奇怪的结构，非 ssl 模式不会发生同样的事情。 作为 https 浏览器连接到我的服务器时 messageReceived 方法的示例：

我已经使用 PortUnificationServerHandler 切换协议..（不使用 nettys http 处理程序，这只是示例，因为我自己的协议也使用 ssl 模式）

1. 第一条消息没问题，我得到了以 GET 或 POST 开头的完整标题
2. 比我发送响应...
3. 第二条消息只有一个字节长，并且只包含“G”或“P”。
4. 第三条消息比其余的以 ET 或 OST 开头，其余的 http 标头和正文..
5. 这里又是我的回应...
6. 第四条消息又是一个字节长并且再次只包含一个字节..
7. 第 5 条消息再剩下的……这样游戏就更进一步了……

这里不重要，使用哪个子协议，http 或任何其他协议，在第一条消息之后我首先得到一个字节，然后在第二条消息中得到请求的其余部分..

我想构建一些代理艺术，获取 ssl 数据并在其他侦听器上发送未编码的数据，但是当我直接这样做而不等待完整的数据请求时，目标侦听器（例如 http 服务器）无法处理此类数据，如果目标仅获得一个字节作为第一个（即使下一条消息包含其余部分），则通道将立即关闭并放弃请求.. 好的，首先虽然要做以下操作，暂时缓存第一个字节并等待下一条消息，然后加入这些消息，并且只有响应才能正常工作，但有时这不是正确的方法，因为一个字节有时真的最后一个消息字节，如果我缓存它并错误地等待下一条消息，我可以永远等待，因为 https 浏览器此时期望一些响应并且不再发送任何数据..

现在的问题是，是否可以使用 SSL 解决此问题？可能有特殊设置会影响这种行为吗？ 我希望立即完全加入消息，而不是首先是第一个字节，然后是其余的.. 您能否确认，对于较新的 Netty 版本，您使用 PortUnificationServerHandler 具有相同的行为（但没有 netty http 处理程序，请尝试一些自己的处理程序。） 这种行为好吗，我不相信，预计它会起作用..

Answer 1

您遇到的问题可能是由于the countermeasures against the BEAST attack。

这不是问题。似乎问题在于您假设您打算根据消息/数据包读取数据。情况并非如此：TCP（和 TLS/SSL）旨在用作连续数据流。您应该在数据可用时继续读取数据。将传入数据拆分到有意义的位置由应用程序协议指导。对于 HTTP，指示是标头后面的空白行和实体的 Content-Length 或分块传输编码。

如果您定义自己的协议，则无论您使用纯 HTTP 还是 SSL/TLS，都需要类似的机制。假设你不需要它只是偶然的。

Answer 2

我遇到过这个问题，发现它是使用 JDK1.7 引起的。回到 JDK1.6 解决了它。我没有时间进一步调查，但现在假设 SSLEngine 实现在 JDK 中发生了变化。我会在时间允许的时候进一步调查。