Как http-клиент связывает http-ответ с запросом (с Netty) или вообще?

Question

Предполагается ли, что конечная точка http отвечает на запросы от конкретного клиента в порядке их получения?

Что делать, если это не имеет смысла в случае запросов, обрабатываемых кластером за прокси-сервером, или запросов, обрабатываемых с помощью NIO, когда один запрос выполняется быстрее, чем другой?

Существует ли стандартный способ связывания уникального идентификатора с каждым запросом http для связи с ответом?Как это обрабатывается в клиентах, таких как http-компоненты httpclient или curl?

Вопрос сводится к следующему случаю:

Предположим, я загружаю файл с сервера и запрос не завершен,Способен ли клиент выполнять другие запросы в том же соединении keep-alive?

Answer 1

При каждом открытии TCP-соединения оно распознается портами источника и назначения, а также IP-адресами. Поэтому, если я подключусь к www.google.com через порт назначения 80 (по умолчанию для HTTP), мне потребуется свободный исходный порт, который будет генерироваться ОС.

Ответ веб-сервера затем отправляется на порт источника (и IP). Так же работает NAT, запоминая, какой порт источника принадлежит какому внутреннему IP-адресу (и наоборот для входящих соединений).

Что касается вашего редактирования: нет, одно соединение http может выполнять одну команду (GET / POST / etc) одновременно. Если вы отправляете другую команду во время получения данных от ранее выполненной команды, результаты могут отличаться в зависимости от реализации клиента и сервера. Я предполагаю, что Apache, например, передаст результат второго запроса после отправки данных первого запроса.

Answer 2

Я не буду переписывать ответ CodeCaster, потому что он очень хорошо сформулирован.

В ответ на ваше редактирование - нет. Это не. Одно постоянное соединение HTTP может использоваться только для одного запроса одновременно, иначе это может привести к путанице. Поскольку HTTP не определяет какую-либо форму механизма отслеживания запросов / ответов, это просто невозможно.

Следует отметить, что существуют другие протоколы, в которых используется аналогичный формат сообщения (соответствует RFC822 ), которые допускают это (используя такие механизмы, как заголовок cSeq SIP ) и было бы возможно реализовать это в пользовательском приложении HTTP, но HTTP не определяет никакого стандартного механизма для этого, и поэтому ничего нельзя сделать, что можно было бы предположить, чтобы работать везде. Это также может вызвать проблемы с ответом на второе сообщение: дождитесь завершения первого ответа перед отправкой второго ответа или попытаетесь приостановить первый ответ, пока отправляете второй ответ? Как вы будете сообщать об этом таким образом, чтобы гарантировать, что сообщения не будут повреждены?

Также обратите внимание, что SIP (обычно) работает по протоколу UDP, что не гарантирует упорядочение пакетов, что делает систему cSeq более необходимой.

Если вы хотите отправить запрос на сервер во время выполнения другой транзакции, вам потребуется создать новое соединение с сервером и, следовательно, новый поток TCP.

Facebook провел некоторое исследование этого вопроса, когда создавал свои CDN, и пришел к выводу, что вы можете эффективно иметь 2 или 3 открытых потока HTTP одновременно, но более того, это сокращает общее время передачи из-за дополнительных издержек пакета Стоимость. Я бы дал ссылку на запись в блоге, если бы смог найти ссылку ...