FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

قیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

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

Server چیست؟ سرور دقیقاً چه کاری انجام می‌دهد؟

تعریف Server: ماشین فیزیکی، فرایند نرم‌افزاری، و «بک‌اند»؛ چرخهٔ درخواست HTTP طبق MDN؛ Origin در برابر لبه؛ چرا مالک سایت برای سرور پول می‌پردازد.

سا
سهیل ابراهیم‌پور

بنیان‌گذار و مهندس محصول

·۲۹ شهریور ۱۴۰۵·8 دقیقه مطالعه
Server چیستWeb ServerOrigin ServerBackendHTTP RequestClient-ServerHostingProcessHardware
مینی‌سرور با کابل شبکه روی میز

در گفت‌وگوی روزمره «سرور» گاهی یعنی یک کامپیوتر در رک دیتاسنتر، گاهی برنامه‌ای که روی پورت ۸۰ گوش می‌دهد، و گاهی کل «بک‌اند» محصول. هر سه کاربرد رایج‌اند؛ گیج شدن وقتی است که این معانی قاطی شوند و تصمیم خرید یا معماری روی تعریف مبهم بنا شود.

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

این مقاله سه لایهٔ معنا، چرخهٔ یک درخواست، و دلیل اقتصادی پرداخت برای سرور را جدا می‌کند تا وقتی می‌گویید «باید سرور بگیریم» بدانید دقیقاً چه می‌خرید.

چسب‌یادداشت Compute Storage Network روی تابلو

پاسخ کوتاه

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 را این‌گونه خلاصه می‌کند:

  1. باز کردن اتصال قابل‌اطمینان (معمولاً TCP؛ امروز اغلب با TLS برای HTTPS).
  2. ارسال پیام درخواست: متد (مثل GET یا POST)، مسیر منبع، نسخهٔ پروتکل، هدرها، و در برخی متدها بدنه.
  3. خواندن پاسخ سرور: کد وضعیت، هدرها، و در صورت نیاز بدنه (مثلاً HTML).
  4. بستن یا بازاستفادهٔ اتصال برای درخواست‌های بعدی.

برای نمایش یک صفحه، مرورگر اول سند 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 — نه لزوماً اینکه جعبهٔ فیزیکی مرده باشد.

چرا مالکان برای سرور پول می‌پردازند؟

چون سه نیاز همزمان باید برآورده شود:

  1. دسترس‌پذیری: سایت باید وقتی مشتری یا کاربر می‌آید پاسخ دهد؛ خاموش بودن ماشین شخصی پشت مودم خانگی برای کسب‌وکار جدی کافی نیست.
  2. ظرفیت و پایداری: CPU، RAM، دیسک و پهنای باند باید ترافیک واقعی را تحمل کند؛ اوج فروش یا کمپین بدون ظرفیت یعنی خطا و از دست رفتن درآمد.
  3. کنترل داده و منطق: سفارش، کاربر، محتوا و کلیدها باید جایی قابل پشتیبان‌گیری، امن‌سازی و نسخه‌گذاری باشند.

مدل هزینه فرق می‌کند: خرید سخت‌افزار CapEx و نگهداری است؛ سرور ابری معمولاً OpEx و صورتحساب بر اساس مصرف است (AWS همین تمایز را برای cloud server توضیح می‌دهد). در هر دو حالت، پول فقط بابت «فلز» نیست — بابت زمانی است که سیستم بالا می‌ماند و تیم شما مجبور نیست هر شب سخت‌افزار را نجات دهد.

جایگزین‌های ناقص: فقط صفحات استاتیک روی Object storage و CDN برای بروشور ممکن است کافی باشد؛ اپ با لاگین، سبد خرید یا دادهٔ شخصی تقریباً همیشه به Origin محاسباتی و ذخیره‌سازی نیاز دارد. Serverless هم «بدون سرور از دید شما» است نه «بدون کامپیوتر در جهان» — اجرا روی زیرساخت شخص دیگری است.

AWS منافع cloud server را انعطاف پیکربندی، مدیریت هزینه‌ای بدون نگهداری سخت‌افزار، و مقیاس‌پذیری می‌داند. این‌ها دلیل مهاجرت بسیاری تیم‌هاست؛ دلیل کافی برای هر محصول نیست — گاهی یک VPS ساده یا حتی اشتراکی محدود هنوز با اندازهٔ کار جور است.

اشتباه‌های مفهومی رایج

  • «CDN گرفتیم پس دیگر سرور لازم نیست» — برای منطق و دادهٔ اصلی معمولاً لازم است.
  • «یک سرور قوی یعنی همیشه سریع» — گلوگاه ممکن است دیتابیس، شبکه، یا کش نباشد.
  • «هاست اشتراکی، VPS و اختصاصی فقط اسم بازاریابی‌اند» — سطح ایزوله و مسئولیت عملیات فرق واقعی دارد (مقالهٔ ۰۴۲).
  • «سرور = فقط لینوکس در ترمینال» — برای مالک محصول، سرور یعنی تعهد دسترس‌پذیری خدمت.
  • «اگر لوکال کار می‌کند پس پروداکشن هم همان است» — تفاوت شبکه، TLS، مقیاس و داده واقعی را نادیده می‌گیرد.

از خرید تا بهره‌برداری: سؤالات قبل از پول دادن

  1. چه معنایی از سرور می‌خرم: VM، اختصاصی، یا فقط فضای اشتراکی؟
  2. چه کسی OS را وصله می‌کند و بکاپ می‌گیرد؟
  3. اگر ترافیک سه برابر شد، مسیر مقیاس چیست؟
  4. داده کجاست و چگونه برمی‌گردد اگر دیسک از بین برود؟

پاسخ این سؤال‌ها را قبل از مقایسهٔ قیمت بنویسید؛ وگرنه ارزان‌ترین برچسب را می‌خرید و گران‌ترین 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/

نویسنده

سا

سهیل ابراهیم‌پور بنیان‌گذار FutureForge است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر با مسئله‌ای شبیه این روبه‌رو هستید، درباره‌ی شرایط پروژه‌تان با هم صحبت کنیم.

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
Logging چیست؟ ثبت رویداد برای تشخیص و پاسخ به حادثه
تعیین اندازهٔ سرور: RAM، CPU و Storage بر اساس Workload
Docker در برابر Kubernetes؛ مقایسهٔ دقیق نه شعار
چرا همیشه به Kubernetes نیاز ندارید؟
Kubernetes چیست؟ اجرای مقاوم workloadهای کانتینری

عملیات و استقرار

Logging چیست؟ ثبت رویداد برای تشخیص و پاسخ به حادثه

۲۹ شهریور ۱۴۰۵

عملیات و استقرار

تعیین اندازهٔ سرور: RAM، CPU و Storage بر اساس Workload

۲۹ شهریور ۱۴۰۵

عملیات و استقرار

Docker در برابر Kubernetes؛ مقایسهٔ دقیق نه شعار

۲۹ شهریور ۱۴۰۵

عملیات و استقرار

چرا همیشه به Kubernetes نیاز ندارید؟

۲۹ شهریور ۱۴۰۵

عملیات و استقرار

Kubernetes چیست؟ اجرای مقاوم workloadهای کانتینری

۲۹ شهریور ۱۴۰۵
همه یادداشت‌ها219
معماری نرم‌افزار13
واژه‌نامه37
عملیات و استقرار87
مهندسی محصول74
راهنمای وب8
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو