Кто устанавливает размер окна TCP до 0, Indy или Windows?

Question

У нас есть сервер приложений, который наблюдал отправку заголовков с размером окна TCP 0, когда сеть была перегружена (на сайте клиента).

Мы хотели бы знать, является ли Indy или нижележащий уровень Windows ответственным за уменьшение размера окна TCP от номинального 64K в соответствии с доступной пропускной способностью.
И мы сможемдействовать, когда оно становится равным 0 (ничего не отправляется, пользователи ждут => ничего хорошего).

Итак, любая информация, ссылка, указатель на код Indy приветствуются ...

Отказ от ответственности: я не специалист по сетям.Пожалуйста, держите ответ понятным для среднего меня; -)
Примечание: это Indy9 / D2007 на Windows Server 2003 SP2.

Более подробные сведения:
Случаи нулевого окна TCP происходят на среднем уровне при обращении к серверу БД.
Это происходит в те же моменты, когда конечные пользователи жалуются на замедления в клиентском приложении (эточто вызвало расследование сети).
2 основных сетевых проблем, вызвавших узкие места.
Нулевое окно TCP возникло при перегрузке сети, но может быть вызвано или не вызвано этим.
Мы хотимзнать, когда это произойдет, и иметь возможность что-то сделать (по крайней мере, регистрируя) в нашем коде.

Таким образом, основной вопрос в том, кто устанавливает размер окна в 0 и где?
Куда подключаться (в Indy?), Чтобы знать, когда возникает это условие?

Answer 1

Размер окна в заголовке TCP задается программным обеспечением стека TCP, чтобы отразить размер доступного буферного пространства. Если ваш сервер отправляет пакеты с окном, установленным на ноль, это, вероятно, связано с тем, что клиент отправляет данные быстрее, чем приложение, работающее на сервере, читает их, и буферы, связанные с соединением TCP, теперь заполнены.

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

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

Answer 2

Поскольку вас также может заинтересовать решение вашей проблемы:

Если у вас есть какой-то контроль над тем, что работает на стороне сервера (тот, который отправляет сообщения с размером окна 0): Рассматривали ли вы использование setsockopt () с SO_RCVBUF, чтобы значительно увеличить размер буфера приема вашего сокета?

В Indy setsockopt () является методом TIdSocketHandle. Вы должны применить его ко всем объектам TIdSocketHandle, связанным с вашим сокетом. А в Indy 9 они находятся через свойство Bindings в вашем TIdTCPServer.

Я предлагаю сначала использовать getsockopt () с SO_RCVBUF, чтобы увидеть, что ОС дает вам в качестве размера буфера по умолчанию. Затем значительно увеличить это, возможно, путем последовательных испытаний, каждый раз удваивая размер. Вы также можете захотеть повторно запустить вызов getsockopt () после вашего setsockopt (), чтобы убедиться, что ваш setsockopt действительно выполнен: обычно существует верхний предел, который реализация сокета устанавливает для размеров буфера. И в этом случае обычно есть зависящий от ОС способ поднять это верхнее значение. Но это довольно экстремальные случаи, и вам вряд ли это понадобится.

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

Удачи!

Answer 3

Заголовок TCP с нулевым размером окна указывает, что буферы получателя заполнены. Это нормальное условие для писателя быстрее, чем читателя.

При чтении вашего описания не ясно, если это неожиданно. Что заставило вас открыть анализатор протоколов?