Стоимость защищенного websocket и небезопасного websocket

В настоящее время я разрабатываю многопользовательскую игру на основе браузера, в которой используется WebSockets. Мои самые высокие приоритеты - низкая латентность и совместимость с широким спектром платформ и сетевых настроек.

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

Как будет влиять на производительность TLS-шифрование соединения веб-сокета? Обратите внимание, что я часто отправляю очень маленькие, но очень важные сообщения.
будет wss://работать в любой среде, где ws://работает или мне нужен резервный механизм?

Или, может быть, было бы разумнее использовать мой прецедент для шифрования на уровне приложения?

Ответ 1

WSS будет работать в значительно более широких сетевых средах, чем WS, из-за того, что прокси и другие посредники не понимают или активно блокируют WebSocket.

Что касается дополнительной задержки, введенной TLS, я бы ожидал, что она будет незначительной по сравнению с задержкой, которую вы получаете от WAN-соединений в любом случае (это примерно 10-250 мс RTT).

Что касается пропускной способности, поскольку TLS использует симметричные шифры для шифрования полезной нагрузки, я бы не ожидал накладных расходов.

TLS явно потребляет циклы процессора, но, учитывая текущую мощность процессора, часто это не проблема.

Реализация собственного шифрования не имеет смысла.. если вы не заботитесь о конфиденциальности в конце концов, но тогда вы не сможете ничего делать на стороне сервера (помимо отправки другим клиентам).

Короче: перейдите к WSS.

Я написал сообщение в блоге о служебных ресурсах WebSocket (включая сравнение с TLS vs non-TLS): http://tavendo.com/blog/post/dissecting-websocket-overhead/

Ответ 2

Несколько лет назад я провел исследование производительности, которое показало, что SSL через Интернет было всего в 3 раза медленнее, чем обычный текст. Я ожидаю, что разрыв будет сокращаться с тех пор из-за улучшения аппаратной скорости.

Я бы не рекомендовал вам внедрять собственное шифрование, когда SSL уже существует. У вас нет оснований полагать, что это будет быстрее, чем SSL, и вы почти наверняка примете недостатки безопасности, которых нет в SSL.