Кто записывает размер окна TCP к 0, Инди или Windows?
У нас есть сервер приложений, которые наблюдались, отправляя заголовки с размером окна TCP 0 время от времени, когда сеть имела перегрузку (на сайте клиента).
Мы хотели бы знать, является ли это Инди или базовый уровень Windows, который ответственен за корректировку размера окна TCP вниз от номинала 64K в адаптации к доступной пропускной способности.
И мы смогли бы реагировать на него становящийся 0 (ничто не добирается, отправляют, пользователи ожидают => отрицательный результат).
Так, любая информация, ссылка, указатель на код Инди приветствуется...
Отказ от ответственности: Я не сетевой специалист. Сохраните ответ понятным для среднего числа меня ;-)
Примечание: это - Indy9/D2007 на Windows Server 2003 SP2.
Более окровавленные детали:
Нулевые случаи окна TCP происходят на среднем уровне, говорящем с сервером БД.
Это происходит в те же моменты, когда конечные пользователи жалуются на замедление в клиентском приложении (это - то, что инициировало сетевое расследование).
Были определены 2 проблемы крупной сети, вызывающие узкие места.
Нулевое окно TCP произошло, когда была перегрузка сети, но можете, или может не быть вызван им.
Мы хотим знать, когда это происходит и имеет способ сделать что-то (регистрирующийся, по крайней мере) в нашем коде.
Таким образом, базовый вопрос состоит в том, кто устанавливает размер окна на 0 и где?
Где сцепиться (в Инди?) для знания, когда то условие происходит?
3 ответа
Размер окна в заголовке TCP обычно устанавливается программным обеспечением стека TCP, чтобы отразить размер доступного буферного пространства. Если ваш сервер отправляет пакеты с окном, установленным на ноль, возможно, это связано с тем, что клиент отправляет данные быстрее, чем приложение, работающее на сервере, читает их, и буферы, связанные с TCP-соединением, теперь заполнены.
Это совершенно нормальная операция для протокола TCP, если клиент отправляет данные быстрее, чем сервер может их прочитать. Клиент должен воздерживаться от отправки данных до тех пор, пока сервер не отправит окно с ненулевым размером (в этом нет смысла, так как он все равно будет отброшен).
Это может отражать или не отражать серьезную проблему между клиентом и сервером, но если условие сохраняется, это, вероятно, означает, что приложение, работающее на сервере, перестало читать полученные данные (как только оно начинает чтение, это освобождает буферное пространство для TCP. , и стек TCP отправит новый ненулевой размер окна).
Заголовок TCP с размером окна, равным нулю, указывает на то, что буферы получателя переполнены. Это нормальное состояние для более быстрого писателя, чем читателя.
Читая ваше описание, неясно, является ли это неожиданным. Что заставило вас открыть анализатор протоколов?
Так как вам тоже может быть интересно решение вашей проблемы:
Если у вас есть какой-то контроль над тем, что запущено на стороне сервера (тот, который посылает сообщения о 0 размере окна): Вы рассматривали возможность использования setsockopt() с SO_RCVBUF для значительного увеличения размера буфера приема вашего сокета?
В Indy, setsockopt() - это метод TIdSocketHandle. Вы должны применить его ко всем объектам TIdSocketHandle, связанным с вашим сокетом. А в Indy 9 они находятся через свойства Bindings в вашем TIdTCPServer.
Я предлагаю сначала использовать getsockopt() с SO_RCVBUF, чтобы увидеть, что ОС дает вам в качестве размера буфера по умолчанию. Затем значительно увеличьте его, возможно, путем последовательных проб, удваивая размер каждый раз. Вы также можете повторно выполнить вызов getsockopt() после вашего setsockopt(), чтобы убедиться, что ваш setsockopt был действительно выполнен: Обычно существует верхний предел, который реализация сокета устанавливает на размер буфера. И в этом случае обычно существует зависящий от ОС способ сдвинуть это предельное значение вверх. Но это скорее крайние случаи, и вам это вряд ли понадобится.
Если у вас нет контроля над исходным кодом той стороны, на которой происходит переполнение, просто проверьте, нет ли в работающем там программном обеспечении какого-либо параметра для изменения размера буфера.
Удачи!