Pourquoi le serveur HTTP Apache est-il si complexe?

Le serveur HTTP Apache est un projet assez important - beaucoup plus grand que, disons, lighthttpou nginxcertainement les "simples serveurs HTTP" que vous voyez flotter dans les didacticiels C / C ++.

À quoi sert le code supplémentaire? Est-ce que cela ajoute de la sécurité / stabilité (et si oui, comment?) Ou est-ce juste pour faire des choses comme analyser des conffichiers Apache / .htaccesstaper des choses (et, je suppose, VirtualHostsetc.).

Je demande de ne pas critiquer Apache, mais parce que je suis intéressé à écrire un serveur Web en quelque sorte et j'aimerais savoir des choses qui, bien que peut-être pas évidentes, sont importantes à retenir pour un serveur Web sécurisé, stable et rapide.

C'est beaucoup plus complexe car:

• c'est plus vieux ,
• il a un plus grand ensemble de fonctionnalités ( Comparaison des fonctionnalités ),
• il est modulaire ,
• il a une prise en charge plus large de la plate-forme ( OS Support Comparison ),
• il a plusieurs modes de fonctionnement (multi-processus, multi-thread, etc ...).

Mais aussi:

• Il est développé plus activement ( Comparaison des statuts . À compter d'aujourd'hui 2011-05-28, Apache httpd a la mise à jour la plus récente, bien que son processus de publication inhérent devrait être entravé par sa complexité étendue par rapport à ses concurrents.)

Cela étant dit, R. réponse contient des points valables sur son architecture et pourquoi certains autres serveurs Web bénéficient également d'une renommée relative. Cela dépend de ce que vous voulez.

Vous pouvez également consulter /programming/475386/apache-vs-nginx-vs-lighttpd-which-is-simpler-to-configure-and-administer pour plus d'informations. Bien qu'il ne réponde pas directement à votre question, l'ensemble du fil de discussion souligne de nombreuses différences.

Si vous souhaitez écrire un serveur Web à partir de zéro, je dirais qu'étudier Apache httpd est une bonne chose, surtout si vous pouvez regarder en arrière comment il a évolué au fil du temps. Il vous montre également ce que vous devez éviter (à la fois sur les points qu'il traite bien et sur les endroits où il est surpassé par d'autres). Cependant, le code peut être un peu complexe au départ et vous préférerez peut-être regarder des serveurs plus petits et plus légers pour cela. Mais étudiez son architecture globale et comparez-la avec les autres.

À mon avis, c'est à cause de toutes les fonctionnalités dont il dispose. Vous pouvez faire des choses avec Apache que vous ne pourriez pas faire pour le moment avec ni nginx ni lighthttpd. Apache est en fait une plate-forme livrée avec le support HTTP. Vous pouvez avoir n'importe quel protocole implémenté comme FTP ou SMTP (voir mod_echo par exemple). Il prend en charge les filtres, ce qui vous permet, par exemple: de servir du code PHP hors de la base de données au lieu des fichiers (puisque mod_php est un module de filtrage et non un producteur de contenu). Cela peut sembler une idée peu utile, mais en général, vous pouvez utiliser des filtres pour modifier tout contenu entrant ou sortant sans avoir à modifier le producteur de contenu d'origine. Il a des ajustements pour les clients HTTP qui ne sont plus là, mais à l'époque, Apache était le seul moyen de les servir de manière cohérente et sans bogue. Une grande partie n'est pas utilisée de nos jours.

Le code supplémentaire est également utilisé pour la sécurité, car mod_log_forensics et CoreDumpDirectory fournissent un véritable outil lorsque vous sentez que quelqu'un exploite une vulnérabilité de sécurité. Je n'ai jamais entendu parler de quelque chose comme ça dans le cas d'autres serveurs Web. Quant à la stabilité, elle provient d'un noyau bien architecturé, pas de code supplémentaire. Il y a des gars sur la liste de diffusion Apache dev, qui sont appelés "stabilisateurs de base". Ils sont très pointilleux sur tout changement dans le noyau et ont tendance à les pousser vers les modules, ce qui rend Apache assez stable. S'il échoue, la plupart du temps, c'est un échec du module et non le bogue dans le cœur du serveur.

J'utilise Apache depuis plus de douze ans en tant qu'administrateur et développeur de grandes applications Web Perl, Python et Ruby. Apache est un serveur Web solide comme le roc qui a une conception propre / modulaire et une forte inclinaison UNIX. L'une de ses fonctionnalités les plus puissantes est sa modularité et sa bonne documentation. Il s'agit d'un serveur Web très facile à gérer. Il est mature et éprouvé, comme le montrent clairement 15 années de part de marché dominante .

Bien que la documentation utilisateur soit très bonne, il y a malheureusement peu de documentation précieuse pour les développeurs / rédacteurs de modules, et je pense que cela a tendance à la blesser un peu car elle n'attire pas autant de développeurs qu'elle le pourrait. Mais cela ne signifie nullement qu'il est mal conçu - juste mal documenté à cet égard. Il y a un livre de Nick Kew qui semble être la ressource définitive pour les rédacteurs de modules. Mais ce serait bien si le projet lui-même avait une meilleure documentation sur tous les aspects de l'écriture des modules.

En ce qui concerne la sur-ingénierie - la lessive. Il a un excellent design. Oui, il y a des verrues ici et là, mais c'est vrai pour tous les logiciels. Son utilisation des pools de mémoire est fantastique, sa capacité à brancher différents back-end montre à quel point il est propre et modulaire, il a une excellente API C, et l'APR facilite beaucoup de choses non seulement pour le projet Apache pour pour développeurs dans d'autres projets. Si vous vous souciez de la portabilité, vous apprécierez l'APR. Ce n'est peut-être pas parfait, mais il est toujours solide, bien conçu et très pratique.

Du point de vue des fonctionnalités, de la flexibilité, de l'administration, du support de la plateforme, de l'évolutivité, de la documentation et de la maturité, Apache est un serveur Web fantastique.

Il est sur-conçu / sur-conçu. Pire encore, il utilise APR (Apache Portable Runtime), une couche gonflée qui finit par dépenser de nombreux niveaux d'appels de fonction et d'allocation dynamique de mémoire et de libérer pour accomplir l'équivalent d'un seul printfappel. Tout cela conduit à ce qu'il soit:

• très lent
• très gourmand en ressources
• impossible de vérifier la sécurité
• difficile à comprendre et à modifier