требования к железу/софту для запуска web-сервера, на встраиваемом устройстве Опции

[shreck]

Добрый день.
Нужно разработать устройство, управление которым должно осуществляться через ethernet и wi-fi.
Какая минимальная/типичная/комфортная программно-аппаратная конфигурация должна быть у встраивамого устройства, чтобы запустить на нем более-менее полноценный web-сервер и web-службу?

[kolobok0]

...через ethernet и wi-fi....программно-аппаратная конфигурация...запустить на нем более-менее полноценный web-сервер и web-службу?

чтоб поднять Ethernet - много телодвижений не надо. С ВайФаем сложнее. Если Вам принципиально и то и то, то тогда надо искать готовые девайсы(типа роутеров под льюникс) или готовые платки которые берут на себя данный функционал (типа визнета и иже).
Чисто изернет - определяетесь какая поддерживаемая скорость нужна, цена вопроса, сколько ресурсов на самой железке. Исходя из этого есть варианты
1) чисто всё самому реализовывать. в инете есть вплоть до физического уровня всё на МК. правда скорость - сами понимаете не серъёзно.
2) взять готовые микросхемки(типа CS8900A - это правда десятка, чисто как пример) сети(как правило управление ими - параллельное), внимание уделить при разводке дорожек, согласующему трансику на выходе. с точки зрения софта - микросхемка предоставляет только физический уровень и фильтрацию(поддержку) на мак уровне(типа бродкасты и явную адресацию). стэк подымать самому. Минималка для вэба - ARP, IP, ICMP, TCP, WEB начинку(HTTP + некий свой встроенный язык - аля пыхпых). для расширения UDP на любителя - занимает копейки телодвижений, а заюзать можно не плохо для своих нужд. Обращаю внимание, что если встраиваемый сервак должен принимать страницы более 1500 байт(такое может быть - в зависимости от функционала вэба), то обязательно нужно поддерживать сборку на IP уровне!(не путать с TCP). Если её поддерживать - то как правило требования к ОЗУ возрастает(время жизни фрагмента, интенсивность и размер ОЗУ - связаные вещи).
3) взять готовые платки (микросхемка, сетевой трансик, кварц). как и во втором варианте возможно придётся(зависит от милкосхемки) реализовывать стэк самому(см. пункт 2). Но есть и готовые решения - например WizNet. Управление как правило идёт через SPI или COM или типа того. Стэк как правило в этом случае поддерживается милкосхемкой. Вэб решение бывает внутри, а бывает и нет.
4) взять готовые девайс типа роутера. софтверная начинка - льюникс и иже. выхода можно намудрить. Но это не пром. вариант кмк.

...сайт запустить на своей втроенной железке и выставить голой ж... в Интернет? Набега хакеров не боитесь?...

глупость несёте...
поясните как хакеры будут ломать флэш МК через Ethernet?

Сообщение отредактировал kolobok0 - Jul 27 2012, 11:49

[AlexandrY]

глупость несёте...
поясните как хакеры будут ломать флэш МК через Ethernet?

Не хакеры ломать будут, а боты и вообще все соседи.
Будут во первых непрерывно сканировать порты.
Будет идти непрерывный широковещательный трафик от роутеров и прочей инфраструктуры.
Потом будут непрерывно долбить по HTTP, Telnet, FTP и т.д.
Серверу все время надо будет парсить идиотские запросы по HTTP.
В конце концов сервер упадет либо из-за нехватки памяти либо из-за ошибки в парсере.
Либо сам встроенный сервер занесут в черный список за неадекватные ответы.
Обрезание трафика по email уже обычное дело.
С провайдерами приходится ругаться чтобы дивайсы могли отправлять емайлы беспрепятственно.
Ну а Flash (вернее файловые носители на Flash) рухнет от износа.

[_sv_]

Ну а Flash (вернее файловые носители на Flash) рухнет от износа.

И Flash тоже перепишут.
Посылается TCP пакет (или фрагмент более высокого протокола),
который вызывает переполнение стека, в следствии чего запускется
фрагмент кода из уже убитого стека.
Разработка такого мероприятия "с нуля" - достаточно муторное мероприятие.
Но в этой степи работают уже много лет и есть серьезные наработки.
По "стилистике" ответов определяют тип используемого стека.
Конкретные опции - экспериментально.

В целом, задача не "для маленьких", но это лишь вопрос желания.

P.S. От дальнейших подробностей - воздержусь : )

Сообщение отредактировал _sv_ - Jul 30 2012, 14:28

[A. Fig Lee]

И Flash тоже перепишут.
Посылается TCP пакет (или фрагмент более высокого протокола),
который вызывает переполнение стека, в следствии чего запускется
фрагмент кода из уже убитого стека.
Разработка такого мероприятия "с нуля" - достаточно муторное мероприятие.
Но в этой степи работают уже много лет и есть серьезные наработки.
По "стилистике" ответов определяют тип используемого стека.
Конкретные опции - экспериментально.

В целом, задача не "для маленьких", но это лишь вопрос желания.

P.S. От дальнейших подробностей - воздержусь : )

Похоже, Вы не совсем понимаете как это работает. Для такой атаки надо детально знать код.
Просто так stack overflow вызвать НЕВОЗМОЖНО.

Не хакеры ломать будут, а боты и вообще все соседи.
Будут во первых непрерывно сканировать порты.
Будет идти непрерывный широковещательный трафик от роутеров и прочей инфраструктуры.
Потом будут непрерывно долбить по HTTP, Telnet, FTP и т.д.
Серверу все время надо будет парсить идиотские запросы по HTTP.
В конце концов сервер упадет либо из-за нехватки памяти либо из-за ошибки в парсере.
Либо сам встроенный сервер занесут в черный список за неадекватные ответы.
Обрезание трафика по email уже обычное дело.
С провайдерами приходится ругаться чтобы дивайсы могли отправлять емайлы беспрепятственно.
Ну а Flash (вернее файловые носители на Flash) рухнет от износа.

То о чем Вы говорите не имеет никакого отношения к ембеддед вебсерверу.
Все тоже самое будет происходить и с обычным PC.
Файрволл не уменьшает количество обращений и не предотвращает ДОС атаки.
Единственно, что это немного разгружает процессор, но имплементация такого файрволла
на микроконтроллере займет пару строчек.

[AlexandrY]

То о чем Вы говорите не имеет никакого отношения к ембеддед вебсерверу.
Все тоже самое будет происходить и с обычным PC.
Файрволл не уменьшает количество обращений и не предотвращает ДОС атаки.
Единственно, что это немного разгружает процессор, но имплементация такого файрволла
на микроконтроллере займет пару строчек.

Обычный PC обычен только для дилетанта, а разработчика со стороны даже близко не подпустят к технологии его сетевых чипов.
Подите найдите описание контроллера Etherneta на тот же Raspberry Pi.
Это черные ящики. Если он начнет падать, то есть полная гарантия что вы никогда не узнаете почему.

Файрволл полностью может закрыть трафик к внутреннему серверу защитив его от перегрузок.
Софтварная импмлементация простейшего файрвола довольно сложна (сложнее простейшего WEB сервера) и ресурсоемка.
Но мы наверно о разном

[A. Fig Lee]

Обычный PC обычен только для дилетанта, а разработчика со стороны даже близко не подпустят к технологии его сетевых чипов.
Подите найдите описание контроллера Etherneta на тот же Raspberry Pi.
Это черные ящики. Если он начнет падать, то есть полная гарантия что вы никогда не узнаете почему.

Файрволл полностью может закрыть трафик к внутреннему серверу защитив его от перегрузок.
Софтварная импмлементация простейшего файрвола довольно сложна (сложнее простейшего WEB сервера) и ресурсоемка.
Но мы наверно о разном

На PC файрволл и сетевой чип - это параллельные прямые.
Вся коммуникация идет через драйвер и кернел API.
Во вторых, закрытость чипа определяется политикой компании производителя, а не наличием/присутствием его в PC.
Broadcom знаменит своим "не пущать!", так что Ваш пример ничего не доказывает.
В сурсах Линукса море драйверов для разных нетворк чипов.
Зачем они правда нужны для имплементации файрволла на PC, я не понял.

Да, наверное, мы о разном. Я говорю конкретно о теме, Вы же предлагаете подменить ембеддед вебсервер целой сетью с файрволлом на входе,
судя по Вашему посту.

Кстати, простейший файрволл тупо сравнивает IP источника и не пропускает пакеты с запрещеным IP, где Вы видели проще HTTP server?

[AlexandrY]

Broadcom знаменит своим "не пущать!", так что Ваш пример ничего не доказывает.
В сурсах Линукса море драйверов для разных нетворк чипов.

Я говорю конкретно о теме, Вы же предлагаете подменить ембеддед вебсервер целой сетью с файрволлом на входе,
судя по Вашему посту.

Кстати, простейший файрволл тупо сравнивает IP источника и не пропускает пакеты с запрещеным IP, где Вы видели проще HTTP server?

Эт что, в надежде что линукс большой и такие голословные утверждения никто не проверит?
Нут так в директории линукса с linux.org относительно сетевых физических контроллеров только 19 файлов!
Причем такого размера, что на драйвера не тянут. Это вообще ноль!
Конкретно файлов касающихся сетевых чипов там можно на пальцах пересчитать и видно, что функциональность их обрезана.

Embedded web cервер не файрволами надо обкладывать, а вообще нельзя в публичный интернет выставлять.
Да и функцию файрвола вы в моем контексте исказили.

[Idle]

Нут так в директории линукса с linux.org относительно сетевых физических контроллеров только 19 файлов!
Причем такого размера, что на драйвера не тянут. Это вообще ноль!
Конкретно файлов касающихся сетевых чипов там можно на пальцах пересчитать и видно, что функциональность их обрезана.

а как посчитали количество? у меня в /usr/src/linux/drivers/net побольше всего, подскажите, pls где туплю

Сообщение отредактировал Idle - Aug 2 2012, 13:07

[AlexandrY]

а как посчитали количество? у меня в /usr/src/linux/drivers/net побольше всего, подскажите, pls где туплю

/usr/src/linux/drivers/net/phy

а то в /net там записаны IrDA, CAN, WiMax и т.д.

Так вот я захожу на динамический сайт с обычным CMS расположенный на хостинге, захожу на страницу ванной комнаты и задаю параметры. Контроллер ванной комнаты так же периодически обращается к сайту на хостинге и если обнаруживает измененные параметры, то принимает их и выполняет. Так я избавил контроллер с ограничеными ресурсами от необходимости обрабатывать WEB интерфейс, значительно упростил систему.

Хостинг выбирают с Node.js. Тогда можно делать управление в риалтайме.

Но в моих дивайсах делается по другому.
По VPN дивайсы через NAT сервер провайдера (так стандартно бывает при GPRS соединении) по VPN организуют постоянный канал к домашней сети (можно просто роутер с поддержкой VPN) и там объявляются на фиксированных частных IP адресах.
Когда надо поуправлять дивайсом из публичного интернета, заходим опять же по VPN в свою домашнюю (частную, корпоративную) сеть и получаем доступ к WEB серверу дивайса по известному частному адресу.
В данном случае дивайсы защищены NAT сервером провайдера. Домашняя сеть защищена домашним роутером. Обмен же происходит в риалтайме.

[Idle]

/usr/src/linux/drivers/net/phy
а то в /net там записаны IrDA, CAN, WiMax и т.д.

так вы ж про mac а не про phy разговор вели, чем там рулить-то в фае? драйверы на чипы контроллеров на уровень выше в каталогах и отдельных файлах
или я опять чего-то не понимаю?

упд
мне вообще не понятно, кому эти драйверы фаев нужны? как-то попросили, мол, настрой программно; мужику лень стало смотреть в даташит и подтяжки подбирать для аппаратной конфигурации - притянул всё в одно место

а какие там маки неполные? энтузиасты писали или производитель не заморачивается?

да и опять же есть мак+езернет фай в одном чипе и одном драйвере, или я опять не понял?

Сообщение отредактировал Idle - Aug 2 2012, 21:02

[AlexandrY]

так вы ж про mac а не про phy разговор вели, чем там рулить-то в фае? драйверы на чипы контроллеров на уровень выше в каталогах и отдельных файлах
или я опять чего-то не понимаю?

да и опять же есть мак+езернет фай в одном чипе и одном драйвере, или я опять не понял?

Я MAC нигде не упоминал, меня вообще интересовало найти по работе с L3 что-нибудь посовременней.
Среди кучи мусора в директории NET PHY будет самым осмысленным местом где это могло бы лежать.
Есть там, конечно, и отдельные директории для оригинальных чипов, но это слезы.
Никаких оснований говорить, что в линуксе чего-то "море" нет.