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

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

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

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

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

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

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

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

Мы оцениваем трафик порядка терабита в секунду (это верхний предел, определённый из объёмов 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 млн долларов.)

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

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

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

Как известно, перехват HTTPS проще реализовать при участии удостоверяющего центра, который, технически, может выпустить особый сертификат, позволяющий перехватывающему узлу выдать себя за легитимный сервер, с которым планировал соединиться пользователь. Эта особенность протокола ставит удостоверяющие центры в положение, когда их (вполне обосновано) постоянно подозревают в выпуске “перехватывающих сертификатов”. Или, как минимум, в содействии такому выпуску. После недавних “разоблачений АНБ” эта, чисто административная ситуация, сильно обострилась. Проблем добавляет и тот факт, что стандартные средства TLS/SSL, изначально разработанные для защиты коммерческих транзакций, выполняемых через Интернет, сейчас используются жителями разных стран с целью защиты личных сообщений и прочих важных данных.

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

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

Впрочем, нужно подождать, посмотреть, что выпустят производители браузеров.

В продолжение записки о том, что внутри W3C на полном серьёзе обсуждают внедрение механизмов DRM в стандарты HTML. Речь, в частности, идёт о некоем предложении под названием Encrypted Media Extensions (EME). Похоже, планируется использовать известную схему: в браузере должен быть некий программный интерфейс, позволяющий не только управлять исполнением кода снаружи, но и внедрять внешний код в браузер, прозрачно для пользователя.

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

В “Мозилле”, кстати, уже появился “баг-репорт”, требующий запрета реализации DRM в браузере. Посмотрим, как дело будет развиваться.

W3C продолжает сходить с ума. Во-первых, там никак не откажутся от введения в стандарты механизмов DRM. Во-вторых, дошли уже до того, что формируют под своим крылом рабочую группу, цель которой (буквально!) защитить стандартами исходные коды браузерных HTML5-приложений от просмотра пользователями браузера. Цитата из описания целей группы: “this group intends to find mechanisms of code protection for web apps, especially for packaged apps, making the source codes (e.g. HTML, CSS, JavaScript), as well as relevant resource files (image, audio and video, etc.) cannot be seen easily“. То есть, намереваются стандартизовать запрет на просмотр пользователем исходного кода веб-страницы (грубо говоря, нельзя будет использвать CTRL+U). Вот такие феерические задачи нынче ставит перед собой W3C.

Не исключено, что вся эта история с документами NSA от Сноудена – есть хорошо спланированный асимметричный ответ на трансграничное распространение Интернета, на ключевую роль Штатов в этом новом сегменте киберпространства. Ведь сейчас эта история, в подаче крупнейших СМИ, выглядит уже вот так: Интернет – не более чем инструмент для тотальной слежки за гражданами США и, попутно, за гражданами других стран; но последняя особенность – это что-то вроде нехорошего побочного эффекта, хотя, конечно, штатовское правительство пытается за него ухватиться, выдав за основное предназначение всего масштабного проекта.

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

Tor – один из самых популярных в Интернете методов “анонимизации”. Число пользователей (или клиентов) Tor за прошедший месяц выросло в четыре, примерно, раза, о чём свидетельствует статистика с сайта проекта:

Впрочем, в блоге Fox-IT пишут, что причина тут, возможно, не в возросшем интересе к “анонимизации”, а в ботнетах, которые стали активнее использовать Tor для связи между узлами и центрами управления.