nodejs: Ajax와 소켓.IO, 장단점

nodejs: Ajax와 소켓.IO, 장단점

클라이언트측 Ajax 콜(jQuery)을 모두 삭제하고 대신 영구 소켓 접속(Socket)을 사용할까 생각했습니다.IO)

따라서 이벤트 청취자/이머터 클라이언트 측과 서버 측을 사용합니다.

예를 들어, 클릭 이벤트가 브라우저에서 사용자에 의해 트리거되고 클라이언트 측 이미터가 소켓 연결을 통해 이벤트를 서버에 푸시합니다.서버측 리스너는 착신 이벤트에 응답하여 "완료" 이벤트를 클라이언트에 푸시합니다.클라이언트의 리스너는 착신 이벤트에 대해 DIV 요소로 페이딩하여 응답합니다.

그게 말이 되나요?장점과 단점?

이 스레드에는 매우 부정확한 일반적인 잘못된 정보가 많이 있습니다.

TL/DR; 어플리케이션용 HTTP를 대체하는 WebSocket!그것은 마이크로소프트와 다른 많은 선두 기업들의 도움으로 구글에 의해 디자인되었다.모든 브라우저가 지원합니다.죄인은 없어요

SocketIO는 WebSocket Protocol(RFC 6455)을 기반으로 구축되어 있습니다.AJAX를 완전히 대체하기 위해 설계되었습니다.확장성 문제는 전혀 없습니다.AJAX보다 훨씬 적은 리소스를 사용하면서 더 빠르게 작동합니다.

AJAX는 10년 전의 것으로 페이지 전체를 새로고침하지 않고 서버에 콜백을 할 수 있도록 추가된 단일 JavaScript XMLHTTPRequest 함수를 기반으로 구축되었습니다.

즉, AJAX는 단일 JavaScript 함수를 가진 문서 프로토콜(HTTP)입니다.

반면 WebSocket은 HTTP를 완전히 대체하도록 설계된 애플리케이션 프로토콜입니다.WebSocket 프로토콜을 요청하여 HTTP 연결을 업그레이드할 때 서버와의 양방향 전이중 통신을 사용할 수 있으며 프로토콜 핸드쉐이킹은 수행되지 않습니다.AJAX에서는 킵얼라이브를 유효하게 할 필요가 있습니다(Socket과 동일).I/O(오래된 프로토콜만) 또는 AJAX 요청을 할 때마다 서버를 정지시키는 새로운 HTTP 핸드쉐이크를 강제로 실행합니다.

A 소켓노드 위에서 실행 중인 IO 서버는 4GB RAM과 단일 CPU를 사용하여 keep-alive 모드에서 100,000개의 동시 연결을 처리할 수 있으며, 이 제한은 프로토콜이 아닌 V8 가비지 수집 엔진에 의해 발생합니다.AJAX에서는 꿈에도 이룰 수 없는 일입니다.

소켓을 선택하는 이유I/O가 매우 빠르고 리소스 소비량이 매우 적음

주요 이유는 WebSocket이 애플리케이션용으로 설계되었으며 AJAX는 문서 프로토콜 위에 애플리케이션을 사용할 수 있도록 하기 위한 회피책이기 때문입니다.

HTTP 프로토콜을 자세히 살펴보고 MVC 프레임워크를 사용하면 단일 AJAX 요청이 실제로 700~900바이트의 프로토콜 로드를 URL(사용자 자신의 페이로드 없이) AJAX로 전송합니다.반면 WebSocket은 서버와의 통신에 약 10바이트, 즉 약 70배 적은 데이터를 사용합니다.

소켓 이후IO는 오픈 접속을 유지하고 핸드쉐이크는 없으며 서버 응답 시간은 서버 자체에 대한 왕복 또는 ping 시간으로 제한됩니다.

소켓 접속이 포트 접속이라는 잘못된 정보가 있지만 포트 접속은 아닙니다.소켓 연결은 테이블 내의 엔트리일 뿐입니다.소비되는 리소스는 극히 적으며, 1대의 서버로 1,000,000 이상의 WebSocket 접속을 제공할 수 있습니다.AWS XXL 서버는 1,000,000 이상의 소켓을 호스트할 수 있습니다.IO 접속

AJAX 접속은 전체 HTTP 헤더를 gzip/deflate하고 헤더를 디코딩하고 헤더를 인코딩하며 HTTP 서버 스레드를 스핀업하여 요청을 처리합니다.이것은 문서 프로토콜이기 때문입니다.서버는 문서를 한 번 뱉도록 설계되었습니다.

반면 WebSocket은 접속을 위해 테이블에 약 40~80바이트의 엔트리를 저장합니다.바로 그거야.폴링은 전혀 이루어지지 않습니다.

Web Socket은 확장용으로 설계되어 있습니다.

소켓까지IO가 지저분해서...이것은 전혀 사실이 아니다.AJAX는 지저분하기 때문에 약속이나 대응이 필요합니다.

소켓 포함IO는 단순히 이미터와 리시버가 있기 때문에 서로에 대해 알 필요도 없으며 약속 시스템도 필요하지 않습니다.

사용자 목록을 요청하려면 서버에 메시지를 보내면 됩니다.

socket.emit("giveMeTheUsers");

서버가 준비되면 다른 메시지를 보냅니다.타다, 넌 끝났어.따라서 사용자 목록을 처리하려면 원하는 응답을 받았을 때 어떻게 해야 하는지 간단히 말하면 됩니다.

socket.on("HereAreTheUsers", showUsers(data) );

바로 그겁니다.어디가 엉망진창이야?음, 아무것도 없습니다:) 우려의 분리?다 됐다.고객을 가둬서 기다려야 한다는 걸 알게 하는 거요?기다릴 필요가 없습니다:) 언제든지 새로운 사용자 목록을 얻을 수 있습니다.서버는 어떤 UI 명령도 이 방법으로 재생할 수 있습니다.WebRTC를 사용하는 서버를 사용하지 않아도 클라이언트는 서로 접속할 수 있습니다.

SocketIO로 채팅 시스템? 10줄 코드.실시간 화상회의?80줄의 코드 예...루크...나와 함께 해.작업에 적합한 프로토콜을 사용합니다.앱을 만들고 있다면...앱 프로토콜을 사용합니다.

여기서의 문제와 혼란은 AJAX 사용에 익숙한 사람들이 클라이언트의 모든 추가 약속 프로토콜과 백엔드의 REST API가 필요하다고 생각하는 데서 비롯된다고 생각합니다.필요 없습니다. :) 더 이상 필요 없습니다. :)

웹소켓으로 바꾸기로 결정했을 때 REST API는 더 이상 필요하지 않습니다.REST는 사실 구식이에요.데스크톱 앱을 작성하면 REST로 대화창을 통해 소통합니까?아니요:) 그건 꽤 바보같은 소리예요.

SocketIO를 사용하면 WebSocket을 사용하여 동일한 작업을 수행할 수 있습니다.클라이언트측을 앱의 다이얼로그로서 간단하게 생각할 수 있습니다.더 이상 휴식이 필요 없습니다.

실제로 WebSocket을 사용하는 동안 REST를 사용하려고 하면 데스크톱 대화 상자의 통신 프로토콜로 REST를 사용하는 것과 마찬가지로 어리석은 것입니다.전혀 의미가 없어요

그게 무슨 말이야?당신의 앱을 사용하고자 하는 다른 앱은 어떻습니까?그들이 REST에 접근할 수 있도록 해야 하나요?티미...Web Socket은 출시된 지 4년이 되었습니다.WebSocket을 사용하여 앱에 연결하고 프로토콜을 사용하여 메시지를 요청하도록 하십시오.50배 적은 리소스로 훨씬 빠르고 10배 쉽게 개발할 수 있습니다.미래를 창조하는데 왜 과거를 지원합니까?

물론 REST에 대한 사용 사례는 있지만 모두 구형 및 구식 시스템용입니다.대부분의 사람들은 아직 그것을 모른다.

갱신:

최근 많은 사람들이 어떻게 2018년(그리고 2019년)에 WebSockets를 사용하여 앱 작성을 시작할 수 있는지 물어보고 있는데, Socket을 가지고 놀면 장벽이 매우 높아 보인다는 것이다.IO는 어디서 무엇을 배워야 할지 모릅니다.

다행히 지난 3년간은 웹소켓에 매우 친절했습니다.

이제 REST와 WebSocket을 모두 지원하는 3가지 주요 프레임워크가 있으며, 심지어 IoT 프로토콜이나 ZeroMQ와 같은 최소/속도 프로토콜도 지원합니다. 이에 대해 걱정할 필요가 없습니다. 즉석에서 지원을 받을 수 있습니다.

주의: Meteor가 가장 인기가 있지만, Meteor와 몇 년 동안 코드 작업을 해 온 사람이라면, Meteor가 매우 자금력이 풍부한 WebSocket 프레임워크이지만, Meteor와 코드 작업을 해 온 사람이라면, Meteor는 내부적인 혼란이며, 확장하기에는 악몽이라고 말할 수 있기 때문에 제외합니다.WordPress가 PHP와 비슷하지만, WordPress는 인기가 있지만 잘 만들어지지 않았습니다.그것은 잘 생각되지 않아서 곧 죽게 될 것이다.Meteor 여러분, 죄송합니다.Meteor와 비교해서 이 세 가지 다른 프로젝트를 확인하시면 Meteor는 같은 날 버려집니다.

아래의 모든 프레임워크를 사용하여 서비스를 한 번 작성하면 REST와 WebSocket 지원을 모두 받을 수 있습니다.또한 거의 모든 백엔드 데이터베이스 간에 한 줄의 구성 코드만 스왑할 수 있습니다.

Features 사용하기 쉽고, 전면과 백엔드에서 동일하게 동작하며, 대부분의 기능을 지원합니다.Features는 express와 같은 기존 도구를 위한 경량 포장지 모음입니다.featurs-vuex와 같은 훌륭한 툴을 사용하면 완전한 모킹이 가능한 불변의 서비스를 만들고 REST, WebSocket 및 기타 프로토콜(Primus 사용)을 지원하며 코드 한 줄(일부 구성만) 없이 검색 및 페이지 수를 포함한 완전한 CRUD 작업을 무료로 수행할 수 있습니다.또한 json-schema-faker와 같은 생성된 데이터에서도 매우 잘 작동하므로 사물을 완전히 조롱할 수 있을 뿐만 아니라 랜덤하지만 유효한 데이터로 조롱할 수 있습니다.코드(구성만) 없이 자동 검색, 생성, 삭제 및 편집을 지원하도록 앱을 연결할 수 있습니다.아시다시피 적절한 코드 스루 구성이 자기 수정 코드의 가장 큰 장벽입니다.Features는 그것을 제대로 하고 있으며, 당신을 앱 디자인의 미래로 안내할 것입니다.

Moleculer Moleculer는 불행히도 Featurs보다 백엔드에서 훨씬 우수합니다.Features는 기능하며 무한대로 확장할 수 있지만, Features는 프로덕션 클러스터링, 라이브 서버 콘솔, 폴트 톨러런스, 즉시 사용 가능한 로그 파이프, API 게이트웨이 등은 전혀 생각하지 않습니다(Featurs를 사용하여 프로덕션 API 게이트웨이를 구축한 반면 Moleculer는 훨씬 더 나은 방식으로 구현합니다).또한 Moleculer는 인기와 신기능 모두에서 WebSocket 프레임워크보다 빠르게 성장하고 있습니다.

Moleculer의 승리 스트라이크는 깃털이나 액션을 사용할 수 있다는 것입니다.Moleculer 백엔드로 영웅적인 프런트엔드로 발전기를 일부 잃어버리더라도 생산 품질은 크게 향상됩니다.

따라서 전면과 백엔드의 Features를 익히는 것을 추천합니다.첫 번째 앱을 만들면 백엔드를 Moleculer로 전환해 보세요.Moleculer는 시작하기가 더 어렵지만 모든 확장 문제를 해결해 주기 때문에 새로운 사용자에게 혼란을 줄 수 있습니다.

ActionHero 실행 가능한 대안으로 여기에 열거되어 있지만, Featers와 Moleculer가 더 나은 구현입니다.액션에 대해서영웅은 너와 함께 살지 않아, 그것을 사용하지 마. 더 많은 것을, 더 빨리 줄 수 있는 두 가지 더 좋은 방법이 있어.

메모: API 게이트웨이는 미래이며 위의 3가지 모두 이를 지원하지만 Moleculer는 말 그대로 즉시 사용할 수 있습니다.API 게이트웨이를 통해 클라이언트 상호 작용을 마사지할 수 있으므로 캐싱, 메모화, 클라이언트 간 메시징, 블랙리스트 작성, 등록, 폴트 톨러런스 및 기타 모든 확장 문제를 단일 플랫폼 구성 요소로 처리할 수 있습니다.API 게이트웨이를 Kubernetes와 결합하면 문제를 최소화하고 무한대로 확장할 수 있습니다.확장 가능한 앱에서 사용할 수 있는 최고의 설계 방법입니다.

2021년 갱신:

산업이 너무 발전해서 프로토콜에 신경 쓸 필요조차 없습니다.이제 GraphQL은 기본적으로 WebSockets를 사용합니다!구독 사용법만 찾아보면 됩니다.가장 빨리 처리할 수 있는 방법이 당신에게 있을 겁니다.

Vue, React 또는 Angular를 사용하는 경우 기본 GraphQL 구현이 있기 때문에 운이 좋습니다.GraphQL 서브스크립션을 사용하여 서버에서 데이터를 호출하기만 하면 해당 데이터 개체가 자동으로 최신 상태를 유지하고 반응합니다.

레거시 시스템을 사용해야 할 경우 GraphQL은 REST로 폴백되며 소켓을 사용하여 구독이 계속 업데이트됩니다.GraphQL로 이동하면 모든 것이 해결됩니다.

'WTH?!'라고 생각하신다면요.FireBase와 같이 서버 오브젝트에 가입하기만 하면 자동으로 갱신됩니다.네, 이제 그게 사실이에요.GraphQL 구독만 사용하십시오.WebSockets를 사용합니다.

채팅 시스템?코드 1줄실시간 비디오 시스템?코드 1줄10MB의 오픈월드 데이터를 100만 실시간 사용자 간에 공유하는 비디오 게임? 코드 한 줄.코드는 현재 GQL 쿼리일 뿐입니다.

적절한 백엔드를 구축하거나 사용하기만 하면 GQL 서브스크립션에서 이러한 모든 실시간 작업이 수행됩니다.가능한 한 빨리 전환하고 프로토콜에 대해 걱정하지 마십시오.

Socket.IO는 클라이언트와 서버 간의 지속적인 연결을 사용하기 때문에 서버 측의 리소스에 따라 동시 연결의 최대 제한에 도달합니다.또한 동일한 리소스로 처리할 수 있는 Ajax 비동기 요구도 증가합니다.

Socket.IO는 주로 클라이언트와 서버 간의 실시간 및 양방향 연결을 위해 설계되었으며 일부 애플리케이션에서는 영구 연결을 유지할 필요가 없습니다.한편, Ajax 비동기 접속은 HTTP 접속 셋업 단계를 통과하고 모든 요구와 함께 헤더 데이터와 모든 쿠키를 전송해야 합니다.

Socket.IO는 단일 프로세스 서버로 설계되었으며 필요한 서버 리소스에 따라 확장성에 문제가 있을 수 있습니다.

Socket.IO는 클라이언트 요청 결과를 캐시하는 것이 더 나은 경우 애플리케이션에 적합하지 않습니다.

Socket.IO 애플리케이션은 SEO 최적화 및 검색 엔진 인덱싱에 어려움을 겪고 있습니다.

Socket.IO는 표준이 아니며 W3C Web Socket API와 동등하지 않습니다.브라우저가 지원하는 경우 현재의 Web Socket API를 사용합니다.이 API는 실시간 앱에서 크로스 브라우저 호환성을 해결하기 위해 개인이 만든 것으로, 약 1년 정도 젊습니다.socket.io을 기반으로 코드를 작성하기 위해서는 ajax/jquery에 비해 학습 곡선, 개발자 및 커뮤니티 리소스 감소, 장기 유지 보수 및 향후 필요성 또는 더 나은 옵션이 중요할 수 있습니다.

단방향 메시지를 발송하고 해당 메시지에 콜백을 호출하면 매우 혼란스러울 수 있습니다.

$.get('/api', sendData, returnFunction);보다 깨끗하다socket.emit('sendApi', sendData); socket.on('receiveApi', returnFunction);

그래서 dnode와 nowjs를 socket.io 위에 구축하여 관리하기 쉽게 만들었습니다.콜백을 포기하지 않고 이벤트 구동.

언급URL : https://stackoverflow.com/questions/7193033/nodejs-ajax-vs-socket-io-pros-and-cons