На сколько ресурсоемко использовать сокеты вместо ajax?

Question

[WebDev]

У нас сайт SPA и мы довольно часто релизим обновления. Из-за особенностей SPA , пользователи не получают обновлений, пока намеренно не обновят страницу. Есть и такие, кто по несколько дней не обновляет и пишет в поддержку, что о новой фиче написали, а у него ее нет.
Решили выводить сообщение, что есть изменения и нужно перезагрузить страницу.
Тут два варианта: слать запрос Аяксом каждую минуту, например. Или устанавливать для всех пользователей сокет соединение.
Соединение конечно лучше, там сообщение пользователь получит мгновенно, но как дела обстоят с нагрузкой? Сколько такие пустые соединения будут расходовать ресурсов и стоит ли их использовать вместо ajax?

Comments

[Владимир Коротенко]

Число портов ограничено 65536. Ну и держать постоянно открытое соединение то-же напряжно для сервера.
Что же до проверки, ничего не нужно вводить дополнительно. Просто добавьте заголовок X-Last-Modify: и записывайте туда Unix timestamp.

На клиенте настройте Intercept и при изменении значения перезагружайте клиента.

Для axios подробно описано в документации.
https://github.com/axios/axios

[shai_hulud]

Владимир Коротенко

> Число портов ограничено 65536.
Как вообще это может быть связано с вопросом автора? Просто "факт дня" на заметку?

> Ну и держать постоянно открытое соединение то-же напряжно для сервера.
Чем "напряжно"? Чем это более напряжно относительно и постоянных запросов?

[Владимир Коротенко]

Вы таки плохо читаете? Максимальное количество сессий 65k, все дальше порты закончились и приходиться добавлять еще 1 IP и еще один.

Постоянные запросы тем и хороши что они отработали и уступили место другим.

И мы еще не рассматриваем таблицы ядра и лимиты на файловые дескрипторы.

Тем более что спа что то там делает постоянно, отдал получил.

Так что при сокетах мы получаем концептуальное бытылочное горлышко.

[shai_hulud]

Владимир Коротенко, Хорошо читаю. Ничего подобного нет. TCP соединение ака "сессия" идентифицируется уникальной четверкой значений, remote_ip, remote_port, local_ip, local_port,
Для клиента, что бы открыть соединение, надо забиндить один айпи и один порт, для сервера просто слушать один айпи и один порт. На один порт сервера можно открыть практически любое (2^32 * 2^16) количество соединений. Файловые дескрипторы выставляются в бесконечность. Хардовый лимит в предел (1кк или больше).
О каких 65536 портах вы тут говорите не понятно.

Вот почитайте IP - https://tools.ietf.org/html/rfc791, TCP - https://tools.ietf.org/html/rfc793

Вот демо, для тех кто не умеет читать мануалы.

Понаберут по объявлениям, потом читай их бред в комментах.

[Владимир Коротенко]

shai_hulud, В вашем примере черным по белому написано
Как это ни странно, обеспечить необходимую нагрузку было сложнее, чем создать сервер. Дело в том, что TCP-соединение уникально определяется четверкой [source ip, source port, dest ip, dest port], таким образом с одной машины на 1 порт сервера можно создать не более 64 тыс одновременных соединений (по количеству source ports). Можно было бы создать 16 сетевых интерфейсов с разными IP, как было описано здесь, но это сложно когда машинка стоит у хостера.
Вы читать не умеете? Или вы все это хозяйство предполагаете обработать на одном сервере?

[shai_hulud]

Владимир Коротенко, Да там написано что КЛИЕНТ не может открыть больше соединений чем доступно эфемерных портов. Советую открыть те ссылки выше и почитать внимательнее.

Почитать и подумать, как ограничение на эфемерные порты на КЛИЕНТЕ относится к тому что автор на СЕРВЕРЕ хочет получать WS соединения? И ответить по существу.

[Владимир Коротенко]

Client -> (тут хоть обсоединяйся) Nginx -> (а вот здесь вы поймаете лимит) API-SRV -> DB

[Владимир Коротенко]

Но зачем на ровном месте создавать проблему, а потом ее героически решать?

Answer 1

[Roman K]

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

Добавь в бэкенд глобальный заголовок, типа "X-Build: 2019-11-07T12:06:40", который будет означать дату сборки бэкенда (придётся при выкатке фронта выкатывать и бэк в одно время). Дату сборки получаешь или из последнего коммита гита (кстати, можно хоть даже хэш коммита вместо даты), или прямо при сборке образа класть файлик с текущей датой. При первом запросе в стейте SPA устанавливаешь дату сборки, все последующие любые запросы в бэк смотришь, не изменился ли заголовок. Если изменился — вот тебе изменения, которые должны повлечь релоад страницы, показывай попапы.

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

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

Comments

[Asen]

Так себе решение: это при каждом запросе придется держать в уме, что нужно чекнуть хедер (централизация может даже не спасти), потом, зубодробительные UX в случае, когда пользователь запросил данные, а получил релоад. Куда надёжнее и гранулярнее будет периодическая посылка аякс-запроса

[Roman K]

Asen, /facepalm

Ты запросы делаешь через единственный инстанс какого-нибудь axios'а. Что тебе мешает в этом единственном месте чекать хэдер? Кто тебя заставляет релоадить страницу? Показывай попап или чё хочешь делай. Продолжать думать за тебя?

[Asen]

Roman Kitaev, за меня не нужно, попробуй сам: что в SPA вообще должно провоцировать отправку бизнес-запросов (с которыми должен прийти заголовок), если страница "висит по нескольку дней открытой"? Это все последствия одной проблемы, которой ты, к сожалению, не улавливаешь

[Roman K]

Asen, а зачем обновлять страницу, которая неделями висит? Обнови её тогда, когда пользователь начнет ей пользоваться.

Answer 2

[Олег]

65 тысяч портов на одном IP
Я попутал стандартные сокеты с ws.
При работе с вебсокетами, после хендшекинга возвращается дескриптор на поток.
Их тоже не бесконечное количество, но 500К доступных вполне можно расчитывать.

Comments

[Олег]

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

Сокеты, чтобы получил мгновенно, нужны постоянно открытые.
Значит на одном порту клиент здоровается с сервером и получает номер
порта беседы. Номер порта целове безнаковое 2 байта. 65 тысяч (про нижнюю 1024 зарезервированных пока забудем)
Веб сокеты из js всегда шлют http заголовки. Фактически это эмуляция постоянного соединения поверх http

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

[WebDev]

Олег, Но лимита в 65К подключенных клиентов нет, верно?

Answer 3

[Александр Александрович]

В текущем проекте шлём Ajax, не на API, а к статическому файлу `manifest.json`, где дополнительно указываем параметры, номер сборки, включен ли режим обслуживания и т.п.