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

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

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

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

Можно предложить такую схему: жук достаточно автономен и не нуждается в большом числе команд, поступающих в режиме реального времени; а небольшой набор “медленных” управляющих сигналов может передаваться в защищённом режиме (размазываем по времени и частотам) и восстанавливаться, вычисляться, на борту, при помощи накопления энергии сигнала. Равно та же методика хорошо работает для GPS-приёмников.

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

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

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

Хотя, наверное, как товар от Google – очки с “эсэмэсками” должны пойти хорошо. Тем более, что туда же можно транслировать указания вида “купи вот эту куртку”.

Продолжаем неделю интернет-адресации на 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. Но это пока что планы. Вопросы и пожелания принимаются в комментариях к этой записке.

Поделюсь ссылкой, пожалуй. Прибавляется число локальных узлов одного из корневых серверов:

RU-CENTER и ICANN реализовали совместный проект по инсталляции российского узла сервера L-Root.

Addon (05/04/2012): а вот и сообщение на сайте ICANN.

Вообще, локальных узлов корневых серверов много, адресуются они, обычно, с помощью anycast. То есть, обращаясь к тому или иному серверу по одному и тому же IP-адресу, но из разных сегментов Сети, вы будете попадать на наиболее “близкий” физический сервер. Расстояние тут измеряется в терминах топологии Интернета, конечно. Примерно так результат для l.root-servers.net теперь выглядит “с близкого расстояния”, из московского дата-центра:

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
1 MSK-KHOUSE-NR1.nic.ru (109.70.27.19) 0.772 ms 1.111 ms 1.245 ms
2 MSK-STD-NR1.nic.ru (193.232.147.215) 1.348 ms 1.351 ms 1.458 ms
3 l.root-servers.net (199.7.83.42) 1.226 ms 1.223 ms 1.213 ms

А вот вариант из Ирландии (Amazon, кусочек):

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
[…]
4 ec2-79-125-0-135.eu-west-1.compute.amazonaws.com (79.125.0.135) 0.684 ms ec2-79-125-0-133.eu-west-1.compute.amazonaws.com (79.125.0.133) 0.470 ms 0.453 ms
5 178.236.0.232 (178.236.0.232) 0.816 ms 178.236.0.124 (178.236.0.124) 1.403 ms 1.134 ms
6 178.236.0.124 (178.236.0.124) 1.117 ms 1.127 ms 178.236.0.131 (178.236.0.131) 1.229 ms
7 inex.woodynet.net (193.242.111.60) 2.421 ms 178.236.0.131 (178.236.0.131) 1.158 ms inex.woodynet.net (193.242.111.60) 2.602 ms
8 inex.woodynet.net (193.242.111.60) 2.343 ms 3.063 ms 2.784 ms
9 l.root-servers.net (199.7.83.42) 1.906 ms 1.865 ms 1.615 ms

В общем, больше серверов, хороших и разных.

Ещё немного веб-технологий. Как известно, 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-коннекта (то есть, для ста пользователей – сто “тредов”); с плагином – “тред” был замечен ровно один, вне зависимости от числа коннектов. Поэтому и не падает.

(На правах технократического юмора.) Если вы хотите версию того, как можно вызвать аварию всех 13 корневых серверов глобальной DNS, то вот такой вариант: взломан скрытый сервер VeriSign, с которого раздаётся зона на эти самые корневые сервера. В результате, 31 марта, хакеры распространят испорченную корневую зону. DNS сломается. Не требуется даже генерировать подписи DNSSEC, ведь задача состоит не в том, чтобы подменить адресацию, а в том, чтобы всё сломать.

В ноябре прошлого года при обходе зоны .ru (для доменов вида [www.]domain.tld в DNS искалась А-запись) удалось получить адреса для 2762616 имён. По состоянию на 27.03.2012 – таких имён удалось найти уже 2993620. Прирост – 231004 домена.

По IP-адресам: уникальных IP – 204275. Прирост (относительно 09.11.11) – 16944 адреса. Поделим приросты: 231004/16944 ~13.6 домена на один IP-адрес. Впрочем, это такой очень размытый показатель. Для всей зоны тот же показатель составляет ~14.6 домена на IP-адрес.

Обнаружилось 246624 домена (~8.2%) для которых указано более одной А-записи. Нашлось 14 IP-адресов, на каждый из которых указывает более 10000 доменов .ru. Рекорд, как обычно, за доменной парковкой Sedo – 141407 доменов указывают на один IP, относящийся к этому сервису.

Итак, сайт переехал. Можно использовать комментарии. Если обнаружите какие-то неработающие штуки – сообщайте, пожалуйста, будем исправлять.

(Кстати, логи опять подтверждают, что далеко не везде доверяют TTL из DNS: скажем, YandexBot продолжает приходить и на старый адрес, и на новый.)

В ближайшие несколько часов я возьму в руки пару консолей и попробую перенести dxdt.ru на другой сервер. Поэтому, до сообщения о том, что переезд закончен, лучше не писать сюда комментариев: могут остаться в базе на старом сервере, так как в момент переезда некоторое время будут работать параллельно оба сайта, и на какой вы попадёте – это только DNS знает.

Наверное, помните очередную “сенсацию” в СМИ про “неизвестный язык программирования”, следы которого, как заявляли со ссылкой на “Касперских”, были обнаружены в коде трояна Duqu? Так вот тот мегазагадочный “неизвестный” суперязык программирования оказался, по сообщению всё той же лаборатории, языком C. Во как ловко. Процитирую BugTraq.ru:

Из неопознанности языка делались глубокие выводы о высокой квалификации разработчиков (на чем аналитики ЛК продолжают настаивать и сейчас – мол, выбрать такое экзотическое средство разработки по нынешним объектно-ориентированным временам могли лишь самые хардкорные олдфаги, которые с трудом пересели с ассемблера на C, ну и потом предпочли не связываться с C++, а сымитировать тот же функционал макросами).

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

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

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

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

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