Комментарии 18
Странно слышать про такие ограничения по вебсокетам. Вот пример миллионов соединений
Кажется, вы про ограничения на сервере. А в тексте указано ограничение от браузера.
Если открыть много вкладок и в каждой по вебсокет соединению, то видимо на 200+ соединения открываться перестанут, это что из текста я понял, не было вроде про сервер сказано ничего, только про клиент.
Это вроде про серверы
ПРИМЕЧАНИЕ. Не все веб-серверы готовы к websocket-ам из коробки. Например, Rails v.5 пришлось перейти с WEBrick на Puma. При этом Puma не могла хранить больше 1024 соединений, что было исправлено в обновлении до четвертой версии только в 2019 гогоду.
Не могу себе представить сценарий, где в браузере нужно открывать сотни вебсокет соединений. Обычно открывается одно на вкладку. Может кто-то подскажет зачем?
если рассматривать статью не по названию а понимая что всё это в контексте руби то получится она не такой "странной".
не все умеют так неплохо работать c websocket навроде erlang и node.js, среди них например ruby и php.
Начнем с самого простого — Short Polling или обычная кнопка «Обновить», которую нажимает пользователь. Это очень ресурсоемкий вариант, который дает большую нагрузку на сервер и в настоящее время его использование нежелательно.
вот это намного странней.
некоторые отдают чисто статичную страницу и уже потом js подтягивает контент при нужде.
даже если есть динамичные части то всё равно за счёт кэширований это не должно вызывать сильных нагрузок. сильные нагрузки только в начале пока не прогреты кэши.
даже без кэшов динамичная страница может быстро и без сильной нагрузки генерироваться, но современная логика излишне усложнена для соответствия всяким парадигмам, хайпу и тп.
После этого веб стал «приложением», и получил название Web 2.0.
Нет. Веб 2.0 это когда пользователи стали генерировать контент.
> Нет поддержки очереди сообщений. Например, если в чате отправляются одно за другим несколько сообщений, они могут быть доставлены не по порядку
Вебсокеты то как раз по упорядочены
Гарантии доставки - обычно решается в зависимости от задачи, таймауты/пинги/сообщение что ответ принял/идемпотентность/слежение за tcp сокетом под вебсокетами/игнорирование
до всего этого аякса неплохо работали скрытые iframe в качестве асинхронных запросов для получения данных (и без всяких ограничкний на количество) . что вкупе с яваскриптом отлично генерирвало контент. просто в то время в интернеты не всех пускали. особенно всяких маркетологв. а тем, кто там обитал все эти свистоперделки ее нужны.
все эти гигантскик объемы данных можно смело резать в 2 раза минимум. и качество информации в 90% не ухудшится (ибо нечему)
Вебсокеты — это не HTTP, а долгоживущее TCP-соединение от клиента к серверу по отдельному протоколу, который так и называется — WebSockets.
Ну...HTTP — это тоже TCP, а если требуется лишь request/response, то http с keep-alive весьма похож на вебсокеты)
Если интернет соединение было на какое-то время потеряно - так же будут потеряны сообщения, которые были отправлены в это время, нельзя их "подцепить".
не верно. брал модуль w5500, отправлял через него короткие данные, отображаемые в реальном времени в браузере, вынимал , во время передачи, коннектор из w5500 секунд на 10-15, и втыкал снова, никаких потерь не происходило, в w5500 есть буфер, в котором и накапливались эти данные.
если посмотреть через wireshark, то можно заметить , что передача по ws идет с квитирование.
как по мне, то использование в лоб json и ему подобных убивает достоинство ws, если разделить передаваемую инфу по ws на части : "команда", "разделитель", "данные", то можно более полно использовать возможности js для ws, а именно "рефлексию",
типа xxx24®ddddddddd , где dddddd может быть и json и строка html
тогда
con.onmessage = function (response) {
if (typeof (response.data) === 'string')
{
var rg = /^([a-z_0-9.]{1,})\|([\s\S]*)/i;
var r = rg.exec(response.data);
try {
if (r[1].includes('.'))
{
var d = r[1].split('.');
window[d[0]][d[1]](r[2]);
} else
{
window[r[1]](r[2]);
}
} catch (er) {
console.log('ошибка ' + er.stack);
console.log('вызов ' + r[1]);
console.trace();
}
}
что позволяет вызвать любую функцию или метод из класса. с передачей туда данных.
вариант рабочий, проверенный. работает также и для шаблонов
Квитирование в ws можно заметить из без wireshark, достаточно знать что веб-сокеты идут поверх TCP. Собственно, и буфер есть в w5500 не просто так, а потому что протокол TCP его требует.
Только вот попробуйте в своём эксперименте продержать связь выключенной достаточное время для устаревания соединения в NAT. Или просто возьмите достаточно "умную" ОС, которая заметит что коннектор вынут и сбросит все сокеты.
То есть, если своей сервер, то можно настроить HTTP/2 на Apache, заюзать Server-sent events (как наиболее простое для развертывания и использования решение) и не париться?
нет необходимости обновлять каждый автобус по очереди, а достаточно обновлять данные по всем автобусам на карте раз в 20 секунд.
Short Polling или обычная кнопка «Обновить», которую нажимает пользователь. Это очень ресурсоемкий вариант, который дает большую нагрузку на сервер
у меня какое-то внутреннее противоречие возникло
Оставлю тут - https://github.com/openware/rango
Небольшой вебсокет-сервер на go транслирующий события через redis. Держит сотни тысяч соединений, легко интегрируется с Ruby и другими. Авторизация по JWT. Используем в продакшене
Убьет ли HTTP/2 лонг поллинг и вебсокеты?