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

Question

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

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

Answer 1

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

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

Минусы:

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

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

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

Просто мои два цента;)

Answer 2

IIS и Apache хорошо разбираются в http-серверах.

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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