Огромная задержка на веб-сокетах https (wss)

Я работаю над браузерной ммо-игрой под названием mope.io (игра доступна по адресу https://mope.io). ) — мы недавно добавили поддержку https, но заметили ОГРОМНУЮ задержку по сравнению с веб-сокетами wss. На многих наших игровых серверах с https (проблема, кажется, возникает случайным образом на некоторых серверах) на wss возникает задержка в несколько секунд, которой раньше не было на ws.

Краткая информация: наш игровой сервер отправляет 10 пакетов обновлений в секунду, предоставляя информацию об изменениях в игре.

Мы используем cloudflare для нашего сайта (настройка Full:Strict) через наш собственный подстановочный сертификат (*.mope.io). Все наши игровые серверы имеют совпадающие DNS-записи, подпадающие под этот сертификат (чтобы веб-сокеты могли работать через https — мы подключаемся, например, к wss://server1.mope.io:7020 вместо ws://1.2.3.4: 7020). Игровые серверы написаны на Java с использованием следующей библиотеки: https://github.com/TooTallNate/Java-WebSocket

Любые идеи о причинах, по которым веб-сокеты могут работать так ужасно медленно под wss/tls? Это происходит даже тогда, когда я единственный, кто подключен к серверу. Любая помощь/руководство приветствуется :)

Дополнительная информация: я заметил 11-секундное время до первого байта для первого https-запроса при подключении к сайту до того, как cloudflare кэшировал его, что может быть причиной этого!?


java ssl cloudflare latency java-websocket
person Stan Tatarnykov    schedule 17.03.2017    source источник
comment
Вы разработчик mope.io?   -  person NoOneIsHere    schedule 17.03.2017
comment
Делали ли вы какие-либо анализы сети, чтобы убедиться, что сервер не перегружен другими пакетами?   -  person efekctive    schedule 17.03.2017
comment
Да, это Clickstan, ведущий разработчик mope.io.   -  person Stan Tatarnykov    schedule 18.03.2017
comment
efekctive, На данный момент нет, мне нужно найти воспроизводимый тестовый пример и отладить его, чтобы найти точную точку в библиотеке, где возникает эта большая задержка.   -  person Stan Tatarnykov    schedule 18.03.2017
comment
Вы так и не нашли решения для этого? (Я заметил, что mope.io сейчас не https). У меня такая же проблема с моей игрой .io - я использую Java и ту же библиотеку WebSocket, ха-ха. Я думаю, что это может быть неразрешимой проблемой TLS, которая на самом деле не предназначена для частоты, на которой работают игры .io. В моей игре есть логин, поэтому сайт явно помечен как небезопасный.   -  person rococo    schedule 14.08.2018
comment
Я не делал, я просто отключил https на данный момент   -  person Stan Tatarnykov    schedule 14.03.2019

Ответы (1)


arrow_upward
1
arrow_downward

У моего друга была похожая проблема на его игровом сервере Node.js wss, и он подозревал, что это DoS-атака. Ему удалось воспроизвести «зависание» на своем сервере только с одним компьютером, быстро открывая WSS-соединения. Я не уверен, влияет ли это только на безопасные серверы веб-сокетов или как на небезопасные, так и на безопасные.

Проблема возникла как в библиотеке WS, так и в библиотеке UWS. В библиотеке websockets/ws задержка происходила даже при отклонении соединений на verifyClient(), чтобы предотвратить попадание в собственную логику обработки соединений приложений (что может быть разумным объяснением задержки), поэтому мне интересно, может ли узкое место быть где-то в узлах, лежащих в основе сокетов с обработкой безопасных соединений.

Наше решение для предотвращения зависания состояло в том, чтобы настроить iptables с ограничением скорости. Замените 1234 на порт вашего сервера.

sudo iptables -I INPUT -p tcp --dport 1234 -m state --state NEW -m recent --set
sudo iptables -I INPUT -p tcp --dport 1234 -m state --state NEW -m recent --update --seconds 1 --hitcount 2 -j DROP

Это позволит 2 соединения в секунду на IP-адрес. Также при необходимости сохраните iptables, так как он сбрасывается при перезагрузке системы.

https://serverfault.com/questions/296838/traffic-filtering-for-websockets

https://debian-administration.org/article/187/Using_iptables_to_rate-limit_incoming_connections

person Community    schedule 15.05.2019