Как находить проблемы с интернетом и кто виноват ч.1

Многие могут рассказать такую историю :
— Алло, техподдержка провайдера? У меня плохо открывается сайт aaaaaa.com.
— С нашей стороны пули вылетели, проблема в мишени у сайта — пишите туда.

— Привет. Это сайт aaaaaa.com? У меня плохо открывается ваш сайт.
— У нас всё хорошо, пишите провайдеру.

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

Disclaimer: автор знает, что 

  1. Traceroute не всегда покажет проблемы, что маршруты больше про BGP и AS-PATH. 

  2. Автор в курсе про пиринг, асимметрию, MPLS, BGP Communities и что килобайт это 1024 байта.

  3. Маршрут «туда» и «обратно» — два разных маршрута и traceroute разницы не покажет.

  4. Матерые сетевики могут найти очень много неточностей. Эти неточности допущены специально, для облегчения понимания материала не-сетевиками. : D 

За чей счет банкет?

Интернет в России гораздо дешевле интернета, например в Америке или в Германии. Дешевле в несколько раз. Vodafone Kabel в Германии стоит 45 евро в месяц за 500 мегабит.  Это 4000 рублей на момент написания текста. В России, например, у РосТелеком я плачу 1050 рублей в месяц за оптику, по которой приходит 600 мегабит. 

Так как в России не производится коммутационное оборудование, то казалось бы — за чей счет банкет? Ведь железо стоит столько же сколько и в Германии.  Попробуем в этом разобраться.

Путь от пользователя до сервера выглядит, обычно, следующим образом:

5f6c4b7dffc348a51069496b37c81a51

Городской роутер провайдера

Я плачу 1050 рублей в месяц за 600 мегабит. На телеком-рынке стоимость 1 мегабита составляет от 6 до 30 рублей в зависимости от города. Это значит, что 600 мегабит интернета стоит от 3600 рублей. Как же мне РосТелеком продает всего за 1050? Этому есть несколько причин. Одна из ключевых — он продает не только мне. Пользователь обычно не использует интернет на полную катушку 24×7. Поэтому, в тарифе написано — ДО 600 мегабит. С точки зрения математики это выглядит следующим образом:  

В городском роутере есть 10 гигабит интернета. Этот интернет продали 500 пользователям. При этом, каждому продали по 1 гигабиту. И того — продали 500 гигабит. А всего 10. Так как не все пользователи и не всегда качают фильмы с торрентов, то и проблем обычно нет.  Это называется oversell. 

Вечер пятницы

В пятницу вечером проблемы, впрочем, могут начаться. В 17:00 школьники приходят домой с улицы, родители приходят домой с работы. Все садятся за компьютеры и начинают смотреть YouTube/Тикток и так далее. В этот момент как раз и получается, что 10 гигабит на город перестает хватать. 

Для пользователя это выражается в следующем:  

  1. Ухудшается пинг (иногда в несколько раз).

  2. Падает скорость.

Но, давайте будем честными — при пинге до сайта в 4 мс и 20 мс, а также при скорости загрузки сайта в 50 мегабит и 600 мегабит, мы разницы, обычно, не чувствуем — странички грузятся почти так же быстро, видео играется и, в целом, всё хорошо. Сайты нынче стали настолько требовательны к ресурсам компьютера, что важнее стала не скорость интернета, а производительность процессора и память.

Однако, если вы пользуетесь удаленным рабочим столом или ssh — разница ощущается. А в сервисах типа GFN.RU 4 мс и 20 мс input-лага — это не только гораздо хуже картинка, но и разница между жизнью и смертью в Rainbow Six Siege.

Если со скоростью всё понятно, то на пинге стоит остановиться отдельно. Трафик в интернете движется со скоростью света. Независимо от загрузки магистрали, расстояние между пользователем и сайтом не поменялось — почему же пинги стали хуже?

На сетевом оборудовании могут использоваться очереди (PBQ/QoS). Если пакет ушел в сеть, а канал загружен, то он может попасть в очередь и будет там болтаться либо пока не устареет, либо пока у него не появится возможность попасть в канал (пока не рассосется более приоритетный трафик).  

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

Тем не менее, не стоит беспокоиться — TCP/IP (который используется при взаимодействии с сайтами) — протокол с подтверждением доставки. Если что-то по пути потеряется, то потеря будет отправлена еще раз. Для пользователя это будет выглядеть как снижение скорости, которое он не заметит.

UDP (используется обычно для видео/голоса) — более быстрый, но без контроля доставки, данные и правда могут потеряться по пути. Эти потери обслуживаются на более высоком уровне, по сравнению с TCP. В стриминговых сервисах потери UDP-пакетов приводят к снижению битрейта — до тех пор, пока потери не прекратятся.

Стоит так же обратить внимание, что:

  1. Скорость у пользователя ДО 600 мегабит.

  2. Пинг в договоре не прописывается.

  3. Сайт может отдавать пользователю 20 мегабит вместо 600 даже при хорошей скорости от пользователя до сайта. Например, с помощью https://www.nginx.com/blog/dynamic-bandwidth-limits-nginx-plus-key-value-store/. И чтоб защититься от DDoS и краулинга.

  4. Для того, чтоб диагностировать скорость между сайтом и пользователем — нужны специальные инструменты в том числе у сайта, и они должны быть доступны диагносту.

Вывод — в обычной ситуации, доказать провайдеру, что между вами и сайтом проблема где-то у провайдера — практически невозможно. 

Маршруты в большом интернете

После того, как трафик прошел городской роутер и дошел до магистрального роутера, он попадает в интернет. 

Топология интернета напоминает Mesh Сеть Топология интернета напоминает Mesh Сеть

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

BGP

Для выбора по какому маршруту отправить трафик, используется протокол BGP. С его помощью определяется количество узлов между двумя точками. Трафик может быть направлен по маршруту с меньшим количеством узлов (самый короткий AS-PATH). Однако, данный метод не учитывает такой метрики, как расстояние между узлами.  Вполне может произойти, и происходит, что между двумя точками есть, например, два маршрута:

  1. AS123 <--1000km--> AS456 <--50км--> AS888 

  2. AS123 <--5000км--> AS888

Как видим, ASPATH у второго маршрута короче (на нем меньше промежуточных точек) и трафик вполне может пойти по нему. Хотя, напомню, скорость света указывает на то, что первый маршрут будет быстрее.

Загрузка канала и экономика

Обратимся к первой картинке. Видим, что у провайдера есть 3 магистральных канала:  

Оранжевый, синий и зеленый. 

Синий — самый жирный. Например, 8 гигабит. Оранжевый чуть менее жирный. Например, 4 гигабита. И зеленый — самый тонкий: 2 гигабита. 

При этом, синий — самый короткий, оранжевый чуть длиннее и зеленый — самый длинный. 

Казалось бы — всегда используй жирный и короткий, не ходи тонкими и длинными. Но, в реальности, это происходит не всегда.

Канал между двумя точками всегда стоит денег. С точки зрения экономики это выглядит следующим образом:

  1. Арендуется оптическое волокно. В зависимости от ДЦ и жадности владельца оптики волокно стоит по-разному. Иногда, ОЧЕНЬ по-разному. Если на входе в ДЦ есть оптика только от одного владельца, которому, в том числе принадлежит ДЦ, то цена может быть сильно негуманной. Альтернатив-то нет.

  2. По этому волокну организовывается сетевая связь между двумя точками. 

  3. Приобретается предоплаченная полоса трафика. Например, 3 гигабита.

  4. Договариваются о цене на Берсты: когда вместо оплаченных 3 гигабит по каким-то причинам «наливается» 5 гигабит. Обычно, берсты стоят дороже предоплаченной полосы и их стараются не использовать. 

Берст (burst): кратковременное (или не кратковременное) превышение. В данном случае предоплаченной полосы. Провайдер в канале 10 гигабит купил всего 1 гигабит. Он может на самом деле использовать все десять. Всё, что выше купленого — называется берстом или превышением.

95 персентиль (95th percentile, MRTG95). Напоминает медиану (50th percentile). Как считается : берется отрезок времени, например 100 секунд. Разбивается на 100 отрезков по 1 секунде. В каждом отрезке определяется максимальная загрузка канала. Отбрасывается 5 отрезков с самой большой загрузкой. Из оставшихся отрезков находят отрезок с самой высокой загрузкой — это и будет 95 персентиль.

Нюанс с берстами. Загрузка канала считается по 95 персентилям. Это значит, что если в течение месяца канал более чем 32 часа загружен на 10 гигабит, даже если выкуплен 1 гигабит, и средняя загрузка 0.5 гигабит, то … арендатору приходит счет за 10 гигабит. Поэтому, арендаторы стараются избегать берстов и загружать все свои каналы равномерно. 

Всё вышесказанное напрямую влияет как именно ваш трафик пойдет от вас до сервера:  

  1. Во-первых, по самому дешевому каналу.

  2. Во-вторых –по тому, где есть неиспользованная предоплаченная полоса.

  3. В-третьих, если какой-то канал «мигнул» бёрстами, то их потом могут добивать: залил в какой-то резервный канал 10 гигабит в результате аварии на основном канале — значит, до конца месяца можно спокойно в резервный канал лить все 10 гигабит. Счет-то все равно уже придет за 10 гигабит. 

  4. И уже на последнем месте будет учитываться скорость и комфорт пользователя.

Так же стоит отметить, что перегрузка магистрального канала на несколько процентов — пользователями не чувствуется. Да, при перегрузке будут потери пакетов, но, как написано выше — TCP и UDP трафик это спокойно обработает. TCP -на уровне протокола, а UDP — на уровне приложения. 

В интерактивных стриминг-сервисах, увы, это чувствуется — инпут-лаг, рассыпающаяся картинка.

А еще, магистральное оборудование, может и «не понимать», что бюджет канала исчерпан. Если маршруты говорят, что эти 12 гигабит стоит заливать в канал, в котором всего 10 гигабит полосы, то туда Nexus и попробует залить. 

Всё вышесказанное говорит о том, что:   когда вечером все начинают смотреть YouTube, то может как падать скорость, так и появляться потери пакетов. А трафик может ходить очень странными путями.

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

© Habrahabr.ru