Занятная приоретизация голосового трафика в Telegram

f0855ac8443d419194ed6732c7bf02e1.jpg

Наверное, многим интересно, как же команде Telegram удалось сделать популярную для мессенджеров функцию голосовых звонков уже сразу после запуска разительно отличающейся по качеству в лучшую сторону перед многими другими VoIP — сервисами.
Во время изучения работы Telegram Calls я обратил внимание на интересную техническую деталь, которая используется на сетевом уровне и помогает уменьшить задержки при прохождении пакетов, когда при соединении используются релейные сервера.

Если взглянуть на дамп трафика, который проходит при звонке, в котором использовался релейный сервер, можно заметить, что трафик определяется протоколом RIP. IP на 91. — это сервер Telegram. Я снимал дамп трафика на своём VPN — сервере, поэтому адрес клиента из локальной подсети.

01991b0f8f2a4cc8a94afbecbb79cc3c.png

А вот скриншот из дебага клиента, но уже при P2P. Стоит отметить, что 520 порт назначен только серверам, поэтому этот метод работает тогда, когда P2P — соединение между клиентами невозможно и один из серверов из списка выступает в роли релея.

a72310cbb7ba496486c739e73a991a99.png

Вспомним, что нам известно про протокол RIP?
RIP — протокол маршрутизации. RIP работает на 3 уровне (сетевой) стека TCP/IP, используя UDP порт 520. UDP, то есть доставка, не требующая подтверждения приёма, как известно, сам по себе отлично подходит для трафика реального времени, коим является голос.

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

Эта приоретизация реализуется в маршрутизаторах с помощью DSCP — кодов (Differentiated Services Code Point), и по-умолчанию, например, в Cisco согласно RFC 791 и RFC 2474 протоколы маршрутизации RIP/RIP2/OSPF/EIGRP маркируются кодом 6. А это, на минуточку, предвысший, Internetwork Control приоритет.

bc2682cbd49145e68a1308f0cf1bc435.png

Кроме приоритизации DSCP, Cisco IOS также имеет внутренний механизм PAK_priority, который служит для предоставления приоритета для важных датаграмм именно в момент их прохождения через роутер. PAK_priority designation был задуман разработчиками Cisco (и, можно предположить, некоторыми другими) оборудования как критически важный для корректной работы Cisco IOS, и поэтому его никак нельзя конфигурировать. Что исключает возможность администраторам как-либо влиять на приорететный пропуск трафика, имеющего для системы характеристики Control.

Похоже, вспомнив про древний протокол и особенности его работы (полезный UDP, существование возможности Unicast — обмена), архитекторы Telegram использовали его порт, тем самым заставили многие маршрутизаторы на пути следования пакетов обрабатывать их трафик как очень важный, тем самым, очевидно, несколько сократив задержки.

Вроде бы небольшая деталь в мире мощных кодеков, но, как говорится, дьявол кроется в мелочах — так почему бы не заставить эти мелочи работать на благо конечной цели?

Комментарии (1)

  • 15 апреля 2017 в 06:17

    0

    Ммм… Я всегда считал, что PAK priority работает не для транзитного в data plane трафика, а для трафика, выходящего из control plane в data plane. Если это так — то для трафика телеграма этот механизм бесполезен.

    Не исключаю, что я считал неправильно, но, например, http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html говорит как раз о том, что «The RIP and OSPF routing processes that run on the core CPU of a router mark all traffic they originate with both IP precedence 6 and pak_priority». Тут важно, что это именно процессы контрол-плейна, создающие трафик. А разбирать транзитный трафик в датаплейне на предмет развешивания на них неуправляемых приоритетных флагов, было бы не только трудоемко, но и несколько опрометчиво.

© Habrahabr.ru