HTML5 WebSockets보다 AJAX의 긴/짧은 폴링은 어떤 상황에서 선호됩니까?

HTML5 WebSockets보다 AJAX의 긴/짧은 폴링은 어떤 상황에서 선호됩니까?

저는 친구를 위한 작은 채팅 어플리케이션을 만들고 있지만, 페이지를 강제로 새로 고치는 것만큼 수동적이거나 기초적이지 않은 정보를 적시에 얻는 방법에 대해 잘 모르겠습니다.

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

장/단기 폴링을 조사하면서 HTML5 WebSockets를 발견했습니다.이것은 구현하기 쉬워 보이지만 숨겨진 단점이 있는지 잘 모르겠습니다.예를 들어 WebSockets는 특정 브라우저에서만 지원된다고 생각합니다.WebSockets에는 그 밖에 주의해야 할 단점이 있습니까?

두 테크놀로지가 같은 기능을 하는 것 같기 때문에 어떤 시나리오에서 다른 테크놀로지를 사용하는 것이 좋습니까?좀 더 구체적으로 말하면, HTML5 WebSockets가 AJAX의 긴/짧은 폴링을 폐지한 것인가, 아니면 WebSockets보다 AJAX를 선호하는 설득력 있는 이유가 있는가?

WebSockets는 확실히 미래 지금 당장.

긴 폴링은 AJAX처럼 각 요청에 대한 연결을 만드는 것을 방지하기 위한 더러운 회피책이지만 긴 폴링은 WebSockets가 존재하지 않을 때 작성되었습니다.WebSockets로 인해 긴 폴링은 가버리다 이제 그만.

WebRTC는 피어 투 피어 통신을 가능하게 합니다.

웹소켓을 배우는 것을 추천합니다.

비교:

웹상의 다른 커뮤니케이션 기술의

• AJAX -request→response. 서버에 대한 연결을 만들고 옵션 데이터를 사용하여 요청 헤더를 전송하고 서버로부터 응답을 받아 연결을 닫습니다.모든 주요 브라우저에서 지원됩니다.

• 장기 여론조사 -request→wait→responseAJAX와 같이 서버에 대한 접속을 작성하지만 일정 기간(단, 얼마 되지 않음) 동안 킵얼라이브 접속을 유지합니다.접속중에, 오픈 클라이언트는 서버로부터 데이터를 수신할 수 있습니다.클라이언트는 타임아웃 또는 데이터 eof로 인해 접속이 종료된 후 정기적으로 재접속해야 합니다.서버측에서는, 애플리케이션 로직으로 정의되고 있는 요구의 응답은 현재 또는 장래에 행해지는 것을 제외하고, AJAX와 같은 HTTP 요구로서 취급됩니다.지원 차트(전체) | 위키백과

• 웹 소켓 -client↔server서버에 TCP 접속을 확립해, 필요에 따라서 계속 열어 둡니다.서버 또는 클라이언트는 쉽게 연결을 닫을 수 있습니다.클라이언트는 HTTP 호환 핸드쉐이크 프로세스를 거칩니다.성공하면 서버와 클라이언트는 언제든지 양방향으로 데이터를 교환할 수 있습니다.애플리케이션이 두 가지 방법으로 빈번한 데이터 교환을 필요로 하는 경우 효율적입니다.WebSockets에는 클라이언트에서 서버로 전송되는 각 메시지에 대한 마스킹을 포함하는 데이터 프레임이 있으므로 데이터가 암호화됩니다.지원 차트(매우 우수) | 위키백과

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

• 서버에서 전송된 이벤트 -client←server클라이언트는 서버에 대한 지속적이고 장기적인 접속을 확립합니다.서버만이 클라이언트에 데이터를 송신할 수 있습니다.클라이언트가 서버에 데이터를 송신하려면 , 다른 테크놀로지/프로토콜을 사용할 필요가 있습니다.이 프로토콜은 HTTP와 호환되며 대부분의 서버 측 플랫폼에서 구현하기 쉽습니다.이는 Long Polling 대신 사용하는 것이 좋습니다.지원 차트 (양호, IE 제외)| wikipedia

장점:

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

보안에 관한 고려 사항

사람들은 종종 웹소켓의 보안에 대해 걱정한다.실제로는 거의 차이가 없거나 심지어 WebSockets를 더 나은 옵션으로 사용하고 있습니다.우선, AJAX에서는, 각 요구가 인터넷인프라스트럭처를 통과하는 새로운 TCP 접속이기 때문에, MITM 의 가능성이 높아집니다.WebSockets를 사용하면 일단 접속하면 그 사이에 가로채기가 훨씬 어려워집니다.클라이언트에서 서버로 데이터를 스트리밍할 때 프레임 마스킹이 강화되고 데이터를 조사하는 데 더 많은 노력이 필요합니다.최신 프로토콜은 모두 HTTP와 HTTPS(암호화)를 지원합니다.

추신.

WebSockets는 일반적으로 네트워킹에 대한 로직 접근 방식이 매우 다르며, 실시간 게임이 http와 같은 접근 방식이 아닙니다.

경합하는 테크놀로지 중 하나가 Server-Sent Events/Event Source입니다.롱폴링, 웹소켓, 서버 전송 이벤트(SSE) 및 Comet이란 무엇입니까?이 모든 것에 대해 좋은 논의를 하고 있습니다.이러한 기능 중 일부는 서버 측에서 다른 기능보다 통합이 용이하다는 점에 유의하십시오.

또는WebSockets최적의 옵션입니다. 사용할 수 것은 「」, 「」입니다.WebSockets필요한 라이브러리를 설치할 수 없는 경우 사용할 수 있는 기능이 제한될 수 있습니다.때는 '먹다'를 .Long Polling을 사용하다

• XHR 폴링 이벤트가 발생했을 때(즉시 또는 지연 후에) 요구에 응답합니다.후속 요청은 추가 이벤트를 수신하기 위해 이루어져야 합니다.

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

• Server Sent Events Client가 서버에 요청을 보냅니다.서버는 언제든지 새로운 데이터를 웹페이지로 전송합니다.

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

• 첫 번째 핸드쉐이크 후 WebSockets(HTTP 프로토콜을 통해).통신은 WebSocket 프로토콜을 사용하여 양방향으로 이루어집니다.

  핸드쉐이크는 HTTP 요청/응답으로 시작되며, 서버가 동일한 포트 상의 HTTP 연결 및 WebSocket 연결을 처리할 수 있습니다.접속이 확립되면 통신은 HTTP 프로토콜에 준거하지 않는 양방향 바이너리 프로토콜로 전환됩니다.위키백과

언급URL : https://stackoverflow.com/questions/10028770/in-what-situations-would-ajax-long-short-polling-be-preferred-over-html5-websock