Server چیست؟ سرور دقیقاً چه کاری انجام میدهد؟
تعریف Server: ماشین فیزیکی، فرایند نرمافزاری، و «بکاند»؛ چرخهٔ درخواست HTTP طبق MDN؛ Origin در برابر لبه؛ چرا مالک سایت برای سرور پول میپردازد.
SE
8 min readSoheil Ebrahimpour
Founder & product engineer

در گفتوگوی روزمره «سرور» گاهی یعنی یک کامپیوتر در رک دیتاسنتر، گاهی برنامهای که روی پورت ۸۰ گوش میدهد، و گاهی کل «بکاند» محصول. هر سه کاربرد رایجاند؛ گیج شدن وقتی است که این معانی قاطی شوند و تصمیم خرید یا معماری روی تعریف مبهم بنا شود.
MDN در Overview of HTTP وب را کلاینت–سرور توصیف میکند: درخواست را معمولاً مرورگر (User-agent) شروع میکند و سرور پاسخ میدهد. Cloudflare Learning «Origin server» را رایانهای میداند که یک یا چند برنامه برای گوش دادن و پردازش درخواستهای اینترنتی اجرا میکند. AWS «Cloud server» را نمونهٔ مجازی روی زیرساخت ارائهدهنده تعریف میکند که از دید کلاینت مثل سرور فیزیکی رفتار میکند.
این مقاله سه لایهٔ معنا، چرخهٔ یک درخواست، و دلیل اقتصادی پرداخت برای سرور را جدا میکند تا وقتی میگویید «باید سرور بگیریم» بدانید دقیقاً چه میخرید.

پاسخ کوتاه
Server در وب ماشینی (فیزیکی یا مجازی) بههمراه نرمافزاری است که منتظر درخواست میماند، کار لازم را انجام میدهد، و پاسخ میفرستد — معمولاً روی HTTP. سختافزار برق، CPU، RAM و دیسک را تأمین میکند؛ فرایند نرمافزاری منطق و پروتکل را اجرا میکند؛ و در زبان محصول، «سرور / بکاند» اغلب همهٔ خدمات سمت سرور را در بر میگیرد: وبسرور، اپلیکیشن، پایگاهداده، صف و ذخیرهسازی.
مالک برای سرور پول میپردازد چون بدون جایی که درخواست را بپذیرد و داده و منطق کسبوکار را نگه دارد، سایت یا اپ عمومی وجود ندارد. CDN و کش لبه کمک میکنند، اما جایگزین کامل Origin برای منطق پویا و دادهٔ اصلی نیستند.
سرور جایی است که درخواست تمام میشود و پاسخ شروع میشود — چه یک باکس فلزی باشد، چه یک فرایند، چه چند خدمت پشت یک نام دامنه.
سه معنای رایج «Server»
۱) سختافزار یا ماشین
یک سرور فیزیکی جعبهای در دیتاسنتر (یا رک کوچک) با CPU، حافظه، دیسک و شبکه است که ۲۴ساعته روشن میماند. سازمان ممکن است آن را بخرد و نگه دارد، یا از ارائهدهنده اجاره کند. AWS در مقایسهٔ cloud server و normal server میگوید سرور سنتی سختافزار تحت مالکیت سازمان است؛ cloud server نرمافزاری روی زیرساخت CSP است که منابع را از سختافزار اشتراکی جدا میکند.
در عمل، وقتی میگویید «سرور اختصاصی خریدم» معمولاً یعنی کل یا بخش بزرگی از یک ماشین فیزیکی در اختیار شماست. وقتی میگویید «یک VPS گرفتم» یعنی برشی مجازی از یک ماشین فیزیکی با منابع اختصاصیافته. هر دو «سرور»اند، اما مدل مالکیت و همسایگی فرق دارد.
۲) فرایند نرمافزاری
Nginx، Apache، Node.js که listen میکند، یا سرویس اپلیکیشن داخل کانتینر، همگی «سرور» به معنای فرایند هستند: برنامه روی یک پورت منتظر اتصال میماند و به پیامها جواب میدهد. روی یک ماشین فیزیکی میتوان چندین سرور نرمافزاری همزمان اجرا کرد. MDN یادآوری میکند با HTTP/1.1 و هدر Host حتی چند سایت میتوانند یک IP را به اشتراک بگذارند.
وقتی مهندس میگوید «سرور کرش کرد»، گاهی منظور فرایند است نه خاموش شدن برق رک. این تمایز برای عیبیابی مهم است: ریاستارت فرایند با تعویض سختافزار یکی نیست.
۳) «بکاند» محصول
در تیم محصول، «سرور» اغلب مترادف کل سمت غیرکلاینت است: API، احراز هویت، پرداخت، دیتابیس، ذخیرهسازی فایل، و کارهای زمانبندیشده. کاربر نهایی این جزئیات را نمیبیند؛ فقط میبیند صفحه بالا میآید یا خطا میدهد. برای تصمیم بودجه، این معنای سوم مهم است چون هزینه فقط «یک VM» نیست — پایش، پشتیبان، امنیت و نیروی عملیات هم بخشی از همان «داشتن سرور» است.
چرخهٔ یک درخواست: از کلیک تا پاسخ
MDN جریان HTTP را اینگونه خلاصه میکند:
- باز کردن اتصال قابلاطمینان (معمولاً TCP؛ امروز اغلب با TLS برای HTTPS).
- ارسال پیام درخواست: متد (مثل GET یا POST)، مسیر منبع، نسخهٔ پروتکل، هدرها، و در برخی متدها بدنه.
- خواندن پاسخ سرور: کد وضعیت، هدرها، و در صورت نیاز بدنه (مثلاً HTML).
- بستن یا بازاستفادهٔ اتصال برای درخواستهای بعدی.
برای نمایش یک صفحه، مرورگر اول سند HTML را میگیرد، سپس درخواستهای بیشتری برای CSS، اسکریپت، تصویر و غیره میفرستد و آنها را ترکیب میکند. سرور از دید منطقی ممکن است یک ماشین نباشد: MDN میگوید ممکن است مجموعهای با Load balancing، کش، دیتابیس یا سرویسهای تجارت الکترونیک باشد که سند را تماماً یا بخشی در لحظه تولید میکنند.
بین مرورگر و سرور نهایی، Proxyها میتوانند Caching، فیلتر، تعادل بار، احراز هویت یا Logging انجام دهند. CDN در این مسیر اغلب نقش لبه و کش را بازی میکند؛ Origin همان جایی است که منطق اصلی و دادهٔ منبع زندگی میکنند. Cloudflare میگوید فاصلهٔ فیزیکی Origin تا کلاینت به Latency اضافه میکند و CDN با نزدیک کردن کش، RTT را کم میکند — اما برای کارهایی مثل بررسی رمز هششده در دیتابیس، Origin همچنان نقش دارد.
HTTP از نظر معنایی Stateless است: هر درخواست مستقل است مگر با Cookie یا مکانیزم نشست، حالت را خودتان بسازید. این توضیح میدهد چرا «سرور جلسه را یادش میماند» در واقع ترکیبی از سرور اپ و ذخیرهٔ سمت سرور/کلاینت است، نه جادوی پروتکل خام.
سرور وب چه کارهایی انجام میدهد؟
- گوش دادن به درخواست و مسیریابی به سایت/اپ درست (بر اساس Host، مسیر، یا قوانین).
- سرو فایل استاتیک یا اجرای منطق پویا (رندر قالب، فراخوانی API داخلی).
- صحبت با پایگاهداده و سامانههای دیگر برای خواندن/نوشتن حالت کسبوکار.
- اعمال قواعد امنیتی پایه: TLS، محدودیت نرخ، اعتبارسنجی ورودی در لایهٔ اپ.
- ثبت لاگ و متریک برای عیبیابی و ظرفیتسنجی.
Cloudflare در توضیح HTTP یادآوری میکند درخواست معمولاً متدی مثل GET (گرفتن) یا POST (ارسال دادهٔ فرم) دارد و پاسخ موفق GET اغلب بدنهٔ HTML برای مرورگر میآورد. بدون سروری که این قرارداد را رعایت کند، «سایت» فقط فایل روی لپتاپ توسعهدهنده است.
پاسخ فقط «۲۰۰ و HTML» نیست: کدهای ۳xx برای هدایت، ۴xx برای خطای کلاینت، ۵xx برای خطای سمت سرور بخشی از همان قراردادند. وقتی میگویید سرور خراب است، اغلب یعنی ۵xx یا timeout — نه لزوماً اینکه جعبهٔ فیزیکی مرده باشد.
چرا مالکان برای سرور پول میپردازند؟
چون سه نیاز همزمان باید برآورده شود:
- دسترسپذیری: سایت باید وقتی مشتری یا کاربر میآید پاسخ دهد؛ خاموش بودن ماشین شخصی پشت مودم خانگی برای کسبوکار جدی کافی نیست.
- ظرفیت و پایداری: CPU، RAM، دیسک و پهنای باند باید ترافیک واقعی را تحمل کند؛ اوج فروش یا کمپین بدون ظرفیت یعنی خطا و از دست رفتن درآمد.
- کنترل داده و منطق: سفارش، کاربر، محتوا و کلیدها باید جایی قابل پشتیبانگیری، امنسازی و نسخهگذاری باشند.
مدل هزینه فرق میکند: خرید سختافزار CapEx و نگهداری است؛ سرور ابری معمولاً OpEx و صورتحساب بر اساس مصرف است (AWS همین تمایز را برای cloud server توضیح میدهد). در هر دو حالت، پول فقط بابت «فلز» نیست — بابت زمانی است که سیستم بالا میماند و تیم شما مجبور نیست هر شب سختافزار را نجات دهد.
جایگزینهای ناقص: فقط صفحات استاتیک روی Object storage و CDN برای بروشور ممکن است کافی باشد؛ اپ با لاگین، سبد خرید یا دادهٔ شخصی تقریباً همیشه به Origin محاسباتی و ذخیرهسازی نیاز دارد. Serverless هم «بدون سرور از دید شما» است نه «بدون کامپیوتر در جهان» — اجرا روی زیرساخت شخص دیگری است.
AWS منافع cloud server را انعطاف پیکربندی، مدیریت هزینهای بدون نگهداری سختافزار، و مقیاسپذیری میداند. اینها دلیل مهاجرت بسیاری تیمهاست؛ دلیل کافی برای هر محصول نیست — گاهی یک VPS ساده یا حتی اشتراکی محدود هنوز با اندازهٔ کار جور است.
اشتباههای مفهومی رایج
- «CDN گرفتیم پس دیگر سرور لازم نیست» — برای منطق و دادهٔ اصلی معمولاً لازم است.
- «یک سرور قوی یعنی همیشه سریع» — گلوگاه ممکن است دیتابیس، شبکه، یا کش نباشد.
- «هاست اشتراکی، VPS و اختصاصی فقط اسم بازاریابیاند» — سطح ایزوله و مسئولیت عملیات فرق واقعی دارد (مقالهٔ ۰۴۲).
- «سرور = فقط لینوکس در ترمینال» — برای مالک محصول، سرور یعنی تعهد دسترسپذیری خدمت.
- «اگر لوکال کار میکند پس پروداکشن هم همان است» — تفاوت شبکه، TLS، مقیاس و داده واقعی را نادیده میگیرد.
از خرید تا بهرهبرداری: سؤالات قبل از پول دادن
- چه معنایی از سرور میخرم: VM، اختصاصی، یا فقط فضای اشتراکی؟
- چه کسی OS را وصله میکند و بکاپ میگیرد؟
- اگر ترافیک سه برابر شد، مسیر مقیاس چیست؟
- داده کجاست و چگونه برمیگردد اگر دیسک از بین برود؟
پاسخ این سؤالها را قبل از مقایسهٔ قیمت بنویسید؛ وگرنه ارزانترین برچسب را میخرید و گرانترین downtime را تجربه میکنید.
جمعبندی برای تصمیم
Server سختافزار یا ماشین مجازی است، فرایند گوشدهنده است، و در زبان کسبوکار اغلب کل بکاند است. چرخهٔ HTTP از اتصال و درخواست تا پاسخ، قرارداد بین کلاینت و آن سمت است. پول بابت سرور یعنی پول بابت جای امن و در دسترس برای اجرای منطق و نگه داشتن داده.
قدم بعدی منطقی: تفاوت VPS، Cloud و فیزیکی را برای انتخاب مدل بهرهبرداری بخوانید؛ بعد ظرفیت و استقرار را جداگانه تصمیم بگیرید.
منابع و مراجع
- MDN — Overview of HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
- Cloudflare Learning — What is an origin server? — https://www.cloudflare.com/learning/cdn/glossary/origin-server/
- Cloudflare Learning — What is HTTP? — https://www.cloudflare.com/learning/ddos/glossary/hypertext-transfer-protocol-http/
- AWS — What is a Cloud Server? — https://aws.amazon.com/what-is/cloud-server/
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.




