IT TIP

WebSocket, UDP 및 벤치 마크

itqueen 2020. 12. 31. 23:13
반응형

WebSocket, UDP 및 벤치 마크


HTML5 웹 소켓은 현재 TCP 통신의 한 형태를 사용합니다. 그러나 실시간 게임의 경우 TCP는이를 차단하지 않습니다 (기본과 같은 다른 플랫폼을 사용하는 큰 이유). 프로젝트를 계속하려면 UDP가 필요할 수 있으므로 HTML6의 사양이 UDP를 지원하는지 알고 싶습니다.

또한 WS 프로토콜을 저수준 직접 소켓 프로토콜과 비교할 WebSocket에 대한 신뢰할 수있는 벤치 마크가 있습니까?


LAN에서는 WebSocket을 통한 200 마이크로 초 (브라우저 JS에서 WebSocket 서버 및 그 반대)의 메시지에 대한 왕복 시간을 얻을 수 있으며 이는 원시 ICMP 핑과 유사합니다. MAN에서는 약 10ms, WAN (가정용 ADSL에서 같은 국가의 서버까지)은 약 30ms, 3.5G를 통해 최대 약 120-200ms입니다. 요점은 : WebSocket은 네트워크를 기반으로 어쨌든 얻을 수있는 대기 시간을 사실상 추가하지 않습니다.

WebSocket의 와이어 수준 오버 헤드 (원시 TCP와 비교)는 메시지 당 2 옥텟 (길이 <126 옥텟의 마스크되지 않은 페이로드)과 14 옥텟 (길이가 64k 이상인 마스킹 된 페이로드) 사이입니다 (이전 숫자는 메시지가 여러 개로 분할되지 않는다고 가정합니다. WebSocket 프레임). 매우 낮은.

WebSocket 와이어 레벨 오버 헤드에 대한 자세한 분석은이 블로그 게시물을 참조하십시오. 여기에는 WebSocket 이외의 레이어에 대한 분석도 포함됩니다.

더 많은 것 : 스트리밍 처리가 가능한 WebSocket 구현을 사용하면 (초기 WebSocket 핸드 셰이크 후) 단일 WebSocket 메시지와 프레임을 각 방향으로 시작한 다음 오버 헤드없이 최대 2 ^ 63 옥텟을 보낼 수 있습니다. 본질적으로 이것은 WebSocket을 원시 TCP의 멋진 전주곡으로 렌더링합니다. 주의 사항 : 중개자는 자체 결정에 따라 트래픽을 분할 할 수 있습니다. 그러나 WSS (즉, 보안 WS = TLS)를 실행하면 중개자가 간섭 할 수 없으며 HTTP 호환 전주곡 (WS 핸드 셰이크)이있는 원시 TCP가 있습니다.

WebRTC는 미디어 전송에 RTP (= UDP 기반)를 사용하지만 신호 채널이 추가로 필요합니다 (예 : WebSocket 일 수 있음). RTP는 손실 허용 실시간 미디어 전송에 최적화되어 있습니다 . "실시간 게임"은 종종 미디어가 아닌 플레이어 위치와 같은 것을 전송하는 것을 의미합니다. WebSocket이 작동합니다.

참고 : WebRTC 전송은 RTP를 통해 이루어 지거나 SRTP를 통해 보호 될 수 있습니다. 여기에서 "RTP 프로파일"을 참조 하십시오 .


로컬 유선 네트워크에서 WebSocket을 사용하여 게임을 개발 한 다음 가능하면 WebRTC 데이터 채널 API로 이동하는 것이 좋습니다. @oberstet이 올바르게 언급했듯이 WebSocket 평균 대기 시간은 기본적으로 특히 로컬 네트워크에서 원시 TCP 또는 UDP와 동일하므로 개발 단계에 적합합니다. WebRTC 데이터 채널 API는 WebSocket과 매우 유사하게 설계되었으므로 (연결이 설정되면) 널리 사용 가능 해지면 통합하기가 매우 간단해야합니다.

귀하의 질문은 UDP가 지연 시간이 짧은 게임을 위해 원하는 것이며 그에 대한 진실이 있음을 의미합니다. 게임을 작성하고 있기 때문에 이미 알고있을 수 있지만, 그렇지 않은 경우 실시간 게임을위한 TCP 대 UDP에 대한 빠른 입문서가 있습니다 .

TCP는 순차적이고 안정적인 전송 메커니즘이며 UDP는 최선의 노력입니다. TCP는 전송 된 모든 데이터를 전송 된 순서대로 전달합니다. UDP 패킷은 도착할 때 전송되고 순서가 잘못 될 수 있으며 간격이있을 수 있습니다 (혼잡 한 네트워크에서는 UDP 패킷이 TCP 패킷보다 먼저 삭제됨). TCP는 크게 개선 된 것처럼 들리며 대부분의 네트워크 트래픽 유형에 해당되지만 이러한 기능에는 비용이 발생합니다. 패킷이 지연되거나 삭제되면 다음 모든 패킷도 지연됩니다 (순차 전달을 보장하기 위해).

실시간 게임은 일반적으로 TCP 소켓에서 발생할 수있는 지연 유형을 용인 할 수 없으므로 대부분의 게임 트래픽에 UDP를 사용하고 삭제 및 비 순차적 데이터를 처리하는 메커니즘을 갖습니다 (예 : 페이로드 데이터). 몇 밀리 초 후에 다른 위치 업데이트를 받게되므로 (아마도 눈치 채지 못할 것이므로) 적 플레이어의 한 위치 업데이트를 놓친다면 그렇게 큰 문제가 아닙니다. 그러나 500ms 동안 위치 업데이트를 얻지 못하고 갑자기 모두 한 번만 꺼내면 끔찍한 게임 플레이가 발생합니다.

즉, 로컬 유선 네트워크에서 패킷은 거의 지연되거나 삭제되지 않으므로 TCP는 초기 개발 대상으로 완벽합니다. WebRTC 데이터 채널 API를 사용할 수있게되면 여기로 이동하는 것을 고려할 수 있습니다. 현재 제안에는 재시도 또는 타이머를 기반으로 구성 가능한 안정성이 있습니다.

다음은 몇 가지 참고 자료입니다.


간단히 말해서 멀티 플레이어 게임에 TCP를 사용하려면 적응 형 스트리밍 기술 이라고하는 것을 사용해야합니다 . 즉, 클라이언트 간의 게임 세계를 동기화하기 위해 전송되는 실시간 데이터의 양이 현재 사용 가능한 대역폭과 각 클라이언트의 대기 시간에 의해 제어되는지 확인해야합니다.

동적 조절, 컨 플레이션, 델타 전달 및 기타 메커니즘은 TCP를 UDP만큼 효율적으로 만들지는 않지만 여러 유형의 게임에 충분히 사용할 수있는 적응 형 스트리밍 기술입니다.

저는 웹을 통한 멀티 플레이어 3D 게임 동기화 최적화 ( http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html ) 기사에서 이러한 기술을 설명하려고했습니다 .

또한 지난달 샌프란시스코에서 열린 HTML5 개발자 컨퍼런스 에서이 주제에 대한 강연을했습니다 . 동영상이 방금 YouTube에서 제공되었습니다. http://www.youtube.com/watch?v=cSEx3mhsoHg


Websocket에 대한 UDP 지원은 없지만 (실제로 있어야 함) UDP와 유사한 통신을 위해 WebRTC의 RTCDataChannel API를 사용할 수 있습니다. 여기에 좋은 기사가 있습니다.

http://www.html5rocks.com/en/tutorials/webrtc/datachannels/

RTCDataChannel은 실제로 구성 가능한 안정성과 주문 된 배달을 가진 SCTP를 사용합니다. 순서없는 메시지를 전달하도록 지시하고 최대 재전송 횟수를 0으로 설정하여 UDP처럼 작동하도록 할 수 있습니다.

나는 이것 중 어느 것도 시도하지 않았습니다.


HTML6의 사양이 UDP를 지원하는지 알고 싶습니다.

WebSockets는 그렇지 않습니다. WebSockets의 이점 중 하나는 기존 HTTP 연결을 피기 백 한다는 것 입니다. 이것은 프록시와 방화벽에 WebSocket이 HTTP처럼 보이므로 차단되지 않는다는 것을 의미합니다.

임의의 UDP 연결은 보안 문제로 인해 웹 사양에 포함되지 않을 가능성이 높습니다 . 당신이 추구 하는 것에 가장 가까운 것은 WebRTC 와 관련된 JSEP 프로토콜일부로 올 것 입니다.

WS 프로토콜을 저수준 직접 소켓 프로토콜과 비교하는 신뢰할 수있는 벤치 마크가 있습니까?

내가 아는 것은 아닙니다. 나는 팔다리로 나가서 WebSockets가 더 느릴 것이라고 예측할 것입니다.)

참조 URL : https://stackoverflow.com/questions/13040752/websockets-udp-and-benchmarks

반응형