# ارائه: چت‌روم ساده با WebSocket

## اسلاید ۱ - عنوان پروژه

**چت‌روم ساده با WebSocket**

این پروژه برای درس مهندسی اینترنت آماده شده است و هدف آن نمایش ارتباط بلادرنگ بین مرورگر و سرور با استفاده از FastAPI و WebSocket است.

![معماری چت‌روم](docs/screenshots/home.png)

## اسلاید ۲ - چرا WebSocket به وجود آمد؟

وب در ابتدا بیشتر بر پایه مدل درخواست و پاسخ HTTP کار می‌کرد. مرورگر یک درخواست می‌فرستاد، سرور پاسخ می‌داد و ارتباط همان‌جا تمام می‌شد.

با پیچیده‌تر شدن برنامه‌های وب، نیاز به دریافت سریع اطلاعات جدید از سمت سرور بیشتر شد؛ مثلا پیام جدید در چت، اعلان‌ها یا وضعیت زنده یک سیستم.

قبل از WebSocket معمولا از روش‌هایی مثل polling و long polling استفاده می‌شد. این روش‌ها قابل استفاده بودند، اما باعث تکرار زیاد درخواست‌های HTTP و مصرف منابع بیشتر می‌شدند.

![تاریخچه WebSocket](docs/images/websocket-history.svg)

## اسلاید ۳ - تاریخچه کوتاه

- **HTTP کلاسیک:** برای دریافت صفحه و ارسال فرم مناسب بود، اما برای ارسال لحظه‌ای داده از سرور به مرورگر طراحی نشده بود.
- **AJAX و polling:** امکان درخواست‌های پس‌زمینه را فراهم کرد، ولی مرورگر همچنان باید مرتب از سرور سوال می‌پرسید.
- **Long polling:** تعداد درخواست‌های بی‌فایده را کمتر کرد، اما همچنان هر پیام جدید درگیر چرخه HTTP بود.
- **استاندارد WebSocket:** در RFC 6455 به عنوان یک پروتکل استاندارد برای ارتباط دوطرفه و پایدار معرفی شد.
- **کاربردهای امروز:** چت، بازی آنلاین، داشبورد زنده، ویرایش هم‌زمان، اعلان‌ها و کنترل تجهیزات IoT.

## اسلاید ۴ - WebSocket چگونه از HTTP شروع می‌شود؟

WebSocket از ابتدا یک ارتباط جدا از HTTP نیست. ارتباط با یک درخواست HTTP معمولی شروع می‌شود که از سرور می‌خواهد پروتکل را تغییر دهد.

مرورگر یک درخواست `GET` با سرآیندهایی شبیه این می‌فرستد:

```text
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: ...
```

اگر سرور درخواست را قبول کند، پاسخ زیر را برمی‌گرداند:

```text
101 Switching Protocols
```

بعد از این پاسخ، همان اتصال TCP دیگر مثل HTTP عادی استفاده نمی‌شود و داده‌ها در قالب فریم‌های WebSocket جابه‌جا می‌شوند.

![فرایند ارتقای HTTP](docs/images/websocket-handshake.svg)

## اسلاید ۵ - بعد از ارتقا چه اتفاقی می‌افتد؟

بعد از تبدیل ارتباط:

- مرورگر هر زمان بخواهد می‌تواند برای سرور پیام بفرستد.
- سرور هم هر زمان بخواهد می‌تواند برای مرورگر پیام بفرستد.
- ارتباط باز می‌ماند و برای هر پیام، درخواست HTTP جدید ساخته نمی‌شود.
- داده‌ها به صورت فریم WebSocket ارسال می‌شوند.

به همین دلیل به WebSocket ارتباط **دوطرفه کامل** گفته می‌شود.

## اسلاید ۶ - جایگاه WebSocket در مدل OSI

WebSocket معمولا در لایه کاربرد بررسی می‌شود، چون برنامه تصمیم می‌گیرد پیام‌ها چه معنایی دارند.

در یک ارتباط معمول بین مرورگر و سرور:

- برنامه از WebSocket برای ارسال و دریافت پیام استفاده می‌کند.
- شروع ارتباط با مفاهیم HTTP انجام می‌شود.
- انتقال قابل اعتماد داده‌ها بر عهده TCP است.
- IP بسته‌ها را بین میزبان‌ها مسیریابی می‌کند.
- Ethernet یا Wi-Fi داده را روی شبکه واقعی حمل می‌کند.

![جایگاه WebSocket در مدل OSI](docs/images/websocket-osi.svg)

## اسلاید ۷ - نگاه شبکه‌ای ساده

مسیر داده در این پروژه را می‌توان این‌طور ساده کرد:

```text
پیام چت در قالب JSON
فریم WebSocket
قطعه TCP
بسته IP
فریم شبکه
سیگنال فیزیکی
```

کد پروژه بیشتر در بالاترین بخش این زنجیره کار می‌کند. پیام JSON ساخته می‌شود، از طریق WebSocket فرستاده می‌شود و جزئیات انتقال در لایه‌های پایین‌تر توسط سیستم‌عامل و شبکه انجام می‌شود.

## اسلاید ۸ - معماری پروژه

این پروژه سه بخش اصلی دارد:

- **رابط مرورگر:** فایل‌های HTML، CSS و JavaScript.
- **مسیر WebSocket:** مسیر FastAPI با الگوی `/ws/{room_id}/{client_id}`.
- **مدیر اتصال‌ها:** نگهداری socketهای فعال به تفکیک اتاق.

وقتی یک کاربر پیام می‌فرستد، سرور پیام را از socket همان کاربر می‌گیرد و آن را برای همه socketهای همان اتاق پخش می‌کند.

![معماری پروژه](docs/images/chatroom-architecture.svg)

## اسلاید ۹ - جریان پیام در پروژه

1. کاربر نام و اتاق را وارد می‌کند.
2. JavaScript یک شیء `WebSocket` می‌سازد.
3. مرورگر درخواست HTTP Upgrade را ارسال می‌کند.
4. FastAPI اتصال WebSocket را قبول می‌کند.
5. مدیر اتصال، کاربر را در لیست اتاق ذخیره می‌کند.
6. پیام به صورت JSON از مرورگر به سرور فرستاده می‌شود.
7. سرور پیام را برای کاربران همان اتاق پخش می‌کند.
8. مرورگرها پیام جدید را بدون تازه‌سازی صفحه نمایش می‌دهند.

## اسلاید ۱۰ - مزایا و معایب

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

![مزایا و معایب WebSocket](docs/images/websocket-pros-cons.svg)

## اسلاید ۱۱ - مزایا

- تاخیر کم، چون ارتباط باز می‌ماند.
- امکان ارسال فوری داده از سمت سرور به مرورگر.
- مناسب برای چت، اعلان، ابزارهای همکاری، بازی و داشبورد زنده.
- کاهش سربار سرآیندهای تکراری HTTP بعد از دست‌دهی اولیه.
- مدل برنامه‌نویسی ساده برای ارتباط پیوسته و دوطرفه.

## اسلاید ۱۲ - معایب

- اتصال‌های طولانی‌مدت از منابع سرور استفاده می‌کنند.
- مقیاس‌پذیری روی چند سرور به طراحی بیشتر نیاز دارد.
- قطع اتصال، اتصال دوباره و خطاهای شبکه باید مدیریت شوند.
- بعضی پراکسی‌ها یا دیواره‌های آتش ممکن است تنظیم درست برای WebSocket بخواهند.
- برای صفحه‌های ساده CRUD معمولا لازم نیست.

## اسلاید ۱۳ - چرا پروژه ساده نگه داشته شده است؟

در این پروژه عمدا ثبت‌نام، پایگاه داده، احراز هویت، تاریخچه پیام‌ها و پیچیدگی‌های استقرار اضافه نشده‌اند.

هدف این است که رفتار اصلی WebSocket واضح دیده شود:

- باز شدن اتصال
- ورود به اتاق
- ارسال پیام
- پخش پیام برای کاربران اتاق
- بسته شدن اتصال

این سادگی پروژه را برای ارائه کلاسی مناسب‌تر می‌کند.

## اسلاید ۱۴ - برنامه اجرای دمو

1. سرور را با دستور `uvicorn app.main:app --reload` اجرا کنید.
2. برنامه را در دو تب مرورگر باز کنید.
3. در هر تب یک نام متفاوت وارد کنید.
4. هر دو کاربر وارد یک اتاق شوند.
5. از یک تب پیام ارسال کنید.
6. دریافت فوری پیام در تب دوم را نشان دهید.
7. یکی از کاربران را قطع کنید و تغییر فهرست کاربران آنلاین را نمایش دهید.

## اسلاید ۱۵ - جمع‌بندی

WebSocket مشکل ارتباط بلادرنگ در وب را با تبدیل یک اتصال HTTP به یک کانال پایدار و دوطرفه حل می‌کند.

در این چت‌روم، همین مفهوم با یک بخش سرور کوچک FastAPI و یک رابط فارسی ساده نمایش داده شده است.