Web Server یا وب سرور نرمافزاری است که درخواستهای HTTP و HTTPS را از مرورگر یا کلاینت دریافت میکند و متناسب با مسیر درخواست، فایل ایستا را تحویل میدهد یا درخواست را به برنامه دیگری میفرستد. گاهی به ماشینی که این نرمافزار روی آن نصب شده نیز وب سرور میگویند، ولی در مباحث مهندسی نرمافزار باید میان خود نرمافزار، سرور میزبان و برنامه بکاند تفاوت بگذاریم.
برای مثال وقتی کاربر صفحهای از یک فروشگاه اینترنتی باز میکند، ابتدا سامانه نام دامنه آدرس دامنه را به IP تبدیل میکند. سپس اتصال به وب سرور برقرار میشود، امنیت لایه انتقال در صورت استفاده از HTTPS ارتباط را محافظت میکند و درخواست HTTP پردازش میشود. وب سرور میتواند تصویر محصول و فایل CSS را مستقیم برگرداند و درخواست ثبت سفارش را به اپلیکیشن بدهد.
وب سرور دقیقاً چه کاری انجام میدهد؟
- پاسخ به درخواست HTTP: خواندن متد، مسیر و هدرها و ارسال پاسخ با کد وضعیت مناسب.
- ارائه فایل ایستا: نمایش HTML، تصویر، فایل JavaScript، CSS و فایل دانلودی.
- هدایت درخواست پویا: ارسال درخواست به PHP-FPM، یک سرور Node.js، برنامه پایتونی یا سرویس ASP.NET.
- HTTPS و مدیریت گواهی: در بسیاری از معماریها پایان دادن به اتصال TLS و اعمال تنظیمات امنیتی.
- ریورس پروکسی و لودبالانسینگ: توزیع یا هدایت درخواست به یک یا چند سرویس بکاند، بسته به قابلیت و تنظیمات محصول.
- عملیات و پایش: ثبت Access Log و Error Log، تنظیم Timeout، محدودیت حجم درخواست و فشردهسازی پاسخ.
انواع نرمافزارهای وب سرور
| وب سرور | نقطه قوت یا کاربرد رایج | ملاحظات |
|---|---|---|
| Nginx (انجینکس) | ارائه محتوای ایستا، ریورس پروکسی، تنظیم مسیر درخواست و توزیع بار | مدیریت فایلهای پیکربندی و تنظیم اتصال به اپلیکیشن جداگانه |
| Apache HTTP Server (آپچی) | پشتیبانی گسترده از ماژولها و Virtual Host و قابلیتهای سازگار با پروژههای قدیمی و جدید | رفتار و مصرف منابع به MPM و ماژولهای فعال بستگی دارد |
| Caddy (کدی) | پیکربندی ساده و مدیریت خودکار HTTPS برای دامنههای واجد شرایط | برای معماریهای ویژه باید Caddyfile یا ماژولها دقیق تنظیم شوند |
| IIS (آیآیاس) | یکپارچگی با Windows Server، مدیریت از طریق IIS Manager و کاربرد فراوان در محیط ASP.NET | استقرار و ابزارهای مدیریتی عمدتاً وابسته به اکوسیستم ویندوز هستند |
| Lighttpd (لایتتیپیدی) | وب سرور سبک برای سناریوهای مشخص و سرویسدهی HTTP | انتخاب به نیاز عملیاتی، ماژولها و پشتیبانی تیم بستگی دارد |
هر کدام از این ابزارها میتوانند نقش وب سرور داشته باشند. برای آشنایی عملی بیشتر با انجینکس، ریورس پروکسی و لودبالانسر به صفحههای مستقل مراجعه کنید.
مسیر درخواست: از مرورگر تا اپلیکیشن
| مرحله | مثال فروشگاه اینترنتی | جزئیات |
|---|---|---|
| ۱. پیدا کردن سرور | shop.example.org | کلاینت با DNS آدرس سرور را پیدا میکند |
| ۲. اتصال | TCP و در HTTPS مذاکره TLS | وب سرور روی پورت تعیینشده مانند ۴۴۳ درخواست را دریافت میکند |
| ۳. تصمیم درباره مسیر | /images/item.jpg | وب سرور میتواند فایل ایستا را مستقیم بخواند |
| ۴. ارسال به اپلیکیشن | POST /orders | درخواست پویا به PHP-FPM یا سرور برنامه ارسال میشود |
| ۵. ساخت پاسخ | 201 Created یا 422 | اپلیکیشن نتیجه را برمیگرداند و وب سرور پاسخ HTTP را به کلاینت میفرستد |
مفهوم پروتکل انتقال ابرمتن، متدهای HTTP و کدهای وضعیت HTTP اجزای این جریان هستند. با این حال، هر درخواست لزوماً از تمام این مراحل به همین شکل عبور نمیکند. وجود CDN، کش، پروکسی یا معماری Serverless میتواند مسیر واقعی را تغییر دهد.
نمونه پیکربندی انجینکس برای سرویس Node.js
در این مثال انجینکس به درخواستهای ورودی روی پورت ۸۰ گوش میدهد و آنها را به سرویسی میفرستد که روی پورت ۳۰۰۰ همین سرور اجرا شده است. برای استفاده عمومی باید HTTPS و تنظیمات امنیتی مناسب هم فعال شوند.
server {
listen 80;
server_name app.example.org;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
وب سرور و PHP-FPM چه ارتباطی دارند؟
در یک پروژه PHP مانند لاراول، خود انجینکس کد PHP را اجرا نمیکند. وب سرور درخواست مرتبط با اسکریپت را از طریق FastCGI به پیاچپی افپیام میدهد و پاسخ را به مرورگر میرساند. در این ترکیب، فایلهای قابل انتشار باید در پوشه public باشند و مسیر دسترسی به فایلهای داخلی برنامه مسدود شود.
server {
listen 80;
server_name php.example.org;
root /var/www/shop/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
}
location ~ /\. {
deny all;
}
}
نکته پیکربندی
مثال بالا آموزشی است. آدرس و پورت PHP-FPM، نام فایل تنظیمات، دسترسی به پوشهها و جزئیات FastCGI به توزیع لینوکس و محیط استقرار بستگی دارد. در بعضی سرورها PHP-FPM به جای پورت TCP از Unix Socket استفاده میکند. پیش از انتشار، تنظیمات را با شرایط واقعی پروژه تطبیق دهید.
مثال ساده Apache با Virtual Host
در آپچی میتوان برای چند دامنه روی یک سرور تنظیمات مستقل تعریف کرد. این مثال یک وبسایت ایستا را از مسیر مشخص ارائه میکند.
<VirtualHost *:80>
ServerName docs.example.org
DocumentRoot "/var/www/docs/public"
<Directory "/var/www/docs/public">
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/docs-error.log
CustomLog ${APACHE_LOG_DIR}/docs-access.log combined
</VirtualHost>
مثال Caddy برای یک اپلیکیشن PHP
در کدی میتوان با دستور php_fastcgi درخواستهای PHP را به PHP-FPM سپرد و فایلهای ایستا را با file_server ارائه کرد. در صورت فراهم بودن شرایط دامنه و اتصال، کدی HTTPS را بهصورت خودکار مدیریت میکند.
shop.example.org {
root * /var/www/shop/public
encode zstd gzip
php_fastcgi 127.0.0.1:9000
file_server
}
چند دستور کاربردی برای عیبیابی وب سرور
| دستور | کاربرد |
|---|---|
curl -I https://shop.example.org | بررسی هدرها و کد وضعیت پاسخ |
sudo nginx -t | اعتبارسنجی تنظیمات انجینکس قبل از بارگذاری مجدد |
sudo systemctl reload nginx | بارگذاری تنظیمات جدید انجینکس بدون توقف کامل سرویس، در محیطهای مبتنی بر systemd |
sudo apachectl configtest | بررسی صحت تنظیمات آپچی |
sudo ss -ltnp | دیدن پردازشهایی که روی پورتهای TCP گوش میدهند |
sudo journalctl -u nginx -n 50 | مشاهده بخشی از لاگ سرویس انجینکس در systemd |
وب سرور، اپلیکیشن سرور و هاست چه تفاوتی دارند؟
| مفهوم | وظیفه | نمونه |
|---|---|---|
| وب سرور | دریافت درخواست HTTP، ارائه فایل، پروکسی یا هدایت درخواست | Nginx و Apache و Caddy و IIS |
| اپلیکیشن سرور یا Runtime | اجرای منطق برنامه و تولید پاسخ پویا | Node.js، Gunicorn/Uvicorn، Kestrel و PHP-FPM در نقش اجرای PHP |
| هاست یا سرور میزبان | فراهم کردن منابع پردازشی، حافظه، فضای ذخیرهسازی و شبکه | VPS، سرور اختصاصی یا ماشین ابری |
| ریورس پروکسی | قرار گرفتن جلوی سرویسهای دیگر و هدایت درخواست به آنها | قابلیتی که Nginx و Caddy و Apache میتوانند ارائه کنند |
گاهی یک نرمافزار چند نقش را همزمان انجام میدهد. مثلاً Kestrel یا سرور داخلی Node.js میتواند مستقیم درخواست HTTP بگیرد و اپلیکیشن را اجرا کند. به همین دلیل مرز میان وب سرور و اپلیکیشن سرور در همه فناوریها یکسان نیست. برای انتخاب زیرساخت، صفحات وب هاستینگ، کانتینر و داکر را نیز ببینید.
برای محیط عملیاتی چه چیزهایی را بررسی کنیم؟
گواهی TLS معتبر، محدود بودن دسترسی به فایلهای حساس، ثبت و پایش لاگها، تنظیم Timeout، محدودیت اندازه درخواست، Health Check، پشتیبانگیری از پیکربندی و تست تنظیمات قبل از Reload اهمیت دارند. داشتن وب سرور بهتنهایی به معنی امن یا مقیاسپذیر بودن برنامه نیست.
مستندات اصلی
- راهنمای مقدماتی رسمی انجینکس
- نمونههای Virtual Host در آپچی
- راهنمای PHP-FastCGI در کدی
- معرفی رسمی IIS در مایکروسافت
اصطلاحات مرتبط: انجینکس، پیاچپی افپیام، ریورس پروکسی، لودبالانسر، پروتکل انتقال ابرمتن، امنیت لایه انتقال، دامنه، سامانه نام دامنه، وب هاستینگ، دیوار آتش برنامه وب، کشینگ، رابط برنامهنویسی کاربردی.