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

Кстати, на сайте RU-CENTER, принимающем предварительные заявки на регистрацию доменов в новых зонах, можно ощутить, куда же катится DNS – чего там только не будет, на новом верхнем уровне: new.nic.ru.

Завтра Индия запускает космический аппарат к Марсу. Проект называется Mars Orbiter Mission (MOM). Планируется, что аппарат, находясь на околомарсианской орбите, будет собирать данные об атмосфере Марса, а также о его поверхности. Но, понятно, что основная задача – вообще добраться до красной планеты: для индийской космической программы это первый столь сложный проект.

Lockheed Martin рассказывает про теоретическую разработку гиперзвукового летательного аппарата SR-72. Напоминают, что хорошо сейчас известный SR-71 установил рекорды скорости полёта, державшиеся несколько десятилетий.

SR-72 должен достигать скоростей порядка M=6. Запланирована комбинированная двигательная установка, включающая турбореактивный двигатель, служащий в роли основного до скорости M=3. Сразу же рассказывают об ударном потенциале такого сверхскоростного аппарата, оснащённого, к тому же, гиперзвуковыми ракетами. Действительно, гиперзвуковые беспилотники, в качестве платформы для быстрой доставки ракетного оружия на территорию, прикрытую классическими системами ПВО – это одна из самых перспективных тем.

Lockheed Martin разместили только краткое сообщение, а развёрнутая статья по теме опубликована Aviation Week.

Пару месяцев назад, в заметке о перехвате HTTPS, я писал:

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

Кто бы сомневался: Wired сообщает, что NSA буквально так и делает с трафиком Google.

Сообщают, что президент ICANN высказался насчёт изменения юридического положения корпорации:

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

На видео, которое доступно по ссылке ниже, запись, сделанная с борта самодельного беспилотника. Аппарат успешно выполнил облёт заинтересовавшего его владельца судна, забравшись примерно на пять километров от берега. Интересно.

(Видео на YouTube.com.)

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

Пишут, что в Штатах спустили на воду эсминец класса Zumwalt, для достройки. (Церемонии не было. По ссылке есть фотографии.)

В продолжение предыдущей записки о системе хранения интернет-трафика. Понятно, что мало найти место для хранения трафика, нужно ещё решить ряд других непростых задач: во-первых, трафик нужно как-то заливать в хранилище; во-вторых, нужно предоставить доступ (с поиском и разными выборками) к сохранённому трафику.

Мы оцениваем трафик порядка терабита в секунду (это верхний предел, определённый из объёмов MSK IX). Конечно, напрямую заливать терабит в систему хранения через один порт технически невозможно. Поэтому для приёма трафика требуется построить некий распределённый многопортовый шлюз. Это большая проблема. Дело даже не в том, что гипотетический сверхпроизводительный элементарный узел сможет обрабатывать не более гигабита в секунду и таких узлов потребуется тысяча, а в том, что поступающий трафик нужно будет корректно сортировать по ряду признаков. Сортировка нужна хотя бы для того, чтобы удалить дубликаты пакетов и верно определить источник и получателя для каждой сессии. Тем не менее, эта проблема решается. Узлы, составляющие принимающий шлюз, могут быть размещены на разных площадках: не обязательно организовывать подключение в одной точке. Между узлами потребуется построить собственную сеть обмена “метаинформацией” о том, кто и что сохраняет. Очищенный на местах трафик отправляется в центральное хранилище.

Отдельная сложность – поиск в базе данных, имеющей объём около трех петабайт. Вспомним, что речь идёт о данных, которые перезаписываются каждые 12 часов. То есть, поиск должен быть быстрым, так как каждый час, затраченный на выборку, означает, что часть данных, которые могут потребоваться для уточняющих запросов, уже удалена. Возьмём экстремальный случай и предположим, что для выполнения запроса требуется перебрать 10% собранных данных. Пусть объём всей базы 2,7 петабайта, тогда 0.1 это 270 терабайт. Если наш “процессинговый центр” обрабатывает гигабайт в секунду (чрезвычайно быстро), то для перелопачивания 270 терабайт потребуется 75 часов. А это означает, что обработка уже не имеет никакого смысла. Не нужно, впрочем, делать вывод, что из подобной системы хранения нельзя извлечь ничего полезного.

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

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

Предположим, что у нас есть гигабитный канал и нам нужно записывать весь проходящий интернет-трафик, на уровне IP, вместе с заголовками и служебной информацией. Сколько потребуется места в хранилище? Гигабит – это не более 125 мегабайт в секунду. 125 Mb * 3600 = 450 гигабайт в час. Объём буфера на 12 часов не превысит 450*12 = 5,4 терабайт. Удобно использовать хранилище, построенное на базе SSD. А если прикрутить к хранилищу пару мощных процессоров, то (нешифрованный) трафик можно будет на лету сжимать, раза в два: получаем 2,7 терабайта.

Вернёмся к объёмам трафика. На MSK-IX говорят о терабите (в секунду, понятно), как о некоторой важной отметке. Пусть это действующий верхний предел, определяющий понятие “большой объём трафика” для масштабов Рунета. Терабит (примем, что это 1000 гигабит), взятый за 12 часов, согласно расчётам из предыдущего абзаца, поместится в хранилище, имеющее объём 2,7 петабайта. Объём приличный, да. Пусть 100 Gb на SSD, вместе с доступом, стоят около $50, тогда затраты на диски составят 500 тыс. долларов США (поправка: это на петабайт, то есть, полный комплект – 1 млн 350 тыс. долларов). Понятно, конечно, что само хранилище будет стоить существенно дороже, но ничего фантастического в этих, примерно, трёх петабайтах – нет.

(Дополнение 25/10/13. Посмотрим на расценки сервиса хранения данных Amazon S3: размещение 2,7 петабайта обойдётся в 2,7 * 55000 = 148500 долларов США в месяц, по тарифу US Standard; это, конечно, только хранение данных с резервированием, извлечение, а также быстрый доступ вообще, потребуют дополнительных затрат. 148,5 тыс. ежемесячно – дают нам 1 млн 782 тыс. в год. То есть, можно предположить, что соответствующее хранилище обойдётся где-то в 7-10 млн долларов.)

Продолжение: сбор и обработка трафика.

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

• Исторические “распознавалки” речи;
• Skype и перехват его трафика;
• Запись (возможная) всех телефонных разговоров в Штатах;
• Смартфоны-шпионы: куда податься?
• Аппаратные закладки на уровне полупроводников.

На картинке ниже – рост числа российских и зарубежных хостингов, на которых размещаются сайты под доменами .RU (то есть, сайты Рунета). Зарубежные хостинги – это нижний график, красный. За год он хорошо приблизился к хостингу российскому.

Источник данных: stat.nic.ru.