Какие дополнительные накладные расходы возникают при отправке пакета через соединение через веб-сокет?

При выполнении запросов AJAX я всегда старался сделать как можно меньше, поскольку каждый запрос требует открытия http-соединения для отправки данных. Поскольку соединение через веб-сокет постоянно открыто, есть ли какие-либо затраты, помимо очевидной пропускной способности пакета, для отправки запроса?

Например. В течение 1 минуты клиент отправляет на сервер 100 КБ данных. Если предположить, что клиенту не нужен ответ ни на один из этих запросов, есть ли какое-либо преимущество в том, чтобы ставить пакеты в очередь и отправлять их одним большим пакетом по сравнению с отправкой их по мере их готовности?

Другими словами, есть ли накладные расходы на остановку и запуск передачи данных для постоянно открытого соединения?

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


person Dan Hastings    schedule 20.01.2017    source источник


Ответы (1)


Вы правы в том, что сообщение webSocket будет иметь меньшие накладные расходы для данной передачи сообщения, чем отправка того же сообщения через вызов Ajax, потому что соединение с веб-сокетом уже установлено и поскольку сообщение веб-сокета имеет меньшие накладные расходы, чем HTTP-запрос.

Во-первых, всегда меньше накладных расходов при отправке одной большой передачи по сравнению с отправкой множества меньших передач. Такова природа TCP. Каждый TCP-пакет обрабатывается и подтверждается отдельно, поэтому отправка большего количества пакетов требует немного больше накладных расходов. Является ли эта разница актуальной или существенной и стоит ли писать дополнительный код или стоит ли жертвовать каким-то элементом вашего пользовательского опыта (из-за задержки пакетной обработки), полностью зависит от специфики данной ситуации.

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

К вашему сведению, из-за реализации алгоритма Нагеля в большинстве реализаций TCP стек TCP сам выполняет небольшую пакетную обработку для вас, если вы отправляете несколько запросов, довольно близко расположенных во времени, или если вы отправляете по более медленному каналу.

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

person jfriend00    schedule 20.01.2017
comment
@DanHastings - это ответило на ваш вопрос? - person jfriend00; 24.03.2017
comment
Не спрашивающий, но он определенно ответил на мой! - person jhpratt; 07.08.2017