Продолжаем смотреть публичные камеры видео-наблюдения Москвы

Дело было вечером, делать было нечего. Поводом послужила активность пользователя  leider, который дал в комментарии ссылку на публичный ресурс: video.dit.mos.ru/window



Чем примечателен этот ресурс — он предоставляет публичный доступ к камерам видео-наблюдения через встроенный плеер.



В данной статье не будет ни «соли», ни сахара, а только здоровые пища ссылки прямо из печки.

Список ссылок, которые использует плеер на том ресурсе:

http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.1.186_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.0.50_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.41.134_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.23:2033/rtsp___10.194.23.9_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.33:2033/rtsp___10.208.14.117_axis_media_media.amp_camera_2/live

http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.121_live_h264/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.1_live_h264/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.153:2033/rtsp___10.232.0.113_live_h264/live

Включаем логику программиста "влоб!":

• videoproxy2.echd.ru:41025/rtsplive — это прокси
• 10.200.30.33:2033 — это кеширующий сервер
• rtsp___10.208.14.117_axis_media_media.amp_camera_2/live — это ссылка на поток с камеры на сервере.

Рабочие ссылки:

• videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
• videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp

Нерабочие ссылки:

• videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18
• videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:80
• videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:81
• videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8080
• videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8081
• videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:[пачка_rtsp_портов из wiki, так же 7020 и 27020]

Автоматизация поиска

Теория:

• прокся только одна (videoproxy2.echd.ru:41025/rtsplive/)
• порт кеширующих серверов неизменен (:2033)
• хвостик _axis_media_media.amp/live
• хвостик _live_h264/live

Далее, _camera_4 и т.д. не учитывается, так как  существует «10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live» и не существует «10.200.30.24:2033/rtsp___10.208.14.77_axis_media_media.amp_camera_3/live», но следуя логике должна быть обязательно "_axis_media_media.amp/live" — вот их-то и будем искать.

Список IP для кеширующих серверов:

• 10.200.21.21
• 10.200.21.22
• 10.200.21.23
• 10.200.30.24
• 10.200.30.33
• 10.200.26.150
• 10.200.26.153

В идеале как диапазон надо бы выбрать 10.200.21.1--10.200.30.254.

Список IP адресов для камер:

• 10.194.1.7
• 10.194.23.9
• 10.208.0.50
• 10.208.1.186
• 10.208.14.117
• 10.208.41.134
• 10.232.0.113
• 10.232.0.121

Как диапазон (опять же идеальный) берем адреса 10.194.0.1--10.232.255.254 за исключением 10.200.*.* , так как по моей логике (как бы сделал я) — это кеширующие сервера.

В итоге вырисовывается вот такой шаблон для запросов:

• videoproxy2.echd.ru:41025/rtsplive/10.200.ip13.ip14:2033/rtsp___10.ip22.ip23.ip24_axis_media_media.amp/live
• videoproxy2.echd.ru:41025/rtsplive/10.200.ip13.ip14:2033/rtsp___10.ip22.ip23.ip24_live_h264/live

 

• ip13 — 21..30
• ip14 — 0..254
• ip22 — 194..232
• ip23 — 0..255
• ip24 — 1..254

Получаем: 5 миллиардов адресов и запросов… В реальности запросов много меньше и мы к тому же можем экономить 903k запросов за 10-15 секунд простоя скрипта… (об этом ниже).

Успех:

• В случае успеха сервер нам возвращает в Content-type x-flv или обратное условие НЕ text;
• В случае успеха сервер отвечает за 1-3 секунды.

Неудача:

• Сервер отвечает за 200-400мс с text в Content-type;
• Сервер долго думает, если послали запрос к «несуществующему» кеш-серверу, в этом случае надо остановить парсинг по этому серверу и перескочить на IP «выше».

Чтобы минимизировать время парсинга задаем timeout на соединение равный 10000 мс, следом перед запросом и после запроса (когда сервер ответил или сработал timeout на нашем клиенте) сохраняем значение времени. Далее из второго вычитаем первое и если прошло 9500мс или более, то переходит на 1 IP выше (для кеширующего сервера), что дает нам упомянутую выше экономию 903 224 запросов или 104 дня ожидания по 10 секунд!

Так же надо понимать, что ссылки на камеры бегут по кругу, и как заметили в предыдущей статье — камер около 140 000. Сервер спокойно отдает 10 запросов в секунду, так что если мы уже нашли 140 000 камер, то в будущем нам искать их повторно не нужно.

Но парсинг такого количество адресов займет целую вечность, а мы пока не в матрице!

 

Практика

Сокращаем круг поисков:

• 10.200.21.21-24, камеры 10.[194, 208, 232].0-255.1-254
• 10.200.30.21-34, камеры 10.[194, 208, 232].0-255.1-254
• 10.200.26.150-153, камеры 10.232.0-255.1-254

Их прокся спокойно обрабатывает ~10 запросов на 1 поток, пробуем… 8 потоков, 16 потоков… хватит и 16. Итого ~160 ссылок в секунду и поток на уровне 2-3 мегабит, что не нагружает сеть.

Ответ от сервера:

video/x-flv — это если мы получили поток с камеры через их сервер, text/html — если сообщение об ошибке. В программе надо делать условие не нахождения x-flv, а отсутствия text. Потому, что если камера лежит, то сервер просто тупит и мы ничего не получаем, но камера-то есть.

В результате было найдено 608 камер:

IP	.21.23	.21.22	.21.21	.26.150	.26.151	.30.21	.26.152	.30.24	.26.153	.30.23	.30.25	.21.24	.30.22
число	193	176	171	31	10	7	4	4	3	3	3	2	1

• 540 камер _axis_media_media.amp/live
• 68 камер _live_h264/live

 

Уведомления:

• 27 января в полдень было отправлено письмо на dit@, час спустя личка leider чтобы посмотрели почту. В письме было описано что и как работает.
• 28 января так же в полдень — новое письмо на dit-video@, где упомянул, что уже писал на dit@ и что ответа так и не последовало (в каждом письме было указано, что жду новостей)

«Новости»:

• Ссылка на камеру, приведенная в примере была закрыта еще 27 числа… тихо и молча.

Надеюсь, что после этой публикации они введут проверку на videoproxy2, чтобы он выдавал только камеры из проекта «окна». Для прочих камер/всех камер можно поднять blablaproxy2, который нигде не светить и который будет работать по https.

Ссылки по теме:

Страница с плеерами || дамп в формате mysql (описание полей в комментариях).