بهینه سازی سرور اوبونتو

در این مقاله قصد داریم روش‌های بهینه‌ سازی سرورهای اوبونتو را برای میزبانی وبسایت شما با استفاده از وب سرور nginx آموزش دهیم .

افزایش مقادیر systemd
اگر از systemd برای سرویس‌هایی مانند nginx، netdata و … استفاده می‌کنید، باید یک پیکربندی جدید برای آن‌ها داشته باشید تا آن سرویس‌ها را با محدودیت جدید تطبیق دهید:

mkdir -p /etc/systemd/system/nginx.service.d
این متن را به فایل اضافه کنید

مسیر فایل  » /etc/systemd/system/nginx.service.d/limit.conf
عبارت مورد نظر :
[Service]
LimitNOFILE=100000

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

cat /proc/$(ps aux | grep “nginx: master process” | grep -v grep | awk ‘{print $2}’)/limits | grep “Max open files”

حالا nginx را ری‌استارت کنید و دوباره چک کنید تا آپدیت جدید را ببینید

systemctl daemon-reload
systemctl restart nginx.service
cat /proc/$(ps aux | grep “nginx: master process” | grep -v grep | awk ‘{print $2}’)/limits | grep “Max open files”

سرور شما حداکثر تعداد اتصالات را محدود کرده است؟

این ممکن است با نوعی سرور اتفاق بیفتد، ما باید این مقدار را افزایش دهیم تا سرور تعداد اتصالات بیشتری را بپذیرد. خیلی ساده است. فقط فایل /etc/sysctl.conf را باز کنید و خطوط زیر را اضافه کنید، سپس راه اندازی مجدد کنید:

net.ipv4.netfilter.ip_conntrack_max = 1048576
net.nf_conntrack_max = 1048576
net.core.somaxconn = 1048576

بهینه سازی وب سرور

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

HTTP/2 را در Nginx فعال کنید

اولین قدم در تنظیم Nginx برای TTFB/Latency سریعتر با HTTPS این است که مطمئن شوید HTTP/2 فعال است.
HTTP/2 اولین بار با Nginx نسخه 1.9.5 برای جایگزینی پروتکل spdy تحویل داده شد.
فعال کردن ماژول HTTP/2 در Nginx ساده است. فقط باید کلمه کلیدی http2 را در بلوک سرور به فایل پیکربندی Nginx اضافه کنید (مثلا /etc/nginx/sites-enabled/sitename). و به خاطر داشته باشید که HTTP/2 نیاز به فعال بودن HTTPS دارد.

listen 443 ssl http2;

سپس بارگذاری مجدد سرویس Nginx را انجام دهید و تمام!

service nginx reload

کش sesion SSL را فعال کنید

چرا باید کش جلسه SSL را فعال کنیم؟ با اتصالات HTTPS، به جای اتصال کاربران نهایی از طریق رفت و برگشت، اتصال به یک دست دادن اضافی نیاز دارد. با این حال، استفاده از HTTP/2 و فعال کردن Nginx ssl_session_cache، عملکرد سریع‌تر HTTPS را برای اتصالات اولیه تضمین می‌کند و به سادگی بسیار سریع‌تر از بارگذاری صفحه http.

می‌توانید Nginx را طوری پیکربندی کنید که این کش را بین همه کارگران به اشتراک بگذارد. و در حالی که داشتن یک نمونه چند CPU بسیار توصیه می شود.
1 مگابایت می تواند حدود 4000 جلسه را ذخیره کند. ما در پیکربندی 20 مگابایت و کش TTL (استفاده مجدد از زمان مجاز) قرار دادیم زیرا انتظار داریم بار زیادی روی سرور وجود داشته باشد:

ssl_session_cache shared:SSL:20m; # holds approx 80000 sessions

ssl_session_timeout 2h; # 2 hours for Cache TTL

TLS (همچنین به عنوان امنیت لایه حمل و نقل نیز شناخته می شود) – یک پروتکل رمزنگاری است که برای تامین امنیت ارتباطات از طریق یک شبکه کامپیوتری طراحی شده است. جایگزین SSL شد. من حتی یک تشبیه می کنم که TLS در واقع نسل بعدی SSL است که منسوخ شده و تحت تأثیر حملات POODLE قرار گرفته است. پروتکل TLS شامل دو لایه است: رکورد TLS و پروتکل های دست دادن TLS. درک این نکته مهم است که عملیات TLS برای منابع بسیار گران است، به طوری که حتی چندین فرآیند کارگر برای اجرا در سیستم های چند پردازنده ای مورد نیاز است. عملیات Handshake TLS از نظر بارگذاری و زمان اجرا «دشوارترین» است. بنابراین، بهترین راه‌حل بهینه‌سازی جلسه است: اتصالات مداوم، حافظه پنهان، کلیدهای استاتیک و فعال کردن OCSP Stapling. به همین دلیل است که ما بهینه سازی را با فعال کردن کش جلسه SSL آغاز کردیم. Keepalive – اتصال مداوم استفاده از اتصالات مداوم، پردازش چندین درخواست را به صورت همزمان در یک اتصال ممکن می کند.

server { … keepalive_timeout 90; … } Ticket های session پروتکل TLS می‌تواند از Ticket session برای از سرگیری جلسه استفاده کند، در صورتی که مشتری از آن پشتیبانی کند (خانواده‌های مرورگر Chromium و Firefox). برای انجام این کار، سرور TLS یک settion TIcket رمزگذاری شده با کلید خود و شناسه کلید را برای مشتری ارسال می کند. کلاینت جلسه امن را با ارسال آخرین Ticketبه سرور در طول اولیه سازی رویه TLS Handshake از سر می گیرد. سپس سرور جلسه را با توجه به پارامترهای ذخیره شده از سر می گیرد.

server {
…
ssl_session_ticket_key current.key;
ssl_session_ticket_key prev.key;
ssl_session_ticket_key prevprev.key; … } منگنه OCSP پروتکل وضعیت گواهی آنلاین یک مکانیسم تأیید اعتبار گواهی SSL است که جایگزین پروتکل کندتر فهرست لغو گواهی (CRL) می شود. هنگام استفاده از CRL، مرورگر لیست ابطال گواهی را دانلود می کند و گواهی فعلی را بررسی می کند که زمان اتصال را افزایش می دهد. هنگام استفاده از OCSP، مرورگر یک درخواست تأیید را به آدرس OCSP ارسال می کند و در پاسخ وضعیت گواهی را دریافت می کند که می تواند سرورهای مرجع صدور گواهینامه (CA) را به شدت بارگیری کند. برای استفاده از این پروتکل، از OCSP Stapling استفاده می شود – صاحب گواهی به طور مستقل در یک بازه زمانی معین از سرور OCSP نظرسنجی می کند و پاسخی را که حاوی یک امضا است ذخیره می کند. سپس پاسخ از طریق بسط درخواست وضعیت گواهی به Handshake TLS متصل می شود. به این ترتیب سرورهای CA تعداد زیادی درخواست را که حاوی اطلاعات حساس در مورد دیدگاه های کاربر نیز هستند دریافت نمی کنند. برای فعال کردن OCSP Stapling به سادگی چند خط اضافه کنید:

server {
…
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/sitename.crt; … }

Strict Transport Security

برای وادار کردن مرورگر به استفاده از پروتکل HTTPS، مکانیزمی به نام Strict Transport Security وجود دارد.
هنگام دریافت چنین هدر از سرور، مرورگر متوجه می شود که حتی پس از دنبال کردن پیوند HTTP، استفاده از پروتکل HTTPS ضروری است.
این دستورالعمل به جلوگیری از برخی از حملات کمک می کند، به خصوص اگر سرور تغییر مسیری از HTTP به HTTPS نداشته باشد.

add_header Strict-Transport-Security “max-age=31536000; includeSubDomains”;

Reduce SSL buffer size

گزینه Nginx ssl_buffer_size اندازه بافر مورد استفاده برای ارسال داده از طریق HTTPS را تعیین می کند. به طور پیش فرض، ssl_buffer_size روی 16k تنظیم شده است. این یک رویکرد ارزشی «پیش‌فرض» خوب است که برای پاسخ‌های بزرگ طراحی شده است.
با این حال، برای به حداقل رساندن TTFB (زمان برای اولین بایت) اغلب بهتر است از مقدار کمتری استفاده کنید و به تنظیمات شما بستگی دارد. در نمونه مشتری ما تنظیم کردیم:

ssl_buffer_size 4k;

SSL Ciphers and deploying Diffie-Hellman

در ادامه این لینک می توانید توضیح دهید که چرا باید از یک گروه Strong Diffie-Hellman استفاده کنید.

مرورگرهای مدرن از جمله گوگل کروم، موزیلا فایرفاکس و مایکروسافت اینترنت اکسپلورر حداقل اندازه گروه را به 1024 بیت افزایش داده اند. توصیه می کنیم یک گروه 2048 بیتی ایجاد کنید، اما اگر پارانویا هستید، 4096 را انتخاب کنید:

openssl dhparam -out dhparams.pem 2048
در Nginx config گزینه ssl_ciphers در بلوک سرور قرار می گیرد:

server {
… ssl_prefer_server_ciphers on; ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA’; ssl_dhparam /etc/Nginx/SSL/DH params.pem; … }