Статьи Галерея Форум Чат Файлы HowTo Ссылки Поиск
Текущее время: 20 июл 2019, 13:39




Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: интересный глюк с сетью...
СообщениеДобавлено: 03 ноя 2008, 16:30 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Есть прототип сервера написанный с использованием асинхронной модели. Сервер кросс-платформный и использует ICOP (на Windows), epoll (Linux), kqueue (FreeBSD, Mac OS X). Для целей тестирования сервер отдает простейшую HTML страницу, а быстродействие серверного скелетона тестируется с помощью утилиты ab (Apache Bench).

Были протестированы разничные варианты связок сервера и клиента - везде все хорошо, кроме связки сервер на Windows и тестирующий клиент на Mac OS X. Эмпирическим путем, поскольку в связках Windows-сервер плюс Linux-клиент и Windows-сервер - FreeBSD-клиент все работает хорошо, было установлено, что проблема существует из-за того, что Mac OS X выделяет порты из динамического клиентского диапазона подряд (т.е. 49152, 49153 и т.п.), что приводит к тому, что Windows на некоторое время перестает обрабатывать коннекты (не реагирует на SYN-пакеты от клиента). При связках с другими OS, где порты клиентского диапазона выделяются не подряд, а в случайном порядке - Windows ведет себя нормально - его не смущает большой connection rate.

При этом, что интересно в Mac OS X по умолчанию клиентские порты были настроены на диапазон 49152-65535, при этом Windows подвисала где-то на 16000 обработанных соединениях. При установке диапазона на Mac OS X в 1025-65535 до коматоза было обслужено соответствующее число портов - около 64000.

Когда Windows перестает отвечать на запросы Mac, то если при этом коннектиться на этот же Windows-сервер с другой машины Linux или BSD - все ок. Но, если пробовать подключаться на этот же Windows-сервер, но уже с другого Mac, то он тоже не может коннектиться на эту винду. Таким образом Windows отвечает на запросы любых клиентов, кроме Mac - даже несмотня на то, что запросы идут с физически разных машин.

Если же с мака, когда он уже не может соединяться с виндой, попробовать законнектиться с сервером на любой другой машине под Linux/BSD - то все ОК. Но если с этого же Mac попробовать законнектиться на физически другой Windows-сервер, то коннект также не работает.

Думал, что по симптомам дело в свиче/рутере, но оказалось, что это не так - подключенные напрямую машины глючат также.

После достижения некоторого лимита на залоченный таким образом Windows-сервер не может подключить ни один Mac-клиент, а залоченный Mac-клиент не может подключиться ни к одному Windows-серверу.

Хотя к этому же Windows-серверу легко коннектстся клиенты других OS, также как и этот Mac-клиент легко коннектится к серверам на других OS.

Еще инетересно, когда подвисат ab, то запущенный телнет висит какое-то время, а потом оживает. Вероятно идет SYN ретрансмит, на который уже есть ответ от винды.

Что больше всего странно - что если это проблема винды, то почему залоченный Mac-клиент, не может законнектиться на физически другой Windows-сервер? А если это проблема Mac-клиента, то почему физически другой Mac-клиент не может законнектиться на залоченный Windows-сервер? Почему у обоих залоченных Windows-сервера и Mac-клиента сразу же после подвисона (или точнее выразиться в процессе) нет никаких проблем в коммуникации с другими OS (Linux/FreeBSD).

Да. Все машины, которые использовались в тесте - физические, не виртуальные. Так что это не проблема виртуализации.

P.S. Если кто поможет разобраться - ящик пива или, скажем, $100 - легко.

Еще инфа по теме с английского форума:

Цитата:
Questions answered so far:

1) is only ab connections hang? what about telnet?

telnet hangs either

2) is it sequental (not randomized) port usage on Mac OS X?

not likely. sequental port usage from other OS dosn't reproduce the problem - just from Macs. However increasing range of dymanic ports in Mac os makes for this Mac-client a possibility to process as many connections as there are ports before the hang out. But what about a connection to locked Windows-server from another physical Mac-client that also hangs (immediately)?

3) is it TIME_WAIT problem?

not likely. TIME_WAIT TCBs must be reused and Mac-client connection to another Windows-server both have no TIME_WAIT TCBs in netstat -na output. With Linux/BSD clients all is OK - so TIME_WAIT TCBs are properly reused.

4) is it port exhaustion problem?

not likely. as only a few connections open simultaneously. with 10 concurrent connections all the same sympthoms as with 100 or 1000. And locked Mac-client successfully connects to another server running other OS (Linux/BSD).

5) is tcpdump (or any other sniffer) shows difference in packet sessions/sequences in comparison to BSD/Linux clients?

no. not easily visible. all exactly the same sequence of packets. 3 packets for opening the connection (syn, syn+ack, ack) + 2 data packets (1 for each direction) + 4 packets for gracefully shutting down (lingering) the connection (fin and ack for each direction).

6) did you try NAT in between of server and client?

yes. but no positive results.

7) is it switch/router issue?

no. direct computer-to-computer connection did not help either

8) did you try different network settings?

yes. all that you can find on the internet for both OSes. none of them helped so far.

9) which systems are affected

tested with Vista, Server 2003, Server 2008, Mac OS X Tiger, Mac OS X Leopard - all latest patches applied.

a) is it virtualization issue?

no. each machine involved in the testing is a physically different piece of hardware.

b) is it a packet rate / network speed / latency problem?

1000, 100, 10, 2 Mbps show same problems. round trip time from <1 ms. up to 10 ms.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 03 ноя 2008, 19:19 
Неотъемлемая часть форума

У нас с: 19.08.2004
Сообщения: 209
заранее извиняюсь, если неправильно понял вопросы, но
быть может, вопросы, изложенные выше, - это вопросы к разработчику/архитектору такого сервера, а не сетевому администратору?
В этом ключе хотелось бы предложить попробовать подебажить со стороны винды (последняя версия отладчика позволяет дебажить win2k3 и, немножко, висту).
ps. само собой, что я имею ввиду windbg, а не пародию на него из вижуал студии любой редакции :)


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 03 ноя 2008, 22:54 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Вопросы и ответы - это результаты моего безрезультатного долбления в стену. Просто на англ. форумах я тоже пишу.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 04 ноя 2008, 14:01 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
Цитата:
При этом, что интересно в Mac OS X по умолчанию клиентские порты были настроены на диапазон 49152-65535, при этом Windows подвисала где-то на 16000 обработанных соединениях. При установке диапазона на Mac OS X в 1025-65535 до коматоза было обслужено соответствующее число портов - около 64000.


А если дать только диапазон портов 1025-49152? Смущает меня цифера 65535....


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 04 ноя 2008, 23:34 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Аналогично с любым диапазоном.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 05 ноя 2008, 12:00 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
ХМ....можно выставить диапазон в десяток/сотню портов(что бы меньше дамп был=) и выложить полный дамп трафика между машинами до момента отказа в обслуживании и в тех случаях когда глюка нет?

И состояния соединений и портов. Не знаю как в венде, в макос должно быть что-то вроде netstat?

Или там уже тоже копал?


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 05 ноя 2008, 21:25 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Суть в чем. Когда клиент и сервер разъединяются по методу graceful disconnect - на сервере остается TIME_WAIT TCB для квадрипла SRV_IP :PORT CLIENT_IP :PORT. Когда на стороне клиента заканчиваются порты, то они начинают использоваться по кругу. В таком случае, если на сервере для повторно использующегося клиентского порта есть TIME_WAIT TCB, то SYN от клиента просто игнорируются.

Именно такая ситуация получается в связке Windows-сервер и Mac-client.

Далее начинается интересное.

В реализации стэков TCP/IP на разных ОС задается лимит максимального числа TIME_WAIT TCB, при достижении которого информация о старых соединениях заменяется новыми. Таким образом, если на сервере максимальное число TIME_WAIT TCB ниже максимального числа динамических клиенских портов на клиенте, то при большой частоте соединений не происходит игнорирования SYN и обрабатываются все соединения.

Это работает на серверах под Linux и BSD. Если в клиенте ограничить число клиенских портов, например, 10-ю, то при коннекте на сервер под любой ОС будут игнорироваться SYN и со стороны клиента это будет подвисон.

В BSD по умолчанию число TIME_WAIT TCB чуть более 1600 (в Linux не копался, но думаю аналогично) - что при дипазоне в 16000 портов на клиенте приводит к тому, что описанные глюки никогда не проявятся.

На Windows-сервере ситуация несколько странная. Какое-то время назад там был параметр MaxFreeTcbs, где задавалось нужное нам число, но долбое... мудозво... альтернативно умные из microsoft решили сделать такой же альтернативно умный TCP-стэк.

Из доступной документации понятно, что лимита на TIME_WAIT TCB в новом стеке нет - винда создает их столько сколько нужно - пока не закончатся порты у клиента. Поскольку это делается для каждого, то один клиент не лочит всю систему, но когда необходимы частые коннекты между двумя машинами, то получается именно эта неприятная ситуация - сервер не отвечает на любые запросы клиента, пока не устареют TIME_WAIT TCB.

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

Получается, что связка Windows-сервер и Mac-клиент функционирует в точном соответствии с тем, что описывает MS в свой документации. Правда в ситуации с маком при повторениях винда не сразу игнорит клиентские запросы, а начиная с третьего повторения.

Однако остается весьма интересный факт того, что Windows-сервер в комбинации с Linux- или BSD-клиентом не имеет такой проблемы. Да Windows-сервер создает число TIME_WAIT TCB равное числу портов на клиенте, но при повторении этих портов TIME_WAIT TCB каким-то образом используются повторно, т.е. сервер не игнорирует SYN, а всегда отвечает, несмотря на наличие в списке квадрипла для повторяющегося порта. Причем это работает даже если для чистоты эксперимента ограничить диапазон портов на клиенте до 10 шт.

Ну и еще остается загадка, почему физически другой Mac с другим IP не может подключиться к залоченному Windows-серверу - вероятно Windows воспринимает всем маки как одного клиента без различий по IP.

Получается, что BSD/Linux каким-то образом обманывают Windows так, что он не воспринимает их за тех же самых клиентов (несмотря на тот же IP).

Параметр же MaxFreeTcbs, сколько я ни крутил настройки, теперь не действует.

Тепеть задача заключается в том, чтобы либо заставить Windows каким-то образом ограничить число TW TCB - заставить работать параметр MaxFreeTcbs, если вообще его не вырезали намертво нехорошие дяди из редмонда. Либо настроить Mac таким образом, чтобы он обманывал Windows также, как это делают Linux/BSD.

Дампы пакетов здесь http://rapidshare.de/files/40842389/tcpdump.txt.html


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 06 ноя 2008, 12:48 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
Судя по дампу, SYN-пакеты из макосей имеют длинну на 4 байта больше чем SYN-пакеты из фряхи или дебаяна. Предполагаю,что грабля в этом SYN-пакете. Я бы покопал в 2-х направлениях: 1. В венде есть(?) хитровыделаная защита от DOS(syn-flood) - найти и обезвредить=) 2. Попытаться заставить макось отправлять SYN-пакеты меньшей длинны, вырезая лишние данные. Скорей всего дело даже не в длинне, а в содержании:

syn от макось
<mss 1460,nop,wscale 3,nop,nop,timestamp 140487914 0,sackOK,eol>
syn от фряхи
<mss 1460,nop,wscale 3,sackOK,timestamp 51241 0>
syn от дебаяна
<mss 1460,sackOK,timestamp 75621 0,nop,wscale 6>

Как говориться найдите 10 отличий=) В пакете от макоси присутствует опция eol(End of Options List) и 3 nop(No operation), тогда как в пакетах других ОС только 1 nop. Кроме этого, возможно, что еще имеет значение в каком порядке идут опции.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 07 ноя 2008, 00:58 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Очевидные отличия я уже проверял. Дело не в EOL или опциях. Я пробовал менять все, что можно поменять через sysctl в Mac OS - это в т.ч. убирало EOL и делало SYN пакет размером 40-44 байт вместо 60. Это не помогло.

Единственное отличие, которое нельзя исправить - в Mac OS X нет автоматической настройки окна, размер которого всегда одинаковый. В BSD/Linux окно подстраивается.

По крайней мере я не знаю есть ли способы как-то включить автотюнинг размера окна на маках.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 07 ноя 2008, 14:20 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
Блин. Утро вечера мудренее=)) Посмотрел еще раз дамп и узрел, чего вчера не видел. А соединение то рвет МАКОСЬ!

1. Макось отправляет SYN.(10.10.10.100.64791 > 10.10.10.3.8888: S)
2. Венда отвечает SYN/ACK(10.10.10.3.8888 > 10.10.10.100.64791: S)
3. Макось сбрасывает соединение RST.(10.10.10.100.64791 > 10.10.10.3.8888: R)

Т.е. получается что это макоси что-то не нравиться в ответе из венды и квитирование не завершается. Так что эт я, наверно, зря syn-пакет обидел...Эта картинка мне напомнила скрытое (stealth) TCP SYN сканирование (флаг -sS в сканере nmap). При этом типе сканирования картинка один в один совпадает с результатами дампа. Даже воспроизвел в своей сетке:

13:15:18.383156 IP 192.168.1.10.50316 > 192.168.1.9.22: S 3780959039:3780959039(0) win 4096 <mss 1460>
13:15:18.383487 IP 192.168.1.9.22 > 192.168.1.10.50316: S 4155143669:4155143669(0) ack 3780959040 win 5840 <mss 1460>
13:15:18.383537 IP 192.168.1.10.50316 > 192.168.1.9.22: R 3780959040:3780959040(0) win 0


Пака правда не знаю, что тебе это дает. Но информация к размышлению есть....


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 07 ноя 2008, 15:31 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Это в тигре старый ab там каким-то образом он открывает новое соединение в конце работы и сразу закрывает его - тоже не влияет :)


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 07 ноя 2008, 15:48 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
:D Так а где тогда дамп самого глюка? ну когда перестает соединять.


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 07 ноя 2008, 20:13 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
Это ковырял?
Цитата:
TcpMaxConnectRetransmissions
Раздел: Tcpip\Parameters
Тип параметра: REG_DWORD – число
Допустимые значения: 0 - 0xFFFFFFFF
По умолчанию: 2
Описание: этот параметр определяет количество запросов на подключение (SYN), передаваемых протоколом TCP, пока попытка не будет отменена. Таймаут повторной передачи удваивается после каждой последующей повторной передачи, выполняемой во время попытки подключения. Начальный таймаут равен трем секундам.

Источник

Правда это для ХП. Вот какой-то список для висты Думаю можно поковырять параметры: SynAttackProtect,TcpMaxConnectResponseRetransmissions,TcpMaxDataRetransmissions, TcpMaxHalfOpen, TcpMaxHalfOpenedRetried, TcpMaxPortsExhausted


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 08 ноя 2008, 04:53 
Интересующийся

У нас с: 22.08.2005
Сообщения: 50
Эти параметры для XP и на новых виндах не действуют. Да и в любом случае - они пригодились бы в случае, если бы были проблемы с Windows-клиентом, а здесь на винде сервер. Хотя по невнимательности чтения я их уже раньше пробовал - естественно, не помогли :)

Проблема возникает не из-за того, что используется тот же порт, а из-за того, что используется одинаковый tcp sequence number в сочатании с одинаковым портом. Когда порты одинаковы, но сиквенсы разные, как на BSD/Linux - все работает.

Вероятно, что в макоси проблемы с генераций сиквенс номеров. В BSD/Linux они инкрементируются, а в макоси рандомные используются и часто повторяются. Когда выпадает злополучная комбинация, сервер игнорит SYNы, а клиент соответственно надолго задумывается (на 30 секунд, пока TIME_WAIT на винде не умрет). Если сиквенс другой, а порт тот же, то TIME_WAIT TCB, если он есть на винде - реюзается и все работает хорошо.

Код:
16:38:17.956662 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1599284064 0,sackOK,eol>
16:38:17.956823 IP 10.10.10.3.8888 > 10.10.10.100.49152: S 2569049771:2569049771(0) ack 3152692866 win 8192 <mss 1460,nop,wscale 8,sackOK,timestamp 13724720 1599284064>
16:38:17.960649 IP 10.10.10.100.49152 > 10.10.10.3.8888: . ack 1 win 65535 <nop,nop,timestamp 1599284064 13724720>
16:38:18.097056 IP 10.10.10.100.49152 > 10.10.10.3.8888: P 1:3(2) ack 1 win 65535 <nop,nop,timestamp 1599284065 13724720>
16:38:18.097845 IP 10.10.10.3.8888 > 10.10.10.100.49152: P 1:112(111) ack 3 win 260 <nop,nop,timestamp 13724734 1599284065>
16:38:18.097848 IP 10.10.10.3.8888 > 10.10.10.100.49152: F 112:112(0) ack 3 win 260 <nop,nop,timestamp 13724734 1599284065>
16:38:18.099656 IP 10.10.10.100.49152 > 10.10.10.3.8888: . ack 113 win 65535 <nop,nop,timestamp 1599284065 13724734>
16:38:18.099665 IP 10.10.10.100.49152 > 10.10.10.3.8888: F 3:3(0) ack 113 win 65535 <nop,nop,timestamp 1599284065 13724734>
16:38:18.099667 IP 10.10.10.3.8888 > 10.10.10.100.49152: . ack 4 win 260 <nop,nop,timestamp 13724734 1599284065>

16:38:18.563446 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1599284066 0,sackOK,eol>
16:38:21.544625 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1599284071 0,sackOK,eol>
16:38:24.534756 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1599284077 0,sackOK,eol>
16:38:27.540565 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,sackOK,eol>
16:38:30.534526 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,sackOK,eol>
16:38:33.520506 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,sackOK,eol>
16:38:39.536765 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,sackOK,eol>

16:38:51.506068 IP 10.10.10.100.49152 > 10.10.10.3.8888: S 3152692865:3152692865(0) win 65535 <mss 1460,sackOK,eol>
16:38:51.506070 IP 10.10.10.3.8888 > 10.10.10.100.49152: S 2582101504:2582101504(0) ack 3152692866 win 8192 <mss 1460,nop,nop,sackOK>
16:38:51.512343 IP 10.10.10.100.49152 > 10.10.10.3.8888: . ack 1 win 65535
16:38:51.512344 IP 10.10.10.100.49152 > 10.10.10.3.8888: P 1:3(2) ack 1 win 65535
16:38:51.512344 IP 10.10.10.3.8888 > 10.10.10.100.49152: P 1:112(111) ack 3 win 64240
16:38:51.512345 IP 10.10.10.3.8888 > 10.10.10.100.49152: F 112:112(0) ack 3 win 64240
16:38:51.512346 IP 10.10.10.100.49152 > 10.10.10.3.8888: . ack 113 win 65535
16:38:51.514482 IP 10.10.10.100.49152 > 10.10.10.3.8888: F 3:3(0) ack 113 win 65535
16:38:51.514483 IP 10.10.10.3.8888 > 10.10.10.100.49152: . ack 4 win 64240


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: интересный глюк с сетью...
СообщениеДобавлено: 08 ноя 2008, 12:47 
Интересующийся

У нас с: 28.05.2008
Сообщения: 70
А 64 тысячи пакетов пробегают быстрее чем выходить TIME_WAIT?


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу 1, 2  След.


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
[ All resources are available under GNU GPL ] [ Support ] [ Hosted by DataHata | MyCloud.by ] [ Powered by phpBB® Forum Software © phpBB Group ]

LVEE Winter LVEE Rambler's Top100