Nginx 2.0 est un serveur Web de pointe et axé sur les événements conçu avec l'efficacité, l'évolutivité et la conformité du protocole HTTP à la base. Inspiré par l'architecture NGINX d'origine, notre objectif était de créer un serveur Web qui correspond à son prédécesseur en performances, flexibilité et facilité d'utilisation. Développé à travers les efforts de collaboration de moi-même et de Tukka, Nginx 2.0 incarne notre engagement envers l'innovation, offrant une plate-forme robuste pour le contenu Web statique et dynamique, optimisé pour les applications et services Web modernes.
Notre parcours dans le développement de Nginx 2.0 a été motivé par un engagement envers l'innovation, la performance et la poursuite de l'excellence en technologie de service Web. Ici, nous nous plongeons dans les fonctionnalités principales qui incarnent nos ambitions et nos prouesses techniques, présentant les progrès que nous avons effectués pour redéfinir les capacités d'un serveur Web moderne.
Dans l'élaboration de Nginx 2.0, nous avons priorisé l'adhésion stricte à la norme HTTP / 1.1, garantissant que notre serveur prend en charge robustement des méthodes HTTP essentielles telles que GET, tête, publication et supprimer. Cet engagement ne s'aligne pas seulement sur notre objectif d'une large compatibilité, mais reflète également notre dévouement à fournir une base solide et fiable pour le service Web.
La complexité et la diversité des configurations de serveurs Web nous ont conduit à implémenter un analyseur de descente récursif, reflétant le modèle hiérarchique observé dans Nginx. Cette stratégie améliore la gestion de la configuration, ce qui le rend intuitif et gérable tout en préservant la flexibilité nécessaire aux configurations complexes.
Comprenant les divers environnements dans lesquels notre serveur fonctionne, nous avons développé une couche d'abstraction personnalisée pour le multiplexage d'E / S qui s'intègre de manière transparente à Kqueue (MacOS) et Epoll (Linux). Cette approche multiplateforme témoigne de notre engagement à optimiser les performances sur différents systèmes, garantissant que Nginx 2.0 fonctionne efficacement dans diverses conditions opérationnelles.
Notre concentration sur l'efficacité et les performances est particulièrement évidente dans la façon dont Nginx 2.0 gère les grandes réponses et le streaming vidéo. En prenant en charge le codage de transfert: demandes de morceaux et de plage, nous avons optimisé la livraison d'un grand contenu, garantissant une utilisation minimale des ressources tout en maintenant la lecture vidéo fluide et ininterrompue. Cette fonctionnalité est un résultat direct de notre dévouement à l'amélioration des expériences des utilisateurs, en relevant des défis communs dans la livraison de contenu avec des solutions innovantes.
Pour étendre les capacités du serveur au-delà du service de contenu statique, nous avons intégré le support CGI complet dans Nginx 2.0. Cela permet l'exécution de programmes externes pour la génération de contenu dynamique et le traitement de formulaire, entre autres tâches. Cette intégration reflète notre vision d'un serveur Web polyvalent qui peut répondre à un large éventail d'exigences d'application Web, offrant la flexibilité nécessaire pour développer des expériences Web interactives et personnalisées.
Le développement d'un cadre de journalisation configurable au sein de Nginx 2.0 découle de notre reconnaissance du rôle critique que la journalisation joue dans la compréhension et l'optimisation des opérations du serveur. En implémentant un système qui prend en charge plusieurs niveaux de journal et permet une configuration dynamique des sorties de journal, nous nous avons fourni un outil puissant pour surveiller, déboguer et améliorer les performances du serveur. Ce cadre incarne notre engagement envers la transparence et le contrôle, garantissant que nous pouvons toujours garder une impulsion sur la santé et l'efficacité du serveur.
Bienvenue à Nginx 2.0, un serveur Web axé sur les événements conçu pour l'efficacité, l'évolutivité et la conformité avec la norme HTTP / 1.1. Ce guide vous guidera à travers les étapes pour installer et créer Nginx 2.0 sur votre système.
Avant de commencer, assurez-vous que votre système répond aux exigences suivantes:
Nginx 2.0 utilise un makefile pour la construction de la source. Suivez ces étapes pour cloner le référentiel et construire le serveur:
Cloner le référentiel
Commencez par cloner le référentiel Nginx 2.0 à votre machine locale:
git clone https://github.com/anassajaanan/Nginx-2.0
cd nginx-2.0Construire le projet
Vous pouvez créer le projet dans deux configurations: débogage pour le développement et la libération pour la production.
Build de débogage:
La version de débogage comprend des symboles de débogage supplémentaires et est compilé avec des désinfectants de comportements et des comportements non définis (sur macOS) ou avec de solides vérifications de protection et de débordement (sur Linux) à des fins de développement et de test.
make debugVersion de libération:
La version de version est optimisée pour les performances avec l'optimisation -O3 , le ciblage de l'architecture native et l'optimisation du temps de liaison. Il s'agit de la configuration recommandée pour le déploiement.
make prodExécution de Nginx 2.0
Pour démarrer le serveur, spécifiez un chemin de fichier de configuration si vous le souhaitez. Si aucun chemin n'est fourni, le serveur utilisera la configuration par défaut située sur [conf/nginx.conf]
./webserver [configfile_path] # For release build Remplacez [configfile_path] par le chemin d'accès à votre fichier de configuration. En cas d'omission, Nginx 2.0 utilisera la configuration par défaut.
Pour une construction de débogage:
./webserver_debug [configfile_path] # For debug build Pour nettoyer la construction d'artefacts et démarrer frais, utilisez les commandes clean ou fclean :
Nettoyer des objets et des dépendances:
make cleanClean complet (y compris les binaires):
make fcleanValgrind Memory Check:
Pour les utilisateurs de Linux, exécutez votre version de débogage avec Valgrind pour vérifier les fuites de mémoire:
make valgrindAssurez-vous que Valgrind est installé sur votre système pour que cela fonctionne.
Cette section décrit les directives disponibles dans NGINX 2.0, leurs contextes applicables, leurs politiques de validation et leurs exemples d'utilisation. Cette approche structurée garantit une compréhension claire de la façon de configurer efficacement votre serveur Web.
root Contextes autorisés: server , location
Politique de validation: doit être unique dans son contexte.
Exemple:
server {
root /var/www/html; # Document root
}listen Contextes autorisés: server
Politique de validation: doit être unique dans son contexte.
Exemple:
server {
listen 8080 ; # Server listens on port 8080
}autoindex Contextes autorisés: server , location
Politique de validation: doit être unique dans son contexte.
Exemple:
location /images {
autoindex on ; # Enables directory listing
}server_name Contextes autorisés: server
Politique de validation: doit être unique dans son contexte.
Exemple:
server {
server_name example.com;
}client_max_body_size Contextes autorisés: http , server
Politique de validation: doit être unique dans son contexte.
Exemple:
http {
client_max_body_size 20M ; # Limits request body size
}error_page Contextes autorisés: http , server , location
Politique de validation: prend en charge deux arguments ou plus.
Exemple:
server {
error_page 404 /404.html;
}try_files Contextes autorisés: server , location
Politique de validation: doit être unique dans son contexte, prend en charge deux arguments ou plus. Le dernier argument est traité comme une secours.
Exemple:
location / {
try_files $uri $uri / /index.html;
}index Contextes autorisés: http , server , location
Politique de validation: prend en charge un ou plusieurs arguments. Le serveur utilisera le premier fichier trouvé comme index. Le dernier argument est traité comme une secours si elle commence par une barre oblique. Si aucun index n'est trouvé, une liste de répertoires est affichée.
Exemple:
location / {
index index.html index.htm /fallback;
}return Contextes autorisés: server , location
Politique de validation: prend en charge un argument en tant que code d'état pour renvoyer un message d'état prédéfini, ou deux arguments où le premier est le code d'état et le second est une URL pour la redirection ou le texte pour revenir en tant que corps. Lorsqu'ils sont utilisés pour la redirection, les codes d'état communs sont 301 (redirection permanente) ou 302 (redirection temporaire).
Exemple 1: Renvoi d'un code d'état avec le texte:
location /gone {
return 410 "The resource is no longer available" ;
}Cette configuration renvoie un code d'état 410 avec un message personnalisé indiquant que la ressource n'est plus disponible.
Exemple 2: Redirection:
location /oldpage {
return 301 http://example.com/newpage;
} Cette directive redirige les demandes /oldpage vers une nouvelle URL avec un code d'état 301, indiquant une redirection permanente.
limit_except Contextes autorisés: location
Politique de validation: doit être unique dans son contexte, prend en charge un ou plusieurs arguments pour spécifier les méthodes HTTP autorisées.
Exemple: Cette directive restreint les méthodes autorisées pour que le point de terminaison /api puisse obtenir et publier, niant toutes les autres méthodes.
location /api {
limit_except GET POST;
}keepalive_timeout Contextes autorisés: http , server
Politique de validation: doit être unique dans son contexte.
Exemple:
server {
keepalive_timeout 15 ; # Keep connections alive for 15 seconds
}cgi_extension Contextes autorisés: server
Politique de validation: doit être unique dans son contexte, prend en charge un ou plusieurs arguments. Spécifie les extensions de fichiers à traiter comme des scripts CGI.
Exemple:
server {
cgi_extension .cgi .pl .py .sh .extension; # Handle .cgi .pl .py files as CGI scripts
}Cet exemple complet montre une configuration de serveur avec des contextes imbriqués et plusieurs directives, présentant une configuration réaliste pour Nginx 2.0.
http {
client_max_body_size 20M ; # Apply to all servers
keepalive_timeout 15 ; # Connection keep-alive timeout
server {
listen 8080 ;
server_name localhost;
root /var/www/example;
index index.html index.htm index.php;
# Serve static files directly
location / {
try_files $uri $uri / /fallback;
}
# Enable directory listing for /images
location /images {
autoindex on ;
root /var/www/example;
}
# Custom error pages
error_page 404 /404.html;
error_page 500 502 /50x.html;
# API endpoint with method restrictions
location /api {
limit_except GET POST DELETE;
}
# CGI script execution for specific extensions
cgi_extension .cgi .pl;
}
}
Ce guide et ce exemple devraient vous doter des connaissances nécessaires pour configurer efficacement Nginx 2.0, garantissant que votre serveur Web est adapté à vos exigences spécifiques et à vos contextes opérationnels.
Vous trouverez ci-dessous un aperçu de la structure du projet NGINX 2.0, fournissant un aperçu de l'organisation de la base de code et de l'objectif de chaque répertoire et fichiers clés:
/web-server-project
├── src # Source files
│ ├── config # Configuration-related classes and files
│ │ ├── BaseConfig.cpp
│ │ ├── BaseConfig.hpp
│ │ ├── LocationConfig.cpp
│ │ ├── LocationConfig.cpp
│ │ ├── MimeTypeConfig.cpp
│ │ ├── MimeTypeConfig.hpp
│ │ ├── ReturnDirective.cpp
│ │ ├── ReturnDirective.hpp
│ │ ├── ServerConfig.cpp
│ │ ├── ServerConfig.hpp
│ │ ├── TryFilesDirective.cpp
│ │ └── TryFilesDirective.hpp
│ │
│ ├── cgi # CGI handling classes
│ │ ├── CgiDirective.hpp
│ │ ├── CgiDirective.cpp
│ │ ├── CgiHandler.hpp
│ │ └── CgiHandler.cpp
│ │
│ ├── http # HTTP protocol handling classes
│ │ ├── HttpRequest.hpp
│ │ ├── HttpRequest.cpp
│ │ ├── HttpResponse.hpp
│ │ ├── HttpResponse.cpp
│ │ ├── HttpRequest.cpp
│ │ ├── RequestHandler.hpp
│ │ └── RequestHandler.cpp
│ │
│ ├── logging # Logging functionality
│ │ ├── Logger.hpp
│ │ └── Logger.cpp
│ │
│ ├── parsing # Dedicated parsing logic
│ │ ├── ConfigLoader.cpp
│ │ ├── ConfigLoader.hpp
│ │ ├── ConfigNode.cpp
│ │ ├── ConfigNode.hpp
│ │ ├── ConfigParser.cpp
│ │ ├── ConfigParser.hpp
│ │ ├── ConfigTokenizer.cpp
│ │ ├── ConfigTokenizer.hpp
│ │ ├── ContextNode.cpp
│ │ ├── ContextNode.hpp
│ │ ├── DirectiveNode.cpp
│ │ ├── DirectiveNode.hpp
│ │ ├── LogicValidator.cpp
│ │ ├── LogicValidator.hpp
│ │ ├── MimeTypeParser.cpp
│ │ ├── MimeTypeParser.hpp
│ │ ├── SyntaxValidator.cpp
│ │ ├── SyntaxValidator.hpp
│ │ ├── TreeBuilder.cpp
│ │ └── TreeBuilder.hpp
│ │
│ ├── event_polling # Abstraction over kqueue and Epoll
│ │ ├── EpollManager.cpp
│ │ ├── EpollManager.hpp
│ │ ├── EventPoller.cpp
│ │ ├── EventPoller.hpp
│ │ ├── KqueueManager.cpp
│ │ └── KqueueManager.hpp
│ │
│ ├── server # Core server functionality
│ │ ├── ClientState.cpp
│ │ ├── ClientState.hpp
│ │ ├── ResponseState.cpp
│ │ ├── ResponseState.hpp
│ │ ├── Server.cpp
│ │ ├── Server.hpp
│ │ ├── ServerManager.cpp
│ │ └── ServerManager.hpp
│ │
│ └── main.cpp # Entry point of the application
│
├── conf # Configuration files (e.g., nginx.conf, mime.types)
├── content # Static content served by the server
├── logs # Log files generated by the server
├── uploads # Directory for handling uploaded files
└── Makefile # Build instructions for your project
Cette structure est conçue pour améliorer la maintenabilité et l'évolutivité, garantissant que n'importe qui peut facilement naviguer et contribuer au projet.
Pour faciliter l'exploration et la maîtrise des concepts de développement, de réseautage et de programmation de serveurs Web, nous recommandons la liste organisée suivante des ressources:
select() - Comprendre l'appel select() Système pour le multiplexage.select() - plongeon profonde dans les opérations d'E / S non bloquantes et l'utilisation de select() .Des remerciements particuliers sont accordés à Abdelaziz Eroui pour sa conférence informative sur la programmation TCP / IP et socket, qui fait partie de la série manquante semestrielle, qui a fourni des informations approfondies sur les principes fondamentaux de la mise en réseau critique au succès de notre projet.
Nous aimerions également exprimer notre gratitude à Mehdi Cheracher pour sa conférence sur le réseautage et la programmation asynchrone. Ses enseignements ont contribué à guider efficacement notre approche de la gestion des communications du réseau.
Leurs contributions au domaine et au dévouement à l'éducation ont été inestimables à la fois pour notre projet et dans la communauté au sens large.
Nous accueillons chaleureusement les contributions de la communauté et sommes ravis de vous rejoindre pour améliorer Nginx 2.0! Que vous fixiez des bogues, que vous ajoutiez de nouvelles fonctionnalités ou améliorez la documentation, vos contributions sont inestimables pour améliorer Nginx 2.0 pour tout le monde.
Si vous avez des questions ou avez besoin d'aide, n'hésitez pas à tendre la main en ouvrant un problème. Nous sommes là pour vous aider et nous attendre à vos contributions!