مبانی کامپیوتر و اینترنتاینترنت چطور کار می‌کنددرس ۱۲ از ۱۶

کلاینت و سرور

مدل کلاینت و سرور: چه کسی شروع می‌کند و چه کسی منتظر می‌ماند، درخواست و پاسخ، مثال‌های روزمره (مرورگر و وب‌سرور، psql و PostgreSQL، ssh و sshd)، بالا آوردن یک وب‌سرور واقعی با python3 -m http.server، خواندن لاگ سرور، باز کردن سایت از گوشی در همان شبکه، یک سرور پویای کوچک با پایتون، و فرق فرانت‌اند و بک‌اند.

حدود ۱۸ دقیقه مطالعه
۷ مثال اجراشده
۳ تمرین با جواب
مقدماتی (از صفر مطلق)
به‌روزرسانی: ۲۹ مهر ۱۴۰۵

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

مسئله: «سرور» یعنی چه؟

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

تشبیه: رستوران

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

سه نکته از همین تشبیه:

همیشه کلاینت شروع می‌کند. آشپزخانه به خانه‌ی تو زنگ نمی‌زند؛ تو به رستوران می‌روی.
سرور باید آدرس ثابت و معروف داشته باشد (IP یا دامنه، و پورت). کلاینت می‌تواند هر جایی باشد.
آشپزخانه بسته باشد یعنی «رستوران هست ولی آشپزخانه کار نمی‌کند»: همان Connection refused درس پورت.

کلاینت درخواست می‌فرستد و سرور پاسخ می‌دهد؛ سرور بعد از پاسخ دادن، منتظر درخواست بعدی می‌ماند.

کلاینت و سرورهایی که همین الان می‌شناسی

کلاینت	سرور	پروتکل و پورت
مرورگر، `curl`	وب‌سرور (nginx، برنامه‌ی پایتون)	HTTP/HTTPS، 80/443
اپ تلگرام روی گوشی	سرورهای تلگرام	پروتکل خود تلگرام
`ssh` در ترمینال تو	`sshd` روی سرور	SSH، 22
`psql`، برنامه‌ی فروشگاه	PostgreSQL	پروتکل PostgreSQL، 5432
کامپیوتر تو هنگام باز کردن هر سایت	resolver DNS	DNS، 53
برنامه‌ی ایمیل	سرور ایمیل	SMTP/IMAP

یک برنامه می‌تواند هم‌زمان هر دو باشد: برنامه‌ی فروشگاه برای مرورگر مشتری سرور است و برای دیتابیس کلاینت. سرور فروشگاه وقتی صفحه‌ی «سفارش‌های من» را می‌سازد، خودش از دیتابیس می‌پرسد.

یک درخواست واقعی معمولاً از چند لایه کلاینت و سرور رد می‌شود؛ هر کس برای لایه‌ی بعدی کلاینت است.

مثال‌های عملی

مثال ۱: یک وب‌سرور در یک دستور

یک پوشه با یک صفحه‌ی HTML بساز. (HTML زبان صفحه‌های وب است؛ فعلاً فقط کپی کن. cat > فایل <<EOF ... EOF متن بین دو EOF را در فایل می‌نویسد؛ در دوره‌ی bash یاد می‌گیری.)

mkdir -p ~/site && cd ~/site
cat > index.html <<EOF
<!doctype html>
<html lang="fa" dir="rtl">
<head><meta charset="utf-8"><title>فروشگاه من</title></head>
<body>
  <h1>به فروشگاه من خوش آمدی</h1>
  <p>این صفحه از یک سرور روی کامپیوتر خودم می‌آید.</p>
</body>
</html>
EOF
echo "سلام" > notes.txt
mkdir -p images

حالا سرور را روشن کن:

python3 -m http.server 8000

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

پایتون یک وب‌سرور آماده دارد: فایل‌های پوشه‌ی فعلی را روی پورت ۸۰۰۰ سرو می‌کند. ترمینال «گیر» کرده؛ درست است: سرور یعنی برنامه‌ای که منتظر می‌ماند و تا Ctrl+C نزنی تمام نمی‌شود. 0.0.0.0 یعنی روی همه‌ی آدرس‌های این کامپیوتر گوش می‌دهد (درس پورت).

مرورگر را باز کن و برو به http://localhost:8000. صفحه‌ات را می‌بینی. اگر در WSL هستی، مرورگر ویندوز هم localhost:8000 را باز می‌کند (WSL پورت‌ها را به ویندوز می‌رساند). در Multipass به‌جای localhost آدرس IP ماشین را بگذار (multipass info آن را نشان می‌دهد).

مثال ۲: کلاینت خط فرمانی، `curl`

یک ترمینال دیگر باز کن (سرور در اولی در حال اجراست):

curl -s http://localhost:8000/ | head -5
curl -s http://localhost:8000/notes.txt
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/nothing.html

<!doctype html>
<html lang="fa" dir="rtl">
<head><meta charset="utf-8"><title>فروشگاه من</title></head>
<body>
  <h1>به فروشگاه من خوش آمدی</h1>
سلام
404

curl همان کار مرورگر را می‌کند، بدون نمایش صفحه: درخواست می‌فرستد و پاسخ خام را چاپ می‌کند. مرورگر همین متن HTML را می‌گیرد و آن را به صفحه‌ی زیبا تبدیل می‌کند. برای فایلی که نیست، سرور کد 404 («پیدا نشد») برگرداند. -o /dev/null یعنی محتوا را دور بریز و -w "%{http_code}" یعنی فقط کد پاسخ را چاپ کن. (کدهای پاسخ را در درس HTTP کامل می‌بینی.)

مثال ۳: لاگ سرور، دفتر ثبت درخواست‌ها

به ترمینال اول (سرور) نگاه کن:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [22/Oct/2026 00:24:08] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [22/Oct/2026 00:24:08] code 404, message File not found
127.0.0.1 - - [22/Oct/2026 00:24:08] "GET /nothing.html HTTP/1.1" 404 -
127.0.0.1 - - [22/Oct/2026 00:24:08] "GET /notes.txt HTTP/1.1" 200 -

هر خط یک درخواست است:

127.0.0.1: IP کلاینت. این‌جا localhost، چون از همین کامپیوتر آمد.
[22/Oct/2026 00:24:08]: زمان.
"GET / HTTP/1.1": چه خواست؛ متد GET («بده»)، مسیر / (صفحه‌ی اصلی) و نسخه‌ی پروتکل.
200 یا 404: سرور چه جوابی داد.

لاگ‌ها چشم تو روی سرورند. روی سرور واقعی، وقتی کاربری می‌گوید «سایت خطا داد»، اولین کار نگاه کردن به همین خط‌هاست (دوره‌ی nginx درسی کامل درباره‌ی لاگ دارد). ترتیب GET / در مرورگر معمولاً یک درخواست اضافه هم دارد: GET /favicon.ico که مرورگر برای آیکون کوچک تب می‌فرستد و احتمالاً ۴۰۴ می‌گیرد. طبیعی است.

مثال ۴: سرور، پوشه‌ها را هم نشان می‌دهد

curl -s http://localhost:8000/images/ | head -12

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Directory listing for /images/</title>
</head>
<body>
<h1>Directory listing for /images/</h1>
<hr>
<ul>
</ul>
<hr>

برای پوشه‌ای که index.html ندارد، این سرور فهرست فایل‌ها را نشان می‌دهد (این‌جا خالی). برای آزمایش راحت است، ولی برای سایت واقعی خطرناک: هر فایلی در پوشه بگذاری، هر کس می‌بیند و دانلود می‌کند. http.server فقط برای آزمایش و انتقال سریع فایل است، نه سایت واقعی؛ برای آن، وب‌سرورهایی مثل nginx هست.

مثال ۵: از گوشی باز کن

گوشی را به همان Wi-Fi وصل کن. IP لپ‌تاپ را پیدا کن (درس شبکه):

ip -br addr

و در مرورگر گوشی بزن http://IP-لپ‌تاپ:8000، مثلاً http://192.168.1.20:8000. سایتت روی گوشی است. در لاگ سرور، خط جدید IP گوشی را نشان می‌دهد، نه 127.0.0.1:

192.168.1.34 - - [22/Oct/2026 00:31:12] "GET / HTTP/1.1" 200 -
192.168.1.34 - - [22/Oct/2026 00:31:12] code 404, message File not found
192.168.1.34 - - [22/Oct/2026 00:31:12] "GET /favicon.ico HTTP/1.1" 404 -

(روی ماشین آزمایشی این درس، از یک آدرس دیگرِ همان کامپیوتر وصل شدیم و لاگ همان آدرس را ثبت کرد: 192.0.2.2 - - [22/Oct/2026 00:24:17] "GET / HTTP/1.1" 200 -.)

اگر باز نشد: WSL و Multipass و ماشین مجازی یک شبکه‌ی مجازی جدا دارند و گوشی مستقیم به آن‌ها دسترسی ندارد؛ این آزمایش روی لینوکسی که مستقیم روی لپ‌تاپ نصب است (یا با تنظیمات «bridged» ماشین مجازی) کار می‌کند. فایروال ویندوز یا مک هم ممکن است جلویش را بگیرد. اگر نتوانستی، مهم نیست؛ مفهوم همان است.

حالا سرور را فقط برای خود کامپیوتر محدود کن:

python3 -m http.server 8000 --bind 127.0.0.1

Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...

از گوشی دیگر باز نمی‌شود، از خود لپ‌تاپ چرا. همان درس ۱۲۷٫۰٫۰٫۱ و ۰٫۰٫۰٫۰.

مثال ۶: سرور خاموش

در ترمینال سرور Ctrl+C بزن:

^C
Keyboard interrupt received, exiting.

و دوباره از ترمینال دوم:

curl -sS http://localhost:8000/
echo "exit=$?"

curl: (7) Failed to connect to localhost port 8000 after 0 ms: Couldn't connect to server
exit=7

Couldn't connect to server در curl همان Connection refused است: کامپیوتر هست، برنامه‌ی سرور نیست. در مرورگر پیامی مثل «This site can’t be reached … refused to connect» می‌بینی.

⚡ بررسی سریع

مرورگر می‌گوید localhost refused to connect. محتمل‌ترین علت؟

جواب درست: برنامه‌ی سرور روی آن پورت در حال اجرا نیست

اگر سرور بود ولی فایل نبود، 404 می‌گرفتی؛ refused یعنی کسی روی پورت نیست.

مثال ۷: سرور پویا، جواب برای هر کس فرق می‌کند

http.server فقط فایل‌های ثابت را می‌دهد: همه همان index.html را می‌گیرند. سایت‌های واقعی جواب را می‌سازند: «سلام علی، سبد خریدت ۳ کالا دارد». یک سرور ۲۰ خطی پایتون که برای هر درخواست جواب تازه می‌سازد. فایل ~/hello_server.py (با nano یا هر ویرایشگری؛ پایتون را در دوره‌ی خودش یاد می‌گیری، فعلاً فقط بخوان و اجرا کن):

from http.server import BaseHTTPRequestHandler, HTTPServer
from datetime import datetime

visits = 0

class Hello(BaseHTTPRequestHandler):
    def do_GET(self):
        global visits
        visits += 1
        client_ip = self.client_address[0]
        now = datetime.now().strftime("%H:%M:%S")
        body = f"سلام {client_ip}! ساعت سرور {now} است. تو بازدیدکننده‌ی شماره‌ی {visits} هستی.\n"
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.end_headers()
        self.wfile.write(body.encode("utf-8"))

print("listening on http://127.0.0.1:8001 ...")
HTTPServer(("127.0.0.1", 8001), Hello).serve_forever()

python3 ~/hello_server.py

در ترمینال دیگر، چند بار:

curl -s http://127.0.0.1:8001/
curl -s http://127.0.0.1:8001/
curl -s http://127.0.0.1:8001/anything

سلام 127.0.0.1! ساعت سرور 00:24:18 است. تو بازدیدکننده‌ی شماره‌ی 1 هستی.
سلام 127.0.0.1! ساعت سرور 00:24:19 است. تو بازدیدکننده‌ی شماره‌ی 2 هستی.
سلام 127.0.0.1! ساعت سرور 00:24:19 است. تو بازدیدکننده‌ی شماره‌ی 3 هستی.

هر درخواست جواب متفاوت گرفت: سرور برای هر کدام تابع do_GET را اجرا کرد، شمارنده را یکی بالا برد و متن تازه ساخت. این کد سمت سرور (بک‌اند) است. چیزهای مهم:

شمارنده‌ی visits در RAM سرور است (درس کامپیوتر از چه ساخته شده). سرور را ببند و دوباره روشن کن: از ۱ شروع می‌شود. برای همین سایت‌های واقعی داده را در دیتابیس نگه می‌دارند (دوره‌ی SQL).
این سرور به هر مسیری (/anything) همان جواب را داد؛ سرورهای واقعی بر اساس مسیر تصمیم می‌گیرند چه کنند (دوره‌ی پایتون، درس API).
Content-Type به کلاینت می‌گوید جواب چه نوعی است و با چه encodingی بخواندش (درس متن و encoding): بدون charset=utf-8، مرورگر ممکن است فارسی را خراب نشان دهد.

پشت پرده: سرور در عمل چه می‌کند؟

برنامه‌ی سرور یک حلقه‌ی بی‌پایان است:

از سیستم‌عامل یک سوکت روی پورت (مثلاً ۸۰۰۰) می‌گیرد و گوش می‌دهد.
منتظر می‌ماند تا کلاینتی وصل شود (در این حالت تقریباً هیچ CPUای مصرف نمی‌کند؛ درس سیستم‌عامل).
اتصال را می‌پذیرد، درخواست را می‌خواند، پاسخ را می‌سازد و می‌فرستد.
برمی‌گردد به قدم ۲.

http.server پایتون هر درخواست را جدا انجام می‌دهد. وب‌سرورهای واقعی (nginx) هم‌زمان ده‌ها هزار اتصال را با چند پروسه مدیریت می‌کنند. ولی اساس همین حلقه است.

دو مدل دیگر هم هست که به آن‌ها برمی‌خوری:

همتا به همتا (P2P): هر طرف هم کلاینت است هم سرور؛ مثل تورنت، یا تماس‌های تصویری که مستقیم بین دو گوشی برقرار می‌شوند. سرور مرکزی فقط برای «پیدا کردن هم» است.
فرانت‌اند و بک‌اند: در یک سایت، فرانت‌اند کدی است که در مرورگر اجرا می‌شود (HTML، CSS، جاوااسکریپت؛ ظاهر و تعامل) و بک‌اند کدی است که روی سرور اجرا می‌شود (مثل hello_server.py؛ منطق، دیتابیس، امنیت). قانون طلایی: به هر چیزی که از کلاینت می‌آید اعتماد نکن؛ کاربر می‌تواند کد فرانت‌اند را عوض کند، ولی به کد بک‌اند دسترسی ندارد.

فرانت‌اند در دستگاه کاربر اجرا می‌شود و قابل‌دستکاری است؛ بک‌اند روی سرور است و تصمیم‌های مهم آن‌جا گرفته می‌شود.

جدول‌های مرجع

دستور	کار
`python3 -m http.server 8000`	سرو کردن پوشه‌ی فعلی روی همه‌ی آدرس‌ها
`python3 -m http.server 8000 --bind 127.0.0.1`	فقط برای همین کامپیوتر
`curl -s http://localhost:8000/`	گرفتن صفحه
`curl -s -o /dev/null -w "%{http_code}\n" URL`	فقط کد پاسخ
`Ctrl+C`	خاموش کردن سرور در ترمینال

در لاگ	معنی
IP اول خط	چه کسی درخواست داد
`"GET /path HTTP/1.1"`	چه چیزی خواست
`200` / `404`	پاسخ سرور: موفق / پیدا نشد

اشتباهات رایج

۱) بستن ترمینال سرور

سرور در همان ترمینال اجرا می‌شود؛ ترمینال را ببندی، سرور هم می‌میرد. راه‌حل: برای آزمایش یک ترمینال جدا برای سرور نگه دار. روی سرور واقعی، برنامه‌ها را سرویس می‌کنند تا همیشه اجرا شوند (دوره‌ی لینوکس، systemd).

۲) سرو کردن پوشه‌ی اشتباه

python3 -m http.server در پوشه‌ی خانه (~) یعنی همه‌ی فایل‌هایت در شبکه دیده می‌شوند. راه‌حل: همیشه اول cd به پوشه‌ی سایت، و در شبکه‌ی عمومی (کافه، دانشگاه) --bind 127.0.0.1.

۳) `http.server` به‌عنوان سایت واقعی

بدون HTTPS، بدون امنیت کافی، فقط یک درخواست در هر لحظه. راه‌حل: فقط برای آزمایش؛ برای سایت nginx (دوره‌ی nginx).

۴) پورت گرفته‌شده

OSError: [Errno 98] Address already in use

یک سرور دیگر (احتمالاً همان که در ترمینال دیگر فراموش کردی) روی آن پورت است. راه‌حل: آن را ببند، یا پورت دیگری بده (8001).

۵) اعتماد به داده‌ی کلاینت

قیمت محصول در فرم HTML نوشته شده و سرور همان را قبول می‌کند؛ کاربر قیمت را در مرورگر به ۱ تومان عوض می‌کند. راه‌حل: هر تصمیم مهم (قیمت، دسترسی) در بک‌اند، با داده‌ی خود سرور.

تمرین

تمرینآسان

در پوشه‌ی ~/site یک فایل about.html با یک تیتر ساده بساز، سرور را روشن کن و با curl فقط کد پاسخ about.html و contact.html (که وجود ندارد) را بگیر. در لاگ سرور هر کدام چه شکلی است؟

دیدن جواب

cd ~/site
echo "<h1>درباره‌ی ما</h1>" > about.html
python3 -m http.server 8000

در ترمینال دیگر:

curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/about.html
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000/contact.html

200
404

127.0.0.1 - - [22/Oct/2026 00:40:02] "GET /about.html HTTP/1.1" 200 -
127.0.0.1 - - [22/Oct/2026 00:40:02] code 404, message File not found
127.0.0.1 - - [22/Oct/2026 00:40:02] "GET /contact.html HTTP/1.1" 404 -

(ساعت‌ها برای تو فرق می‌کند.) هر درخواست یک خط، و برای ۴۰۴ یک خط توضیح اضافه.

تمرینمتوسط

hello_server.py را طوری عوض کن که اگر مسیر /time خواسته شد فقط ساعت را بدهد، و برای هر مسیر دیگر کد 404 با پیام «این صفحه نیست» برگرداند. (راهنما: مسیر درخواست در self.path است.)

دیدن جواب

    def do_GET(self):
        if self.path == "/time":
            status = 200
            body = datetime.now().strftime("%H:%M:%S") + "\n"
        else:
            status = 404
            body = "این صفحه نیست\n"
        self.send_response(status)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.end_headers()
        self.wfile.write(body.encode("utf-8"))

curl -s -w " [%{http_code}]\n" http://127.0.0.1:8001/time
curl -s -w " [%{http_code}]\n" http://127.0.0.1:8001/

00:42:10
 [200]
این صفحه نیست
 [404]

همین الگو (نگاه به مسیر، تصمیم، ساختن پاسخ با کد درست) قلب هر بک‌اند است. در دوره‌ی پایتون با کتابخانه‌ی Flask همین کار را تمیزتر و با JSON انجام می‌دهی. سرور را بعد از تغییر کد با Ctrl+C ببند و دوباره اجرا کن؛ پایتون کد جدید را فقط موقع شروع می‌خواند.

تمرینسخت

دو سرور هم‌زمان راه بینداز: http.server روی پورت ۸۰۰۰ برای ~/site و hello_server.py روی ۸۰۰۱. با یک حلقه‌ی bash به هر کدام ۵ درخواست بفرست و بعد با nc -zv ثابت کن هر دو باز هستند و پورت ۸۰۰۲ بسته است. یک سرور سوم با python3 -m http.server 8000 (پورت تکراری) چه خطایی می‌دهد؟

دیدن جواب

cd ~/site && python3 -m http.server 8000      # ترمینال ۱
python3 ~/hello_server.py                     # ترمینال ۲

ترمینال ۳:

for i in 1 2 3 4 5; do
    curl -s -o /dev/null -w "8000: %{http_code}\n" http://localhost:8000/
    curl -s http://127.0.0.1:8001/
done
nc -zv 127.0.0.1 8000; nc -zv 127.0.0.1 8001; nc -zv 127.0.0.1 8002
python3 -m http.server 8000

8000: 200
سلام 127.0.0.1! ساعت سرور 00:45:01 است. تو بازدیدکننده‌ی شماره‌ی 1 هستی.
...
8000: 200
سلام 127.0.0.1! ساعت سرور 00:45:01 است. تو بازدیدکننده‌ی شماره‌ی 5 هستی.
Connection to 127.0.0.1 8000 port [tcp/*] succeeded!
Connection to 127.0.0.1 8001 port [tcp/*] succeeded!
nc: connect to 127.0.0.1 port 8002 (tcp) failed: Connection refused
OSError: [Errno 98] Address already in use

یک کامپیوتر، یک IP، دو سرور مستقل روی دو پورت: همان «یک ساختمان، چند واحد» درس پورت. (for i in 1 2 3 4 5; do ... done دستورها را پنج بار تکرار می‌کند؛ دوره‌ی bash.) سرور سوم نمی‌تواند پورتی را بگیرد که مال دیگری است: Address already in use.

آزمونک

در مدل کلاینت و سرور، چه کسی ارتباط را شروع می‌کند؟
سرور در اصل چیست؟
در خط لاگ «127.0.0.1 - - [...] "GET /notes.txt HTTP/1.1" 200 -» عدد 200 یعنی…
برنامه‌ی فروشگاه که از PostgreSQL داده می‌گیرد، نسبت به دیتابیس چه نقشی دارد؟
چرا شمارنده‌ی hello_server.py بعد از ری‌استارت از ۱ شروع می‌شود؟
کدام باید در بک‌اند تصمیم گرفته شود؟

جمع‌بندی

سرور برنامه‌ای است که روی یک پورت گوش می‌دهد و پاسخ می‌دهد؛ کلاینت درخواست را شروع می‌کند.
یک برنامه می‌تواند هم‌زمان کلاینت و سرور باشد (برنامه‌ی فروشگاه: سرور برای مرورگر، کلاینت برای دیتابیس).
python3 -m http.server یک وب‌سرور آزمایشی در یک دستور؛ curl کلاینت خط فرمانی.
لاگ سرور برای هر درخواست: IP کلاینت، زمان، چه خواست، چه جواب گرفت.
سرور ثابت فایل می‌دهد؛ سرور پویا (بک‌اند) جواب را برای هر درخواست می‌سازد.
به داده‌ی کلاینت اعتماد نکن؛ تصمیم‌های مهم در بک‌اند.

برگه‌ی تقلب این درس

دستور	کاری که می‌کند
`python3 -m http.server 8000`	وب‌سرور آزمایشی
`... --bind 127.0.0.1`	فقط برای همین کامپیوتر
`curl -s http://localhost:8000/`	گرفتن صفحه
`curl -s -o /dev/null -w "%{http_code}\n" URL`	فقط کد پاسخ
`Ctrl+C`	خاموش کردن سرور
`Address already in use`	پورت گرفته شده
`Couldn't connect to server`	سرور روشن نیست
`http://IP-لپ‌تاپ:8000`	باز کردن از گوشی در همان شبکه

مسئله: «سرور» یعنی چه؟

تشبیه: رستوران

کلاینت و سرورهایی که همین الان می‌شناسی

مثال‌های عملی

مثال ۱: یک وب‌سرور در یک دستور

مثال ۲: کلاینت خط فرمانی، curl

مثال ۳: لاگ سرور، دفتر ثبت درخواست‌ها

مثال ۴: سرور، پوشه‌ها را هم نشان می‌دهد

مثال ۵: از گوشی باز کن

مثال ۶: سرور خاموش

مثال ۷: سرور پویا، جواب برای هر کس فرق می‌کند

پشت پرده: سرور در عمل چه می‌کند؟

جدول‌های مرجع

اشتباهات رایج

۱) بستن ترمینال سرور

۲) سرو کردن پوشه‌ی اشتباه

۳) http.server به‌عنوان سایت واقعی

۴) پورت گرفته‌شده

۵) اعتماد به داده‌ی کلاینت

تمرین

آزمونک

جمع‌بندی

مثال ۲: کلاینت خط فرمانی، `curl`

۳) `http.server` به‌عنوان سایت واقعی