我试图理解，为什么 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 处理程序，请尝试一些自己的处理程序。）这种行为好吗，我不相信，预计它会起作用..