Gestion de Windows Server
IIS : le serveur Web Windows, pris au sérieux
IIS est le serveur Web intégré à Windows Server : pools d'applications pour l'isolation et le recyclage des processus, modules d'authentification et de réécriture d'URL, et intégration avec la pile Microsoft (ASP.NET, frontends orientés ADFS, proxy inverse de classe ARR). Il mérite mieux que son stéréotype de substitut maladroit à Apache ; ses véritables limites sont architecturales, et savoir où elles mordent le rend gérable.
Points clés
- Les pools d'applications constituent l'unité d'organisation principale : chaque pool est une limite de processus w3wp avec sa propre identité, ses propres paramètres de recyclage et son mode pipeline ; La pratique de dimensionnement standard est d'un pool par application, car elle recycle l'isolation en cas de crash sans détruire les voisins.
- Le recyclage a besoin de gouvernance : des recyclages périodiques par défaut (souvent 29 heures) existent pour masquer les fuites, mais ils provoquent des interruptions de session inexpliquées ; ajustez délibérément les temps de recyclage, le préchargement AlwaysRunning et les délais d'inactivité plutôt que d'accepter les valeurs par défaut.
- Les modules portent la configuration : URL Rewrite, ARR (reverse proxying), Windows/Forms auth et Let's Encrypt via les modules ACME ; reflète les modules communs d'Apache avec les modules IIS, mais surveillez la mémoire, car l'empilement des modules est la façon dont les boîtes IIS se gonflent.
- La forme du proxy inverse est légitime : l'ARR devant une ou plusieurs fermes Web IIS reflète les modèles nginx-as-proxy ; là où le trafic est principalement statique ou avec proxy inverse d'API à grande échelle, nginx ou un LB dédié gagne en termes de coût et de simplicité.
- La configuration est XML sous le capot (applicationHost.config plus web.config) ; les transformations de configuration et les données de départ sont correctement publiées via CI, mais la lutte de configuration entre les niveaux hiérarchiques est réelle ; gardez une seule source de vérité lorsque cela est possible.
- Raccourcis de performances : mise en cache de sortie (mode noyau si possible), compression (préchauffage de la compression statique), modules WOFF/Brotli et règles de cache ARR ; Les paramètres SSL/TLS suivent l'histoire de la suite de chiffrement Windows (TLS 1.2/1.3 via un registre ou une politique de chiffrement), d'où proviennent la plupart des conclusions des auditeurs.
Note de terrain
Une boîte IIS dont nous avons hérité avait des pools d'applications recyclés selon la fréquence par défaut de 29 heures, ce qui signifiait que chaque ticket de déconnexion client appartenait à un calendrier. La configuration d'AlwaysRunning et un réglage honnête ont arrêté les tickets ; le client pensait que nous avions trouvé un bug. Nous avons trouvé un défaut.
Questions fréquentes
IIS devrait-il s'asseoir derrière nginx dans une pile hybride ?
Un modèle courant et vérifié : nginx met fin à TLS, sert des fichiers statiques et effectue des requêtes dynamiques de proxy inverse vers les pools d'applications IIS, combinant l'efficacité de pointe avec l'intégration des applications Microsoft ; les pièces mobiles supplémentaires doivent être surveillées à partir des mêmes tableaux de bord.
La configuration flexible de classe .htaccess est-elle disponible ?
IIS utilise web.config avec des règles de réécriture d'URL et des sections de restriction IP/sécurité au niveau du répertoire ; un comportement équivalent existe, mais les hiérarchies de configuration IIS diffèrent et la syntaxe du module de réécriture doit être apprise séparément.
Qu'est-ce qui provoque des déconnexions aléatoires sur les applications IIS ?
Recyclage généralement associé à l'état de session en cours ou à des fermes à grande échelle sans sessions persistantes/alignement de clés de machine ; le correctif est la configuration (serveur d'état de session ou AlwaysRunning), et non des redémarrages mystérieux.
Comment se compare-t-il globalement à Apache et à Nginx ?
Lorsque l'application est .NET sous Windows, IIS est l'option cohérente ; pour les domaines Linux et les rôles Edge/Proxy, nginx ou Apache sont les choix honnêtes selon nos comparaisons de serveurs Web.
Comment Kinetikatech vous aide avec gestion de windows server
Nous l'avons résolu des centaines de fois : Bientôt disponible : surveillance, correctifs et protection contre la force brute pour Windows Server, la même discipline 24h/24 et 7j/7, outils natifs. Avec Supervision Windows Server et Gestion de serveurs, vous bénéficiez du cycle complet : nous évaluons, nous déployons, nous surveillons jour et nuit et nous répondons en 30 minutes quand cela compte.