>Для IPSec единственным правильным решением является создание независимых туннелей на независимых устройствах, желательно по независимым каналам связи
вот и я этого не понял :) проще сделать несколько независимых туннелей, а поверх сделать какой-нибудь IGP с быстрой сходимостью.
результат будет тот же, но без вот этого болезненного прикручивания HA к IPSEC.
>ну у вас будет просто две независимых ppp-сессии, вот и все.
так там будут разные адреса и failover будет означать разрыв всех сессий.
>Защититься мы пытаемся от выхода из строя одной из железок
события маловероятные, имхо. гораздо более реалистичны проблемы по питанию, а это требует двух БП и желательно наличие двух вводов.
>либо от нарушения связности с одним из устройств
тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь? :)))
если железки стоят в одной(или соседних) стойке — тут тоже масса проблем.
вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
И потом не жалуйтесь, что ролик с ютуба надо подождать, пока закешируется
это бизнес, ничего личного. клиент выберет где лучше и дешевле.
ну и локальные кеши(вроде google global cache) решают проблемы для популярного контента.
а живой поток совсем сыпется.
с чего бы вдруг раздача файликов по http будет «сыпаться»? речь ведь про OTT, где используется HLS/DASH и клиент может делать prefetch(понятно, что с live это не получится, но и это решаемо).
Я живу в поселке в пятиэтажке в 6 км от миллионника
я живу в пригороде СПб, в 20км от города. в пятиэтажках по 4-5 провайдеров, тарифы от 25Мбит/с, чаще — 50-100Мбит/с.
в ряде городов по ADSL (Киров например) подключают до сих пор
и что? вот даже сейчас я снова могу подключиться по ADSL, но от этого сама технология не перестанет быть legacy.
Возможно вы просто далеки от темы связи и провайдеров?
я несколько лет был сотрудником ISP, потом один маленький сотовый оператор из большой тройки.
теперь вот смотрю на всех со стороны компании, предоставляющей OTT.
да, я понимаю, что для оператора мультикаст удобнее, т.к. меньше грузит сеть итп.
но для клиента он неудобен и как только начинаем вещать в hd — сразу всё становится грустно(из-за возросшего битрейта и требований к качеству сети по джиттеру/потерям).
да, есть костыли, когда клиентское устройство держит tcp-коннект с сервером и в случае дропов запрашивает потерянное по tcp. но это всё вендор-специфично и мало где поддерживается.
плюс, на доступе используют далеко не самое лучшее управляемое железо в котором igmp работает… нуу… вообщем как-то работает :)
выливается это в медленное переключение каналов или же непереключение вообще(про мелочи, когда igmp leave мы потеряли и клиенту продолжает сыпаться на порт старая подписка вообще молчу).
при этом, надо не забывать, что мультикаст — это только live. как только появляется VOD/NPVR и абоненты осваивают эту услугу, плюсы мультикаста уходят со сцены.
если же речь про dvb — это надо отдельный кабель. если у клиента новая квартира или просто новый ремонт с идеей прокладки кабеля ваш пошлют крайне далеко.
а с OTT в этом плане проще: если smarttv, то wifi в телевизоре уже есть. если hdmi-stick — там тоже есть wifi.
не один. и что? какая разница — смотрю я youtube или же пользуюсь каким-либо интернет-сервисом с видео?
В Москве может быть и да. А на територии нашей всеобъятной родины уходить особо некуда
конкуренция есть всегда. опять же, для sd-качества полоса нужна скромная.
Последние лет 10 про это говорят. Только все никак не получается.
ну вот одепты фиксы тоже говорят что «живее всех живых», но людей, которые ей пользуются становится всё меньше.
фикса сейчас — этот legacy. с развитием lte и голос в мобильных сетях тоже станет legacy.
>Мое мнение — к IPTV сегодня массовый пользователь пока не готов. Как и массовый оператор.
прекрасно. чем больше операторов так будет думать — тем лучше :)
потому что им потом будет сложнее догонять проекты вроде megafon.tv или spbtv и больше тратиться на расширение внешних каналов.
зритель хочет смотреть любимые передачи _когда ему удобно_, а не когда её поставили в сетку вещания.
вот и я этого не понял :) проще сделать несколько независимых туннелей, а поверх сделать какой-нибудь IGP с быстрой сходимостью.
результат будет тот же, но без вот этого болезненного прикручивания HA к IPSEC.
так там будут разные адреса и failover будет означать разрыв всех сессий.
>Защититься мы пытаемся от выхода из строя одной из железок
события маловероятные, имхо. гораздо более реалистичны проблемы по питанию, а это требует двух БП и желательно наличие двух вводов.
>либо от нарушения связности с одним из устройств
тогда и свитчи надо резервировать, и опять же — вопросы питания. а так — srx стоят рядом и требуют линка между ними(который тоже надо будет резервировать ведь? :)))
если железки стоят в одной(или соседних) стойке — тут тоже масса проблем.
вообщем, я о том, что честное резервирование подразумевает неслабые вложения в инфраструктуру и вот просто пара железок мало чем помогут. да и ту же задачу можно решить куда более дешевыми способами :)
а кластером мы от какой беды пытаемся защититься?
это бизнес, ничего личного. клиент выберет где лучше и дешевле.
ну и локальные кеши(вроде google global cache) решают проблемы для популярного контента.
а живой поток совсем сыпется.
с чего бы вдруг раздача файликов по http будет «сыпаться»? речь ведь про OTT, где используется HLS/DASH и клиент может делать prefetch(понятно, что с live это не получится, но и это решаемо).
Я живу в поселке в пятиэтажке в 6 км от миллионника
я живу в пригороде СПб, в 20км от города. в пятиэтажках по 4-5 провайдеров, тарифы от 25Мбит/с, чаще — 50-100Мбит/с.
в ряде городов по ADSL (Киров например) подключают до сих пор
и что? вот даже сейчас я снова могу подключиться по ADSL, но от этого сама технология не перестанет быть legacy.
Возможно вы просто далеки от темы связи и провайдеров?
я несколько лет был сотрудником ISP, потом один маленький сотовый оператор из большой тройки.
теперь вот смотрю на всех со стороны компании, предоставляющей OTT.
да, я понимаю, что для оператора мультикаст удобнее, т.к. меньше грузит сеть итп.
но для клиента он неудобен и как только начинаем вещать в hd — сразу всё становится грустно(из-за возросшего битрейта и требований к качеству сети по джиттеру/потерям).
да, есть костыли, когда клиентское устройство держит tcp-коннект с сервером и в случае дропов запрашивает потерянное по tcp. но это всё вендор-специфично и мало где поддерживается.
плюс, на доступе используют далеко не самое лучшее управляемое железо в котором igmp работает… нуу… вообщем как-то работает :)
выливается это в медленное переключение каналов или же непереключение вообще(про мелочи, когда igmp leave мы потеряли и клиенту продолжает сыпаться на порт старая подписка вообще молчу).
при этом, надо не забывать, что мультикаст — это только live. как только появляется VOD/NPVR и абоненты осваивают эту услугу, плюсы мультикаста уходят со сцены.
если же речь про dvb — это надо отдельный кабель. если у клиента новая квартира или просто новый ремонт с идеей прокладки кабеля ваш пошлют крайне далеко.
а с OTT в этом плане проще: если smarttv, то wifi в телевизоре уже есть. если hdmi-stick — там тоже есть wifi.
не один. и что? какая разница — смотрю я youtube или же пользуюсь каким-либо интернет-сервисом с видео?
В Москве может быть и да. А на територии нашей всеобъятной родины уходить особо некуда
конкуренция есть всегда. опять же, для sd-качества полоса нужна скромная.
Последние лет 10 про это говорят. Только все никак не получается.
ну вот одепты фиксы тоже говорят что «живее всех живых», но людей, которые ей пользуются становится всё меньше.
фикса сейчас — этот legacy. с развитием lte и голос в мобильных сетях тоже станет legacy.
никто не декодирует видео силами cpu. даже на rk3188, который Quad-core Cortex-A9.
>Мультимедиа чипы от broadcom китайцам в руки до сих пор не дают.
на бродакоме свет клином не сошелся. есть вышеупомянутый rockchip или же sigma designs.
>В довесок ко всему отсутствие нативного софта для проигрывания iptv.
что именно вы подразумеваете под iptv?
sd-каналы с вполне нормальным качеством укладываются в 2-3мбит/с.
мультикаст клиенту неудобен(потому что плохо проходит через wifi), а dvb-c — потому что требует тянуть кабель.
>Или может быть вы добавите 12-15 тр, ну чтоб соседей не трогать?
клиент просто проголусует ногами и уйдет туда, где это будет.
вообщем-то у операторов путь либо в triple play, либо стать тупой data pipe.
прекрасно. чем больше операторов так будет думать — тем лучше :)
потому что им потом будет сложнее догонять проекты вроде megafon.tv или spbtv и больше тратиться на расширение внешних каналов.
зритель хочет смотреть любимые передачи _когда ему удобно_, а не когда её поставили в сетку вещания.
php-fpm — это вполне себе prefork-сервер: по процессу на запрос. кроме того, умеет спавнить воркеров on demand.
потому что без ключа -a ifconfig покатывает только то что в UP.
не совсем. витую пару без физического доступа сложно сделать неработоспособной, в отличие от wifi-сети.
на свежую голову пришёл более правдоподобный вариант: spdy — бинарный, а http — текстовый.