Konfiguracja połączenia z Websocket

Question

Próbuję dowiedzieć się więcej o websocket i jego wewnętrznych implementacjach. Ale wciąż nie można zrozumieć kilku rzeczy. Próbowałem googling dla wyjaśnienia dogłębnego, ale większość z nich po prostu daje przegląd wysokiego poziomu. Oto moje wątpliwości

1. Według tego, co czytam, serwer websocket (C#/C++ realizacja) domyślnie używa portu 80. Chociaż można użyć dowolnego portu, to korzystne, możemy użyć portu 80 jako wygraliśmy nie mają żadnych problemów z firewallem. Jeśli tak, to w jaki sposób mamy uruchamiać serwer WWW i serwer gniazd internetowych na tym samym porcie (80)?

2. Załóżmy, że serwer websocket działa na porcie 81 i serwer sieciowy jest uruchomiony na porcie 80.

1. Więc gdy przeglądarka wysyła żądanie HTTP wstępnego uzgadniania (Upgrade: websocket) , ten wniosek wysłany do portu 81. Zgadza się? Jeśli tak, to żądanie (patrz poniżej) nie ma żadnego związku z protokołem HTTP. Ale nadal używamy nagłówków protokołu HTTP. Czemu?

    GET /mychat HTTP/1.1 
        Host: server.example.com 
        Upgrade: websocket 
        Connection: Upgrade 
        Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== 
        Sec-WebSocket-Protocol: chat 
        Sec-WebSocket-Version: 13 
        Origin: http://example.com 
   

2. Dlaczego nie odczuwało używają tego samego interfejsu websocket obecnie wdrażany w większości przeglądarce wydania bezpośrednie połączenie TCP/IP z danego portu, bez rzeczy HTTP?

3. Czy istnieje limit rozmiaru lub pakiet danych/limit bufor dla danych wysłanych/odebranych od klient/serwer? Jeśli tak jest, czy musimy sami tworzyć ramki danych i obsługiwać je?

Czy serwer websocket zawsze musi być oddzielną usługą/procesem? Czy w przyszłości serwer WWW (IIS, apache) będzie obsługiwał hostowanie serwerów gniazd sieci w obrębie przestrzeni procesowej?

Answer 1

1. Przy użyciu kompatybilnego handshake HTTP można zintegrować obsługi websocket na serwer lub po prostu z serwera WWW do przodu połączenia websocket do serwera dedykowanego websocket.

2. Uzgadnianie WebSocket wykorzystuje handshake kompatybilny z protokołem HTTP, aby umożliwić łatwe obsługiwanie obu protokołów na tym samym porcie i pozwala istniejącym konfiguracjom zapory znacznie łatwiej obsługiwać ruch WebSocket. Ponadto, zapobieganie krzyżowym atakom skryptów jest dobrze zrozumiałe w kontekście żądań HTTP, a zatem WebSocket wykorzystuje tę wiedzę. Nawet po ustanowieniu połączenia, WebSocket jest nie jest połączeniem z surowym gniazdem. Jest to protokół oparty na komunikatach i dlatego wymaga ramkowania. Ponadto ramka jest maskowana, gdy jest wysyłana z klienta (przeglądarki) do serwera, aby złagodzić obawy o teoretyczną lukę w niepoprawnie działających serwerach proxy/buforach/pośrednikach.

3. Nie ma ograniczenia rozmiaru wiadomości w samym protokole. Wiadomość może być podzielona na wiele ramek. Istnieje limit protokołu dla rozmiaru klatki, ale wynosi on 2^64 bajty. Rzeczywisty limit rozmiaru klatki będzie mniejszy w zależności od implementacji klient/serwer. Jeśli masz wiele megabajtów pojedynczych wiadomości, które chcesz wysłać, możesz rozważyć zmianę aplikacji na mniejszą wiadomość, aby zmaksymalizować obsługę różnych przeglądarek i serwerów.

4. Obsługa WebSocket może z pewnością zostać zintegrowana z serwerami sieciowymi i był to scenariusz przewidziany przez grupę roboczą.Na przykład rozważmy pywebsocket, który jest przeznaczony do uruchamiania zarówno samodzielnego, jak i mod_python modułu w Apache. Jako inny przykład, ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.