Serveur WEB

Capacités de Charge

La charge supportée par un serveur web dépend de nombreux facteurs, notamment la configuration spécifique, l'optimisation des performances, le type de contenu servi,la nature des requêtes.

2 vCores et 4 Go de RAM

• Apache : 200 à 300 requêtes par seconde
• Nginx : 1000 à 1500 requêtes par seconde
• Nginx en mode proxy inverse : environ 800 à 1200 requêtes par seconde
• Node.js : environ 1500 à 2000 requêtes par seconde

8 vCores et 16 Go de RAM

• Apache : 1000 à 1500 requêtes par seconde
• Nginx : 4000 à 5000 requêtes par seconde
• Nginx en mode proxy inverse : environ 3000 à 4000 requêtes par seconde
• Node.js : environ 8000 à 10000 requêtes par seconde

Apache : est idéal pour des configurations complexes et une compatibilité avec de nombreux langages et frameworks.

• .htaccess #configurer des paramètres de serveur web de manière granulaire au niveau du répertoire
• Apache utilise une architecture modulaire chargés dynamiquement , le traitement CGI, la réécriture d'URL
• Apache gère très bien les scripts Perl, Python, et autres langages via CGI.
• De nombreuses applications web et frameworks sont conçus avec une compatibilité spécifique pour Apache.

Nginx : est parfait pour servir du contenu statique à haute performance et comme proxy inverse

• .htaccess n'a pas la même flexibilité dans les configurations
• Les modules ne sont pas dynamiques et doivent être compilés dans le noyau Nginx
• Meilleure performance que Apache pour les requêtes statiques et en tant que proxy inverse.

Node.js : est optimal pour les applications en temps réel et les opérations I/O intensives.

• Événements non bloquants Node.js utilise un modèle basé sur les événements et non bloquant, ce qui le rend très performant pour les applications en temps réel.
• Node.js peut servir des requêtes HTTP sans avoir besoin d'un serveur web externe comme Apache ou Nginx.
• Un vaste écosystème de modules disponibles via NPM (Node Package Manager) pour ajouter des fonctionnalités.
• Très bonne scalabilité pour les applications I/O intensives.

N° 1

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v                            
+------------------+
|  Apache + (PHP)  |
+---------+--------+

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v                            
+------------------+
|  Nginx + (PHP)   |
+---------+--------+

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v      
+---------+-------------+
| Nginx (proxy inverse) |
+---------+-------------+
          |
          v                            
+----------------------+
|  Node.js (JavaScript)|
+---------+------------+

N° 2 - Nginx en mode proxy inverse + Cache

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v                            
+---------+-----------+
|   Squid (Cache)     |
+---------+-----------+
          |
          v                            
+---------+-------------+
| Nginx (proxy inverse) |
+---------+-------------+
          |
          v                            
+---------------------------------+
|  Apache + (PHP / FastCGI)       |
|  + (mod_wsgi + Python)          |
|  + (mod_perl + Perl )           |
|  + (mod_ruby + Ruby /Rails)     |
|  + (mod_cgi et mod_cgid + CGI)  |
|  + (mod_lua  + Lua)             |
+---------+-----------------------+

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v                            
+---------+-----------+
|   Squid (Cache)     |
+---------+-----------+
          |
          v                            
+---------+-------------+
| Nginx (proxy inverse) |
+---------+-------------+
          |
          v                            
+------------------+
|  Nginx   ...     |
+---------+--------+

+------------------+
|  Utilisateurs    |
+---------+--------+
          |
          v                            
+---------+-----------+
|   Squid (Cache)     |
+---------+-----------+
          |
          v                            
+---------+-------------+
| Nginx (proxy inverse) |
+---------+-------------+
          |
          v                            
+-------------------------+
|  Node.js (JavaScript)   |
|  + (TypeScript)         |
|  + (CoffeeScript)       |
|  + (Dart)               |
|  + (Elm)                |
+---------+---------------+

Cache

Squid et Nginx sont tous deux des solutions de cache HTTP, mais ils ont des fonctionnalités et des usages différents

Squid

Squid est un serveur proxy et un cache HTTP qui peut accélérer la livraison de contenus en mettant en cache les réponses des serveurs web et en les servant directement aux utilisateurs. Squid est principalement utilisé pour les réseaux d'entreprise et les grandes infrastructures web pour réduire la latence et économiser la bande passante.

Nginx

Nginx est un serveur web et proxy inverse qui peut également servir de cache HTTP pour améliorer les performances des sites web et des applications. Il est souvent utilisé pour distribuer la charge des requêtes sur plusieurs serveurs backend et mettre en cache les réponses des serveurs backend.

Shared Content Delivery Network (CDN)

Un Content Delivery Network (CDN) partagé, également connu sous le nom de "Shared CDN", est un réseau de serveurs distribués géographiquement qui travaillent ensemble pour fournir rapidement du contenu Internet aux utilisateurs finaux. Le terme "partagé" fait référence à l'utilisation de l'infrastructure CDN par plusieurs clients, ce qui permet de réduire les coûts et d'optimiser les ressources. Les serveurs CDN sont répartis dans le monde entier. Cela permet de placer le contenu plus près des utilisateurs finaux, réduisant ainsi la latence et améliorant les temps de chargement. Le CDN met en cache le contenu statique (images, vidéos, fichiers CSS/JS, etc.) sur ses serveurs périphériques (Edge Servers). Lorsqu'un utilisateur demande ce contenu, il est servi à partir du serveur le plus proche plutôt que du serveur d'origine. Fournisseur de CDN : Cloudflare, Akamai, Amazon CloudFront, et Fastly>

Installation et Configuration des Ports d'Écoute

Pour installer plussieurs serveur il simplement configuré les ports d'entrer et sortie

Utilisateurs (80/443) -> (80/443) Squid (3128) -> (3128) Nginx (8080) -> (8080)Apache

Installation SSL

A installé sur le serveur d'entrée