친구를위한 작은 채팅 응용 프로그램을 작성하고 있지만 페이지를 새로 고치는 것만 큼 수동적이거나 기초적이지 않은 정보를 적시에 얻는 방법에 대해서는 잘 모르겠습니다.

현재 간단한 AJAX를 사용하여 이것을 구현하고 있지만 짧은 타이머가 경과하면 정기적으로 서버를 누르는 단점이 있습니다.

Long / Short Polling을 조사 할 때 HTML5 WebSocket을 살펴 보았습니다. 이 보인다 쉽게 구현할 수 있지만, 일부 숨겨진 단점가 있는지 확실하지 않습니다. 예를 들어 WebSockets는 특정 브라우저에서만 지원된다고 생각합니다. WebSockets에 대해 알아야 할 다른 단점이 있습니까?

두 기술이 모두 같은 역할을하는 것처럼 보이기 때문에 어떤 시나리오에서 하나를 사용하는 것을 선호합니까? 보다 구체적으로, HTML5 WebSockets가 AJAX long / short polling을 쓸모 없게 만들었습니까, 아니면 WebSockets보다 AJAX를 선호해야하는 강력한 이유가 있습니까?

WebSockets는 확실히 미래입니다.

긴 폴링은 AJAX와 같이 각 요청에 대한 연결을 만드는 것을 막는 더러운 해결 방법이지만 WebSocket이 존재하지 않을 때 긴 폴링이 생성되었습니다. 이제 WebSocket으로 인해 긴 폴링이 사라집니다.

WebRTC는 피어 투 피어 통신을 허용합니다.

WebSockets를 배우는 것이 좋습니다 .

비교:

웹상의 다양한 통신 기술

• AJAX - request→ response. 서버에 대한 연결을 작성하고 선택적 데이터와 함께 요청 헤더를 전송하고 서버에서 응답을 얻은 후 연결을 닫습니다. 모든 주요 브라우저에서 지원됩니다.

• 긴 설문 조사 - request→ wait→ response. AJAX와 같이 서버에 대한 연결을 작성하지만 얼마 동안 (계속) 연결 유지 연결을 유지합니다. 연결 중에 열린 클라이언트는 서버에서 데이터를 수신 할 수 있습니다. 시간 초과 또는 데이터 eof로 인해 연결이 종료 된 후 클라이언트는 주기적으로 다시 연결해야합니다. 서버 측에서는 AJAX와 동일한 HTTP 요청처럼 처리됩니다. 단, 요청시 응답은 현재 또는 향후에 애플리케이션 로직에 의해 정의 될 것입니다. 지원 차트 (전체) | 위키 백과

• WebSocket을 - client↔ server. 서버에 대한 TCP 연결을 작성하고 필요한만큼 열어 두십시오. 서버 나 클라이언트는 연결을 쉽게 닫을 수 있습니다. 클라이언트는 HTTP 호환 핸드 셰이크 프로세스를 거칩니다. 성공하면 서버와 클라이언트는 언제든지 양방향으로 데이터를 교환 할 수 있습니다. 응용 프로그램이 두 가지 방식으로 자주 데이터를 교환해야하는 경우 효율적입니다. WebSocket에는 클라이언트에서 서버로 전송되는 각 메시지에 대한 마스킹을 포함하는 데이터 프레임이 있으므로 데이터가 단순히 암호화됩니다. 지원 차트 (매우 좋음) | 위키 백과

• WebRTC - peer↔ peer. 전송은 클라이언트간에 통신을 설정하고 전송에 독립적이므로 UDP, TCP 또는 훨씬 더 추상적 인 계층을 사용할 수 있습니다. 일반적으로 비디오 / 오디오 스트리밍과 같은 대용량 데이터 전송에 사용되며, 신뢰성이 2 차이고 응답 시간 및 적어도 일부 데이터 전송을 위해 몇 개의 프레임 또는 품질 진행 감소가 희생 될 수 있습니다. 양쪽 (피어)은 서로 독립적으로 데이터를 푸시 할 수 있습니다. 중앙 서버와는 완전히 독립적으로 사용할 수 있지만 여전히 엔드 포인트 데이터를 교환 할 수있는 방법이 필요합니다. 대부분의 경우 개발자는 중앙 서버를 사용하여 피어를 "링크"합니다. 이는 중앙 집중식 서버가 필요하지 않은 연결을 설정하기 위해 필수 데이터를 교환하는 데만 필요합니다. 지원 차트 (중간) | 위키 백과

• 서버가 보낸 이벤트 - client← server. 클라이언트는 서버에 지속적이고 장기적인 연결을 설정합니다. 서버 만이 클라이언트에게 데이터를 보낼 수 있습니다. 클라이언트가 서버로 데이터를 보내려면 다른 기술 / 프로토콜을 사용해야합니다. 이 프로토콜은 HTTP와 호환되며 대부분의 서버 측 플랫폼에서 구현하기가 쉽습니다. Long Polling 대신 사용하기에 바람직한 프로토콜입니다. 지원 차트 (IE 제외) | 위키 백과

장점 :

WebSockets 서버 측 의 주요 장점은 HTTP 요청 (핸드 셰이크 후)이 아니라 적절한 메시지 기반 통신 프로토콜이라는 것입니다. 이를 통해 엄청난 성능 및 아키텍처 이점을 얻을 수 있습니다 . 예를 들어 node.js에서 다른 소켓 연결에 대해 동일한 메모리를 공유 할 수 있으므로 각 공유 변수에 액세스 할 수 있습니다. 따라서 데이터베이스를 중간에 교환 지점으로 사용할 필요가 없습니다 (예 : AJAX 또는 Long Polling과 같이 PHP와 같은 언어 사용). RAM에 데이터를 저장하거나 소켓간에 즉시 다시 게시 할 수도 있습니다.

보안 고려 사항

사람들은 종종 WebSockets의 보안에 대해 걱정합니다. 실제로는 차이가 적거나 WebSocket을 더 나은 옵션으로 사용합니다. 우선 AJAX를 사용하면 각 요청이 인터넷 인프라를 통과하는 새로운 TCP 연결이므로 MITM 가능성이 높아집니다 . WebSocket을 사용하면 일단 연결되면 데이터를 클라이언트에서 서버로 스트리밍 할 때 프레임 마스킹을 강화하고 추가 압축을 수행하여 데이터를 조사하는 데 더 많은 노력이 필요합니다. 모든 최신 프로토콜은 HTTP 및 HTTPS (암호화)를 모두 지원합니다.

추신

WebSocket은 일반적으로 http 와는 달리 실시간 게임과 비슷하지만 네트워킹 에 대해 매우 다른 논리 접근 방식을 가지고 있음을 기억 하십시오.

생략 한 경합 기술 중 하나는 Server-Sent Events / Event Source입니다. 롱 폴링, 웹 소켓, SSE (Server-Sent Events) 및 혜성이란 무엇입니까? 이 모든 것들에 대한 좋은 토론이 있습니다. 이들 중 일부는 다른 서버보다 서버 측에서 통합하기가 쉽다는 점을 명심하십시오.

채팅 응용 프로그램 또는 서버와 지속적으로 대화하는 다른 응용 프로그램의 WebSockets경우 가장 좋은 옵션입니다. 그러나 WebSockets서버를 지원하는 서버 에서만 사용할 수 있으므로 필요한 라이브러리를 설치할 수없는 경우 서버를 사용하는 기능이 제한 될 수 있습니다. 이 경우 Long Polling비슷한 기능을 얻기 위해 사용해야 합니다.

• XHR 폴링 이벤트가 발생하면 (즉시 또는 지연 후) 요청에 응답합니다. 추가 요청을 받으려면 후속 요청이 필요합니다.

  브라우저는 서버의 비동기 요청을하므로 응답하기 전에 데이터를 사용할 수있을 때까지 기다릴 수 있습니다. 응답에는 클라이언트가 실행할 인코딩 된 데이터 (일반적으로 XML 또는 JSON) 또는 Javascript가 포함될 수 있습니다. 응답 처리가 끝나면 브라우저는 다른 XHR을 만들어 보내 다음 이벤트를 기다립니다. 따라서 브라우저는 항상 서버에서 미해결 요청을 유지하여 각 이벤트가 발생할 때마다 응답합니다. 위키 백과

• 서버 송신 이벤트 클라이언트는 서버로 요청을 보냅니다. 서버는 언제든지 웹 페이지에 새 데이터를 보냅니다.

  전통적으로 웹 페이지는 새로운 데이터를 받기 위해 서버에 요청을 보내야합니다. 즉, 페이지는 서버에서 데이터를 요청합니다. 서버에서 보낸 이벤트를 사용하면 서버가 메시지를 웹 페이지로 푸시하여 언제든지 새 데이터를 웹 페이지로 보낼 수 있습니다. 이러한 수신 메시지는 웹 페이지 내에서 Events + data로 취급 될 수 있습니다. 모질라

• WebSockets 초기 핸드 셰이크 후 (HTTP 프로토콜을 통해). 통신은 WebSocket 프로토콜을 사용하여 양방향으로 수행됩니다.

  핸드 셰이크는 HTTP 요청 / 응답으로 시작하여 서버가 동일한 포트에서 WebSocket 연결뿐만 아니라 HTTP 연결을 처리 할 수 ​​있도록합니다. 연결이 설정되면 통신은 HTTP 프로토콜을 준수하지 않는 양방향 이진 프로토콜로 전환됩니다. 위키 백과