Рейтинг онлайн-кинотеатров для Камчатки: результаты личного эксперимента

Я провёл небольшое исследование, чтобы выяснить, в каких онлайн-кинотеатрах лучше всего смотреть фильмы на Камчатке. Для этого я оформил бесплатные пробные подписки в основных сервисах и проверил качество их работы. Методика была следующей: я запускал просмотр и в консоли разработчика браузера смотрел, с какого раздающего сервера приходит ссылка. Для каждого из этих серверов с помощью команды ping (с опцией -c 50) проверял RTT и TTFB (time to first byte, то есть время от отправки запроса до получения первого байта от сервера).

Эти метрики показались мне наиболее объективными для сравнения, поскольку тесты на скорость загрузки контента могут отличаться из-за разной длины сегментов. При этом, TTFB я проверял только после того, как убеждался, что сегмент отдаётся из кэша (HIT), чтобы получились максимально чистые результаты. Для TTFB брал от 10 до 15 значений и считал среднее. Все данные сведены в таблицу.

Наблюдения:

• Wink использует CDN Ngenx и, судя по всему, не имеет собственной сети доставки контента

• RuTube и Premier работают через один и тот же CDN

• VK Видео использует CDN «Одноклассников»

• Интересно, что у Premier и RuTube, при использовании одного CDN, показатели TTFB существенно различаются. Я провел тесты несколько раз, ничего не меняется. Вероятно, раздача идёт с серверов разной «мощности».

• Если судить по RTT и TTFB, то наилучшие показатели у Okko, Кинопоиска, IVI и Kion.

• Судя по именам узлов, у Okko и Кинопоиска есть кэш-серверы в Хабаровске, а у Kion во Владивостоке. IVI использует Anycast, поэтому точное географическое положение их узлов определить невозможно, но думаю они также в Хабаровске и/или Владике. У остальных сервисов, скорее всего, все узлы расположены в Москве

Чем меньше RTT и TTFB, тем ниже вероятность буферизации и подвисаний при просмотре. Однако, это технические метрики, отражающие работу инфраструктуры. Многие проблемы для конечного пользователя могут быть скомпенсированы самим видеоплеером, его настройками адаптивного битрейта (ABR) и алгоритмами предзагрузки сегментов. Но у тех сервисов, у которых высокий RTT и TTFB реально ощутимо дольше стартует просмотр и бывают зависания в процессе, но полноценный просмотр уже проверял не у всех.

Выводы: буду доверять техническим метрикам и смотреть Okko 😅

UPD: В комментах подсказали, как определить конкретную ноду у IVI - https://region.dfs.ivi.ru/ (Хабаровск)

🎤 Будни сетевика 😊

Как у вас началась рабочая неделя?

У меня она началась с новости о том, что ровно через неделю, 17 ноября, я буду выступать на Пиринговом форуме 2025.

Секция «Архитектура бесшовного опыта: от кэша до глобальной маршрутизации» обещает быть очень интересной!

Для тех, кто будет на форуме, буду рад обсудить что-нибудь или просто пообщаться.

🎤 Будни сетевика 😊

Обновляли джуны в проде по CVE.

Помимо основных платформ MX и QFX у нас есть совсем немного EX3400, но с ними не все так просто.

The Juniper EX3400 switch series is a decent access switch. But a Product Manager chose to save $0.50 on COGS by choosing a 2GB disk. That’s just not enough space to handle normal Junos upgrades. This has wasted untold engineer hours on busywork. I hope that person (A) got a bonus, and (B) is never allowed to under-spec hardware again.

Проверил, как обстоят дела на других моделях, на скрине вывод команды show system storage.

🎤 Будни сетевика 😊

Ingress NGINX Retirement: What You Need to Know

In March 2026, Ingress NGINX maintenance will be halted, and the project will be retired. After that time, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. The GitHub repositories will be made read-only and left available for reference.

Existing deployments of Ingress NGINX will not be broken. Existing project artifacts such as Helm charts and container images will remain available.

UPD: В комментах подсказали, что есть два Nginx Ingress:

1. От самого Kubernetes - https://github.com/kubernetes/ingress-nginx/
2. От F5/Nginx - https://github.com/nginx/kubernetes-ingress/

Речь в статье про первый.

🎤 Будни сетевика 😊

Дефолтный ARP-полисер на Juniper MX

Несколько лет назад мы в течение довольно долгого времени пытались найти причину флапов BFD на маршрутизаторах Juniper MX. Проблема была плавающая и ни с чем не коррелировала, возникала на обоих маршрутизаторах в паре в двух разных дата-центрах. В какой-то момент уже дошли до диагностики QSFP-модулей, потому что как раз в это время начали использовать новые модули от другого поставщика 😅

В итоге, все оказалось гораздо проще. У Juniper есть дефолтный ARP-полисер, который ограничен в 150 kb/s.

Вот он «красавчик», показывает дропы:

jun_mx> show policer default_arp_policer
Policers:
Name Bytes Packets
default_arp_policer 22695791183 493445894

Этот полисер применяется по умолчанию ко ВСЕМ интерфейсам:

Logical interface irb.50
Policer: Input: __default_arp_policer__
Logical interface irb.51
Policer: Input: __default_arp_policer__
Logical interface irb.100
Policer: Input: __default_arp_policer__
Logical interface irb.777
Policer: Input: __default_arp_policer__
Logical interface irb.778
Policer: Input: __default_arp_policer__
…
и тд

Решением было создать кастомный ARP-полисер:

set firewall policer okko_arp_policer if-exceeding bandwidth-limit 2m

set firewall policer okko_arp_policer if-exceeding burst-size-limit 1m

set firewall policer okko_arp_policer then discard

И применить его на все интерфейсы:

set interfaces irb unit 50 family inet policer arp okko_arp_policer

set interfaces irb unit 51 family inet policer arp okko_arp_policer

set interfaces irb unit 100 family inet policer arp okko_arp_policer

set interfaces irb unit 777 family inet policer arp okko_arp_policer

set interfaces irb unit 778 family inet policer arp okko_arp_policer
…
и тд

После этого на каждом интерфейсе будет использоваться СВОЙ ARP-полисер, а не общий дефолтный:

jun_mx> show policer
Policers:
Name Bytes Packets
__default_arp_policer__ 0 0
okko_arp_policer-irb.50-inet-arp 0 0
okko_arp_policer-irb.51-inet-arp 0 0
okko_arp_policer-irb.100-inet-arp 0 0
okko_arp_policer-irb.777-inet-arp 0 0
okko_arp_policer-irb.778-inet-arp 0 0

🎤 Будни сетевика 😊

Задача: Запустить goBGP в Docker-контейнере без прав суперпользователя и установить BGP-сессию с реальным сетевым оборудованием.

Нет root, потому что безопасность, что в целом является стандартной практикой.

Определимся с терминологией:

Хост - сервер или виртуальная машина, на которой работает контейнер.

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

BGP использует 179-й порт, который является привилегированным (менее 1024), и для его использования без прав суперпользователя не обойтись. Но у нас нет необходимости принимать соединения на 179-м порту, достаточно, чтобы goBGP сам мог инициировать сессию. В goBGP есть параметр для этого:

ListenPort: -1, // не слушать tcp:179

Для установления BGP-сессии будет использоваться динамический порт, который нужно как-то передать на хост из контейнера. Самый простой вариант - запустить контейнер с network_mode: host, что позволяет контейнеру напрямую использовать сетевой стек хоста. В режиме host сетевой стек контейнера не изолирован от хоста, т.е. если контейнер привязывается к какому-либо порту (в нашем случае к порту, с которого устанавливается BGP-сессия), то этот же порт будет открыт на хосте. EXPOSE в Dockerfile делать не нужно.

Настраиваем пиров и проверяем, что BGP-сессия установилась!

Проверяем, что внутри контейнера нет открытого порта 179:

# netstat -lntup | grep $(docker inspect 4c39c56c2f7e --format='{{.State.Pid}}')

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2497377/service
tcp 0 0 0.0.0.0:7854 0.0.0.0:* LISTEN 2497377/service
udp 0 0 0.0.0.0:2055 0.0.0.0:* 2497377/service

Проверяем на хосте:

# netstat -lntup | grep 179
#

Порт 179 никто не слушает - так и должно быть. Без прав root не получится занять порт ниже 1024.

Посмотрим все соединения в системе на хосте, связанные с портом 179:

# lsof -i :179
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
service-na 2497377 user 14u IPv4 100373363 0t0 TCP service_name:48155->_gateway:bgp (ESTABLISHED)

В выводе видно, что процесс с PID 2497377 установил исходящее соединение на порт 179, а локально он использует случайный порт 48155, то есть goBGP выступает в роли BGP-клиента.

Если по каким-то причинам нужно внутри контейнера (без прав root) слушать 179-й порт и принимать входящие соединения, придется использовать Linux capabilities:

RUN setcap 'cap_net_bind_service=+ep' /путь_к_приложению

CAP_NET_BIND_SERVICE позволяет процессу использовать привилегированные порты (<1024).

Но это актуально только если используется опция no-new-privileges:true. У нас она обязательна к применению по требованию ИБ. По умолчанию, NET_BIND_SERVICE разрешен, полный список разрешенных capibilities тут.

Можно еще попробовать запустить goBGP на нестандартном порту (например 1179) и с помощью iptables на хостовой машине пробросить трафик с 179 на 1179. При этом убрать network_mode: host.

И примерно так пробросить на хосте:

iptables -t nat -A PREROUTING -p tcp --dport 179 -j DNAT --to-destination <container_ip>:1179

P.S. Если есть дополнения или я где-то ошибаюсь, буду рад комментариям.

UPD: Спасибо за исправления @maxnrm

🎤Будни сетевика 😊 | #Задача

⚡️ YADRO×SPRINT OFFER: оффер для Network Engineer in Test за 3 дня!

Хотите работать в команде, которая создаёт инфраструктуру для дата-центров и обеспечивает надёжность сетевых систем мирового уровня?

Мы в поиске специалистов в команду KORNFELD, которая занимается тестированием коммутаторов различных типов и сетевого оборудования YADRO. Инженеры анализируют поведение систем, актуализируют требования, создают сценарии и подходы к тестированию — от функционального до надёжности и отказоустойчивости, а также помогают совершенствовать архитектуру продуктов и пользовательский опыт.

💡 Как всё проходит:
1️⃣ Оставьте заявку до 30 ноября, пройдите HR-скрининг и технический скрининг.
2️⃣ Пройдите техническое и менеджерское интервью.
3️⃣ Получите оффер всего за 3 дня.

🚀 Основные задачи:
• Анализ продуктовых требований и подготовка use cases.
• Проведение E2E- и failover-тестирования.
• Разработка тест-кейсов и тест-планов для нового и уже существующего функционала.
• Участие в совместных испытаниях и взаимодействие с командами разработки, L3 и сервиса.

🔥 Для нас важны:
• Опыт работы с сетевым оборудованием (Cisco, Huawei, Juniper и др).
• Глубокие знания протоколов, применяемых в ЦОДах (BGP, OSPF, VxLAN, VRRP и др.).
• Навыки тестирования и траблшутинга.
• Внимательность, системность и интерес к сетевым технологиям.

💙 Оставляйте заявку до 30 ноября, присоединяйтесь к инженерному сообществу YADRO и вносите вклад в развитие сетевых технологий будущего!

Как создать бесконечно длинный AS_PATH в BGP: инструкция, которой лучше не следовать.

Описан сценарий, показывающий, как комбинация функций BGP confederations и AS override может привести к нештатному поведению протокола, в частности к петле, а в случае автора еще и к падению процесса BGP.

А можно сразу к выводам:

The main lessons from this tale are:

• never use BGP confederations under any circumstances, and
• be cautious of features that weaken BGP routing loop detection.

Статья свежая, 2024 г, но кто-нибудь видел в проде BGP confederations или это все-таки только в учебниках?

🎤 Будни сетевика 😊

Интересное чтиво о высокоуровневом проектировании систем масштаба Netflix и др

• Designing Netflix
• Designing WhatsApp
• Designing Uber
• Designing Tinder
• Designing Instagram


🎤 Будни сетевика 😊