Назад | Перейти на главную страницу

Как балансировщик нагрузки управляет TCP-соединениями

У меня есть вопросы об обработке TCP-соединений с помощью балансировщика нагрузки.

У меня есть три сервера за балансировщиком нагрузки, и иногда из-за некоторых задач обработки случается, что данные между серверами и клиентами не отправляются, после 5 минут простоя соединения будут сброшены, потому что сервер отправил флаг RST (сброс соединения одноранговым узлом ). Мне было интересно, что за это может отвечать балансировщик нагрузки, поэтому я использовал WireShark для захвата TCP-пакетов с помощью RST FLAG, и он захватил такие пакеты.

Мой вопрос: если балансировщик нагрузки отвечает за сброс соединения, я не увижу RST-пакеты на стороне сервера, поскольку они были отправлены LB с измененным IP-адресом источника? Или, может быть, я ошибаюсь, и все еще возможно захватить его на стороне сервера, даже если LB отправляет пакеты RST?

ИЗМЕНИТЬ 1

Я хотел бы сузить (или, возможно, улучшить) свой вопрос. Если что-то между клиентом и сервером отправляет пакет с RST, должен ли он быть виден как на клиенте, так и на сервере или только на одном из них (например, клиент)?

РЕДАКТИРОВАТЬ 2

Я захватил пакеты с флагом RST на стороне клиента и сервера, и что странно, так это то, что на стороне клиента это выглядит так, как будто сервер LB отправил их, а на стороне сервера похоже, что клиент отправил их (по IP-адресу источника / назначения )

Насколько я понимаю, это ваше неправильное представление о сетевых темах, включая уровни OSI и методы связи.

Чтобы кратко ответить на ваш главный вопрос, я должен сказать, что то, как работает ваш LoadBalancer, полностью зависит от вашей конфигурации и от того, как вы определили / хотели, чтобы он лечился. Но чтобы показать вам, как на самом деле работает LoadBalancing на уровнях 4 и 7 модели OSI, прочтите следующую информацию:

Прежде всего, о пакетах RST вы должны отметить, что то, что вы упомянули, является совершенно обычным, потому что RST используется для сброса соединения и может происходить с обеих сторон в зависимости от того, что не может быть завершено, и когда больше не происходит разговора между сервером и клиентом. пока соединение еще не завершено. Выдержка из ответа в Quora, RST-пакет отправляется либо в середине трехстороннего рукопожатия, когда сервер отклоняет соединение, либо он недоступен, ИЛИ в середине передачи данных, когда сервер или клиент становятся недоступными или отклоняют дальнейшую связь без формального четырехстороннего Процесс завершения TCP-соединения.

Протокол управления передачей (TCP) работает в транспорт уровень (уровень 4 в модели OSI). TCP обеспечивает надежную, упорядоченную и проверенную на ошибки доставку потока октетов и создает виртуальное соединение между приложениями, работающими на хостах, обменивающихся данными по IP-сети. Другими словами, он предоставляет услугу связи на промежуточном уровне между прикладной программой и Интернет-протоколом, а поскольку IP-пакеты могут - могут - быть потеряны, повреждены или поступают не по порядку, TCP имеет механизмы для исправления этих ошибок, преобразования поток IP-пакетов в надежный канал связи. Каждому приложению назначается уникальный номер порта TCP, чтобы обеспечить доставку в нужное приложение на хостах, на которых запущено множество приложений. Например, стандартный TCP-порт 22 был назначен для связи с серверами SSH - порты по умолчанию можно изменить в файлах конфигурации, если это необходимо.

В Балансировка нагрузки уровня 4 IP-адрес балансировщика нагрузки объявляется клиентам веб-сайта или службы. Итак, как можно было догадаться, адрес назначения, записанный в запросах клиентов, будет адресом LoadBalancer. Когда Балансировщик нагрузки уровня 4 получает запрос и принимает решение о балансировке нагрузки, а также выполняет преобразование сетевых адресов (NAT) для пакета запроса, изменяя записанный IP-адрес назначения со своего собственного на адрес сервера содержимого, который он выбрал во внутренней сети. Например, в вашем сценарии ваш LoadBalancer изменит свой собственный адрес на тот, который необходим для сервера запрошенной службы для клиента, чтобы быть более точным, давайте рассмотрим один из ваших трех серверов за LoadBalancer, который служит вашим сервером хранения, а клиент желает прочитать PDF-файл или любой другой контент на вашем сайте. В качестве адреса назначения клиента установлен общедоступный IP-адрес, который назначен вашему LoadBalancer, и когда ваш LoadBalancer получит запрос, он решит, на какой сервер - во внутренней сети, используя собственный - он должен сопоставить запрос в зависимости от ваших правил. установлен и настроен в вашем LoadBalancer. Точно так же, прежде чем пересылать ответы сервера клиентам, балансировщик нагрузки изменяет адрес источника, записанный в заголовке пакета, с IP-адреса внутреннего сервера (например, вашего хранилища) на свой собственный. (Номера TCP-портов назначения и источника, записанные в пакетах, иногда также изменяются аналогичным образом.) Затем он принимает решения о маршрутизации на основе адресной информации, извлеченной из первых нескольких пакетов в потоке TCP, и не проверяет содержимое пакета.

И чтобы ответить «если балансировщик нагрузки отвечает за сброс соединений, я не увижу пакеты RST на стороне сервера, поскольку они отправляются LB с измененным IP-адресом источника?», Я должен сказать, что вы будете видеть пакеты RST на других серверах, только если их соединение необходимо сбросить с помощью LoadBalancer, а не соединение клиента с LoadBalancer.

Кстати, я настоятельно рекомендую вам использовать tcpdump на своих внутренних серверах, чтобы узнать, можете ли вы получать запросы от LoadBalancer или нет, чтобы вы могли видеть, что идет не так, и узнать, как исправить свои проблемы. Не вводите себя в заблуждение, используя WireShark, это отличный инструмент, но вы должны быть достаточно знакомы, чтобы понимать, что он вам показывает.