X11 포워딩이 왜 그렇게 비효율적입니까?

-C 스위치를 포함하여 X11 포워딩을 사용하여 큰 GUI를 원격으로 시작할 때마다 경험이 매우 반응이 없습니다. 내 질문은 개념 / 프로토콜 수준에서 무엇을 유발 하는가?

25mbit 연결을 통해 아무 문제없이 HD 비디오를 컴퓨터로 스트리밍 할 수 있습니다. 반면 X11 포워딩을 통해 원격으로 실행되는 GUI의 응답이 없으면 100mbit LAN에서도 지연 시간이 거의 없어야합니다.

비디오 스트리밍과 달리 대기 시간이 최대 두 배가 될 것임을 이해합니다 (입력은 원격 컴퓨터로 전송되고 응용 프로그램이 응답 할 수있는 후에야). 내부적으로 대기 시간을 증가시키는 다른 요소가 있습니까 더욱이?

둘째, 대역폭. 왜 그렇게 많이 먹어요? 사진 및 비디오 형식과 관련하여 크기를 크게 줄이기 위해 많은 방법이 사용됩니다.

예를 들어 .bmp 대 .png의 경우 큰 검은 색 정사각형 이미지는 정보가 모든 단일 픽셀에 대해 저장되는 것이 아니라 내가 이해하는 한 범위가 좁아지기 때문에 .png 표현에서 줄어 듭니다.

비디오의 경우, 전체 프레임이 아닌 프레임 간 차이를 전송하여 많은 정보를 저장할 수 있습니다.

나는 이것이 매우 간단하다는 것을 알고 있지만 X11 은이 방법을 사용하지 않습니까? 어떤 수준에서 비트 맵 또는 비차 등 원칙으로 동작합니까? 그렇지 않은 경우 왜 그렇게 많은 대역폭을 차지합니까?

X11 프로토콜은 그래픽으로 (비트 맵 / 텍스처로) 집약적 인 작업을 처리하기위한 것이 아닙니다. X11이 처음으로 디자인 된 당시에는 컴퓨터 그래픽이 오늘날보다 훨씬 단순했습니다.

기본적으로 X11은 화면을 컴퓨터로 보내지 않지만 로컬 컴퓨터의 X 서버가 로컬 시스템에서 화면을 다시 만들 수 있도록 디스플레이 지침을 보냅니다. 그리고 이것은 디스플레이를 변경할 때마다 새로 고쳐 져야합니다.
따라서 컴퓨터는 "좌표 x, y에서 (xx, yy)까지이 색상의 선 그리기, 너비가 W 인 직사각형, 너비가 높은 H 픽셀, (x, y)의 왼쪽 상단 모서리와 같은 높이의 픽셀과 같은 명령 스트림을받습니다." "
로컬 클라이언트는 업데이트해야 할 사항을 실제로 인식하지 못하고 원격 시스템에는 클라이언트가 실제로 필요한 것에 대한 정보가 거의 없으므로 기본적으로 서버는 클라이언트가 필요로하거나 필요로하지 않는 많은 중복 정보를 보내야합니다.
렌더링 할 디스플레이가 제한된 수의 간단한 그래픽 모양으로 구성되고 낮은 새로 고침 빈도 (애니메이션 등 없음) 만 필요한 경우 매우 효율적입니다. X11이 처음 개발 된 당시의 사례입니다.

그러나 최신 GUI에는 눈에 띄는 것이 많고 그 중 많은 부분이 원격 시스템에서 클라이언트로 전송되어야하는 비트 맵 / 텍스처 / 글꼴 형식으로 상당한 대역폭이 필요합니다. 그리고 모든 종류의 눈 사탕에는 빈번한 업데이트가 필요한 애니메이션 효과가 포함됩니다. 너비 / 높이가 픽셀 수의 4 배이므로 디스플레이도 계속 커집니다.

물론 시간이 지남에 따라 X11 프로토콜이 가능한 한 이것을 최적화하기 위해 개선되었지만 기본 기본 설계는 본질적으로 오늘날 GUI 사람들의 요구에 적합하지 않습니다.

RDP 및 VNC와 같은 다른 프로토콜은 원격 시스템이 모든 어려운 작업을 수행하고 해당 시스템이 클라이언트 (압축 된 비트 맵으로)에 가능한 한 효율적으로 보낼 업데이트를 결정할 수 있도록 설계되었습니다. 종종 그것은 현대 GUI에 더 효율적인 것으로 판명되었습니다.

두 방법 모두 완벽하지는 않으며 모든 상황을 동일하게 처리 할 수 ​​없습니다. 모든 유스 케이스에서 잘 수행 할 수있는 단일 디스플레이 프로토콜과 같은 것은 없습니다.
따라서 대부분의 경우 로컬 클라이언트와 원격 서버간에 지원되는 모든 프로토콜을 시도하고 최상의 결과를 제공하는 프로토콜을 사용하십시오. 그리고 어떤 경우에는 선택의 여지가 없으며 가능한 모든 것을 처리해야합니다.

대부분의 프로토콜은 일부 성능 조정을 허용하지만 이러한 설정 중 많은 설정은 서버 측 전용이며 일반 사용자가 사용할 수 없습니다. (그리고 그것들을 올바르게 구성하는 것은 약간의 예술입니다. 많은 sys-admins는 그것을 망설이지 않을 것입니다.)

대부분의 경우 성능을 향상시키는 가장 쉬운 방법은 때로는 눈에 띄지 않게 더 간단한 데스크탑 환경으로 전환하고 배경 이미지를 사용하지 않는 것입니다.

X11 연결 속도가 느려지는 이유는 주로 두 가지입니다. 두 가지 모두 대역폭과 대기 시간입니다. X11 앱이 네트워크에서 느린 이유를 이해하려면 두 가지 모두에 대해 설명하겠습니다.

대역폭

X11은 기본적으로 응용 프로그램과 디스플레이 서버간에 전달되는 네트워크 데이터를 압축하지 않습니다. 앞에서 언급했듯이 SSH에서 -C 옵션을 사용하여 압축을 활성화 할 수 있지만 이것이 도움이되지만 그래픽 데이터 압축에 최적화되어 있지 않습니다. 100 대 1의 압축률을 얻을 수있는 H.264와 같은 형식에 비해 -C 압축은 2 대 1 압축을 달성하는 데 운이 좋을 것입니다. 더 나은 솔루션은 X11 비디오에 그래픽 또는 비디오 최적화 코덱을 사용하는 것입니다. 그러나 데스크톱은 일반적으로 영화보다 선명한 이미지를 가져야 사용자가 여전히 텍스트를 명확하게 읽을 수 있으므로 너무 손실되지 않도록주의해야합니다. 세부 사항을 세밀하게 작성하십시오.

지연 시간

대부분의 작업에는 응용 프로그램과 디스플레이 서버간에 여러 번의 왕복이 필요하기 때문에 X11은 대기 시간이 긴 경향이 있습니다. 핑 시간이 밀리 초 미만인 LAN을 통해 실행하면 이러한 여러 번의 왕복이 눈에 띄지 않지만 인터넷 연결을 통해 빠르게 추가됩니다.

솔루션

몇 년 전에 X11 프로토콜에 내재 된 대역폭 및 대기 시간 문제를 해결하기 위해 몇 가지 프로젝트가 구축되었습니다. lbx (낮은 대역폭 X) 및 dxpc (차동 X 프로토콜 압축기). 나는 lbx가 많은 견인력을 가지고 있다고 생각하지 않지만 dxpc는 NX 라는 제품에 사용되는 기본 기술이되었습니다 . NX는 손실 압축을 사용하여 대역폭 요구 사항을 줄이고 차동 알고리즘과 캐싱을 사용하여 대기 시간이 길어지는 통과하는 정보의 수를 줄입니다. 나는 NX를 자주 사용했으며 성능이 로컬 응용 프로그램만큼 좋았습니다. 당신이 그것을 느끼고 있다면 당신은 NX를 시도하고 그것이 당신을 위해 작동하는지 볼 수 있습니다. 단점은 연결의 양쪽 끝에 소프트웨어를 설치해야하지만 X11은 일반적으로 이미 설치되어 있다는 것입니다.