Я пытаюсь понять, почему режим Netty SSL работает странным образом? Кроме того, проблема заключается в следующем: когда любой SSL-клиент (https-браузер, java-клиент, использующий ssl, а также любое клиентское приложение ssl) подключается к серверу Netty, я получаю в начале полное сообщение, где я могу правильно распознать используемый протокол, но пока канал остается подключенным, любые последующие сообщения имеют странную структуру, чего не происходит в режиме без ssl. В качестве примера метода messageReceived, когда браузер https подключается к моему серверу:
Я использовал PortUnificationServerHandler для переключения протоколов.. (без использования обработчика http nettys, это просто пример, потому что я также использую режим ssl для своего собственного протокола)
- первое сообщение в порядке, я получаю полный заголовок, начинающийся с GET или POST
- чем я посылаю ответ...
- второе сообщение имеет длину всего один байт и содержит только «G» или «P».
- третье сообщение больше, чем остальные, начинающиеся либо с ET, либо с OST, а остальная часть заголовка и тела http.
- вот опять следует мой ответ...
- четвертое сообщение снова имеет длину один байт и снова содержит только один байт.
- пятое сообщение опять остальное... и так игра идет дальше..
здесь не важно, какой подпротокол используется, http или любой другой, после первого сообщения я получаю сначала один байт, а во втором сообщении остальную часть запроса.
Я хотел создать некоторое искусство прокси, получить данные ssl и отправить их в незакодированном виде другому слушателю, но когда я делаю это напрямую, не дожидаясь полного запроса данных, целевой слушатель (например, http-сервер) не может обрабатывать такие данные, если цель получает только один байт как первый (даже если следующее сообщение содержит остальные), канал немедленно закрывается и запрос отбрасывается.. Хорошо, сначала нужно сделать следующее, временно кэшировать первый байт и дождаться следующего сообщения и чем присоединиться к этим сообщениям и только чем ответить, это работает нормально, но иногда это неправильный подход, потому что один байт иногда действительно является последним байтом сообщения, и если я кэширую его и ошибочно жду следующего сообщения, я могу ждать вечно, потому что браузер https ожидает в это время какого-то ответа и больше не отправляет никаких данных.
Теперь вопрос, возможно ли решить эту проблему с помощью SSL? Может есть какие-то специальные настройки, влияющие на такое поведение? Я хочу полностью объединенное сообщение сразу как есть, а не сначала первый байт, а затем остальные.. Не могли бы вы подтвердить, что с более новыми версиями Netty вы ведете себя так же, используя PortUnificationServerHandler (но без обработчика netty http, попробуйте какой-нибудь собственный обработчик.) Это поведение нормально, я не верю, оно было спроектировано так, чтобы работать.
