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

Занимательно видеть, что, например, на сайтах российских автодилеров, где они стараются продавать автомобили, используется “Яндекс.Метрика”. Согласно пользовательскому соглашению, “Яндекс” может использовать данные, собираемые “Метрикой”, в своих целях. Соответственно, почему бы ему не использовать эти данные для повышения качества “таргетирования” рекламы в “Яндекс.Директе”? А в “Директе”, тем посетителям, которые ушли с сайта автодилера и теперь путешествуют по другим, даже не автомобильным сайтам, показывается реклама конкурентов. Лучше всего, если объявления содержат те же модели, которыми конкретный посетитель интересовался.

Риск, в общем-то, хорошо известный. Думаю, что и Google, и другие системы массовой статистики, могут поступать так же. Тем не менее, коды на “продающие сайты” ставят стандартно. Очень грубая оценка даст нам примерно 15-20% потерь клиентов в направлении конкурентов через данную схему. Забавно, что, в таком случае, на “закрытом” рынке, некий автодилер мог бы заработать при помощи сайта дополнительно эти самые 10-15%, всего лишь убрав со страниц внешние “шпионские счётчики”. Ну, окей, понятно, что нужно нормировать расчёт по выручке и так далее, что нужно ещё исследовать, уводит ли “Директ” посетителей таким образом, но сумма-то может выйти весьма заметной, не факт, что использование той же “Метрики” позволяет поднять продажи на сравнимую величину. А код – всё равно на сайтах.

С относительно недавних пор WordPress получил функцию автоматического обновления. То есть, и раньше-то эта CMS была среди лидеров по удобству процедуры обновления: кликнул на кнопку в панели управления – всё успешно обновилось (не чета, например, Drupal-у, который до сих пор требует ручного накатывания файлов обновления, что, конечно, не слишком удобно). А теперь для обновления WordPress-а и кнопку нажимать не нужно: скачивает и накатывает новые файлы он самостоятельно, тихо, никого не спрашивая. Присылает e-mail по результатам обновления. Замечательная практика.

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

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

Кстати, на сайте 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 млн долларов.)

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