مقاله جالبیه در مورد انواع روش های ارتباط real-time و مزایا و معایب هر کدوم از جنبه های مختلف

https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html

@gocasts

#websocket

@Syntax_fa

چند نکته درباره وب سوکت و توضیح ساده برای درک بهتر

فرآیند ارتباط وب‌سوکت

1. شروع با HTTP/HTTPS:
- کلاینت ابتدا یک درخواست HTTP به سرور می‌فرستد. این درخواست شامل هدرهای خاصی است که نشان‌دهنده تمایل به ارتقاء ارتباط به وب‌سوکت است. این هدرها شامل موارد زیر هستند:
- Upgrade: websocket
- Connection: Upgrade

2. ارتقاء به وب‌سوکت:
- سرور درخواست را دریافت کرده و بررسی می‌کند. اگر شرایط درست باشد، با یک پاسخ خاص به کلاینت، ارتباط را به وب‌سوکت ارتقاء می‌دهد. این پاسخ شامل وضعیت 101 Switching Protocols است.

3. استفاده از ws:// و wss://:
- پس از ارتقاء، ارتباط به‌صورت دائمی و دوطرفه برقرار می‌شود.
- ws://
نشان‌دهنده استفاده از پروتکل وب‌سوکت بر روی HTTP است.
- wss://
نشان‌دهنده استفاده از پروتکل وب‌سوکت بر روی HTTPS است (که رمزنگاری شده است).

چرا ws:// استفاده می‌شود؟

- ws://localhost:8080
- این URL نشان می‌دهد که ارتباط نهایی به‌صورت وب‌سوکت انجام می‌شود.

نکته:
در HTTP/2، مکانیزم آپگرید به وب‌سوکت از طریق هدرهای HTTP/1.1 استفاده نمی‌شود. HTTP/2 به صورت ذاتی از این روش پشتیبانی نمی‌کند. برای ارتباط وب‌سوکت در HTTP/2، معمولاً از HTTP/1.1 برای ایجاد و ارتقاء ارتباط استفاده می‌شود یا از روش‌های دیگری برای مدیریت ارتباطات بلادرنگ بهره می‌گیرند.

روش‌های دیگه برای مدیریت ارتباطات بلادرنگ:
1. Server-Sent Events (SSE):
- یک ارتباط یک‌طرفه است که سرور می‌تواند به‌طور پیوسته داده‌ها را به کلاینت ارسال کند.
- مناسب برای برنامه‌هایی که نیاز به ارسال داده‌های بلادرنگ از سرور به کلاینت دارند.

2. Long Polling:
- کلاینت یک درخواست HTTP ارسال می‌کند و سرور تا زمانی که داده‌ای برای ارسال وجود ندارد، پاسخ را معلق نگه می‌دارد(یک تایم اوت مشخص هم دارد مثلا 20 ثانیه)
- پس از ارسال داده، کلاینت بلافاصله یک درخواست جدید ارسال می‌کند.

3. HTTP/2 Streams:
- استفاده از قابلیت چندپخشی و استریم‌های همزمان در HTTP/2 برای ارسال و دریافت داده‌های بلادرنگ.

4. gRPC:
- یک فریم‌ورک RPC بر پایه HTTP/2 که از ارتباطات بلادرنگ و استریمینگ پشتیبانی می‌کند.


چرا نیاز به درخواست HTTP اولیه است؟

وب‌سوکت‌ها به‌عنوان یک پروتکل ارتقاء بر روی HTTP طراحی شده‌اند تا با زیرساخت‌های موجود وب سازگار باشند. این امر به کلاینت‌ها و سرورها اجازه می‌دهد تا از همان پورت‌ها و مکانیزم‌های امنیتی استفاده کنند.

مثال در گولنگ:

package main

import (
"fmt"
"net/http"
"github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
  CheckOrigin: func(r *http.Request) bool {
    // checking conditions
    return true
  },
}

func handleConnections(w http.ResponseWriter, r *http.Request) {
  // upgrade http request to websocket
  ws, err := upgrader.Upgrade(w, r, nil)
  if err != nil {
    fmt.Println(err)
    return
  }
  defer ws.Close()

  // messages
  for {
    messageType, msg, err := ws.ReadMessage()
    if err != nil {
      fmt.Println(err)
      break
    }
    fmt.Printf("Received: %s\n", msg)

    err = ws.WriteMessage(messageType, msg)
    if err != nil {
      fmt.Println(err)
      break
    }
  }
}

func main() {
  http.HandleFunc("/", handleConnections)
  fmt.Println("Server started on :8080")
  err := http.ListenAndServe(":8080", nil)
  if err != nil {
    fmt.Println("Error starting server:", err)
  }
}

#websocket

@Syntax_fa