Мне действительно нужна помощь только в понимании следующего изображения, но я приведу фон для контекста.
У нас есть приложение, настроенное на использование прокси-сервера на порту 8080 и требующее доступа в Интернет. В случайное время в течение дня приложение не подключается и просто умирает. Мы пытаемся выяснить причину. Мы исключили правила URL-адреса FW и прокси (он всегда попадает на один и тот же URL-адрес, когда работает, и все равно дает сбой). Я думаю, что проблема связана с сетью из-за проблемы производительности самого прокси-сервера. Чтобы разобраться, я делал сетевые захваты, когда это происходило.
Если вы посмотрите на следующее изображение, это фрагмент с удаленными данными IP. Первая строка с источником "42" — это клиентская машина, делающая запрос TLS через прокси (IP 35) на порту 8080. ПРИМЕЧАНИЕ: Обычно это работает и запрашивает тот же URL/IP, но это один из случаев, когда это не удалось. Нижнее окно — это данные первой зеленой строки.
Выделенная часть "Следующий порядковый номер" соответствует ACK последнего возвращенного пакета от 35 (2-я строка до последней). Это 35, по сути, отвечает клиенту, заявляя, что он получил все данные, которые были ему отправлены (это означает, что устройство включено, поскольку оно подтверждает получение данных (что означает отсутствие проблем с FW или сетью)). Обратите внимание, что он не отправляет никаких данных обратно. Сразу после этого клиент отправляет TCP RST. Вот моя интерпретация, но я хотел бы, чтобы кто-то проверил, так как мои навыки TCP немного подзабыли.
Клиент отправляет прокси-серверу некую форму запроса, но по какой-то причине прокси-сервер не отвечает (на прикладном уровне). Поскольку прокси-сервер ОТВЕЧАЕТ TCP ACK, это означает, что на сетевом уровне все хорошо. Это означало бы, что когда данные передаются по сетевому стеку на сам прокси-сервер, именно прокси-сервер разрывает соединение. Почему это происходит, я пока не знаю, но я ищу разъяснений, чтобы поговорить с командой прокси-сервера и сказать им, что им нужно расследовать это (они не думают, что это прокси-сервер).
Другим доказательством в поддержку моего довода является то, что первые 4 строки, которые вы видите на изображении перед RST, повторяются много раз. Опять же, это означает, что клиент повторно отправляет любой запрос, который у него есть, но никогда не получает ответа; а затем он в конечном итоге сдается и выполняет сброс.
По-видимому, есть балансировщик нагрузки, который находится перед прокси, а прокси на самом деле представляет собой несколько машин. У меня есть ощущение, что проблема с одной из них на бэкенде, и LB не удаляет узел из пула, и поэтому потенциально отправляет данные в черную дыру.
Я ищу второе мнение. Судя по снимку, приведенное выше резюме выглядит точным?
решение1
Сразу после этого клиент выдает TCP RST
Не сразу. RST отправляется клиентом через 30 секунд после того, как сервер отправил последний ACK.
... первые 4 строки, которые вы видите на изображении перед RST, повторяются много раз
Это не те же самые строки. У них разное значение ACK.
Моя интерпретация здесь такова, что клиент отправляет запрос с большей полезной нагрузкой (отсюда и множественные ACK от сервера для подтверждения этого), а затем ожидает, что прокси отправит ответ обратно. Через 30 секунд без ответа клиент сдается и закрывает соединение с помощью RST.
Непонятно, почему прокси не отправляет ответ. Это может быть проблема прокси. Но это может быть также проблема вышестоящего сервера, и сервер просто распространяет проблему на клиента.
Обратите внимание, что интерпретация может быть неверной. Контекста и захвата пакетов не так много, поэтому это скорее обоснованное предположение.