Projektowanie/architektura: gniazdo sieciowe jedno połączenie a wiele połączeń

Question

Czy podczas projektowania architektury klient/serwer istnieje korzyść dla multipleksowania wielu połączeń WEBSOCKET z tego samego procesu do serwera (np. Dzielenie jednego połączenia) z otwarciem jednego połączenia Połączenie WEBSOCKET na wątek/sesję w kliencie (jak zwykle robi się przy łączeniu z serwerami memcached lub bazy danych).

Jestem świadomy obciążenia związanego z każdym połączeniem (np. RAM ...). Ale spodziewaj się mieć mniej niż 1K-10K co najwyżej po każdej stronie klienta.

---

Szczególny przypadek użycia: Załóżmy, mam zdalny serwer z wielu sesji na jednej stronie, a po drugiej stronie mam wielu klientów, każdy klient będzie podłączyć do innej sesji przez serwer websocket. Na zdalnym serwerze istnieją 2 sposoby jego implementacji: (1) każda sesja tworzy własne połączenie websocket (2) wszystkie sesje będą korzystały z tego samego połączenia websocket.

Z punktu widzenia połączenia, podoba mi się rozwiązanie do dzielenia się (jedno połączenie sieciowe do wszystkich sesji), ponieważ serwer websocket jest ograniczony przez # dostępnych połączeń (zapisywanie serwerów/skalowanie).

Jednak z punktu widzenia ruchu/prędkości danych/wydajności, jeśli sesje wyślą wiele małych pakietów przez połączenie, wtedy, jeśli używamy jednego połączenia udostępniania, nie będziemy w stanie wykorzystać przepustowości (ładunek. .../zbierz kilka małych pakietów w jeden lub podziel duży pakiet na małe pakiety), ponieważ może być konieczne wysyłanie różnych pakietów do różnych klientów z różnych sesji, w tym przypadku nie będziemy w stanie zebrać kilku pakietów (małe pakiety), ponieważ mają inny cel i pochodzą z różnych źródeł !!, chyba że stworzymy "połączenie wirtualne", które zarządza danymi każdej sesji, aby zmaksymalizować prędkość, ale to spowodowałoby dużą złożoność implementacji !!!

Jakieś inne opinie?

Dzięki, JB.

Answer 1

Myślę, że powinieneś rozważyć użycie ograniczonej puli połączeń, tak jak w architekturze połączeń z bazą danych.

Innym rozwiązaniem, które chciałbym rozważyć, jest pośrednik baz danych Pub/Sub, taki jak Redis. Umożliwia to korzystanie z istniejących rozwiązań, a także łatwiejszą skalowalność.

Według mojego najlepszego zrozumienia, zarówno posiadanie pojedynczego połączenia, jak i używanie wielu połączeń ma swoje problemy.

Na przykład jedno połączenie może wysyłać tylko jedną wiadomość na raz. Wystarczająco duża wiadomość może zablokować połączenie ... czy przenosisz duże ilości danych?

Wiele połączeń może spowodować obciążenie, które może być bardzo kosztowne, a także zwiększyć szanse na błędy. Rozważmy następujący:

1. Tworzenie nowych połączeń jest bardzo drogie, wykorzystuje przepustowość, cierpi z powodu dłuższych opóźnień sieciowych i wymaga lokalnych zasobów i to jest dokładnie to, co WebSockets pozwala nam uniknąć.

2. Wystąpią problemy z skalowalnością. Na przykład Heroku ogranicza liczbę połączeń websocket do 600 na serwer, a przynajmniej tak szybko to zrobili (i myślę, że to rozsądne) ... Jak połączyć wszystkie serwery ze sobą w jeden magazyn danych?

3. Pamiętaj, że każdy system operacyjny ma otwarty limit plików, a strony internetowe korzystają z architektury IO (każda z nich jest "otwartym plikiem", więc zasoby sieciowe są ograniczonym zasobem).

Odnośnie prędkości ruchu/danych/wydajność, to jest kwestia architektury serwera ... ale wierzę, że będzie rzeczywiście zobaczyć niewielki wzrost prędkości za pomocą jednego połączenia (lub niewielką pulę połączeń). Należy pamiętać, że nie ma skutecznego wielozadaniowości, gdy trzeba wysyłać pakiety TCP/IP.

Ponadto, z ograniczoną liczbą połączeń (nawet z jednym połączeniem), będziesz mógł skorzystać z funkcji łączenia pakietów OS, która pozwoli Ci wysłać kilka ramek websocket przez jeden pakiet TCP/IP (chyba że ciągle opróżniasz gniazdo TCP/IP). W rzeczywistości marnujesz więcej przepustowości dzięki większej liczbie połączeń - nawet bez względu na przepustowość używaną do otwierania każdego nowego połączenia.

Tylko moje 5 centów, wszyscy będziemy myśleć inaczej, jestem pewien.

Powodzenia!