Какая скорость интернета нужна для просмотра IPTV и как улучшить показатели


Благодаря появлению технологии Smart TV телевизор получил широкие возможности по обеспечению различных мультимедийных и интерактивных функций для своих пользователей. Поэтому, при покупке устройства со Смарт ТВ мы рассчитываем на качественное и беспроблемное использование его возможностей.

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

Помочь разобраться с вопросом, какая скорость интернета нужна для Смарт ТВ, от чего она зависит и какие существуют способы её увеличения и призвана наша статья.

Какая скорость интернета нужна для просмотра IPTV

IPTV – это технология, рассчитанная на стабильный, высокоскоростной обмен данными в сети. Иначе четкой картинки, детализации, быстрой смены планов не видать. Будут проблемы с буферизацией, ролики станут подтормаживать. Если не углубляться в нюансы разрешения, частоты обновления кадров трансляции, то можно исходить из запросов потокового видео, установленных разработчиками.

Данные представлены в таблице:

Скорость, Мб/сКомментарий
До 2Не подходит. Проблемы с загрузкой, обновлением страниц (особенно с медиа-контентом).
До 7Минимально допустимый предел. Уже можно смотреть видео, но пока только в определенном качестве.
От 7 до 14Просмотр Full HD без ограничений. Для трансляций в формате 2K высока вероятность затрудненной буферизации.
От 14 до 45Подходит для видео со стандартным обновлением экрана (30 fps). Доступны любые форматы с данным показателем.
До 100Можно смотреть все без ограничений. Включая ролики высокого разрешения 4К с частотой смены кадров до 60 fps.

Остается определить, что предлагает ваш поставщик интернет услуг (и тарифный план), а также, какие по параметрам трансляции вы собираетесь смотреть.

Параметры, влияющие на скорость передачи данных

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

Когда подключение устройства осуществляется по медной линии или оптоволоконному кабелю, совершенно другие факторы начинают влиять на качество соединения.

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

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

Как увеличить скорость интернет-соединения

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

Для стабилизации, увеличения скорости обмена данных можно сделать следующее:

  1. Проверить тип соединения. Wi-Fi прогнозируемо «срезает» до 30 %. Если есть техническая возможность, лучше переключиться на кабель.
  2. Проверить количество абонентов (устройств), присутствующих в сети. Тех, кто в данный момент качает ролики, просматривает видео.
  3. Убедиться, что оборудование (роутер, ПК, Смарт ТВ) поддерживает работу с IPTV-вещанием, его параметрами.
  4. Изменить тариф на производительный.

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

Сколько Мбит / с мне нужно для потоковой передачи?

Clark.com проверил YouTube TV, Hulu + Live TV, Sling TV, AT&T TV Now, fuboTV и других поставщиков потокового вещания, чтобы узнать минимальную рекомендуемую скорость загрузки для каждой службы.

Мы узнали, что магическое число обычно находится в районе 10 Мбит / с (мегабит в секунду):

Службы потокового вещания в прямом эфире

  • AT&T TV Now : скорость не менее 12 Мбит / с на поток обеспечивает наилучшее качество
  • Frndly TV : 5 Мбит / с для одного потока HD и 1,5 Мбит / с для одного потока SD
  • fuboTV : от 3 до 25 Мбит / с в зависимости от разрешения
  • Hulu + Live TV : 8 Мбит / с или выше для надежного и высококачественного просмотра; несколько одновременных потоков могут потребовать более высокой пропускной способности
  • Philo : 3 Мбит / с для качества SD, 7 Мбит / с для одного потока HD и 13 Мбит / с для надежной потоковой передачи HD с несколькими потоками
  • Sling TV : 5 Мбит / с для одного потока видеоконтента на телевизоре, ПК или Mac; 25 Мбит / с для домашних хозяйств, которые используют Интернет на нескольких устройствах
  • YouTube TV : 3 Мбит / с для качества SD, 7 Мбит / с для одного потока HD и 13 Мбит / с для надежной потоковой передачи HD с несколькими потоками

Другие сервисы потокового видео

  • Amazon Prime Video : 3 Мбит / с для качества SD, 5 Мбит / с для качества HD и 25 Мбит / с для качества Ultra HD
  • Disney + : 5 Мбит / с для контента HD и 25 Мбит / с для контента 4K UHD
  • HBO Max: минимальная скорость загрузки 5 Мбит / с.
  • Hulu : 1,5 Мбит / с для потоковой передачи SD-видео и 3 Мбит / с или выше для HD-видео
  • Netflix : 3 Мбит / с для качества SD, 5 Мбит / с для качества HD и 25 Мбит / с для качества Ultra HD
  • Павлин: не менее 2,5 Мбит / с для одного потока

Как улучшить скорость подключения к сети

Если проблема не решена, то, возможно, следует искать другие способы. Например, пообщаться с менеджерами телекоммуникационной компании, чтобы выяснить, в чем причина разрыва соединения. Также не будет лишним проверить настройки ПК, телеприемника, смартфона, на которых осуществляется просмотр. Возможно, проблема скрывается в них.

В случае с ПК или ноутбуком не помешает выполнить проверку на наличие вредоносных программ. Даже устаревшие вирусные базы влияют на скорость интернета. При беспроводном подключении следует выбрать зону наилучшего покрытия. Это делают вручную, перемещаясь по комнате или с помощью специального ПО.

И помните! Чудеса случаются, но редко. Если телевизор технически не поддерживает потоковое видео высокого разрешения, то не помогут ни новый тарифный план, ни скоростной интернет.

Почему заявленная провайдером скорость не совпадает с фактической

Провайдеры указывают в договоре максимальную скорость интернета. Если у вас подключение по медному кабелю, то скорость Интернета будет до 100 Мбит/с. Также возможен вариант подключения по оптоволокну, тогда скорость может достигать 1 Гбит/с. Причиной низкой скорости может быть подключение между оборудованием провайдера и вашим ТВ, а иногда и старый роутер, или сетевая карта ПК/ ноутбука. На сайте Speedcheck есть подробное руководство, которое поможет вам найти и устранить вероятные проблемы с подключением.

Multicast routing для IPTV

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался. Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

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

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Введение

Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.
Первым делом озвучим несколько понятий, чтоб исключить дальнейшие недопонимания. Существует три вида трафика:

  • unicast — одноадресный, один источник потока один получатель
  • broadcast — широковещательный, один источник, получатели все клиенты в сети
  • multicast — многоадресный, один отправитель, получатели некоторая группа клиентов

Какой вид трафика использовать для IPTV?

unicastbroadcastmulticast
Особенности применительно к IPTVполучаем дублирование трафика, для каждого абонента создается свой потокклиентское оборудование вынуждено обрабатывать весь поток каналов, который может быть совсем не несколько килобитабонент получает только тот поток, который запрашивает


Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast. Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.

Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).

Немного о том, как работает IGMP.

Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:

224.12.0.1канал 1News
224.12.0.2канал 2History
224.12.0.3канал 3Animals

Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.

Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.

MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.

Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.

Настройка multicast routing.

Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.

Пример настройки роутеров MR1 и MR2.

Network A10.1.0.0/24
Network B10.2.0.0/24
Network C10.3.0.0/24

MR1MR2
MR1#sh run
ip multicast-routing ! interface Ethernet 0 description Multicast Source ip address 10.0.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 1 description Network A ip address 10.1.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 2 description Network B ip address 10.2.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 3 description Link to MR2 ip address 10.10.10.1 255.255.255.0 ip pim sparse-mode ! ip pim rp-address 10.0.0.2 IPTV override ! ip access-list standard IPTV permit 224.11.0.0 0.0.0.3
MR2#sh run
ip multicast-routing ! interface Ethernet 0 description Link to MR1 ip address 10.10.10.2 255.255.255.0 ip pim sparse-mode ! interface Ethernet 1 description Network C ip address 10.3.0.1 255.255.255.0 ip pim sparse-mode ! ip pim rp-address 10.0.0.2 IPTV override ! ip access-list standard IPTV permit 224.11.0.0 0.0.0.3 ! ip route 10.0.0.0 255.255.255.0 10.10.10.1

Команда «ip multicast-routing» включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.
Остановимся чуть поподробнее на команде «ip pim sparse-mode».

Про режимы протокола PIM и сам протокол.

PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений. У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.
В нашей конфигурации на интерфейсах мы указали режим «ip pim sparse-mode».

(config-if)# ip pim?

dense-mode Enable PIM dense-mode operation sparse-dense-mode Enable PIM sparse-dense-mode operation sparse-mode Enable PIM sparse-mode operation ………

В чем же разница?

PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.
PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.

Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.

Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.

Между PIM-DM и PIM-SM существуют еще отличия. PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.

У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).

Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — «*» символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.

Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.

Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):

ip pim rp-address 10.0.0.1 IPTV overrideуказываем адрес RP и access-list IPTV access-list определяет какие группы
ip access-list standard IPTVрегистрироваться на данной точке рандеву
permit 224.11.0.0 0.0.0.3

Все остальные роутеры должны знать маршрут до RP: ip route 10.0.0.0 255.255.255.0 10.10.10.1

Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?

Посмотрим, что будет происходить после настройки роутеров.

Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения
Для MR1: %PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3

Для MR2: %PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0

Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:

MR1#sh ip pim neighbor

PIM Neighbor Table Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable

Neighbor AddressInterfaceUptime/ExpiresVerDR Prio/Mode
10.10.10.2Ethernet300:03:05/00:01:37v21 / DR S

Не забываем про TTL.

В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.
Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.

Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.

MR2#sh ip traffic

IP statistics: Rcvd: 36788 total, 433 local destination 0 format errors, 0 checksum errors, 2363 bad hop count ……………………………………

Если этот счетчик быстро увеличивается, значит — проблема в TTL.

Show ip mroute

После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:
MR1# sh ip mroute

(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP Incoming interface: NULL, RPF nbr 0.0.0.0 Outgoing interface list: NULL

(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: NULL

(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP Incoming interface: NULL, RPF nbr 0.0.0.0 Outgoing interface list: NULL

(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: NULL

(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP Incoming interface: NULL, RPF nbr 0.0.0.0 Outgoing interface list: NULL

(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: NULL

Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.

Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:

MR1#sh ip mroute

………………… (*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S Incoming interface: NULL, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3, Forward/Sparse, 00:02:37/00:02:53

(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3, Forward/Sparse, 00:02:37/00:02:53

Стало видно, что приходят запросы на эту группу с порта Ethernet3.

RPF проверка

Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?
Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.

Отследить, как источник проходит проверку RPF можно с помощью команды:

MR2#sh ip rpf ? Hostname or A.B.C.D IP name or address of multicast source

MR2#sh ip rpf 10.0.0.2

RPF information for? (10.0.0.2) RPF interface: Ethernet0 RPF neighbor:? (10.10.10.1) RPF route/mask: 10.0.0.0/24 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables

Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)

UPD: Разрешите представить ее. Елена Сахно — lena_sakhno

Рейтинг
( 1 оценка, среднее 5 из 5 )
Понравилась статья? Поделиться с друзьями:
Для любых предложений по сайту: [email protected]