WebSockets - почто стояли на майдане?

[metaclass]

ссылка

Вкратце - технология, по которой коннект с веб-браузера на сервер будет висеть пока не сдохнет, а сервер при желании сможет в этот коннект срать данными, которые браузер будет обрабатывать.
Выглядит, конечно, весьма привлекательно для неадекватов любителей делать интерактивщину на вебе.

Только вот представьте себе, что счас вся серверная и прочая инфраструктура заточена под, условно говоря, "короткий запрос-короткий ответ". Я уже несколько раз сталкивался с кривонастроенными сетями у клиентов, где долговисящие запросы просто обрывались где-то в середине сети. При этом обычные всякие почты, вебы и говноторенты в таких условиях работают более менее нормально. А вот если запросу в целях работы нужно висеть установленному - жопа и смерть, 5-10 минут неактивности и гамон.

Там по ссылке где нибудь упоминается обработка ошибок? Или keep-alive пакеты на уровне протокола? Ах, да, я забыл, в гугле не бывает зависающего сетевого оборудования, сдохших свитчей и неправильно настроенных прокси, натов и файрволлов, поэтому обработкой ошибок никто не заморачивается. "У нас на столе все работает".

Надеюсь, гугол это протолкнет в мейнстрим и начнется еще лет десять ебосрани для всех ИТшников, сисадминов, к которым будет приходит руководство и требовать чтобы "у меня веб-приложение должно работать" и веб-разработчиков, которым придется выламывать себе мозг, делая нормальную обработку ошибок с помощью костылей и хаков.

Comments

[max-posedon.livejournal.com]

Главная беда: раньше http был stateless, теперь statefull, со всеми вытекающими.

[metaclass.livejournal.com]

Ай, в сложных приложениях там жеж все равно состояния были. Просто что их в сессиях/состояниях юзера приходилось держать. И сейчас то же самое будет, и наверно еще хуже, потому что поверх сессии коннекта еще будет сессия приложения, и все это как-то надо будет взаимодействовать разработчику.

[max-posedon.livejournal.com]

То-то и оно, что состояния были в приложениях, если их мало(данных состояния) - хранить можно было в шифрованных куках, если много в базе данных или memcached. Но! это позволяло балансировать запросы, никто не требовал чтобы N-ый запрос пользователя обрабатывался на том же сервере, что и 1-й. Http оставался stateless, можно было перегрузить *любой* сервер, а с websockets я себе это всё мало представляю.

И главное ради чего? Ради поддержки сокетов в http, скоро там будет поддержка FS, OpenGL уже на подходе, а потом будет написан браузер работающий в браузере, который например контент оптимизирует и банеры режет (в стиле web-интефейса к Opera Turbo), и всё, пиздец. Круг замкнётся.

А наши дети уже будут пользоваться браузерами запущенными в браузерах запущенных в браузерах запущенных в OS в которой GUI делается на html.

[metaclass.livejournal.com]

Да, с балансировкой нагрузки и перезагрузкой серверов будет смех.
Единственное, что может оказаться, что реально эти вебсокеты сделают не в виде явно висящего tcp-коннекта, а в поверх него прикрутят канал связи с возможностью прозрачного перенаправления на другие сервера, типа браузер при приходе сообщения об обрыве TCP коннекта не будет веб-сокет рвать а пытаться повторно установить соединение.