serveur Web

Un serveur Web est un logiciel informatique et un matériel sous-jacent qui accepte les requêtes via HTTP (le Protocole réseau créé pour distribuer le contenu Web ) ou sa variante sécurisée HTTPS . Un agent utilisateur, généralement un navigateur Web ou un robot d’exploration Web , initie la communication en faisant une demande pour une page Web ou une autre ressource à l’ aide de HTTP, et le serveur répond avec le contenu de cette ressource ou un message d’erreur . Un serveur Web peut également accepter et stocker des ressources envoyées par l’agent utilisateur s’il est configuré pour le faire.^{[1] [2]}

Clients PC communiquant via le réseau avec un serveur Web servant uniquement du contenu statique. L’intérieur et l’avant d’un serveur Dell PowerEdge , un ordinateur conçu pour être monté dans un environnement de Montage en rack . Il est souvent utilisé comme serveur Web. Plusieurs serveurs Web peuvent être utilisés pour un site Web à fort trafic. Ferme de serveurs Web avec des milliers de serveurs Web utilisés pour les sites Web à très haut trafic. Modem ADSL exécutant un serveur Web intégré servant des pages Web dynamiques utilisées pour la configuration du modem.

Le matériel utilisé pour faire fonctionner un serveur Web peut varier en fonction du volume de requêtes qu’il doit traiter. Au bas de la gamme se trouvent les systèmes embarqués , tels qu’un routeur qui exécute un petit serveur Web comme interface de configuration. Un site Web à fort trafic peut traiter des requêtes avec des centaines de serveurs qui s’exécutent sur des racks d’ordinateurs à haut débit.

Une ressource envoyée depuis un serveur Web peut être un fichier préexistant ( contenu statique ) disponible sur le serveur Web, ou elle peut être générée au moment de la requête ( contenu dynamique ) par un autre programme qui communique avec le logiciel serveur. Les premiers peuvent généralement être servis plus rapidement et peuvent être mis en cache plus facilement pour les demandes répétées, tandis que les seconds prennent en charge une plus large gamme d’applications.

Des technologies telles que REST et SOAP , qui utilisent HTTP comme base pour la communication générale d’ordinateur à ordinateur, ainsi que la prise en charge des extensions WebDAV , ont étendu l’application des serveurs Web bien au-delà de leur objectif initial de servir des pages lisibles par l’homme.

Histoire

Première proposition web (1989) évaluée comme “vague mais passionnante…” Le premier serveur Web au monde, un poste de travail NeXT Computer avec Ethernet, 1990. L’étiquette du boîtier indique : “Cette machine est un serveur. NE LA METTEZ PAS HORS TENSION !!”

Il s’agit d’un très bref historique des programmes de serveur Web , donc certaines informations recoupent nécessairement l’historique des navigateurs Web , du World Wide Web et d’Internet ; par conséquent, dans un souci de clarté et de compréhensibilité, certaines informations historiques clés rapportées ci-dessous peuvent être similaires à celles trouvées également dans un ou plusieurs des articles d’histoire mentionnés ci-dessus.

Premier projet WWW (1989-1991)

En mars 1989, Sir Tim Berners-Lee proposa un nouveau projet à son employeur le CERN , dans le but de faciliter l’échange d’informations entre scientifiques en utilisant un système hypertexte . La proposition, intitulée “HyperText and CERN” , a demandé des commentaires et a été lue par plusieurs personnes. En octobre 1990 la proposition fut reformulée et enrichie (ayant comme co-auteur Robert Cailliau ), et finalement elle fut approuvée. ^{[3] [4] [5]}

Entre la fin de 1990 et le début de 1991, le projet a conduit Berners-Lee et ses développeurs à écrire et tester plusieurs bibliothèques de logiciels ainsi que trois programmes, qui fonctionnaient initialement sur le système d’ exploitation NeXTSTEP installé sur les postes de travail NeXT : ^{[6] [7] [5]}

• un navigateur web graphique , appelé WorldWideWeb ;
• un navigateur Web portable en mode ligne ;
• un serveur Web, plus tard connu sous le nom de CERN httpd .

Ces premiers navigateurs récupéraient des pages Web à partir de serveurs Web à l’aide d’un nouveau protocole de communication de base nommé HTTP 0.9 .

En août 1991, Tim Berner-Lee a annoncé la naissance de la technologie WWW et a encouragé les scientifiques à l’adopter et à la développer. ^[8] Peu de temps après, ces programmes, ainsi que leur code source , ont été mis à la disposition des personnes intéressées par leur utilisation. ^[6] En pratique, le CERN a permis à d’autres personnes, y compris des développeurs, etc., de manière informelle, de jouer avec et peut-être de développer davantage ce qui avait été fait jusqu’à ce moment-là. Ce fut la naissance officielle du CERN httpd . Depuis lors, Berner-Lee a commencé à promouvoir l’adoption et l’utilisation de ces programmes ainsi que leur portage sur d’autres systèmes d’exploitation . ^[5]

Développement rapide et sauvage (1991-1995)

Sites Web actifs (1991-1996)

Nombre de sites Web actifs (1991-1996) [9] [10]

En décembre 1991, le premier serveur Web hors d’Europe a été installé au SLAC (USA). ^[7] Ce fut un événement très important car il a lancé des communications Web transcontinentales entre les navigateurs Web et les serveurs Web.

En 1991-1993, le programme de serveur Web du CERN a continué à être activement développé par le groupe www, tandis que, grâce à la disponibilité de son code source et aux spécifications publiques du protocole HTTP, de nombreuses autres implémentations de serveurs Web ont commencé à être développées.

En avril 1993, le CERN a publié une déclaration officielle publique indiquant que les trois composants du logiciel Web (le client en mode ligne de base, le serveur Web et la bibliothèque de code commun), ainsi que leur code source , étaient tombés dans le domaine public . ^[11] Cette déclaration a libéré les développeurs de serveurs Web de tout problème juridique possible concernant le développement d’ œuvres dérivées basées sur ce code source (une menace qui, en pratique, n’a jamais existé).

Au début de 1994, le plus notable parmi les nouveaux serveurs Web était NCSA httpd qui fonctionnait sur une variété de systèmes d’exploitation basés sur Unix et pouvait servir du contenu généré dynamiquement en implémentant la POSTméthode HTTP et le CGI pour communiquer avec des programmes externes. Ces capacités, ainsi que les fonctionnalités multimédias du navigateur Mosaic de NCSA (également capable de gérer des formulaires HTML afin d’envoyer des données au serveur Web) ont mis en évidence le potentiel de la technologie Web pour l’édition et les applications informatiques distribuées .

Dans la seconde moitié de 1994, le développement de NCSA httpd s’est arrêté au point qu’un groupe de développeurs de logiciels externes, de webmasters et d’autres personnalités professionnelles intéressées par ce serveur, ont commencé à écrire et à collecter des correctifs grâce au code source NCSA httpd disponible pour domaine public. Au début de 1995, ces correctifs ont tous été appliqués à la dernière version du code source NCSA et, après plusieurs tests, le projet de serveur Apache HTTP a été lancé. ^{[12] [13]}

Fin 1994, un nouveau serveur Web commercial, nommé Netsite , a été lancé avec des fonctionnalités spécifiques. C’était le premier de nombreux autres produits similaires qui ont d’abord été développés par Netscape , puis aussi par Sun Microsystems et enfin par Oracle Corporation .

Au milieu de 1995, la première version d’ IIS a été publiée, pour le système d’exploitation Windows NT , par Microsoft . Il s’agit d’un événement marquant car il a marqué l’entrée, dans le domaine des technologies du World Wide Web, d’un développeur et éditeur commercial très important qui a joué et joue encore un rôle clé des deux côtés (client et serveur) du web.

Dans la seconde moitié de 1995, les serveurs Web du CERN et du NCSA ont commencé à décliner (en pourcentage d’utilisation globale) en raison de l’adoption généralisée de nouveaux serveurs Web qui avaient un cycle de développement beaucoup plus rapide avec plus de fonctionnalités, plus de correctifs appliqués et plus de performances que les précédents.

Croissance explosive et concurrence (1996-2014)

Sites Web actifs (1996-2002)

Nombre de sites Web actifs (1996-2002) [10] [14]

Sun’s Cobalt Qube 3 – un appareil de serveur informatique (2002, abandonné)

À la fin de 1996, il existait déjà plus de cinquante logiciels de serveur Web (différents) connus, accessibles à tous ceux qui souhaitaient posséder un nom de domaine Internet et/ou héberger des sites Web. ^[15] Beaucoup d’entre eux n’ont vécu que peu de temps et ont été remplacés par d’autres serveurs Web.

La publication de RFC sur les versions de protocole HTTP/1.0 (1996) et HTTP/1.1 (1997, 1999), a forcé la plupart des serveurs Web à se conformer (pas toujours complètement) à ces normes. L’utilisation de connexions persistantes TCP/IP (HTTP/1.1) a obligé les serveurs Web à la fois à augmenter considérablement le nombre maximum de connexions simultanées autorisées et à améliorer leur niveau d’évolutivité.

Entre 1996 et 1999, Netscape Enterprise Server et IIS de Microsoft ont émergé parmi les principales options commerciales tandis que parmi les programmes librement disponibles et Open source , Apache HTTP Server détenait la tête en tant que serveur préféré (en raison de sa fiabilité et de ses nombreuses fonctionnalités).

Au cours de ces années, il y avait aussi un autre serveur Web commercial, très innovant et donc remarquable appelé Zeus ( maintenant abandonné ) qui était connu comme l’un des serveurs Web les plus rapides et les plus évolutifs disponibles sur le marché, au moins jusqu’à la première décennie des années 2000, malgré sa faible pourcentage d’utilisation.

Apache est devenu le serveur Web le plus utilisé de mi-1996 à fin 2015 quand, après quelques années de déclin, il a été dépassé dans un premier temps par IIS puis par Nginx. Ensuite, IIS est tombé à des pourcentages d’utilisation bien inférieurs à ceux d’Apache (voir aussi la part de marché ).

Depuis 2005-2006, Apache a commencé à améliorer sa vitesse et son niveau d’évolutivité en introduisant de nouvelles fonctionnalités de performance (par exemple MPM d’événements et nouveau cache de contenu). ^{[16] [17]} Comme ces nouvelles améliorations de performances étaient initialement marquées comme expérimentales, elles n’ont pas été activées par ses utilisateurs pendant longtemps et ainsi Apache a encore plus souffert de la concurrence des serveurs commerciaux et, surtout, des autres serveurs open-source. qui entre-temps avaient déjà atteint des performances bien supérieures (principalement en servant du contenu statique) depuis le début de leur développement et au moment du déclin d’Apache étaient en mesure d’offrir également une liste assez longue de fonctionnalités avancées bien testées.

En fait, quelques années après 2000 ont commencé, non seulement d’autres serveurs Web commerciaux et très compétitifs, par exemple LiteSpeed ​​, mais aussi de nombreux autres programmes Open source, souvent d’excellente qualité et de très hautes performances, parmi lesquels il convient de noter Hiawatha , Cherokee HTTP server , Lighttpd , Nginx et d’autres produits dérivés/connexes également disponibles avec un support commercial, ont émergé.

Vers 2007-2008, les navigateurs Web les plus populaires ont augmenté leur limite par défaut précédente de 2 connexions persistantes par domaine hôte (une limite recommandée par RFC-2616) ^[18] à 4, 6 ou 8 connexions persistantes par domaine hôte , afin d’accélérer la récupération de pages Web lourdes avec beaucoup d’images, et pour atténuer le problème de la pénurie de connexions persistantes dédiées aux objets dynamiques utilisés pour les notifications bidirectionnelles d’événements dans les pages Web. ^[19] En un an, ces changements ont, en moyenne, presque triplé le nombre maximal de connexions persistantes que les serveurs Web devaient gérer.Cette tendance (à augmenter le nombre de connexions persistantes) a certainement donné une forte impulsion à l’adoption de proxys inverses devant des serveurs Web plus lents et a également donné une chance de plus aux nouveaux serveurs Web émergents qui pouvaient montrer toute leur vitesse et leur capacité. pour gérer un très grand nombre de connexions simultanées sans nécessiter trop de ressources matérielles (ordinateurs coûteux avec beaucoup de processeurs, de RAM et de disques rapides). ^[20]

Nouveaux défis (2015 et années suivantes)

En 2015, les RFC ont publié une nouvelle version du protocole [HTTP/2], et comme l’implémentation de nouvelles spécifications n’était pas du tout anodine, un dilemme s’est posé parmi les développeurs de serveurs web moins populaires (par exemple avec un pourcentage d’utilisation inférieur à 1% .. 2%), sur l’ajout ou non de la prise en charge de cette nouvelle version de protocole. ^{[21] [22]}

En fait, la prise en charge de HTTP/2 nécessitait souvent des changements radicaux dans leur implémentation interne en raison de nombreux facteurs (connexions cryptées pratiquement toujours requises, capacité à distinguer les connexions HTTP/1.x et HTTP/2 sur le même port TCP, représentation binaire des messages HTTP , priorité des messages, compression des En-têtes HTTP, utilisation de flux également appelés sous-connexions TCP/IP et contrôle de flux associé, etc.) et donc quelques développeurs de ces serveurs Web ont choisi de ne pas prendre en charge la nouvelle version HTTP/2 (à moins dans un avenir proche) également pour ces raisons principales : ^{[21] [22]}

• les protocoles HTTP/1.x auraient de toute façon été pris en charge par les navigateurs pendant très longtemps (peut-être pour toujours) afin qu’il n’y ait pas d’incompatibilité entre les clients et les serveurs dans un futur proche ;
• la mise en œuvre de HTTP/2 était considérée comme une tâche d’ une complexité écrasante qui pourrait ouvrir la porte à une toute nouvelle classe de bogues qui n’existait pas jusqu’en 2015 et qui aurait donc nécessité des investissements notables dans le développement et le test de la mise en œuvre du nouveau protocole ;
• l’ajout du support HTTP/2 pourrait toujours être fait à l’avenir au cas où les efforts seraient justifiés.

Au lieu de cela, les développeurs des serveurs Web les plus populaires se sont précipités pour offrir la disponibilité d’un nouveau protocole , non seulement parce qu’ils avaient la main-d’œuvre et le temps pour le faire, mais aussi parce que généralement leur implémentation précédente du protocole SPDY pouvait être réutilisée comme point de départ. et parce que la plupart des navigateurs Web utilisés l’ont implémenté très rapidement pour la même raison. Une autre raison qui a incité ces développeurs à agir rapidement était que les webmasters ressentaient la pression du trafic Web toujours croissant et qu’ils voulaient vraiment installer et essayer – dès que possible – quelque chose qui pourrait réduire considérablement le nombre de connexions TCP/IP et accélérer accès aux sites Web hébergés. ^[23]

En 2020-2021, la dynamique HTTP/2 concernant sa mise en œuvre (par les meilleurs serveurs Web et les navigateurs Web populaires) a été en partie reproduite après la publication de brouillons avancés de la future RFC sur le protocole HTTP/3 .

Présentation technique

Clients PC connectés à un serveur Web via Internet

L’aperçu technique suivant doit être considéré uniquement comme une tentative de donner quelques exemples très limités sur certaines fonctionnalités qui peuvent être implémentées dans un serveur Web et certaines des tâches qu’il peut effectuer afin d’avoir un scénario suffisamment large sur le sujet.

Un programme de serveur Web joue le rôle de serveur dans un modèle client-serveur en implémentant une ou plusieurs versions du protocole HTTP, incluant souvent la variante sécurisée HTTPS et d’autres fonctionnalités et extensions considérées comme utiles pour son utilisation prévue.

La complexité et l’efficacité d’un programme de serveur Web peuvent varier considérablement selon (par exemple): ^[1]

• fonctionnalités communes mises en œuvre ;
• tâches courantes effectuées ;
• performances et niveau d’évolutivité visé comme objectif ;
• modèle logiciel et techniques adoptés pour atteindre le niveau de performance et d’évolutivité souhaité ;
• matériel cible et catégorie d’utilisation, par exemple système embarqué, serveur Web à trafic faible-moyen, serveur Web Internet à trafic élevé .

Caractéristiques communes

Bien que les programmes de serveur Web diffèrent dans la façon dont ils sont mis en œuvre, la plupart d’entre eux offrent les fonctionnalités communes suivantes.

Ce sont des fonctionnalités de base que la plupart des serveurs Web ont généralement.

• Service de contenu statique : pour pouvoir servir du contenu statique (fichiers Web) aux clients via le protocole HTTP.
• HTTP : prise en charge d’une ou plusieurs versions du protocole HTTP afin d’envoyer des versions de réponses HTTP compatibles avec les versions des requêtes HTTP client, par exemple HTTP/1.0, HTTP/1.1 (éventuellement également avec des connexions chiffrées HTTPS ), plus, si disponible, HTTP /2 , HTTP/3 .
• Journalisation : généralement, les serveurs Web ont également la capacité de consigner certaines informations, concernant les demandes des clients et les réponses du serveur, dans des fichiers journaux à des fins de sécurité et de statistiques.

Quelques autres fonctionnalités plus avancées et populaires ( seulement une très courte sélection ) sont les suivantes.

• Serveur de contenu dynamique : pour pouvoir servir du contenu dynamique (généré à la volée) aux clients via le protocole HTTP.
• Hébergement virtuel : pour pouvoir servir de nombreux sites Web ( noms de domaine ) en utilisant une seule adresse IP .
• Autorisation : pouvoir autoriser, interdire ou autoriser l’accès à des portions de parcours de sites Web (ressources Web).
• Cache de contenu : pour pouvoir mettre en cache du contenu statique et/ou dynamique afin d’accélérer les réponses du serveur ;
• Prise en charge des fichiers volumineux : pour pouvoir servir des fichiers dont la taille est supérieure à 2 Go sur OS 32 bits .
• Bandwidth throttling : pour limiter la vitesse de réponse des contenus afin de ne pas saturer le réseau et pouvoir servir plus de clients ;
• Moteur de réécriture : pour mapper des parties d’ URL propres (trouvées dans les requêtes des clients) à leurs vrais noms.
• Pages d’erreur personnalisées : prise en charge des messages d’erreur HTTP personnalisés.

Tâches communes

Un programme de serveur Web, lorsqu’il est en cours d’exécution, effectue généralement plusieurs tâches générales , (par exemple) : ^[1]

• démarre, éventuellement lit et applique les paramètres trouvés dans son ou ses fichiers de configuration ou ailleurs, ouvre éventuellement le fichier journal, commence à écouter les connexions/demandes du client ;
• essaie éventuellement d’adapter son comportement général en fonction de ses réglages et de ses conditions de fonctionnement actuelles ;
• gère la/les connexion(s) client(s) (en acceptant de nouvelles ou en fermant celles existantes selon les besoins) ;
• reçoit les requêtes des clients (en lisant les messages HTTP) :
  • lit et vérifie chaque message de requête HTTP ;
  • effectue généralement la normalisation d’URL ;
  • effectue généralement le Mappage d’URL (qui peut par défaut être la traduction du chemin d’URL) ;
  • effectue généralement la traduction du chemin d’URL ainsi que divers contrôles de sécurité ;
• exécute ou refuse la Méthode HTTP demandée :
  • gère éventuellement les autorisations URL ;
  • gère éventuellement les redirections d’URL ;
  • gère éventuellement les demandes de ressources statiques (contenu des fichiers) :
    • gère éventuellement les fichiers d’index de répertoires ;
    • gère éventuellement les fichiers réguliers ;
  • gère éventuellement les demandes de ressources dynamiques :
    • gère éventuellement les listes de répertoires ;
    • gère éventuellement le traitement du programme ou du module , en vérifiant la disponibilité, le démarrage et éventuellement l’arrêt de l’exécution des programmes externes utilisés pour générer du contenu dynamique ;
    • gère éventuellement les communications avec les programmes externes / modules internes utilisés pour générer du contenu dynamique ;
• répond aux demandes des clients en envoyant des réponses HTTP appropriées (par exemple, ressources demandées ou messages d’erreur) en vérifiant ou en ajoutant éventuellement des En-têtes HTTP à ceux envoyés par des programmes/modules dynamiques ;
• enregistre éventuellement (partiellement ou totalement) les demandes des clients et/ou leurs réponses dans un fichier journal d’utilisateur externe ou dans un fichier journal système par syslog , en utilisant généralement le format de journal courant ;
• enregistre éventuellement les messages de processus concernant les anomalies détectées ou d’autres événements notables (par exemple, dans les demandes des clients ou dans son fonctionnement interne) à l’aide de syslog ou d’autres fonctionnalités du système ; ces messages de journal ont généralement un niveau de débogage, d’avertissement, d’erreur, d’alerte qui peut être filtré (non journalisé) en fonction de certains paramètres, voir également le niveau de gravité ;
• génère éventuellement des statistiques sur le trafic web géré et/ou ses performances ;
• autres tâches personnalisées.

Lire le message de demande

Les programmes de serveur Web sont capables : ^{[24] [25] [26]}

• lire un message de requête HTTP ;
• l’interpréter;
• vérifier sa syntaxe ;
• pour identifier les En-têtes HTTP connus et en extraire leurs valeurs.

Une fois qu’un message de demande a été décodé et vérifié, ses valeurs peuvent être utilisées pour déterminer si cette demande peut être satisfaite ou non et de nombreuses autres étapes sont effectuées pour ce faire, y compris les contrôles de sécurité .

Normalisation des URL

Les programmes de serveur Web effectuent généralement un certain type de normalisation d’URL ( URL trouvée dans la plupart des messages de requête HTTP) dans l’ordre :

• faire en sorte que le chemin des ressources soit toujours un chemin uniforme propre à partir du répertoire racine du site Web ;
• pour réduire les risques de sécurité (par exemple en interceptant plus facilement les tentatives d’accès à des ressources statiques en dehors du répertoire racine du site Web ou d’accès à des portions de chemin situées sous le répertoire racine du site Web qui sont interdites ou qui nécessitent une autorisation) ;
• pour rendre le chemin des ressources Web plus reconnaissable par les êtres humains et les programmes d’analyse de journaux Web (également appelés analyseurs de journaux / applications statistiques).

Le terme normalisation d’URL fait référence au processus de modification et de standardisation d’une URL de manière cohérente. Il existe plusieurs types de normalisation qui peuvent être effectuées, y compris la conversion du nom de domaine des URL en minuscules, les plus importantes étant la suppression du “.” et “..” segments de chemin et en ajoutant des barres obliques de fin au composant de chemin non vide.

Mappage d’URL

“Le Mappage d’URL est le processus par lequel une URL est analysée pour déterminer à quelle ressource elle fait référence, afin que cette ressource puisse être renvoyée au client demandeur. Ce processus est effectué avec chaque demande adressée à un serveur Web, avec certaines des requêtes étant servies avec un fichier, tel qu’un document HTML ou une image gif, d’autres avec les résultats de l’exécution d’un programme CGI, et d’autres par un autre processus, tel qu’un gestionnaire de module intégré, un document PHP , ou une servlet Java.” ^[27]

En pratique, les programmes de serveur Web qui implémentent des fonctionnalités avancées, au-delà de la simple diffusion de contenu statique (par exemple, moteur de réécriture d’URL, diffusion de contenu dynamique), doivent généralement déterminer comment cette URL doit être gérée, par exemple :

• comme une redirection d’ URL , une redirection vers une autre URL ;
• en tant que requête statique du contenu du fichier ;
• en tant que requête dynamique de :
  • liste de répertoires de fichiers ou d’autres sous-répertoires contenus dans ce répertoire ;
  • d’autres types de requêtes dynamiques afin d’identifier le processeur de programme/module capable de gérer ce type de chemin d’URL et de lui transmettre d’autres Parties d’URL , c’est-à-dire généralement des variables d’informations de chemin et de chaîne de requête .

Un ou plusieurs fichiers de configuration du serveur Web peuvent spécifier le mappage des parties du chemin de l’URL (par exemple, les parties initiales du chemin du fichier , l’ extension du nom de fichier et d’autres composants du chemin) vers un gestionnaire d’URL spécifique (fichier, répertoire, programme externe ou module interne). ^[28]

Lorsqu’un serveur Web implémente une ou plusieurs des fonctionnalités avancées mentionnées ci-dessus, la partie chemin d’une URL valide peut ne pas toujours correspondre à un chemin de système de fichiers existant sous l’arborescence de répertoires du site Web (un fichier ou un répertoire dans le système de fichiers ) car il peut faire référence à un nom virtuel d’un processeur de module interne ou externe pour les requêtes dynamiques.

Traduction du chemin d’URL vers le système de fichiers

Les programmes de serveur Web sont capables de traduire un chemin d’URL (tout ou partie de celui-ci), qui fait référence à un chemin de système de fichiers physique, en un chemin absolu sous le répertoire racine du site Web cible. ^[28]

Le répertoire racine du site Web peut être spécifié par un fichier de configuration ou par une règle interne du serveur Web en utilisant le nom du site Web qui est la partie hôte de l’URL trouvée dans la requête du client HTTP. ^[28]

La traduction du chemin vers le système de fichiers est effectuée pour les types de ressources Web suivants :

• un fichier local, généralement non exécutable (demande statique du contenu du fichier) ;
• un annuaire local (requête dynamique : listing d’annuaire généré à la volée) ;
• un nom de programme (requêtes dynamiques exécutées à l’aide de l’interface CGI ou SCGI et dont la sortie est lue par le serveur Web et renvoyée au client qui a effectué la requête HTTP).

Le serveur Web ajoute le chemin trouvé dans l’URL demandée (message de requête HTTP) et l’ajoute au chemin du répertoire racine du site Web (hôte). Sur un serveur Apache , c’est généralement /home/www/website(sur les machines Unix/var/www/website , c’est généralement : ). Voir les exemples suivants de la façon dont cela peut en résulter.

Traduction de chemin d’URL pour une demande de fichier statique

Exemple de requête statique d’un fichier existant spécifié par l’URL suivante :

HTTP://www.exemple.com/chemin/fichier.html

L’ agent utilisateur du client se connecte à www.example.compuis envoie la requête HTTP /1.1 suivante :

GET /chemin/fichier.html HTTP/1.1 Hébergeur : www.exemple.com Connexion : keep-alive

Le résultat est la ressource du système de fichiers local :

/home/www/www.example.com/chemin/fichier.html

Le serveur Web lit alors le fichier , s’il existe, et envoie une réponse au navigateur Web du client. La réponse décrira le contenu du fichier et contiendra le fichier lui-même ou un message d’erreur reviendra indiquant que le fichier n’existe pas ou que son accès est interdit.

Traduction du chemin d’URL pour une demande d’annuaire (sans fichier d’index statique)

Exemple de requête dynamique implicite d’un répertoire existant spécifié par l’URL suivante :

HTTP://www.example.com/directory1/directory2/

L’ agent utilisateur du client se connecte à www.example.compuis envoie la requête HTTP /1.1 suivante :

GET /répertoire1/répertoire2 HTTP/1.1 Hébergeur : www.exemple.com Connexion : keep-alive

Le résultat est le chemin du répertoire local :

/home/www/www.example.com/directory1/directory2/

Le serveur web vérifie alors l’existence du répertoire et s’il existe et qu’il est accessible puis tente de trouver un fichier d’index (qui dans ce cas n’existe pas) et passe ainsi la requête à un module interne ou un programme dédié aux listes de répertoires et lit enfin la sortie de données et envoie une réponse au navigateur Web du client. La réponse décrira le contenu du répertoire (liste des sous-répertoires et fichiers contenus) ou un message d’erreur reviendra indiquant que le répertoire n’existe pas ou que son accès est interdit.

Traduction de chemin d’URL pour une demande de programme dynamique

Pour une requête dynamique , le chemin d’URL spécifié par le client doit faire référence à un programme externe existant (généralement un fichier exécutable avec un CGI) utilisé par le serveur Web pour générer du contenu dynamique. ^[29]

Exemple de requête dynamique utilisant un fichier programme pour générer une sortie :

HTTP://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

L’ agent utilisateur du client se connecte à www.example.compuis envoie la requête HTTP /1.1 suivante :

GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1 Hébergeur : www.exemple.com Connexion : keep-alive

Le résultat est le chemin du fichier local du programme (dans cet exemple un programme PHP ) :

/home/www/www.example.com/cgi-bin/forum.php

Le serveur Web exécute ce programme en lui transmettant les informations de chemin et la chaîne de requête action=view&orderby=thread&date=2021-10-15 afin que le programme sache quoi faire (dans ce cas, pour renvoyer, sous forme de document HTML, une vue des entrées du forum classées par fil depuis le 15 octobre 2021) . En outre, ce serveur Web lit les données envoyées par ce programme externe et renvoie ces données au client qui a fait la demande.

Gérer le message de demande

Une fois qu’une requête a été lue, interprétée et vérifiée, elle doit être gérée en fonction de sa méthode, de son URL et de ses paramètres qui peuvent inclure des valeurs d’En-têtes HTTP.

En pratique, le serveur Web doit gérer la requête en utilisant l’un de ces chemins de réponse : ^[28]

• si quelque chose dans la demande n’était pas acceptable (dans la ligne d’état ou les en-têtes de message), le serveur Web a déjà envoyé une réponse d’erreur ;
• si la demande a une méthode (par exemple OPTIONS) qui peut être satisfaite par le code général du serveur Web, une réponse réussie est envoyée ;
• si l’URL nécessite une autorisation, un message d’erreur d’autorisation est envoyé ;
• si l’URL correspond à une redirection, un message de redirection est envoyé ;
• si l’URL correspond à une ressource dynamique (un chemin virtuel ou une liste de répertoires), son gestionnaire (un module interne ou un programme externe) est appelé et les paramètres de requête (chaîne de requête et informations sur le chemin) lui sont transmis afin de lui permettre de répondre à cette demande ;
• si l’URL correspond à une ressource statique (généralement un fichier sur le système de fichiers), le gestionnaire statique interne est appelé pour envoyer ce fichier ;
• si la méthode de demande n’est pas connue ou s’il existe une autre condition inacceptable (par exemple, ressource introuvable, erreur interne du serveur, etc.), une réponse d’erreur est envoyée.

Servir du contenu statique Clients PC communiquant via le réseau avec un serveur Web servant uniquement du contenu statique.

Si un programme de serveur Web est capable de servir du contenu statique et qu’il a été configuré pour le faire, il est capable d’envoyer le contenu du fichier chaque fois qu’un message de requête a une correspondance de chemin d’URL valide (après le Mappage d’URL, la traduction d’URL et la redirection d’URL) qui d’un fichier existant sous le répertoire racine d’un site Web et le fichier a des attributs qui correspondent à ceux requis par les règles internes du programme de serveur Web. ^[28]

Ce type de contenu est appelé statique parce qu’il n’est généralement pas modifié par le serveur Web lorsqu’il est envoyé aux clients et qu’il reste le même jusqu’à ce qu’il soit modifié (modification de fichier) par un programme.

REMARQUE : lors de la diffusion de contenu statique uniquement , un programme de serveur Web ne modifie généralement pas le contenu des fichiers des sites Web servis (car ils ne sont que lus et jamais écrits) et il suffit donc de ne prendre en charge que ces méthodes HTTP :

• OPTIONS
• HEAD
• GET

La réponse du contenu de fichier statique peut être accélérée par un cache de fichier .

Fichiers d’index de répertoire

Si un programme de serveur Web reçoit un message de demande client avec une URL dont le chemin correspond à l’un des répertoires existants et que ce répertoire est accessible et que le ou les fichiers d’index de répertoire sont activés, un programme de serveur Web peut essayer de servir le premier des répertoires connus ( ou configuré) noms de fichiers d’index statiques (un fichier normal ) trouvés dans ce répertoire ; si aucun fichier d’index n’est trouvé ou si d’autres conditions ne sont pas remplies, un message d’erreur est renvoyé.

Les noms les plus utilisés pour les fichiers d’index statiques sont : index.html, index.htmet Default.htm.

Fichiers réguliers

Si un programme de serveur Web reçoit un message de demande client avec une URL dont le chemin correspond au nom de fichier d’un fichier existant et que ce fichier est accessible par le programme de serveur Web et que ses attributs correspondent aux règles internes du programme de serveur Web, alors le programme de serveur Web peut envoyer ce dossier au client.

Habituellement, pour des raisons de sécurité, la plupart des programmes de serveur Web sont préconfigurés pour ne servir que des fichiers normaux ou pour éviter d’utiliser des types de fichiers spéciaux comme les fichiers de périphérique , ainsi que des liens symboliques ou des liens physiques vers eux. L’objectif est d’éviter les effets secondaires indésirables lors de la diffusion de ressources Web statiques. ^[30]

Diffusez du contenu dynamique Clients PC communiquant via le réseau avec un serveur Web servant du contenu statique et dynamique.

Si un programme de serveur Web est capable de servir du contenu dynamique et qu’il a été configuré pour le faire, alors il est capable de communiquer avec le bon module interne ou programme externe (associé au chemin URL demandé) afin de lui transmettre les paramètres de demande client ; après cela, le programme du serveur Web lit sa réponse de données (qu’il a générée, souvent à la volée) puis la renvoie au programme client qui a fait la demande. ^{[ citation nécessaire ]}

REMARQUE : lors de la diffusion de contenu statique et dynamique , un programme de serveur Web doit généralement prendre en charge également la Méthode HTTP suivante afin de pouvoir recevoir en toute sécurité des données du ou des clients et ainsi pouvoir héberger également des sites Web avec des formulaires interactifs. ) pouvant envoyer de grands ensembles de données (par exemple, de nombreuses saisies de données ou téléchargements de fichiers ) vers un serveur Web/des programmes/modules externes :

• POST

Afin de pouvoir communiquer avec ses modules internes et/ou ses programmes externes, un programme de serveur Web doit avoir implémenté une ou plusieurs des nombreuses interfaces de passerelle disponibles (voir aussi Interfaces de passerelle de serveur Web utilisées pour le contenu dynamique ).

Les trois interfaces passerelles standards et historiques sont les suivantes.

Image de synthèse Un programme CGI externe est exécuté par le programme du serveur Web pour chaque demande dynamique, puis le programme du serveur Web lit à partir de celui-ci la réponse de données générée, puis la renvoie au client. SCGI Un programme SCGI externe (il s’agit généralement d’un processus) est démarré une fois par le programme du serveur Web ou par un autre programme / processus, puis il attend les connexions réseau ; chaque fois qu’il y a une nouvelle demande, le programme du serveur Web établit une nouvelle connexion réseau avec lui afin d’envoyer les paramètres de la demande et de lire sa réponse de données, puis la connexion réseau est fermée. FastCGI Un programme FastCGI externe (il s’agit généralement d’un processus) est démarré une fois par le programme du serveur Web ou par un autre programme / processus, puis il attend une connexion réseau établie en permanence par le serveur Web ; à travers cette connexion sont envoyés les paramètres de la demande et lisent les réponses de données. Listes d’annuaires Liste d’annuaires générée dynamiquement par un serveur Web.

Un programme de serveur Web peut être capable de gérer la génération dynamique (à la volée) d’une liste d’index de répertoires de fichiers et de sous-répertoires. ^[31]

Si un programme de serveur Web est configuré pour le faire et qu’un chemin d’URL demandé correspond à un répertoire existant et que son accès est autorisé et qu’aucun fichier d’index statique n’est trouvé sous ce répertoire, une page Web (généralement au format HTML) contenant la liste des fichiers et/ou sous-répertoires du répertoire mentionné ci-dessus, est généré dynamiquement (à la volée). S’il ne peut pas être généré, une erreur est renvoyée.

Certains programmes de serveur Web permettent la personnalisation des listes de répertoires en autorisant l’utilisation d’un modèle de page Web (un document HTML contenant des espaces réservés, par exemple $(FILE_NAME), $(FILE_SIZE), etc., qui sont remplacés par les valeurs de champ de chaque entrée de fichier trouvée dans le répertoire par le serveur Web), par exemple index.tplou l’utilisation de code source HTML et intégré qui est interprété et exécuté à la volée, par exemple index.asp, et / ou en prenant en charge l’utilisation de programmes d’index dynamiques tels que CGI, SCGI, FGCI, par exemple index.cgi, index.php, index.fcgi.

L’utilisation de listes de répertoires générées dynamiquement est généralement évitée ou limitée à quelques répertoires sélectionnés d’un site Web, car cette génération nécessite beaucoup plus de ressources du système d’exploitation que l’envoi d’une page d’index statique.

L’utilisation principale des listes de répertoires est de permettre le téléchargement de fichiers (généralement lorsque leurs noms, tailles, dates-heures de modification ou attributs de fichier peuvent changer de manière aléatoire / fréquemment) tels qu’ils sont, sans avoir à fournir d’informations supplémentaires à l’utilisateur demandeur . ^[32]

Traitement de programme ou de module

Un programme externe ou un module interne ( unité de traitement ) peut exécuter une sorte de fonction d’application qui peut être utilisée pour obtenir des données ou pour stocker des données dans un ou plusieurs référentiels de données , par exemple : ^{[ citation nécessaire ]}

• fichiers (système de fichiers);
• bases de données (DB);
• d’autres sources situées sur l’ordinateur local ou sur d’autres ordinateurs.

Une unité de traitement peut renvoyer tout type de contenu Web, également en utilisant des données extraites d’un référentiel de données, par exemple : ^{[ citation nécessaire ]}

• un document (par exemple HTML , XML , etc.) ;
• une image;
• une vidéo;
• des données structurées, par exemple pouvant être utilisées pour mettre à jour une ou plusieurs valeurs affichées par une page dynamique ( DHTML ) d’une interface web et qui ont peut-être été demandées par une API XMLHttpRequest (voir aussi : page dynamique ).

En pratique, chaque fois qu’il y a un contenu qui peut varier, en fonction d’un ou plusieurs paramètres contenus dans la demande du client ou dans les paramètres de configuration, alors, généralement, il est généré dynamiquement.

Envoyer un message de réponse

Les programmes de serveur Web sont capables d’envoyer des messages de réponse en réponse aux messages de demande du client. ^[24]

Un message de réponse d’erreur peut être envoyé parce qu’un message de demande n’a pas pu être lu, décodé, analysé ou exécuté avec succès. ^[25]

REMARQUE : les sections suivantes ne sont présentées qu’à titre d’exemple pour aider à comprendre ce que fait plus ou moins un serveur Web ; ces sections ne sont en aucun cas exhaustives ni complètes.

Message d’erreur

Un programme de serveur Web peut répondre à un message de requête client avec de nombreux types de messages d’erreur, de toute façon ces erreurs sont principalement divisées en deux catégories :

• Erreurs du client HTTP , dues au type de message de requête ou à la disponibilité de la Ressource Web demandée ; ^[33]
• Erreurs de serveur HTTP , dues à des erreurs de serveur internes. ^[34]

Lorsqu’une réponse / un message d’erreur est reçu par un navigateur client, alors s’il est lié à la demande principale de l’utilisateur (par exemple, une URL d’une Ressource Web telle qu’une page Web), ce message d’erreur s’affiche généralement dans une fenêtre / un message du navigateur. .

Autorisation d’URL

Un programme de serveur Web peut être en mesure de vérifier si le chemin URL demandé : ^[35]

• accessible librement à tous ;
• nécessite une authentification de l’utilisateur (demande d’informations d’identification de l’utilisateur, par exemple un nom d’utilisateur et un mot de passe ) ;
• l’accès est interdit à certains ou à tous les types d’utilisateurs.

Si la fonction d’autorisation/droits d’accès a été implémentée et activée et que l’accès à la Ressource Web n’est pas accordé, alors, selon les droits d’accès requis, un programme de serveur Web :

• peut refuser l’accès en envoyant un message d’erreur spécifique (par exemple, accès interdit );
• peut refuser l’accès en envoyant un message d’erreur spécifique (par exemple, accès non autorisé ) qui oblige généralement le navigateur client à demander à l’utilisateur humain de fournir les informations d’identification requises ; si les identifiants d’authentification sont fournis, le programme du serveur Web les vérifie et les accepte ou les rejette.

Redirection d’URL

Un programme de serveur Web peut avoir la capacité de faire des redirections d’URL vers de nouvelles URL (nouveaux emplacements) qui consiste à répondre à un message de demande client avec un message de réponse contenant une nouvelle URL adaptée pour accéder à une Ressource Web valide ou existante (le client doit refaire la requête avec la nouvelle URL). ^[36]

La redirection URL de l’emplacement est utilisée : ^[36]

• pour fixer un nom de répertoire en ajoutant un slash final ‘/’ ; ^[31]
• pour donner une nouvelle URL pour un chemin d’URL qui n’existe plus vers un nouveau chemin où ce type de Ressource Web peut être trouvé.
• pour donner une nouvelle URL à un autre domaine lorsque le domaine actuel a trop de charge.

Exemple 1 : un chemin d’URL pointe vers un nom de répertoire mais il n’a pas de slash final ‘/’ donc le serveur web envoie une redirection au client afin de lui demander de refaire la requête avec le nom de chemin fixe. ^[31]

De :
/directory1/directory2
À :
/directory1/directory2/

Exemple 2 : un ensemble complet de documents a été déplacé à l’intérieur du site Web afin de réorganiser leurs chemins de système de fichiers.

De :
/directory1/directory2/2021-10-08/
À :
/directory1/directory2/2021/10/08/

Exemple 3 : un ensemble complet de documents a été déplacé vers un nouveau site Web et il est désormais obligatoire d’utiliser des connexions HTTPS sécurisées pour y accéder.

De :
HTTP://www.example.com/directory1/directory2/2021-10-08/
À :
https://docs.example.com/directory1/2021-10-08/

Les exemples ci-dessus ne sont que quelques-uns des types de redirections possibles.

Message réussi

Un programme de serveur Web est capable de répondre à un message de demande client valide par un message réussi, contenant éventuellement des données de Ressource Web demandées . ^[37]

Si les données de ressources Web sont renvoyées au client, il peut s’agir de contenu statique ou de contenu dynamique selon la manière dont elles ont été récupérées (à partir d’un fichier ou à partir de la sortie d’un programme/module).

Cache de contenu

Afin d’accélérer les réponses des serveurs Web en réduisant les temps de réponse HTTP moyens et les ressources matérielles utilisées, de nombreux serveurs Web populaires implémentent un ou plusieurs caches de contenu , chacun spécialisé dans une catégorie de contenu. ^{[38] [39]}

Le contenu est généralement mis en cache par son origine, par exemple :

• contenu statique :
  • cache de fichiers ;
• contenu dynamique :
  • cache dynamique (sortie module/programme).

Cache de fichiers

Historiquement, les contenus statiques trouvés dans des fichiers auxquels il fallait accéder fréquemment, de manière aléatoire et rapide, ont été stockés principalement sur des disques électromécaniques depuis le milieu des années 1960/1970 ; Malheureusement, les lectures et les écritures sur ce type de périphériques ont toujours été considérées comme des opérations très lentes par rapport à la vitesse de la RAM . Ainsi, depuis les premiers systèmes d’exploitation , les premiers caches de disque, puis également les sous-systèmes de cache de fichiers du système d’exploitation ont été développés pour accélérer les opérations d’ E/S . des données/fichiers fréquemment consultés.

Même avec l’aide d’un cache de fichiers du système d’exploitation, la lenteur relative/occasionnelle des opérations d’E/S impliquant des répertoires et des fichiers stockés sur des disques est rapidement devenue un goulot d’étranglement dans l’augmentation des performances attendues des serveurs Web de haut niveau, en particulier depuis le milieu des années 1990, lorsque le trafic Internet sur le Web a commencé à croître de façon exponentielle parallèlement à l’augmentation constante de la vitesse des lignes Internet / réseau.

Le problème de savoir comment accélérer encore plus efficacement le service des fichiers statiques, augmentant ainsi le nombre maximum de requêtes/réponses par seconde ( RPS ), a commencé à être étudié/recherché depuis le milieu des années 1990, dans le but de proposer des modèles de cache utiles qui pourrait être implémenté dans des programmes de serveur Web. ^{[40] [41]}

En pratique, de nos jours, de nombreux programmes de serveurs Web populaires / hautes performances incluent leur propre cache de fichiers utilisateur , adapté à l’utilisation d’un serveur Web et utilisant leur implémentation et leurs paramètres spécifiques. ^{[42] [43] [44]}

L’adoption généralisée du RAID et/ou des disques SSD rapides ( matériel de stockage avec une vitesse d’E/S très élevée) a légèrement réduit mais bien sûr pas éliminé l’avantage d’avoir un cache de fichiers intégré dans un serveur Web.

Cache dynamique

Le contenu dynamique, produit par un module interne ou un programme externe, peut ne pas toujours changer très fréquemment (étant donné une URL unique avec des clés / paramètres) et donc, peut-être pendant un certain temps (par exemple de 1 seconde à plusieurs heures ou plus), le résultat la sortie peut être mise en cache dans la RAM ou même sur un disque rapide . ^[45]

L’utilisation typique d’un cache dynamique est lorsqu’un site Web a des pages Web dynamiques sur les actualités, la météo, les images, les cartes, etc. qui ne changent pas fréquemment (par exemple toutes les n minutes) et qui sont consultées par un grand nombre de clients par minute / heure; dans ces cas, il est également utile de renvoyer le contenu mis en cache (sans appeler le module interne ou le programme externe) car les clients n’ont souvent pas de copie mise à jour du contenu demandé dans les caches de leur navigateur. ^[46]

Quoi qu’il en soit, dans la plupart des cas, ces types de caches sont implémentés par des serveurs externes (par exemple, proxy inverse ) ou en stockant la sortie dynamique des données dans des ordinateurs séparés, gérés par des applications spécifiques (par exemple , memcached ), afin de ne pas concurrencer les ressources matérielles (CPU, RAM , disques) avec serveur(s) Web. ^{[47] [48]}

Serveurs Web en mode noyau et en mode utilisateur

Un logiciel de serveur Web peut être soit intégré au système d’ exploitation et exécuté dans l’espace noyau , soit exécuté dans l’espace utilisateur (comme d’autres applications régulières).

Les serveurs Web qui s’exécutent en mode noyau (généralement appelés serveurs Web de l’espace noyau ) peuvent avoir un accès direct aux ressources du noyau et peuvent donc être, en théorie, plus rapides que ceux qui s’exécutent en mode utilisateur ; Quoi qu’il en soit, il existe des inconvénients à exécuter un serveur Web en mode noyau, par exemple : des difficultés à développer ( débogage ) des logiciels alors que des erreurs critiques d’ exécution peuvent entraîner de graves problèmes dans le noyau du système d’exploitation.

Les serveurs Web qui s’exécutent en mode utilisateur doivent demander au système l’autorisation d’utiliser plus de mémoire ou plus de ressources CPU . Non seulement ces requêtes au noyau prennent du temps, mais elles peuvent ne pas toujours être satisfaites car le système réserve des ressources pour son propre usage et a la responsabilité de partager les ressources matérielles avec toutes les autres applications en cours d’exécution. L’exécution en mode utilisateur peut également signifier l’utilisation de plus de copies de tampon/données (entre l’espace utilisateur et l’espace noyau), ce qui peut entraîner une diminution des performances d’un serveur Web en mode utilisateur.

De nos jours, presque tous les logiciels de serveur Web sont exécutés en mode utilisateur (car bon nombre des petits inconvénients susmentionnés ont été surmontés par un matériel plus rapide, de nouvelles versions de système d’exploitation , des appels système beaucoup plus rapides et un nouveau logiciel de serveur Web optimisé). Consultez également la comparaison des logiciels de serveur Web pour découvrir lesquels d’entre eux s’exécutent en mode noyau ou en mode utilisateur (également appelé espace noyau ou espace utilisateur).

Les performances

Pour améliorer l’ expérience utilisateur (côté client / navigateur), un serveur Web doit répondre rapidement (le plus tôt possible) aux demandes des clients ; à moins que la réponse au contenu ne soit limitée (par configuration) pour certains types de fichiers (par exemple, des fichiers volumineux ou volumineux), le contenu des données renvoyées doit également être envoyé aussi rapidement que possible (vitesse de transfert élevée).

En d’autres termes, un serveur Web doit toujours être très réactif , même en cas de forte charge de trafic Web, afin de maintenir l’attente totale de l’utilisateur (somme du temps du navigateur + temps du réseau + temps de réponse du serveur Web ) pour une réponse aussi faible que possible .

Indicateurs de performance

Pour les logiciels de serveur Web, les principales mesures de performance clés (mesurées dans des conditions de fonctionnement variables ) sont généralement au moins les suivantes (c’est-à-dire) : ^{[49] [50]}

• nombre derequêtes par seconde (RPS, similaire àQPS, selon la version et la configuration HTTP, le type de requêtes HTTP et d’autres conditions de fonctionnement) ;
• le nombre de connexions par seconde ( CPS ), est le nombre de connexions par seconde acceptées par le serveur web (utile lors de l’utilisation de HTTP/1.0 ou HTTP/1.1 avec une très faible limite de requêtes/réponses par connexion, soit 1 .. 20) ;
• latence du réseau + temps de réponse pour chaque nouvelle requête client ; généralement, l’outil de référence montre combien de demandes ont été satisfaites sur une échelle de temps (par exemple, dans les 1 ms, 3 ms, 5 ms, 10 ms, 20 ms, 30 ms, 40 ms) et/ou le temps de réponse le plus court, moyen et le plus long ;
• débit de réponses , en octets par seconde.

Parmi les conditions de fonctionnement, le nombre (1 .. n ) de connexions clientes simultanées utilisées lors d’un test est un paramètre important car il permet de corréler le niveau de simultanéité supporté par le serveur web avec les résultats des métriques de performance testées.

Efficacité du logiciel

La conception et le modèle de logiciel de serveur Web spécifique adopté (par exemple):

• processus unique ou multi-process ;
• thread unique (pas de thread) ou multi-thread pour chaque processus ;
• utilisation ou non de coroutines ;

… et d’autres techniques de programmation , telles que (par exemple) :

• zéro copie ;
• minimisation des éventuels échecs du cache CPU ;
• minimisation des éventuelles erreurs de prédiction des branches du processeur dans les chemins critiques pour la vitesse ;
• minimisation du nombre d’ appels système utilisés pour effectuer une certaine fonction / tâche ;
• autres trucs;

… utilisé pour implémenter un programme de serveur Web, peut fortement biaiser les performances et en particulier le niveau d’ évolutivité qui peut être atteint sous une charge importante ou lors de l’utilisation de matériel haut de gamme (de nombreux processeurs, disques et beaucoup de RAM).

En pratique, certains modèles de logiciels de serveur Web peuvent nécessiter plus de ressources du système d’exploitation (en particulier plus de processeurs et plus de RAM) que d’autres pour pouvoir bien fonctionner et ainsi atteindre les performances cibles.

Des conditions de fonctionnement

De nombreuses conditions de fonctionnement peuvent affecter les performances d’un serveur Web ; les valeurs de performance peuvent varier en fonction de (c’est-à-dire) :

• les paramètres du serveur Web (y compris le fait que le fichier journal est ou n’est pas activé, etc.) ;
• la version HTTP utilisée par les requêtes client ;
• le type de requête HTTP moyen (méthode, longueur des En-têtes HTTP et corps facultatif) ;
• si le contenu demandé est statique ou dynamique ;
• si le contenu est mis en cache ou non (par serveur et/ou par client) ;
• si le contenu est compressé à la volée (lors du transfert), pré-compressé (c’est-à-dire lorsqu’une ressource de fichier est stockée sur un disque déjà compressé afin que le serveur Web puisse envoyer ce fichier directement au réseau avec la seule indication que son contenu est compressé) ou pas compressé du tout ;
• si les connexions sont cryptées ou non ;
• la vitesse moyenne du réseau entre le serveur Web et ses clients ;
• le nombre de connexions TCP actives ;
• le nombre de processus actifs gérés par le serveur Web (y compris les programmes externes CGI, SCGI, FCGI) ;
• les limitations matérielles et logicielles ou les paramètres du système d’ exploitation du ou des ordinateurs sur lesquels le serveur Web s’exécute ;
• autres conditions mineures.

Analyse comparative

Les performances d’un serveur Web sont généralement évaluées à l’aide d’un ou plusieurs des outils de test de charge automatisés disponibles .

Limites de charge

Un serveur Web (installation de programme) a généralement des limites de charge prédéfinies pour chaque combinaison de conditions de fonctionnement , également parce qu’il est limité par les ressources du système d’exploitation et parce qu’il ne peut gérer qu’un nombre limité de connexions client simultanées (généralement entre 2 et plusieurs dizaines de des milliers pour chaque processus de serveur Web actif, voir aussi le problème C10k et le problème C10M ).

Lorsqu’un serveur Web approche ou dépasse ses limites de charge, il est surchargé et peut donc ne plus répondre .

Causes de surcharge

À tout moment, les serveurs Web peuvent être surchargés en raison d’une ou plusieurs des causes suivantes (par exemple).

• Trafic Web légitime excessif . Des milliers voire des millions de clients se connectant au site Web en peu de temps, par exemple, effet Slashdot .
• Attaques par déni de service distribué . Une attaque par déni de service (attaque DoS) ou une attaque par déni de service distribué (attaque DDoS) est une tentative de rendre un ordinateur ou une ressource réseau indisponible pour ses utilisateurs prévus.
• Vers informatiques qui provoquent parfois un trafic anormal à cause de millions d’ordinateurs infectés (non coordonnés entre eux).
• Les vers XSS peuvent générer un trafic élevé en raison de millions de navigateurs ou de serveurs Web infectés.
• Bots Internet Trafic non filtré/limité sur les grands sites Web avec très peu de ressources réseau (par exemple bande passante ) et/ou de ressources matérielles (CPU, RAM, disques).
• Ralentissements d’ Internet (réseau) (par exemple en raison de pertes de paquets) de sorte que les demandes des clients sont servies plus lentement et que le nombre de connexions augmente tellement que les limites du serveur sont atteintes.
• Serveurs Web, servant du contenu dynamique , attendant des réponses lentes provenant d’ ordinateurs principaux ( par exemple , des bases de données ), peut-être en raison de trop de requêtes mélangées à trop d’insertions ou de mises à jour de données de base de données ; dans ces cas, les serveurs Web doivent attendre les réponses de données back-end avant de répondre aux clients HTTP, mais pendant ces attentes, trop de nouvelles connexions/demandes client arrivent et elles deviennent donc surchargées.
• Indisponibilité partielle des serveurs Web ( ordinateurs ) . Cela peut se produire en raison d’une maintenance ou d’une mise à niveau requise ou urgente, de pannes matérielles ou logicielles telles que des pannes de back-end (par exemple , la base de données ) ; dans ces cas, les serveurs Web restants peuvent recevoir trop de trafic et devenir surchargés.

Symptômes de surcharge

Les symptômes d’un serveur Web surchargé sont généralement les suivants (par exemple).

• Les requêtes sont servies avec des délais (éventuellement longs) (de 1 seconde à quelques centaines de secondes).
• Le serveur Web renvoie un code d’erreur HTTP , tel que 500, 502, ^{[51] [52]} 503, ^[53] 504, ^[54] 408, ou même un 404 intermittent .
• Le serveur Web refuse ou réinitialise (interrompt) les connexions TCP avant de renvoyer le moindre contenu.
• Dans de très rares cas, le serveur Web ne renvoie qu’une partie du contenu demandé. Ce comportement peut être considéré comme un bogue , même s’il apparaît généralement comme un symptôme de surcharge.

Techniques anti-surcharge

Pour surmonter partiellement les limites de charge supérieures à la moyenne et pour éviter la surcharge, les sites Web les plus populaires utilisent des techniques courantes comme les suivantes (par exemple).

• Réglage des paramètres du système d’exploitation pour les capacités et l’utilisation du matériel.
• Réglage des paramètres du ou des serveurs Web pour améliorer leur sécurité et leurs performances.
• Déployer des techniques de cache Web (non seulement pour les contenus statiques mais, dans la mesure du possible, pour les contenus dynamiques également).
• Gestion du trafic réseau, en utilisant :
  • Des pare -feu pour bloquer le trafic indésirable provenant de mauvaises sources IP ou ayant de mauvais modèles ;
  • Gestionnaires de trafic HTTP pour supprimer, rediriger ou réécrire les requêtes ayant de mauvais modèles HTTP ;
  • Gestion de la bande passante et mise en forme du trafic , afin de lisser les pics d’utilisation du réseau.
• Utiliser différents noms de domaine , adresses IP et ordinateurs pour servir différents types de contenu (statique et dynamique) ; l’objectif est de séparer les fichiers volumineux ou volumineux ( download.*) (ce domaine peut également être remplacé par un CDN ) des fichiers de petite et moyenne taille ( static.*) et du site dynamique principal (peut-être où certains contenus sont stockés dans une base de données principale ) ( www.*) ; l’idée est de pouvoir servir efficacement des fichiers volumineux ou volumineux (plus de 10 à 1000 Mo) (peut-être en limitant les téléchargements) et de mettre entièrement en cache les fichiers de petite et moyenne taille, sans affecter les performances du site dynamique sous forte charge, en utilisant différents paramètres pour chaque (groupe) d’ordinateurs serveurs Web, par exemple :
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Utilisation de nombreux serveurs Web (ordinateurs) regroupés derrière un équilibreur de charge afin qu’ils agissent ou soient considérés comme un seul grand serveur Web.
• Ajout de plus de ressources matérielles (c.-à-d . RAM , disques rapides ) à chaque ordinateur.
• Utiliser des programmes informatiques plus performants pour les serveurs web (voir aussi : efficacité logicielle ).
• Utiliser l’ interface de passerelle de serveur Web la plus efficace pour traiter les requêtes dynamiques (générant un ou plusieurs programmes externes à chaque fois qu’une page dynamique est récupérée, tue les performances).
• Utiliser d’autres techniques de programmation et solutions de contournement , en particulier s’il s’agit de contenu dynamique, pour accélérer les réponses HTTP (c’est-à-dire en évitant les appels dynamiques pour récupérer des objets, tels que des feuilles de style, des images et des scripts), qui ne changent jamais ou changent très rarement, en copiant ce contenu dans des fichiers statiques une fois, puis en les maintenant synchronisés avec le contenu dynamique).
• Utiliser les dernières versions efficaces de HTTP (par exemple, au-delà de l’utilisation de HTTP/1.1 commun également en activant HTTP/2 et peut-être HTTP/3 également, chaque fois que le logiciel de serveur Web disponible prend en charge de manière fiable les deux derniers protocoles) afin de réduire considérablement le nombre de Les connexions TCP/IP démarrées par chaque client et la taille des données échangées (en raison de la représentation plus compacte des En-têtes HTTP et peut-être de la compression des données).

Avertissements concernant l’utilisation des protocoles HTTP/2 et HTTP/3

Même si les nouveaux protocoles HTTP (2 et 3) génèrent généralement moins de trafic réseau pour chaque demande/données de réponse, ils peuvent nécessiter plus de ressources du système d’ exploitation (c . autres détails de mise en œuvre) ; en plus de cela, HTTP/2 et peut-être aussi HTTP/3, en fonction également des paramètres du serveur Web et du programme client, peuvent ne pas être les meilleures options pour le téléchargement de données de fichiers volumineux ou volumineux à très grande vitesse car leurs flux de données sont optimisés pour la concurrence de requêtes et donc, dans de nombreux cas, l’utilisation de connexions HTTP/1.1 TCP/IP peut conduire à de meilleurs résultats / à des vitesses de téléchargement plus élevées (votre kilométrage peut varier) . ^{[55] [56]}

Part de marché

Graphique :
Part de marché de tous les sites pour les serveurs Web les plus populaires 2005-2021 Graphique :
Part de marché de tous les sites pour les serveurs Web les plus populaires 1995–2005

Vous trouverez ci-dessous les dernières statistiques de la part de marché de tous les sites des meilleurs serveurs Web sur Internet par Netcraft .

Serveur Web : Part de marché de tous les sites

Date	nginx (Nginx, Inc.)	Apache ( AFS )	OpenResty (OpenResty Software Foundation)	Serveur Cloudflare ( Cloudflare, Inc. )	IIS ( Microsoft )	GWS ( Google )	Autres
Octobre 2021 [57]	34,95 %	24,63%	6,45 %	4,87 %	4,00% (*)	4,00% (*)	Moins de 22%
Février 2021 [58]	34,54 %	26,32%	6,36 %	5,0 %	6,5 %	3,90 %	Moins de 18%
Février 2020 [59]	36,48%	24,5 %	4,00 %	3,0 %	14,21 %	3,18 %	Moins de 15 %
Février 2019 [60]	25,34 %	26,16 %	N / A	N / A	28,42 %	1,66 %	Moins de 19%
Février 2018 [61]	24,32%	27,45 %	N / A	N / A	34,50%	1,20 %	Moins de 13 %
Février 2017 [62]	19,42 %	20,89 %	N / A	N / A	43,16%	1,03 %	Moins de 15%
Février 2016 [63]	16,61 %	32,80%	N / A	N / A	29,83 %	2,21 %	Moins de 19%

REMARQUE : (*) pourcentage arrondi à un nombre entier, car ses valeurs décimales ne sont pas rapportées publiquement par la page source (seule sa valeur arrondie est rapportée dans le graphique).

Apache, IIS et Nginx sont les serveurs Web les plus utilisés sur le World Wide Web. ^{[64] [65]}

Voir également

• Serveur (informatique)
• Serveur d’application
• Comparaison des logiciels de serveur Web
• Serveur HTTP (partie centrale d’un programme de serveur Web qui sert les requêtes HTTP)
• Compression HTTP
• application Web
• Application Web Open source
• Liste des forfaits AMP
• Objet variante
• Hébergement virtuel
• Service d’hébergement Web
• Conteneur Web
• proxy Web
• service Web

Interfaces standard de passerelle de serveur Web utilisées pour les contenus dynamiques :

• Interface de passerelle commune CGI
• Interface de passerelle commune simple SCGI
• Interface de passerelle commune rapide FastCGI

Quelques autres interfaces de serveur Web (spécifiques au serveur ou au langage de programmation ) utilisées pour les contenus dynamiques :

• SSI Server Side Include, rarement utilisé, les documents HTML statiques contenant des directives SSI sont interprétés par le logiciel serveur pour inclure de petites données dynamiques à la volée lorsque les pages sont servies, par exemple la date et l’heure, d’autres contenus de fichiers statiques, etc.
• Interface de programmation d’application du serveur SAPI :
  • Interface de programmation d’applications de serveur Internet ISAPI
  • Interface de programmation d’applications NSAPI Netscape Server
• Interface de passerelle de serveur Web PSGI Perl
• Interface de passerelle de serveur Web Python WSGI
• Interface de passerelle de serveur Web de rack
• Interface de passerelle de serveur Web JavaScript JSGI
• Java Servlet , Pages JavaServer
• Pages de serveur actif , ASP.NET

Références

1. ^ ^{un bc} Nancy J. Yeager ^; Robert E. McGrath (1996). Technologie de serveur Web . ISBN 1-55860-376-X. Récupéré le 22 janvier 2021 .
2. ^ Guillaume Nelson; Arvind Srinivasan ; Murthy Chintalapati (2009). Serveur Web Sun : le guide essentiel . ISBN 978-0-13-712892-1. Récupéré le 14 octobre 2021 .
3. ^ Zolfagharifard, Ellie (24 novembre 2018). ” “Père du Web” Sir Tim Berners-Lee sur son plan de lutte contre les fausses nouvelles” . The Telegraph . Londres . ISSN 0307-1235 . Archivé de l’original le 11 janvier 2022 . Récupéré le 1er février 2019 .
4. ^ “Histoire des ordinateurs et de l’informatique, Internet, naissance, le World Wide Web de Tim Berners-Lee” . histoire-ordinateur.com . Récupéré le 1er février 2019 .
5. ^ ^{un bc Tim Berner} -Lee (1992). “Historique du projet WWW (original)” . CERN (projet World Wide Web) . Récupéré le 20 décembre 2021 .
6. ^ ^{un b} Tim Berner-Lee (20 août 1991). “Application hypertexte étendue WorldWideWeb disponible (annonce)” . CERN (projet World Wide Web) . Récupéré le 16 octobre 2021 .
7. ^ ^un administrateur Web ^{b .} « Historique Web » . CERN (projet World Wide Web) . Récupéré le 16 octobre 2021 .
8. ^ Tim Berner-Lee (2 août 1991). “Qualificateurs sur les liens hypertextes…” CERN (projet World Wide Web) . Récupéré le 16 octobre 2021 .
9. ^ Ali Mesbah (2009). Analyse et test d’applications Web monopage basées sur Ajax . ISBN 978-90-79982-02-8. Récupéré le 18 décembre 2021 .
10. ^ ^{un b} Zakon de Robert H’obbes. “Hobbes’ Internet Timeline v5.1 (WWW Growth) REMARQUE : jusqu’en 1996, nombre de serveurs Web = nombre de sites Web” . ISOC. Archivé de l’original le 15 août 2000 . Récupéré le 18 décembre 2021 . {{cite web}}: Maint CS1 : URL inappropriée ( lien )
11. ^ Tim Smith; François Flückiger. “Licences sur le Web” . CERN (projet World Wide Web) . Récupéré le 16 octobre 2021 .
12. ^ “NCSA httpd” . NCSA (archives Web). Archivé de l’original le 1er août 2010 . Récupéré le 16 décembre 2021 .
13. ^ “À propos du serveur Apache HTTPd : comment Apache est devenu” . Apache : projet de serveur HTTPd. 1997 . Récupéré le 17 décembre 2021 .
14. ^ “Enquête sur les serveurs Web, REMARQUE : le nombre de sites Web actifs en 2000 a été interpolé” . Netcraft . Récupéré le 27 décembre 2021 .
15. ^ “Netcraft : logiciel de serveur Web (1996)” . Netcraft (archives Web). Archivé de l’original le 30 décembre 1996 . Récupéré le 16 décembre 2021 .
16. ^ “Aperçu des nouvelles fonctionnalités d’Apache 2.2” . Apache : projet de serveur HTTPd. 2005 . Récupéré le 16 décembre 2021 .
17. ^ “Aperçu des nouvelles fonctionnalités d’Apache 2.4” . Apache : projet de serveur HTTPd. 2012 . Récupéré le 16 décembre 2021 .
18. ^ “Connexions, connexions persistantes : considérations pratiques” . RFC 2616, Protocole de transfert hypertexte — HTTP/1.1 . p. 46–47. seconde. 8.1.4. doi : 10.17487/RFC2616 . RFC 2616 .
19. ^ “Connexions simultanées maximales au même domaine pour les navigateurs” . 2017 . Récupéré le 21 décembre 2021 .
20. ^ “Linux Web Server Performance Benchmark – Résultats 2016” . RootUsers . Récupéré le 22 décembre 2021 .
21. ^ ^{un b} “Est-ce que HTTP/2 remplacera HTTP/1.x ?” . Groupe de travail HTTP de l’IETF . Récupéré le 22 décembre 2021 .
22. ^ ^{un b} “Implémentations de HTTP/2 dans le logiciel client et serveur” . Groupe de travail HTTP de l’IETF . Récupéré le 22 décembre 2021 .
23. ^ “Pourquoi une seule connexion TCP ?” . Groupe de travail HTTP de l’IETF . Récupéré le 22 décembre 2021 .
24. ^ ^{un b} “la Messagerie de Client/Serveur” . RFC 7230, HTTP/1.1 : syntaxe et routage des messages . p. 7–8. seconde. 2.1. doi : 10.17487/RFC7230 . RFC 7230 .
25. ^ ^{un b} “la Gestion des Messages Incomplets” . RFC 7230, HTTP/1.1 : syntaxe et routage des messages . p. 34. s. 3.4. doi : 10.17487/RFC7230 . RFC 7230 .
26. ^ “La robustesse de l’analyse des messages” . RFC 7230, HTTP/1.1 : syntaxe et routage des messages . p. 34–35. seconde. 3.5. doi : 10.17487/RFC7230 . RFC 7230 .
27. ^ R. Bowen (29 septembre 2002). « Mappage d’URL » (PDF) . Fondation du logiciel Apache . Récupéré le 15 novembre 2021 .
28. ^ ^{un bcd e ” Mappage} des URL aux emplacements du système de fichiers ^“ . Apache : projet de serveur HTTPd. 2021 . Récupéré le 19 octobre 2021 .
29. ^ “Contenu dynamique avec CGI” . Apache : projet de serveur HTTPd. 2021 . Récupéré le 19 octobre 2021 .
30. ^ Chris Shiflett (2003). Manuel du développeur HTTP . édition de Sams. ISBN 0-672-32454-7. Récupéré le 9 décembre 2021 .
31. ^ ^{un bc ASF Infrabot} (22 mai 2019). “Annuaire des listes” . Fondation Apache : projet de serveur HTTPd . Récupéré le 16 novembre 2021 .
32. ^ “Apache : liste des répertoires pour télécharger des fichiers” . Apache : serveur HTTPd . Récupéré le 16 décembre 2021 .
33. ^ “Erreur client 4xx” . RFC 7231, HTTP/1.1 : Sémantique et contenu . p. 58. s. 6.5. doi : 10.17487/RFC7231 . RFC 7231 .
34. ^ “Erreur de serveur 5xx” . RFC 7231, HTTP/1.1 : Sémantique et contenu . p. 62-63. seconde. 6.6. doi : 10.17487/RFC7231 . RFC 7231 .
35. ^ “Introduction” . RFC 7235, HTTP/1.1 : Authentification . p. 3. s. 1. doi : 10.17487/RFC7235 . RFC 7235 .
36. ^ ^{un b} “Codes d’état de réponse : Redirection 3xx” . RFC 7231, HTTP/1.1 : Sémantique et contenu . p. 53–54. seconde. 6.4. doi : 10.17487/RFC7231 . RFC 7231 .
37. ^ “2xx réussi” . RFC 7231, HTTP/1.1 : Sémantique et contenu . p. 51-54. seconde. 6.3. doi : 10.17487/RFC7231 . RFC 7231 .
38. ^ “Guide de mise en cache” . Apache : projet de serveur HTTPd. 2021 . Récupéré le 9 décembre 2021 .
39. ^ “Mise en cache de contenu NGINX” . F5 NGINX. 2021 . Récupéré le 9 décembre 2021 .
40. ^ Evangelos P. Markatos (1996). “Mise en cache de la mémoire principale des documents Web” . Réseaux informatiques et systèmes RNIS . Récupéré le 9 décembre 2021 .
41. ^ BV Pawar; JB Patil (23 septembre 2010). “Un nouvel algorithme de mise en cache prédictif intelligent pour les serveurs Web Internet” . Journal oriental d’informatique et de technologie . Récupéré le 9 décembre 2021 .
42. ^ “Serveur Web IPlanet 7.0.9 : cache de fichiers” . Oracle. 2010 . Récupéré le 9 décembre 2021 .
43. ^ “Module Apache mod_file_cache” . Apache : projet de serveur HTTPd. 2021 . Récupéré le 9 décembre 2021 .
44. ^ “Serveur HTTP : configuration : cache de fichiers” . GNOU. 2021 . Récupéré le 9 décembre 2021 .
45. ^ “Module Apache mod_cache_disk” . Apache : projet de serveur HTTPd. 2021 . Récupéré le 9 décembre 2021 .
46. ^ “Qu’est-ce que le cache dynamique ?” . Éducatif. 2021 . Récupéré le 9 décembre 2021 .
47. ^ “Didacticiel sur l’option de cache dynamique” . Siteground. 2021 . Récupéré le 9 décembre 2021 .
48. ^ Arun Iyengar; Jim Challenger (2000). “Améliorer les performances du serveur Web en mettant en cache des données dynamiques” (PDF) . Usenix . Récupéré le 9 décembre 2021 .
49. ^ Omid H. Jader; Subhi RM Zeebaree ; Rizgar R. Zebari (12 décembre 2019). “Une enquête sur l’état de l’art pour la mesure des performances des serveurs Web et les mécanismes d’équilibrage de charge” (PDF) . IJSTR : REVUE INTERNATIONALE DE RECHERCHE SCIENTIFIQUE ET TECHNOLOGIQUE . Récupéré le 4 novembre 2021 .
50. ^ Jussara M. Almeida; Virgilio Almeida; David J. Yates (7 juillet 1997). “WebMonitor : un outil pour mesurer les performances des serveurs World Wide Web” . Premier lundi . Récupéré le 4 novembre 2021 .
51. ^ Fisher, Tim; Fil de vie. “Vous obtenez une erreur 502 Bad Gateway ? Voici ce qu’il faut faire” . Fil de vie . Récupéré le 1er février 2019 .
52. ^ “Qu’est-ce qu’une mauvaise passerelle 502 et comment la réparer?” . PRO DE L’INFORMATIQUE . Récupéré le 1er février 2019 .
53. ^ Fisher, Tim; Fil de vie. “Obtenir une erreur 503 Service non disponible ? Voici ce qu’il faut faire” . Fil de vie . Récupéré le 1er février 2019 .
54. ^ Fisher, Tim; Fil de vie. “Obtenir une erreur de dépassement de délai de passerelle 504 ? Voici ce qu’il faut faire” . Fil de vie . Récupéré le 1er février 2019 .
55. ^ nombreux (24 janvier 2021). “Téléchargements lents avec HTTP/2″ . github . Récupéré le 15 novembre 2021 .
56. ^ Junho Choi (24 août 2020). “Fournir des améliorations de la vitesse de téléchargement HTTP/2″ . Cloudflare . Récupéré le 15 novembre 2021 .
57. ^ “Enquête sur les serveurs Web d’octobre 2021” . Netcraft .
58. ^ “Enquête sur les serveurs Web de février 2021” . Netcraft .
59. ^ “Enquête sur les serveurs Web de février 2020” . Netcraft .
60. ^ “Enquête sur les serveurs Web de février 2019” . Netcraft .
61. ^ “Enquête sur les serveurs Web de février 2018” . Netcraft .
62. ^ “Enquête sur les serveurs Web de février 2017” . Netcraft .
63. ^ “Enquête sur les serveurs Web de février 2016” . Netcraft .
64. ^ Vaughan-Nichols, Steven J. “NGINX, le rival du serveur Web d’Apache et d’IIS, connaît une croissance rapide” . ZDNet . Récupéré le 1er février 2019 .
65. ^ Hadi, Nahari (2011). Sécurité du commerce Web : conception et développement . Krutz, Ronald L. Indianapolis: Wiley Pub. ISBN 9781118098899. OCLC 757394142 .

Liens externes

• Mozilla : qu’est-ce qu’un serveur web ?
• Netcraft : enquête sur l’actualité des serveurs Web