Nginx 2.0 es un servidor web de vanguardia, basado en eventos, diseñado con eficiencia, escalabilidad y cumplimiento del protocolo HTTP en su núcleo. Inspirado en la arquitectura Nginx original, nuestro objetivo era crear un servidor web que coincida con su predecesor en rendimiento, flexibilidad y facilidad de uso. Desarrollado a través de los esfuerzos de colaboración de mí y Tukka, Nginx 2.0 incorpora nuestro compromiso con la innovación, ofreciendo una plataforma robusta para contenido web estático y dinámico, optimizado para aplicaciones y servicios web modernos.
Nuestro viaje en el desarrollo de NGINX 2.0 ha sido impulsado por un compromiso con la innovación, el rendimiento y la búsqueda de la excelencia en la tecnología de servicio web. Aquí, profundizamos en las características centrales que encarnan nuestras ambiciones y destreza técnica, mostrando los avances que hemos logrado para redefinir las capacidades de un servidor web moderno.
Al elaborar Nginx 2.0, priorizamos la estricta adherencia al estándar HTTP/1.1, asegurando que nuestro servidor admita de manera robusta métodos HTTP esenciales como Get, Head, Post y Delete. Este compromiso no solo se alinea con nuestro objetivo para una amplia compatibilidad, sino que también refleja nuestra dedicación para proporcionar una base sólida y confiable para la servicio web.
La complejidad y diversidad de las configuraciones del servidor web nos llevó a implementar un analizador de descenso recursivo, reflejando el modelo jerárquico visto en Nginx. Esta estrategia mejora la gestión de la configuración, lo que la hace intuitiva y manejable al tiempo que preserva la flexibilidad necesaria para configuraciones complejas.
Comprendiendo los diversos entornos en los que opera nuestro servidor, desarrollamos una capa de abstracción personalizada para la multiplexación de E/S que se integra sin problemas con Kqueue (MacOS) y Epoll (Linux). Este enfoque multiplataforma es un testimonio de nuestro compromiso de optimizar el rendimiento en diferentes sistemas, asegurando que NGINX 2.0 funcione de manera eficiente en diversas condiciones operativas.
Nuestro enfoque en la eficiencia y el rendimiento es particularmente evidente en cómo Nginx 2.0 maneja grandes respuestas y transmisión de video. Al admitir la codificación de transferencia: solicitudes de rango y de rango, hemos optimizado la entrega de contenido grande, asegurando un uso mínimo de recursos al tiempo que mantiene una reproducción de video sin interrupciones e ininterrumpidas. Esta característica es un resultado directo de nuestra dedicación para mejorar las experiencias de los usuarios, abordando desafíos comunes en la entrega de contenido con soluciones innovadoras.
Para extender las capacidades del servidor más allá de servir contenido estático, integramos el soporte integral de CGI en Nginx 2.0. Esto permite la ejecución de programas externos para la generación de contenido dinámico y el procesamiento de formularios, entre otras tareas. Esta integración refleja nuestra visión de un servidor web versátil que puede atender a una amplia gama de requisitos de aplicaciones web, ofreciendo la flexibilidad necesaria para desarrollar experiencias web interactivas y personalizadas.
El desarrollo de un marco de registro configurable dentro de Nginx 2.0 proviene de nuestro reconocimiento del papel crítico que desempeña el registro en la comprensión y la optimización de las operaciones del servidor. Al implementar un sistema que admite múltiples niveles de registro y permite la configuración dinámica de salidas de registro, nos hemos proporcionado una herramienta poderosa para monitorear, depurar y mejorar el rendimiento del servidor. Este marco incorpora nuestro compromiso con la transparencia y el control, asegurando que siempre podamos mantener un pulso en la salud y la eficiencia del servidor.
Bienvenido a Nginx 2.0, un servidor web basado en eventos diseñado para la eficiencia, la escalabilidad y el cumplimiento del estándar HTTP/1.1. Esta guía lo guiará a través de los pasos para instalar y construir Nginx 2.0 en su sistema.
Antes de comenzar, asegúrese de que su sistema cumpla con los siguientes requisitos:
Nginx 2.0 usa un archivo MakE para construir desde la fuente. Siga estos pasos para clonar el repositorio y construir el servidor:
Clonar el repositorio
Comience clonando el repositorio Nginx 2.0 a su máquina local:
git clone https://github.com/anassajaanan/Nginx-2.0
cd nginx-2.0Construir el proyecto
Puede construir el proyecto en dos configuraciones: Depurar para el desarrollo y la liberación para la producción.
Construcción de depuración:
La construcción de depuración incluye símbolos de depuración adicionales y se compila con dirección y desinfectantes de comportamiento indefinidos (en macOS) o con una fuerte protección y controles de desbordamiento (en Linux) para fines de desarrollo y prueba.
make debugConstrucción de lanzamiento:
La compilación de lanzamiento está optimizada para el rendimiento con optimización -O3 , orientación de arquitectura nativa y optimización del tiempo de enlace. Esta es la configuración recomendada para la implementación.
make prodEjecutando nginx 2.0
Para iniciar el servidor, especifique una ruta del archivo de configuración si lo desea. Si no se proporciona una ruta, el servidor usará la configuración predeterminada ubicada en [conf/nginx.conf]
./webserver [configfile_path] # For release build Reemplace [configfile_path] con la ruta a su archivo de configuración. Si se omite, Nginx 2.0 usará la configuración predeterminada.
Para una construcción de depuración:
./webserver_debug [configfile_path] # For debug build Para limpiar los artefactos de construcción y comenzar de nuevo, use los comandos clean o fclean :
Objetos y dependencias limpias:
make cleanLimpieza completa (incluidos binarios):
make fcleanVerificación de memoria de Valgrind:
Para los usuarios de Linux, ejecute su compilación de depuración con Valgrind para verificar si hay filtraciones de memoria:
make valgrindAsegúrese de que Valgrind esté instalado en su sistema para que esto funcione.
Esta sección describe las directivas disponibles en Nginx 2.0, sus contextos aplicables, políticas de validación y ejemplos de uso. Este enfoque estructurado garantiza una comprensión clara de cómo configurar su servidor web de manera efectiva.
root Contextos permitidos: server , location
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
server {
root /var/www/html; # Document root
}listen Contextos permitidos: server
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
server {
listen 8080 ; # Server listens on port 8080
}autoindex Contextos permitidos: server , location
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
location /images {
autoindex on ; # Enables directory listing
}server_name Contextos permitidos: server
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
server {
server_name example.com;
}client_max_body_size Contextos permitidos: http , server
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
http {
client_max_body_size 20M ; # Limits request body size
}error_page Contextos permitidos: http , server , location
Política de validación: admite dos o más argumentos.
Ejemplo:
server {
error_page 404 /404.html;
}try_files Contextos permitidos: server , location
Política de validación: debe ser única dentro de su contexto, admite dos o más argumentos. El último argumento es tratado como un respaldo.
Ejemplo:
location / {
try_files $uri $uri / /index.html;
}index Contextos permitidos: http , server , location
Política de validación: respalda uno o más argumentos. El servidor usará el primer archivo encontrado como índice. El último argumento se trata como un respaldo si comienza con un corte. Si no se encuentra ningún índice, se muestra un listado de directorio.
Ejemplo:
location / {
index index.html index.htm /fallback;
}return Contextos permitidos: server , location
Política de validación: admite cualquiera de los dos argumentos como un código de estado para devolver un mensaje de estado predefinido, o dos argumentos en los que el primero es el código de estado y el segundo es una URL para la redirección o el texto para devolver como cuerpo. Cuando se usan para la redirección, los códigos de estado comunes son 301 (redirección permanente) o 302 (redirección temporal).
Ejemplo 1: devolver un código de estado con texto:
location /gone {
return 410 "The resource is no longer available" ;
}Esta configuración devuelve un código de estado 410 con un mensaje personalizado que indica que el recurso ya no está disponible.
Ejemplo 2: redirección:
location /oldpage {
return 301 http://example.com/newpage;
} Esta directiva redirige las solicitudes de /oldpage a una nueva URL con un código de estado 301, lo que indica una redirección permanente.
limit_except Contextos permitidos: location
Política de validación: debe ser única dentro de su contexto, admite uno o más argumentos para especificar métodos HTTP permitidos.
Ejemplo: esta directiva restringe los métodos permitidos para el punto final /api para obtener y publicar, negando todos los demás métodos.
location /api {
limit_except GET POST;
}keepalive_timeout Contextos permitidos: http , server
Política de validación: debe ser única dentro de su contexto.
Ejemplo:
server {
keepalive_timeout 15 ; # Keep connections alive for 15 seconds
}cgi_extension Contextos permitidos: server
Política de validación: debe ser única dentro de su contexto, respalda uno o más argumentos. Especifica las extensiones de archivo que se tratarán como scripts CGI.
Ejemplo:
server {
cgi_extension .cgi .pl .py .sh .extension; # Handle .cgi .pl .py files as CGI scripts
}Este ejemplo completo demuestra una configuración del servidor con contextos anidados y múltiples directivas, mostrando una configuración realista para 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;
}
}
Esta guía y ejemplo debe equiparlo con el conocimiento para configurar Nginx 2.0 de manera efectiva, asegurando que su servidor web esté adaptado a sus requisitos específicos y contextos operativos.
A continuación se muestra una descripción general de la estructura del proyecto NGINX 2.0, que proporciona información sobre la organización de la base de código y el propósito de cada directorio y archivos clave:
/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
Esta estructura está diseñada para mejorar la mantenibilidad y la escalabilidad, asegurando que cualquiera pueda navegar y contribuir fácilmente al proyecto.
Para ayudar en una mayor exploración y dominio del desarrollo del servidor web, las redes y los conceptos de programación, recomendamos la siguiente lista de recursos curados:
select() - Comprender la llamada del sistema select() para la multiplexación.select() - Dive profundo en operaciones de E/S sin bloqueo y el uso de select() .Un agradecimiento especial se extiende a Abdelaziz Eroui por su conferencia informativa sobre la programación TCP/IP y Socket, parte de la serie de semestres faltantes, que proporcionó profundas ideas sobre los fundamentos de las redes críticas para el éxito de nuestro proyecto.
También nos gustaría expresar nuestra gratitud a Mehdi Cheracher por su conferencia sobre redes y programación asincrónica. Sus enseñanzas han sido fundamentales para guiar nuestro enfoque para manejar las comunicaciones de redes de manera eficiente.
Sus contribuciones al campo y la dedicación a la educación han sido invaluables tanto para nuestro proyecto como para la comunidad en general.
¡Agradecemos calurosamente las contribuciones de la comunidad y estamos encantados de que se una a nosotros para mejorar Nginx 2.0! Ya sea que esté arreglando errores, agregando nuevas funciones o mejorando la documentación, sus contribuciones son invaluables para mejorar Nginx 2.0 para todos.
Si tiene alguna pregunta o necesita asistencia, no dude en comunicarse con la apertura de un problema. ¡Estamos aquí para ayudar y esperar sus contribuciones!