SYN получает RST, ACK очень часто

Question

Привет эксперты по программированию сокетов,

Я пишу прокси-сервер в Linux для SQL Server 2005/2008, работающий в Windows.Прокси-код закодирован с использованием сокетов bsd и в C, и он работает нормально с проблемой, описанной ниже.

Когда я использую клиент базы данных (написанный на JAVA и работающий в Linux) для запуска запросов (с параллелизмом 100 или более) непосредственно к серверу базы данных, не происходит сброс подключения.Но через мой прокси я испытываю много перезагрузок соединения.

Копание глубже Я узнал, что соединение от «клиента БД» до «Прокси» всегда успешно, но когда «Прокси» пытается соединиться с сервером БД,сбой соединения из-за получения пакета SYN RST, ACK.

Это должно было дать некоторую предысторию.Вопрос в том, почему иногда SYN получает RST, ACK?

DB client(linux) to Server(windows)  ----> Works fine
DB client(linux) to Proxy(Linux) to Server(windows) -----> problematic

Я знаю, что это может произойти в случае отказа в соединении, но это определенно не тот случай.SYN-переполнение может быть другим сценарием, но это не объясняет правильного поведения при непосредственном запуске на сервере.

Я подозреваю, что может потребоваться настройка некоторых параметров сокета, что клиент делает перед подключением, а мой прокси - нет.Пожалуйста, осветите это.Любая помощь (ссылки или указатели) приветствуется.

Дополнительная информация:

Написал клиент C, который выполняет параллельные соединения, который принимает параллелизм в качестве аргумента.Вот мои наблюдения: -> При параллельности 5000 и выше некоторые соединения не удалось установить «соединение отказано».-> ниже 2000, он работает нормально.

Но настоящая проблема наблюдается даже при параллельности 100 и более.Примечание: проблема зависит от времени, иногда она вообще не возникает, а иногда очень часто, и клиент БД (напрямую к серверу) всегда работает нормально.

Answer 1

SQL Server требуется рабочие потоки для приема входящих соединений. Если ваш сервер не хватает рабочего (что можно легко диагностировать по большому количеству записей в состоянии sys.dm_os_tasks в состоянии PENDING), то попытка открыть новое соединение не удастся. Вполне вероятно, что я подозреваю, что это происходит из-за того, что вы загружаете на сервер больше рабочей нагрузки, которую он может выдержать. Вам нужно оптимизировать рабочую нагрузку или получить более мощный сервер.

Клиенты, такие как клиент Java, эффективно используют пул соединений и даже при высокой нагрузке не нужно открывать новое соединение, поэтому вы не видите этой проблемы, вместо этого вы видите только задержки в завершении запросов ,

Answer 2

Когда SYN получает ответ RST, это не должно быть проблемой SQL-SERVER.

Поскольку приложение может accept сокет только после завершения рукопожатия tcp.

Есть ли какое-либо устройство между прокси и машинами SQL-Server?

Постарайтесь убедиться, что ответ RST исходит от сервера sql-сервера.

Я думаю, что количество соединений далеко от SYN-FLOOD.

Answer 3

Прослушивающий сокет хранит очередь установленных соединений и соединений в процессе установления (например, получен SYN, получен ответ SYNACK, но пока нет подтверждения от клиента). Если установленная очередь переполняется, реакция стека IP отличается в ОС. Наиболее традиционный подход состоял в том, чтобы игнорировать новые SYN, ожидая, когда пользовательский оператор accept () освободит слот в очереди. С атаками SYN-наводнения в середине 90-х годов был изобретен новый метод под названием «SYN cookies», который полностью исключает необходимость в очереди на установление, за счет стоимости поддержки специальной опции TCP. OTOH Я слышал, что стеки Windows меняют свое поведение - при некоторых условиях реакция на переполнение очереди является ответом RST. В более ранних стеках (например, Win95) это был основной ответ, и сторона клиента была соответственно изменена, чтобы игнорировать ответ RST на SYN :( Вот почему я предполагаю, что некоторые функции прокси-хоста запускают RST в стеке Windows.

Другое предположение состоит в том, что сервер БД вообще закрывает сокет прослушивания при некоторых условиях (например, обнаруженный пик перегрузки), который появляется только с прокси.