День добрый.
Перед выходными серьёзно увеличили покрытие WIFI для предоставления Hotspot услуг.
Сегодня узнаю о том что в часы пик никто не мог подключиться. Пользователи набирали логин-пароль в web-интерфейсе, затем кликали ОК и после длительного ожидания браузер отваливался с ошибкой оо невозможности отобразить страницу.
в логах апача на протяжении двух пиковых часов:
[Sat Oct 4 21:00:41 2008] [error] [client 172.16.5.188] Premature end of script headers: /usr/local/apache/cgi-bin/utm5/card5
в /var/log/messages
Oct 4 20:45:29 new_account kernel: pid 52352 (card5), uid 80: exited on signal 11
через два часа, когда наплыв пользователей прошел,- нормальная работа восстановилась.
Понятно, что проще всего будет дождавшить очередного пика посмотреть во что упирается card5 по ресурсам, но такой пик возможет только в следующие выходные, а проблему хочется снять уже сейчас.
Думаю, что число активных хотспотов было в районе 500.
utm5-2.1.005
FreeBSD 7.0 i386
card5 умирает при большом количестве hotspot-клиентов
-
AntonLemon
- Сообщения: 55
- Зарегистрирован: Вт авг 16, 2005 11:29
-
AntonLemon
- Сообщения: 55
- Зарегистрирован: Вт авг 16, 2005 11:29
Данная проблема до сих пор не решена. Однако, её более детальное исследование выявило уязвимость в биллинге.
У нас имеется более 20 тысяч карточных пользователей. с подключенной услугой HOTSPOT
По технологии нетапа, Браузер каждого активного хотспот-юзера с заданной переодичностью (200сек) отправляет GETом строку в core о том что он ещё активен.
запрос:
GET /cgi-bin/utm5/card5?skey=08500149cc3f98e4d2b19913d0a406b6&cmd=refresh
Первым делом ядро оезет в базу проверять данный skey, а потом в не зависимости от результата поиска по базе, ядро начинает перестраивать внутри себя какие-то UTM5 DBA: Link. В логе это выглядит как
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 766
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 784
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 791
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 797
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 803
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 805
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 815
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 819
И так далее , пока всех 20 тыс карточных юзеров не просчитает.
Простая проверка на моём четырехядерном сервере биллинга показала, что в данной ситуации более чем 4 подобных запроса в секунду билинг не выдерживает, а значит предел количества пользователей висящих на билинге есть, и он довольно небольшой. Более того, случается, что когда сидит в онлайне 300-400 пользователей и вдруг у одного из них сглючивает бразузер, который начинает постоянно рефрешить страницу, то билинг падает незамедлительно.
Опять же, какой простор для denial-of-service attack, поскольку биллинг умирает даже при несуществующем skey
Уверен, что разработчикам нужно обязательно пересмотреть алгоритм действий ядра на рефреш хотспотовской страницы юзера.
У нас имеется более 20 тысяч карточных пользователей. с подключенной услугой HOTSPOT
По технологии нетапа, Браузер каждого активного хотспот-юзера с заданной переодичностью (200сек) отправляет GETом строку в core о том что он ещё активен.
запрос:
GET /cgi-bin/utm5/card5?skey=08500149cc3f98e4d2b19913d0a406b6&cmd=refresh
Первым делом ядро оезет в базу проверять данный skey, а потом в не зависимости от результата поиска по базе, ядро начинает перестраивать внутри себя какие-то UTM5 DBA: Link. В логе это выглядит как
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 766
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 784
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 791
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 797
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 803
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 805
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 815
?Debug : Oct 24 09:11:41 UTM5 DBA: Link: 819
И так далее , пока всех 20 тыс карточных юзеров не просчитает.
Простая проверка на моём четырехядерном сервере биллинга показала, что в данной ситуации более чем 4 подобных запроса в секунду билинг не выдерживает, а значит предел количества пользователей висящих на билинге есть, и он довольно небольшой. Более того, случается, что когда сидит в онлайне 300-400 пользователей и вдруг у одного из них сглючивает бразузер, который начинает постоянно рефрешить страницу, то билинг падает незамедлительно.
Опять же, какой простор для denial-of-service attack, поскольку биллинг умирает даже при несуществующем skey
Уверен, что разработчикам нужно обязательно пересмотреть алгоритм действий ядра на рефреш хотспотовской страницы юзера.
-
AntonLemon
- Сообщения: 55
- Зарегистрирован: Вт авг 16, 2005 11:29
Здравствуйте, коллеги. Я так понял в данной теме есть люди, у которых большое количество клиентов hotspot.
Хочу поинтересоваться, сталкивались с проблемой авторизации пользователей на android и ipad. На данных устройствах при переходе к другому приложению или вкладке закладка засыпает, и в результате через некоторое время пользователь отваливается от сети.
Если сталкивались и какое-то решение нашли, то очень прошу ответить. Если не нашли, тоже прошу отписаться, думаю это ускорит решение проблемы со стороны Netup.
Хочу поинтересоваться, сталкивались с проблемой авторизации пользователей на android и ipad. На данных устройствах при переходе к другому приложению или вкладке закладка засыпает, и в результате через некоторое время пользователь отваливается от сети.
Если сталкивались и какое-то решение нашли, то очень прошу ответить. Если не нашли, тоже прошу отписаться, думаю это ускорит решение проблемы со стороны Netup.