websocket 연결을 통해 패킷을 보내는 데 추가로 어떤 오버 헤드가 있습니까?

Question

AJAX 요청을 수행 할 때마다 데이터를 보내기 위해 http 연결을 열어야하는 각 요청의 오버 헤드가 있으므로 가능한 한 적게 수행하려고했습니다. websocket 연결이 끊임없이 열려 있기 때문에 요청을 보내는 명백한 패킷 대역폭 외부의 비용이 있습니까?

예를 들면. 1 분 동안 클라이언트는 100KB의 데이터를 서버로 보냅니다. 클라이언트가 이러한 요청에 대한 응답을 필요로하지 않는다고 가정하면 패킷을 대기열에 넣고 대기열로 보내는 것과 대기열로 보낼 수 있다는 장점이 있습니까?

즉, 끊임없이 열려있는 연결에 대한 데이터 전송을 중지하고 시작하는 데 오버 헤드가 있습니까?

가능한 한 실시간으로 멀티 플레이어 브라우저 게임을 만들고 싶지만 더 큰 통합 요청에 비해 분당 100 억 개의 작은 요청이 서버에 추가적인 스트레스를주는 것을 발견하고 싶지는 않습니다. 클라이언트가 응답을 필요로하는 경우, 앞뒤로 많은 대기가 있으므로 응답 속도가 느려질 것이라는 것을 이해합니다. 나는 이것을 고려하고 적절할 때에 만 통합 할 것이다. 분당 요청 수가 많을수록 사용자 환경이 좋아 지지만 서버에 어떤 대가를 치룰 지 알지 못합니다.

Answer 1

webSocket 연결은 이미 설정되어 있고 webSocket 메시지는 HTTP 요청보다 오버 헤드가 적기 때문에 Ajax 호출을 통해 동일한 메시지를 보내는 것보다 주어진 메시지 전송에 대해 webSocket 메시지의 오버 헤드가 낮을 것이라는 점에 틀림 없습니다.

우선, 더 큰 전송을 보내는 데는 오버 헤드가 적고 작은 전송은 많이 전송합니다. 이것이 바로 TCP의 성격입니다. 모든 TCP 패킷은 별도로 처리되고 확인되므로 더 많은 비용을 보내려면 약간의 오버 헤드가 필요합니다. 그 차이가 관련성이 있는지 또는 중요하고 추가적인 코드 작성이나 사용자 경험의 일부 요소 희생에 가치가 있는지 (일괄 처리 지연으로 인해) 주어진 상황의 세부 사항에 전적으로 달려 있습니다.

지연이없고 패킷 일괄 처리가없는 경우 클라이언트가 최상의 환경을 제공한다고 설명 했으므로 일괄 처리를 구현하지 않고 서버에서 서버를 처리하는 방법을 테스트하지 않아야합니다. 꽤 바쁜 때 작은 패킷이 많이로드됩니다. 문제가 해결되면 더 나은 사용자 환경을 유지하십시오. 로드에 대한 문제가 있다면 서버를 심각하게 프로파일 링하고 성능에 주요 병목 현상이 어디 있는지 확인하십시오. 병목 현상이 실제로 어디에서 발생하는지에 대해 놀랄 것입니다. 왜 당신이 확장 성을 향상시키기 위해 에너지를 집중 시킬지를 알기 위해 프로파일 링하고 측정해야만하는 이유).

FYI의 대부분 구현에서 Nagel's algorithm의 구현으로 인해 TCP 스택 자체는 시간이 많이 걸리거나 느린 링크를 통해 전송할 때 여러 요청을 전송할 때 소량의 일괄 처리를 수행합니다.

동적 시스템을 구현하는 것도 가능합니다. 서버가 계속 작동하는 한 더 작고 응답이 빠른 패킷을 유지하지만 서버가 사용량이 많아지면 배치를 시작하여 분리 된 전송의 수.