Jaka jest różnica między protokołami WebSocket i STOMP?

Jakie są główne różnice między protokołami WebSocket i STOMP?

To pytanie jest podobne do pytania o różnicę między protokołem TCP i HTTP. Wciąż spróbuję odpowiedzieć na twoje pytanie, jeśli zaczynasz, to naturalne, że pomieszam te dwa terminy.

Krótka odpowiedź

STOMP wywodzi się z WebSockets. Firma STOMP wspomina tylko o kilku konkretnych sposobach wymiany ramek komunikatów między klientem a serwerem za pomocą protokołu WebSockets.

Długa odpowiedź

WebSockets

Jest to specyfikacja umożliwiająca synchroniczną dwukierunkową komunikację między klientem a serwerem. Chociaż jest podobny do gniazd TCP, jest to protokół, który działa jako ulepszone połączenie HTTP, wymieniając ramki o zmiennej długości między dwiema stronami, zamiast strumienia.

TUPAĆ

Definiuje protokół dla klientów i serwerów do komunikacji z semantyką przesyłania wiadomości. Nie definiuje żadnych szczegółów implementacji, ale raczej odnosi się do łatwego do wdrożenia protokołu przewodowego do integracji wiadomości. Zapewnia wyższą semantykę oprócz protokołu WebSockets i definiuje kilka typów ramek, które są mapowane na ramki WebSockets. Niektóre z tych typów to ...

• połączyć
• Subskrybuj
• wypisz się
• wyślij (wiadomości wysyłane na serwer)
• wiadomość (dla wiadomości wysyłanych z serwera) BEGIN, COMMIT, ROLLBACK (zarządzanie transakcjami)

WebSocket sugeruje architekturę obsługi wiadomości, ale nie nakazuje używania żadnego określonego protokołu przesyłania wiadomości. Jest to bardzo cienka warstwa w protokole TCP, która przekształca strumień bajtów w strumień wiadomości (tekstowych lub binarnych) i niewiele więcej. Interpretacja znaczenia wiadomości zależy od aplikacji.

W przeciwieństwie do HTTP, który jest protokołem na poziomie aplikacji, w protokole WebSocket po prostu nie ma wystarczającej ilości informacji w wiadomości przychodzącej, aby struktura lub kontener wiedział, jak je przekierować lub przetworzyć. Dlatego WebSocket jest prawdopodobnie zbyt niskim poziomem dla czegokolwiek innego niż bardzo banalna aplikacja. Można to zrobić, ale prawdopodobnie doprowadzi to do stworzenia struktury na górze. Jest to porównywalne z tym, jak większość dzisiejszych aplikacji internetowych jest napisanych przy użyciu frameworka internetowego, a nie samego interfejsu Servlet API.

Z tego powodu WebSocket RFC definiuje użycie podprotokołów. Podczas uzgadniania klient i serwer mogą użyć nagłówka Sec-WebSocket-Protocol w celu uzgodnienia protokołu podrzędnego, tj. Protokołu wyższego poziomu aplikacji do użycia. Użycie protokołu podrzędnego nie jest wymagane, ale nawet jeśli nie jest używany, aplikacje nadal będą musiały wybrać format wiadomości zrozumiały zarówno dla klienta, jak i serwera. Ten format może być niestandardowy, specyficzny dla platformy lub standardowy protokół przesyłania wiadomości.

STOMP  - prosty protokół przesyłania wiadomości pierwotnie stworzony do użytku w językach skryptowych z ramkami inspirowanymi HTTP. STOMP jest szeroko obsługiwany i dobrze przystosowany do użytku przez WebSocket i przez Internet.

Interfejs API WebSocket umożliwia aplikacjom internetowym obsługę komunikacji dwukierunkowej, podczas gdy STOMP jest prostym protokołem przesyłania wiadomości tekstowych.

Protokół STOMP jest powszechnie używany wewnątrz gniazda sieciowego, gdy aplikacja internetowa musi obsługiwać dwukierunkową komunikację z serwerem WWW.

Dobry tutorial to STOMP Over WebSocket autorstwa Jeffa Mesnilla (2012)

STOMP może być również używany bez websocket, np. Przez połączenie Telnet lub usługę brokera wiadomości.

Z Raw WebSockets można korzystać bez STOMP - np. Przykład Spring Boot + WebSocket bez STOMP i SockJs .