NGINX 2.0是一款尖端的,事件驱动的Web服务器,其核心均采用效率,可扩展性和HTTP协议合规性。受原始NGINX体系结构的启发,我们的目标是创建与其性能,灵活性和易用性相匹配的Web服务器。 NGINX 2.0通过我自己和Tukka的协作努力开发,体现了我们对创新的承诺,为静态和动态Web内容提供了强大的平台,可针对现代的Web应用程序和服务进行了优化。
我们开发NGINX 2.0的旅程是由对创新,性能和对Web服务技术卓越的追求的承诺所驱动的。在这里,我们深入研究了体现我们的野心和技术实力的核心功能,展示了我们在重新定义现代Web服务器功能方面所取得的进步。
在制作NGINX 2.0中,我们优先遵守对HTTP/1.1标准的严格依从性,以确保我们的服务器强大地支持基本的HTTP方法,例如GET,HEAD,POST,POST和DELETE。这项承诺不仅符合我们的广泛兼容性目标,而且还反映了我们致力于为网络服务提供坚实,可靠的基础。
Web服务器配置的复杂性和多样性使我们实现了递归下降解析器,反映了Nginx中看到的层次模型。该策略增强了配置管理,使其直观且易于管理,同时保留了复杂设置所需的灵活性。
了解服务器运行的各种环境,我们为I/O多路复用开发了一个自定义抽象层,该层与Kqueue(MacOS)和Epoll(Linux)无缝集成。这种跨平台方法证明了我们致力于在不同系统上优化性能的承诺,从而确保NGINX 2.0在各种操作条件下有效地执行。
在NGINX 2.0如何处理大型响应和视频流中,我们对效率和性能的关注尤其明显。通过支持传输编码:块和范围请求,我们优化了大型内容的交付,确保了最少的资源使用情况,同时保持平稳,不间断的视频播放。此功能是我们致力于增强用户体验的直接结果,并通过创新解决方案解决了内容交付方面的共同挑战。
为了将服务器的功能扩展到服务静态内容之外,我们将综合CGI支持集成到NGINX 2.0中。这允许执行用于动态内容生成和形式处理的外部程序以及其他任务。这种集成反映了我们对可以满足广泛Web应用程序需求的多功能Web服务器的愿景,从而提供了开发交互式,个性化的Web体验所需的灵活性。
NGINX 2.0中可配置的记录框架的开发源于我们认识到记录在理解和优化服务器操作中扮演的关键作用。通过实现支持多个日志级别并允许对日志输出的动态配置的系统,我们为自己提供了一种强大的工具来监视,调试和改善服务器性能。该框架体现了我们对透明和控制的承诺,以确保我们始终可以对服务器的健康和效率保持一致。
欢迎使用NGINX 2.0,这是一款旨在效率,可扩展性和符合HTTP/1.1标准的事件驱动的Web服务器。本指南将引导您完成在系统上安装和构建NGINX 2.0的步骤。
在开始之前,请确保您的系统符合以下要求:
Nginx 2.0使用Makefile从源构建。请按照以下步骤克隆存储库并构建服务器:
克隆存储库
首先将NGINX 2.0存储库克隆到您的本地计算机:
git clone https://github.com/anassajaanan/Nginx-2.0
cd nginx-2.0建立项目
您可以通过两种配置来构建项目:开发和发行生产。
调试构建:
调试构建包括其他调试符号,并用地址和未定义的行为消毒器(在MACOS上)或强有力的保护和溢出检查(在Linux上)进行编译,以进行开发和测试。
make debug发布构建:
通过-O3优化,本机体系结构定位和链接时间优化,对发行版构建进行了优化。这是用于部署的建议配置。
make prod运行NGINX 2.0
要启动服务器,请根据需要指定配置文件路径。如果没有提供路径,服务器将使用位于[conf/nginx.conf]的默认配置
./webserver [configfile_path] # For release build将[configfile_path]替换为配置文件的路径。如果省略,NGINX 2.0将使用默认配置。
对于调试构建:
./webserver_debug [configfile_path] # For debug build 要清理构建工件并开始新鲜,请使用clean或fclean命令:
清洁对象和依赖性:
make clean完全清洁(包括二进制):
make fcleanValgrind内存检查:
对于Linux用户,使用Valgrind运行调试构建以检查内存泄漏:
make valgrind确保系统上安装了Valgrind,以使其工作。
本节概述了NGINX 2.0中可用的指令,其适用上下文,验证策略和用法示例。这种结构化方法可确保清楚地了解如何有效配置您的Web服务器。
root允许的上下文: server , location
验证策略:必须在其上下文中是唯一的。
例子:
server {
root /var/www/html; # Document root
}listen允许的上下文: server
验证策略:必须在其上下文中是唯一的。
例子:
server {
listen 8080 ; # Server listens on port 8080
}autoindex允许的上下文: server , location
验证策略:必须在其上下文中是唯一的。
例子:
location /images {
autoindex on ; # Enables directory listing
}server_name允许的上下文: server
验证策略:必须在其上下文中是唯一的。
例子:
server {
server_name example.com;
}client_max_body_size允许的上下文: http , server
验证策略:必须在其上下文中是唯一的。
例子:
http {
client_max_body_size 20M ; # Limits request body size
}error_page允许的上下文: http , server , location
验证策略:支持两个或多个参数。
例子:
server {
error_page 404 /404.html;
}try_files允许的上下文: server , location
验证策略:必须在其上下文中是唯一的,支持两个或多个参数。最后一个论点被视为后备。
例子:
location / {
try_files $uri $uri / /index.html;
}index允许的上下文: http , server , location
验证策略:支持一个或多个参数。服务器将使用第一个发现的文件作为索引。如果最后一个论点从斜线开始,则将其视为后备。如果找不到索引,将显示目录列表。
例子:
location / {
index index.html index.htm /fallback;
}return允许的上下文: server , location
验证策略:支持一个参数作为状态代码以返回预定义的状态消息,或两个参数,其中第一个是状态代码,第二个是重定向或文本作为主体返回的URL。当用于重定向时,通用状态代码为301(永久重定向)或302(临时重定向)。
示例1:用文本返回状态代码:
location /gone {
return 410 "The resource is no longer available" ;
}此配置返回带有自定义消息的410状态代码,表明该资源不再可用。
示例2:重定向:
location /oldpage {
return 301 http://example.com/newpage;
}该指令重定向/oldpage请求 /旧页面,使用301状态代码的新URL,表明永久重定向。
limit_except允许的上下文: location
验证策略:必须在其上下文中是唯一的,支持一个或多个参数以指定允许的HTTP方法。
示例:该指令限制了/api端点获取和发布的允许方法,否认所有其他方法。
location /api {
limit_except GET POST;
}keepalive_timeout允许的上下文: http , server
验证策略:必须在其上下文中是唯一的。
例子:
server {
keepalive_timeout 15 ; # Keep connections alive for 15 seconds
}cgi_extension允许的上下文: server
验证策略:必须在其上下文中是唯一的,支持一个或多个参数。指定要视为CGI脚本的文件扩展名。
例子:
server {
cgi_extension .cgi .pl .py .sh .extension; # Handle .cgi .pl .py files as CGI scripts
}这个全面的示例演示了带有嵌套上下文和多个指令的服务器设置,展示了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;
}
}
本指南和示例应为您提供有效配置Nginx 2.0的知识,以确保您的Web服务器是根据您的特定要求和操作上下文量身定制的。
以下是NGINX 2.0项目结构的概述,可洞悉代码库的组织以及每个目录和密钥文件的目的:
/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
该结构旨在提高可维护性和可扩展性,以确保任何人都可以轻松导航并为项目做出贡献。
为了进一步探索和掌握Web服务器开发,网络和编程概念,我们建议以下策划的资源列表:
select() - 了解select()系统调用以进行多路复用。select() - 深入研究非阻滞I/O操作以及select()的使用。特别感谢Abdelaziz Eroui关于TCP/IP和插座编程的信息演讲,这是丢失学期系列的一部分,该课程深入洞悉了对我们项目成功至关重要的网络基础。
我们还要对Mehdi Cheracher的网络和异步编程的演讲表示感谢。他的教义有助于指导我们有效地处理网络通信的方法。
他们对该领域的贡献和对教育的奉献精神对我们的项目和更广泛的社区都是无价的。
我们非常欢迎社区的捐款,并很高兴能让您加入我们改进Nginx 2.0!无论您是修复错误,添加新功能还是改进文档,您的贡献对于使每个人的Nginx 2.0更好。
如果您有任何疑问或需要帮助,请随时通过打开问题来伸出援手。我们在这里为您提供帮助,并期待您的贡献!