socket.io 과 웹 소켓의 차이점

socket.io 과 웹 소켓의 차이점

nodenode.js.js에 .io 과 은 무엇입니까?
둘 다 서버 푸시 기술입니까?내가 느낀 유일한 차이점은

1. socket.io 에서는 이벤트 이름을 지정하여 메시지를 주고받을 수 있습니다.

2. socket.io 의 경우 서버에서 보내는 메시지가 모든 클라이언트에 도달하지만, 웹 소켓에서도 마찬가지로 모든 연결의 배열을 유지하고 모든 클라이언트에 메시지를 보내기 위해 루프를 통과해야 했습니다.

또한 웹 검사자(예: Chrome/firebug/fiddler)가 (서버에서 socket.io/websocket) 로) 이러한 메시지를 수신할 수 없는 이유가 궁금합니다.

이것을 명확히 해주시기 바랍니다.

오해

WebSocket 및 Socket에 대한 일반적인 오해는 거의 없습니다.IO:

1. 첫 번째 오해는 소켓을 사용하는 것입니다.IO는 그렇지 않은 것처럼 보이는 WebSocket을 사용하는 것보다 훨씬 쉽습니다.아래 예를 참조하십시오.

2. 두 번째 오해는 웹소켓이 브라우저에서 널리 지원되지 않는다는 것입니다.자세한 내용은 아래를 참조하십시오.

3. 세 번째 오해는 소켓입니다.IO는 이전 브라우저에서 폴백으로 연결을 다운그레이드합니다.실제로는 브라우저가 오래된 것으로 가정하고 서버에 대한 AJAX 연결을 시작하며, 나중에 일부 트래픽이 교환된 후 WebSocket을 지원하는 브라우저에서 업그레이드됩니다.자세한 내용은 아래를 참조하십시오.

나의 실험

웹소켓과 소켓의 차이점을 설명하기 위해 npm 모듈을 작성했습니다.IO:

• https://www.npmjs.com/package/websocket-vs-socket.io
• https://github.com/rsp/node-websocket-vs-socket.io

이것은 서버측 코드와 클라이언트측 코드의 간단한 예이며, 클라이언트는 웹소켓 또는 소켓을 사용하여 서버에 연결됩니다.IO와 서버는 클라이언트가 DOM에 추가하는 1초 간격으로 세 개의 메시지를 보냅니다.

서버측

WebSocket 및 Socket 사용의 서버 측 예를 비교합니다.Express.js 앱에서 동일한 작업을 수행하는 IO:

웹 소켓 서버

Express.js를 사용하는 WebSocket 서버 예:

var path = require('path');
var app = require('express')();
var ws = require('express-ws')(app);
app.get('/', (req, res) => {
  console.error('express connection');
  res.sendFile(path.join(__dirname, 'ws.html'));
});
app.ws('/', (s, req) => {
  console.error('websocket connection');
  for (var t = 0; t < 3; t++)
    setTimeout(() => s.send('message from server', ()=>{}), 1000*t);
});
app.listen(3001, () => console.error('listening on http://localhost:3001/'));
console.error('websocket example');

출처: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.js

소켓.IO 서버

Express.js를 사용하는 Socket.IO 서버 예제:

var path = require('path');
var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);
app.get('/', (req, res) => {
  console.error('express connection');
  res.sendFile(path.join(__dirname, 'si.html'));
});
io.on('connection', s => {
  console.error('socket.io connection');
  for (var t = 0; t < 3; t++)
    setTimeout(() => s.emit('message', 'message from server'), 1000*t);
});
http.listen(3002, () => console.error('listening on http://localhost:3002/'));
console.error('socket.io example');

출처: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.js

클라이언트 측

WebSocket 및 Socket 사용의 클라이언트 측 예를 비교합니다.브라우저에서 동일한 작업을 수행할 IO:

웹 소켓 클라이언트

바닐라 JavaScript를 사용한 WebSocket 클라이언트 예:

var l = document.getElementById('l');
var log = function (m) {
    var i = document.createElement('li');
    i.innerText = new Date().toISOString()+' '+m;
    l.appendChild(i);
}
log('opening websocket connection');
var s = new WebSocket('ws://'+window.location.host+'/');
s.addEventListener('error', function (m) { log("error"); });
s.addEventListener('open', function (m) { log("websocket connection open"); });
s.addEventListener('message', function (m) { log(m.data); });

출처: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/ws.html

소켓.IO 클라이언트

Vanilla JavaScript를 사용하는 Socket.IO 클라이언트 예제:

var l = document.getElementById('l');
var log = function (m) {
    var i = document.createElement('li');
    i.innerText = new Date().toISOString()+' '+m;
    l.appendChild(i);
}
log('opening socket.io connection');
var s = io();
s.on('connect_error', function (m) { log("error"); });
s.on('connect', function (m) { log("socket.io connection open"); });
s.on('message', function (m) { log(m); });

출처: https://github.com/rsp/node-websocket-vs-socket.io/blob/master/si.html

네트워크 트래픽

네트워크 트래픽의 차이를 확인하려면 내 테스트를 실행할 수 있습니다.다음은 제가 얻은 결과입니다.

웹 소켓 결과

요청 2개, 1.50KB, 0.05초

다음 두 가지 요청 중에서:

1. HTML 페이지 자체
2. WebSocket으로 연결 업그레이드

(연결 업그레이드 요청은 101 Switching Protocols 응답으로 개발자 도구에서 볼 수 있습니다.)

소켓.IO 결과

6개 요청, 181.56KB, 0.25초

다음 6가지 요청 중에서:

1. HTML 페이지 자체
2. Socket.IO의 JavaScript(180KB)
3. 첫 번째 긴 폴링 AJAX 요청
4. 두 번째 긴 폴링 AJAX 요청
5. 세 번째 긴 폴링 AJAX 요청
6. WebSocket으로 연결 업그레이드

스크린샷

로컬 호스트에서 받은 WebSocket 결과:

로컬 호스트에서 얻은 Socket.IO 결과:

직접 테스트해 보십시오.

빠른 시작:

# Install:
npm i -g websocket-vs-socket.io
# Run the server:
websocket-vs-socket.io

브라우저에서 http://localhost:3001/을 열고 Shift+Ctrl+I로 개발자 도구를 열고 네트워크 탭을 열고 Ctrl+R로 페이지를 다시 로드하여 WebSocket 버전의 네트워크 트래픽을 확인합니다.

브라우저에서 http://localhost:3002/를 열고 Shift+Ctrl+I로 개발자 도구를 열고 네트워크 탭을 열고 Ctrl+R로 페이지를 다시 로드하여 소켓의 네트워크 트래픽을 확인합니다.IO 버전.

제거 방법:

# Uninstall:
npm rm -g websocket-vs-socket.io

브라우저 호환성

2016년 6월 현재 웹소켓은 오페라 미니를 제외한 IE 이상을 포함한 모든 것에서 작동합니다.

2016년 6월 현재 웹소켓의 브라우저 호환성입니다.

최신 정보는 http://caniuse.com/websockets 을 참조하십시오.

장점은 #2에서 설명한 대로 WebSocket의 사용을 단순화한다는 것이며, 더 중요한 것은 브라우저나 서버에서 WebSocket이 지원되지 않는 경우 다른 프로토콜에 대한 페일오버를 제공한다는 것입니다.WebSocket이 작동하지 않는 환경에 대해 잘 알고 있고 이러한 제한 사항을 해결할 수 있는 경우가 아니라면 WebSocket을 직접 사용하지 않습니다.

이것은 웹소켓과 소켓 모두에서 좋은 판독치입니다.IO.

http://davidwalsh.name/websocket

tl;dr;

그것들을 비교하는 것은 레스토랑 음식(때로는 비쌀 수도 있고, 100% 원하지 않을 수도 있음)을 집에서 만든 음식과 비교하는 것과 같습니다. 여기서 여러분은 각자의 재료를 모아서 스스로 재배해야 합니다.

만약 여러분이 단지 사과를 먹고 싶다면, 후자가 더 나을 것입니다.하지만 만약 여러분이 복잡한 것을 원하지만 혼자라면, 모든 재료를 혼자서 요리하고 만들 가치가 없습니다.

---

저는 이 두 가지 모두와 함께 일했습니다.여기 제 경험이 있습니다.

소켓 IO

• 자동 연결 있음

• 네임스페이스 있음

• 방 있음

• 서브스크립션

• 사전 설계된 통신 프로토콜을 사용합니다.

  (등록, 등록 취소 또는 특정 룸으로 메시지를 보내는 프로토콜에 대해 말하자면, 모두 웹 소켓에서 직접 설계해야 합니다.)

• 양호한 로깅 지원

• redis와 같은 서비스와 통합 가능

• WS가 지원되지 않는 경우에 대비하여 폴백(글쎄요, 점점 더 드문 상황이긴 하지만)

• 도서관입니다.즉, 모든 면에서 여러분의 대의에 도움이 된다는 것입니다.웹 소켓은 라이브러리가 아닌 프로토콜입니다. 어떤 소켓입니다.IO는 어쨌든 사용됩니다.

• 전체 아키텍처는 사용자가 아닌 다른 사용자가 지원하고 설계하므로 위에서 설명한 내용을 설계하고 구현하는 데 시간을 들일 필요가 없습니다. 비즈니스 규칙 코딩으로 바로 이동할 수 있습니다.

• 라이브러리이므로 커뮤니티가 있음(HTTP 또는 웹 소켓에 대한 커뮤니티를 가질 수 없음:P 표준/프로토콜일 뿐임)

웹 소켓

• 당신은 절대적인 통제권을 가지고 있습니다, 당신이 누구인지에 따라, 이것은 매우 좋을 수도 있고 나쁠 수도 있습니다.
• 그것은 도서관이 아니라 프로토콜이라는 것을 기억하세요.
• 독자적인 아키텍처 및 프로토콜 설계
• 자동 연결이 없습니다. 원하는 경우 사용자가 직접 구현합니다.
• 서브스크립션 서비스가 없습니다. 사용자가 설계합니다.
• 로깅이 없습니다. 사용자가 구현합니다.
• 예비 지원 없음
• 강의실이나 네임스페이스가 없습니다.만약 당신이 그러한 개념들을 원한다면, 당신은 그것들을 직접 구현합니다.
• 아무것도 지원하지 않는 당신은 모든 것을 구현하는 사람이 될 것입니다.
• 먼저 기술적인 부분에 집중하고 웹 소켓에서 오고 가는 모든 것을 설계해야 합니다.
• 먼저 설계를 디버그해야 합니다. 그러면 시간이 오래 걸립니다.

분명히, 당신은 내가 소켓에 치우친 것을 볼 수 있습니다.IO. 저도 그렇게 말하고 싶지만, 저는 정말 그렇지 않습니다.

소켓을 사용하지 않기 위해 정말 고군분투하고 있습니다.IO. 사용하고 싶지 않습니다.저는 제 물건을 디자인하고 제 문제를 스스로 해결하는 것을 좋아합니다.

하지만 1000줄짜리 프로젝트가 아닌 비즈니스를 원한다면 웹 소켓을 선택해야 합니다. 모든 것을 직접 구현해야 합니다.모든 것을 디버깅해야 합니다.당신은 당신만의 구독 서비스를 만들어야 합니다.당신만의 프로토콜입니다.당신의 모든 것.그리고 당신은 모든 것이 꽤 세련되었는지 확인해야 합니다.그리고 그 과정에서 많은 실수를 하게 될 것입니다.모든 것을 설계하고 디버깅하는 데 많은 시간이 소요될 것입니다.저는 그랬고 지금도 그래요.저는 웹소켓을 사용하고 있습니다. 제가 여기에 온 이유는 그들이 자신의 스타트업을 위한 비즈니스 규칙을 해결하고 대신 웹소켓을 디자인하는 전문 용어를 다루려고 하는 한 사람에게는 견딜 수 없기 때문입니다.

대규모 애플리케이션을 위해 웹 소켓을 선택하는 것은 복잡한 기능을 구현하려는 단일 팀이나 소규모 팀의 경우 쉬운 선택이 아닙니다.나는 소켓으로 작성한 것보다 더 많은 코드를 웹 소켓에 작성했습니다.과거의 IO는 소켓을 사용했을 때보다 10배 더 단순했습니다.IO.

내가 할 말은...소켓 선택완성된 제품과 디자인을 원하는 경우 IO.(기능적으로 매우 간단한 것을 원하지 않는 한)

저는 socket.io 을 사용하는 것에 반대하는 주장을 할 것입니다.

저는 socket.io 을 단지 폴백이 있다는 이유만으로 사용하는 것은 좋은 생각이 아니라고 생각합니다.IE8 RIP.

과거에는 새로운 버전의 노드를 사용하는 경우가 많았습니다.JS가 socket.io 을 위반했습니다.이 목록에서 예를 확인할 수 있습니다.https://github.com/socketio/socket.io/issues?q=install+error

Android 앱이나 기존 앱과 연동해야 하는 것을 개발하러 간다면 WS로 바로 작업해도 괜찮을 것입니다. socket.io 에서 문제를 일으킬 수도 있습니다.

노드용 WS 모듈을 추가합니다.JS는 놀라울 정도로 사용하기 쉽습니다.

소켓 사용.IO는 기본적으로 jQuery를 사용하는 것과 같습니다. 이전 브라우저를 지원하려면 코드를 적게 작성해야 하며 라이브러리는 폴백을 제공합니다.Socket.io 은 가능한 경우 웹 소켓 기술을 사용하고, 그렇지 않은 경우 사용 가능한 최상의 통신 유형을 확인하여 사용합니다.

https://socket.io/docs/ # What-Socket-IO-nat-not (제가 강조하는 바)

무슨 소켓.IO가 아닙니다.

Socket.IO는 WebSocket 구현이 아닙니다.비록 소켓.IO는 실제로 가능한 경우 전송으로 WebSocket을 사용하며, 메시지 확인이 필요할 때 패킷 유형, 네임스페이스 및 패킷 ID와 같은 일부 메타데이터를 각 패킷에 추가합니다.이것이 WebSocket 클라이언트가 Socket에 성공적으로 연결할 수 없는 이유입니다.IO 서버 및 소켓.IO 클라이언트도 WebSocket 서버에 연결할 수 없습니다.여기에서 프로토콜 사양을 참조하십시오.

// WARNING: the client will NOT be able to connect!
const client = io('ws://echo.websocket.org');

2021년에 한 가지 더 답변을 드리고 싶습니다. socket.io 은 2020년 9월부터 다시 활발하게 유지되고 있습니다.2019년부터 2020년 8월까지(거의 2년) 기본적으로 활동이 전혀 없었고 프로젝트가 중단되었을 수도 있다고 생각했습니다.

Socket.io 은 또한 Why Socket이라는 기사를 실었습니다.2020년 IO? HTTP 롱슬롯으로의 폴백을 제외하면, 이 두 가지 기능은 socket.io 가 제공하고 웹 소켓에는 부족하다고 생각합니다.

• 자동 표현
• 주어진 고객(방/방) 집합에 데이터를 브로드캐스트하는 방법

제가 편리하다고 생각하는 또 다른 기능은 socket.io 서버 개발입니다. 특히 서버 배포를 위해 도커를 사용합니다.저는 항상 하나 이상의 서버 인스턴스를 시작하기 때문에 크로스 서버 통신은 필수이며 socket.io 는 이를 위해 https://socket.io/docs/v4/redis-adapter/ 를 제공합니다.

redis-adapter를 사용하면 서버 프로세스를 여러 노드로 쉽게 확장할 수 있는 반면 ws 서버의 로드 밸런싱은 어렵습니다.자세한 내용은 여기 https://socket.io/docs/v4/using-multiple-nodes/ 을 참조하십시오.

현대의 브라우저가 지금 웹소켓을 지원한다고 해도, 나는 소켓을 던질 필요가 없다고 생각합니다.IO는 멀리 떨어져 있지만 오늘날의 어떤 프로젝트에서도 여전히 제자리를 차지하고 있습니다.이해하기 쉽고, 개인적으로 소켓 덕분에 웹소켓이 어떻게 작동하는지 배웠습니다.IO.

이 항목에서 언급했듯이 Angular, React 등을 위한 통합 라이브러리와 TypeScript 및 기타 프로그래밍 언어를 위한 정의 유형이 많이 있습니다.

제가 Socket.io 과 WebSockets의 차이점에 추가하고 싶은 또 다른 점은 Socket.io 과의 클러스터링이 큰 문제가 아니라는 것입니다.Socket.io 은 확장성을 높이기 위해 Redis와 연결하는 데 사용할 수 있는 어댑터를 제공합니다.예를 들어 ioredis와 socket.io -redis가 있습니다.

예, SocketCluster가 존재한다는 것은 알고 있지만, 이는 주제에서 벗어난 것입니다.

Socket.IO는 WebSocket을 사용하고 WebSocket을 사용할 수 없을 때는 폴백 알고리즘을 사용하여 실시간 연결을 만듭니다.

TLDR:

'Socket.io '은 애플리케이션 계층 규격 '웹 소켓' 위에/사용하여 구현할 수 있는 애플리케이션 계층 규격입니다.

웹 소켓 사양
socket.io 사양

여기서 간단한 답은 기본적인 웹 기술 정의에 있다고 생각합니다.

1. 사양:"일부 sepc의 주입"이라는 레이블을 붙이기 위해 프로그램이 달성해야 하는 요구 사항을 상세히 설명하는 문서화된 표준입니다.어떤 프로그램이든 코드를 실행하는 기계만큼만 잘하기 때문에 프로그램을 빌드할 때 이 고무 스탬프를 얻는 것이 중요합니다.프로그래밍은 기본적으로 사양을 기반으로 하며, 사양을 따르지 않으면 코드가 올바르게 실행되지 않습니다.그러나 규격은 아무런 효과가 없습니다.그것은 단지 텍스트 문서입니다.
2. 구현:이 코드는 사양에 명시된 작업을 수행하는 실제 실행 코드입니다.
3. 응용 프로그램 계층 - 전송을 통해 전송되는 메시지 및 악수를 정의하는 시스템입니다.이것은 HTTP/WebSockets/Socketio로 작업할 때 알아야 할 사항입니다.연결, 인증, 데이터 전송 및 도착 방법을 정의합니다.

언급URL : https://stackoverflow.com/questions/10112178/differences-between-socket-io-and-websockets