我试图理解，为什么Netty SSL模式以奇怪的方式工作？ 此外，问题是，当任何SSL客户端（https浏览器，使用ssl的java客户端，也是任何ssl客户端应用程序）连接到Netty服务器时，我开始使用完整的消息，我可以正确识别所使用的协议，但是通道保持连接，任何后续消息都有奇怪的结构，非ssl模式没有发生同样的事情。 以https浏览器连接到我的服务器时的messageReceived方法为例：
我已经使用PortUnificationServerHandler来切换协议..（不使用nettys http处理程序，它只是示例，因为我也使用ssl模式用于我自己的协议）
- 第一条消息没问题，我从GET或POST
开始获得完整的标题- 比发送回复...
- 第二条消息只有一个字节长，仅包含“G”或“P”。
- 第三条消息是从ET或OST开始的其余部分以及其余的http标题和正文..
- 这里再次按照我的回复......
- 第四条消息又是一个字节长，并且只包含一个字节..
- 第五条消息，其余的......以这种方式，游戏更进一步......
这里不重要，使用哪个子协议，http或者其他任何一个，在第一个消息之后我首先获得一个字节，然后在第二个消息中获得请求的其余部分。
我想构建一些代理技术，获取ssl数据并将其发送到其他侦听器上，但是当我直接执行它而不等待完整数据请求时，目标侦听器（例如http服务器）无法处理此类数据，如果目标只获得一个字节作为第一个（即使下一个消息包含其余的），通道立即关闭，请求被放弃.. 好吧，首先是做以下操作，暂时缓存第一个字节并等待下一条消息然后加入这些消息，而不仅仅是响应，这样可以正常工作，但有时这种方法不正确，因为有时一个字节确实是最后一个消息字节，如果我缓存它并等待错误的下一条消息，我可以永远等待，因为https浏览器此时需要一些响应并且不会再发送任何数据..
现在的问题是，是否可以使用SSL解决此问题？可能有特殊设置会影响这种行为吗？ 我想要一次完全加入消息，而不是第一个字节，而不是其余的.. 您能否确认，使用较新的Netty版本，您可以使用PortUnificationServerHandler（但没有netty http处理程序，尝试使用自己的处理程序）。 这种行为是好的，我不相信，这是预期的工作..
答案 0 :(得分：1)
您遇到的问题很可能是由于the countermeasures against the BEAST attack。
这不是问题。似乎问题在于您假设您打算根据消息/数据包读取数据。情况并非如此：TCP（和TLS / SSL）旨在用作连续数据流。您应该在数据可用时继续读取数据。在应用程序协议的指导下，将有意义的传入数据拆分到何处。对于HTTP，指示是标题之后的空白行以及实体的Content-Length或分块传输编码。
如果您定义自己的协议，则无论使用纯HTTP还是SSL / TLS，都需要类似的机制。假设你不需要它只是偶然的工作。
答案 1 :(得分：0)
我遇到过这个问题，发现它是使用JDK1.7造成的。回到JDK1.6解决了它。我没有时间进一步调查，但现在已经假设在JDK中SSLEngine实现已经改变了。如果时间允许，我会进一步调查。