Вопрос или проблема
У меня запущен 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 через веб-сокеты. Давайте рассмотрим несколько возможных причин и решений для этой ситуации.
Причины задержки подключения
-
Настройка WebSocket: Убедитесь, что вы правильно настраиваете веб-сокеты в своем приложении. В частности, проверьте, что используемый вами URL для подключения начинается с
ws://
, а не сhttp://
. Это имеет значение для правильного открытия соединения. -
Отсутствие поддержки протокола на стороне x11vnc: x11vnc поддерживает веб-сокеты, но важно уточнить, что это должно быть настроено правильно. Убедитесь, что ваш x11vnc был скомпилирован с поддержкой веб-сокетов. Это можно проверить в документации или воспользоваться командой
x11vnc --version
, чтобы найти соответствующую информацию. -
Проблемы с кодировкой: Обратите внимание на поддерживаемые типы кодировки. В вашем выводе видно, что x11vnc игнорирует неподдерживаемые типы кодировки при подключении клиента noVNC. Убедитесь, что установлены кодировки, совместимые с noVNC. Попробуйте использовать
-noxdamage
при запуске x11vnc, чтобы отключить xdamage, и посмотрите, улучшится ли время подключения. -
Сетевые задержки или конфигурации: Проверьте настройки сети вашего Docker-контейнера. Убедитесь, что порты правильно проброшены и нет блокировок со стороны фаервола. Попробуйте использовать сетевой режим Docker
host
, чтобы определить, повлияет ли это на подключение.
Варианты решения
-
Попробуйте изменить команду запуска x11vnc следующим образом:
x11vnc -display :0 -forever -nopw -listen 0.0.0.0 -xkb -noxdamage
-
Если вы используете
react-vnc
, убедитесь, что URL не содержит лишних символов или неправильных параметров. Проверьте правильность адресаws://<vps_ip>:5900/
. -
Проверьте настройки веб-сервера (например, Nginx или Apache), если он используется перед вашим приложением, чтобы гарантировать правильную проксификацию веб-сокетов.
-
В логах x11vnc обратите внимание на сообщения перед созданием xdamage объекта. Это могут быть знаковые индикаторы, указывающие на проблемы с сетевым подключением или отсутствием ресурсов.
Заключение
Если после выполнения вышеперечисленных шагов проблема все еще остается, попробуйте обратиться к документации noVNC и x11vnc, а также к сообществам поддержки, так как проблема может быть специфичной для вашей конфигурации или реализации. Обязательно протестируйте каждое изменение, чтобы определить, какое из них устраняет задержку в подключении.