RFB 프로토콜

RFB protocol

RFB("원격 프레임 버퍼")는 그래픽 사용자 인터페이스에 대한 원격 액세스를 위한 개방형 단순 프로토콜이다.프레임 버퍼 레벨에서 작동하기 때문에 Microsoft Windows, MacOS, X Window 시스템을 포함한 모든 윈도우 설정 시스템과 애플리케이션에 적용할 수 있다.RFB는 VNC(Virtual Network Computing)와 그 파생상품에 사용되는 프로토콜이다.

설명

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

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

역사

RFB는 원래 ORL(Olivetti Research Laboratory)에서 원격 디스플레이 기술로 개발되어 ATM 연결성을 갖춘 단순한 씬 클라이언트가 사용하게 되었다.기기를 최대한 단순하게 유지하기 위해 기존의 어떤 리모트 디스플레이 기술보다 우선하여 RFB를 개발하여 사용하였다.

RFB는 VNC가 개발되었을 때 두 번째 그리고 더 오래 지속되는 사용을 발견했다.VNC는 오픈 소스 소프트웨어와 RFB 사양으로 웹에 게시되었다.그 이후로 RFB는 누구나 사용할 수 있는 무료 프로토콜이었습니다.

2002년 ORL이 폐쇄되었을 때 VNC와 RFB의 핵심 인물들 중 일부는 VNC의 지속적인 개발과 RFB 프로토콜 유지를 위해 RealVNC, Ltd.를 결성하였다.현재 RFB 프로토콜은 RealVNC 웹사이트에 게시되어 있다.

프로토콜 버전

RFB 프로토콜의 공개 버전은 다음과 같다.

버전 출판된 날짜 사양
RFB 3.3 ORL 1998년 1월 원격 프레임 버퍼 프로토콜 3.3
RFB 3.7 리얼VNC 2003년 8월 원격 프레임 버퍼 프로토콜 3.7
RFB 3.8(전류) 리얼VNC 2007년 6월 원격 프레임 버퍼 프로토콜 3.8
IETF RFC(3.8) 리얼VNC 2011년 3월 RFC 6143

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

모든 기존 확장을 문서화하는 것을 목적으로 하는 RFB 프로토콜 규격의 커뮤니티 버전은 TigerVNC 프로젝트에 의해 주최된다.[2]

인코딩 유형

인코딩은 협상의 일환이기 때문에 아래의 인코딩 중 일부는 일정 연장 처리 능력을 광고하는 데 사용되는 사이비인코딩이다.

RFB 인코딩[2]
숫자 인코딩
0x00000000 날것
0x00000001 복사수정
0x00000002 RRE(상승 직사각형 런 길이)
0x00000004 CoRRE(Compact RRE)
0x00000005 헥타일(RRE 변종)
0x00000006 즈립
0x00000007 꽉 끼다
0x00000008 ZlibHex(Zlib + Hextile)
0x00000009 울트라
0x00000010 ZRLE(Zlib 런 길이)
0x00000011 지월
0x00000014 H.264
0x00000032 오픈 H.264
0xFFFF0001 캐시사용
0xFFFF0006 XOREnable
0xFFFF8000 ServerState(UltraVNC)
0xFFFF8001 EnableKeepAlive(UltraVNC)
0xFFFF8002 FTProtocolVersion(파일 전송 프로토콜 버전 - UltraVNC)
0xFFFFFEC7 ContinuousUpdates
0xFFFFFEC8 울타리
0xFFFFFECC ExtendedDesktopSize
0xFFFFFECF 일반 입력 인터페이스(GII)
0xFFFFFF00-0xFFFFF09 압축 수준(엄격한 인코딩)
0xFFFFFF10 XCursor
0xFFFFFF11 리치 커서
0xFFFFFF18 포인터포스
0xFFFFFF20 마지막 수정
0xFFFFFF21 뉴FBSize
0xFFFFFF74 타이트한 PNG
0xFFFFFFE0–0xFFFFFFFE9 QualityLevel(엄격한 인코딩)

공개적으로 정의된 그림 기반 인코딩 중 가장 효율적인 인코딩 유형은 타이트한 인코딩 유형이다.TightVNC에 의해 두 가지 유형의 인코딩이 정의된다.

  • 직사각형, 팔레트 및 그라데이션 채우기, zlib와 JPEG가 혼합된 Tight Encoding과 Zlib-plus-filter "기본 압축"[3]을 더한 것이다.
  • 엄격한 PNG 인코딩, 기본 압축으로 엄격한 인코딩을 PNG 데이터로 대체.

RFB 데이터의 인코딩을 위해 H.264가 연구되었지만, TurboVNC 개발자에 의해 예비 결과(오픈 H.264 포맷 사용)가 부진한 것으로 설명되었다.더 적은 I-프레임(키프레임)으로 더 효율적이 되긴 하지만 CPU 활용도는 여전히 문제로 남아 있다.[4]

제한 사항

클립보드 데이터 전송의 경우, "현재 라틴-1 문자 집합 외부에서는 텍스트를 전송할 수 있는 방법이 없다."[5]일반적인 의사 암호 확장자는 UTF-8을 확장된 형식으로 사용하여 문제를 해결한다.[2]: § 7.7.27

VNC 프로토콜은 픽셀 기반이다.이는 뛰어난 유연성(즉, 어떤 유형의 데스크톱도 표시할 수 있음)으로 이어지지만 X11과 같은 기본 그래픽 레이아웃이나 RDP와 같은 데스크톱을 더 잘 이해하는 솔루션보다 효율성이 떨어지는 경우가 많다.이러한 프로토콜은 그래픽 원시 요소 또는 상위 수준의 명령을 더 단순한 형태(예: 열린 창)로 전송하는 반면, RFB는 압축되더라도 원시 픽셀 데이터만 전송한다.

VNC 프로토콜은 마우스 버튼 상태를 단일 바이트로 바이너리 위/아래로 표현한다.이것은 마우스 버튼의 수를 8개로 제한한다(효과적으로 "사용 안 함"을 의미하는 버튼 0의 관례에 따라 7개).현대의 많은 마우스들은 9개 이상의 버튼을 열거하여, 앞으로/뒤로 버튼이 RFB에 영향을 미치지 않게 한다."GII" 확장이 이 문제를 해결한다.[2]: § 7.7.11

참고 항목

참조

  1. ^ "Remote Framebuffer (RFB)". www.iana.org.
  2. ^ a b c d "The RFB Protocol, Community Edition". GitHub.
  3. ^ "VNC Tight Encoder - Comparison Results". www.tightvnc.com.
  4. ^ Commander, DR. "A Study on the Usefulness of H.264 Encoding in a VNC Environment". turbovnc.org.
  5. ^ Richardson, Tristan (2010). "Sections 6.4.6, 6.5.4". The RFB Protocol - Version 3.8.

외부 링크