Decyzja, czy używać prostych żądań HTTP, czy WebSockets

Question

Wdrażamy usługę, z której korzysta wielu użytkowników w tym samym czasie. W szczytach możemy mieć dziesiątki tysięcy ludzi online.

Krytyczna część naszej usługi wymaga reimplementacji, dlatego staramy się wymyślić nowe sposoby jej realizacji. W tej chwili mamy wysłać prostą i bardzo krótką małą prośbę HTTP/AJAX oparte na interakcji z użytkownikiem:

• Ping: Jestem nadal aktywny
• aktywny: Zrobiłem to i napisz go do bazy danych
• wykończenie: muszę skończyć działalność więc zamknę żądań

Jednocześnie, w niektórych przypadkach (1 z 10) mamy otwartą EventSource z której czytamy pewnych modyfikacji na serwerze.

Pytanie brzmi, czy ten model jest wystarczająco dobry, czy lepiej jest otworzyć WebSocket i przekazać wszystko za pośrednictwem WebSockets.

• Zaleta - dla każdego użytkownika utrzymywalibyśmy tylko jedno połączenie zamiast wysyłać wiele żądań.
• Wada - gdy wiele ludzi w Internecie, chcielibyśmy zachować tysiące połączeń aktywnych

Jaka powinna być decyzja o właściwej realizacji?

Zauważono, że to pytanie odpowiada na to samo: WebSockets protocol vs HTTP - jednak proszę o konkretny przypadek użycia. Powiązane pytanie jest ogólnie zadawane.

Answer 1

• Wada - gdy wiele osób na forum, chcielibyśmy zachować tysiące połączeń aktywnych

można zaimplementować usługę zamknąć bezczynne połączenie websocket po przekroczeniu limitu czasu. To pewnie tak samo działa EventSource, więc nie zachowujesz zbyt wielu aktywnych połączeń. (podobne właściwości użytkowe.)

(Ale jeśli powołując się na automatycznym ponownym z EventSource dostarczonych przez przeglądarkę, a następnie przejście do websocket oznacza, że ​​trzeba pisać więcej kodu na logice włączeniem.)

Typowo WebSocket powinien generować mniejszy ruch w sieci. Ale jak duża różnica zależy od tego, w jaki sposób twoja obecna usługa jest zaimplementowana. Jeśli już zoptymalizowałeś swoją logikę i wycisnąłeś każdą wydajność z AJAX i EventSource, użycie WebSocket może być marginalnym ulepszeniem.