>> Это не "дофига способов", это только три.
> А этого мало, или мы за неимением аргументов переходим к придиркам к
> словам?Это не "дофига", это "несколько". И как раз ваш вопрос является придиркой.
Аналогично можно передавать данные в query-параметрах и заголовках при осуществлении соединения по SSE или при апгрейде соединения в Websocket. Разница только в том, что для SSE и Websocket в них можно передать данные лишь в самом начале, а в HTTP-запросах - в каждом запросе.
>> В конечном счете все сводится к тому, что практически всегда данные передаются
>> в теле запроса, в том или ином сериализованном виде.
>> этой точки зрения нет никакой разницы, что использовать.
> То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а
> вовсе не преимущество над SSE.
Большой минус HTTP-запросов - необходимость открывать новые соединения (постоянно для HTTP 1, периодически дли HTTP 2/3).
В случае SSE при использовании HTTP 1 мы имеем 1+n соединений (1 соединение для SSE, n соединений для отправки HTTP запросов).
В случае Websocket мы имеем 1 соединение в любом случае, так как через него можно и отправлять, и получать данные.
>> Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные
>> данные, у него используется \n\n как разделитель сообщений.
> Необходимость передачи бинарных данные у меня и не возникала, но решается элементарно
> с base64.
base64 раздувает данные на треть. 4096 байт в base64 будут 5464 байт.
SSE не дает отправлять сырые текстовые сообщения, по причине того же разделителя. Нужно обязательно как-то сериализовать данные, чтобы не дай боже в теле не было \n\n.
Итого мы имеем...
SSE:
+ более нативное поведение для протокола (легко реализуется);
- обязательная сериализация данных (ограничение протокола);
- невозможность передачи бинарных сообщений (ограничение протокола);
- односторонний канал связи (ограничение протокола, требует дополнительных запросов для отправки данных).
Websocket:
+ двухсторонний канал связи (отправка и получение данных внутри одного соединения);
+ возможность передачи любых сообщений в любом виде (в том числе бинарных);
- отдельный протокол, требующий особой поддержки и апгрейда соединения (сложность реализации, плохо продуманный handshake).
Казалось бы, зачем нужен Websocket, если у SSE "дофига" плюсов (целый один)?
>>> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
>> И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит.
> Не важно кто входит в группу, важно кто пиарит или каким-то образом
> поддерживает этот пиар.
> docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо
> или косвенно, именно он!
SSE разработан для отправки сообщений с сервера.
Websocket разработан как аналог TCP соединения в JS (с ограничениями), изначально даже назывался TCPConnection.
Это _разные_ технологии, и из этих двоих Websocket более функционален. Его даже пиарить не нужно, он банально более удобен в использовании. В Websocket можно легко инкапсулировать другие протоколы, типа STOMP.
А насчет пиара... Вон, Microsoft в последнее время пиарит Linux. Что теперь, отказываться от Linux и переходить на FreeBSD? Oh, wait, его же Sony пиарит, используя в своих консолях...
