Если бы хотели сэкономить, то резали бы полосу пропорционально количеству абонентов. А мы не режем, отдаем все, что есть, даже, если абон один на БС. Его будут ограничивать только радиоусловия и ограничения технологии. В этих условиях его торрент разгонится до максимума, который ему позволен приоритетами на самом компьютере.
Но лучше смоделировать другую ситуацию:
абон 1 сидит близко к БС в хороших радиоусловиях и серфит
абон 2 сидит далеко от БС и плохих радиоусловиях и активно раздает торрент, т.е. нагружает аплинк
В такой конфигурации БС будет отдавать по максимуму радиоресурсов абону 2, чтобы обеспечить ему уровень сервиса приближенный к уровню сервиса абона 1. И так как радиоресурсы аплинка сильно ограничены, то абон 1 начинает испытывать серьезные проблемы даже с простым серфингом (не говорю уже о медиа-потоках), его уровень сервиса сильно падает и не соответствует тем условиям, в которых он сидит. Обоим становится хреново с точки зрения сервиса.
Вот такую ситуацию надо обязательно разруливать на коре, чтобы уровень сервиса абона 1 драматически не падал из-за абона 2. Вот это мы и делаем.
Кстати, если есть желание и интерес, мы, наверное, могли бы очно об этом рассказать. Модель действительно интересная. И мне кажется доля негатива ушла бы после этого.
У нас до некоторого времени p2p был. Пока пару лет назад не обновили клиента торрента и он чуть было не положил не только офисные, но и провайдерские сети — переходил на пакеты малой длинны и создавал большую нагрузку не только на аплинк беспроводных сетей, но и на проводах.
Сейчас мы его в офисе шейпим, но тупо и беспощадно в отличие от коммерческой сети)
Основная особенность мобильных сетей состоит в том, что они рассчитаны на профиль нагрузки, при котором downlink значительно преобладает над uplink. Как только эта закономерность нарушается, абоненты начинают страдать от драматического падения уровня сервиса. Именно на этом основана модель управления трафиком на сети. «Резать» каждый может, а управлять — нет.
DPI на мобильном трафике действительно сейчас есть у всех. Без него нонче никуда.
В нашей конфигурации, к примеру, он очень активно используется в купе с аналитикой с RAN для управления перегрузками на сети, чтобы дать абонентам максимально лучшие условия. У тройки чуть попроще все это организовано, да и профиль нагрузки на их сети отличается из-за отсутствия широкого применения безлимитных тарифов.
Как правило DPI стоит в районе PGW или вообще встроен в него, т.е. это как раз и есть тот самый первый узел, на который попадает абонентский трафик, пройдя через RAN. При это встроенный DPI штука весьма специфичная…
По поводу фильтрации. Опять же я не стану утверждать по поводу ее преднамеренности, но замечу, что wa.yota.ru (.254) работает по HTTPS (там идет обмен абонентскими данными). Чтобы его заблокировать надо либо проанализировать SSL handshake и выцепить от туда сертификат сервера или дополнительные _необязательные_ поля, где имя сервера может быть указано, либо фильтровать по IP. Первый способ не дает гарантии корректной фильтрации, второй — очень грубый, но дает.
Кстати, вот хороший пример:
yota.ru 94.25.232.249 (собственно наш сайт)
wa.yota.ru 94.25.232.254 (API, через который работает приложение)
сайты опубликованы на одном и том же реверс-прокси, одна подсеть, одинаковые маршруты, одинаковые настройки соединения
при этом .249 работал, а .254 — нет
Честно говоря я тоже склонен мыслить позитивно — проблемы с MTU, фазы луны и т.д. Но как-то уж подозрительно все выглядело — проблемы были только с теми ресурсами, на базе которых строится привлечение абонентов. Возможно случайность.
Откровенно говоря, лотерея будет при любом переходе к любому оператору. Об этом полно уже публикаций. Там довольно сложная схема с переносом номера, когда один оператор в определенный момент должен «отпустить» абонента, а второй его «принять» (это если не принимать в расчет бюрократические схемы, там тоже веселья достаточно). И на этой переправе то с одной, то с другой стороны случаются косяки. А взаимодействие между операторами, сами понимаете, не идеальное.
Вопрос от инсайдера :)
Коллеги, а как все-таки объясните такой факт: если перевести сервер на другой (рядом стоящий) IP, то все начинает прекрасно работать?
Проблема в том, что подобное поведение как правило обрабатывается на уровне операционной системы, не приложения. ОС пытается ретрансмитить пакеты, думая, что канал загружен. При этом не отдает управление приложению. Приложение «зависает» на вызове метода.
Почти так)
приложение завязано на два ресурса — wa.yota.ru и static.yota.ru
Мы меняли IP у wa.yota.ru, при этом он начинал работать, трассировка шла корректно, сервер видел запросы, а мы видели ответы от сервера.
Но все затыкалось на static.yota.ru, так как с ним тоже были проблемы.
Если поменять IP еще и у static.yota.ru, то все начинало работать.
Ответ на второй вопрос — да, маршрут оставался тем же, так как IP адреса из одной подсети и на одном оборудовании.
Вот как раз первый тест (wa.yota.ru) был большими пакетами.
Потом решили избавиться от потенциального влияния MTU и перешли на маленькие пакеты.
При этом поведение трассировки разными типами пакетов не изменилось и на сервере наблюдалась одна и та же картина.
Я уже комментировал выше — на том же оборудовании, на IP из той же подсети публиковали тот же сервер, прописывали IP в hosts и все работало. Без изменений MTU.
Отчет значительно более толстый, чем приведенный из него отрывок :)
Там в том числе есть контрольный тест до работающего ресурса
И более того, там есть тест, когда трафик к wa.yota.ru был пущен по альтернативному IP.
TTL 3 и TTL 14 — это тесты к разным серверам (посмотрите на IP)
Честно говоря, задачей отчета было в первую очередь определить, что трафик не пролезает дальше МТС.
По какой причине он не пролезает это уже дело второстепенное. Проблема то в том, что МТС не признавали, что проблема на их стороне.
Собственно тесты именно это и показывают.
Во втором случае использовался условно «толстый» пакет, так как эмулировалось именно поведение приложения.
MTU в 400 байт — это вообще, имхо, прошлый век…
Да, совершенно верно, некоторые другие сайты != все другие сайты.
Но в данном конкретном случае, поверьте, равно. Для публикации серверов используется реверс-прокси, который един для целой группы серверов. В частности, главная страница сайта yota.ru прекрасно открывалась через SIM МТС, а раздел /voice — нет, так как он завязан на static.yota.ru. При этом и static.yota.ru и сам yota.ru опубликованы через одно и то же оборудование.
К сожалению, когда верстали статью, не включили эти результаты в текст.
Но лучше смоделировать другую ситуацию:
абон 1 сидит близко к БС в хороших радиоусловиях и серфит
абон 2 сидит далеко от БС и плохих радиоусловиях и активно раздает торрент, т.е. нагружает аплинк
В такой конфигурации БС будет отдавать по максимуму радиоресурсов абону 2, чтобы обеспечить ему уровень сервиса приближенный к уровню сервиса абона 1. И так как радиоресурсы аплинка сильно ограничены, то абон 1 начинает испытывать серьезные проблемы даже с простым серфингом (не говорю уже о медиа-потоках), его уровень сервиса сильно падает и не соответствует тем условиям, в которых он сидит. Обоим становится хреново с точки зрения сервиса.
Вот такую ситуацию надо обязательно разруливать на коре, чтобы уровень сервиса абона 1 драматически не падал из-за абона 2. Вот это мы и делаем.
Сейчас мы его в офисе шейпим, но тупо и беспощадно в отличие от коммерческой сети)
Никогда не приходилось бороться с проблемами на Wi-Fi из-за большой нагрузки на него p2p трафика?
В нашей конфигурации, к примеру, он очень активно используется в купе с аналитикой с RAN для управления перегрузками на сети, чтобы дать абонентам максимально лучшие условия. У тройки чуть попроще все это организовано, да и профиль нагрузки на их сети отличается из-за отсутствия широкого применения безлимитных тарифов.
Как правило DPI стоит в районе PGW или вообще встроен в него, т.е. это как раз и есть тот самый первый узел, на который попадает абонентский трафик, пройдя через RAN. При это встроенный DPI штука весьма специфичная…
По поводу фильтрации. Опять же я не стану утверждать по поводу ее преднамеренности, но замечу, что wa.yota.ru (.254) работает по HTTPS (там идет обмен абонентскими данными). Чтобы его заблокировать надо либо проанализировать SSL handshake и выцепить от туда сертификат сервера или дополнительные _необязательные_ поля, где имя сервера может быть указано, либо фильтровать по IP. Первый способ не дает гарантии корректной фильтрации, второй — очень грубый, но дает.
Но это так, к слову, для поддержания дискуссии)
yota.ru 94.25.232.249 (собственно наш сайт)
wa.yota.ru 94.25.232.254 (API, через который работает приложение)
сайты опубликованы на одном и том же реверс-прокси, одна подсеть, одинаковые маршруты, одинаковые настройки соединения
при этом .249 работал, а .254 — нет
Честно говоря я тоже склонен мыслить позитивно — проблемы с MTU, фазы луны и т.д. Но как-то уж подозрительно все выглядело — проблемы были только с теми ресурсами, на базе которых строится привлечение абонентов. Возможно случайность.
Коллеги, а как все-таки объясните такой факт: если перевести сервер на другой (рядом стоящий) IP, то все начинает прекрасно работать?
приложение завязано на два ресурса — wa.yota.ru и static.yota.ru
Мы меняли IP у wa.yota.ru, при этом он начинал работать, трассировка шла корректно, сервер видел запросы, а мы видели ответы от сервера.
Но все затыкалось на static.yota.ru, так как с ним тоже были проблемы.
Если поменять IP еще и у static.yota.ru, то все начинало работать.
Ответ на второй вопрос — да, маршрут оставался тем же, так как IP адреса из одной подсети и на одном оборудовании.
Потом решили избавиться от потенциального влияния MTU и перешли на маленькие пакеты.
При этом поведение трассировки разными типами пакетов не изменилось и на сервере наблюдалась одна и та же картина.
Там в том числе есть контрольный тест до работающего ресурса
И более того, там есть тест, когда трафик к wa.yota.ru был пущен по альтернативному IP.
Честно говоря, задачей отчета было в первую очередь определить, что трафик не пролезает дальше МТС.
По какой причине он не пролезает это уже дело второстепенное. Проблема то в том, что МТС не признавали, что проблема на их стороне.
Собственно тесты именно это и показывают.
Во втором случае использовался условно «толстый» пакет, так как эмулировалось именно поведение приложения.
MTU в 400 байт — это вообще, имхо, прошлый век…
Но в данном конкретном случае, поверьте, равно. Для публикации серверов используется реверс-прокси, который един для целой группы серверов. В частности, главная страница сайта yota.ru прекрасно открывалась через SIM МТС, а раздел /voice — нет, так как он завязан на static.yota.ru. При этом и static.yota.ru и сам yota.ru опубликованы через одно и то же оборудование.