roman.com писал(а): Вт сен 01, 2026 15:50:00
да, картинки загружаются один раз.
правда только при стабильной связи и при условии что ОЗУ в ПК хватает и браузер сам не перезагружается...
Нет. Браузерный HTTP-кэш обычно лежит на диске, а не только в ОЗУ. Перезапуск браузера не означает повторную загрузку всех картинок. Есть memory cache и disk cache — это разные вещи.
И перезагрузка браузера влияет только на сессию, а никак не на содержимое кеша.
roman.com писал(а): Вт сен 01, 2026 15:50:00
но нас больше интересует объём памяти в ЕСП.
одна нормальная картинка в хорошем качестве это 5-10 мегабайт.
Просто как веб-программист хочу уточнить - а что это за картинки по 5Мб? Ну, ладно, крутой большой бэкграунд может килобайт 300-400 занимать, но остальное же - килобайт по 10-100. Тем более - для телефона. А ESP сегодня и по 8, и по 16 МБ имеются. Да и, если приспичит, можно какую-ньдь SD-карту приспособить.
roman.com писал(а): Вт сен 01, 2026 15:50:00
поэтому...собираем все картинки в кучу (в одну папку вместе с хтмл или файлом приложения) и загружаем на устройство пользователя (на локальный диск).
в браузере или в приложении указывает путь к папке с картинками (src = ...).
при запуске браузера или приложения, браузер или приложение само возьмёт картинки с локального диска пользователя.
ничего скачивать по сети не надо.
никаких серверов с картинками не надо.
Во-первых, что произойдёт, когда пользователь возьмёт в руки другой прибор?

Надо будет искать ДИСКЕТУ с файлами, чтобы сначала перенести frontend на новое устройство.
Во-вторых, браузеры довольно серьёзно относятся к доступу к локальной файловой системе и к разделению разных origin. Если HTML запускается из локальной папки (file://), а данные надо получать с ESP по http://... или https://..., начинаются CORS, Origin и прочие радости. ESP придётся специально учить принимать такие запросы.
Можно, конечно, поставить пользователю ещё и локальный web-сервер. Только это проблему полностью не решает: получится, например,
http://localhost →
http://esp, то есть опять разные origin и опять CORS. Либо к локальному серверу придётся ещё прикручивать proxy.
А если frontend работает по HTTPS, а ESP отвечает по HTTP, можно дополнительно познакомиться с блокировкой mixed content.
То есть ради экономии места на ESP мы внезапно получили установку клиентского пакета, перенос его на каждое новое устройство, локальные пути, ограничения file://, CORS, возможно локальный web-сервер и proxy. Ну ни фига себе сэкономили место!
Поэтому, на мой взгляд, это перебор по выдумкам и неверный путь решения задачи. Гарантия получить проблемы с браузерами и скриптами там, где их вообще не должно быть.
Я бы сделал проще: HTML/JS и API держать на ESP — это сравнительно небольшой объём. Тяжёлую статику, если она действительно тяжёлая, — картинки и прочее — держать на внешнем сервере либо, если нужна полная автономность, на SD-карте ESP.
В случае отказа ESP и перехода на резервный AVR — отдавать упрощённый аварийный интерфейс без красивых картинок и шрифтов. Его задача в этот момент не красоту показывать, а обеспечить управление и контроль.
А пока я вижу, в сущности, что предлагается вручную реализовать то, что браузер и так умеет делать штатно: скачать статические ресурсы один раз и сохранить их в локальном кэше.
roman.com писал(а): Вт сен 01, 2026 15:50:00
сервер и клиент могут не находиться в одной локальной сети,
например в аппарате закончился сахар и пошли мы в магазин за сахаром для нашего аппарата, а аппарат дома остался вместе с сервером.
а пока мы стоим в очереди за сахаром мы должны контролировать что делает наш аппарат дома ))
а в магазине работает только мобильный интернет или бесплатный вифи.
получается сервер и клиент находятся в разной сети.
эээээ.... А каким образом телефон из магазина вообще соединяется непосредственно с ESP/AVR, находящимся дома? Если хватает денежкофф и умения поставить выделенный IP для своей домашней сетки, NAT, форвардинг портов, сертификаты TLS и прочие ништяки, то почему не хватит того же поставить в этой сети махонький веб-сервер?
roman.com писал(а): Вт сен 01, 2026 15:50:00
HTTPS или HTTP - это в первую очередь сокрытие информации.
тут опять вижу ошибку в логике. Надо помнить, что HTTPS не делает соединение невидимым. HTTPS просто защищает пароль/токен, команды управления, телеметрию, содержимое страниц от подмены данных. И всё. Т.е. - данные сессии.
roman.com писал(а): Вт сен 01, 2026 15:50:00
если мы будем передавать картинки через мобильный интернет или бесплатный вифи по открытому протоколу HTTP то РКН сразу поймет чем мы занимается )) потому что уже давно у всех провайдеров стоит оборудование от РКН и весь трафик просматривается и фильтруется.
и хорошо если РКН поймёт все правильно))
РКН и так увидит, что и как, просто без деталей. Но такие данные, как IP назначения и hostname, объём трафика, время соединения, DNS-запросы, - прекрасно видит.