Совет по архитектуре - удаленный доступ к веб-камере [закрыто]
Мне нужен совет по архитектуре. У меня есть клиент, для которого я создал веб-сайт, который позволяет пользователям удаленно просматривать свои веб-камеры.
Текущий поток данных выглядит следующим образом:
Пользователь открывает страницу для просмотра изображения с веб-камеры. Скрипт Javascript опрашивает URL-адрес на сервере (с добавлением уникальной метки времени) каждые 1000 мс.
Ftp-соединение включено для пользователя ftp камеры. Веб-камера открывает ftp-соединение с сервером. Веб-камера начинает делать фотографии. Веб-камера отправляет фотографию на ftp-сервер.
По запросу URL изображения: Сервер читает последнее изображение на жестком диске, загруженное через ftp для камеры. Сервер удалил все старые изображения с сервера.
В настоящее время это работает нормально для небольшого количества пользователей / камер (около 10 пользователей и примерно такое же количество камер), но мы начинаем беспокоиться о масштабируемости этого подхода.
Мой первоначальный план заключался в том, чтобы вместо чтения файлов с сервера веб-сервер открывал ftp-соединение с веб-сервером и считывал последние изображения прямо оттуда, что означало, что мы могли довольно легко масштабировать по горизонтали. Но время установления ftp-соединения было слишком медленным (в основном из-за того, что PHP не может поддерживать ftp-соединения), поэтому мы отказались от этого подхода и сразу приступили к чтению с жесткого диска.
Поставщик микропрограмм для камер заявляет, что они могут создать http-клиент, который вместо использования ftp для загрузки изображения может отправить изображение на веб-сервер. Мне это кажется достаточно правдоподобным, но я ищу совета по архитектуре.
Сейчас я думаю о простом стеке Nginx / PHP / Redis.
Веб-камера отправляет почтовые запросы последнего изображения в Nginx / PHP, и последнее изображение для этой камеры сохраняется в Redis.
Затем клиенты могут получить последнее изображение из Redis, что должно быть очень быстрым, поскольку изображения всегда будут храниться в памяти.
Тогда поток данных будет выглядеть следующим образом:
Пользователь открывает страницу для просмотра изображения с веб-камеры. Скрипт Javascript опрашивает URL-адрес на сервере (с добавлением уникальной метки времени) каждые 1000 мс
Камера отправляет HTTP-запрос, чтобы начать публиковать изображения по указанному URL-адресу Веб-камера начинает делать фотографии. {{1} }} Веб-камера отправляет почтовые запросы на сервер так быстро, как только может
При запросе URL-адреса изображения: Сервер читает последнее изображение из redis Сервер сообщает redis об удалении более позднего изображения
Мои вопросы are:
- Есть ли дополнительные накладные расходы при передаче изображений через HTTP вместо FTP?
- Есть ли простой способ подсчитать, сколько потенциальных камер мы могли бы иметь потоковую передачу одновременно?
- Есть ли способ предотвратить потенциальную загрузку DOS наших серверов из-за запросов веб-камеры?
- Является ли Redis хорошим решением этой проблемы?
- Следует ли мне отказаться от комбинации PHP / Ngix и заняться чем-то другим?
- Действительно ли это предлагаемое решение хорошо?
- Не приведет ли добавление HTTP в микс слишком медленно к публикации изображения?
Заранее спасибо
Алан
Есть ли большие накладные расходы при передаче изображений через HTTP? вместо FTP?
Не совсем. HTTP легче ускорить и кэшировать, чем FTP.
Есть ли простой способ подсчитать, сколько потенциальных камер мы могли бы иметь потоковую передачу сразу?
Один поток MPEG4 с разрешением 1080p составляет около 10 Мбит. Это приблизительная цифра. Вы должны иметь возможность масштабировать это до вашего фактического разрешения.
Есть ли способ предотвратить потенциально DOS-загрузку наших серверов из-за запросы веб-камеры?
Масштабирование. Я использовал хороший прокси-сервер MJPEG для Node.js , который масштабируется лучше, чем встроенный видеосервер камеры.
Redis - хорошее решение этой проблемы?
Наверное, не хуже как и любой другой. YMMV. Проведите небольшое тестирование.
Должен ли я отказаться от комбинации PHP / Nginx и перейти к чему-то другому?
Придерживайтесь того, что вам удобно.
Действительно ли это предлагаемое решение полезно?
Звучит правдоподобно, ожидает подтверждения концепции тесты и тестирование
. Добавление HTTPS в микс приведет к тому, что публикация изображения станет слишком медленно?
Возможно, немного, но, вероятно, не в значительной степени. Опять же, вам нужно будет провести некоторое тестирование. Возможно, вам удастся использовать отдельный обратный прокси-сервер для завершения SSL-соединений и, таким образом, иметь возможность использовать HTTPS для доступа к изображениям, но загрузка не происходит через HTTPS (если вы этого хотите).
Есть также несколько ускорителей HTTPS , которые вы можете получить для реальных серверов.