Структура/срез трафика

[fox_zi]

Добрый день.

 

Кто в последний раз делал и делал ли вообще срез трафика для анализа какой трафик преобладает? Принято считать, что 70-90% трафика у провайдера это торренты, скажу честно не верю :)

 

Сдаётся, что сейчас уже преобладает http трафик.

[n1k3]

А для чего? Подумываете о шейпере 7го уровня?

Edited December 7, 2009 by n1k3

[woddy]

зависит от контингента.

"в среднем по больнице" да.

[vadimus]

Недавно ради интереса запускал вечером ntop, там чуть больше 80% приходится действительно на http.

[fox_zi]

Ну например предложить новую услугу - http прокси! Пообещать скорость на 15% больше и резание банеров, защиту от вирусов :) Это уже дело маркетинга, как втюхать. Можно как отдельную услугу - прозрачный прокси :)

[networks]

Кому нафиг эти торренты сдались, щас все фильмы уже вконтакте смотрят :)

[micros]

Смотрят то смотрят, и продолжают качать. + пользователи становятся все грамотнее, об обменниках узнает все больше количество людей, у тех же контактов свой треккер есть, у онлайн игр в загрузчик уже давно встроен p2p и т.п.

Растет и этот трафик никак не медленнее чем http с его видео контентом

 

Так что словосочетание "сейчас уже преобладает" имхо - немного режет слух :0)

 

А профиль - он да, в каждой больнице свой. В принципе теоретически можно разделить по старому доброму 80% и 20%

[fox_zi]

Просто если будет 40-50% трафика и более http, ты смысл делать прокси как услугу, есть.

[micros]

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

А такую услугу хорошо продать - будет сложновато

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

 

Разве что, как бесплатную дополнительную фичу + возможность фильтрации контента (ака родительский контроль) можно сделать. + для юриков некоторых удобно фильтровать mp3 и прочий контент чтобы не качали - будет у вас доп услуга к тарифам.

 

Имхо

[2Garin]

Ага! И за содержание такого кеша можно попасть под статью :))))

[fox_zi]

Ага! И за содержание такого кеша можно попасть под статью :))))

с чего бы, если это не принудительно, а как дополнительный и бесплатный сервис?

[martin74]

а вдруг в нем cp найдется?

[2Garin]

Клиент полазил по порнушке, порно картинки в кешах на винте ;)

[networks]

Вот кстати, интересный вопрос :) Тут недавно проскакивала тема, насчет того чтобы операторам сэкономить трафик, покупают там сервер некий специальный, тоже видимо всячески кэширующий, а потом за каждый гиг сэкономленного трафика платят денюжку тем самым разработчикам. Так это чтож получается, разрабы операторов под статью подводят? Непорядок!

[micros]

Получается подводят... если конечно там кэш в чистом виде контент, а не хранится в своем хитром формате, тогда, думаю закосить пробовать можно.

 

Все же кэш как он есть удобен для юзера на помегабайтке (юрики) для анлимщиков -он таки нафиг ненужен, разве что оператору и то для сомнительной пользы

Edited December 8, 2009 by micros

[sid1333]

У нас как-то так (4 часа НН с 20:00 до 23:59):

                                  Общее,байт              HTTP,байт            Порты > 32768,байт
                                  1342662595673           419593858846         513626732764
Ср. скорость, Мбит/с              745,9                   233,1                285,3
% от скорости                     1                       31,25                38,25

Edited December 8, 2009 by sid1333

[fox_zi]

Не совсем уловил, где тут процент от общего?

[micros]

какже :) вам часть таблицы показали с 31% http и 38% предположительно порты обмена торрентами

[Alx65]

Примерно так. Катринка конца июня. Сейчас соотношения примерно те же.

входящий

Global_Bandwidth_per_Service_1_Mon_Jun_29_17_53_27_MSD_200931440.pdf

исходящий

Global_Bandwidth_per_Service_1_Mon_Jun_29_17_54_31_MSD_200931441.pdf