Nginx یک وب سرور و پروکسی ایمیل است که از سال 2004 در دسترس عموم قرار گرفته است. توسعه این پروژه در سال 2002 آغاز شد، در زبان روسی این نام شبیه موتور ex به نظر می رسد. Nginx به دلیل خلق دستان یک برنامه نویس معروف، ایگور سیسوف، در ابتدا برای شرکت Rambler در نظر گرفته شده بود. این برای سیستم عامل های متعلق به گروه شبه یونیکس طراحی شده است. مونتاژ با موفقیت در OpenBSD، FreeBSD، Linux، Mac OS X، Solaris آزمایش شده است. بر روی پلت فرم ویندوز مایکروسافت Nginx با ظهور نسخه باینری نسخه 0.7.52 شروع به کار کرد.

آمار مارس 2011 نشان می دهد که تعداد سایت های ارائه شده توسط Nginx از مرز 22 میلیون عبور کرده است. امروزه Nginx توسط پروژه های معروفی مانند Rambler، Begun، Yandex، SourceForge.net، WordPress.com، vkontakte.ru و دیگران استفاده می شود. همراه با lighttpd، Nginx برای ارائه محتوای استاتیک تولید شده توسط یک برنامه وب "ناخوشایند" که "تحت اختیار" یک وب سرور دیگر اجرا می شود استفاده می شود.
اما قبل از پرداختن به ویژگی‌های کاربردی Nginx، به یاد داشته باشید که یک وب سرور به طور کلی و یک سرور پروکسی به طور خاص چیست.

وب سرور و سرور پروکسی

وب سرورسروری است که درخواست های HTTP را از مرورگرهای وب و سایر کلاینت ها دریافت می کند و پاسخ های HTTP را برای آنها صادر می کند. دومی معمولاً با یک صفحه HTML، جریان رسانه، تصویر، فایل یا داده های دیگر نشان داده می شود. یک وب سرور به این صورت درک می شود نرم افزار، که عملکردهای وب سرور و سخت افزار را انجام می دهد. تبادل داده ها و اطلاعات درخواستی از طریق پروتکل HTTP انجام می شود.

به لیست ویژگی های اضافیسرورهای وب عبارتند از: مجوز و احراز هویت کاربران، ثبت دسترسی آنها به منابع، پشتیبانی HTTPS برای امنیت سوئیچینگ با مشتریان، و موارد دیگر. متداول ترین وب سرور مورد استفاده در سیستم عامل های مشابه یونیکس آپاچی است. خط سوم در لیست ترجیحات مشتری در حال حاضر توسط Nginx اشغال شده است.

سرور پروکسیبه مشتریان اجازه تماس می دهد پرس و جوهای جستجوبه خدمات شبکهبه شکل غیر مستقیم یعنی سروری است که در هدایت درخواست های مشتری به سرورهای دیگر تخصص دارد. با اتصال به یک سرور پراکسی و درخواست منبعی که در سرور دیگری قرار دارد، کلاینت این توانایی را دارد که ناشناس بماند و از رایانه محافظت کند. حملات شبکه. سرور پروکسی داده های درخواستی را یا از حافظه پنهان خود (در صورت وجود) یا با دریافت آنها از سرور مشخص شده برای مشتری صادر می کند. در برخی موارد (برای دستیابی به اهداف فوق)، پاسخ سرور و همچنین درخواست مشتری توسط پروکسی سرور قابل تغییر است.

ساده ترین سرور پروکسی Network Address Translator یا NAT است. در سال 2000، پروکسی NAT در توزیع ویندوز ساخته شد. سرورهای پروکسی مانند هر پدیده ای دو روی سکه دارند، یعنی هم می توان از آنها برای خیر و هم برای شر استفاده کرد. به عنوان مثال، با کمک آنها، کسانی که از تحریم به دلیل اقدامات ناشایست خود در شبکه می ترسند، آدرس IP خود را پنهان می کنند ...

محدوده عملکردی Nginx:

• نگهداری سرور فایل های فهرست، پرس و جوهای استاتیک، تولید توصیفگرهای کش باز کردن فایل ها, لیست فایل;
• پروکسی تسریع شده، توزیع بار اولیه، تحمل خطا.
• پشتیبانی از کش در طول پروکسی سریع و FastCGI.
• پشتیبانی از FastCGI (شتاب داده شده) و سرورهای memcached.
• مدولار بودن، فیلترها، از جمله "رزومه" (محدوده بایت) و فشرده سازی (gzip).
• احراز هویت HTTP، پاسخ های تکه تکه شده، فیلتر SSI.
• اجرای موازی چندین درخواست فرعی در صفحه، پردازش شده از طریق FastCGI یا یک پروکسی در فیلتر SSI.
• پشتیبانی StartTLS و SSL.
• توانایی پشتیبانی از پرل تعبیه شده؛
• احراز هویت ساده (USER/PASS، LOGIN)؛
• هدایت مجدد سرور (پراکسی IMAP/POP3) کاربر به باطن IMAP/POP3 با استفاده از یک سرور احراز هویت خارجی (HTTP).

برای کسانی که با این اصطلاح "روی شما" نیستند، ممکن است شرح عملکرد Nginx بسیار مبهم به نظر برسد. اما وقتی صحبت از راه‌هایی برای استفاده خاص از این وب سرور می‌شود، به تدریج شروع به از بین رفتن خواهد کرد.

معماری و پیکربندی

Worker در Nginx بسیاری از اتصالات را به طور همزمان پردازش می کند و برای آنها تماس هایی را با سیستم عامل (سیستم عامل) epoll (Linux)، انتخاب و kqueue (FreeBSD) فراهم می کند. داده های دریافتی از مشتری توسط ماشین حالت تجزیه می شود. درخواست تجزیه شده توسط زنجیره ای از ماژول های مشخص شده توسط پیکربندی پردازش می شود. شکل‌گیری پاسخ به کلاینت در بافرها اتفاق می‌افتد که می‌توانند به بخش فایل اشاره کنند یا داده‌ها را در حافظه ذخیره کنند. توالی انتقال داده به مشتری توسط زنجیره هایی که بافرها در آنها گروه بندی می شوند تعیین می شود.

از نظر ساختاری، سرور HTTP Nginx به سرورهای مجازی تقسیم می شود که به نوبه خود به مکان ها تقسیم می شوند. سرور مجازییا دستورالعمل، می توانید پورت ها و آدرس ها را برای دریافت اتصالات تنظیم کنید. شما می توانید یک URI دقیق، بخشی از یک URI یا یک عبارت منظم برای مکان مشخص کنید. Pool ها که دنباله ای از بلوک های از پیش انتخاب شده حافظه هستند، برای مدیریت حافظه آنلاین استفاده می شوند. یک بلوک، که در ابتدا برای استخر اختصاص داده شده بود، دارای طول 1 تا 16 کیلوبایت است. به مناطق - اشغالی و غیر اشغالی تقسیم می شود. همانطور که دومی پر می شود، انتخاب یک شی جدید با تشکیل یک بلوک جدید تضمین می شود.

مشتریان از نظر جغرافیایی با استفاده از آدرس IP خود در Nginx طبقه بندی می شوند ماژول ویژه. سیستم درختی Radix به شما امکان می دهد تا به سرعت با آدرس های IP کار کنید و حداقل حافظه را اشغال کنید.

مزایای Nginx

Nginx بسیار سریع در نظر گرفته می شود سرور HTTP. به جای آپاچی یا همراه با آن، از Nginx برای سرعت بخشیدن به پردازش درخواست ها و کاهش بار روی سرور استفاده می شود. واقعیت این است که امکانات عظیمی که توسط معماری ماژولار آپاچی در نظر گرفته شده توسط اکثر کاربران مورد نیاز نیست. پرداخت هزینه برای این عملکرد بی ادعا باعث کاهش قابل توجه منابع سیستم می شود. سایت های معمولی به جای اسکریپت ها بیشتر تحت سلطه فایل های ثابت (تصاویر، شیوه نامه ها، جاوا اسکریپت) هستند. هیچ عملکرد خاصی برای انتقال این فایل ها به بازدید کننده منبع مورد نیاز نیست، زیرا کار بسیار ساده است. و بنابراین، وب سرور برای پردازش چنین درخواست هایی باید مانند Nginx ساده و سبک باشد.

راه های استفاده از Nginx

در یک پورت/IP مجزا.اگر منبع با تصاویر یا فایل هایی برای دانلود اشباع شده باشد، Nginx را می توان روی یک پورت یا IP جداگانه پیکربندی کرد و محتوای ثابت را از طریق آن توزیع کرد. برای انجام این کار، با این حال، شما باید کمی با تغییر لینک ها در سایت مشکل داشته باشید. با تعداد زیادی درخواست برای فایل های ثابت، ایجاد یک سرور جداگانه و نصب Nginx بر روی آن منطقی است.

پروکسی تسریع شده. با استفاده از این گزینه، تمام درخواست های بازدیدکنندگان ابتدا به Nginx می رسد. درخواست های فایل های ثابت (مانند یک تصویر، HTML ساده، جاوا اسکریپت یا فایل CSS) توسط خود Nginx انجام می شود. اگر کاربر به یک اسکریپت خاص دسترسی پیدا کند، درخواست را به بخش آپاچی هدایت می کند. نیازی به هیچ تغییری با کد سایت نیست.

اگر کانال از سرور به بازدید کننده و بالعکس کند باشد، این استفاده از Nginx می تواند تأثیر بیشتری داشته باشد. درخواست دریافت شده از بازدید کننده برای پردازش توسط آپاچی به Nginx منتقل می شود. پس از پردازش درخواست، آپاچی صفحه را به Nginx هدایت می کند و با احساس موفقیت، اتصال را قطع می کند. اکنون Nginx می تواند تا زمانی که کاربر دوست داشته باشد، یک صفحه را عملاً بدون صرف منابع سیستم برای کاربر ارسال کند. آپاچی در جای خود با یک بار حافظه غیرمنطقی بالا در هنگام اجرای تقریباً بیکار همراه خواهد بود. به هر حال، این مورد استفاده Nginx نام دیگری دارد: "فرانت اند به آپاچی".

Nginx به علاوه FastCGI.اگر مفسر زبانی که اسکریپت های سایت با آن نوشته شده اند، از فناوری FastCGI پشتیبانی کند، ممکن است اصلاً به آپاچی نیاز نباشد. از جمله این زبان ها می توان به PHP، Perl و تعدادی دیگر اشاره کرد. درست است، در این مورد، ممکن است مجبور شوید کدهای اسکریپت را تغییر دهید.

مطالب دقیق زیادی در مورد نحوه نصب و پیکربندی Nginx در شبکه وجود دارد. می توانید اطلاعات بیشتری در مورد Nginx در وب سایت توسعه دهنده آن Igor Sysoev کسب کنید.

یک وب سرور اختصاصی مبتنی بر nginx یک راه عالی برای بهبود عملکرد وب سایت ها است. از نظر سرعت پردازش محتوای استاتیک، آن را به سادگی ندارد: به راحتی چندین هزار اتصال همزمان را تحمل می کند و می تواند به راحتی بهینه شده و با هر پیکربندی تنظیم شود. با این حال؟ nginx که به عنوان یک front-end برای آپاچی عمل می کند، آسیب پذیرترین نقطه کل زیرساخت وب است، بنابراین امنیت nginx باید مورد توجه ویژه قرار گیرد.

این مقاله نوعی برنامه آموزشی یا در صورت تمایل خلاصه ای از تمامی تکنیک های ارتقای امنیت nginx است. این شامل تئوری، توضیحاتی در مورد اصول اولیه راه اندازی یک وب سرور و آب دیگر نخواهد بود. در عوض، شما یک برنامه جامع دریافت خواهید کرد مواد عملی، که تمام مراحل اساسی را که باید برای به دست آوردن یک وب سرور واقعاً ایمن انجام دهید، شرح می دهد.

نصب و راه اندازی

بسته nginx به صورت از پیش کامپایل شده برای هر توزیع موجود است. با این حال، با ساختن خود سرور، می‌توانید آن را فشرده‌تر و قابل اعتمادتر کنید، و همچنین می‌توانید رشته سلام سرور وب را تغییر دهید تا از بچه‌های اسکریپت غیر هوشمند جلوگیری کنید.

رشته Hello Web Server را تغییر دهید

منابع nginx را دانلود کنید، فایل src/http/ngx_http_header_filter_module.c را باز کنید و دو خط زیر را پیدا کنید:

static char ngx_http_server_string = "سرور: nginx" CRLF;
static char ngx_http_server_full_string = "سرور: " NGINX_VER CRLF;

آنها را با چیزی شبیه به این جایگزین کنید:

استاتیک char ngx_http_server_string = "سرور: ][ وب سرور"CRF;
static char ngx_http_server_full_string = "سرور: ][ وب سرور" CRLF;

ماژول های nginx را که استفاده نمی کنید حذف کنید

برخی از ماژول های nginx درست در زمان کامپایل به وب سرور متصل می شوند و هر یک از آنها به طور بالقوه خطرناک هستند. شاید در آینده یک آسیب پذیری در یکی از آنها پیدا شود و سرور شما در معرض خطر قرار گیرد. با غیرفعال کردن ماژول های غیر ضروری، می توانید خطر چنین وضعیتی را به میزان قابل توجهی کاهش دهید.

با دستورات زیر بسازید:

# ./configure --without-http_autoindex_module --without-http_ssi_module
#ساخت
# را نصب کنید

بنابراین شما با ماژول های SSI (و در اکثر موارد بی فایده) از پیش غیرفعال شده (و در اکثر موارد بی فایده) و Autoindex، nginx دریافت خواهید کرد. برای اینکه بفهمید کدام ماژول ها می توانند به طور ایمن از سرور وب حذف شوند، اسکریپت پیکربندی را با پرچم "-help" اجرا کنید.

تشریح nginx.conf

پس از نصب، nginx باید پیکربندی شود. قبلاً مطالبی در صفحات مجله وجود داشت که این روند را توصیف می کرد، اما ما به موضوع مقاله می مانیم و در مورد راه های افزایش امنیت سرور صحبت می کنیم.

غیرفعال کردن نمایش نسخه سرور در تمام صفحات خطا

خط "server_tokens off" را به فایل nginx.conf اضافه کنید. این باعث می شود nginx اطلاعات نوع و نسخه وب سرور را در صفحات ایجاد شده در پاسخ به درخواست مشتری اشتباه پنهان کند.

حفاظت از سقوط پشته را تنظیم کنید

افزودن به بخش سرور خطوط زیر:

#vi /etc/nginx/nginx.conf

# حداکثر اندازهبافر برای ذخیره بدنه درخواست مشتری
client_body_buffer_size 1K;
# حداکثر اندازه بافر برای ذخیره هدرهای درخواست مشتری
client_header_buffer_size 1k;
# حداکثر اندازه بدنه درخواست مشتری، مشخص شده در قسمت سرصفحه Content-Length. اگر سرور باید از آپلود فایل پشتیبانی کند، این مقدار باید افزایش یابد
client_max_body_size 1k;
# تعداد و اندازه بافرها برای خواندن هدر درخواست مشتری بزرگ
large_client_header_buffers 2 1k;

به دستورالعمل large_client_header_buffers توجه کنید. به‌طور پیش‌فرض، nginx چهار بافر را برای ذخیره‌سازی رشته URI اختصاص می‌دهد که هرکدام به اندازه هستند برابر اندازهصفحات حافظه (برای x86 این 4 کیلوبایت است). بافرها هر بار که اتصال در پایان درخواست به حالت نگه داشتن زنده می رود آزاد می شوند. دو بافر 1 کیلوبایتی فقط می توانند URI های 2 کیلوبایتی را ذخیره کنند که به مبارزه با ربات ها و حملات DoS کمک می کند.

برای بهبود عملکرد، خطوط زیر را اضافه کنید:

#vi /etc/nginx/nginx.conf

# مهلت زمانی هنگام خواندن بدنه درخواست مشتری
client_body_timeout 10;
# مهلت زمانی هنگام خواندن سرصفحه درخواست مشتری
client_header_timeout 10;
# مهلت زمانی که پس از آن ارتباط keep-alive با مشتری از سمت سرور بسته نخواهد شد
keepalive_timeout 5 5;
# مهلت زمانی در هنگام ارسال پاسخ به مشتری
send_timeout 10;

تعداد اتصالات همزمان را کنترل کنید

برای محافظت از وب سرور از اضافه بار و تلاش برای انجام یک حمله DoS، خطوط زیر را به پیکربندی اضافه کنید:

#vi /etc/nginx/nginx.conf

# ناحیه (محدوده ها) که در آن حالت های جلسه ذخیره می شود را شرح دهید. یک منطقه 1 مگابایتی می تواند حدود 32000 حالت را ذخیره کند، ما اندازه آن را 5 مگابایت تنظیم کردیم
محدودیت های limit_zone $binary_remote_addr 5m;
# حداکثر تعداد اتصالات همزمان را برای یک جلسه تنظیم کنید. در واقع این عدد حداکثر تعداد اتصالات را از یک IP تعیین می کند
limit_conn slimits 5;

دستور اول باید در بخش HTTP باشد، دومی در بخش مکان. هنگامی که تعداد اتصالات از حد مجاز فراتر رود، مشتری پیام "سرویس در دسترس نیست" را با کد 503 دریافت می کند.

اتصالات فقط به دامنه شما مجاز است

مهاجمان می توانند از ربات ها برای اسکن زیرشبکه ها و یافتن وب سرورهای آسیب پذیر استفاده کنند. به طور معمول، ربات ها به سادگی در محدوده آدرس IP به دنبال 80 پورت باز هستند و یک درخواست HEAD برای دریافت اطلاعات در مورد وب سرور ارسال می کنند (یا صفحه نخست). شما به راحتی می توانید با غیرفعال کردن دسترسی به سرور از طریق آدرس IP (افزودن به بخش فرعی مکان) از چنین اسکنی جلوگیری کنید:

#vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$) (
بازگشت 444;
}

تعداد روش های موجود برای دسترسی به وب سرور را محدود کنید

برخی از ربات ها استفاده می کنند روش های مختلفسرور را برای تعیین نوع و/یا نفوذ آن فراخوانی می‌کند، با این حال RFC 2616 به وضوح بیان می‌کند که برای پیاده‌سازی همه آنها نیازی به وب سرور نیست و روش‌های پشتیبانی‌نشده ممکن است به سادگی مدیریت نشوند. امروزه فقط روش‌های GET (درخواست سند)، HEAD (درخواست هدر سرور) و POST (درخواست سند) در حال استفاده هستند، بنابراین سایر روش‌ها را می‌توان با قرار دادن خطوط زیر در بخش سرور فایل پیکربندی، غیرفعال کرد:

#vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$) (
بازگشت 444;
}

ارسال ربات ها

راه دیگری برای مسدود کردن ربات ها، اسکنرها و دیگر ارواح شیطانی بر اساس تعیین نوع مشتری (کاربر-عامل) است. این خیلی مؤثر نیست، زیرا بیشتر ربات ها تحت مرورگرهای کاملاً قانونی کار می کنند، اما در برخی موارد مفید باقی می ماند:

#vi /etc/nginx/nginx.conf

# مسدود کردن مدیران دانلود
اگر ($http_user_agent ~* LWP::Simple|BBBike|wget) (
بازگشت 403;
}
# برخی از انواع ربات ها را مسدود کنید
if ($http_user_agent ~* msnbot|scrapbot) (
بازگشت 403;
}

مسدود کردن هرزنامه ارجاع دهنده

اگر سایت شما گزارش‌های وب را به صورت عمومی منتشر می‌کند، می‌توانید به راحتی قربانی هرزنامه‌های Referrer شوید (زمانی که ربات‌های هرزنامه با سرور شما تماس می‌گیرند و آدرس سایت تبلیغ‌شده را در هدر ارجاع‌دهنده مشخص می‌کنند). این نوع هرزنامه ها به راحتی می توانند رتبه بندی سئوی وب سایت را خراب کنند، بنابراین باید بدون شکست آن را مسدود کرد. یکی از راه های انجام این کار این است که رایج ترین کلمات موجود در آدرس سایت های تبلیغاتی را در لیست سیاه قرار دهید.

#vi /etc/nginx/nginx.conf

بخش # سرور
اگر ($http_referer ~* (عزیزان | برای فروش | دختر | جواهرات | عشق | برهنه | ارگانیک | پوکر | پورن | جنسیت | نوجوان))
{
بازگشت 403;
}

هات لینک را مسدود کنید

Hotlink درج یک تصویر (یا محتوای دیگر) از یک سایت دیگر در یک صفحه است. این اساساً دزدی است، زیرا تصویری که ساعت‌ها از وقت آزاد خود را بر روی آن تلف کرده‌اید، نه تنها آزادانه توسط دیگران به اشتراک گذاشته می‌شود، بلکه بدون اینکه بازدیدکننده‌ای را به سمت آن بیاورد، روی سرور وب شما بارگذاری می‌کند. برای مبارزه با هات لینک ها، کافی است مطمئن شوید که تصاویر تنها در صورتی در اختیار مشتری قرار می گیرند که در حال حاضر در سایت آنها را درخواست کرده باشد (به عبارت دیگر، هدر درخواست ارجاع دهنده باید حاوی نام سایت شما باشد). خطوط زیر را به بخش سرور فایل پیکربندی nginx.conf اضافه کنید (host.com آدرس سایت شما است):

#vi /etc/nginx/nginx.conf

مکان /تصاویر/ (
valid_referers هیچ یک www.host.com host.com را مسدود نکرد.
اگر ($invalid_referer) (
بازگشت 403;
}
}

یا می توانید سرور را برای آپلود تنظیم کنید بنر ویژهبا پیام سرقت به جای تصویر درخواستی. برای انجام این کار، خط "return 403" را با خط زیر جایگزین کنید:

بازنویسی ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg آخرین

از دایرکتوری های مهم در برابر غریبه ها محافظت کنید

مانند هر وب سرور دیگری، nginx به شما اجازه می دهد تا دسترسی به فهرست ها را بر اساس آدرس های IP و رمز عبور کنترل کنید. از این ویژگی می توان برای بستن قسمت های خاصی از سایت استفاده کرد چشم کنجکاو. به عنوان مثال، برای حذف یک URI از دنیای خارج:

#vi /etc/nginx/nginx.conf

مکان /آپلودها/ (
# اجازه دسترسی فقط به ماشین‌های موجود در شبکه محلی را بدهید
اجازه 192.168.1.0/24;
# بقیه را جارو کنید
انکار همه
}

اکنون فقط کاربران شبکه محلی به اسناد موجود در فهرست آپلودها دسترسی خواهند داشت. برای تنظیم رمز عبور، باید مراحل پیچیده تری را انجام دهید. ابتدا باید یک فایل رمز عبور خصوصی برای nginx ایجاد کنید و کاربران لازم را به آن اضافه کنید (به عنوان مثال، کاربر admin را اضافه می کنیم):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

#vi /etc/nginx/nginx.conf

مکان /admin/ (
auth_basic "محدود"؛
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

کاربران جدید را می توان با دستور زیر اضافه کرد:

# htpasswd -s /etc/nginx/.htpasswd/passwd user

از SSL استفاده کنید

اگر سایت شما با داده های کاربر خصوصی مانند اعداد کار می کند کارت های اعتباری، رمز عبور از سرویس های دیگر، یا دسترسی به سرویس دیگری را فراهم می کند اطلاعات مهم، که می تواند به یک لقمه خوشمزه برای اشخاص ثالث تبدیل شود، از رمزگذاری مراقبت کنید. Nginx با SSL به خوبی کار می کند و این ویژگی را نباید نادیده گرفت.

برای راه اندازی رمزگذاری SSL با استفاده از nginx، فقط چند مرحله ساده را دنبال کنید. ابتدا باید یک گواهی با ترتیب دستور زیر ایجاد کنید:

# سی دی /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

سپس گواهی را در فایل پیکربندی nginx شرح دهید:

#vi /etc/nginx/nginx.conf

سرور(
server_name host.com;
گوش کن 443;
ssl در
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

پس از آن، می توانید وب سرور را مجددا راه اندازی کنید:

# /etc/init.d/nginx بارگذاری مجدد

طبیعتاً بدون پشتیبانی خود وب سایت، این کار بیهوده است.

روش های دیگر

متغیرهای صحیح سیستم را تنظیم کنید

فایل /etc/sysctl.conf را باز کنید و خطوط زیر را در آن قرار دهید:

#vi /etc/sysctl.conf

# محافظت در برابر حملات اسمورف
net.ipv4.icmp_echo_ignore_broadcasts = 1
# محافظت در برابر پیام های بد ICMP
net.ipv4.icmp_ignore_bogus_error_responses = 1
# حفاظت در برابر سیل SYN
net.ipv4.tcp_synccookies=1
# مسیریابی منبع را غیرفعال کنید
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# حفاظت از جعل
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# ما روتر نیستیم
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
# ExecShield را فعال کنید
kernel.exec-shield=1
kernel.randomize_va_space = 1
# گستره پورت های موجود را گسترش دهید
net.ipv4.ip_local_port_range = 2000 65000
# حداکثر اندازه بافرهای TCP را افزایش دهید
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling=1

دایرکتوری ریشه وب سرور را روی یک پارتیشن اختصاصی قرار دهید

با قرار دادن دایرکتوری ریشه وب سرور بر روی یک پارتیشن اختصاصی و عدم امکان قرار دادن فایل های اجرایی و دستگاه بر روی آن، از بقیه سیستم در برابر هر کسی که می تواند به ریشه وب سرور دسترسی داشته باشد محافظت می کند. ورودی فایل /etc/fstab باید چیزی شبیه به این باشد:

پیش‌فرض /dev/sda5 /nginx ext4,nosuid,noexec,nodev 1 2

nginx را در محیط chroot/jail قرار دهید

هر سیستم مدرن *nix به شما امکان می دهد برنامه را در یک محیط اجرای ایزوله قفل کنید. در لینوکس، می توانید از فناوری های KVM، Xen، OpenVZ و VServer برای این کار استفاده کنید، در FreeBSD - Jail، در Solaris - Zones. اگر هیچ یک از این فناوری‌ها در دسترس نیستند، می‌توانید nginx را در یک chroot کلاسیک قرار دهید، که اگرچه بسیار شکننده‌تر است، اما بیشتر کراکرها را متوقف می‌کند.

قوانین SELinux را برای ایمن سازی nginx تنظیم کنید

جایگزین خوب محیط های ایزولهاعدام ها سیستم های تشخیص نفوذ و پیشگیری محلی مانند SELinux یا AppArmor هستند. آنها با پیکربندی مناسب می توانند از تلاش برای هک کردن وب سرور جلوگیری کنند. به‌طور پیش‌فرض، هیچکدام از آنها برای کار با nginx پیکربندی نشده‌اند، اما در داخل پروژه SELinuxNginx(http://sf.net/projects/selinuxnginx/) قوانینی برای SELinux ایجاد شده است که همه می توانند از آنها استفاده کنند. فقط برای دانلود و نصب باقی می ماند:

# tar -zxvf se-ngix_1_0_10.tar.gz
# سی دی se-ngix_1_0_10/nginx
#ساخت
# /usr/sbin/semodule -i nginx.pp

تنظیمات فایروال

معمولا nginx روی ماشین‌های اختصاصی آماده برای بار بالا نصب می‌شود، بنابراین اغلب تنها سرویس شبکه است که روی سرور اجرا می‌شود. برای ایمن سازی سرور، کافی است مجموعه بسیار کوچکی از قوانین ایجاد کنید که پورت های 80، 110 و 143 را باز می کند (مگر اینکه، البته، nginx باید به عنوان یک پروکسی IMAP / POP3 نیز کار کند) و هر چیز دیگری را از دنیای بیرون می بندد. .

تعداد اتصالات با فایروال را محدود کنید

برای یک وب سایت کمتر شلوغ، ایده خوبی است که تعداد تلاش برای اتصال در دقیقه از همان آدرس IP را محدود کنید. این می تواند از شما در برابر برخی از انواع حملات DoS و نیروی بی رحم محافظت کند. در لینوکس، این کار را می توان با استفاده از ماژول استاندارد وضعیت iptables/netfilter انجام داد:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m حالت -- حالت NEW -m اخیر --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m حالت --state NEW -m اخیر --به روز رسانی \
-- ثانیه 60 -- تعداد ضربه 15 -j DROP

قوانین محدودیت تعداد اتصالات را از یک IP در دقیقه به 15 کاهش می دهد. شما می توانید همین کار را با pf انجام دهید:

#vi /etc/pf.conf

webserver_ip="1.1.1.1"
جدول اصرار ورزیدن
مسدود کردن سریع از
انتقال $ext_if proto tcp به $webserver_ip \
پورت www flags S/SA وضعیت نگه دارید \
(max-src-conn 100, max-src-conn-rate 15/60, \
اضافه بار فلاش)

علاوه بر محدودیت تعداد اتصالات متوالی (15 در دقیقه)، این قانون یک محدودیت اضافی برای تعداد اتصالات همزمان معادل 100 تعیین می کند.

راه اندازی PHP

اگر از nginx در ارتباط با PHP استفاده می کنید، فراموش نکنید که آن را نیز تنظیم کنید. فایل پیکربندی /etc/php/php.ini سرور امن باید به این صورت باشد:

#vi /etc/php/php.ini

# عملکردهای خطرناک را غیرفعال کنید
disable_functions = phpinfo، سیستم، نامه، exec
# حداکثر زمان اجرای اسکریپت
max_execution_time = 30
# حداکثر زمانی که اسکریپت می تواند برای پردازش داده های درخواست صرف کند
max_input_time = 60
# حداکثر مقدار حافظه اختصاص داده شده به هر اسکریپت
محدودیت_حافظه = 8M
# حداکثر اندازه داده های ارسال شده به اسکریپت با استفاده از روش POST
post_max_size = 8M
# حداکثر اندازه فایل های آپلود شده
upload_max_filesize = 2M
# خطاهای اسکریپت PHP را به کاربران نشان ندهید
display_errors = خاموش
# حالت ایمن را فعال کنید
safe_mode = روشن
# حالت ایمن SQL را فعال کنید
sql.safe_mode = روشن
# اجازه دهید دستورات خارجی فقط در این دایرکتوری اجرا شوند
safe_mode_exec_dir = /path/to/protected/directory
# محافظت در برابر نشت اطلاعات در مورد PHP
expose_php = خاموش
# ورود به سیستم
log_errors = روشن
# جلوگیری از باز کردن فایل های راه دور
allow_url_fopen = خاموش

یافته ها

با اعمال توصیه های این مقاله، سرور وب بسیار ایمن تری خواهید داشت. اما به خاطر داشته باشید که همه تکنیک ها با پیکربندی شما مطابقت ندارند. به عنوان مثال، حفاظت brute-force بر اساس کاهش اندازه بافرهای اختصاص داده شده توسط nginx برای پردازش درخواست های مشتری می تواند منجر به کاهش عملکرد و در برخی موارد منجر به شکست در پردازش درخواست ها شود. محدود کردن تعداد اتصالات حتی به عملکرد یک وب سایت با بارگذاری متوسط ​​آسیب می رساند، اما اگر صفحه دارای جریان ترافیک کم باشد، مفید خواهد بود. همیشه بررسی کنید که تغییرات شما چگونه بر عملکرد و سلامت کلی صفحه وب تأثیر می گذارد.

درباره قهرمان روز

Nginx یکی از سریع ترین و محبوب ترین وب سرورها در جهان است. به گفته نت کرافت، از آن برای تقویت بیش از 12 میلیون وب سایت در سراسر جهان، از جمله ماستودون هایی مانند Rambler، Yandex، Begun، WordPress.com، Wrike، vkontakte.ru، megashara.com، Librusek و Taba.ru استفاده می شود. یک معماری هوشمند مبتنی بر مالتی پلکس کردن اتصال با استفاده از انتخاب، epoll (Linux)، kqueue (FreeBSD) و مکانیسم مدیریت حافظه مبتنی بر استخر (بافرهای کوچک از 1 تا 16 کیلوبایت) به nginx این امکان را می‌دهد که حتی در بارهای بسیار بالا هم افت نکند. تحمل بیش از 10000 اتصال همزمان (به اصطلاح مشکل C10K). در اصل توسط ایگور سیسویف برای Rambler نوشته شد و در سال 2004 تحت مجوز BSD مانند منتشر شد.

در تماس با

Nginx؟ هدف، ویژگی‌ها، گزینه‌های تنظیمات - اینها مواردی هستند که هر توسعه‌دهنده وب باید با آنها آشنا باشد تا پیشرفت‌های خود را آزمایش کند.

بیایید یک کلمه در مورد nginx بگوییم

این ابزار دارای یک فرآیند اصلی و چندین فرآیند کارگری است. اولین مورد با خواندن و بررسی پیکربندی سروکار دارد. همچنین تحت کنترل او مدیریت فرآیندهای کاری است. وظیفه دومی پردازش درخواست های دریافتی است. Nginx از مدلی استفاده می کند که بر اساس رویدادها است. مکانیسم های خاص سیستم عامل نیز برای دستیابی به توزیع کارآمد درخواست ها به طور مستقیم بین فرآیندهای کارگر استفاده می شود. شماره آنها همیشه در فایل پیکربندی نشان داده شده است. با توجه به تعداد هسته‌های پردازنده‌ای که می‌توانید با آن‌ها کار کنید، مقدار می‌تواند ثابت یا به‌طور خودکار تنظیم شود. در nginx، سیستم و ماژول ها با استفاده از یک فایل پیکربندی پیکربندی می شوند. بنابراین، اگر نیاز به تغییر چیزی دارید، باید به دنبال آن باشید. معمولاً در دستورالعمل /etc/nginx قرار دارد (اما مسیر ممکن است در سیستم‌های دیگر تغییر کند) و پسوند .conf دارد.

راه اندازی، راه اندازی مجدد و لاگ

برای انجام این کار، باید فایل اجرایی را فعال کنید. راه اندازی سرور nginx تنها زمانی امکان پذیر است که در حال اجرا باشد. کنترل با فراخوانی فایل اجرایی با گزینه -s انجام می شود. برای این کار از ورودی زیر استفاده کنید:

سیگنال nginx -s

AT این موردمی توانید چنین دستوراتی را جایگزین کنید (باید از طرف کاربری باشد که ابزار را راه اندازی کرده است):

1. متوقف کردن. استفاده شده برای تکمیل سریعکار
2. بارگذاری مجدد دستور برای بارگیری مجدد فایل پیکربندی مورد نیاز است. نکته این است که هیچ تغییری در حین اجرای فایل اعمال نخواهد شد. و برای اعمال آنها، راه اندازی مجدد مورد نیاز است. به محض دریافت این سیگنال، فرآیند اصلی شروع به بررسی نحو صحیح فایل پیکربندی می کند و سعی می کند دستورالعمل ها را در آنجا اعمال کند. در صورت عدم موفقیت، تغییرات را برمی گرداند و با تنظیمات قبلی کار می کند. اگر همه چیز به خوبی پیش رفت، فرآیندهای کارگری جدید راه اندازی می شوند و موارد قدیمی برای تکمیل درخواست ارسال می شوند.
3. ترک برای خاموش شدن صاف استفاده می شود. اگر لازم باشد منتظر بمانید تا درخواست‌های فعلی به پایان برسد، استفاده می‌شود.
4. دوباره باز کنید. فایل های گزارش را ببندید و باز کنید.

با استفاده از خدمات شهری

فرآیندها را نیز می توان با استفاده از ابزارهای یونیکس پیکربندی کرد (ابزار kill به عنوان مثال در نظر گرفته می شود). آنها معمولاً از مکانیسم ارسال سیگنال به فرآیند به طور مستقیم با داده ها استفاده می کنند. آنها با یک شناسه مرتبط هستند. این داده ها در فایل nginx.pid ذخیره می شوند. فرض کنید به فرآیند شماره 134 علاقه مندیم. سپس برای تکمیل بدون مشکل، باید اطلاعات زیر را ارسال کنیم:

kill -s QUIT 1628

فرض کنید می خواهیم فهرستی از همه را ببینیم فایل های در حال اجرا. ما برای این کار از ابزار ps استفاده می کنیم. دستور به شکل زیر خواهد بود:

ps-ax | grep nginx

یعنی همانطور که می بینید هنگام استفاده از ابزارهای اضافی نشان داده می شود که برنامه آن است که در حال انجام است. حالا بیایید روی نحوه انجام تنظیمات nginx تمرکز کنیم.

ساختار فایل پیکربندی

نصب و پیکربندی nginx شامل کار با ماژول ها است. آنها با استفاده از دستورالعمل هایی که در فایل پیکربندی مشخص شده اند پیکربندی می شوند. آنها ساده و مسدود هستند. دستورات نوع اول شامل نام و پارامترهایی است که با فاصله از هم جدا شده اند و انتهای آنها با نقطه ویرگول - (;) نشان داده می شود. بلوک ساختار مشابهی دارد. اما در این بخشنامه به جای پایان، مجموعه قرار می گیرد دستورالعمل های اضافی، که در بریس های مجعد قرار می گیرند (( دستورالعمل )). اگر امکان قرار دادن نام ها و پارامترهای سایر فرآیندها در آنها وجود داشته باشد، چنین ساختارهایی قبلاً زمینه نامیده می شوند. به عنوان مثال می توان به http، موقعیت مکانی و سرور اشاره کرد.

ارائه محتوای استاتیک

این یکی از مهمترین وظایفی است که پیکربندی nginx با آن روبرو است. توزیع محتوای آماری به معنای تصاویر و صفحات HTML (نه پویا) است. بیایید بگوییم که برای راه اندازی یک خوشه nix nginx به یک کار یک بار مصرف نیاز داریم. آیا انجام این کار سخت است؟ نه، و بیایید به یک مثال نگاه کنیم. قبل از اقدام به آن، لازم است شرایط مشکل را به تفصیل بیان کنید. بنابراین، بسته به درخواست ها، فایل ها از دایرکتوری های محلی مختلف می آیند. بنابراین، در /data/www ما اسناد HTML داریم. و دایرکتوری /data/images حاوی تصاویر است. پیکربندی بهینه nginx در این مورد نیاز به ویرایش فایل پیکربندی دارد که در آن باید بلوک سرور را در http پیکربندی کنید. از دو مکان نیز برای پشتیبانی استفاده خواهد شد.

پیاده سازی: سرور

بنابراین، برای شروع، باید خود دایرکتوری ها را ایجاد کنیم و فایل هایی با پسوندهای لازم را در آنها قرار دهیم (شما باید محتوا را به html اضافه کنید). سپس فایل پیکربندی را باز می کنیم. به‌طور پیش‌فرض، از قبل دارای چندین بلوک سرور است که اکثراً نظر داده می‌شوند. برای بهترین نتایج، این فرآیند باید برای تمام اجزای پیش فرض تکرار شود. سپس یک بلوک سرور جدید با کد زیر اضافه می کنیم:

فایل پیکربندی می تواند با چندین بلوک از این دست کار کند. اما آنها باید در نام و پورت های خود که از طریق آنها داده ها دریافت می شود متفاوت باشند.

اجرا: مکان

تعریف شده در داخل سرور:

وجود علامت "/" برای مقایسه داده های دریافتی و دیدن اینکه آیا چنین آدرسی از درخواست پردازش شده در اینجا وجود دارد ضروری است. اگر مشکلی وجود ندارد، مسیر /data/www را به را مشخص کنید فایل مورد نیاز، که در این است سیستم محلی. اگر یک تطابق با چندین بلوک وجود داشته باشد، یکی با طولانی ترین پیشوند انتخاب می شود. در مثال بالا، طول آن برابر با یک است، یعنی فقط در صورت عدم وجود "رقیب" از آن استفاده می شود. حالا بیایید آن را بهبود دهیم:

مکان /تصاویر/ (

همانطور که می توانید بگویید، ما به دنبال تصاویر هستیم. و اکنون بیایید تمام پیشرفت‌هایی را که قبلاً بودند ترکیب کنیم، و پیکربندی در حال حاضر به این صورت است:

مکان /تصاویر/ (

این یک نسخه کارآمد است که اتفاقاً استاندارد است. این سرور به راحتی قابل دسترسی است کامپیوتر محلیاگر به آدرس http://localhost/ بروید. این همه چگونه کار خواهد کرد؟

مثال چگونه کار می کند

بنابراین، هنگامی که درخواست‌هایی وارد می‌شوند که با /images شروع می‌شوند، سرور فایل‌هایی را از دایرکتوری مربوطه برای کاربر ارسال می‌کند. اگر وجود نداشته باشد، اطلاعاتی که نشان دهنده خطای 404 است منتقل می شود. اگر nginx روی رایانه محلی پیکربندی شده باشد، پس از درخواست http://localhost/images/example.png، فایلی را دریافت خواهیم کرد که مکان آن /data/ است. images/example.png. هنگام تعیین یک کاراکتر "/"، جستجو در فهرست /data/www انجام می شود. اما ما فقط تنظیمات را تغییر دادیم. برای اینکه شروع به کار کند، باید راه اندازی مجدد شود. برای این کار از دستور nginx -s reload استفاده کنید. در صورتی که کار معمولیامکان پذیر نیست، سپس در فایل های error.log و access.log واقع در دستورالعمل /usr/local/nginx/logs، می توانید علت خرابی را جستجو کنید.

ایجاد یک پروکسی سرور ساده

می توان در مورد nginx گفت - پیکربندی این شی یکی از کاربردهای رایج است (و اتفاقاً بسیار آسان). از اصل سروری استفاده می کند که درخواستی را دریافت می کند و سپس آنها را به سایت های ضروری هدایت می کند. پس از آن، پاسخی از آنها انتظار می رود که آنها را به سمت تعیین کننده هدایت می کند. بنابراین بیایید به مثالی از ایجاد یک نقطه پایه نگاه کنیم. درخواست های کاربر را رسیدگی می کند و تصاویری را از دایرکتوری محلی به آنها ارائه می دهد. بنابراین، سرور دیگری را با محتوای زیر به بلوک http اضافه کنید:

و حالا بیایید آن را برای شما رمزگشایی کنیم: یک سرور ساده در حال ایجاد است. گوش می دهد گوش را مشخص نکنید، سرور در 80 اجرا می شود. تمام پرس و جوها در منطقه محلی نمایش داده خواهند شد. سیستم فایل، که به دایرکتوری /data/up1 هدایت می شوند (البته قبل از این باید ایجاد شود). برای اینکه بتوانید آن را بررسی کنید، باید فایل index.html را در آنجا قرار دهید. با قرار دادن دستور root در زمینه سرور، می توانیم تحت هر شرایطی از مکان استفاده کنیم (زیرا محدودیت های دسترسی حذف می شوند). اکنون ما روی ایجاد یک سرور پروکسی کار می کنیم. برای عملکرد آن، ما به دستورالعمل proxy_pass نیاز داریم، که پروتکل، نام و پورت شی به عنوان پارامتر مشخص می شود (زمانی که اتصال محلیشبیه http://localhost:8080 خواهد بود. نتیجه زیر را دریافت خواهید کرد:

proxy_pass http://localhost:8080;

مکان /تصاویر/ (

اگر به کد نگاه کنید و آن را تجزیه و تحلیل کنید، ممکن است متوجه شوید که بلوک مکان دوم تغییر کرده است. بنابراین، در این مورد، می تواند با پسوندهای تصویر معمولی کار کند. به روشی کمی متفاوت، می توان آن را به صورت زیر نمایش داد:

مکان ~ \.(gif|jpg|png)$ (

root /data/images;

پیکربندی سرور پروکسی حاصل به صورت زیر است:

proxy_pass http://localhost:8080/;

مکان ~ \.(gif|jpg|png)$ (

root /data/images;

درخواست هایی را که پسوندهای مشخص شده در انتها دارند را فیلتر کرده و برای شخصی که فایل ها را درخواست کرده است ارسال می کند. فراموش نکنید که اگر می خواهید فایل پیکربندی را بررسی کنید، باید آن را دوباره بارگذاری کنید. و باور کنید، این ساده ترین راه اندازی nginx است. اگر فایل پیکربندی سرور Vkontakte یا یک شرکت بزرگ دیگر را باز کنید، کد آنها بیشتر از کلمات در این مقاله خواهد بود.

یکی از محبوب ترین وب سرورها

Nginx به دلیل عملکردی که دارد در بین کاربران وب و سرورهای پروکسی بسیار محبوب است. سرور مزایای زیادی دارد، اما راه اندازی آن برای یک مبتدی دشوار خواهد بود. ما می خواهیم به شما در درک فایل های پیکربندی، نحو و تنظیم پارامترهای اساسی Nginx کمک کنیم.

سلسله مراتب دایرکتوری

تمام فایل های پیکربندی سرور در پوشه /etc/nginx قرار دارند. علاوه بر این، چندین پوشه دیگر و همچنین فایل های پیکربندی مدولار در داخل دایرکتوری قرار دارند.

سی دی /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

اگر از آپاچی استفاده کرده اید، باید با دایرکتوری های سایت های فعال و سایت های در دسترس آشنا باشید. آنها پیکربندی سایت ها را تعیین می کنند. فایل های تولید شده در آخرین دایرکتوری ذخیره می شوند. پوشه سایت‌های فعال برای ذخیره تنظیمات فقط برای صفحات فعال مورد نیاز است. برای پیوند دادن آنها، به یک پیوند نمادین بین پوشه ها نیاز دارید. تنظیمات را می توان در پوشه conf.d نیز ذخیره کرد. در همان زمان در هنگام راه اندازی Nginx، هر فایل با پسوند conf. در یک فایل جدید خوانده می شود. هنگام نوشتن فایل های پیکربندی، کد را بدون خطا تایپ کنید و از نحو پیروی کنید. همه فایل های دیگر در /etc/nginx قرار دارند. پیکربندی حاوی اطلاعاتی در مورد فرآیندهای خاص و همچنین اجزای اضافی است.

فایل پیکربندی اصلی برای Nginx nginx.conf است.

تمام فایل‌های پیکربندی را می‌خواند، آنها را به یکی از درخواست‌شده در راه‌اندازی سرور متصل می‌کند. باز کردن فایل با:

sudo nano /etc/nginx/nginx.conf

خطوط زیر روی صفحه ظاهر می شود:

کاربر www-data;
worker_processes 4;
pid /var/run/nginx.pid;
مناسبت ها(
worker_connections 768;
# چند_پذیرش در;
}
http(
. . .

اولی است اطلاعات کلیدر مورد Nginx عبارت user www-data کاربری را مشخص می کند که سرور را اجرا می کند. دستورالعمل pid نشان می دهد که فرآیندهای PID در کجا واقع شده اند استفاده داخلی. خط worker_processes نشان می دهد که Nginx چند پردازش را می تواند همزمان اجرا کند. علاوه بر این، گزارش ها را می توان در اینجا مشخص کرد (به عنوان مثال، گزارش خطا توسط دستورالعمل error_log تعیین می شود). در زیر بخش رویدادها آمده است. برای مدیریت اتصالات سرور مورد نیاز است. بعد از آن بلوک http است.

ساختار فایل پیکربندی Nginx

درک ساختار قالب بندی فایل به شما در درک بهتر پیکربندی وب سرور کمک می کند. تقسیم می شود بلوک های ساختمان. جزئیات پیکربندی بلوک http توسط بلوک های خصوصی لایه بندی شده است. آنها خواص را از والدین به ارث می برند، یعنی. جایی که در آن قرار دارند. این بلوک بیشتر تنظیمات سرور را ذخیره می کند. آنها به بلوک های سرور تقسیم می شوند که مکان ها در داخل آنها قرار دارند.

وقتی سرور Nginx را پیکربندی می‌کنید، به خاطر داشته باشید که هر چه بلوک پیکربندی پایین‌تر باشد، عناصر کمتری خصوصیات را به ارث خواهند برد و بالعکس. فایل حاوی تعداد زیادی ازگزینه هایی که نحوه عملکرد سرور را تغییر می دهند. برای مثال می‌توانید فشرده‌سازی فایل‌های ارسال شده به مشتری را تنظیم کنید. برای انجام این کار، پارامترها را وارد کنید:

gzip روشن
gzip_disable "msie6";

به خاطر داشته باشید که همان پارامتر می تواند باشد معانی مختلفکه در بلوک های مختلف. ابتدا آن را در بالا تنظیم کنید، سپس پارامتر را دوباره تعریف کنید سطح درست. اگر آخرین اقدام انجام نشود، برنامه مقادیر را به طور خودکار تنظیم می کند.

آخرین خطوط فایل nginx.conf عبارتند از:

شامل /etc/nginx/conf.d/*.conf.
شامل /etc/nginx/sites-enabled/* باشد.

آنها نشان می دهند که مکان و بلوک های سرور خارج از این فایل ذخیره می شوند. آنها تنظیماتی را برای آدرس های url و فایل های خاص تعریف می کنند. چنین ساختاری برای حفظ ساختار پیکربندی مدولار ضروری است. در داخل آن امکان ایجاد دایرکتوری ها، فایل های جدید برای سایت های مختلف وجود خواهد داشت. بعلاوه، فایل های مشابهمی توانید گروه بندی کنید پس از بررسی، می توانید فایل nginx.conf را ببندید.

بلوک های مجازی

آنها مشابه هاست های مجازی در آپاچی هستند. بلوک های بخش سرور شامل ویژگی های سایت های فردی است که در سرور قرار دارند. در پوشه sites-available فایل بلوک سرور را پیدا خواهید کرد که پیش فرض است. در داخل آن، می توانید داده های لازم را که ممکن است هنگام نگهداری سایت ها مورد نیاز باشد، بیابید.

سایت های سی دی در دسترس است
sudo nano پیش فرض
سرور(
root /usr/share/nginx/www;
index index.html index.htm;
server_namelocalhost;
محل / (
try_files $uri $uri/ /index.html;
}
مکان /doc/ (
نام مستعار /usr/share/doc/;
فهرست خودکار روشن
اجازه 127.0.0.1;
انکار همه
}
}

در مثال بالا، نظرات عمدا حذف شدند. این برای سهولت درک انجام شد. در داخل بلوک های سرور تنظیماتی وجود دارد که در پرانتزهای فرفری محصور شده اند:

این بلوک با استفاده از دستورالعمل include در انتهای http مشخص شده در فایل nginx.conf قرار می گیرد. دستورالعمل root فهرستی را که محتوای سایت در آن قرار خواهد گرفت را مشخص می کند. در آن برنامه به دنبال فایل هایی می گردد که کاربر درخواست می کند. مسیر پیش فرض /usr/share/nginx/www است. Nginx خطوط یا دستورات را با نقطه ویرگول از یکدیگر جدا می کند. اگر علامت نقطه گذاری گذاشته نشود، چندین خط یک خط خوانده می شود. برای نوشتن قوانینی که به عنوان شاخص استفاده می شود، از دستورالعمل شاخص استفاده کنید. سرور آنها را به ترتیب فهرست شده بررسی می کند. اگر هیچ یک از صفحات موجود توسط کاربر درخواست نشده باشد، index.html برگردانده خواهد شد. اگر آنجا نباشد، سرور به دنبال index.htm می‌گردد.

قانون server_name

این شامل لیستی از نام های دامنه است که بلوک سرور باید پردازش کند. می توانید هر تعداد از آنها را با فاصله از هم جدا کنید. اگر * را در انتهای یا ابتدای دامنه قرار دهید، می توانید نامی را با ماسک تعیین کنید. ستاره با بخشی از نام مطابقت دارد. اگر *.com.ua را بنویسید، تمام آدرس های مشخص شده است منطقه دامنه. اگر آدرس با توضیحات چندین دستورالعمل مطابقت داشته باشد، به آدرسی که کاملاً مطابقت دارد پاسخ می دهد. اگر مطابقت وجود نداشته باشد، پاسخ طولانی ترین نامی است که ماسک دارد. در غیر این صورت، تطبیق عبارات منظم انجام خواهد شد. نام سرورهایی که از عبارات منظم استفاده می کنند با یک tilde (~) شروع می شوند.

بلوک های مکان

در خط بعدی یک بلوک مکان خواهیم داشت. برای تعیین روش پردازش مورد نیاز است درخواست های خاص. اگر منابع با هیچ بلوک مکان دیگری مطابقت نداشته باشند، دستورالعمل های داخل پرانتز برای آنها اعمال می شود. این بلوک ها ممکن است شامل مسیری مانند /doc/ باشند. برای ایجاد تطابق کامل بین uri و مکان، از علامت = استفاده می شود. با استفاده از tilde، می توانید عبارات منظم را مطابقت دهید. همچنین می توانید با قرار دادن ~ حساسیت حروف کوچک و بزرگ را تنظیم کنید. اگر یک ستاره اضافه کنید، مورد هیچ نقشی ندارد.

به خاطر داشته باشید: زمانی که درخواست به طور کامل با بلوک مکان مطابقت داشته باشد، استفاده می شود و جستجو متوقف می شود. هنگامی که تطابق ناقص است، URI با پارامترهای دستورالعمل های مکان مطابقت داده می شود. یک بلوک با ترکیب ^~ استفاده می شود که با URI برای انتخاب بلوک مطابقت دارد. اگر یک این گزینهاستفاده نکنید، سرور بهترین تطابق را انتخاب می کند و همچنین با استفاده از عبارات منظم جستجو می کند. این برای انتخاب یکی از قالب های مناسب ضروری است. در صورت یافتن عبارت مناسب از آن استفاده می شود. در غیر این صورت، مطابق URI قبلی اعمال خواهد شد. با این حال، به خاطر داشته باشید که Nginx مسابقات کامل را ترجیح می دهد. اگر آنها وجود نداشته باشند، جستجو برای عبارات منظم و سپس توسط URI آغاز می شود. برابری جستجو با ترکیبی از کاراکترهای ^~ مشخص می شود.

قانون try_files

این خیلی ابزار مفید، قادر به بررسی وجود پرونده ها به ترتیب معین است. اولین معیارهای تطبیق را برای پردازش درخواست اعمال می کند. شما می توانید استفاده کنید گزینه های اضافیبرای تعیین اینکه سرور چگونه درخواست ها را ارائه می دهد. در پیکربندی، این خط به طور پیش فرض وجود دارد:

try_files $uri $uri/ /index.html;

منظور او چیست؟ اگر درخواستی وارد شود که توسط یک بلوک مکان ارائه می شود، سرور ابتدا سعی می کند uri را به عنوان یک فایل در نظر بگیرد. این توسط متغیر $uri ارائه می شود. هنگامی که هیچ منطبقی برای آن وجود ندارد، uri به عنوان یک فهرست تلقی می شود. می توانید وجود آن را با اضافه کردن یک اسلش در پایان بررسی کنید: $uri/. شرایطی وجود دارد که نه فایل و نه دایرکتوری پیدا نمی شود. در این صورت، فایل پیش فرض بارگذاری می شود - index.html. قانون try_files اعمال می شود آخرین پارامتربه عنوان یک بازگشت از همین رو فایل داده شدهباید در سیستم باشد با این حال، اگر به هیچ وجه مطابقت پیدا نشد، Nginx یک صفحه خطا را برمی‌گرداند. برای تنظیم آن، = و کد خطا را بنویسید:

گزینه های اضافی

اگر قانون مستعار را اعمال کنید، می‌توانید برای مثال، صفحات بلوک مکان را خارج از فهرست اصلی ارائه دهید. زمانی که فایل‌هایی از doc مورد نیاز باشد، از /usr/share/doc/ درخواست می‌شوند. علاوه بر این، فهرست خودکار در قانون فهرستی از دایرکتوری های سرور را برای دستورالعمل مکان مشخص شده ایجاد می کند. اگر خطوط رد و مجاز را بنویسید، می توانید دسترسی به دایرکتوری ها را تغییر دهید.

به عنوان یک نتیجه، شایان ذکر است که Nginx یک ابزار چند منظوره بسیار قدرتمند است. اما برای درک درست اصل کار آن، زمان و تلاش لازم است. اگر نحوه عملکرد پیکربندی ها را بدانید، می توانید به طور کامل از تمام ویژگی های برنامه لذت ببرید.

دیگر). نسخه فعلی 0.6.x، از نظر قابلیت اطمینان پایدار در نظر گرفته می شود، در حالی که انتشار از شاخه 0.7 ناپایدار در نظر گرفته می شود. در عین حال، مهم است که توجه داشته باشید که عملکرد برخی از ماژول ها تغییر خواهد کرد، در نتیجه ممکن است دستورالعمل ها نیز تغییر کنند، بنابراین سازگاری با عقبدر nginx قبل از نسخه 1.0.0 تضمین نمی شود.

چرا nginx اینقدر خوب است و چرا مدیران پروژه های با بارگذاری بالا آن را بسیار دوست دارند؟ چرا فقط از آپاچی استفاده نمی کنید؟

چرا آپاچی بد است؟

ابتدا باید نحوه عملکرد سرورهای شبکه را به طور کلی توضیح دهیم. کسانی که با برنامه نویسی شبکه آشنا هستند می دانند که اساساً سه مدل از عملکرد سرور وجود دارد:

1. متوالی. سرور یک سوکت گوش دادن را باز می کند و منتظر می ماند تا یک اتصال ظاهر شود (در حالی که منتظر است، در حالت مسدود است). هنگامی که یک اتصال می رسد، سرور آن را در همان زمینه مدیریت می کند، اتصال را می بندد و دوباره منتظر اتصال می ماند. بدیهی است که این به دور از بهترین راه است، به خصوص زمانی که کار با مشتری زمان زیادی می برد و ارتباطات زیادی وجود دارد. علاوه بر این، مدل سریال معایب بسیار بیشتری دارد (مثلاً عدم امکان استفاده از چندین پردازنده) و در شرایط واقعی عملاً از آن استفاده نمی شود.
2. چند فرآیندی (چند رشته ای). سرور یک سوکت گوش دادن را باز می کند. هنگامی که یک اتصال می رسد، آن را می پذیرد، پس از آن ایجاد می کند (یا از مخزن از پیش ایجاد شده می گیرد) روند جدیدیا نخی که می تواند به طور خودسرانه با اتصال کار کند و در پایان کار خاتمه یابد یا به استخر برگردد. در همین حال، موضوع اصلی آماده پذیرش یک اتصال جدید است. این محبوب ترین مدل است زیرا پیاده سازی آن نسبتاً آسان است، امکان انجام محاسبات پیچیده و طولانی را بر اساس هر مشتری فراهم می کند و از همه استفاده می کند. پردازنده های موجود. نمونه ای از کاربرد آن است وب سرور آپاچی. با این حال، این رویکرد جنبه‌های منفی خود را دارد: تعداد زیادی از اتصالات همزمان، رشته‌ها (یا بدتر از آن، فرآیندها) زیادی ایجاد می‌کنند، و سیستم عامل منابع زیادی را برای سوئیچ‌های زمینه صرف می‌کند. به خصوص زمانی که مشتریان در پذیرش محتوا بسیار کند هستند بسیار بد است. در نهایت با صدها رشته یا فرآیند مواجه می‌شوید که فقط مشغول ارسال داده‌ها به کلاینت‌های کند می‌شوند، که بار اضافی روی زمان‌بندی سیستم‌عامل ایجاد می‌کند، تعداد وقفه‌ها را افزایش می‌دهد و حافظه زیادی را مصرف می‌کند.
3. سوکت های غیر مسدود کننده / دستگاه حالت. سرور در یک رشته کار می کند، اما از سوکت های غیر مسدود کننده و مکانیزم نظرسنجی استفاده می کند. آن ها سرور در هر تکرار حلقه بی پایاناز همه سوکت ها سوکتی را انتخاب می کند که با استفاده از تماس انتخاب () آماده دریافت/ارسال داده است. پس از انتخاب سوکت، سرور داده‌ها را به آن ارسال می‌کند یا آنها را می‌خواند، اما منتظر تأیید نمی‌ماند، بلکه به حالت اولیه می‌رود و منتظر یک رویداد در سوکت دیگری می‌شود یا رویداد بعدی را پردازش می‌کند که در آن رویداد رخ داده است. پردازش قبلی این مدلاستفاده بسیار کارآمد از CPU و حافظه، اما اجرای آن بسیار پیچیده است. علاوه بر این، در این مدل، پردازش یک رویداد در یک سوکت باید بسیار سریع باشد - در غیر این صورت، رویدادهای زیادی در صف جمع می‌شوند و در نهایت سرریز می‌شوند. این مدلی است که nginx روی آن کار می کند. علاوه بر این، به شما امکان می دهد چندین فرآیند کارگری (به اصطلاح کارگران) را اجرا کنید. می تواند از چندین پردازنده استفاده کند.

بنابراین، وضعیت زیر را تصور کنید: 200 مشتری به یک سرور HTTP با یک کانال 1 گیگابیت بر ثانیه با یک کانال 256 کیلوبیت بر ثانیه متصل می شوند:

در مورد آپاچی چه اتفاقی می افتد؟ 200 رشته/فرآیند ایجاد می‌شود که نسبتاً سریع محتوا تولید می‌کنند (این می‌تواند یکی باشد صفحات پویا، و همچنین فایل های استاتیک که از دیسک خوانده می شوند)، اما به آرامی آن را به مشتریان ارائه می کنند. سیستم عاملباید با دسته‌ای از رشته‌ها و مسدود کردن ورودی/خروجی سر و کار داشته باشد.

Nginx در چنین شرایطی یک مرتبه کمتر از سیستم عامل و منابع حافظه برای هر اتصال هزینه می کند. با این حال، این محدودیت مدل شبکه nginx را نشان می دهد: نمی تواند تولید کند محتوای پویادرون خودت، چون این باعث ایجاد قفل در داخل nginx می شود. طبیعتاً یک راه حل وجود دارد: nginx می تواند چنین درخواست هایی را (برای تولید محتوا) به هر وب سرور دیگری (مثلاً همان آپاچی) یا یک سرور FastCGI پروکسی کند.

مکانیسم عملکرد بسته نرم افزاری nginx را به عنوان سرور "اصلی" و آپاچی را به عنوان سروری برای تولید محتوای پویا در نظر بگیرید:

Nginx اتصال یک کلاینت را می پذیرد و کل درخواست را از آن می خواند. در اینجا لازم به ذکر است که تا زمانی که nginx کل درخواست را نخواند، آن را به "پردازش" نمی دهد. به همین دلیل، تقریباً همه نشانگرهای پیشرفت آپلود فایل معمولاً "شکست می‌خورند" - با این حال، می‌توان آنها را با استفاده از ماژول upload_progress شخص ثالث برطرف کرد (این به اصلاح برنامه نیاز دارد).

پس از اینکه nginx کل پاسخ را خواند، یک اتصال به آپاچی باز می کند. دومی کار خود را انجام می دهد (محتوای پویا تولید می کند)، پس از آن پاسخ خود را به nginx می دهد، که آن را در حافظه بافر می کند یا فایل موقت. در همین حال، آپاچی منابع را آزاد می کند. علاوه بر این، nginx به آرامی محتوا را در اختیار مشتری قرار می دهد، در حالی که نسبت به آپاچی، منابع بزرگتری را صرف می کند.

این طرح frontend + backend (frontend + backend) نامیده می شود و اغلب استفاده می شود.

نصب و راه اندازی

زیرا nginx تازه شروع کرده است، مشکلاتی در مورد بسته های باینری وجود دارد، بنابراین آماده باشید تا خودتان آن را کامپایل کنید. معمولاً هیچ مشکلی در این مورد وجود ندارد، فقط باید خروجی دستور ./configure --help را با دقت بخوانید و گزینه های کامپایل مورد نیاز خود را انتخاب کنید، به عنوان مثال:

./پیکربندی\
--prefix=/opt/nginx-0.6.x \ # پیشوند نصب
--conf-path=/etc/nginx/nginx.conf \ # محل فایل پیکربندی
--pid-path=/var/run/nginx.pid \ # ... و pid-file
--user=nginx \ # نام کاربری که nginx تحت آن اجرا می شود
--with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module \ # لیست مورد نیاز
—without-http_ssi_module —without-http_userid_module —without-http_autoindex_module —without-http_geo_module —without-http_referer_module —without-http_memcached_module —without-http_nedule_unimitary_module …

پس از پیکربندی، باید استاندارد make && make install را اجرا کنید، پس از آن می توانید از nginx استفاده کنید.

از طرف دیگر، در جنتو می‌توانید از یک ebuild از درخت پورت‌های استاندارد استفاده کنید. در RHEL/CentOS از طریق مخزن epel (حاوی nginx 0.6.x) یا srpm برای نسخه 0.7، که می توانید از اینجا دانلود کنید: http://blogs.mail.ru/community/nginx ; در دبیان، می توانید از بسته nginx از شاخه ناپایدار استفاده کنید.

فایل پیکربندی

فایل پیکربندی nginx بسیار مفید و شهودی است. معمولاً nginx.conf نامیده می شود و در صورتی که مکان در حین کامپایل بازنویسی نشده باشد در $prefix/conf/ قرار می گیرد. من دوست دارم آن را در /etc/nginx/ قرار دهم، و توسعه دهندگان تمام بسته های ذکر شده در بالا نیز همین کار را می کنند.

ساختار فایل پیکربندی به صورت زیر است:

کاربر nginx; # نام کاربری که حقوق nginx با آن اجرا می شود
worker_processes 1; # تعداد فرآیندهای کارگری
مناسبت ها(
<…># این بلوک مکانیسم نظرسنجی مورد استفاده (به زیر مراجعه کنید) و حداکثر تعداد اتصالات ممکن را مشخص می کند
}

http(
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# توضیحات سرورها (این همان چیزی است که VirtualHost در آپاچی نامیده می شود)
سرور(
# آدرس و نام سرور
گوش کن *:80;
نام سرور aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# و به این ترتیب می توانید مکان را تعریف کنید، که برای آن می توانید تقریباً همه دستورالعمل های مشخص شده در سطوح جهانی تر را دوباره تعریف کنید.
مکان /abcd/ (
<директивы>;
}
# متناوبا، می‌توانید مکانی را با یک عبارت منظم انجام دهید، مانند:
مکان ~ \.php$ (
<директивы>;
}
}

# سرور دیگر
سرور(
گوش کن *:80;
نام سرور ccc.bbb;

<директивы>
}
}

توجه داشته باشید که هر دستورالعمل باید با نقطه ویرگول خاتمه یابد.
پروکسی معکوس و FastCGI

بنابراین، در بالا به مزایای طرح frontend + backend نگاه کردیم، نصب، ساختار و نحو فایل پیکربندی را متوجه شدیم، اکنون بیایید به نحوه اجرای پروکسی معکوس در nginx نگاه کنیم.

و خیلی ساده! به عنوان مثال مانند این:

محل / (
proxy_pass http://1.2.3.4:8080;
}

در این مثال، تمام درخواست‌هایی که به مکان / می‌رسند به پورت 8080 سرور 1.2.3.4 پراکسی می‌شوند. می‌تواند آپاچی یا هر سرور http دیگری باشد.

با این حال، چندین ظرافت در رابطه با این واقعیت وجود دارد که برنامه در نظر می‌گیرد که اولاً، همه درخواست‌ها از یک آدرس IP به آن می‌رسند (که می‌توان به عنوان مثال، تلاش برای حمله DDoS یا حدس زدن رمز عبور در نظر گرفت) و ثانیاً ، در نظر بگیرید که روی هاست 1.2.3.4 و پورت 8080 اجرا می شود (به ترتیب، تغییر مسیرهای نادرست ایجاد کنید و لینک های مطلق). برای جلوگیری از این مشکلات بدون نیاز به بازنویسی برنامه، پیکربندی زیر را راحت می دانم:
Nginx به رابط خارجی در پورت 80 گوش می دهد.

اگر باطن (مثلا آپاچی) روی همان میزبانی nginx قرار دارد، در پورت 80 در 127.0.0.1 یا برخی از آدرس های IP داخلی دیگر "گوش می دهد".

پیکربندی nginx در این مورد به صورت زیر است:

سرور(
گوش کن 4.3.2.1:80;
# هدر Host و X-Real-IP: را برای هر درخواست ارسال شده به backend تنظیم کنید
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header میزبان $host:$proxy_port;
# یا "proxy_set_header Host $host;" اگر برنامه به همه پیوندها اضافه شود:80
}

برای اینکه برنامه بتواند بین آدرس های IP بازدیدکنندگان تمایز قائل شود، باید ماژول mod_extract_forwarded را قرار دهید (اگر توسط سرور آپاچی اجرا شده باشد)، یا برنامه را طوری تغییر دهید که اطلاعات مربوط به آدرس IP کاربر را از X- بگیرد. هدر واقعی IP HTTP.

یکی دیگر از گزینه های Backend استفاده از FastCGI است. در این مورد، پیکربندی nginx چیزی شبیه به این خواهد بود:

سرور(
<…>

# مکانی که درخواست های اسکریپت های php در آن قرار می گیرند
مکان ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # آدرس و پورت سرور fastcgi را تعیین کنید،
fastcgi_index index.php; # ... فایل فهرست

# و برخی از پارامترهایی که باید به سرور fastcgi ارسال شوند تا بفهمد کدام اسکریپت و با چه پارامترهایی باید اجرا شود:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # نام اسکریپت
fastcgi_param QUERY_STRING $query_string; # رشته پرس و جو
# و پارامترهای پرس و جو:
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# با توجه به این واقعیت است که مکان های با عبارات با قاعدهدارای یک "اولویت" بزرگ هستند، تمام درخواست های غیر php در اینجا قرار می گیرند.

محل / (
root /var/www/html/
}

استاتیک

برای اینکه باطن کمتر بارگیری شود، بهتر است فایل های استاتیک را فقط از طریق nginx ارائه دهید - بهتر با این کار کنار می آید، زیرا. برای هر درخواست، به طور قابل توجهی منابع کمتری را صرف می کند (نیازی به ایجاد یک فرآیند جدید نیست، اما فرآیند nginx معمولاً مصرف می کند. حافظه کمتر، و بسیاری از اتصالات می توانند خدمت کنند).

در فایل کانفیگ به صورت زیر است:

سرور(
گوش کن *:80;
server_name myserver.com;

محل / (
proxy_pass


">http://127.0.0.1:80;

}

# فرض کنید همه فایل های استاتیک در فایل / هستند
مکان /فایل/ (
root /var/www/html/; # مسیر fs را مشخص کنید
14 روز منقضی می شود. # هدر Expires را اضافه کنید:
error_page 404 = @back; # و اگر فایل پیدا نشد، آن را به مکان نامگذاری شده @back ارسال کنید
}

# درخواست از فایل های / که هیچ فایلی برای آنها یافت نشد به باطن ارسال می شود و می تواند فایل مورد نظر را ایجاد کند یا نمایش دهد. پیام زیبادر مورد خطا
مکان@بازگشت(
proxy_pass
»title=»http://127.0.0.1:80;

">http://127.0.0.1:80;

}

اگر تمام استاتیک در یک دایرکتوری خاص قرار نمی گیرد، از عبارت منظم استفاده کنید:

مکان ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# مشابه با بالا، فقط تمام درخواست هایی که به یکی از پسوندهای مشخص شده ختم می شوند در این مکان قرار می گیرند
root /var/www/html/;
error_page 404 = @back;
}

متأسفانه، nginx مدیریت فایل های ناهمزمان را پیاده سازی نمی کند. به عبارت دیگر، nginx worker در عملیات I/O مسدود شده است. بنابراین اگر فایل های ثابت زیادی دارید و به خصوص اگر از آنها خوانده می شوند دیسک های مختلف، بهتر است تعداد فرآیندهای کارگر (تا تعداد 2-3 برابر بیشتر از تعداد کل هدهای روی دیسک) افزایش یابد. این البته منجر به افزایش بار روی سیستم عامل می شود، اما به طور کلی عملکرد افزایش می یابد. برای کار با مقدار معمولی استاتیک (تعداد بسیار زیاد فایل های نسبتاً کوچک: CSS، جاوا اسکریپت، تصاویر)، یک یا دو فرآیند کارگر کافی است.

ادامه دارد

پیوندها

در اینجا می توانید اطلاعات بیشتری در مورد nginx بیابید: