Я пытаюсь реализовать HTTP-туннель, используя методы, аналогичные тем, которые используются веб-браузерами для имитации дуплексного соединения, в Java с использованием среды Netty. Я хочу реализовать это таким образом, чтобы он работал при наличии реальных HTTP-прокси. Я пытаюсь сделать это без использования контейнера сервлета, чтобы избежать ненужных накладных расходов с точки зрения библиотечных зависимостей и потому, что API сервлета не соответствует шаблонам использования полнодуплексного туннеля http.
Мне известны некоторые ограничения, накладываемые HTTP-прокси, которые "нарушают" некоторые потенциальные возможности использования протокола HTTP:
- HTTP конвейерная обработка может не выполняться за пределами соединения между клиентом и прокси. Т.е. прокси-сервер может отправлять один запрос и ждать ответа перед отправкой следующего запроса, даже если клиент отправил несколько конвейерных запросов к прокси.
- Chunked-кодирование может не выполняться за пределами соединения между прокси-сервером аналогичным образом: сервер может отправлять ответ обратно в виде фрагментов, но прокси-сервер может ожидать окончания фрагмента, прежде чем отправлять полный, dechunked-ответ клиенту.
- HTTP CONNECT часто допускается только для портов SSL / TLS, обычно только для порта 443, поэтому его нельзя использовать в качестве хитрого способа получить беспрепятственное TCP-соединение с внешним миром.
Однако есть еще одна возможность, в которой я не уверен: действительно ли HTTP-прокси реального мира совместно используют постоянное соединение с сервером между несколькими клиентами? Например:
- Клиент A отправляет запросы A1, A2 и A3 на сервер X
- Клиент B отправляет запросы B1 и B2 на сервер X
- Клиент C отправляет запросы C1, C2 и C3 на сервер X
Будет ли прокси потенциально открывать одно соединение с сервером X и отправлять сообщения в следующем порядке:
А1, А2, В1, С1, В2, А3, С2, С3
или подобный порядок, который сохраняет порядок от каждого отдельного клиента, но потенциально чередуется? Или, что еще хуже, прокси-сервер может открывать несколько соединений с сервером и рассылать сообщения от каждого клиента между соединениями, т. Е.
Connection 1: A1, C1, C2, C3
Connection 2: B1, B2, A2, A3
Если это так, мой подход требует больше размышлений, поскольку мне потенциально необходимо демультиплексировать эти сообщения в разные очереди для каждого туннеля, и я не могу просто полагаться на определение соединения, используемого для конкретного клиента.
Кто-нибудь знает о каких-либо хороших ресурсах, которые описывают причуды часто используемых прокси-серверов HTTP и брандмауэров с проверкой состояния?