19 июня в 13:11

Шел 2017 год. Где UDP фрагментация?

VoIP — это термин-зонтик. Набор технологий, протоколов и просто buzzword'ов, которые относятся к передаче голоса (и видео!) по компьютерным сетям (локальным или интернет) вместо телефонных. И да, большая часть телеком-провайдеров всё ещё использует для передачи голоса собственные сети вместо интернет. С недешевыми коробочками, куда втыкаются T1 и E1 провода.

Чаще всего, для айтишников, не работающих в телекоме, VoIP – это связка RTP/RTCP для передачи голоса/видео плюс SIP – для договориться, кому и как передавать. Именно это связка позволяет подключить офисные «SIP телефоны» к Bitrix24 или Asterisk. Оба протокола могут работать как по TCP, так и по UDP. С передачей голоса по RTP вопросов нет: за редчайшим исключением используется UDP протокол, а кодеки компенсируют потерянные пакеты, так что собеседник почти не «квакает» даже не на самом лучшем канале связи. А вот с SIP история более печальная.



Вообще, SIP — это такой HTTP для телефонии. Про него на Хабре есть замечательный двухсерийный пост. Если кто интересуется, очень рекомендую. Ключевое отличие от HTTP, что SIP должен работать в обе стороны всегда. Задача «отправить сообщение с сервера на клиент» решалась в HTTP очень много лет, пережила AJAX, WebSockets, и сейчас наконец-то стабилизировалась в виде HTTP/2. А в SIP эту задачу нужно было решать сразу: не только телефонный аппарат отправлял запрос «вот он я, готов принимать звонки», но и сервер должен был иметь возможность в любой момент сообщить клиенте «а вот тебе и звонок, принимать будешь?».

А у TCP, при всех его достоинствах, есть и недостатки. Например, соединения могут «протухать». Если не поставить маленький keep-alive (а SIP был создан в 1996-м году) и постоянно не отсылать пинги, то «подключение» может оборваться с одной стороны, а вторая сторона этого не заметит. Хорошо, если оборвалось со стороны клиента — он это заметил и переподключился. А если оборвалось со стороны сервера? Нужно ждать, пока у клиента случится keep alive или какой-нибудь другой таймаут и он переподключится. А в это время клиенту звонок.

А еще 20 лет назад, когда это всё создавалось, был очень печальный вопрос переподключения. Для UDP версии SIP клиентам достаточно время от времени (раз в час) посылать пакеты REGISTER, говоря «вот он я, готов принимать звонки». В случае перезагрузки или выключения сервера другой сервер за тем же IP-адресом может работать со всеми этими клиентам. А вот в случае TCP клиентам нужно будет переподключаться. Десять тысяч телефонов здания (обычная ситуация) пошли переподключаться и убили сервер…

В общем, все ждали, что SIP будет по TCP. А он стал по UDP. Сейчас, 20 лет спустя, все больше компаний переключаются на «только по tcp». Тем не менее, огромный парк устройств, клиентов и инфраструктуры ходили по UDP, ходят по UDP и ближайшие несколько лет ходить будут.

А в комбинации «SIP и UDP» есть беда. Собственно, этот пост про нее. Беда называется «фрагментация». Сама по себе фрагментация сетевых пакетов почти безвредна: есть настроенный для сетевой карты MTU, максимальный размер передаваемого за раз пакета. В большинстве случаев это 1500 байт. Для TCP и подавляющего большинства UDP протоколов это никак не влияет: они просто никогда не шлют пакеты больше MTU и используют внутренние механики, чтобы передавать большие объемы данных по кусочкам, терять эти кусочки и пересылать их повторно, если надо.

А SIP — он как HTTP. Текстовый. И в последние годы к простым командам вроде «я тут» и «тебе звонок» добавилась куча дополнительных полей и всяких XML/JSON в пайлоадах. Размер получающихся пакетов стал регулярно выходить за пределы MTU. Начиная с этого момента история становится совсем печальной.



Современный интернет — он, на самом деле, не очень хорошо приспособлен к фрагментированным сетевым пакетам. Производители оборудования и авторы софта резонно полагают, что большинству софта такие пакеты слать не нужно. TCP фрагментирует сам, UDP — это realtime команды, видео и звук. Им не нужно быть больше MTU. Если потеряются, ничего страшного не произойдет. И не очень заморачиваются, насколько хорошо их решения поддерживают фрагментированные пакеты. Свичи могут крешится. «Корпоративные» железки, делающие свои надстройки поверх ethernet/ip, не могут фрагментацию и молча игнорируют пакеты. А у некоторых железок буфер на сборку фрагментированных пакетов — на целых 200 штук. Переполняется он на удивление легко.

Все это мы видим в техподдержке, когда «звонки то работают, а то не работают». Хорошо, когда есть команда инженеров, которые могут запросить у телеком оператора SIP-логи, вдумчиво почитать и ткнуть пальцем в «проблемный» участок. Намного хуже, когда в компании один Asterisk и админ-удаленщик, его обслуживающий. В таком случае «просто магия, иногда звонки не доходят».

Сейчас все стараются использовать SIP по TCP, но проблема отставания инфраструктуры за последние несколько лет встала очень остро. Все больше видео и голосовых звонков совершаются через браузеры (чего стоит только недавно вышедший «Skype для веб»). С какой скоростью развивается веб, мы с вами прекрасно знаем: набежавшие разработчики принесли с собой привычные JSON и XML пайлоады, а видеоконференции на 20-30 человек перестали быть уделом крупных компаний, где бородатые админы могли неделями настраивать циски, «чтобы работало».

Вывод: увидите SIP и UDP в одном месте — будьте осторожны. И при первой возможности переключайте на TCP!

Ссылки позаимствованы вот из этой статьи, которая рассматривает проблему гораздо глубже и тоже рекомендует по возможности использвать TCP

А картинка для привлечения внимания — вот отсюда
Автор: @eyeofhell

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

  • +2
    Насколько я понимаю 1500 байт может быть не везде. Максимальный безопасный размер пакета 508 байт.
    • 0
      Может быть не везде, VPN и MPLS любят добавлять в пакеты свою техническую информацию. Да и поменять MTU на машине никто не мешает.
      • 0
        А на всех устройствах между?
        • 0
          Тут в моих знаниях провал. Что будет, если где-то посередине маршрута VPN/MPLS/WTF, который хочет понизить MTU и начинает фрагментировать… А если пакеты с флагами don't fragment? Не знаю что будет. Возможно, кто-то из более опытных по инфраструктуре Хабравчан подскажет.
          • +2

            Дропы пакетов будут. Именно потому "приличные" протоколы включают способ автоматического определения MTU вдоль маршрута.

  • +4
    А может не надо тащить в SIP привычные JSON и XML пайлоады? В аналог же не тащите…
    • +2
      Так привычки же. Я — не тащу. А вот более молодые разработчики… Ну вы понимаете :)
      • 0

        Линейкой по рукам таким разработчикам, и RFC 3261 пусть курят до просветления. Зачем тащить xml/json в SIP??? Что еще за дикие идеи?

      • +3
        В таком случае, советуйте молодым разработчикам фрагментировать данные перед отправкой. UDP для SIP абсолютно на всех устройствах выбран по-умолчанию. Своим юзерам говорить, что работает у нас SIP only TCP — непросто, проще даже настроенное оборудование поставлять.
        На эту и подобные темы, не зря, Международным союзом электросвязи (ITU-T) для передачи мультимедиа-данных был рекомендован протокол H323. Народ выбрал то, что намного проще — SIP. Если вы будете раздувать SIP — Вас не очень поймут. На то он и призван быть простым, чтобы пакет мог легко выполнить 70 дефолтных переходов (Max-Forwards), в случае надобности.
        По сему 3 варианта:
        1)Фрагментировать самим.
        2)Настраивать оборудование.
        3)Последовать рекомендациям ITU-T.
  • 0

    path mtu discovery? Его сейчас реально ктото делает из популярных операционок? Винда там, андроид, вот эти все ребята? О_О

    • 0

      PMTU делают по моему все, одако проблем он не решает. Path MTU discovery работает (для TCP, don't fragment flag is set) следующим образом: пакет дропается а источнику отправляется соответствующий ICMP. Это imho крайне неудачный механизм, по сути negative ACK, старательно избегаемый в базовой версии TCP. На практике все сетевые устройства ограничивают генерацию ICMP и в ситуации подобной примеру (10000 клиентов одновременно посылают пакет > MTU) большинство из них впадет в экспоненциальный ретрансмит и зависнет навсегда.

      • 0

        Для достаточно умных промежуточных устройств есть еще альтернативный механизм с редактированием заголовка TCP...

        • 0

          Не слышал, а чем это поможет? Если пакет не пролазит в MTU следующего сегмента, его по любому придется либо сегментировать, либо дропнуть.

          • 0

            Пакет SYN, идущий без данных, в MTU пролезет всегда. А дальше — обе стороны уже будут знать PMTU и не будут посылать больших пакетов. Если, конечно, маршрут внезапно не сменится.

            • 0

              Вы хотите сказать что все промежуточные устройства редактируют TCP header обновляя поле MTU? Логично, однако это работает только для статических маршрутов с известными узлами. Более того, оконечные устройства все равно должны быть готовы обрабатывать фрагменты.

        • 0
          > с редактированием заголовка TCP.

          Если имеется в виду добавление опции TCP MSS, то если во встречный пакет такое добавили — хорошо, но если не добавили? Как это «умное промежуточное устройство» узнает про необходимость добавлять MSS для конкретного маршрута? Обычно эту опцию вынуждены включать глобально, чтобы хоть как-то работало, и соответственно понижая эффективность всех передач.
          • 0

            Так же, как маршрутизаторы узнают о необходимости фрагментировать пакет.

            • 0
              Нет, так как раз не получится. Раутер послал свой needfrag и забыл. Он не будет ставить у себя память «вот для этих спецправило — ставить MSS». Такое спасение утопающих — только их дело, в лучшем случае, ближайшего своего шлюза.
              • 0

                А я разве утверждал, что этот механизм работает всегда? Нет, я написал, что он работает для достаточно умных промежуточных устройств. В приведенном вами примере роутер таковым не является.

                • 0
                  Так таких «достаточно умных» днём с огнём не напасёшься.
  • +2
    SIP по TCP ничем не лучше чем SIP по UDP, хотя бы по тому, что стандартом де-факт является UDP-вариант, а TCP все поддерживают чтобы было, очень часто из-за этого проблем там еще больше по факту.
    • +1
      Для передачи звука/видео и прочего, требующего реального времени, UDP больше подходит: ТСР сильно сужает полосу при возрастании потерь, так что на мобильном интернете плохо работает. ТСР будет слать уже неактуальные данные, пока не дошлёт. Но у ТСР несколько лучше дела обстоят с файрволами. UDP часто закрыт, особенно в корпоративных сетях. UDP-flood способен намертво повесить сервер из-за огромного количества прерываний, если трафик лить на открытый UDP-порт, даже объединение нескольких пакетов в одно прерывание не помогает.
      • 0
        DoS он везде одинаковый, что по TCP, что по UDP, большой разницы нет. Как будто TCP-flood нельзя организовать
        • +2
          по UDP можно трафик лить с одного хоста через подмену адреса отправителя и маршрутизаторы этот трафик не блокируют (на моей практике). SYN-flood с некорректным адресом отправителя неплохо режется
  • –2
    На смартфонах SIP по UDP вдобавок намного быстрее пожирает батарейку.
    • +3

      А расскажите, почему? Чем tcp с пингами лучше?

      • +1
        Для TCP маршрутизаторы устанавливают больший таймаут записей NAT, чем для UDP (обычно 15 минут против 30 секунд), поэтому пинговать можно реже.
  • –2
    «Смешались в кучу кони люди»

    Не читайте эту статью — она вас плохому научит.
    во время SIP сессии — различают две части.

    Сигнальную и голосовую.
    Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.

    А вот голосовая идёт по RTP поверх UDP или TCP.
    И здесь проблем с фрагментацией не наблюдается. Потому как проблема ровно обратная — overhead. Голосовые пакеты настолько маленькие, что overhead даже через UDP может достичать 100%. Т.е. длина заголовка UDP ~ равна полезной нагрузке. (у разных кодеков по разному)

    Размер пакета у кодека G.729 — 20 байт. У G711 — 160 байт. Поэтому до фрагментации там как пешком до луны

    • +6
      Сигнальная — это когда клиент обменивается сообщениями с сервером («SIP — он как HTTP. Текстовый»). Она всегдя идёт по TCP (порт обычно 5060). Здесь никаких проблем с фрагментацией нет.


      Я просто скажу, что это не так. Ок? :)
      • –3

        Проблема SIP ( сигнализации ) и длины пакета в большинтстве своем не видна, так как в общем и целом пакеты с самом SIP не большие. Нет там такого огромного количества информации чтобы дойти до ограничений. Даже с описанием видео сессии. Много данных гоняется через websockets но там TCP, так что паника надумана как по мне.

        • 0
          Тоже не вижу проблем, один раз за всю свою практику сталкивался с этим, когда размер INVITE`а переваливал 1500 и… не работало) Начинаешь смотреть, что не так и, внезапно, в этом INVITE`е в SDP перечислено 100500 ненужных кодеков и левых хидеров. Снимаем дамп и настраиваем правильно)
          • –2
            Так вот, за последние пару лет все поменялось. Особенно с видеоконференциями. Прогресс, вот это всё.
            • +2
              С видео конференциями — понятно, там банально информации больше гоняется, а то, о чем вы пишите, касается всего SIP. Из пушки по воробьям палите.
              Вы тогда у и пишите что, мол, при таких-то и таких-то случаях данная проблема возникает. А так под одну гребенку все. Зачем?

              • 0
                Интересная и слабоосвещенная тема. Плюс английская статья про то же самое хорошо зашла, https://200ok.info/2017/03/31/sip-and-fragments/ — я же слежу за индустрией. Так что рассказать на Хабре, судя по просмотрам и плюсам, было здравой идеей. Ну а что тема спорная — в том и интерес.
      • –3
        Ну, хорошо.
        Напишу так.

        При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.
        Основная проблема — это Overhead при куче мелких пакетах, которые излишне нагружают switch/router.
        И tcp рекомендовано применять в сетях большой вероятностью потери пакетов (например — беспроводных)
        • +2
          > При работе с VoIP (статья то VoIP? правильно? прямо так в первом предложении и написано) вы врядли встретитесь с проблемами фрагментации.

          Запросто — когда SDP в INVITE перечисляет пятнадцать кодеков с подробным перечислением свойств каждого, в Via уже несколько записей транзита, а From, To увешаны атрибутами как новогодняя ёлка.
          • –2
            Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?

            А на стенде много чего можно накрутить.

            В нормально настроенном оборудовании IMHO, нужно всего 3 кодека, какой либо HD, G.711 и сильно сжимающий (типа G.729). А при зональном делении и того меньше.

            А пихать 15 кодеков, это как иметь 3 антивируса на компьютере.
            • +1
              > Ну то есть вы согласны — что такая ситуация в реальной жизни маловероятна?

              Не-а. Может, это специфика клиентов моей прошлой работы, но такого было валом. Ну пусть не 15 кодеков, но по 10 пытались выставлять, и параметры вписывались чуть менее, чем все. Я мерял — INVITE толще граничных 1300 байт были регулярно.

              > В нормально настроенном оборудовании IMHO, нужно всего 3 кодека

              Судя по тому, что в типичной железяке, с которой мы работали, были G.711, G.723 в двух профилях, G.729 в двух профилях, GSM, Speex — с Вами мало кто согласен :) Обычно предпочитают выставить побольше, лишь бы связаться хоть как-то. Очень не любят ситуацию, когда звонок не устанавливается потому, что не нашли общего кодека.
              А так как до сих пор есть два слабопересекающихся мира с проприетарными и со свободными кодеками, где на пересечении только G.711, который зарезан потому, что слишком большая полоса (а некоторые клиенты из крупных азиатских стран реализовывали свой менталитет зарезанием всего, что толще ~8Kbit/s) — то такое несогласование происходило постоянно. Если удавалось уговорить обе стороны в таком варианте на GSM — это уже была маленькая победа.
              • –1
                Отвечу в аналогичном стале
                «Сутя по тысячам терминалам и сотням станций разных вендоров которыя я настраивал» таки у вас нетипичные клиенты.

                Если кто-то пытается сделать бизнес и на бесплатных кодеках — это лишь его частные проблемы.

                Вообще — есть два типа проблем:

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

    • +1
      По умолчанию везде SIP использует UDP транспорт. TCP вы настраиваете сами.
      Остальное все верно.
      • 0
        > По умолчанию везде SIP использует UDP транспорт.

        Цитирую RFC3261:

        >> If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP.

        Тут даже не SHOULD, тут MUST. Которое, конечно, игнорируют «не только лишь все», но многие на него смотрят и ожидают соответствующего.
  • +5

    Вы б таки ещё за роутинг аттачей спросили…

  • 0
    Прошу прощения за оффтоп. Уважаемые камрады, не силен в протоколах IP-сигнализации. Есть сервер телефонии под Windows Server 2003, оператор Ростелеком говорит, цитирую: «Но от вас сигнализация идёт по UDP, а не TCP. Соответственно, нужно либо сигнализацию слать по TCP, либо keepalive включать под UDP. Временной интервал 15-30 секунд».Вот что то я и задумался как это реализовать в винде, с Linux было бы чуть проще.
    • +2
      Взять софт, который телефонию обеспечивает, и переключить SIP с UDP на TCP :) Все как в статье.
      • 0
        Да все бы хорошо, софт называется infratel call center,4 версия. Документации никакой по софту нет, производитель софта открещивается от этой версии (закончилась поддержка). Два выхода: обновление на новую версию (платно и очень затратно), обращение в саппорт ничего не даст (саппорт платный тоже)
        • 0
          Беда-печалька. Если софт менять совсем не вариант, то надо ставить простенький proxy между ним и телеком оператором. И единственное, что будет делать прокси — это добавлять keep alive :) Довольно долго настраивать придется :(
        • +2
          Григорий скромно не предложил перейти на Voximplant :)
  • +1
    при первой возможности переключайте на TCP!

    вы всерьёз призываете к нарушению RFC? UA должен использовать UDP и переключаться на TCP в случае проблем. M$ с их Lync (SfB) просто забили на стандарт (обычное дело, часть EEE).
    в современных Астерисках есть PJSIP, с которым нет проблем совместимости
    зато во все времена есть проблема со «специалистами», которые не понимают значения слова «стандарт», и здесь не важно, Астериск они настраивают или что-то другое
    • +2
      У MS вообще есть msSIP и msRTP, просто так, к слову :)
    • –1
      Я ссылку на англоязычную статью оставил, посмотрите — там много референсов. Вот это вам будет интересно: «The SIP standard, RFC 3261 mandates that TCP should be used to prevent fragmented SIP. „
      • 0
        извините, не интересно
        «RFC 3261 обязывает использовать TCP для предотвращения фрагментации»
        т.е. не какие-то другие костыли городить, а использовать TCP.
        будет ли происходить фрагментация в 100% случаев? — нет
        чем руководствоваться чтобы понять, будет ли происходить фрагментация?
        частью 18.1.1 документа:
        If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown… 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU

        перевод части абзаца выше:
        Если разница между размером запроса и размером MTU 200 байт или меньше, или если запрос больше 1300 байт, а MTU не известен…

        вместе с тем часть 19.1.2 документа однозначно нам сообщает:
        The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP.

        перевод предложения выше:
        Транспорт по-умолчанию зависит от схемы (URL). Для адресов sip: это UDP, для sips: это TCP.

        Таким образом в общем случае использование TCP для запросов меньше 1300 байт противоречит стандарту.
  • +1
    > увидите SIP и UDP в одном месте — будьте осторожны

    Moи 10+ лет опыта в VoIP подсказывают что автор пытается ввести людей в заблуждение. SIP по UDP или TCP — не особо важно, сам разговор (RTP/RTCP) идут по UDP (обычно) и в SIPe и в H264. Можно и по TCP, что лучше работает в случае плохого исполнения RTP/RTCP кода. Сам SIP в основном по TCP идет в комерческих сетях.

    > наконец-то стабилизировалась в виде HTTP/2

    Еще не совсем стабилизировалось, это лишь шаг на пути к HTTP/3 который будет по UDP.
    • 0
      Я прям-таки вижу сцену: вечер, я в окружении наших сиповиков-телекомщиков пишу статью, Юра с Олегом и Ваней хором — «Да, да! Вот так! Вводи их в заблуждение! И про RTCP не забудь запутать!» :)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.