Comments 17
Мне кажется у вас не Real Time, а Near Real Time.
У Real-Time систем есть жесткие ограничения по скорости работы, например некое событие должно быть обработано за 1мс и не микросекундой позже, иначе - авария. Такие системы не пишутся на языках со сборщиками мусора и даже операционная система может требоваться другая, чтобы какой-то другой процесс не украл в неподходящий момент процессорное время.
Сообщения в соцсетях и даже пакеты в онлайн играх не имеют таких требований: небольшой лаг может быть неприятным для пользователя, но не критичным.
Риалтайм у вас странный, имхо. Начать стоит, например, отсюда https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8
То, что у вас описано - просто асинхронщина, с риалтаймом ничего общего не имеющая
почему так сурово? любые события на сервере позволяют отправлять сообщения сразу клиенту, время на транспортировку сообщения в сети минимально, даже из-за того что "кпд" сообщения близко к 100%. передается минимум служебной информации самого протокола. время на обработку - оно будет практически одинаково для любой системы ( если не считать специально заточенных только под одну задачу).
Почему тогда web-socket не используется повсеместно, вместо http ? наверное есть причины
WebSocket используется когда необходимо обновлять данные в онлайн режиме. Логично использовать WebSocket в SPA приложениях. Вместо http его использовать не получится, поскольку WebSocket работает поверх http.
Для того чтобы клиент получал данные от сервера (например, список товаров) вполне хорошо справляется HTTP, который (от клиента) pull'ит данные с сервера (клиент захотел, сдела запрос от клиента, получит ответ). И это все работает прямо очень хорошо, тут никакой вебсокет и не требуется.
Но проблема в другом - а что если инициатива должна быть от сервера? Что если сервер знает, когда вдруг надо что-то передать клиету? Через http это можно сделать или периодически (10сек) поллить сервер (есть новости? нет? ну ладно. а сейчас есть?). Но тут проблема с тем, что будет задержка между новостью и следующим поллинг-запросом, и тем, что если новостей нет или мало - нагрузка на сервер все равно высокая. Ну или делать долгие поллинг запросы (сделал запрос, а он через 20 минут ответил только, когда новость появилась). Но это сложно.
И тут вебсокеты отлично решают. Посмотрите современные реалтаймовые чаты, все быстро и хорошо работает. И еще мне очень нравится пополнять баланс карты на Озоне - пополняешь, и одновременно с тем, как у меня пиликает банковское приложение на телефоне (тилим-пилимы, мы услали твои деньги!), тут же на экране обновляются данные. (Тут мои респекты СБП, которая действительно не зря Б, но и вебсокетам и озоновским программистам, которые сокращают до минимума нервозное время, когда у тебя деньги и со счета исчезли и циферка на экране маркетплейса не появилась)
WebSocket поддерживает постоянное и двунаправленное соединение между клиентом и сервером
WebSocket поддерживает отправку данных и от сервера, и от клиента, что делает возможным обмен информацией в обе стороны
WebSocket поддерживает постоянное двустороннее соединение
WebSocket создает постоянное соединение [...] а затем обеспечивает канал для отправки и получения данных в обоих направлениях
WebSocket поддерживает отправку данных как от клиента к серверу, так и от сервера к клиенту
Я так и не понял, какой тип соединения устанавливается и какова отличительная характеристика канала. Возможно, стоит указать всё это ещё несколько раз.
WebSocket - это технология, разработанная для обеспечения real-time коммуникации между клиентами и сервером.
WebSocket - это протокол связи, предназначенный для обеспечения real-time обмена данными между клиентом и сервером.
Это позволяет создавать интерактивные real-time приложения, где оба участника могут активно взаимодействовать.
С реалтаймом чё-то тоже оказалось непонятно...
Если без шуток, то уважаемый автор, отдавайте, пожалуйста, статью на вычитку после ЧатГПТ кому-то из реального мира перед публикацией. Или сами пробегитесь, анализируя то, что написано. Это поможет избежать вот таких забавных ляпов.
Что-то уж больно много стало подобного в статьях на хабре, ей богу.
Я делал на вебсокетах (через пайтоновский SocketIO) универсальный вебсервис для издавания ws сообщений https://github.com/yaroslaff/ws-emit/ . Чтобы получать плюшки вебсокета, но не работать с вебсокетами :-). Отправлять сообщения можно через HTTP запрос к ws-emit, хоть из шелл-скрипта или просто ручками из шелла, на любом языке программирования, даже если для него нет WS либы. Есть даже кое-какая security в виде паролей для присоединения к "комнатам". ( Например, в онлайн магазине вам моментально придет оповещение о пополнении баланса, но не зная пароля, нельзя будет подслушивать сообщения других пользователей )
Пара примеров:
time. просто передает серверный unixtime раз в секунду.
dir2web - браузерный read-only интерфейс к каталогу. То есть, можно смотреть содержимое каталога и текстовых файлов. Если вдруг каталог или файл изменился - тут же они изменятся и в браузере.
Пожалуйста, выкиньте к чертям старые методички! В статье описаны преимущества вебсокета по состоянию 10 лет назад.
WebSocket не является частью HTTP и не работает через него, это протокол, совместимый с HTTP/1.1. Поэтому всех преимуществ HTTP/2 он так и не получил.
Проблемы с множеством HTTP запросов больше нет, с 2015 года. Уже можно держать один долгоживущий streaming ответ как радио и по тому же каналу слать обычные POST пачками, безо всякого оверхеда. И такой связки хватит для 80% задач. Для остальных 20% есть более современный https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API
Короче, похороните уже вебсокет! Он был создан, чтобы решать проблемы, которых уже давно нет
Спасибо за статью. Возможно я не совсем понял, но в шестом примере у вас сообщение отправляется всем подключеным клиентам а не по каналу подписки?
Тема хорошая, но как-то сыровато получилось. Я всецело за информацию о более свежих, быстрых и легких фреймворков, но... Есть Django Channels, который вообще не упомянули, хотя в коммерции в 80% проектах используется именно этот фреймворк и вебсокеты прикручивать придётся на проектах с Django.
И сильно бросился в глаза код из п.4
...
while True:
data = await websocket.receive_text()
...
db.close()судя по коду, мы для каждого клиента на вебсокете выделяем отдельное подключение к БД - стоило бы упомянуть про наличие лимита на количество подключений, возможность использования connection pool, да и память не бесконечна (постгря на каждое соединение выделяет отдельный кусок памяти). В целом, выглядит код так, что мы проявляем абсолютное доверие рандомному клиенту, который пришёл по вебсокету, придерживаем для него соединение с базой, а потом в неё передаём данные без лишних проверок. Понимаю, что это лишь пример, но для новичков такой пример может быть фатальным
Позвольте человеку, львиная доля программистской жизни которого прошла в разработке систем самого что ни на есть реального (и очень жёсткого (hard) к тому же) времени, сделать небольшую ремарку по используемой вами терминологии.
Из названия «Real-time приложения» никак не следует, что они «предоставляют мгновенный обмен данных и информации между сервером и клиентом». Где-то как-то родственные упомянутым вами качества, которые действительно следуют из определения “real-time”, таковы:
гарантированная реакция на событие;
своевременная реакция на событие.
В вашем тексте нет практически ничего, кроме tcp как транспорта нижнего уровня, для воплощения пункта 1, а по пункту 2 просто предлагаю вам поразмышлять и прочувствовать существенную разницу между понятиями “мгновенно” и “во́время”. “Мгновенно” в real-time системах нужно примерно никому, а вот без “вовремя” не может и речи вестись о real-time.
Делали бенчмарк Python websockets? Например, какое максимальное количество сообщений в секунду может обрабатывать клиент без потери сообщений? Я видел бенчмарки на локальных машинах: от 3 тыс до 42 тыс сообщений в сек. Но у меня сейчас при подключении по интернет к серверам биржи при нагрузке 400 сообщений в сек клиент начинает терять сообщения.
Разработка real-time приложений с Python и WebSocket