많은 근거를 다루는 다른 사람들의 훌륭한 답변. 여기에 약간의 추가 정보가 있습니다.
Java Applets, Flash 또는 Silverlight와 같은 플러그인에 비해 WebSocket의 유일한 장점은 WebSocket이 기본적으로 브라우저에 내장되어 있으며 플러그인에 의존하지 않는다는 것입니다.
이것이 Java Applets, Flash 또는 Silverlight를 사용하여 소켓 연결을 설정할 수 있음을 의미한다면 가능합니다. 그러나 제한으로 인해 실제 세계에 너무 자주 배포되는 것을 보지 못합니다.
예를 들어 중개자는 해당 트래픽을 차단할 수 있습니다. WebSocket 표준은 기존 HTTP 인프라와 호환되도록 설계되었으므로 방화벽 및 프록시와 같은 중개자의 간섭을 훨씬 덜받습니다.
또한 WebSocket은 기존 HTTP 인프라와 최대한 호환되는 프로토콜 설계 덕분에 전용 포트없이 포트 80 및 443을 사용할 수 있습니다.
이러한 소켓 대안 (Java, Flash 및 Silverlight)은 교차 출처 아키텍처에서 안전하게 사용하기가 어렵습니다. 따라서 종종 교차 출처를 사용하려고 시도하는 사람들은 안전하게 수행하려는 노력보다 불안정성을 용인 할 것입니다.
또한 추가 "비표준"포트를 열어야하거나 (관리자가 싫어하는 일) 관리해야하는 정책 파일이 필요할 수 있습니다.
요컨대, 소켓 연결을 위해 Java, Flash 또는 Silverlight를 사용하는 것은 심각한 아키텍처에 너무 자주 배포되는 것을 보지 못할만큼 문제가됩니다. 플래시와 자바는 아마도 적어도 10 년 동안이 기능을 가지고 있었지만 널리 퍼지지는 않았습니다.
WebSocket 표준은 이러한 제한 사항을 염두에두고 새로운 접근 방식으로 시작할 수 있었으며 그로부터 몇 가지 교훈을 얻었기를 바랍니다.
일부 WebSocket 구현은 WebSocket 연결을 설정할 수없는 경우 (예 : 이전 브라우저에서 실행 중이거나 중개자가 방해하는 경우) 대체 수단으로 Flash (또는 Silverlight 및 / 또는 Java)를 사용합니다.
이러한 상황에 대한 일종의 폴백 전략이 현명하고 필요하지만 Flash 등을 사용하는 대부분의 경우 위에서 설명한 단점이 있습니다. 그렇게 할 필요는 없습니다. Flash, Silverlight 등을 사용하여 안전한 교차 출처 연결을 달성하기위한 해결 방법이 있지만 대부분의 구현은 쉽지 않기 때문에 그렇게하지 않습니다.
예를 들어, 교차 출처 연결을 위해 WebSocket에 의존하는 경우 제대로 작동합니다. 그러나 이전 브라우저에서 실행하거나 방화벽 / 프록시가 방해를 받아 플래시에 의존하는 경우 (예 : 폴백으로) 동일한 교차 출처 연결을 수행하기가 어렵습니다. 물론 보안에 신경 쓰지 않는 한.
즉, 상당한 작업을 할 준비가되어 있거나 잘 수행 된 프레임 워크를 사용하지 않는 한 네이티브 및 비 네이티브 연결에 대해 작동하는 단일 통합 아키텍처를 갖는 것이 어렵습니다. 이상적인 아키텍처에서는 연결이 기본인지 아닌지 알 수 없습니다. 보안 설정은 두 경우 모두 작동합니다. 클러스터링 설정은 계속 작동합니다. 용량 계획은 여전히 유효합니다. 등등.
http 스트리밍에 비해 WebSockets의 유일한 장점은 수신 된 데이터를 "이해"하고 구문 분석하기 위해 노력할 필요가 없다는 것입니다.
HTTP 스트림을 열고 데이터가 몇 분, 몇 시간 또는 그 이상 흐름을 유지하는 것처럼 간단하지 않습니다. 클라이언트마다 다르게 행동하므로이를 관리해야합니다. 예를 들어 일부 클라이언트는 데이터를 버퍼링하고 일부 임계 값이 충족 될 때까지 애플리케이션에 릴리스하지 않습니다. 더 나쁜 것은 일부는 연결이 닫힐 때까지 데이터를 애플리케이션에 전달하지 않는다는 것입니다.
따라서 여러 메시지를 클라이언트로 보내는 경우, 예를 들어 50 개의 메시지에 해당하는 데이터가 수신 될 때까지 클라이언트 응용 프로그램이 데이터를 수신하지 못할 수 있습니다. 너무 실시간이 아닙니다.
HTTP 스트리밍은 WebSocket을 사용할 수 없을 때 실행 가능한 대안이 될 수 있지만 만병 통치약은 아닙니다. 실제 환경에서 웹의 황무지에서 강력한 방식으로 작업하려면 좋은 이해가 필요합니다.
내가 놓친 다른 중요한 차이점이 있습니까?
아직 아무도 언급하지 않은 것이 하나 더 있으므로 제가 말씀 드리겠습니다.
WebSocket 프로토콜은 높은 수준의 프로토콜을위한 전송 계층으로 설계되었습니다. WebSocket 연결을 통해 직접 JSON 메시지 또는 기타 메시지를 보낼 수 있지만 표준 또는 사용자 지정 프로토콜을 전달할 수도 있습니다.
예를 들어, 사람들이 이미 한 것처럼 WebSocket을 통해 AMQP 또는 XMPP를 수행 할 수 있습니다. 따라서 클라이언트는 마치 브로커 자체에 직접 연결된 것처럼 AMQP 브로커로부터 메시지를 수신 할 수 있습니다 (경우에 따라 연결됨).
또는 일부 사용자 지정 프로토콜이있는 기존 서버가있는 경우 WebSocket을 통해이를 전송하여 해당 백엔드 서버를 웹으로 확장 할 수 있습니다. 종종 엔터프라이즈에 잠겨있는 기존 애플리케이션은 백엔드 인프라를 변경하지 않고도 WebSocket을 사용하여 범위를 확장 할 수 있습니다.
(당연히 모든 작업을 안전하게 수행 할 수 있기를 원하므로 공급 업체 또는 WebSocket 제공 업체에 문의하십시오.)
어떤 사람들은 WebSocket을 웹용 TCP라고합니다. TCP가 더 높은 수준의 프로토콜을 전송하는 것과 마찬가지로 WebSocket도 웹 인프라와 호환되는 방식으로 전송되기 때문입니다.
따라서 WebSocket을 통해 직접 JSON (또는 기타) 메시지를 보내는 것은 항상 가능하지만 기존 프로토콜도 고려해야합니다. 왜냐하면 당신이하고 싶은 많은 일들에 대해 이미 그것을 할 것으로 생각 된 프로토콜이있을 것입니다.
이미 SO에 대한 많은 질문을 하나의 질문으로 다시 묻거나 결합하면 미안하지만 이러한 개념과 관련하여 SO 및 웹에있는 모든 정보를 완벽하게 이해하고 싶습니다.
이것은 훌륭한 질문이었고 답변은 모두 매우 유익했습니다!