Socket Communitcation Reference

📚 HTTP vs WebSocket

• In HTTP and REST, an application is modeled as many URLs. To interact with the application, clients access those URLs, request-response style. Servers route requests to the appropriate handler based on the HTTP URL, method, and headers.
• By contrast, in WebSockets, there is usually only one URL for the initial connect. Subsequently, all application messages flow on that same TCP connection. This points to an entirely different asynchronous, event-driven, messaging architecture.
• WebSocket is also a low-level transport protocol, which, unlike HTTP, does not prescribe any semantics to the content of messages. That means that there is no way to route or process a message unless the client and the server agree on message semantics.
• WebSocket clients and servers can negotiate the use of a higher-level, messaging protocol (for example, STOMP), through the Sec-WebSocket-Protocol header on the HTTP handshake request. In the absence of that, they need to come up with their own conventions.

📚 HTTP Protocol Architecture(Request - Response)

📚 WebSocket Architecture

• 클라이언트와 서버 간 실시간 양방향 통신을 가능케 하는 통신 프로토콜
• 클라이언트 → 서버로의 아니라 클라이언트의 Request없이도 서버 → 클라이언트로 실시간 전송이 가능
• HTTP 통신이 아니기 때문에 ws://의 url을 가진 웹 소켓 전용 프로토콜을 사용
• STOMP 메시지 프레임워크를 사용할 때 내부적으로 ws:// 프로토콜을 사용

📚 Long Polling vs WebSocket vs SSE

WebSocket과 Long Polling

• Polling
  • 클라이언트가 서버에 주기적으로 요청을 보내 변경 사항이 있는가를 확인하는 방식
  • HTTP 요청만 처리하면 되기 때문에 추가 설정이 필요없다.
  • 허나 반대로 말하면 변경 사항이 없는데 계속 Request를 보낼 수 있기 때문에 서버 리소스가 낭비될 수 있다.
• WebSocket
  • 클라이언트와 서버 간 지속적인 연결 유지
  • 무거운 HTTP 메시지가 필요없이 직접 메시지를 주고 받기에 서버 부하 측면에서 HTTP에 비하면 우수
• SSE(Server Sent Events)
  • HTTP기반의 클라이언트와 서버 간 실시간 단방향 통신을 가능케하는 웹 기술
  • SSE 프로토콜을 사용한 통신방향이 서버 → 클라이언트로의 단방향 통신
  • 실시간 업데이트가 필요한 곳에서 사용(주로 알림)