Подскажите, какое оптимальное количество пользователей можно "прикрыть" одним реальным ип адресом(NAT)?
> Подскажите, какое оптимальное количество пользователей можно "прикрыть" одним реальным
> ип адресом(NAT)?65535, если каждому давать открывать только одно соединение. ;)
Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера. НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать начнутся потери пакетов.
> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
> начнутся потери пакетов.... а так же зависит от реализации самого ната, ядреный может вытянуть немного больше,
а юзерский можно завести в нескольких экземлярах и нагружать все ведра/камни
>> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
>> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
>> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
>> начнутся потери пакетов.
> ... а так же зависит от реализации самого ната, ядреный может вытянуть
> немного больше,
> а юзерский можно завести в нескольких экземлярах и нагружать все ведра/камнихм - несколько юзерских на одном паблике? )
>>> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
>>> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
>>> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
>>> начнутся потери пакетов.
>> ... а так же зависит от реализации самого ната, ядреный может вытянуть
>> немного больше,
>> а юзерский можно завести в нескольких экземлярах и нагружать все ведра/камни
> хм - несколько юзерских на одном паблике? )молодец, поймал :)
если у паблик едиственный и больше взять неоткуда, то естественно говорить об экземплярах смысла нет
> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
> начнутся потери пакетов.Коллеги, каким образом кол-во пользователей, которое можно пронатить в один реальник, зависит от вычислительной мощности этой самой коробки?
Для примера.. Возьмем какой-нибудь селерон, 128 Mb оперативки и прогоним через него 400-500 kpps торрентов, и пронатим в один реальник. Теперь тоже самое, но пронатим в три реальника. Как вы думаете, существенная разница в том как себя будет чувствовать машинка, будет?
Я думаю - нет. Так что не надо путать мягкое с теплым.
Кол-во реальников нужно расчитывать исходя из реальных потребностей. Смотреть среднее кол-во соединений на один хост для которого выполняется нат и считать. Это если в общем.
>> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
>> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
>> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
>> начнутся потери пакетов.
> Коллеги, каким образом кол-во пользователей, которое можно пронатить в один реальник, зависит
> от вычислительной мощности этой самой коробки?под количеством пользователей обычно подразумевается пиковый pps
вы же правда не думаете, что любой (по производительности) компот может обработать сколь угодно большой pss?> Для примера.. Возьмем какой-нибудь селерон, 128 Mb оперативки и прогоним через него
> 400-500 kpps торрентов, и пронатим в один реальник. Теперь тоже самое,
> но пронатим в три реальника. Как вы думаете, существенная разница в
> том как себя будет чувствовать машинка, будет?поверьте, "машинке" пофиг :)
но если у вас на нате больше одного ядра, то вы можете поднять несколько юзерский натов и разделить весь поток на несколько ядер> Я думаю - нет. Так что не надо путать мягкое с теплым.
> Кол-во реальников нужно расчитывать исходя из реальных потребностей. Смотреть среднее
> кол-во соединений на один хост для которого выполняется нат и считать.
> Это если в общем.
>>> Ну вообще, в реальности это будет зависеть от выч. мощности твоего сервера.
>>> НАТиво довольно-таки процессороёмкая вещь, когда объём проходящих пакетов в секунду исчисляется
>>> двадцатками тысяч. :-) Смотри по графикам загрузки, когда сервер начнёт заливать
>>> начнутся потери пакетов.
>> Коллеги, каким образом кол-во пользователей, которое можно пронатить в один реальник, зависит
>> от вычислительной мощности этой самой коробки?
> под количеством пользователей обычно подразумевается пиковый pps
> вы же правда не думаете, что любой (по производительности) компот может обработать
> сколь угодно большой pss?Пиковый pps говорите(интересно, кто подразумевает?)... Но пусть даже так. Каким образом пиковый pps связан с количеством реальников на нате? Прикинем... У нас три пользователя - Вася, Петя и баб Маня. Баба Маня смотрит погоду и рецепты(10-20 коннектов в пике, ну пусть 200-300 pps), Вася любит одноглазников(пусть параметры будут те же), а Петя заядлый качек и вы вылазит с торрентов(200-300 коннектов, хз сколько pps и если еще и mTP, то xз*3 pps). И что нам дает суммирование pps, относительно кол-ва реальников на которых мы это будем натить? Да ничего ровным счетом. Кроме необходимой производительности тазика. Ага, только как это связано с кол-вом реальников? Суммирование кол-ва коннектов, да, дает, ибо речь таки идет о NAPT. А пример я привел для того, что иллюстрировать тот факт, что вопрос был о кол-ве -пользователей-, которых можно пронатить в один реальник, а никак не о производительности. Кстати, я пользователей считаю в хостах. А вы в pps?!? А почему не в попугаях? :)
>> Для примера.. Возьмем какой-нибудь селерон, 128 Mb оперативки и прогоним через него
>> 400-500 kpps торрентов, и пронатим в один реальник. Теперь тоже самое,
>> но пронатим в три реальника. Как вы думаете, существенная разница в
>> том как себя будет чувствовать машинка, будет?
> поверьте, "машинке" пофиг :)Поверьте, машинке не пофиг. 400-500 это не суммарный kpps, а только в одном направлении на одном интерфейсе.
> но если у вас на нате больше одного ядра, то вы можете
> поднять несколько юзерский натов и разделить весь поток на несколько ядерЮзерский NAT это похоже что-то из терминологии xBSD. Я же пытаюсь оперировать независимыми понятиями. Да ТС не указал что у него на тазике.
>> Я думаю - нет. Так что не надо путать мягкое с теплым.
>> Кол-во реальников нужно расчитывать исходя из реальных потребностей. Смотреть среднее
>> кол-во соединений на один хост для которого выполняется нат и считать.
>> Это если в общем.
>[оверквотинг удален]
> Поверьте, машинке не пофиг. 400-500 это не суммарный kpps, а только в
> одном направлении на одном интерфейсе.
>> но если у вас на нате больше одного ядра, то вы можете
>> поднять несколько юзерский натов и разделить весь поток на несколько ядер
> Юзерский NAT это похоже что-то из терминологии xBSD. Я же пытаюсь оперировать
> независимыми понятиями. Да ТС не указал что у него на тазике.
>>> Я думаю - нет. Так что не надо путать мягкое с теплым.
>>> Кол-во реальников нужно расчитывать исходя из реальных потребностей. Смотреть среднее
>>> кол-во соединений на один хост для которого выполняется нат и считать.
>>> Это если в общем.давайте уже закончим
я с трудом понимаю ваш ход мысли
>Кстати, я пользователей считаю в хостах. А вы в pps?!? А почему не в попугаях? :)Провайдеры, как правило, на своих точках доступа чисто технически считают пользователей в pps :-)) Потому, что так можно контролировать загрузку железа, зачем держать в уме сколько конкретно рабочих станций ты обслуживаешь лично мне реально не понятно, так как трафик ими генерируемый слабо коррелирует с их количеством.
А вообще мой пост был к тому, что скорее железо устанет, чем ТС достигнет лимита пользователей и ориентироваться ему нужно всё же не на теоретический предел, а на производительность сервера, который у него в распоряжении.
>>Кстати, я пользователей считаю в хостах. А вы в pps?!? А почему не в попугаях? :)
> Провайдеры, как правило, на своих точках доступа чисто технически считают пользователей
> в pps :-)) Потому, что так можно контролировать загрузку железа, зачем
> держать в уме сколько конкретно рабочих станций ты обслуживаешь лично мне
> реально не понятно, так как трафик ими генерируемый слабо коррелирует с
> их количеством.Я неправильный провайдер. Считаю пользователей в хостах, потому как pps и кол-во пользователей, тоже величины между собой корелирующие очень слабо(как раз я приводил пример про бабу Маню и её друзей) :) А трафик, да, в pps.
> А вообще мой пост был к тому, что скорее железо устанет, чем
> ТС достигнет лимита пользователей и ориентироваться ему нужно всё же не
> на теоретический предел, а на производительность сервера, который у него в
> распоряжении.
> Подскажите, какое оптимальное количество пользователей можно "прикрыть" одним реальным
> ип адресом(NAT)?Ну могу рассказать на нашем примере. Два канала по 10Мбит 500 пользователей. Железка - Zyxel Z70 (Linux, 32Мб Озу).
>> Подскажите, какое оптимальное количество пользователей можно "прикрыть" одним реальным
>> ип адресом(NAT)?На ЛОРе ответили (очень похоже на правду)
> При количестве одновременных соединений более шестидесяти тысяч, на внешнем адресе перестанет хватать портов.Ничего подобного. Один и тот же порт может быть использован при соединении к разным хостам. Вот кол-во соединений с одного хоста на ОДИН порт действительно ограничено.
И
> А вот целое государство на одном айпишнике(или сетке, непонятно): http://sterlegrad.ru/world/238-wikipedia-zabanila-celoe-gosu...:) жесть