2

我试图理解，为什么 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. 第五条消息，其余的……这样游戏就更进一步了……

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

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

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

4

2 回答 2

1

您遇到的情况很可能是针对 BEAST 攻击的对策所致。

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

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

于 2013-04-08T11:39:47.857 回答
0

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

于 2013-04-08T09:02:59.227 回答