Apache 2.0 sur Windows

par Dustin Puryear - Mis en ligne le 13/05/2004

Le célèbre serveur Web open-source élargit son champ d'action sous Windows

Les serveurs Web sont devenus l'une des briques de base de l'infrastructure IT du monde des affaires. Sur le marché des serveurs Web, deux noms aujourd'hui se détachent : Microsoft IIS, qui a dominé pendant longtemps le marché Windows Server, et l'Apache HTTP Server, qui a été le préféré pour d'autres implémentations d'OS, principalement Unix.Dans ces dernières années, IIS a été beaucoup critiqué pour diverses raisons, particulièrement des problèmes de sécurité. Mais vers quels autres serveurs Web les sites Windows pouvaient-ils se tourner ? Apache, géré par l'Apache Group, est un serveur Web puissant, élaboré et mature considéré par beaucoup comme le fleuron de la communauté open-source. Et beaucoup de sociétés qui utilisent Apache dans leurs produits - IBM, par exemple, qui l'utilise dans son produit WebSphere - contribuent activement à  Apache et le supportent. Et donc, le site Web continue à  croître et à  s'adapter à  la rapide évolution de l'environnement de gestion. Cependant, l'utilisation du produit sur des platesformes Windows est encore à  ce jour limitée.
Avec la release d'Apache 2.0, ce site Web hautement fiable et évolutif a accru sa portabilité et sa performance sur la plate-forme Windows, et a amélioré sa portabilité sur toutes les platesformes. Les améliorations de la nouvelle version sont telles que vous pouvez bénéficier d'Apache même dans un contexte Windows 2000 ou Windows NT.

Les objectifs initiaux de l'Apache Group étaient la sécurité et la stabilité. Dans Apache 1.3, l'équipe de développement a créé un serveur sûr, fiable et hautement disponible, capable d'assumer de très lourdes charges. Cette version a pendant longtemps été le site Web favori sur la grande majorité des plates-formes non-Windows (Linux, OS/2, Solaris de Sun Microsystems, par exemple) et fonctionne même sur Win2K, NT, et Windows 98. Toutefois, le haut niveau d'évolutivité d'Apache 1.3 ne va pas jusqu'au port Windows du produit. Et donc Apache n'a pas été un vrai concurrent d'IIS chez les utilisateurs de Windows. L'Apache Group a jugé qu'une nouvelle conception était nécessaire pour régler les principaux problèmes sur toutes les platesformes, en particulier la complexité et la performance du code. Cette complexité aurait rendu Apache de plus en plus difficile à  améliorer et à  corriger au fil du temps.
La volonté de l'Apache Group de supporter davantage de plates-formes a d'abord pris la forme d'une compilation traditionnelle : un certain code seulement est compilé dans un programme, selon qu'une condition stipulée (l'OS en service est Solaris, par exemple) est vraie. Au fur et à  mesure que les plates-formes supportées augmentaient et que leurs variations s'accentuaient, la base de code Apache est rapidement devenue extrêmement complexe et l'utilisation d'une compilation conditionnelle a rapidement freiné le développement. L'Apache Group devait aussi prendre en compte un autre facteur : la performance. Apache s'appuyait sur quelques postulats de base sur la façon de traiter les CPU, l'I/O, la mémoire et les processus. Cela ne posait pas de problèmes sur la plupart des systèmes Unix parce qu'Apache avait été développé sur cette plate-forme et principalement pour elle. En revanche, le modèle d'architecture sur lequel Apache avait été construit ne fonctionnait pas bien sur des OS non Unix et même sur certains types d'Unix. Donc, ces postulats ont conduit à  des problèmes d'évolutivité sur ces plates-formes.
L'Apache Group a décidé de régler ces deux problèmes en même temps, en construisant Apache 2.0 sur une couche abstraite et en réglant la mise en oeuvre de cette couche par rapport à  la plate-forme sous-jacente. Et c'est ainsi qu'Apache 2.0 améliore sensiblement la portabilité et les performances.
L'une des abstractions intégrées désormais dans Apache 2.0 est l'APR (Apache Portable Runtime). Comme le montre la figure 1, l'APR sert d'interface entre l'OS et l'Apache HTTP Server et traite les services système comme l'I/O, la mémoire partagée, et la gestion des processus enfants. Mais l'APR n'affecte pas le modèle qu'Apache utilise quand il traite des connexions client simultanées, qui étaient le talon d'Achille d'Apache sur Windows. Les versions Apache antérieures supposent que l'OS sous-jacent peut efficacement créer les processus enfants. Mais certains OS, comme Windows et IBM AIX, supportent mieux le multithreading ; aussi l'utilisation de processus enfants pour traiter des connexions client-réseau n'est pas la solution optimale sur ces platesformes. Apache avait donc besoin d'utiliser un thread pour traiter chaque connexion. (Le multithreading n'est pas aussi résilient vis-à -vis des erreurs que l'utilisation de processus multiples. Un thread défectueux peut causer des problèmes sur les autres threads, tandis que dans un modèle à  processus multiples, chaque processus est indépendant. Toutefois, comme les serveurs Windows utilisent le modèle multithreading, un certain - quoique minime - compromis entre la fiabilité et la performance était nécessaire, en faveur de cette dernière.)
La solution de l'Apache Group est constituée par les MPM (Multi- Processing Modules). C'est une solution à  la fois simple sur le plan théorique et élégante dans sa mise en oeuvre. Les MPM créent une abstraction entre Apache et la méthode utilisée pour traiter les connexions client simultanées. L'idée est que l'Apache Group - ou un développeur qui veut supporter une nouvelle plate-forme - construit un MPM propre à  une architecture ou à  une spécification donnée (par exemple, utiliser des processus enfants, le multithreading, ou la combinaison qui répond le mieux aux besoins de tel ou tel utilisateur). Pendant la configuration, l'utilisateur Apache choisit le MPM le mieux adapté à  l'environnement de l'utilisateur, même si, par défaut, le fichier de configuration qui accompagne chaque port d'Apache utilise le MPM spécifique à  cette plateforme. Apache compte ensuite sur le MPM pour traiter les détails de bas niveau de traitement des connexions client simultanées. Pour les systèmes Windows, Apache utilise le MPM winnt. Comme le montre la figure 2, ce MPM demande au serveur Apache de créer un processus enfant, lequel crée et contrôle ensuite les threads nécessaires pour servir chaque connexion client. (Un processus parent est nécessaire dans ce cas pour créer un nouveau processus si le processus client meurt.)