실시간성을 보장하는 컴퓨터 통신 프로토콜로, 서버와 브라우저 간 연결을 유지한 상태로 양방향 소통이 가능함
HTTP에서도 Polling, Long Polling, Streaming 등 실시간성을 보장하는 기법이 존재함
하지만 실시간성을 보장하는 데 있어서 HTTP보다 웹 소켓의 장점이 더 큼
HTTP는 클라이언트가 연결 요청을 보낼 때마다 연결을 하고 끊기 때문에 매번 연결을 맺고 끊는 과정의 비용이 큼
하지만 웹 소켓은 한번 연결을 맺고 나면 서버나 브라우저가 연결 중지 요청을 보내기 전까지 연결을 유지함
HTTP의 통신은 요청-응답 구조로 원하는 응답을 얻기 위해서는 항상 요청을 해야함
하지만 웹 소켓은 연결이 계속 유지된 상태이기 때문에 요청을 하지 않아도 상대방의 메시지를 받을 수 있음
ex) HTTP - 탁구, 웹 소켓 - 전화
HTTP 프로토콜은 통신을 할 때마다 많은 양의 정보가 이동함
하지만 웹 소켓은 처음에만 HTTP 통신과 유사한 양의 정보를 주고받고, 연결이 수립되고 나면 적은 양의 메시지를 주고받을 수 있기 때문에 실시간 서비스에서 통신에 오가는 비용을 줄일 수 있음

많은 환경에서 웹 소켓을 지원하지만, 브라우저 구버전 등에서는 모두 지원하지는 않음
=> 웹소켓을 지원하지 않는 브라우저에서도 웹 소켓을 사용하는 것과 같은 비슷한 기능을 제공하는 라이브러리를 사용 ex) SokJs, Socket.io
Stomp(Simple Text Oriented Messaging Protocol): 메시징 전송을 효율적으로 하기 위한 프로토콜
: 메세지를 공급하는 주체와 소비하는 주체를 분리하여 제공하는 stomp의 메시징 방법
사용자 클라이언트들이 서버와 웹소켓으로 연결되어 있고 구독 주소가 같을 때 메시지를 해당 구독 주소로 보내면 그 서버를 구독하고 있는 모든 사용자 클라이언트들에게 메시지를 보내게 됨
구독 주소가 다르면 메시지를 받을 수 없음
이때 메시지 발송자도 주소를 구독하고 있으므로 자신이 보낸 메시지를 받음 -> 구독(sub)와 발행(pub)를 동시에