Нужно ли сжимать короткие сообщения Websocket?

Question

Я работаю над игровым проектом, который использует Websocket для общения. Back end - это загрузочное приложение Spring. Прямо сейчас пример сообщения будет выглядеть так:

{ "Тип": "EnemyHpChange", "идентификатор": 0, "значение": - 5}

Как видите, сообщение можно легко сократить до 2 байтов в двоичном формате, возможно, использовать 6 бит для типа сообщения, 2 бита для идентификатора и т. Д.

Уменьшение задержки представляет интерес для меня, поскольку это игра, но насколько быстрее она сжимает подобное сообщение?

Answer 1

Есть две вещи, которые следует учитывать:

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

2. Только тесты могут правильно наблюдать за изменениями производительности. Теории хороши, но под капотом есть сложные оптимизации, которые дают непредвиденные эффекты.

Сетевая задержка

Причиной теории является MTU для пакетов TCP / IP. Вероятно, оба сообщения помещаются в один пакет, поэтому сетевой уровень может вести себя одинаково.

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

Я не уверен, но, насколько я помню, значения MTU в дикой природе часто составляют около 500 байтов или меньше.

Время ожидания парсера

С другой стороны, когда клиент получает данные, двоичные данные часто быстрее и проще анализировать, чем JSON.

Это очень короткие сообщения, но, тем не менее, вполне вероятно, что потребление памяти и скорость синтаксического анализа будут влиять на воспринимаемую задержку, пока клиент идет.

Обратите внимание, что воспринимаемая задержка не меняет сетевую задержку, но отзывчивость клиента и скорость, с которой событие преобразуется в воспринимаемое изменение состояния.