Udostępnij przez

Protokół WebSocket i usługa Application Gateway dla kontenerów

Protokoły WebSocket ustanowione w RFC6455 umożliwiają dwukierunkową komunikację między klientem a serwerem. W przeciwieństwie do tradycyjnego żądania HTTP lub HTTPS, protokoły WebSocket umożliwiają przeglądarce nawiązanie połączenia i odbieranie ciągłych danych z serwera, bez konieczności ciągłego ściągania serwera zdalnego lub konieczności nawiązywania wielu połączeń w obu kierunkach (klient do serwera i serwera do klienta).

Korzyści z protokołu WebSocket

Protokół WebSocket ma kilka korzyści z tradycyjnych żądań HTTP, w tym:

  • Zgodność przeglądarki: prawie wszystkie nowoczesne przeglądarki obsługują WebSocket.
  • Dane w czasie rzeczywistym: zestawy WebSocket umożliwiają transfer danych w czasie rzeczywistym między klientem a serwerem.
  • Wydajność: WebSockety eliminują konieczność ciągłego sondowania serwerów w celu sprawdzania aktualizacji.
  • Zabezpieczenia: protokoły WebSocket można szyfrować przy użyciu protokołu TLS i używać standardowych portów HTTP, takich jak 80 i 443.
  • Elastyczność: zestawy WebSocket mogą być używane w różnych aplikacjach, takich jak czat, gry i platformy handlu finansowego.

Jak działa protokół WebSocket

Aby ustanowić połączenie protokołu WebSocket, określony uzgadnianie oparte na protokole HTTP jest wymieniane między klientem a serwerem. W przypadku powodzenia protokół warstwy aplikacji jest "uaktualniony" z protokołu HTTP do protokołu WebSockets przy użyciu wcześniej ustanowionego połączenia TCP. Gdy tak się stanie, protokół zostanie zmieniony na WebSockets i ruch nie będzie już przepływać za pośrednictwem protokołu HTTP. Dane są wysyłane lub odbierane przy użyciu protokołu WebSocket przez oba punkty końcowe do momentu zamknięcia połączenia protokołu WebSocket.

Diagram przedstawia klienta wchodzącego w interakcję z serwerem internetowym, łącząc się z protokołem HTTP, uaktualniając połączenie z protokołem WebSocket i kontynuując komunikację za pośrednictwem protokołu WebSocket.

Uwaga

Po uaktualnieniu połączenia do protokołu WebSocket jako serwer proxy pośredniczący/kończący, usługa Application Gateway dla kontenerów wyśle dane odebrane z frontendu do backendu i odwrotnie, bez możliwości inspekcji i manipulacji. W związku z tym wszelkie manipulacje, takie jak ponowne zapisywanie nagłówków, ponowne zapisywanie adresów URL lub zastępowanie nazwy hosta nie będą stosowane po nawiązaniu połączenia protokołu WebSocket.

Połączenia protokołu WebSocket mogą być w postaci zwykłego tekstu lub szyfrowane za pośrednictwem protokołu TLS. Po nawiązaniu połączenia za pośrednictwem zwykłego tekstu połączenie jest ustanawiane w formacie ws://< fqdn>/path. Po nawiązaniu połączenia za pośrednictwem protokołu TLS połączenie jest ustanawiane w formacie wss://< fqdn>/path.

Sondy kondycji

Do wykorzystania żądania WebSocket w usłudze Application Gateway for Containers nie jest potrzebna żadna konfiguracja, jednak należy zadbać o prawidłowe skonfigurowanie sond zdrowia, aby backend był uznawany za zdrowy.

Domyślnie usługa Application Gateway dla kontenerów próbuje zainicjować uzgadnianie HTTP na porcie zaplecza z uruchomioną usługą WebSocket. W wielu przypadkach błędnie oznacza to zaplecze jako w złej kondycji, dlatego należy zdefiniować zasady HealthCheckPolicy, aby upewnić się, że sonda kondycji uwzględnia użycie sondy TCP.

Oto przykład polityki HealthCheckPolicy dla zaplecza WebSocket.

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
  name: websockets-health-check-policy
  namespace: test-infra
spec:
  targetRef:
    group: ""
    kind: Service
    name: websockets-backend
    namespace: test-infra
  default:
    interval: 5s
    timeout: 3s
    healthyThreshold: 1
    unhealthyThreshold: 1
    http:
      path: /health 
EOF

Uwaga

WebSockety są obsługiwane tylko przy korzystaniu z API Gateway dla Application Gateway dla kontenerów.

Metryki i monitorowanie

Dzienniki diagnostyczne:

Połączenia protokołu WebSocket działają przy użyciu odrębnego protokołu. Po zainicjowaniu połączenia przeglądarka otrzymuje kod stanu HTTP 101 wskazujący przejście z protokołu HTTP do protokołu WebSocket i zostanie odzwierciedlone w dzienniku dostępu.

Szczegóły połączenia protokołu WebSocket są rejestrowane tylko wtedy, gdy połączenie zostanie zamknięte. Pozwala to na dokładne pomiary czasu trwania każdego połączenia.

Następne kroki

Dowiedz się więcej o WebSockets i Gateway API

  • Last updated on