Nginx 2.0
1.0.0
O NGINX 2.0 é um servidor web de ponta, orientado a eventos, projetado com eficiência, escalabilidade e conformidade do protocolo HTTP em seu núcleo. Inspirado na arquitetura NGINX original, nosso objetivo era criar um servidor da Web que corresponda ao seu antecessor em desempenho, flexibilidade e facilidade de uso. Desenvolvido através dos esforços colaborativos de mim e da Tukka, o Nginx 2.0 incorpora nosso compromisso com a inovação, oferecendo uma plataforma robusta para o conteúdo da Web estático e dinâmico, otimizado para aplicativos e serviços modernos da Web.
Nossa jornada no desenvolvimento do NGINX 2.0 foi impulsionada por um compromisso com a inovação, o desempenho e a busca da excelência na tecnologia de servir na web. Aqui, nos aprofundamos nos principais recursos que incorporam nossas ambições e proezas técnicas, mostrando os avanços que fizemos para redefinir os recursos de um servidor web moderno.
Ao criar o NGINX 2.0, priorizamos a aderência estrita ao padrão HTTP/1.1, garantindo que nosso servidor suporta robustamente os métodos HTTP essenciais, como get, cabeça, postagem e exclusão. Esse compromisso não apenas se alinha ao nosso objetivo de ampla compatibilidade, mas também reflete nossa dedicação ao fornecer uma base sólida e confiável para a porção na web.
A complexidade e a diversidade das configurações do servidor web nos levaram a implementar um analisador de descida recursiva, espelhando o modelo hierárquico observado no Nginx. Essa estratégia aprimora o gerenciamento da configuração, tornando -a intuitiva e gerenciável, preservando a flexibilidade necessária para configurações complexas.
Compreendendo os diversos ambientes em que nosso servidor opera, desenvolvemos uma camada de abstração personalizada para a multiplexação de E/S que se integra perfeitamente ao Kqueue (MacOS) e Epoll (Linux). Essa abordagem de plataforma cruzada é uma prova de nosso compromisso de otimizar o desempenho em diferentes sistemas, garantindo que o NGINX 2.0 tenha um desempenho eficiente em várias condições operacionais.
Nosso foco na eficiência e no desempenho é particularmente evidente em como o Nginx 2.0 lida com grandes respostas e streaming de vídeo. Ao apoiar o codificação de transferência: solicitações de ranking e range, otimizamos a entrega de conteúdo grande, garantindo o uso mínimo de recursos, mantendo a reprodução de vídeo suave e ininterrupta. Esse recurso é um resultado direto de nossa dedicação ao aprimoramento das experiências do usuário, enfrentando desafios comuns na entrega de conteúdo com soluções inovadoras.
Para estender os recursos do servidor além de servir o conteúdo estático, integramos o suporte abrangente do CGI ao NGINX 2.0. Isso permite a execução de programas externos para geração dinâmica de conteúdo e processamento de formulários, entre outras tarefas. Essa integração reflete nossa visão para um servidor web versátil que pode atender a uma ampla gama de requisitos de aplicativos da Web, oferecendo a flexibilidade necessária para o desenvolvimento de experiências interativas e personalizadas da Web.
O desenvolvimento de uma estrutura de registro configurável no NGINX 2.0 decorre do nosso reconhecimento da função crítica de que o registro desempenha na compreensão e otimização das operações do servidor. Ao implementar um sistema que suporta vários níveis de log e permite configuração dinâmica de saídas de log, fornecemos uma ferramenta poderosa para monitorar, depuração e melhorar o desempenho do servidor. Essa estrutura incorpora nosso compromisso com a transparência e o controle, garantindo que sempre possamos manter um pulso na saúde e na eficiência do servidor.
Bem-vindo ao Nginx 2.0, um servidor web orientado a eventos projetado para eficiência, escalabilidade e conformidade com o padrão HTTP/1.1. Este guia o levará pelas etapas para instalar e construir o NGINX 2.0 no seu sistema.
Antes de começar, verifique se seu sistema atende aos seguintes requisitos:
O Nginx 2.0 usa um Makefile para a construção da fonte. Siga estas etapas para clonar o repositório e construir o servidor:
Clone o repositório
Comece clonando o repositório NGINX 2.0 para sua máquina local:
git clone https://github.com/anassajaanan/Nginx-2.0
cd nginx-2.0Construir o projeto
Você pode construir o projeto em duas configurações: Debug for Development and Lanke for Production.
Debug Build:
A construção de depuração inclui símbolos de depuração adicionais e é compilada com endereço e desinfetantes de comportamento indefinidos (no macOS) ou com fortes verificações de proteção e transbordamento (no Linux) para fins de desenvolvimento e teste.
make debugLançamento Build:
A construção de liberação é otimizada para desempenho com otimização -O3 , direcionamento de arquitetura nativa e otimização no tempo de ligação. Esta é a configuração recomendada para implantação.
make prodExecutando o NGINX 2.0
Para iniciar o servidor, especifique um caminho de arquivo de configuração, se desejado. Se nenhum caminho for fornecido, o servidor usará a configuração padrão localizada em [conf/nginx.conf]
./webserver [configfile_path] # For release build Substitua [configfile_path] pelo caminho do seu arquivo de configuração. Se omitido, o Nginx 2.0 usará a configuração padrão.
Para uma construção de depuração:
./webserver_debug [configfile_path] # For debug build Para limpar os artefatos de construção e inicie o Fresh, use os comandos clean ou fclean :
Objetos e dependências limpos:
make cleanLimpo completo (incluindo binários):
make fcleanVerificação da memória de Valgrind:
Para usuários do Linux, execute sua criação de depuração com Valgrind para verificar se há vazamentos de memória:
make valgrindVerifique se Valgrind está instalado no seu sistema para que isso funcione.
Esta seção descreve as diretivas disponíveis no NGINX 2.0, seus contextos aplicáveis, políticas de validação e exemplos de uso. Essa abordagem estruturada garante uma compreensão clara de como configurar seu servidor da Web de maneira eficaz.
root Contextos permitidos: server , location
Política de validação: deve ser único em seu contexto.
Exemplo:
server {
root /var/www/html; # Document root
}listen Contextos permitidos: server
Política de validação: deve ser único em seu contexto.
Exemplo:
server {
listen 8080 ; # Server listens on port 8080
}autoindex Contextos permitidos: server , location
Política de validação: deve ser único em seu contexto.
Exemplo:
location /images {
autoindex on ; # Enables directory listing
}server_name Contextos permitidos: server
Política de validação: deve ser único em seu contexto.
Exemplo:
server {
server_name example.com;
}client_max_body_size Contextos permitidos: http , server
Política de validação: deve ser único em seu contexto.
Exemplo:
http {
client_max_body_size 20M ; # Limits request body size
}error_page Contextos permitidos: http , server , location
Política de validação: suporta dois ou mais argumentos.
Exemplo:
server {
error_page 404 /404.html;
}try_files Contextos permitidos: server , location
Política de validação: deve ser exclusiva em seu contexto, suporta dois ou mais argumentos. O último argumento é tratado como um retorno.
Exemplo:
location / {
try_files $uri $uri / /index.html;
}index Contextos permitidos: http , server , location
Política de validação: suporta um ou mais argumentos. O servidor usará o primeiro arquivo encontrado como o índice. O último argumento é tratado como um substituto se começar com uma barra. Se nenhum índice for encontrado, uma listagem de diretório será mostrada.
Exemplo:
location / {
index index.html index.htm /fallback;
}return Contextos permitidos: server , location
Política de validação: suporta um argumento como um código de status para retornar uma mensagem de status predefinida ou dois argumentos em que o primeiro é o código de status e o segundo é um URL para redirecionamento ou texto para retornar como corpo. Quando usados para redirecionamento, os códigos de status comuns são 301 (redirecionamento permanente) ou 302 (redirecionamento temporário).
Exemplo 1: retornando um código de status com texto:
location /gone {
return 410 "The resource is no longer available" ;
}Esta configuração retorna um código de status 410 com uma mensagem personalizada, indicando que o recurso não está mais disponível.
Exemplo 2: Redirecionamento:
location /oldpage {
return 301 http://example.com/newpage;
} Esta diretiva redireciona solicitações de /oldpage para um novo URL com um código de status 301, indicando um redirecionamento permanente.
limit_except Contextos permitidos: location
Política de validação: deve ser exclusivo em seu contexto, suporta um ou mais argumentos para especificar métodos HTTP permitidos.
Exemplo: Esta diretiva restringe os métodos permitidos para o endpoint /api obter e postar, negando todos os outros métodos.
location /api {
limit_except GET POST;
}keepalive_timeout Contextos permitidos: http , server
Política de validação: deve ser único em seu contexto.
Exemplo:
server {
keepalive_timeout 15 ; # Keep connections alive for 15 seconds
}cgi_extension Contextos permitidos: server
Política de validação: deve ser exclusiva em seu contexto, suporta um ou mais argumentos. Especifica as extensões de arquivo a serem tratadas como scripts CGI.
Exemplo:
server {
cgi_extension .cgi .pl .py .sh .extension; # Handle .cgi .pl .py files as CGI scripts
}Este exemplo abrangente demonstra uma configuração de servidor com contextos aninhados e várias diretivas, mostrando uma configuração realista para o 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;
}
}
Este guia e exemplo devem equipá -lo com o conhecimento para configurar efetivamente o NGINX 2.0, garantindo que seu servidor da Web seja adaptado aos seus requisitos específicos e contextos operacionais.
Abaixo está uma visão geral da estrutura do projeto NGINX 2.0, fornecendo informações sobre a organização da base de código e o objetivo de cada diretório e arquivos de chave:
/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
Essa estrutura foi projetada para melhorar a manutenção e a escalabilidade, garantindo que qualquer pessoa possa navegar facilmente e contribuir para o projeto.
Para ajudar em mais exploração e domínio do desenvolvimento de servidores da Web, conceitos de rede e programação, recomendamos a seguinte lista de recursos:
select() - Entendendo o sistema select() Sistema para multiplexação.select() - mergulhe profunda em operações de E/S não bloqueador e o uso de select() .Agradecimentos especiais são estendidos a Abdelaziz Eroui por sua palestra informativa sobre programação de TCP/IP e soquete, parte da série de semestre que faltava, que forneceu informações profundas sobre os fundamentos das redes críticas para o sucesso do nosso projeto.
Também gostaríamos de expressar nossa gratidão a Mehdi Cheracher por sua palestra sobre networking e programação assíncrona. Seus ensinamentos foram fundamentais para orientar nossa abordagem para lidar com as comunicações de rede com eficiência.
Suas contribuições para o campo e a dedicação à educação foram inestimáveis para o nosso projeto e para a comunidade em geral.
Agradecemos calorosamente contribuições da comunidade e estamos emocionados por você se juntar a nós na melhoria do Nginx 2.0! Esteja você corrigindo bugs, adicionando novos recursos ou melhorando a documentação, suas contribuições são inestimáveis para melhorar o Nginx 2.0 para todos.
Se você tiver alguma dúvida ou precisar de assistência, sinta -se à vontade para alcançar um problema. Estamos aqui para ajudar e aguardar suas contribuições!
