VNC 메커니즘이 어떻게 작동하는지 이해하려고 노력 중입니다.
RFB 프로토콜 3.8 사양은 다음과 같이 말합니다.
업데이트 프로토콜은 클라이언트 요구 사항에 따라 결정됩니다. 즉, 업데이트는 클라이언트의 명시적인 요청에 대한 응답으로만 서버에서 클라이언트로 전송됩니다. 이는 프로토콜에 적응형 품질을 제공합니다. 클라이언트와 네트워크 속도가 느릴수록 업데이트 속도도 낮아집니다. 일반적인 애플리케이션의 경우 프레임 버퍼의 동일한 영역에 대한 변경이 차례로 발생하는 경향이 있습니다. 느린 클라이언트 및/또는 네트워크의 경우 프레임 버퍼 과도 현상을 무시하여 네트워크 트래픽과 클라이언트 그리기를 줄일 수 있습니다.
이는 서버가 FramebufferUpdate클라이언트 측에서만 전송 한다는 의미인 것 같습니다 FramebufferUpdateRequest. 그런 다음 클라이언트는 이러한 패킷을 주기적으로 전송해야 합니다. 하지만 Wireshark를 통해 분석해 보니 그렇지 않다는 것을 알게 되었습니다. 화면이나 포인터 활동이 없으면 클라이언트에서 서버로 이동하는 패킷이 표시되지 않습니다.
클라이언트를 포함하지 않고 화면에 일부 화면 활동을 만들 때( xclockdisplay를 이 값으로 설정하여 실행) 첫 번째 메시지는 클라이언트의 요청이 아니라 서버에서 클라이언트로 전달됩니다.
그래서 내 질문은 다음과 같습니다서버는 실제로 화면 활동이 있을 때마다가 아니라 클라이언트가 요청할 때만 업데이트를 보내나요?이 두 가지 사례는 얼마나 자주 업데이트되나요?
답변1
나는 이것이 오래된 질문이라는 것을 알고 있지만 대답은 RFB RFC에서 찾을 수 있습니다.
클라이언트가 FramebufferUpdateRequest다음으로 표시된 서버 incremental에 메시지를 보낼 때보고해야 할 실제 변경 사항이 있을 때까지. 이 시점에서 서버는 FramebufferUpdate변경된 사각형 데이터가 포함된 메시지를 다시 보냅니다.
즉, 네트워크 데이터를 보면 (아마도 keepalives를 제외하고) 클라이언트에서 서버로 보낸 마지막 패킷이 FramebufferUpdateRequest로 표시 되어 있음을 알 수 있습니다 incremental. 서버는 보낼 업데이트가 있을 때까지 응답을 보내지 않으므로 네트워크는 조용하게 유지됩니다.
더 일반적으로는 화면이 자주 변경되어 여러 개의 연속 메시지가 발생하고 FramebufferUpdateRequest서버에서 단일 복합 메시지가 발생할 수 있습니다.FramebufferUpdate