Web-сервер на ESP8266 на LwIP с возможностью upload файлов

[hd44780]

Проблема такая: нужен web-сервер на базе LwIP и с поддержкой upload файлов. На базе LwIP находил много, но с аплоадом не попадались.

Работаю на базе веб-свалки, тамошний веб-сервер всё вышеперечисленное умеет, но мне не нравится его архитектура - в частности некий общий обработчик всех параметров, прилетающих из браузера. Как-то ближе структура как в тех же apache+php - html-страница стучится в свою персональную функцию. Такая архитектура в eshttpd, но там пресловутый espconn и нет upload.

Я, конечно, могу скрестить козла с бараном и перенести eshttpd на LwIP (ну или на прослойку tcp_srv_conn из той же свалки), заодно добавив в него upload (опять же выдрав это из свалки), но может я буду изобретать велосипед ...

Может ли кто что-то посоветовать? Спасибо.

 

[pvvx]

как в тех же apache+php - html-страница стучится в свою персональную функцию.

Кто вам мешает разбить массив if-ов переменных на ветки с названиями html страниц или маркеров в них?
apache+php = пару ГБ RAM + TБ SSD + 4ГГц CLK*16 ядра На меньшем оно не пашет без лагов

 

[hd44780]

Ага, тогда уж Raspberry Pi 3 туды

Если серьёзно, я попробую переделать ифы на набор страниц и посмотрю, что из этого выйдет. Пока без наворотов. Потом посмотрим.

 

[pvvx]

Ага, тогда уж Raspberry Pi 3 туды

При стандартном наборе программ не годится для web. Только для однопоточного и большие проблемы в стеке TCP с TIME_WAIT. Т.е. до 2-х одновременных запросов и обращений к web раз в час.

Если серьёзно, я попробую переделать ифы на набор страниц и посмотрю, что из этого выйдет. Пока без наворотов. Потом посмотрим.

Для нормальной всеобъемлющей поддержки 'upload' в web требуется много RAM. Необходимо учитывать более 50-ти форматных переменных заголовка эксплоера и прочих переключателей, которые дают факториал веток и должны обслуживаться (обрабатываться) до конца обработки запроса 'upload' ... У ESP, даже ESP32 c доп.памятью банально не хватает памяти для хранения TCP с TIME_WAIT чтобы удовлетворить спецификацию TCP, не говоря уже об прочем

 

[pvvx]

Единственный способ получить не переливающиеся по несколько секунд web страницы c устройства с малыми ресурсами – параллельное (одновременное) обслуживание не менее 7..10 tcp web запросов (одновременно открытых TCP соединений). Желательно более, т.к. любой современный эксплорер на одну страницу с различным контекстом (кол-во вложенных файлов и прочих отдельно загружаемых элементов на странице) строит в среднем от 5 одновременных соединений. При этом не менее одного соединения всегда остается открытым до закрытия отображаемой страницы. Т.е. открыли 5 вкладок на ваш web – получили не менее 5-ти открытых на всё время их отображения соединений на вашем устройстве. А во время их открытия – от 5-ти на каждую вкладку. Если ваш web будет сбрасывать соединения, оставляя рабочим всего одно (как это принято у ардуинщиков), то скорость загрузки страниц будет никакая. Об таком web и говорить не стоит...

Для однопоточного web скорость загрузки сильно зависит от времени пинга и размера окна TCP стека. У ESP(32) TCP окно до 2..4 пакетов и даже при хорошей оптимизации передачи посылается до 2-х пакетов на один подтверждающий ACK. Реализации с передачей более 2-х (стартового + одного пакета вперед) пока не встречалось на ESP. У современных эксплореров размер TCP стека на каждое соединение 64..128 килобайт (40..100 пакетов TCP с MTU 1500+) - можно послать сразу десятки вперед без ожидания подтверждения. Из этого, к примеру, при пинге в 10 ms (удаленное обращение, пусть с GSM канала) выходит, что макс. теор. скорость передачи файла или потока данных с ESP идет пачками по 2 пакета (3 кило) + 10 мс, что без учета времени передачи самих данных дает ограничение до 300 килобайт в сек. В таких случаях увеличение скорости загрузки страниц можно достичь только увеличением кол-ва потоков (кол-ва одновременно открытых и обрабатываемых TCP соединений устройством).

И чем больше одновременно обрабатываемых TCP соединений с учетом правильной обработки TCP и оптимизации процедур открытия и закрытия соединений, тем сложнее создать DDOS такому web серверу. При некой границе, когда скорость обработки более ширины канала сетевого адаптера, ему вообще не страшен DDOS. И такое запросто достигается для 100 Мегабитного Ethernet на одноядерном CPU в 300 MHz… Но apache на PI3++ не могет ….

 

[hd44780]

pvvx, спасибо большое. Я посмотрю, что там получится.
По upload у меня тоже сомнения, но пока не попробуешь, не поймёшь.