Nginx 2.0
1.0.0
NGINX 2.0 هو خادم ويب متطور يحركه الأحداث مصمم بامتثال كفاءة وقابلية التوسع وبروتوكول HTTP في جوهره. مستوحى من بنية Nginx الأصلية ، كان هدفنا هو إنشاء خادم ويب يطابق سلفه في الأداء والمرونة وسهولة الاستخدام. يجسد Nginx 2.0 من خلال الجهود التعاونية التي بذلتها نفسي و Tukka ، التزامنا بالابتكار ، مما يوفر منصة قوية لكل من محتوى الويب الثابت والديناميكي ، وتم تحسينه لتطبيقات وخدمات الويب الحديثة.
كانت رحلتنا في تطوير NGINX 2.0 مدفوعة بالالتزام بالابتكار والأداء والسعي لتحقيق التميز في تقنية خدمة الويب. هنا ، نتعمق في الميزات الأساسية التي تجسد طموحاتنا وبراعتنا الفنية ، مع عرض الخطوات التي قطعناها على إعادة تعريف إمكانيات خادم الويب الحديث.
في صياغة NGINX 2.0 ، قمنا بإعطاء الأولوية للالتزام الصارم بمعيار HTTP/1.1 ، مما يضمن لخادمنا يدعم بشكل قوي أساليب HTTP الأساسية مثل GET و HEAD و POST و DELETE. لا يتوافق هذا الالتزام مع هدفنا للتوافق الواسع فحسب ، بل يعكس أيضًا تفانينا في توفير أساس قوي وموثوق لخدمة الويب.
أدى تعقيد وتنوع تكوينات خادم الويب إلى تنفيذ محلل نزول متكرر ، مما يعكس النموذج الهرمي الذي شوهد في Nginx. تعزز هذه الاستراتيجية إدارة التكوين ، مما يجعلها بديهية وقابلة للإدارة مع الحفاظ على المرونة اللازمة للإعدادات المعقدة.
فهم البيئات المتنوعة التي يعمل فيها خادمنا ، قمنا بتطوير طبقة تجريدية مخصصة لضمادات I/O التي يتكامل بسلاسة مع كل من Kqueue (MacOS) و Epoll (Linux). يعد هذا النهج عبر المنصات شهادة على التزامنا بتحسين الأداء عبر أنظمة مختلفة ، مما يضمن أداء Nginx 2.0 بكفاءة في ظل ظروف تشغيلية مختلفة.
إن تركيزنا على الكفاءة والأداء واضح بشكل خاص في كيفية تعامل Nginx 2.0 مع الاستجابات الكبيرة وتدفق الفيديو. من خلال دعم ترميز النقل: طلبات مكثفة ونطاق ، قمنا بتحسين تسليم المحتوى الكبير ، وضمان الحد الأدنى من استخدام الموارد مع الحفاظ على تشغيل الفيديو السلس دون انقطاع. هذه الميزة هي نتيجة مباشرة لتفانينا في تعزيز تجارب المستخدم ، ومعالجة التحديات الشائعة في توصيل المحتوى من خلال حلول مبتكرة.
لتوسيع قدرات الخادم إلى ما بعد تقديم المحتوى الثابت ، قمنا بدمج دعم CGI الشامل في Nginx 2.0. يسمح ذلك بتنفيذ البرامج الخارجية لتوليد المحتوى الديناميكي ومعالجة النماذج ، من بين مهام أخرى. يعكس هذا التكامل رؤيتنا لخادم ويب متعدد الاستخدامات يمكنه تلبية مجموعة واسعة من متطلبات تطبيقات الويب ، مما يوفر المرونة اللازمة لتطوير تجارب الويب التفاعلية والشخصية.
ينبع تطوير إطار تسجيل قابل للتكوين داخل NGINX 2.0 من إدراكنا للدور الحاسم الذي يلعبه التسجيل في فهم عمليات الخادم وتحسينه. من خلال تطبيق نظام يدعم مستويات السجل المتعددة ويسمح بالتكوين الديناميكي لمخرجات السجل ، قمنا بتزويد أنفسنا بأداة قوية لمراقبة أداء الخادم وتصحيح الأخطاء وتحسينها. يجسد هذا الإطار التزامنا بالشفافية والتحكم ، مما يضمن أن نتمكن دائمًا من الحفاظ على نبض على صحة الخادم وكفاءته.
مرحبًا بكم في NGINX 2.0 ، وهو خادم ويب يحركه الحدث مصمم للكفاءة ، قابلية التوسع ، والامتثال لمعايير HTTP/1.1. سوف يسير هذا الدليل عبر الخطوات لتثبيت وبناء 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 fcleanفحص ذاكرة فالغريند:
بالنسبة لمستخدمي Linux ، قم بتشغيل Debug Build مع Valgrind للتحقق من تسرب الذاكرة:
make valgrindتأكد من تثبيت Valgrind على نظامك حتى يعمل هذا.
يحدد هذا القسم التوجيهات المتاحة في Nginx 2.0 ، وسياقاتها المعمول بها ، وسياسات التحقق من الصحة ، وأمثلة الاستخدام. يضمن هذا النهج المنظم فهمًا واضحًا لكيفية تكوين خادم الويب الخاص بك بشكل فعال.
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 إلى عنوان URL جديد مع رمز الحالة 301 ، مما يشير إلى إعادة توجيه دائم.
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 بشكل فعال ، مما يضمن أن يكون خادم الويب الخاص بك مصمماً بمتطلباتك المحددة والسياقات التشغيلية.
فيما يلي نظرة عامة على هيكل مشروع 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
تم تصميم هذا الهيكل لتعزيز قابلية الصيانة وقابلية التوسع ، مما يضمن أن يتمكن أي شخص من التنقل بسهولة والمساهمة في المشروع.
للمساعدة في مزيد من الاستكشاف وإتقان تطوير خادم الويب والشبكات والبرمجة ، نوصي بالقائمة المنسقة التالية للموارد:
select() - فهم استدعاء النظام select() لتعدد الإرسال.select() - الغوص العميق في عمليات الإدخال/الإخراج غير المحظورة واستخدام select() .يتم تمديد شكر خاص إلى عبد العزيز إيروي على محاضرته المفيدة حول برمجة TCP/IP ومقبس ، وهي جزء من سلسلة الفصل الدراسي المفقودة ، والتي وفرت رؤى عميقة في أساسيات التواصل الحرجة لنجاح مشروعنا.
نود أيضًا أن نعرب عن امتناننا لمهدي Cheracher لمحاضرته حول الشبكات والبرمجة غير المتزامنة. لقد كانت تعاليمه فعالة في توجيه نهجنا للتعامل مع اتصالات الشبكة بكفاءة.
كانت مساهماتهم في هذا المجال والتفاني في التعليم لا تقدر بثمن لكل من مشروعنا والمجتمع الأوسع.
نحن نرحب بحرارة بالمساهمات من المجتمع ونشعر بسعادة غامرة لأن تنضم إلينا في تحسين Nginx 2.0! سواء كنت تقوم بإصلاح الأخطاء أو إضافة ميزات جديدة أو تحسين الوثائق ، فإن مساهماتك لا تقدر بثمن لجعل Nginx 2.0 أفضل للجميع.
إذا كان لديك أي أسئلة أو تحتاج إلى مساعدة ، فلا تتردد في التواصل عن طريق فتح مشكلة. نحن هنا للمساعدة ونتطلع إلى مساهماتك!
