RESTful HTTP 대신 Websocket을 사용하면 어떤 함정이 있습니까?

RESTful HTTP 대신 Websocket을 사용하면 어떤 함정이 있습니까?

---

저는 현재 클라이언트가 큰 일을 요청하고 서버로 보내는 프로젝트를 진행 중입니다. 그런 다음 서버는 작업을 분할하고 클라이언트가 GET 호출을 수행하고 데이터를 스트림 백하도록 URL 배열로 응답합니다. 저는 프로젝트의 미숙 한 사람이며 현재 효율성을 높이기 위해 Spring 웹 소켓을 사용하고 있습니다. 클라이언트가 계속해서 서버를 핑하여 결과를 스트리밍 할 준비가되었는지 확인하는 대신 웹 소켓은 이제 클라이언트에게 직접 연락합니다 만세!

웹 소켓이 전체 프로세스를 처음부터 끝까지 관리하도록하는 것이 나쁜 생각일까요? Spring 웹 소켓과 함께 STOMP를 사용하고 있는데 REST를 버리는 데 여전히 중요한 문제가 있습니까?

---

RESTful HTTP를 사용 하면 클라이언트가 요청을 보내고 서버가 응답을 반환 하는 상태 비 저장 요청 / 응답 시스템 이 있습니다.

webSocket을 사용하면 메시지를 어느 방향 으로든 보낼 수 있고 지정된 메시지를 보내는 것이 RESTful HTTP 요청 / 응답보다 오버 헤드가 적은 상태 저장 (또는 잠재적으로 상태 저장) 메시지 전달 시스템이 있습니다 .

두 가지는 서로 다른 강점을 가진 상당히 다른 구조입니다.

연결된 webSocket의 주요 이점은 다음과 같습니다.

1. 양방향 커뮤니케이션. 따라서 서버는 언제든지 클라이언트에게 알릴 수 있습니다. 따라서 새로운 것이 있는지 확인하기 위해 일정한 간격으로 서버를 폴링하는 대신 클라이언트는 webSocket을 설정하고 서버에서 오는 모든 메시지를 수신 할 수 있습니다. 서버의 관점에서 클라이언트에 관심있는 이벤트가 발생하면 서버는 단순히 클라이언트에 메시지를 보냅니다. 서버는 일반 HTTP로이를 수행 할 수 없습니다.

2. 메시지 당 오버 헤드를 줄입니다.클라이언트와 서버간에 많은 트래픽이 이동할 것으로 예상되는 경우 webSocket을 사용하면 메시지 당 오버 헤드가 낮아집니다. 이것은 TCP 연결이 이미 설정되어 있고 이미 열려있는 소켓에 메시지를 보내야하기 때문입니다. HTTP REST 요청을 사용하면 먼저 클라이언트와 서버간에 여러 번의 TCP 연결을 설정해야합니다. 그런 다음 HTTP 요청을 보내고 응답을 받고 TCP 연결을 닫습니다. HTTP 요청에는 특정 요청과 관련이 없더라도 해당 서버와 정렬 된 모든 쿠키와 같은 일부 오버 헤드가 반드시 포함됩니다. HTTP / 2 (최신 HTTP 사양)는 단일 TCP 연결이 단일 요청 / 응답 이상에 사용될 수 있기 때문에 클라이언트와 서버 모두에서 사용되는 경우 이와 관련하여 약간의 추가 효율성을 허용합니다.

3. 일부 상황에서 더 높은 규모. 메시지 당 오버 헤드가 낮고 새로운 것이 있는지 확인하기위한 클라이언트 폴링이 없기 때문에 확장 성이 추가 될 수 있습니다 (주어진 서버가 제공 할 수있는 클라이언트 수가 더 많음). webSocket 확장성에도 단점이 있습니다 (아래 참조).

4. 상태 저장 연결. 쿠키 및 세션 ID에 의존하지 않고 주어진 연결에 대한 상태를 프로그램에 직접 저장할 수 있습니다. 대부분의 문제를 해결하기 위해 상태 비 저장 연결로 많은 개발이 수행되었지만 때로는 상태 저장 연결로 더 간단합니다.

RESTful HTTP 요청 / 응답의 주요 이점은 다음과 같습니다.

1. 보편적 인 지원. HTTP보다 보편적으로 지원되는 것은 어렵습니다. webSockets는 현재 비교적 좋은 지원을 받고 있지만 webSocket 지원이 정기적으로 제공되지 않는 상황이 여전히 있습니다.

2. 더 많은 서버 환경과 호환됩니다. 오래 실행되는 서버 프로세스를 허용하지 않는 서버 환경이 있습니다 (일부 공유 호스팅 상황). 이러한 환경은 HTTP 요청을 지원할 수 있지만 장기 실행 webSocket 연결은 지원할 수 없습니다.

3. 일부 상황에서 더 높은 규모. 지속적으로 연결된 TCP 소켓에 대한 webSocket 요구 사항은 HTTP 요청이 요구하지 않는 서버 인프라에 몇 가지 새로운 확장 요구 사항을 추가합니다. 따라서 이것은 트레이드 오프 공간이됩니다. webSocket의 장점이 실제로 필요하지 않거나 중요한 방식으로 사용되지 않는 경우 HTTP 요청이 실제로 더 잘 확장 될 수 있습니다. 특정 사용 프로필에 따라 다릅니다.

4. 일회성 요청 / 응답 의 경우 단일 HTTP 요청이 webSocket을 설정하고이를 사용한 다음 닫는 것보다 더 효율적입니다. 이는 webSocket 열기가 HTTP 요청 / 응답으로 시작되고 양측이 webSocket 연결로 업그레이드하는 데 동의 한 후 실제 webSocket 메시지를 보낼 수 있기 때문입니다.

5. 무국적. 상태 비 저장 인프라를 사용하여 작업이 더 복잡해지지 않는 경우 상태 비 저장 세계는 확장을 훨씬 쉽게 만들 수 있습니다 (로드 밸런서 뒤에 서버 프로세스를 더 추가하기 만하면됩니다).

6. 자동 캐시 가능. 올바른 서버 설정을 사용하면 브라우저 나 프록시에 의해 http 응답을 캐시 할 수 있습니다. webSocket을 통해 전송 된 요청에 대한 이러한 내장 메커니즘은 없습니다.

---

따라서 질문 방식을 해결하려면 다음을 수행하십시오.

RESTful HTTP 대신 웹 소켓을 사용하면 어떤 함정이 있습니까?

1. 대규모 (수십만 클라이언트)에서는 동시에 연결된 많은 수의 webSocket을 지원하기 위해 몇 가지 특별한 서버 작업을 수행해야 할 수 있습니다.

2. 가능한 모든 클라이언트 또는 도구 세트는 webSockets 또는 HTTP 요청을 지원하는 것과 동일한 수준으로 이루어진 요청을 지원하지 않습니다.

3. 저렴한 서버 환경 중 일부는 webSocket을 지원하는 데 필요한 장기 실행 서버 프로세스를 지원하지 않습니다.

응용 프로그램에서 진행 상황 알림을 클라이언트로 다시받는 것이 중요하다면 진행 상황이 계속 전송되는 장기 실행 http 연결을 사용하거나 webSocket을 사용할 수 있습니다. webSocket이 더 쉬울 것입니다. 이 특정 활동의 상대적으로 짧은 기간 동안 만 webSocket이 필요한 경우, 클라이언트에 데이터를 푸시하고 그런 다음 정상적인 요청 / 응답 활동에 http 요청을 사용합니다.

---

실제로 요구 사항에 따라 다릅니다. REST 서비스는 Websocket에 비해 개발자가 훨씬 더 투명하고 쉽게 선택할 수 있습니다.

Websocket을 사용하면 URI를 통해 리소스를 참조하는 기능과 같이 RESTful 웹 서비스가 제공하는 대부분의 이점을 제거 할 수 있습니다. 실제로해야 할 일은 REST와 하이퍼 미디어의 장점을 파악하고이를 기반으로 이러한 장점이 중요한지 여부를 결정하는 것입니다.

물론 RESTful 웹 서비스를 만들고 실시간 응답을 위해 웹 소켓 기반 API로이를 보강하는 것은 전적으로 가능합니다.

그러나 제어 된 환경에서 자신 만 사용할 서비스를 만드는 경우 유일한 단점은 모든 클라이언트가 웹 소켓을 지원하지는 않지만 거의 모든 유형의 환경에서 간단한 http 호출을 수행 할 수 있다는 것입니다.

참조 URL : https://stackoverflow.com/questions/29925955/what-are-the-pitfalls-of-using-websockets-in-place-of-restful-http