RFB-протокол
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
RFB (« удаленный фреймбуфер ») — открытый простой протокол удаленного доступа к графическим пользовательским интерфейсам . Поскольку он работает на уровне кадрового буфера , он применим ко всем оконным системам и приложениям, включая Microsoft Windows , macOS , X Window System и Wayland . RFB — это протокол, используемый в виртуальных сетевых вычислениях (VNC) и его производных.
Описание
[ редактировать ]По умолчанию программа просмотра/клиент использует TCP-порт 5900 для подключения к серверу (или 5800 для доступа через браузер), но также можно настроить использование любого другого порта. Альтернативно, сервер может подключиться к средству просмотра в «режиме прослушивания» (по умолчанию через порт 5500). Одним из преимуществ режима прослушивания является то, что сайту сервера не нужно настраивать свой брандмауэр/NAT для разрешения доступа к указанным портам; бремя ложится на зрителя, что полезно, если у сервера нет опыта работы с компьютером, тогда как ожидается, что пользователь-просмотрщик будет более осведомлен.
он был расширен дополнительными функциями (такими как передача файлов) и более сложными методами сжатия Хотя RFB начинался как относительно простой протокол, по мере его развития и безопасности. Чтобы обеспечить беспрепятственную перекрестную совместимость между множеством различных реализаций клиента и сервера VNC, клиенты и серверы согласовывают соединение, используя лучшую версию RFB, а также наиболее подходящие параметры сжатия и безопасности, которые они оба могут поддерживать.
История
[ редактировать ]Первоначально RFB был разработан в исследовательской лаборатории Olivetti (ORL) как технология удаленного отображения, которая будет использоваться простым тонким клиентом с возможностью подключения в асинхронном режиме передачи, называемым Videotile. Чтобы сделать устройство максимально простым, RFB был разработан и использовался вместо любой из существующих технологий удаленного отображения.
RFB нашел второе, более устойчивое применение, когда был разработан VNC. VNC был выпущен как программное обеспечение с открытым исходным кодом , а спецификация RFB опубликована в Интернете. С тех пор RFB стал свободным протоколом, который может использовать каждый.
Когда ORL был закрыт в 2002 году, некоторые из ключевых людей, стоящих за VNC и RFB, сформировали RealVNC , Ltd., чтобы продолжить развитие VNC и поддерживать протокол RFB. Действующий протокол RFB опубликован на сайте RealVNC .
Версии протокола
[ редактировать ]Опубликованные версии протокола RFB следующие:
| Версия | Опубликовано | Дата | Спецификация |
|---|---|---|---|
| РФБ 3.3 | ОРЛ | Январь 1998 г. | Протокол удаленного фреймбуфера 3.3 |
| РФБ 3.7 | ООО «РеалВНК» | август 2003 г. | Протокол удаленного фреймбуфера 3.7 |
| РФБ 3.8 (текущий) | ООО «РеалВНК» | июнь 2007 г. | Протокол удаленного фреймбуфера 3.8 |
| IETF RFC (3.8) | ООО «РеалВНК» | март 2011 г. | RFC 6143 |
Разработчики могут добавлять дополнительные типы кодирования и безопасности, но они должны забронировать для них уникальные идентификационные номера у сопровождающих протокола, чтобы номера не конфликтовали. Конфликтующие номера типов могут привести к путанице при установлении соединения и нарушить перекрестную совместимость между реализациями. Список типов кодирования и безопасности поддерживается компанией RealVNC Ltd и отделен от спецификации протокола, поэтому новые типы могут быть добавлены без необходимости переиздания спецификации. С декабря 2012 года список перешел в IANA . [1]
Сообщественная версия спецификации протокола RFB, целью которой является документирование всех существующих расширений, размещена в проекте TigerVNC . [2]
Типы кодирования
[ редактировать ]Поскольку кодировки являются частью согласования, некоторые из приведенных ниже кодировок являются псевдокодировками, используемыми для объявления возможности обработки определенного расширения.
| Число | Кодирование |
|---|---|
| 0x00000000 | Сырой |
| 0x00000001 | Копирект |
| 0x00000002 | RRE (длина восходящего прямоугольника) |
| 0x00000004 | CoRRE (Компактный RRE) |
| 0x00000005 | Шестигранник (вариант RRE) |
| 0x00000006 | Злиб |
| 0x00000007 | Тугой |
| 0x00000008 | ZlibHex (Zlib + Hextile) |
| 0x00000009 | Ультра |
| 0x00000010 | ZRLE (длина Zlib) |
| 0x00000011 | ЗИВРЛЕ |
| 0x00000014 | H.264 |
| 0x00000032 | Открыть H.264 |
| 0xFFFF0001 | КэшВключить |
| 0xFFFF0006 | XOREnable |
| 0xFFFF8000 | Состояние Сервера (UltraVNC) |
| 0xFFFF8001 | ВключитьKeepAlive (UltraVNC) |
| 0xFFFF8002 | FTProtocolVersion (версия протокола передачи файлов — UltraVNC) |
| 0xFFFFFC7 | Непрерывные обновления |
| 0xFFFFFC8 | Изгородь |
| 0xFFFFFECC | Расширенный размер рабочего стола |
| 0xFFFFFECF | Общий входной интерфейс (GII) |
| 0xFFFFFF00–0xFFFFFF09 | CompressLevel (жесткое кодирование) |
| 0xFFFFFF10 | XКурсор |
| 0xFFFFFF11 | РичКурсор |
| 0xFFFFFF18 | УказательПос |
| 0xFFFFFF20 | ЛастРект |
| 0xFFFFFF21 | НовыйFBSize |
| 0xFFFFFF74 | PNG |
| 0xFFFFFFE0–0xFFFFFE9 | QualityLevel (жесткое кодирование) |
Из общедоступных кодировок на основе изображений наиболее эффективными являются типы кодирования Tight. TightVNC определяет два типа кодировок:
- Tight Encoding, смесь прямоугольников, палитры и градиентной заливки с zlib и JPEG, а также «базовое сжатие» Zlib-plus-filter. [3]
- Жесткое кодирование PNG. Жесткое кодирование с базовым сжатием, замененным данными PNG .
H.264 был исследован для кодирования данных RFB, но предварительные результаты (с использованием формата Open H.264) были описаны разработчиком TurboVNC как неудовлетворительные . Он становится более эффективным с меньшим количеством I-кадров (ключевых кадров), но загрузка ЦП остается проблемой. [4]
Ограничения
[ редактировать ]Что касается передачи данных буфера обмена, «в настоящее время нет возможности передавать текст за пределами набора символов Latin-1». [5] Общее расширение псевдокодировки решает проблему, используя UTF-8 в расширенном формате. [2] : § 7.7.27
Протокол VNC основан на пикселях. Хотя это обеспечивает большую гибкость (т. е. может отображаться любой тип рабочего стола), это часто менее эффективно, чем решения, которые лучше понимают базовый графический макет, такой как X11 , или рабочий стол, такой как RDP . Эти протоколы отправляют графические примитивы или команды высокого уровня в более простой форме (например, открытое окно), тогда как RFB просто отправляет необработанные пиксельные данные, хотя и сжатые.
Протокол VNC выражает состояние кнопки мыши в одном байте, как двоичное вверх/вниз. Это ограничивает количество кнопок мыши до восьми (фактически до 7, учитывая соглашение о том, что кнопка 0 означает «отключена»). Многие современные мыши имеют 9 или более кнопок, в результате чего кнопки вперед/назад не влияют на RFB. Расширение «GII» решает эту проблему. [2] : § 7.7.11
Стандарта для передачи звуковых данных вообще не существует, за единственным исключением: сервер может сигнализировать о том, что звонок (звуковой сигнал, звуковое уведомление). клиент должен воспроизвести [2] : § 7.6.3
См. также
[ редактировать ]- Сравнение программного обеспечения для удаленного рабочего стола
- Технология NX и Xpra для эффективного удаленного подключения к системе X Window
- СПАЙС
- Протокол удаленного рабочего стола (RDP)
Ссылки
[ редактировать ]- ^ «Удаленный кадровый буфер (RFB)» . www.iana.org .
- ^ Jump up to: а б с д и «Протокол RFB, Community Edition» . Гитхаб . 8 августа 2022 г.
- ^ «VNC Tight Encoder — результаты сравнения» . www.tightvnc.com .
- ^ Командир, ДР. «Исследование полезности кодирования H.264 в среде VNC» . www.turbovnc.org .
- ^ Ричардсон, Тристан (2010). «Разделы 6.4.6, 6.5.4». Протокол RFB — версия 3.8 .