В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения )
|
RFB (« удаленный буфер кадра ») — это открытый простой протокол для удаленного доступа к графическим пользовательским интерфейсам . Поскольку он работает на уровне буфера кадра, он применим ко всем оконным системам и приложениям, включая Microsoft Windows , macOS , X Window System и Wayland . RFB — это протокол, используемый в Virtual Network Computing (VNC) и его производных.
По умолчанию зритель/клиент использует порт TCP 5900 для подключения к серверу (или 5800 для доступа через браузер), но также может быть настроен на использование любого другого порта. В качестве альтернативы сервер может подключиться к зрителю в «режиме прослушивания» (по умолчанию на порту 5500). Одним из преимуществ режима прослушивания является то, что серверному сайту не нужно настраивать свой брандмауэр/NAT для разрешения доступа через указанные порты; вся нагрузка ложится на зрителя, что полезно, если на сервере нет компьютерных знаний, в то время как пользователь-зритель, как ожидается, будет более осведомлен.
Хотя RFB начинался как относительно простой протокол, он был улучшен дополнительными функциями (такими как передача файлов) и более сложными методами сжатия и безопасности по мере своего развития. Для поддержания бесшовной кросс-совместимости между множеством различных реализаций клиента и сервера VNC клиенты и серверы согласовывают соединение, используя лучшую версию RFB и наиболее подходящие параметры сжатия и безопасности, которые они оба могут поддерживать.
RFB изначально была разработана в Olivetti Research Laboratory (ORL) как технология удаленного отображения, которая будет использоваться простым тонким клиентом с подключением Asynchronous Transfer Mode, называемым 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 | RealVNC Ltd | Август 2003 г. | Протокол удаленного кадрового буфера 3.7 |
РФБ 3.8 (текущий) | RealVNC Ltd | Июнь 2007 г. | Протокол удаленного кадрового буфера 3.8 |
Запрос предложений IETF (3.8) | RealVNC Ltd | Март 2011 г. | RFC6143 |
Разработчики могут свободно добавлять дополнительные типы кодирования и безопасности, но они должны зарезервировать для них уникальные идентификационные номера у сопровождающих протокола, чтобы номера не конфликтовали. Конфликтующие номера типов могут вызвать путаницу при установлении связи и нарушить кросс-совместимость между реализациями. Список типов кодирования и безопасности поддерживался RealVNC Ltd и отделен от спецификации протокола, так что новые типы могут быть добавлены без необходимости переиздания спецификации. С декабря 2012 года список был передан IANA . [1]
Общественная версия спецификации протокола RFB, направленная на документирование всех существующих расширений, размещена в проекте TigerVNC . [2]
Несколько кодировок являются частью переговоров. Некоторые из кодировок являются псевдокодировками, используемыми для рекламы возможности обработки определенного расширения. [ необходима цитата ] Кодировки включают: [2]
Из публично определенных кодировок на основе изображений наиболее эффективными являются типы кодирования Tight. TightVNC определяет два типа кодировок: Tight Encoding (смесь прямоугольника, палитры и градиентной заливки с zlib и JPEG, плюс «базовое сжатие» Zlib-plus-filter) [3] и Tight PNG Encoding (жесткое кодирование с базовым сжатием, замененным данными 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