У меня есть ситуация, когда приложение прослушивает порт TCP и время от времени, как видно из дампов tcp, устанавливает для своего окна приема (RWIN) нулевое значение. Когда это происходит, его Recv-Q перестает двигаться (потому что отправитель перестает отправлять), и поток приложения, прослушивающий соединение / порт, просто зависает. В WireShark я вижу, что создаются состояния «ZeroWindow», что происходит, когда RWIN установлен на 0 (окно размером 0).
Я пытаюсь определить, устанавливает ли мое приложение, использующее множество библиотек с открытым исходным кодом, заполненных загадочным кодом, вручную RWIN = 0 для своего соединения или это происходит на уровне ОС. Если это приложение, у меня есть доступ ко всему исходному коду, и после некоторой напряженной работы я могу его правильно отладить.
Но если это ОС говорит "эй, что-то не так с этим подключением, установка RWIN на 0 ..."тогда я понятия не имею, как проводить диагностику. Есть мысли? Заранее спасибо!
Окно приема рассчитывается / устанавливается ОС. Linux может изменить объем памяти, доступной для приема TCP-пакетов, с помощью net.core.rmem_max sysctl настройка.
Есть много страниц для настройки производительности TCP, например эта:
http://fasterdata.es.net/host-tuning/linux/
Увы, это, скорее всего, вам не поможет, так как просто увеличивает объем буферизованных данных.
Если буфер заполнен, размер окна устанавливается на 0. Вы должны посмотреть в своем приложении, почему оно не собирает данные из буфера TCP. Файлы журнала, запускайте его в режиме отладки и т. Д. На уровне ОС вы мало что можете сделать для этого.
Это действительно зависит от обстоятельств. Вы не указали, о какой ОС вы говорите, но в Windows (и, я полагаю, также в Linux) размер окна TCP обычно обрабатывается стеком TCP.
Однако вполне возможно, что некоторые компоненты, не относящиеся к ОС, также могут повлиять на это. Например: - Приложение может влиять на поведение стека TCP, задав для сокета размер буфера не по умолчанию (SO_RCVBUF). - Приложение может использовать необработанные сокеты и повторно реализовывать TCP в пользовательском режиме (не знаю, зачем вам это нужно, но это возможно).
Наконец, вы должны знать, что получение размера окна 0 на самом деле является нормальным условием: оно указывает на то, что одна из сторон уже имеет полный буфер данных и ему требуется больше времени для его обработки.