Наверное, многим интересно, как же команде Telegram удалось сделать популярную для мессенджеров функцию голосовых звонков уже сразу после запуска разительно отличающейся по качеству в лучшую сторону перед многими другими VoIP — сервисами.
Во время изучения работы Telegram Calls я обратил внимание на интересную техническую деталь, которая используется на сетевом уровне и помогает уменьшить задержки при прохождении пакетов, когда при соединении используются релейные сервера.
Если взглянуть на дамп трафика, который проходит при звонке, в котором использовался релейный сервер, можно заметить, что трафик определяется протоколом RIP. IP на 91. — это сервер Telegram. Я снимал дамп трафика на своём VPN — сервере, поэтому адрес клиента из локальной подсети.
А вот скриншот из дебага клиента, но уже при P2P. Стоит отметить, что 520 порт назначен только серверам, поэтому этот метод работает тогда, когда P2P — соединение между клиентами невозможно и один из серверов из списка выступает в роли релея.
Вспомним, что нам известно про протокол 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 приоритет.
Кроме приоритизации DSCP, Cisco IOS также имеет внутренний механизм PAK_priority, который служит для предоставления приоритета для важных датаграмм именно в момент их прохождения через роутер. PAK_priority designation был задуман разработчиками Cisco (и, можно предположить, некоторыми другими) оборудования как критически важный для корректной работы Cisco IOS, и поэтому его никак нельзя конфигурировать. Что исключает возможность администраторам как-либо влиять на приоритетный пропуск трафика, имеющего для системы характеристики Control.
Похоже, вспомнив про древний протокол и особенности его работы (полезный UDP, существование возможности Unicast — обмена), архитекторы Telegram использовали его порт, тем самым заставили многие маршрутизаторы на пути следования пакетов обрабатывать их трафик как очень важный, тем самым, очевидно, несколько сократив задержки.
Вроде бы небольшая деталь в мире мощных кодеков, но, как говорится, дьявол кроется в мелочах — так почему бы не заставить эти мелочи работать на благо конечной цели?
Автор: Daniel Snow
