상위 질문
타임라인
채팅
관점

RFB (프로토콜)

위키백과, 무료 백과사전

Remove ads

RFB(Remote FrameBuffer)는 그래픽 사용자 인터페이스에 원격으로 접근하기 위한 개방적이고 간단한 통신 프로토콜이다. 마이크로소프트 윈도우, macOS, X 윈도 시스템 및 웨이랜드를 포함한 모든 윈도 시스템 및 애플리케이션에 적용할 수 있다.

RFB는 Virtual Network Computing (VNC) 및 그 파생 제품에서 사용되는 프로토콜이다.

설명

RFB는 가상 네트워크 컴퓨터의 기반이다. 기본적으로 뷰어/클라이언트는 TCP 포트 5900을 사용하여 서버에 연결하지만(브라우저 접근의 경우 5800), 다른 포트를 사용하도록 설정할 수도 있다. 또는 서버가 "수신 모드"에서 뷰어에 연결할 수 있다(기본적으로 포트 5500). 수신 모드의 한 가지 장점은 서버 측에서 지정된 포트에 대한 접근을 허용하도록 방화벽/NAT를 구성할 필요가 없다는 것이다. 부담은 뷰어에 있으며, 서버 측에 컴퓨터 전문 지식이 없는 경우 유용하며, 뷰어 사용자는 더 많은 지식을 가질 것으로 예상된다.

RFB는 처음에는 비교적 간단한 프로토콜로 시작했지만, 개발됨에 따라 추가 기능(파일 전송 등)과 더욱 정교한 데이터 압축 및 보안 기술로 강화되었다. 다양한 VNC 클라이언트 및 서버 구현 간의 원활한 상호 호환성을 유지하기 위해 클라이언트와 서버는 최상의 RFB 버전과 둘 다 지원할 수 있는 가장 적절한 압축 및 보안 옵션을 사용하여 연결을 협상한다.

Remove ads

역사

RFB는 원래 올리베티 연구소(ORL)에서 비디오타일이라는 비동기 전송 방식 연결이 가능한 간단한 신 클라이언트가 사용할 원격 디스플레이 기술로 개발되었다. 장치를 최대한 간단하게 유지하기 위해 기존의 원격 디스플레이 기술 대신 RFB가 개발되어 사용되었다.

RFB는 VNC가 개발되면서 두 번째이자 더욱 지속적인 용도를 찾았다. VNC는 오픈 소스 소프트웨어로 출시되었고 RFB 사양은 웹에 게시되었다. 그 이후로 RFB는 누구나 사용할 수 있는 무료 프로토콜이 되었다.

2002년 ORL이 폐쇄되었을 때, VNC와 RFB의 주요 인물 중 일부는 VNC 개발을 계속하고 RFB 프로토콜을 유지하기 위해 RealVNC, Ltd.를 설립했다. 현재 RFB 프로토콜은 RealVNC 웹사이트에 게시되어 있다.

버전

RFB 프로토콜의 게시된 버전은 다음과 같다.

자세한 정보 버전, 게시자 ...

개발자는 추가 인코딩 및 보안 유형을 자유롭게 추가할 수 있지만, 숫자가 충돌하지 않도록 프로토콜 유지보수자에게 고유한 식별 번호를 예약해야 한다. 유형 번호가 충돌하면 연결 핸드셰이킹 시 혼란을 야기하고 구현 간의 상호 호환성을 깨뜨린다. 인코딩 및 보안 유형 목록은 RealVNC Ltd에서 유지 관리했으며 프로토콜 사양과 별개이므로 사양을 재발행할 필요 없이 새로운 유형을 추가할 수 있다. 2012년 12월부터 이 목록은 IANA로 넘어갔다.[1]

기존의 모든 확장을 문서화하는 것을 목표로 하는 RFB 프로토콜 사양의 커뮤니티 버전은 TigerVNC 프로젝트에서 호스팅된다.[2]

인코딩 유형

여러 인코딩이 협상의 일부이다. 일부 인코딩은 특정 확장을 처리할 수 있는 기능을 알리는 데 사용되는 의사 인코딩이다. 인코딩에는 다음이 포함된다.[2]

  • Raw
  • Zlib
  • Tight
  • XZ
  • H.264
  • Tight PNG

공개적으로 정의된 그림 기반 인코딩 중 가장 효율적인 것은 Tight 인코딩 유형이다. TightVNC에 의해 두 가지 유형의 인코딩이 정의된다: Tight 인코딩 (사각형, 팔레트, 그라데이션 채우기와 zlib 및 JPEG의 혼합, 그리고 Zlib-plus-filter "기본 압축")[3] 및 Tight PNG 인코딩 (기본 압축이 PNG 데이터로 대체된 Tight 인코딩).

RFB 데이터를 인코딩하기 위해 H.264가 연구되었지만, 초기 결과(Open H.264 형식을 사용)는 TurboVNC 개발자에 의해 만족스럽지 못하다고 묘사되었다. I-프레임(키프레임)이 적을수록 효율적이지만, CPU 사용률은 여전히 문제로 남아 있다.[4]

Remove ads

한계

클립보드 데이터 전송과 관련하여 "현재 라틴-1 문자 세트 외부의 텍스트를 전송할 방법이 없다".[5] 일반적인 의사 인코딩 확장은 확장된 형식으로 UTF-8을 사용하여 이 문제를 해결한다.[2](§ 7.7.27)

VNC 프로토콜은 픽셀 기반이다. 이는 큰 유연성(즉, 모든 유형의 데스크톱을 표시할 수 있음)을 제공하지만, X11 또는 RDP와 같은 데스크톱처럼 기본 그래픽 레이아웃을 더 잘 이해하는 솔루션보다 효율성이 떨어지는 경우가 많다. 이러한 프로토콜은 그래픽 기본 요소 또는 상위 수준 명령을 더 간단한 형식(예: 창 열기)으로 보내는 반면, RFB는 압축되었지만 원시 픽셀 데이터만 보낸다.

VNC 프로토콜은 마우스 버튼 상태를 단일 바이트로, 이진 상/하로 표현한다. 이는 마우스 버튼 수를 8개(버튼 0이 "비활성화"를 의미하는 관례를 감안하면 사실상 7개)로 제한한다. 많은 최신 마우스는 9개 이상의 버튼을 열거하므로 RFB를 통해 앞/뒤 버튼이 작동하지 않는다. "GII" 확장이 이 문제를 해결한다.[2](§ 7.7.11)

원래 프로토콜 사양은 사운드 데이터를 전혀 전송하는 방법을 정의하지 않으며, 서버가 클라이언트에서 경고음 (가청 비프음, 알림 소리)을 재생해야 한다고 신호를 보낼 수 있는 유일한 예외가 있다.[2](§ 7.6.3) 그러나 RFB 프로토콜의 커뮤니티 버전에는 "QEMU 오디오" 확장이 정의되어 있다.[2]

Remove ads

같이 보기

각주

외부 링크

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads