Construire la fondation

vis-à -vis des serveurs Web ont
changé. Pour passer de 1 000 sites Web
sur IIS à  10 000 sites Web ou plus, tout
en améliorant la sécurité et la fiabilité,
Microsoft a dû se débarrasser du noyau
et en construire un nouveau.
Une autre raison qui plaide en faveur
d’une nouvelle fondation pour IIS
est le fait que Microsoft (et d’autres
fournisseurs) ont appris que des applications
médiocrement écrites étaient,
de loin, la cause la plus fréquente des
insuffisances des serveurs Web en matière
de performance et de fiabilité. IIS
5.0 atténue ces problèmes avec le
conteneur Pooled – Out of Process
pour des applications Web. Dans IIS
5.0, une application défaillante s’exécutant
dans le pool Out of Process peut
ne pas provoquer le crash d’IIS parce
que l’application tourne dans un processus
autre que Inetinfo, mais toutes
les applications Web tournant dans le
pool Out of Process s’arrêteront et
toutes les applications s’exécutent
dans le pool par défaut. Le diagnostic
et le dépannage sont difficiles dans un
tel cas parce qu’il difficile de trouver
l’application responsable. La nouvelle
architecture d’IIS 6.0 résout ces problèmes
en isolant les tâches suivantes :
écoute des requêtes, création et supervision
des sites Web, et exécution des applications Web. En théorie, la nouvelle
architecture améliore grandement
la disponibilité, la sécurité et la
performance. En pratique, Microsoft et
les testeurs bêta déclarent constater
des améliorations spectaculaires en
stabilité et performance. L’architecture
IIS 6.0 s’appuie sur trois composants
majeurs : W3SVC, http.sys et le
W3Core.

W3SVC. W3SVC est peut-être le
composant le plus discret de l’architecture
IIS 6.0, mais son rôle est néanmoins
important. W3SVC crée et supervise
les processus worker (qui
exécutent des applications de site
Web) d’après les paramètres de la métabase.
Dans IIS 5.0, le parent le plus
proche du composant IIS 6.0 W3SVC
est l’IIS Administration Service, qui fait
partie de Inetinfo ; par conséquent, si
Inetinfo défaille, l’IIS Administration
Service défaille aussi et ne peut pas redémarrer
Inetinfo ou d’autres applications
défaillantes. Dans IIS 6.0, W3SVC
fonctionne comme un processus indépendant
immunisé contre une défaillance
d’application Web parce
qu’aucun code tierce partie ne s’exécute
dans W3SVC. W3SVC est toujours
en activité, donc il peut surveiller la
disponibilité des applications Web et
agir si nécessaire. Cette technique permet
au serveur de surveiller et de redémarrer
des applications d’après vos
propres paramètres.

Http.sys. Le nouvel aspect le plus
radical du modèle IIS 6.0 est l’ajout du
driver http.sys, qui traite les requêtesHTTP et fonctionne en mode kernel.
Le fait de déplacer le traitement des requêtes
HTTP du mode utilisateur en
IIS 5.0 et IIS 4.0 dans le kernel en IIS
6.0 marque le début d’une nouvelle génération
de serveurs IIS.
Dans Win2K et NT 4.0, IIS fonctionne
en mode utilisateur, qui est le
mode OS dans lequel fonctionnent les
applications. Les applications tournant
en mode utilisateur ne communiquent
pas directement avec le matériel. Elles
invoquent des procédures standard
qui transfèrent des données ou invoquent
des fonctions des composants
en mode kernel (drivers NIC, sous-systèmes
graphiques, par exemple) pour
effectuer une tâche comme sauvegarder
un fichier, définir une adresse IP,
ou envoyer un fichier HTML au réseau.
Les transitions entre le mode utilisateur
et le mode kernel sont coûteuses.
Les serveurs Microsoft transfèrent
la requête HTTP entrante de la
pile TCP/IP dans le kernel vers Winsock
fonctionnant en mode utilisateur, lequel
transfère ensuite la requête vers
IIS. Le passage du mode kernel au
mode utilisateur s’effectue rapidement
mais introduit une pause momentanée
dans le processus. En situation de
charge, de telles pauses momentanées
peuvent se cumuler et, comme ces
transitions sont requises, vous ne pouvez
pas optimiser le processus.
Le driver en mode kernel IIS 6.0
http.sys réduit sensiblement le
nombre de transitions entre le mode
utilisateur et le mode kernel. Http.sys
est à  l’écoute des requêtes HTTP et détermine
quel processus en mode utilisateur
doit traiter la requête, ou si le driver peut fournir le contenu demandé.
IIS 6.0 fonctionnant en mode utilisateur
compte entièrement sur le
http.sys en mode kernel comme moteur
du serveur pour recevoir les requêtes
utilisateur. Par conséquent, le
driver doit être réactif et fiable. C’est
pourquoi Microsoft a conçu le driver
de telle sorte qu’il n’exécute aucun
code utilisateur susceptible de l’effondrer.
De ce fait, même si une application
est défaillante, IIS 6.0 continuera à 
écouter les requêtes HTTP.
Un processeur HTTP en mode kernel
haute vitesse qui ne peut pas exécuter
des applications, est parfait pour
renvoyer des requêtes de contenu statique
ou inchangé directement à  partir
d’un cache en mode kernel. Cette situation
réduit les transitions coûteuses
vers le mode utilisateur, et une réponse
renvoyée d’un cache en mode
kernel est rapide. Http.sys d’IIS 6.0
gère un tel cache et utilise des heuristiques
de cache très améliorées pour
déterminer quelle information doit
être mise en cache. Par exemple,
http.sys pourrait demander plus d’une
requête de contenu avant de la mettre
en cache.
Comme http.sys fournit du contenu
statique à  partir du cache de réponse
sans passer en mode utilisateur,
la performance globale d’IIS 6.0 est
nettement supérieure à  celle d’IIS 5.0.
Les présentations de Microsoft ont
montré des benchmarks WebBench
dans lesquels IIS 6.0 délivre du
contenu statique environ 150 % plus
vite qu’IIS 5.0. Même si vous utilisez un
serveur IIS 6.0 en mode isolation IIS 5.0 (dans lequel l’architecture d’IIS 6.0
imite celle d’IIS 5.0), vous bénéficierez
du cache de réponse et des autres
améliorations du driver http.sys.
En outre, Microsoft a optimisé le
driver http.sys pour qu’il achemine les
requêtes directement vers le processus
worker correct. IIS 5.0 et IIS 4.0 ont besoin
de plusieurs étapes pour déterminer
quelle instance d’un processus
contient l’application Web qui devrait
recevoir une requête. Http.sys enregistre
toutes les applications IIS 6.0 et
attribue à  chacune un handle qu’IIS
utilise en interne pour identifier un ou
plusieurs namespaces que l’application
enregistrée utilise. Ainsi, quand
http.sys reçoit une requête HTTP, il
peut rapidement acheminer la requête
du mode kernel de http.sys vers l’application
Web correcte en mode utilisateur.

L’écouteur de http.sys effectue
aussi quelques autres tâches :

• comparer les URL entrantes avec les
  règles de longueur et de formation

• gérer les files d’attente pour les requêtes
  entrantes

• effectuer des travaux de journalisation
  pour les sites IIS Web (pour optimiser
  la performance du loggin)

• renforcer les restrictions de bande
  passante et la gestion au niveau
  TCP/IP

• mettre en oeuvre les requêtes des
  certificats client (mais pas SSL –
  Secure Sockets Layer).

Comme http.sys est un driver OS
plutôt qu’un composant IIS, on utilise
des paramètres de registres au lieu de
la métabase IIS pour configurer le driver.
A l’heure actuelle, beaucoup des
paramètres de registres de http.sys ne
sont pas documentés. Ce manque de
documentation laisse penser que
Microsoft pourrait décourager la modification
de ces paramètres par les utilisateurs,
parce qu’il est prévu de les
changer. Les paramètres de registres
du driver http.sys se trouvent dans
HKEY_LOCAL_MACHINE\SYSTEM\Cur
rentControlSet\Services\HTTP. Vous pouvez y ajouter des sous-clés de registres
(qui ne sont pas présentes par
défaut) telles que

• EnableNonUTF8 – Si vous ajoutez
  cette sous-clé et lui donnez une valeur
  0, http.sys n’accepte que les URL
  codées en Universal Character Set
  (UCS) Transformation Format 8
  (UTF-8). UTF-8 est un standard (défini
  à  http://www.ietf.org/rfc/rfc2279.
  txt) conçu pour permettre l’utilisation
  de jeux de caractères en langue
  étrangère. Par défaut, EnableNon-
  UTF8 est réglé sur 1, signifiant qu’IIS
  accepte des URL codées en UTF-8,
  ANSI, ou DBCS (double-byte character
  set).

• PercentUAllowed – Quand cette
  sous-clé est mise à  1 (par défaut),
  http.sys accepte les URL contenant
  des caractères qui utilisent la notation
  %uNNNN (où NNNN est un ensemble
  de nombres qui représente
  le caractère désiré). Quand Percent-
  UAllowed est mis à  0, IIS 6.0 rejette
  les URL contenant des caractères représentés
  sous cette forme.

La forme %uNNNN de la notation
Unicode n’est pas utilisée fréquemment.
Ne la confondez pas avec la
forme UTF-8 plus courante dans laquelle
%20 représente un espace, de
sorte que http://www.iisanswers.
com/new article.htm est égal à 
http://www.iisanswers.com/new%20article.
htm. Microsoft Internet Explorer
(IE) gère automatiquement les transformations
UTF-8, et IIS 6.0 les accepte
indépendamment des paramètres
EnableNonUTF8 et PercentUAllowed.
Ces deux paramètres pour
http.sys, plus d’autres que vous pouvez
trouver dans la documentation IIS
6.0 représentent des améliorations
dans la manière dont IIS 6.0 interprète
les URL. Certains des problèmes les
plus graves en matière de sécurité d’IIS
5.0 concernent la manière dont IIS 5.0
analyse syntaxiquement les URL.
Microsoft a éliminé ces vulnérabilités
et a apporté d’autres améliorations
pour vous permettre de préciser plus clairement quelles règles IIS 6.0 doit
utiliser pour décoder une URL. Ces
améliorations sont particulièrement
importantes pour un Internet international
dans lequel diverses langues
sont représentées.
Pour plus d’informations sur
Unicode, voir http://www.unicode.org.
Pour plus d’informations sur les vulnérabilités
d’IIS 5.0, voir http://wiretrip.
net/rfp/p/doc.asp/i5/d57.htm. Pour
vous aider à  configurer http.sys, recherchez
un utilitaire dans le Microsoft
Windows Server 2003 Resource Kit.
W3Core (pool d’applications). Par
défaut, IIS 6.0 fonctionne en mode
d’isolation du processus worker, illustré
figure 4. Dans ce mode, IIS 6.0 utilise
une instance séparée de w3wp.exe,
aussi appelée worker process ou un
W3Core, pour exécuter chaque application
Web. De ce fait, le mode d’isolation
du processus worker n’a rien qui
ressemble à  une application in-process.
Cela améliore la fiabilité et la sécurité.
La fiabilité s’améliore parce que
les applications Web n’interfèrent pas
entre elles, ne peuvent pas crasher
http.sys, et sont supervisées de manière
indépendante par W3SVC quand
à  leur disponibilité. La sécurité s’améliore
parce que les applications ne
fonctionnent pas sous le compte
System comme le font les applications
in-process dans IIS 5.0 et IIS 4.0. Par
défaut, toutes les instances de
w3wp.exe fonctionnent sous un
compte Network Service à  privilèges limités,
que montre la figure 5. Vous
pouvez aussi configurer le processus
worker pour qu’il fonctionne sous un autre compte utilisateur.
Dans le cas d’une attaque par débordement
de buffer réussie sur une
application Web, l’intrus ne peut accéder
qu’aux ressources à  disposition du
compte utilisateur qui exécute le processus
worker attaqué – par défaut, le
compte Network Service. Ce compte
n’a pas d’accès Write au dossier
Inetpub ou d’accès Execute à  la plus
grande partie de System32, donc une
attaque CodeRed (par exemple) n’a
pas d’endroit où aller.
Certaines applications Web, particulièrement
les filtres ISAPI (Internet
Server API), pourraient causer des problèmes
quand elles s’exécutent « outof-
process ». Dans IIS 5.0 et IIS 4.0, les
filtres ISAPI fonctionnent toujours à 
l’intérieur d’Inetinfo et donc ils
n’avaient pas besoin d’être conçus
pour s’exécuter out-of-process. De ce
fait, certains filtres échoueront quand
ils fonctionneront en mode isolation
du processus worker d’IIS 6.0 – particulièrement
les filtres qui appellent
SF_READ_RAW_DATA ou SF_SEND_
RAW_DATA. IIS 6.0 a un second mode
de fonctionnement appelé mode isolation
d’IIS 5.0. Les filtres ISAPI qui ne
fonctionnent pas bien en mode isolation
du processus worker devraient
fonctionner correctement en mode
isolation d’IIS 5.0 et vos applications
continueront à  bénéficier de nombreuses
améliorations d’IIS 6.0, en particulier
la vitesse et la disponibilité
qu’offre le driver http.sys.
Vous verrez des références à  une
fonction IIS 6.0 appelée pools d’applications.
Un pool d’applications est un processus worker (ou un ensemble de
processus) possédant un nom. Considérez-
le de la manière suivante : en IIS
5.0, vous pouvez définir Application
Protection sur Low (IIS Process),
Medium (Pooled) ou High (Isolated).
Cette possibilité est utile, mais qu’advient-
il si vous voulez exécuter deux
applications d’un pool (une instance
de dllhost.exe) et deux applications
différentes d’un autre pool (une instance
différente de dllhost.exe) ? IIS 5.0
n’offre aucun moyen de nommer des
instances de dllhost.exe et d’attribuer
des applications à  ces noms. Les pools
d’applications d’IIS 6.0 vous permettent
d’attribuer un nom à  un processus
worker, comme le montre la figure 6,
afin de pouvoir attribuer des sites ou
des répertoires Web à  ce pool, comme
le montre la figure 7.