Apache 2.0 sur Windows

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.)