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

Тут Артемий Ломов сделал специальную страницу, имитирующую медленную загрузку элементов в браузер – можно вживую посмотреть, как отрисовываются разные блоки и “применяются” стили. Страница находится на сайте WebHiTech-а.

Продолжаем неделю интернет-адресации на dxdt.ru. Я подумал, что данные по адресации внутри домена .ru, которые я извлекаю из DNS для того, чтобы собирать SSL-сертификаты с работающих веб-сайтов, довольно занятны сами по себе. В общем, сделал такой вот сервис: http://adr.dxdt.ru/ – он позволяет получить список доменов, а вернее, имён хостов, которые соответствуют заданному IP-адресу. Работает только для .ru. И не в режиме онлайн. Запросы можно делать простым GET-ом, формат описан на странице сервиса: там вообще только Apache, это такой очень простой сервис.

(Интересности: есть немало имён с адресом 1.1.1.1 или с адресом 0.0.0.0; само собой, распространен 127.0.0.1.)

Есть идея туда же прикрутить базу SSL-ей, тогда можно будет посмотреть, какие сертификаты видны для данного IP. Но это пока что планы. Вопросы и пожелания принимаются в комментариях к этой записке.

Ещё немного веб-технологий. Как известно, dxdt.ru работает на WordPress (WP). Ещё лучше известно, что связка Apache+PHP+MySQL+WordPress – это монструозный источник нагрузки для сервера. Надо сказать, что так как большого трафика на dxdt.ru нет, то я никогда не тратил время на “повышение нагрузочной способности” этого конкретного веб-сайта. Но тут таки на досуге попробовал установить нахваливаемый многими плагин для WP – W3 Total Cache (W3TC). Оказалось, что, да, нахваливают обоснованно.

В случае с dxdt.ru, означенный плагин исправил ситуацию самым кардинальным образом. До установки плагина, тестирование (в терминологии blitz.io) двумя сотнями одновременных пользовательских коннектов приводило к тому, что сервер капитально ложился через несколько секунд (причину я не расследовал, но, похоже, что множество набежавших Apache+MySQL съедало всю доступную память). После установки и настройки этого самого W3TC – работоспособность, при тех же условиях, сохраняется, хотя часть “пользователей” (~8%) теряется. Неплохо, на мой вкус. Думаю, что соответствующий трафик – примерно 5 млн хитов в сутки – dxdt.ru не грозит. Да и “длительное” время ответа (~500 ms) не должно беспокоить.

Пояснение (03.04.12):

Насчёт времени ответа: всё просто, речь же шла о тесте из штатовского дата-центра, а dxdt.ru размещается в Ирландии, поэтому время ответа такое “большое”, пакетам требуется дважды пересечь океан. Сам сервер генерирует страницы примерно за 30-60 ms.

Дополнение:

Да, о настройках W3TC. Я использовал кэширование на диск и включил дополнительные правила mod_rewrite, как рекомендуют в описании плагина. То есть, это самая простая конфигурация. Но эффект заметен, так что – рекомендую.

Дополнение-2 (01.04.12):

Посмотрел на причину падений без плагина. Всё так и есть: без плагина W3TC, благодаря особенностям работы mod_php, Apache поднимает отдельный “тред” MySQL для каждого http-коннекта (то есть, для ста пользователей – сто “тредов”); с плагином – “тред” был замечен ровно один, вне зависимости от числа коннектов. Поэтому и не падает.

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

Статистика: встретилось 533 клиентских устройства WiFi. Обратите внимание: это не точки доступа, которых повстречалось более 1500 штук, а разные планшеты, смартфоны, ноутбуки и тому подобные штуки. Всё это время автомобиль находился на разных городских улицах, не во дворах, то есть, разумно предположить, что большая часть – мобильные устройства. (И это не метро! Там плотность устройств была бы выше, это очевидно.) Из 533 устройств 363 (~68%) не были, в момент обнаружения, привязаны к точке доступа. То есть, это неплохо подтверждает гипотезу о преобладании мобильных устройств в полученной выборке.

Так вот, 130 устройств передавали в эфир список идентификаторов точек доступа, к которым они ранее подключались. Я писал об этой особенности реализации WiFi раньше. 130 штук – это около 24%, примерно четверть. Немало, да.

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

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

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер DNS, налаженный внутри VPN?

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

Понятно, что в случае с собственным VPN-соединением, запущенным через “чужую” сеть, определять адреса серверов может всё тот же провайдерский резолвер. В конце концов, через VPN ходит TCP/IP, а не символьные имена доменов. После того, как резолвер определил IP-адрес сервера, соединение будет устанавливаться уже через VPN.

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

Другое решение – держать рекурсивный резолвер локально, на своём ноутбуке. Я не уверен, может ли это делать Windows (наверное, может), но с юниксоподобными системами проблем нет, достаточно поднять локальный BIND. Трафик резолвера нужно завернуть в VPN, это обеспечит секретность. (Тут есть подводный камень: использование NAT, – а трафик из VPN во внешний мир может выходить именно через NAT, – грозит тем, что испортится один из защитных механизмов DNS, который называется “рандомизация портов UPD на источнике запроса”; но это другая история.) А главный недостаток один: нужно на каждом клиенте VPN держать свой рекурсивный резолвер. Неудобно. Поэтому куда более логично разместить собственный резловер на сервере, обеспечивающем VPN. Всё равно этот сервер работает постоянно.

А кроме того, редкий провайдерский резолвер поддерживает DNSSEC. Я таких вообще не видел.

(И, хорошо, можно использовать открытые сервисы, наподобие Google public DNS, но это всё ж не то решение, которое сравнится с собственным резолвером. При этом гугловский сервис быстрее. В моём случае – заметно быстрее.)

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

Автор теста – Артемий Ломов.

Микроэлектронные комплектующие, которые производятся и закупаются за рубежом, могут содержать в себе аппаратные закладки (строго говоря, и отечественные микросхемы тоже могут содержать закладки, но это уже другая категория рисков). Понятно, что такие закладки могут вредить оборудованию, в составе которого используются вредоносные микросхемы. Тут нетрудно наметить сразу несколько направлений борьбы.

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

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

Занятно, что новые веб-технологии стороны клиента содержат всё больше и больше разнообразных “алгоритмических” добавок, работающих без всякого Javascript. Например, в технологии Media Queries есть логические выражения, преобразование которых проводит браузер, оперируя разными свойствами доступного окружения операционной системы (типа размера окна и так далее). Поделюсь парой полезных ссылок по этой теме, это статьи проекта WebHiTech:

• С удобством от устройства к устройству. Часть 1;
• С удобством от устройства к устройству. Часть 2.

А вообще, такое развитие – прямой путь к появлению всевозможных новых уязвимостей. Интересно, возникнут ли вредоносные программы, распространяющиеся исключительно внутри файлов CSS?

Кстати, вот долгоиграющая тема – мимикрирующий под домен “Проверка.РФ” адрес http://проверка.рф⁄click.dxdt.ru/. Я завёл этот адрес в 2009 году, в демонстрационных целях. Надо сказать, что браузеры с тех пор сильно улучшились, данный “кривой” адрес отображают хорошо, в Punycode. А вот Google пока что не меняется. Как и раньше, на странице выдачи по запросу “Проверка.рф” домен отображается кириллицей, результат неотличим от адреса под настоящим кириллическим доменом верхнего уровня. Впрочем, про это я уже рассказывал полтора года назад, со скриншотом.