noVNC долго подключается к x11vnc в Docker

Вопрос или проблема

У меня запущен x11vnc внутри контейнера docker с базовым образом Alpine. (порт 5900 открыт и сопоставлен с 5900 на хосте) Я также использую Xvfb. Я запускаю x11vnc внутри контейнера с помощью этой команды

x11vnc -display :0 -forever -nopw -listen 0.0.0.0 -xkb

Я могу нормально подключаться к нему, используя обычный VNC-клиент, такой как RealVNC, без каких-либо проблем и необычных задержек. Это вывод, когда используется RealVNC

24/09/2024 15:42:00 Получено соединение от клиента 112.134.157.141
24/09/2024 15:42:00   0 других клиентов
24/09/2024 15:42:00 Обычное сокет-соединение
24/09/2024 15:42:00 Автоповтор клавиш X-сервера отключен.
24/09/2024 15:42:00   чтобы снова включить, выполните: 'xset r on' (3 раза)
24/09/2024 15:42:00 увеличено accepted_client=2 для 112.134.157.141:48624  sock=10
24/09/2024 15:42:01 Версия протокола клиента 3.8
24/09/2024 15:42:01 Протокол версии отправлен 3.8, используется 3.8
24/09/2024 15:42:01 rfbProcessClientSecurityType: выполняется обработчик для типа 1
24/09/2024 15:42:01 rfbProcessClientSecurityType: возвращая securityResult для клиента rfb версии >= 3.8
24/09/2024 15:42:01 создан объект xdamage: 0xc00026
24/09/2024 15:42:03 client_set_net: 112.134.157.141  0.0016
24/09/2024 15:42:03 rfbProcessClientNormalMessage: игнорирование неподдерживаемого типа кодирования Enc(0x00000018)
24/09/2024 15:42:03 rfbProcessClientNormalMessage: игнорирование неподдерживаемого типа кодирования Enc(0x00000016)
24/09/2024 15:42:03 rfbProcessClientNormalMessage: игнорирование неподдерживаемого типа кодирования Enc(0x00000015)
24/09/2024 15:42:03 rfbProcessClientNormalMessage: игнорирование неподдерживаемого типа кодирования Enc(0x0000000F)
24/09/2024 15:42:03 rfbProcessClientNormalMessage: игнорирование неподдерживаемого типа кодирования Enc(0xFFFFFEC6)
24/09/2024 15:42:03 Включение обновлений курсора в полноцветном режиме для клиента 112.134.157.141
24/09/2024 15:42:03 Включение расширения протокола NewFBSize для клиента 112.134.157.141
24/09/2024 15:42:03 Использование кодирования ZRLE для клиента 112.134.157.141
24/09/2024 15:42:03 Пиксельный формат для клиента 112.134.157.141:
24/09/2024 15:42:03   8 бит на пиксель, глубина 6
24/09/2024 15:42:03   настоящий цвет: макс. r 3 g 3 b 3, сдвиг r 4 g 2 b 


Но когда я пытаюсь подключиться через react-vnc (который использует noVNC), подключение занимает много времени

Это вывод от x11vnc при попытке подключения с помощью react-vnc, он зависает на "создан объект xdamage: 0xc00027" примерно на 4 минуты.

24/09/2024 15:42:43 Получено соединение от клиента 112.134.157.141
24/09/2024 15:42:43   0 других клиентов
24/09/2024 15:42:43 Получено 'ws' рукостискание WebSockets
24/09/2024 15:42:43   - webSocketsHandshake: используется бинарное/сырое кодирование
24/09/2024 15:42:43   - Версия клиента WebSockets hybi-13
24/09/2024 15:42:43 Автоповтор клавиш X-сервера отключен.
24/09/2024 15:42:43   чтобы снова включить, выполните: 'xset r on' (3 раза)
24/09/2024 15:42:43 увеличено accepted_client=3 для 112.134.157.141:47494  sock=10
24/09/2024 15:42:43 создан объект xdamage: 0xc00027
24/09/2024 15:46:42 hybiReadHeader: чтение; Соединение сброшено соперником
24/09/2024 15:46:42 rfbProcessClientProtocolVersion: чтение: Соединение сброшено соперником
24/09/2024 15:46:42 количество клиентов: 0
24/09/2024 15:46:42 Восстановлен автоповтор клавиш X-сервера: 1
24/09/2024 15:46:42 Клиент 112.134.157.141 отключен
24/09/2024 15:46:42 Статистика             события    Передача/ СыройЭквивалент (сохранено)
24/09/2024 15:46:42  ИТОГО             :      0 |         0/        0 (  0.0%)
24/09/2024 15:46:42 Статистика             события    Получено/ СыройЭквивалент (сохранено)
24/09/2024 15:46:42  ИТОГО             :      0 |         0/        0 (  0.0%)
24/09/2024 15:46:45 уничтожен объект xdamage: 0xc00027

он зависает на “создан объект xdamage: 0xc00027” примерно на 4 минуты. И начинает работать после “соединение сброшено соперником

Вот как выглядит реализация next.js.

"use client";

import React, { useRef } from 'react';
import { VncScreen } from 'react-vnc';

function App() {
  const ref = useRef();

  return (
    <VncScreen
      url="ws://<vps_ip>:5900/"
      scaleViewport
      background="#000000"
      style={{
        width: '100vw',
        height: '100vh',
      }}
      ref={ref}
    />
  );
}

экспортировать по умолчанию App;
в Chrome я также получаю это предупреждение

"index.es.js:9621 Подключение WebSocket к 'ws://<vps_ip>:5900/' не удалось: WebSocket закрыт до установления соединения.
close   @   index.es.js:9621
"

Это нормально, если нет, как это исправить

Ответ или решение

Проблема, с которой вы столкнулись, связана с длительным временем подключения noVNC к x11vnc через веб-сокеты. Давайте рассмотрим несколько возможных причин и решений для этой ситуации.

Причины задержки подключения

  1. Настройка WebSocket: Убедитесь, что вы правильно настраиваете веб-сокеты в своем приложении. В частности, проверьте, что используемый вами URL для подключения начинается с ws://, а не с http://. Это имеет значение для правильного открытия соединения.

  2. Отсутствие поддержки протокола на стороне x11vnc: x11vnc поддерживает веб-сокеты, но важно уточнить, что это должно быть настроено правильно. Убедитесь, что ваш x11vnc был скомпилирован с поддержкой веб-сокетов. Это можно проверить в документации или воспользоваться командой x11vnc --version, чтобы найти соответствующую информацию.

  3. Проблемы с кодировкой: Обратите внимание на поддерживаемые типы кодировки. В вашем выводе видно, что x11vnc игнорирует неподдерживаемые типы кодировки при подключении клиента noVNC. Убедитесь, что установлены кодировки, совместимые с noVNC. Попробуйте использовать -noxdamage при запуске x11vnc, чтобы отключить xdamage, и посмотрите, улучшится ли время подключения.

  4. Сетевые задержки или конфигурации: Проверьте настройки сети вашего Docker-контейнера. Убедитесь, что порты правильно проброшены и нет блокировок со стороны фаервола. Попробуйте использовать сетевой режим Docker host, чтобы определить, повлияет ли это на подключение.

Варианты решения

  1. Попробуйте изменить команду запуска x11vnc следующим образом:

    x11vnc -display :0 -forever -nopw -listen 0.0.0.0 -xkb -noxdamage
  2. Если вы используете react-vnc, убедитесь, что URL не содержит лишних символов или неправильных параметров. Проверьте правильность адреса ws://<vps_ip>:5900/.

  3. Проверьте настройки веб-сервера (например, Nginx или Apache), если он используется перед вашим приложением, чтобы гарантировать правильную проксификацию веб-сокетов.

  4. В логах x11vnc обратите внимание на сообщения перед созданием xdamage объекта. Это могут быть знаковые индикаторы, указывающие на проблемы с сетевым подключением или отсутствием ресурсов.

Заключение

Если после выполнения вышеперечисленных шагов проблема все еще остается, попробуйте обратиться к документации noVNC и x11vnc, а также к сообществам поддержки, так как проблема может быть специфичной для вашей конфигурации или реализации. Обязательно протестируйте каждое изменение, чтобы определить, какое из них устраняет задержку в подключении.

Оцените материал
Добавить комментарий

Капча загружается...