Недостаток в лишней сущности, когда она не нужна. Надо - юзаются, не надо - не юзаются

Просто однажды написав такую библиотеку можно через нее общаться между своими серверами и между фронтендами и браузерами клиентов. Универсальность протокола терпит лишнюю в некоторых случаях сущность

Вебсокеты — это хорошо. А вот их реализация — это плохо.

Если ты открыл 100 вкладок с сессиями, то HTTP это выдержит, а websocket поломается. Там ограничение на число соединений к одному серверу, причем очень небольшое, где-то от 4 до 16.

Для проксирования в nginx, во-первых, нужны лишние телодвижения, а во-вторых, у меня в свое время они так и не взлетели.

Если бы не такие грабли, то HTTP-сессии стоило бы вообще забыть.

гугл или web головного мозга?

web

и давно тебя такие нехорошие идеи посещают?

Какие недостатки?

отсутсвие нормальной реализации и кривые прокси,

у нас использовался свой бинарный протокол поверх http, есесно заложились что все работает через банальный http прокси.

при использовании Transfer-encoding chunked вся идея япревращалась в тыкву, и это весьма древний стандарт, а эти ваши вебсокеты еще свежее.

Давненько. Я вообще думал раньше SSH использовать

Подключение к СУБД по SSH-туннелю

1) Проходимость возрастает, например всякие веб-прокси

эта твоя идея будет способствовать ограничению этой самой проходимости для всех протоколов, кроме HTTP. Раз все используют только его, зачем нам остальные порты и протоколы, давайте всё заблокируем

интернет не создавался исключительно для HTTP

И вообще, чего мелочиться, пусть роутеры тоже на js работают, пакеты на нём маршрутизируют, в jsone закодированные

и ethernet заменим, встроим в сетевую карту аппаратный js-интерпретатор и вместо непонятных бинарных полей всё в json запихнём, будет круто и по-хипстерски

Странные выводы из моей идеи

Если ты открыл 100 вкладок с сессиями, то HTTP это выдержит, а websocket поломается. Там ограничение на число соединений к одному серверу, причем очень небольшое, где-то от 4 до 16.

Уже решили: http://daniel.haxx.se/http2/

Почитай, чтобы быть в курсе, там все это описано.

Да всё верно написал. Один минус вс это с сжатием, дркгих проблем нету.

А что со сжатием? Оно же вроде не жмет по дефолту, а жать можно самому если вообще нету режима сжатия

> 1) Проходимость возрастает, например всякие веб-прокси

Есть такия птичка, наивняк.

Спасибо, ознакомился.

Вот умеют же доки писать! С лего-картинками и русским переводом.

Но какой-то ядреный этот HTTP2. И не HTTP (гоняем не текст, а бинари), и не 2 (совместимость заявляют). Но вот лимит на соединения починили, факт.

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

У нас на прошлой работе был rpc по вебсокетам между серверами, рабочая схема. Реализация websocket-клиента, правда немного подкачала, я подампил и пофиксил. Других серьезных проблем вроде небыло.

А между сервером и фронтом гонялся совершенно другой формат данных, поэтому логику мы не обобщали.

А вобще хорошей заменой «голым» сокетам должен быть SCTP, но с его реализацией и поддержкой вобще борода, даже в эрланге на последних ядрах линукса у меня были проблемы, причину которых я так и не раскопал.

В чём вебсокеты кардинально лучше protobuf + перед каждым сообщением размер данных (4 байта)?

SCTP

SUBJ. Но меня опередили.

тыкал в него палочкой лет 5 назад — очень сырой был.

подозреваю, что ситуация с веб-сокетами не лучше.

1) Проходимость возрастает, например всякие веб-прокси

и как там у вас, в стране эльфов?

С веб-сокетами, к сожалению лучше. Намного. «К сожалению» - потому что в свете SCTP вебсокеты смотрятся велосипедом.

Браузер умеет. Сервисы по привычным url

Браузер умеет

Довольно узкий юзкейс.

Сервисы по привычным url

Неплохо. Но реализуется элементарным первым сообщением в качестве handshake, где можно передать строку-url, или просто path.

http://websocketd.com