Serveur web autonome vs Apache/IIS

Question

Je suis en train de développer une application assez complexe avec win32 et l'accès web. L'implémentation côté serveur est personnalisée et elle sera hébergée dans notre entreprise. Le serveur HTTP pourrait être implémenté en tant que serveur HTTP Indy (ou autre) autonome ou plus traditionnellement avec Apache/IIS. Je voudrais savoir quels sont les avantages/inconvénients du serveur HTTP autonome par rapport à Apache/IIS, en termes de sécurité ou de tout autre élément que vous considérez pertinent.

Answer 1

Je dirais que cela dépend de vos besoins et attentes. C'est une grosse différence si vous écrivez un serveur http simple personnalisé avec peut-être même un support ISAPI etc ..., ou si vous écrivez un serveur http hautement spécialisé/proxy/etc ... qui ne fait que limiter les tâches spécialisées. Par exemple, j'ai un proxy spécialisé et un framework de gestion de module ISAPI spécialisé. Il n'y a pas si peu d'avantages que je dirais. Les avantages sont les suivants:

1. Facilité de déploiement. Essayez de déployer Apache avec votre application sur chaque machine
2. Meilleure performance, empreinte mémoire réduite. Essayez d'utiliser Apache sur les ordinateurs portables bas de gamme
3. Meilleure sécurité. Parce que vous ne faites que réduire les tâches, les risques de violation sont beaucoup plus petits. Apache fait tout pour que les chances de violation soient beaucoup plus élevées.
4. Contrôle complet du fonctionnement de ce serveur et contrôle du code. Si vous avez besoin d'un comportement légèrement différent ou de nouvelles fonctionnalités, vous l'avez.
5. Si vous exécutez des modules ISAPI comme je le fais, vous pouvez les mettre en sandbox dans des processus séparés et obtenir une meilleure stabilité. Si un module/demande se bloque, les autres ne sont pas blessés.

Les inconvénients:

1. écriture encore un autre serveur http
2. Apprendre les protocoles et le fonctionnement interne de zéro
3. Way plus grand nombre de bugs et plus de chances d'erreurs parce que le code n'est pas encore bataille endurci. Cela nécessite du temps pour s'installer.
4. Parce que vous avez un focus étroit, vous n'êtes pas aussi polyvalent qu'Apache pour la comparaison. Pas nécessairement mauvais comme indiqué plus tôt.

Mon verdict serait comme ceci. Si vous avez juste besoin d'un simple serveur http pour servir du contenu et que vous l'hébergerez en interne, sur un ou plusieurs serveurs, optez pour Apache. Si vous faites un code de manipulation http spécialisé, cela sera beaucoup installé et vous aurez besoin de contrôle, puis développez le vôtre. Croyez-moi, ça vaut le coup. Je suis tellement heureux maintenant, que je me suis tenu à cela à l'époque, quand nous décidions de la même chose. Maintenant, j'ai beaucoup d'installations portables du logiciel qui est assez complexe et je ne peux pas imaginer avoir à installer Apache sur chaque ordinateur portable. Et puis le configurer pour fonctionner comme j'en ai besoin.

Et Indy (avec tous ses problèmes et bizarreries) s'est avéré être un serveur web très stable. ICS est probablement le même ici, mais je ne l'ai pas encore utilisé pour ça, donc je ne peux pas le dire. Configuration du serveur HTTP Indy est ridiculement facile.

Juste mes deux cents;)

Answer 2

IIS et Apache sont des serveurs HTTP bien compris. Le seul avantage d'avoir votre propre serveur http est de simplifier le déploiement, ce qui ne sera probablement pas un avantage en supposant que la partie côté serveur de votre application sera exclusivement hébergée dans votre entreprise.

Un autre avantage peut être la performance, vous pouvez obtenir un débit plus élevé et de meilleurs temps de réponse avec un serveur http personnalisé. Mais en dehors de la facilité de déploiement et de la performance, je ne vois aucun autre avantage.

Il y a beaucoup d'inconvénients que

• vous écrivez du code qui a déjà été écrit
• vous devez justifier et expliquer pourquoi les nouveaux développeurs IIS et Apache ne convenait pas
• vous voulez besoin de documenter et former les autres à utiliser un tel serveur http. par exemple, les nouveaux développeurs doivent savoir comment configurer le certificat SSL ou la compression GZIP sur IIS/Apache, mais ils devront apprendre de vous comment le faire dans votre serveur http et s'il est pris en charge du tout
• si cela est Votre premier serveur http à écrire, vous aurez besoin de passer beaucoup de temps sur l'apprentissage et l'étude de diverses normes et conventions qui sont en dehors de votre domaine d'activité principal que votre application cible vraiment.

Answer 3

Par "stand alone serveur web" Voulez-vous dire dans votre application noyé? Je n'ai jamais utilisé Indy, mais j'ai travaillé sur plusieurs applications Java en utilisant la bibliothèque Jetty. Les avantages principaux d'un proxy Apache/IIS par rapport à un serveur d'application sont un déploiement et une configuration plus simples, car le service Web est étroitement intégré à l'application, sans rien d'autre à installer. Si vous avez des applications existantes et que cette nouvelle application est autorisée à être déployée dans le même environnement, je suis certain que vos administrateurs système voudront que vous utilisiez le serveur d'applications existant. Personne n'aime la complexité opérationnelle supplémentaire, même si c'est un peu plus facile à construire. L'ajout d'une autre application à un serveur d'applications est trivial.

Autres considérations:

Sécurité: configuration réseau, les fichiers journaux, les contrôles d'accès, etc. auront toutes les différentes implémentations de vos systèmes Apache/IIS et différent signifie généralement pire sécurité. Des choses simples comme l'authentification SSL que vos administrateurs sys comprennent avec Apache/IIS fonctionneront différemment avec un serveur web intégré. Performance: Le serveur embarqué est probablement un peu plus efficace, mais un peu moins évolutif. Vos décisions en matière de codage ont une grande incidence sur ce problème et, avec les serveurs intégrés, il est facile de tout gâcher. Développement: Je trouve les serveurs embarqués beaucoup plus faciles à travailler car je peux les utiliser comme de simples applications Java au lieu d'applications web, par exemple. une vue Java Eclipse au lieu de la vue J2EE avec l'intégration de Tomcat. Je sais que cette réponse est d'un point de vue Java, mais j'espère que les idées générales s'appliquent à Delphi.

Answer 4

Je développe généralement en mode autonome afin d'obtenir une meilleure expérience de débogage, puis de le déployer en tant que DLL ISAPI.

Answer 5

J'ai eu plusieurs fois où je me demandais à ce sujet aussi.

J'ai également travaillé sur certaines implémentations IInternetProtocol, pour permettre à Internet Explorer de fonctionner avec des schémas d'URL alternatifs.

Alors j'ai commencé un projet open source il y a quelque temps: http://xxm.sourceforge.net/

Il vous permet de basculer librement entre une extension ISAPI, un serveur autonome, et peut-être plus tard. Un module Apache et un gestionnaire de protocole Firefox sont en cours de création.

Le code Delphi et HTML sont combinés dans les mêmes fichiers sources, tout comme les autres langages de script Web, mais utilise le compilateur Delphi (rapide) pour construire le bibliothèques utilisées pour exécuter le site Web.

Answer 6

Je me concentre toujours sur ISAPI et utilise IDDebugger pour déboguer ce processus. Cela vous donne le meilleur des deux mondes, votre débogage contre la même version que vous déployez finalement. Malheureusement, je ne développe pas pour Apache, donc je ne peux pas parler de sa facilité de développement. Puisque j'utilise cette méthode, je n'ai jamais à m'inquiéter des changements entre les versions autonomes et ISAPI qui ne sont pas synchronisées, et je peux facilement déposer une version client dans mon environnement de test pour dupliquer tout comportement spécifique et tester ce comportement avec une solution et être absolument sûr que cela fonctionnera lorsqu'il est déployé sur le terrain.

Il y a beaucoup trop de choses à se soucier d'envisager même d'utiliser un serveur Web autonome face à Internet. C'est beaucoup mieux de mettre cette inquiétude (et de nombreuses années d'expérience) entre les mains d'IIS/Apache.

Answer 7

J'ai écrit plusieurs applications qui implémentent la pile HTTP Indy et fournissent des services Web. Cela peut être à la fois facile et complexe. La complexité vient lorsque vous commencez à travailler avec des threads car vous devez savoir comment Indy crée des threads pour les requêtes HTTP. Donc, l'intégrer avec votre code serveur peut nécessiter une réflexion, surtout si le serveur se connecte à une source de données ou à des contrôles communs d'un certain type.

De plus, vous devez gérer toute la sécurité, l'accès aux fichiers et à peu près tout ce qu'un serveur Web normal fera vous-même. Voici où vous pouvez venir décoller parce qu'il y a des exemples limités pour Indy. Cela dit, j'ai trouvé que le serveur HTTP Indy 10 est robuste et fonctionne très bien si vous ciblez des exigences spécifiques, telles que le simple fait de diffuser du code XML en fonction de ce que fait votre application. Vous avez un contrôle total sur ce que le serveur est en train de faire et vous pouvez opter pour différents modèles de déploiement - Windows Service, Stand-Alone App, etc ...

Si vous avez une application thread-safe bien conçue, puis l'implémentation de HTTP sur le dessus Cela peut être aussi simple que de déposer le composant Indy HTTP Server sur un formulaire ou une unité. Pas besoin de dupliquer du code juste pour le web.