Сколько «стоит» WebSoket request по сравнению с RESTful HTTP request?

Question

[hbrmdc]

Для осуществления каждого RESTful HTTP request, происходит инициация нового TCP соединения, затем происходит собственно request, после чего TCP соединение закрывается.
WebSocket не создает нового соединения, вместо этого он производит upgrade, используя HTTP Upgrade mechanism
Я работал в основном с RESTful HTTP, и там я старался собирать по-больше данных для единоразового осуществления запроса, чтобы снизить нагрузку на сервер, потому что считаю, что один запрос по-больше меньше грузит сервер, чем тот-же объем данных разбитый на 3-4 мелких запроса. Действуют ли те же самые правила при работе с web socket? Имеет ли смысл делать меньше запросов и получать бОльшие ответы, вместо отправки 3-4 мелких запросов? А если запросов будет 10-15?
Как измерить это?
Самый банальный пример: подгрузка данных при скролле вниз страницы - подгружать по 40 объектов за раз или 4 раза по 10 - ведь пользователь могут и не понадобиться те 30 объектов, которые не уместились на первом "экране" (без скролла вниз)

Благодарю за уделенное время!

Answer 1

[nirvimel]

Для осуществления каждого RESTful HTTP request, происходит инициация нового TCP соединения, затем происходит собственно request, после чего TCP соединение закрывается.

Это не верно для HTTP 1.1. Смотрите Постоянное HTTP-соединение

Действуют ли те же самые правила при работе с web socket?

Преимущество WebSocket в том, что не происходит парсинг HTTP заголовков на каждый запрос и формирование заголовков в каждом ответе. После первичной установки соединения через HTTP, дальше открывается фактически raw-протокол по которому происходит передача "голых" пакетов без каких-либо заголовков. Это снижает нагрузку на сервер, на все промежуточные прокси (а значит может влиять на latency) и на клиент. Но это не то, ради чего WebSocket разрабатывался изначально. Основная проблема, для решения которой он создавался, это замена push/long-polling/comment, костылей, не приспособленного для этого HTTP.

Имеет ли смысл делать меньше запросов и получать бОльшие ответы, вместо отправки 3-4 мелких запросов?

HTTP2 полностью решает эту проблему. До его внедрения такой подход все еще актуален.

Answer 2

[Сергей]

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

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

Comments

[hbrmdc]

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

[Сергей]

Минимизация трафика.
Возможно одним запросом сделать выборку проще, чем тягаться мини запросы к бд.

Вообще в каждом конкретном случае нужно разбираться что лучше а что нет.

[hbrmdc]

что значит "разбираться что лучше а что нет"? каким объективным методом измерить это?

[Сергей]

Время обработки запроса пользователя - это самая главная метрики. Остальные придумайте сами