Провайдеры

TL;DR: Эксперты делятся видением проблем в России, связанными с цифровым правом на доступ к Интернету.

12 и 13 сентября Теплица социальных технологий и РосКомСвобода проводят хакатон по цифровому гражданству и цифровым правам demhack.ru. В преддверии мероприятия организаторы публикуют четвертую статью, посвященную картированию проблемного поля для того, чтобы программисты и активисты смогли найти для себя интересный вызов. Предыдущие статьи: по праву на публикацию цифровых произведений можно найти здесь (часть 1), на доступ к информации здесь (часть 2), на анонимность (часть 3) здесь.

Право на доступ к Интернету

Право на доступ к Интернету (право на Интернет-доступ, право на соединение) подкрепленное юридическими нормами убеждение, что все люди должны иметь беспрепятственный доступ ко Всемирной сети, т.к. только при наличии доступа они могут осуществлять свои права на самовыражение, свободу слова, собрание.

В 2016-м году Совет по правам человека ООН принял резолюцию A/HRC/32/L.20, которая, к сожалению, не приравняла доступ к Интернету к базовым правам человека, как об этом писали некоторые СМИ, но зафиксировала ряд важных деклараций:

1. те же самые права, которые человек имеет в офлайновой среде, должны также защищаться в онлайновой среде, в частности свобода выражения мнений, которая применима независимо от границ [].

2. ООН безоговорочно осуждает меры по умышленному недопущению или нарушению доступа к информации или ее распространения в режиме онлайн.

Несмотря на то, что глобально право на интернет-доступ (пока) не включено в универсальную декларацию прав человека, часть стран (Коста-Рика, Эстония, Франция и др.) признает доступ в Интернет как право человека.

В России право на доступ к интернету следует из прав и свобод, описанных в статье 29 (даже несмотря на апдейт 2020).

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

Это ощущение в 2008-м году недвусмысленно выразил пользователь Антон Уральский, вписавший себя в историю в роли автора мема Ни единого разрыва. Антон был на нервах, использовал ненормативную лексику, угрожал судебными тяжбами и т.д. Но пусть только тот, кто жестоко не обламывался от отсутствующего интернета и не клял провайдеров в три матери, бросит в Антона виртуальный камень.

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

В теории систем такие свойства называют эмерджентными, т.е. такими, которые присущи системе в целом, но не присущи к её элементам в отдельности. В отличие от аналогии с электричеством, водо- и теплоснабжением, существует тонкая, но ощутимая разница между большими локальными сетями (даже настолько большими, что покрывали бы целые страны) и Интернетом.

Некоторые из обсуждавшихся сюжетов:

1. Блокировки сайтов, протоколов, приложений;

2. Локальные шатдауны;

3. Неполитические вопросы доступа к Интернету (удаленность, экономические, демографические ограничения).

Сюжет 1. Блокировки сайтов, протоколов, приложений

В рамках круглых столов к праву на доступ к Интернету мы отнесли и доступность отдельных сайтов, как элементов Интернета, хотя доступ к сайтам, сервисам и порталам также относится и к целому ряду других цифровых прав.

Проблема 1.1.: Сложно определить, заблокирован ли сайт или просто не работает. Следовательно, сложно доказать, что сайт заблокировали, а не то, что у админа лапки.

Вариант решения на хакатоне: инструмент, который подтверждал или каким-то образом предполагал бы гипотезу о причине неработоспособности того или иного сайта. Частично, информацию о блокировках в России, предоставляет отличнейший плагин РосКомСвободы. Но на данный момент плагин обращается только к списку заблокированных сайтов, в то время как блокировки могут происходить не только официально. А еще могут быть DDOSы и другие неприятные истории. Достаточно взглянуть на то, что происходит в одной соседней стране.

Проблема 1.2.: проблема доведения до сведения общественности факта блокировки. Нет инструкции действий при блокировке.

Варианты решения на хакатоне:

1. сайт, который позволяет промониторить и дать инструкции, с шаблонами жалоб на блокировку.

2. маркетплейс для юридических фирм, которые бы обжаловали блокировки и фандрейзинг на поддержку юристов.

Проблема 1.3.: Проблема восстановления доступности. Ок, заблокировали и что дальше? Часто админы не знают, что делать после блокировки.

Проблема 1.4.: Проблема возможного скрытия объема блокировок. В какой-то момент блокировки могут попытаться законодательно скрыть. Другими словами, может произойти снижение государственной транспарентности в области ограничения информации.

Варианты решений на хакатоне:

1. найти способы визуализировать проблему с блокировками.

2. сделать реестр запрещенных сайтов распределенным.

Проблема 1.5.: неоднородность блокировок у разных провайдеров. У разных провайдеров разные технологии. Сюда же относится и т.н. проблема переблокировок когда сайт недоступен, но уже должен быть доступен.

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

Сюжет 2. Локальные шатдауны

Подпись к твиту: Минск плавно исчезает с радаров. Источник: NetBlocks.

Шатдаун (англ. отключение) временное отключение Интернета на ограниченной территории. Шатдауны незаконны и приносят прямые экономические убытки, а также напрямую нарушают гражданские права и свободы.

Проблема 2.1.: Недостаточная популярность и недостаток сообщества людей, которые могли бы мониторить шатдауны. Нет методики мониторинга шатдаунов, нет юридической значимой методики фиксации шатдауна.

Варианты решений на хакатоне:

1. разработка методики мониторинга и фиксации шатдаунов;

2. использование ИИ в маршрутизации пакетов (адаптивные протоколы по передаче данных);

3. доработка существующих решений, которые помогают пользователям во время шатдаунов (например, Psiphon).

Проблема 2.2.: отсутствия информации о том, что делать во время шатдауна пользователям.

Варианты решения на хакатоне:

1. Использование Mesh-сетей (интернет-коммуны)

2. Использование альтернативных методов подъема сетей.

3. Ресурс с информацией о том, что делать с юридической точки зрение, если в городе шатдаун. Шаблоны, обращения, примеры, гиды.

Сюжет 3. Неполитические вопросы доступа к Интернету (удаленность, экономические, демографические ограничения)

Проблема 3.1.: Высокая дифференциация по уровню доступа к Интернету в России.

Проблема 3.2.: Люди не представляют, что качество доступа в интернет может влиять на их другие права. Низкий уровень грамотности.

Варианты решений для 3.1. и 3.2.: просветительские проекты, онлайн-оффлайн кампании по просвещению о том, что доступ в интернет гражданское право.

Проблема 3.3.: Не хватает исследований, как именно люди пользуются интернетом, как интернет влияет на экономику, как качество интернета влияет на экономический рост, как шатдауны влияют на экономику. Нет изучения условий доступа к интернету в России.

Вариант решения на перспективу: создать исследование о российских пользователях интернета.

Организаторы хакатона надеются, что выявленные вызовы послужат благодатной почвой для решений на хакатоне (да и вообще).

Теплица социальных технологий и РосКомСвобода благодарят всех экспертов, принявших участие в круглом столе. Зарегистрироваться на хакатон цифрового гражданства и цифровых прав demhack.ru можно до 8-го сентября 2020 г.

Многие могут рассказать такую историю :
- Алло, техподдержка провайдера? У меня плохо открывается сайт 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 мегабит.

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

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

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

Я плачу 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. Для того, чтоб диагностировать скорость между сайтом и пользователем нужны специальные инструменты в том числе у сайта, и они должны быть доступны диагносту.

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

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

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

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

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, то может как падать скорость, так и появляться потери пакетов. А трафик может ходить очень странными путями.

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