پروژه مهندسی اینترنت

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

نمایش Socket Programming و ارتباط Real-time در وب

نمای صفحه چت‌روم
مسیر ارائه History → Polling → Handshake → OSI → Architecture → Demo
1
HandshakeHTTP Upgrade
2
ChannelPersistent TCP
3
FramesFull-duplex
4
BroadcastRoom delivery
History

چرا WebSocket لازم شد؟

مسیر تکامل از HTTP کلاسیک تا اتصال پایدار دوطرفه

تاریخچه WebSocket
HTTP
Request / Response
  • ساده
  • بدون Server Push
AJAX
Polling
  • درخواست تکراری
  • هزینه شبکه بیشتر
LONG
Long Polling
  • اتصال منتظر
  • پیچیدگی بیشتر
WS
WebSocket
  • اتصال پایدار
  • پیام دوطرفه
Resource Cost

هزینه هر روش برای سرور

هر روش، فشار متفاوتی روی Network، CPU، memory و socket دارد

Classic HTTP
  • درخواست جداگانه
  • پردازش header
  • پایان چرخه
Polling
  • درخواست زیاد
  • پاسخ‌های خالی
  • سربار Network
Long Polling
  • اتصال باز
  • نگهداری state
  • مصرف buffer
WebSocket
  • یک اتصال پایدار
  • فریم سبک
  • state فعال
Polling → درخواست تکراری · Long Polling → انتظار طولانی · WebSocket → کانال پایدار
HTTP Upgrade Handshake

WebSocket چطور شروع می‌شود؟

ابتدا HTTP، سپس پاسخ 101 و بعد WebSocket Frames

ClientBrowser
  • ساخت WebSocket
  • درخواست Upgrade
1. GET + Upgrade
2. 101 Switching Protocols
3. WebSocket Frames
ServerFastAPI
  • پذیرش Upgrade
  • نگهداری socket
HTTP Upgrade Handshake
GET /ws/general/ali HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
HTTP Versions

WebSocket در نسخه‌های HTTP

مدل آموزشی پروژه روی HTTP/1.1 Upgrade تمرکز دارد

HTTP/1.1Upgrade + 101
  • مدل کلاسیک
  • یک TCP connection
  • ساده برای آموزش
HTTP/2Extended CONNECT
  • روی یک stream
  • بدون Upgrade کلاسیک
  • پیچیده‌تر
HTTP/3QUIC + CONNECT
  • بدون TCP
  • روی QUIC
  • مدرن‌تر
HTTP/1.1: Upgrade → 101 → WebSocket Frames
OSI Model

جایگاه WebSocket در شبکه

WebSocket در لایه Application استفاده می‌شود؛ TCP/IP حمل داده را انجام می‌دهد

Layer 7WebSocket + JSON
Layer 6UTF-8 text
Layer 5Long-lived session
Layer 4TCP reliable stream
Layer 3IP routing
Layer 2/1Ethernet / Wi-Fi
AApplication
  • اتاق
  • کاربر
  • پیام
TTransport
  • TCP
  • تحویل قابل اعتماد
NNetwork
  • IP
  • مسیریابی
Project Architecture

معماری پروژه چت‌روم

هر تب مرورگر یک WebSocket connection دارد

Client ABrowser tab
Client BBrowser tab
FastAPI WebSocket Endpoint

/ws/{room}/{user}

ConnectionManager
Broadcast داخل همان room
Room: generalA · B · C
Room: classD · E
Browser UI FastAPI endpoint Room Manager Broadcast
Message Flow

جریان پیام در پروژه

از ورود کاربر تا نمایش پیام بدون refresh

1Joinname + room
2UpgradeHTTP → WebSocket
3SendJSON content
4Broadcastroom sockets
5Renderبدون refresh
نام و اتاق
WebSocket در JS
HTTP Upgrade
قبول در FastAPI
Room Manager
JSON message
Broadcast
نمایش پیام
Trade-offs

مزایا و محدودیت‌ها

WebSocket برای Real-time عالی است، اما state سرور را بیشتر می‌کند

Full-duplex
  • ارسال دوطرفه
  • بدون انتظار request بعدی
Low latency
  • تاخیر کم
  • فریم سبک‌تر
!Server state
  • socket باز
  • مدیریت disconnect
Chat Notifications Live dashboard Online game
Demo

برنامه اجرای دمو

دو تب، یک room، پیام Real-time

نمای دمو
  1. اجرای uvicorn app.main:app --reload
  2. باز کردن دو tab
  3. ورود دو user به یک room
  4. ارسال message
  5. نمایش بدون refresh
  6. تغییر online users
← → حرکت · N یادداشت · F تمام‌صفحه