Автономный веб-сервер против Apache / IIS

Question

Я разрабатываю довольно сложное приложение как с win32, так и с доступом через Интернет. Реализация на стороне сервера является индивидуальной, и будет проводиться в нашей компании. HTTP-сервер может быть реализован как отдельный Indy (или другой) HTTP-сервер или, более традиционно, с Apache / IIS.

Я хотел бы знать, каковы преимущества / недостатки автономного HTTP-сервера по сравнению с Apache / IIS с точки зрения безопасности или всего, что вы считаете уместным.

Answer 1

Я бы сказал, что это зависит от ваших потребностей и ожиданий. Это большая разница, если вы пишете собственный простой http-сервер с поддержкой ISAPI и т. Д., Или вы пишете узкоспециализированный http-сервер / proxy / и т. Д., Который выполняет только узкие специализированные задачи. Например, у меня есть такой специализированный прокси-сервер и специализированная среда обработки модулей ISAPI. Есть не так много преимуществ, я бы сказал. Итак, плюсы:

1. Простота развертывания. Попробуйте развернуть apache с вашим приложением на каждой машине
2. Лучшая производительность, меньший объем памяти. Попробуйте использовать Apache на недорогих ноутбуках
3. Лучшая безопасность. Поскольку вы выполняете только узкие задачи, вероятность нарушения намного меньше. Apache делает все это, поэтому вероятность взлома намного выше.
4. Полный контроль над работой такого сервера и контроль над кодом. Если вам нужно немного другое поведение или новые функции, вы его получите.
5. Если вы используете модули ISAPI, как и я, вы можете поместить их в отдельные процессы и добиться большей стабильности. Если один модуль / запрос дает сбой, другие не пострадают.

Минусы:

1. Написание еще одного http-сервера
2. Изучение протоколов и внутренней работы с нуля
3. Значительно больше ошибок и больше шансов на ошибки, потому что код еще не закален. Это требует времени, чтобы обосноваться.
4. Поскольку у вас узкий фокус, вы не настолько универсальны, как Apache для сравнения. Не обязательно плохо, как указано ранее.

Мой приговор будет таким. Если вам просто нужен простой http-сервер для обслуживания некоторого контента, и вы будете размещать его дома, на одном или нескольких серверах, перейдите на Apache. Если вы создаете специальный кусок кода, обрабатывающий http, который будет много устанавливаться и вам нужен контроль, то разработайте свой собственный. Поверьте мне, это стоит времени. Я так рад сейчас, что я придерживался этого тогда, когда мы решали то же самое. Теперь у меня есть множество программ установки ноутбука, которые довольно сложны, и я не могу себе представить необходимость установки Apache на каждый ноутбук. А затем настроить его на работу так, как мне нужно.

И Indy (со всеми его проблемами и причудами) оказался очень стабильным из коробки веб-сервером. Вероятно, ICS здесь такая же, но я еще не использовал ее, поэтому не могу сказать. Настройка Indy HTTP-сервера смехотворно проста.

Только мои два цента;)

Answer 2

Под «автономным веб-сервером» вы подразумеваете встраивание в ваше приложение? Я никогда не использовал Indy, но я работал над несколькими Java-приложениями, используя библиотеку Jetty . Основными преимуществами этого по сравнению с прокси-сервером Apache / IIS для сервера приложений являются простота развертывания и настройки, поскольку веб-служба тесно интегрирована в приложение и не требует установки ничего лишнего.

Если у вас уже есть приложения, и это новое приложение разрешено развертывать в той же среде, я уверен, что ваши системные администраторы захотят, чтобы вы использовали существующий сервер приложений. Никто не любит дополнительные эксплуатационные сложности, даже если вам немного легче строить. Добавление другого приложения на сервер приложений тривиально.

Другие соображения:

Безопасность. Конфигурация сети, файлы журналов, средства управления доступом и т. Д. Будут иметь различные реализации от ваших систем Apache / IIS, и, как правило, они означают более низкую безопасность. Простые вещи, такие как аутентификация SSL, которые ваши системные администраторы понимают с помощью Apache / IIS, будут работать по-разному со встроенным веб-сервером.

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

Разработка. Мне кажется, что со встроенными серверами работать намного проще, поскольку я могу запускать их как простые Java-приложения вместо веб-приложений, например. представление Java Eclipse вместо представления J2EE с интеграцией Tomcat.

Я знаю, что это ответ с точки зрения Java, но я надеюсь, что общие идеи применимы к Delphi.

Answer 3

IIS и Apache - хорошо понимаемые http-серверы.

Единственное преимущество наличия собственного http-сервера - это упрощение развертывания, которое, вероятно, не будет преимуществом, если предположить, что серверная часть вашего приложения будет размещаться исключительно в вашей компании.

Еще одним преимуществом может быть производительность, вы можете добиться более высокой пропускной способности и лучшего времени отклика с помощью специально созданного http-сервера. Но кроме простоты развертывания и производительности, я не вижу никаких других преимуществ.

Есть много недостатков, хотя

• вы пишете код, который уже был написан
• вам нужно будет обосновать и объяснить новым разработчикам, почему IIS и Apache не подходят
• вам нужно будет документировать и обучать других, как использовать такой http-сервер. например, ожидается, что новые разработчики будут знать, как настроить SSL-сертификат или сжатие GZIP на IIS / Apache, однако им придется узнать у вас, как это сделать на вашем http-сервере и поддерживается ли вообще эта функция
• если это ваш первый http-сервер для записи, вам нужно будет потратить много времени на изучение и изучение различных стандартов и соглашений, которые находятся за пределами вашей основной бизнес-сферы, на которую действительно нацелено ваше приложение.

Answer 4

Я написал несколько приложений, которые реализуют Indy HTTP Stack и предоставляют веб-сервисы. Это может быть как легко, так и сложно. Сложность возникает, когда вы начинаете работать с потоками, поскольку вам необходимо знать, как Indy создает потоки для HTTP-запросов. Поэтому для интеграции его с кодом вашего сервера может потребоваться определенное внимание, особенно если сервер подключается к источнику данных или имеет общие элементы управления какого-либо типа.

Кроме того, вам нужно управлять всей безопасностью, доступом к файлам и почти всем остальным, что обычный веб-сервер сделает самостоятельно. Вот где вы можете отклеиться, потому что примеры для Indy ограничены.

Сказав это, я обнаружил, что HTTP-сервер Indy 10 надежен и работает очень хорошо, если вы ориентируетесь на конкретные требования, такие как простое обслуживание XML на основе того, что делает ваше приложение. У вас есть полный контроль над тем, что делает сервер, и вы можете выбрать различные модели развертывания - Служба Windows, Автономное приложение и т. Д ...

Если у вас есть хорошо разработанное поточно-ориентированное приложение, то реализовать HTTP поверх него можно так же просто, как перетащить компонент Indy HTTP Server в форму или модуль. Не нужно дублировать какой-либо код только для веб-материалов.

Answer 5

У меня было несколько случаев, когда я тоже думал об этом.

Я также работал над некоторыми реализациями IInternetProtocol, чтобы позволить Internet Explorer работать с альтернативными схемами URL.

Итак, я начал проект с открытым исходным кодом некоторое время назад: http://xxm.sourceforge.net/

Позволяет свободно переключаться между расширением ISAPI, автономным сервером и, возможно, позже. (В разработке находятся модуль Apache и обработчик протокола Firefox.)

Delphi-код и HTML объединены в те же исходные файлы, что и другие языки веб-сценариев, но используют (быстрый) компилятор Delphi для создания библиотек, используемых для запуска веб-сайта.

Answer 6

Я, как правило, разрабатываю как отдельный, так что я получаю лучший опыт отладки, а затем развернуть как ISAPI DLL.

Answer 7

Я всегда фокусируюсь на ISAPI и использую IDDebugger для отладки этого процесса. Это дает вам лучшее из обоих миров, вашу отладку по той же версии, которую вы в конечном итоге развернете. К сожалению, я не разрабатываю для Apache, поэтому не могу говорить о его простоте разработки.

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

Слишком много вещей, о которых стоит беспокоиться, даже если подумать об использовании автономного веб-сервера, подключенного к Интернету. Намного лучше передать это беспокойство (и многолетний опыт) в руки IIS / Apache.