ajax가 사용할 수 있는 websocket/socket.io의 단점은 무엇입니까?

ajax가 사용할 수 있는 websocket/socket.io의 단점은 무엇입니까?

이전에도 비슷한 질문을 한 적이 있으며 모두 AJAX가 쓸모없게 되지 않을 것이라는 결론에 도달했다.하지만 어떤 면에서 웹소켓보다 에이잭스가 더 나은가?

socket.io을 사용하면 플래시나 긴 폴링으로 되돌아가기 쉬우므로 브라우저 호환성은 문제가 되지 않는 것 같습니다.

웹소켓은 양방향입니다.여기서 ajax는 비동기 요구를 합니다.Websocket 클라이언트는 서버에 메시지를 보냅니다.POST/GET 파라미터는 JSON으로 부호화할 수 있습니다.

그렇다면 100% 웹소켓을 사용하는 것이 어떤 문제일까요?모든 방문자가 서버에 대한 지속적인 웹 소켓 연결을 유지한다면 방문 세션에서 몇 가지 Ajax 요청을 하는 것보다 더 낭비가 될까요?

그게 더 낭비일 것 같아요.접속되어 있는 모든 클라이언트에 대해서, 그 클라이언트와 짝을 이루는 서버상의 오브젝트/기능/코드/무엇이 필요합니다.소켓 핸들러, 파일 기술자, 또는 접속을 처리하도록 서버가 설정되어 있다.

AJAX를 사용하면 서버 측 리소스를 클라이언트에 1:1로 매핑할 필요가 없습니다.클라이언트 수는 서버 측 리소스보다 덜 의존적으로 확장할 수 있습니다.node.js에서도 처리 가능한 연결 수와 열린 연결 수에 제한이 있습니다.

그 밖에 고려해야 할 것은 특정 AJAX 응답도 캐시할 수 있다는 것입니다.스케일업 시 HTTP 캐시를 추가하여 빈번한 AJAX 요청으로 인한 부하를 줄일 수 있습니다.

★★
웹 소켓을 활성화 상태로 유지하면 클라이언트와 서버 모두에 Ajax의 비용이 한 번만 발생하는지 여부에 따라 비용이 발생합니다.

한 답변
웹소켓은 종종 "에이잭스를 사용하세요, 그걸로 충분합니다!"라는 전체 때문에 오해를 받는다.아약스, 아약스같은 분야에 적용할 수도 있지만 웹 소켓을 사용하는 것이 터무니 없는 경우가 있습니다.

간단한 예를 들어 보겠습니다.클라이언트 측에서 페이지가 로드된 후 데이터를 로드하는 동적 페이지입니다.간단해, 에이잭스한테 전화해서버에서 클라이언트까지 단방향만 있으면 됩니다.클라이언트는 이러한 데이터를 요구하고 서버는 클라이언트에 데이터를 송신합니다.왜 그런 작업을 위해 웹소켓을 구현합니까?접속을 항상 열 필요는 없습니다.클라이언트가 서버에 계속 요구할 필요도 없고, 서버가 클라이언트에 통지할 필요도 없습니다.접속은 열린 상태로 유지되며 리소스를 낭비하게 됩니다.접속을 열린 상태로 유지하려면 지속적으로 확인해야 하기 때문입니다.

채팅 어플리케이션에서는 상황이 완전히 다릅니다.새로운 것이 있는 경우는, x초 또는 밀리초마다 클라이언트에 문의하도록 강요하는 것이 아니라, 서버에 의해서 클라이언트에 통지가 필요합니다.그건 말이 안 돼요.

더 잘 이해하기 위해, 그것을 두 사람으로서 보자.둘 중 하나는 서버이고, 오버는 클라이언트입니다.아약스클라이언트는 레터를 송신하고 서버는 다른 레터로 응답합니다.
서버,줄거 "네", "네", "네", "네", "네"?
요 - 안 돼요 - 안 돼요
, 한테 줄 거 있어 - 네, 뭐 있어?
요 - 안 돼요 - 안 돼요
, 한테 줄 거 있어 - 네, 뭐 있어?
요. - 네, 여기 있어요.
클라이언트가 응답을 요청하지 않은 경우 서버는 실제로 클라이언트에 편지를 보낼 수 없습니다.엄청난 자원 낭비입니다.모든 Ajax 요청에 대해 캐시된 경우에도 서버 측에서 작업을 수행해야 합니다.

이제 앞서 Ajax에 로딩된 데이터로 논의한 사례를 살펴보겠습니다.클라이언트가 서버와 통화하고 있다고 가정합니다.연결을 활성 상태로 유지하려면 비용이 많이 듭니다.전기요금이 들고 교환원에게 요금을 내야 합니다.왜 다른 사람에게 전화를 걸어 한 시간 동안 계속 전화를 걸어야 하죠? 그 사람이 당신에게 3단어만 말해주길 바란다면요? 빌어먹을 편지를 보내요.

결론적으로 웹소켓은 Ajax를 완전히 대체하는 것이 아닙니다!
웹소켓 사용이 터무니 없는 Ajax가 필요할 수 있습니다.

: : SSE " "
그 기술은 널리 쓰이지는 않지만 유용할 수 있다.이름에서 알 수 있듯이 Server-Sent Events는 서버에서 클라이언트로의 단방향 푸시입니다.클라이언트는 아무것도 요구하지 않고 서버는 데이터만 보냅니다.

: - Ajax : Ajax
: - SSE
: - 웹소켓 : 웹소켓

개인적으로 웹소켓은 AJAX가 아닌 웹 어플리케이션에서 점점 더 많이 사용될 것이라고 생각합니다.캐싱과 SEO가 더 큰 관심사인 웹 사이트에는 적합하지 않지만 웹 앱에는 놀라운 기능을 제공합니다.

DNode 및 소켓스트림 등의 프로젝트를 통해 복잡성을 해소하고 RPC 스타일의 심플한 코드화를 실현할 수 있습니다.즉, 클라이언트코드가 서버의 함수를 호출하여 원하는 함수에 데이터를 전달합니다.또한 서버는 클라이언트의 함수를 호출하여 데이터를 전달할 수도 있습니다.TCP 의 사소한 것에 신경 쓸 필요는 없습니다.

게다가 AJAX 콜에서는 오버헤드가 많이 발생합니다.예를 들어, 접속을 확립하고 HTTP 헤더(쿠키 등)를 모든 요구와 함께 전달해야 합니다.웹소켓은 그 대부분을 없앱니다.어떤 사람들은 웹소켓이 더 낭비적이라고 말하는데, 아마도 그들이 옳을지도 모른다.하지만 나는 그 차이가 그렇게 큰지 확신하지 못한다.

관련 자료에 대한 많은 링크를 포함한 다른 관련 질문에 대해 자세히 답변했습니다.확인하실 수 있습니다.

websocket api를 rest api로 대체하시겠습니까?

조만간 웹소켓 기반 프레임워크가 웹 앱의 일부와 같은 실시간 채팅 작성뿐만 아니라 독립형 웹 프레임워크로도 팝업되기 시작할 것이라고 생각합니다.영구 접속이 생성되면 웹 어플리케이션의 UI 파트를 포함한 모든 종류의 데이터를 수신할 수 있으며, 현재는 AJAX 요청을 통해 제공됩니다.이 접근방식은 용장HTTP 헤더를 포함한 비동기 요구에 의해 발생하는 트래픽과 부하를 줄일 수 있지만 SEO에 어떤 영향을 줄 수 있습니다.

다만, 상시 접속이 불필요하거나 바람직하지 않은 시나리오가 다수 존재하기 때문에, Websocket이 AJAX를 대체하거나 위험에 빠뜨릴지는 의문입니다.예를 들어 클라이언트와 영구적으로 연결할 필요가 없는 단일 목적 REST 기반 서비스를 사용하는 매시업 애플리케이션을 예로 들 수 있습니다.

"잘못된" 것은 아무것도 없습니다.

유일한 차이점은 대부분 가독성입니다.Ajax의 주요 장점은 대부분의 기능이 사용자용으로 작성되었기 때문에 빠른 개발이 가능하다는 것입니다.

소켓을 열 때마다 휠을 다시 발명할 필요가 없다는 큰 장점이 있습니다.

WS:// 연결은 "AJAX" 요청보다 오버헤드가 훨씬 적습니다.

다른 사람들이 말했듯이, 서버 대 클라이언트 통지가 필요하지 않거나 클라이언트 대 서버 요청이 낮은 빈도로 발생하는 일부 시나리오에서는 연결을 계속 유지하는 것이 과잉일 수 있습니다.

그러나 또 다른 단점은 웹소켓이 낮은 수준의 프로토콜이기 때문에 초기 핸드쉐이크가 실행되면 TCP에 추가 기능을 제공하지 않는다는 것입니다.따라서 웹소켓을 통해 요청-응답 패러다임을 구현할 때 HTTP(매우 성숙한 확장 프로토콜 패밀리)가 제공하는 캐싱(클라이언트 및 공유 캐시), 검증(조건부 요청), 안전성과 IDPotentence(에이전트의 동작 방식에 영향을 주는), 범위 요청, 컨텐츠 유형, 상태 코드,...

즉, 비용을 들여 메시지 크기를 줄일 수 있습니다.

따라서 AJAX는 요구 응답, 웹소켓은 서버 푸싱, 고주파수의 저지연 메시징을 선택할 수 있습니다.

서버에의 접속을 오픈하고, 서버에의 폴링이 계속 되는 경우는, 다른 소켓을 선택해 주세요.

간단한 비유 : Ajax는 서버에 질문(요구)을 하고 서버는 이러한 질문에 대한 답변(응답)을 합니다.연속적으로 질문할 경우 Ajax가 작동하지 않습니다.양쪽에 리소스가 필요하기 때문에 오버헤드가 커집니다.

언급URL : https://stackoverflow.com/questions/4848642/what-is-the-disadvantage-of-using-websocket-socket-io-where-ajax-will-do