Loading...
Spring Framework Reference Documentation 7.0.2의 WebSockets의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
See equivalent in the Reactive stack
이 참고 문서의 이 부분은 Servlet 스택, WebSocket 메시징에 대한 지원을 다루며, 여기에는 raw WebSocket 상호 작용, SockJS를 통한 WebSocket 에뮬레이션, 그리고 WebSocket 위의 서브 프로토콜로서 STOMP를 통한 퍼블리시-서브스크라이브 메시징이 포함됩니다.
WebSocket 프로토콜, RFC 6455는 클라이언트와 서버 사이에 단일 TCP 커넥션을 통해 풀 듀플렉스, 양방향 통신 채널을 설정하는 표준화된 방법을 제공합니다. 이것은 HTTP와는 다른 TCP 프로토콜이지만, 포트 80과 443을 사용하고 기존 방화벽 규칙을 재사용할 수 있도록 HTTP 위에서 동작하도록 설계되었습니다.
WebSocket 상호 작용은 WebSocket 프로토콜로 업그레이드하거나, 이 경우 전환하기 위해 HTTP Upgrade 헤더를 사용하는 HTTP 요청으로 시작합니다. 다음 예제는 이러한 상호 작용을 보여줍니다:
1GET /spring-websocket-portfolio/portfolio HTTP/1.1 2Host: localhost:8080 3Upgrade: websocket (1) 4Connection: Upgrade (2) 5Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg== 6Sec-WebSocket-Protocol: v10.stomp, v11.stomp 7Sec-WebSocket-Version: 13 8Origin: http://localhost:8080
| 번호 | 설명 |
|---|---|
| 1 | Upgrade 헤더입니다. |
| 2 | Upgrade 커넥션을 사용합니다. |
일반적인 200 상태 코드 대신, WebSocket 지원이 있는 서버는 다음과 유사한 출력을 반환합니다:
1HTTP/1.1 101 Switching Protocols (1) 2Upgrade: websocket 3Connection: Upgrade 4Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0= 5Sec-WebSocket-Protocol: v10.stomp
| 번호 | 설명 |
|---|---|
| 1 | 프로토콜 전환 |
성공적인 핸드셰이크 이후에는, HTTP 업그레이드 요청의 기반이 되는 TCP 소켓이 열린 상태로 유지되어 클라이언트와 서버가 계속해서 메시지를 보내고 받을 수 있습니다.
WebSocket이 어떻게 동작하는지에 대한 완전한 소개는 이 문서의 범위를 벗어납니다. RFC 6455, HTML5의 WebSocket 장 또는 웹에 있는 많은 소개와 튜토리얼을 참고하십시오.
WebSocket 서버가 웹 서버(예를 들어, nginx) 뒤에서 동작하는 경우, WebSocket 업그레이드 요청을 WebSocket 서버로 전달하도록 웹 서버를 설정해야 할 수 있습니다. 마찬가지로, 애플리케이션이 클라우드 환경에서 동작하는 경우, WebSocket 지원과 관련된 클라우드 제공자의 안내를 확인하십시오.
WebSocket은 HTTP와 호환되도록 설계되었고 HTTP 요청으로 시작하지만, 두 프로토콜은 매우 다른 아키텍처와 애플리케이션 프로그래밍 모델로 이어진다는 점을 이해하는 것이 중요합니다.
HTTP와 REST에서는 애플리케이션이 많은 URL로 모델링됩니다. 애플리케이션과 상호 작용하기 위해 클라이언트는 이러한 URL에 요청-응답 방식으로 접근합니다. 서버는 HTTP URL, 메서드, 헤더에 따라 요청을 적절한 핸들러로 라우팅합니다.
반대로 WebSocket에서는 일반적으로 초기 연결을 위한 URL이 하나만 있습니다. 이후에는 모든 애플리케이션 메시지가 동일한 TCP 커넥션을 통해 흐릅니다. 이는 완전히 다른 비동기, 이벤트 기반, 메시징 아키텍처를 가리킵니다.
WebSocket은 또한 로우 레벨 전송 프로토콜로서, HTTP와는 달리 메시지 내용에 대해 어떤 시맨틱도 규정하지 않습니다. 이는 클라이언트와 서버가 메시지 시맨틱에 합의하지 않는 한 메시지를 라우팅하거나 처리할 방법이 없다는 것을 의미합니다.
WebSocket 클라이언트와 서버는 HTTP 핸드셰이크 요청의 Sec-WebSocket-Protocol 헤더를 통해 (예를 들어, STOMP와 같은) 상위 수준 메시징 프로토콜의 사용을 협상할 수 있습니다. 그것이 없는 경우, 그들은 자체적인 컨벤션을 만들어야 합니다.
WebSocket은 웹 페이지를 동적이고 인터랙티브하게 만들 수 있습니다. 그러나 많은 경우, AJAX와 HTTP 스트리밍 또는 롱 폴링의 조합이 간단하고 효과적인 솔루션을 제공할 수 있습니다.
예를 들어, 뉴스, 메일, 소셜 피드는 동적으로 업데이트될 필요가 있지만, 몇 분마다 한 번씩 그렇게 해도 전혀 문제가 없을 수 있습니다. 반면에 협업, 게임, 금융 앱은 훨씬 더 실시간에 가까워야 합니다.
지연 시간만으로는 결정 요인이 되지 않습니다. 메시지 볼륨이 상대적으로 낮은 경우(예를 들어, 네트워크 장애 모니터링) HTTP 스트리밍 또는 폴링이 효과적인 솔루션을 제공할 수 있습니다. 낮은 지연 시간, 높은 빈도, 높은 볼륨의 조합이 WebSocket 사용에 가장 적합한 경우를 만듭니다.
또한 인터넷 상에서는 여러분의 통제 밖에 있는 제한적인 프록시가 Upgrade 헤더를 전달하도록 설정되지 않았거나 유휴 상태로 보이는 장기 커넥션을 종료하기 때문에 WebSocket 상호 작용을 방해할 수 있다는 점을 염두에 두십시오. 이는 방화벽 내부의 내부 애플리케이션에 WebSocket을 사용하는 것이 공개용 애플리케이션에 사용하는 것보다 더 단순한 결정이라는 것을 의미합니다.
Testing
WebSocket API
