dxdt.blog: занимательный интернет-журнал

Кстати, я не так давно писал, что гипотетически возможен вариант с “внешним отключением Интернета“. Однако, насколько можно судить, сейчас в новостях речь идёт не просто об отключении Рунета, а о том, чтобы получить возможность всё же использовать Интернет, в том случае, если от него пытаются отключить внешние силы.

Вообще, разумными представляются действия, направленные на сохранение присутствия в глобальной Сети, вне зависимости от внешних попыток отключения. Действующая сейчас глобальная инфраструктура, конечно, создаёт тут весьма заметные трудности, но их можно и преодолеть. Неотключаемый (для всех) Интернет – был бы наиболее интересен. Однако, он, пока что, невозможен.

Технически, сломать национальный сегмент можно, если ломающая сторона обладает достаточными полномочиями и ресурсами. Тут сомнений быть не может. Ломать, естественно, нужно не на уровне DNS, а на уровне BGP (то есть, на уровне маршрутизации). Если у вас не работает BGP, то национальный сегмент разваливается на множество автономных систем, которые не могут обмениваться трафиком. То есть, нет даже единого интранета. Естественно, DNS при этом тоже не работает. Но локальные сети – остаются. Также, остаётся “локальный” обмен трафиком, если между несколькими автономными системами установлены прямые подключения (“пиры”). Например, у “Яндекса” есть прямые каналы к крупным российским хостингам (возможно, и к зарубежным). Эти каналы не видны для всего остального Интернета. (Не видны – в терминах BGP.)

(Очень интересно будет вспомнить, что отключение Интернета в Сирии, если верить иностранной прессе, произошло из-за ошибки сотрудников АНБ, которые удалённо ковырялись в пограничном маршрутизаторе и – сломали его. Медийное пространство хорошо выстроено, да.)

В 2012 году в Сирии случилась глобальная телекоммуникационная авария, и местные сети (автономные системы) пропали из Интернета. Теперь Эдвард Сноуден рассказывает, что это случилось в результате неудачной операции АНБ по перехвату трафика в сирийском сегменте. Подразделение агентства пыталось удалённо внедрить в программное обеспечение маршрутизатора (Cisco, небось) “дополнительную нагрузку”, но специалисты ошиблись и просто сломали маршрутизатор (такое случается, сложно поспорить). Занятное развитие истории.

Очень занимательная атака: используя подмену путей BGP (routing hijacking), злоумышленники перехватывали результаты работы “майнеров” Bitcoin, которые участвовали в пулах. Напомню, что пулы – это объединения пользователей, которые добывают биткоины. Так как для реализации пулов используется незащищённый протокол, атакующие смогли перенаправлять трафик, адресованный центру, распределяющему задачи по “майнерам”, на свои сервера. Перенаправление проводилось с использованием BGP, на провайдерском уровне. Предметом атаки являлось несколько пулов. Таким образом, результаты добычи биткоинов доставались тем, кто управлял перехватывающими трафик узлами, которые, фактически, отъедали часть мощностей пула. (Подробности – по ссылке выше.)

Доктайп HTML5 стал самым распространённым на веб-узлах Рунета, потеснив XHTML 1.0 Transitional. Строго говоря, это не означает, что HTML5 стал самым распространённым языком разметки: на страницах с доктайпом HTML5 всё равно используются элементы, упразднённые в этом стандарте. Однако популярность HTML5 сильно выросла, а пережитки прошлых стандартов будут встречаться на сайтах ещё долго – тут уж ничего не поделаешь.

Заработал nic.yandex. А www.yandex, почему-то, ещё не сделали. Странно.

“Яндекс” получил очередное одобрение ICANN для своей заявки на домен верхнего уровня yandex. Интересно, что скоро у “Яндекса”, возможно, появится вот такой “короткий” адрес: http://www.yandex/, то есть, без привычного .ru. Совсем строгая запись будет выглядеть вот так: http://www.yandex./ – крайняя справа точка обозначает корневой домен. А вот сделать просто http://yandex/ – пока не выйдет: правила ICANN для New gTLD запрещают.

В День независимости США NASA публикует картинку новой ракетной системы (Space Launch System, SLS), предназначенной, кроме прочего, для вывода на орбиту обитаемого космического корабля Orion (это замена российской космической технике). Пока что ничего из этого не летает, но в перспективе обещают полезную нагрузку в 130 тонн. 130 тонн это много. Первый экземпляр должен вывести пустой Orion в тестовый космический полёт. Нагрузка составит 70 тонн, что тоже является неплохим показателем.

Конечно, важен и такой показатель, как затраты на вывод килограмма груза на орбиту. Но для больших проектов в любом случае нужны сверхмощные ракеты – иначе слишком много элементов придётся собирать на орбите. Орбитальная сборка – тоже не самый дешёвый процесс, тем более, что практического опыта такой сборки крайне мало, а точнее будет сказать: его нет.

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

Определить посещаемость можно при помощи анализа HTTP-трафика, проводимого на сетях провайдеров доступа (либо на точках обмена трафиком, что неплохо подходит для российского сегмента Интернета). То есть, нужно использовать DPI. Наблюдая за трафиком, относительно несложно посчитать число заходов браузеров на заданный ресурс. Думаю, основная идея метода достаточно очевидна: считаются GET-запросы, содержащие заданный URL. Не обязательно даже следить за всем потоком трафика: полные данные можно вычислить по некоторой выборке.

Есть ещё дополнительные косвенные методы. Например, запросы к серверам DNS, скажем, к корневым. Частота запросов о заданном имени хоста (об адресе сайта) связана с посещаемостью этого сайта. Правда, запросы выполняют рекурсивные резолверы, поэтому собранную статистику нужно “нормировать” по числу клиентов, обслуживаемых тем или иным резолвером. (Последняя величина, кстати, тоже косвенно определяется из наблюдений за DNS-запросами, а точнее – за вариативностью этих запросов, приходящих от разных резолверов; грубо говоря, данные выдаёт “дисперсия”, но это детали.)

Другое дело, что такое понятие, как “посещение сайта интернет-пользователем”, – оно очень размыто, для него нет определения. Это одна из фундаментальных проблем всякой веб-аналитики: строго говоря, пользователи никогда не заходят на сайты – это делают их компьютеры. Можно подумать, что это излишняя придирка к терминам, но это не так: представьте, что персональный компьютер без ведома пользователя заражён вредоносной программой, и запросы к сайтам делает именно эта программа. Результат запроса пользователю не показывается, то есть он заведомо не просматривает страниц. Нередкая ситуация в современной сетевой реальности.

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

В свете очередных сообщений СМИ о планах “преобразования” национального сегмента Сети, вот что нужно сказать: в идеальном мире адекватным ответом на попытки получения тотального доступа к пользовательским данным одной из сторон, действующей в глобальной Сети, было бы не огораживание “на своих серверах”, а разработка и продвижение технологий, сохраняющих приватность пользовательских данных в условиях “открытого” Интернета. Существующий математический аппарат позволяет так устроить протоколы и архитектуру сервисов, что у каждого пользователя будет контроль над доступом к его данным, вне зависимости от того, на каких серверах глобальной Сети они вдруг находятся.

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

Да.

Наш мир, конечно, не идеален.

(Политические комментарии – буду удалять. Надеюсь на понимание.)

Несколько часов назад в корне DNS делегированы столичные домены moscow и москва (кириллический). Проверить, как они работают, можно здесь:

http://nic.moscow/
http://nic.москва/

Некоторое время назад я оценивал, сколько нужно хранить трафика, чтобы иметь более или менее полный слепок пользовательской активности в Рунете за 12 часов (отдельная записка посвящена тому, как этот трафик принимать и обрабатывать). Сейчас актуальная тема – хранение неких “метаданных”, под которыми подразумевается лог действий в некоторой “системе обмена сообщениями”. Лог доступен за период в шесть месяцев. Сколько требуется пространства для решения этой задачи?

Если оценивать нижний предел, то совсем немного. Естественно, всё зависит от того, насколько детальные метаданные требуется сохранять. Пусть записываются только факты “контакта” между пользователями, взятые с точностью до суток. Под “контактом” подразумевается отправка сообщений: если отправлено одно или более сообщений – значит, был контакт в заданные сутки (число сообщений и направление передачи – не уичтываем). Предположим, что типичный пользователь в сутки контактирует с десятком других пользователей (это вполне реальный показатель).

Итак, для перечисления интернет-пользователей всякой популярной системы достаточно 32 бит или четырёх байтов (2^32 это примерно 4,2 млрд), поэтому запись идентификаторов для контактов заданного пользователя потребует 4*10=40 байтов за сутки. Добавляем сюда отпечатки времени – 3 байта на запись (с точностью до секунд в сутках + служебные биты). Получаем: 40+3*10=70 байтов за сутки. Очень мало. (Можно легко засунуть сюда и тип используемых сервисов, кстати.)

Рассмотрим другое, более технологичное, представление, где контакт – это пара идентификаторов и метка времени (ID1,ID2,T): 4+4+3=11 байтов на запись, а записи хранятся в единой БД, общим потоком. Если посмотреть на такую структуру данных, взятую “по модулю” одного пользователя, то получим оценку в 110 байтов в сутки на пользователя (естественно, тут есть простор для оптимизации). То есть, за 180 дней (примерно шесть месяцев): 180*110=19800 – около 20 килобайт данных за сутки на каждого пользователя. Для десяти миллионов – всего-то 200 гигабайт (без оптимизации кодирования, заметьте).

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

Другое дело, если требуется хранить подробный лог, в котором, например, отражено, как именно взаимодействовали пользователи, куда каждый из них ходил, сколько сообщений отправил, что нажимал, сколько времени провёл за тем или иным занаятием. В таком случае необходимый объём данных легко вырастет на два порядка. А ведь занятно, что и 20 терабайт (200Gb*100) – тоже не выглядят пугающе.