WebSockets — полноценный асинхронный веб

[kirsan_vlz]

Правильный веб 2.0?
Только на днях начал ковырять comet-технологию, а тут такое.
Будем-с ждать :)

[el777]

Я тоже в серьез присматривался к Comet и Beyeux для одного проекта, но нашел WebSockets. На мой взгляд, эта технология на голову или даже 2 выше! Но еще очень свежая.

[nekt]

Пока она еще появится повсеместно…

[el777]

Кстати, говоря, это зависит от нам.
Насколько активно мы итешники будем разрабатывать и пиарить свои сервисы. Чем больше интересных вещей будет, тем быстрее пользователь начнет этим пользоваться.

[flyaway]

Очень-очень свежая.
Например, не совсем ясно, если у комета проблемы с принудительным закрытием злыми проксями долго висящих соединений, то почему таких же проблем не будет у websockets?

[el777]

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

[Finderom]

Я начал ковырять Google Gears, а через неделю узнал что Google будет от нее отказываться в пользу HTML5.

[Dr_Zoidberg]

Вау! Занятно

[Zibx]

Это именно тот случай, когда можно заставлять ставить браузер. Это платформа веб приложений.

[vovchisko]

Не закончится.

Я думаю, что MS поддержит идею, пусть даже не сразу, но ждать долго не заставит.

[vovchisko]

Да и IE8 не такой уж и плохой браузер. Хоть я им и не пользуюсь из за пары плагинов в FF. Но я то не %USERNAME% — мне они как воздух.
Если бы не они — пользовался бы IE8.

"… да, знаю, грусть, злоба и осадок на душе остаётся после нескольких лет разработки под IE6.
Но я уже отпустил IE6 и простил его. Пусть отходит с миром. Всё будет хорошо."

[mihaild]

IE8 может и неплохой браузер (во сколько раз он отстает по скорости js от ФФ? а от хрома?), но если MS не захочет — поддержки сокетов в IE не будет. А зачем бы им делать эту поддержку, сдавая лишние козыри гуглу?

[vovchisko]

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

Как-то раз на какой-то конференции (не помню, но точно слышал) у дядьки с гугля спросили «а когда же это всё зарботает в IE?» на что он ответил «IE? я не знаю такого браузера» (или как-то так) — вот такая политика.

И БАМ! в IE8 всё работает.

если допустим пользователи gmail не смогут заходить на свою почту (а её часто в последнее время оказывается именно gmail) то от IE они откажутся.

Со времён IE6 политика MS значительно изменилась. Я бы даже сказал, что они существенно поумнели.

[olegkrasnov]

А им деваться будет некуда. Как-то Билл Гейтс говорил что интернетом они заниматься не будут, а будут продвигать сеть АОЛ, но потом пришлось забить на АОЛ, заняться интернетом и сделать свой браузер.

[el777]

Охохо…
Вот этого я жду с содроганием. МС опять окажется в роли догоняющего, а значит реализует в спешке и криво — значит будет брешь в системе. Через нее пойдет большой поток вирусов. Что негативно скажется на мнении о самой технологии, хотя тут она совершенно не виновата. Начнут повсеместно отключать, резать на корпоративных проксях и так далее. Быть может помните, на заре веба была проблема с куков?
В итоге все проиграют: и пользователи, затормозится развитие технологий, и рейтинг самого МС опустится еще ниже плинтуса.

[vovchisko]

Не пророчьте апокалипсис! %USERNAME% и так в страхе живёт ;)

Я думаю таки что-то изменилось, и так тупить в МС уже не станут. Тем более, что не так уж будет и сложно сделать поддержку WebSocket без багов, как по мне.

Всё будет хорошо ;)

[Bambr]

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

[sys]

даже если МС и не затупит с реализацие в новых версиях, все равно останется проблема со старыми версиями ИЕ. А пользователи экплорера наиболее инертны в плане обновлений. Так что широкодоступной эта технология станет ой как не скоро.

[el777]

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

[slik]

Что именно отправлять, разработчики полностью оставили на ваше усмотрение: хотите XML, хотите AJAX, да хоть стихи Пушкина.

Под AJAX вы имели ввиду JSON? :)

[el777]

Да, конечно, JSON! Спасибо, сейчас поправим.

[Mithgol]

В первом скрипте в строке 10 опечатка: не «onopen» там должно стоять.

[el777]

Спасибо. Не заметил.

[danilissimus]

>Теперь уже нет клиента и сервера
…
>Если браузер это устраивает, то он просто оставляет _TCP-соединение_ открытым

>Теперь уже нет клиента и сервера

ммм? что?

[el777]

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

[danilissimus]

>нет четко выраженного разделения на «спрашивающий» и «отвечающий»
простите, но ОТВЕЧАЮЩИЙ — любом случае сервер. или сервер может САМОСТОЯТЕЛЬНО инициировать подключение к клиенту?

[el777]

Нет, сервер не может. Инициатива всегда исходит от клиента.
Я немного запутал вас в терминологии.
Но возможен такой сценарий: клиент установил подключение до сервера и молчит. Когда серверу потребовались данные — например ФИО пользователя — он сам направляет клиенту асинхронное сообщение. Клиент показывает какую-то форму пользователю, принимает данные и отсылает их на сервер.
В таком варианте вроде бы как сервер спрашивающая сторона. :)

Вот еще важный момент! Поскольку соединение асинхронное то правильнее о нем думать не как о сессии «вопрос-ответ», а как «репликах в воздух».

[safright]

смысл фразы в том, что _сейчас_ бравзер является исключительно клиентом — и «в большом» (первоначальное подключение) и «в малом» (небольшие транзакции в рамках одного подключения, например AJAX-запросы).
Веб-сокеты позволят реализовать равноправность «в малом», сохранив разделение «в большом».

[safright]

* AJAX-запросы в том смысле, что чтобы это работало клиент (бравзер) должен сам регулярно опрашивать сервер «а не появилось ли у тебя чего-нибудь новенького». Сервер же вообще никак не может обратиться к клиенту кроме как по запросу от него.

[el777]

Вы очень хорошо и понятно описали :)

[grigoryvp]

Подскажите, текущая реализация Ajax держит TCP подключение или создает его каждый раз, когда javascript отправляет запрос на сервер (обычный или long poll)? Что-то меня вот этот комментарий смутил: habrahabr.ru/blogs/webdev/79038/#comment_2318372

[safright]

м, вроди бы AJAX это принцип, а не конкретная реализация =)

К несчастью, я не очень хорошо разбираюсь в особенностях существующих механизма запросов (про аякс, асинхронность и прочее я выводы получил совсем через другие размышления).
Погуглив, нашел статейку на ангельском — вроди в ней есть указания на нужные сведения (и, заодно, о технологии, которой товарисч козырял).

[alekciy]

Не AJAX, а XHR. Пока клиент не закрыл соединение оно идет в рамках одного TCP соединения.

[Bambr]

> хаках, а не стандартых
очепяточку поправьте плз. И большое спасибо за интересный материал.

ЗЫ Интересно, если бы такая смелая затея вышла не из гугла, а из чего-то масштабом помельче — прошло бы?

[el777]

Тут дело не в гугле — самой идее больше года — www.w3.org/TR/websockets/ Гугл — лишь первый, кто ее реализовал.
Опять повторился сценарий «волшлебного пендаля», как было с Хромом. Вышел браузер с быстрым яваскриптом и инкогнито-режимом — вроде бы ничего нового — но все тут же подтянулись.

[licvidator]

Кто-нибудь может мне объяснить, зачем нужен инкогнито-режим? Порнуху смотреть, чтобы подруга по хистори не запалила?

[Hest]

да хотя бы, почему нет

[mihaild]

Ходить на левые сайты, если вы залогинены где-то где есть (может быть) XSS

[krasin]

На чужом компе чтобы своих куков не оставлять

[licvidator]

Логично.
Про чужой комп я не думал…

[TravisBickle]

Сча я напишу модуль для phpDaemon. Будет опупенно.

[el777]

Ждем! :)

[vovchisko]

Кинул в закладки ваше заявление ;)

Всё будет хорошо. Я гарантирую это.

[TravisBickle]

Набросок тут — тут. Протокол реализован. Осталось сделать API внутри самого демона.

[TravisBickle]

API тоже готово. Пример приложения вот тут — ExampleWebSocket.php. Оно отвечает 'pong' на фрейм 'ping'. Вот тут — тестовая страничка.

[vovchisko]

Круто. Вечером покатаюсь.
Жаль плюсавать не могу :(

[Timeless]

Теперь еще Google Protobuf под Javascript портировать и будет совсем сказка в плане снижения объема передаваемых данных

Но впрочем я это за одну только асинхронность готов любить. Web от client-server становится площадкой общения равноправных игроков — это замечательно

[el777]

Можно. Но с другой стороны надо ли?
WebSockets по скорости и эффективности передачи данных практически равен чистому TCp-соединению. Здесь не надо слишком сильно оптимизировать, потому мы имеем дело с открытой системой — то есть чтобы все кто угодно могли с ней легко взаимодействовать. Здесь лучше оставить некоторую абстрактность и гибкость.
Protobuf — это чисто гугловая вещь, а WebSockets — общественный стандарт планируемый для широкого использования.

[Deepwalker]

WebSockets это транспорт, Protobuf это эффективная инкапсуляция — не путайте. Стандарт никак не описывает в каком именно виде вы данные будете гонять.

[el777]

В принципе да — у нас есть универсальный бинарный контейнер.
Надо только, чтобы приложение понимало, что оно получает.

[teran]

>> WebSockets по скорости и эффективности передачи данных практически равен чистому TCp-соединению.

WebSockets это фактически TCP over HTTP, так что оверхед есть и немалый.

[el777]

> WebSockets это фактически TCP over HTTP, так что оверхед есть и немалый.
Не соглашусь с вами. HTTP используется только на начальной стадии, дальше идет почти чистый TCP. Единственное отличие — к передаваемым строкам добавляется по 1 байту в начало и конец.

[kurokikaze]

Кстати да, возможно есть смысл попробовать их объединить.

[disserman]

только гуглу слава не за вебсокеты, а за гениальное ведение бизнеса. вместо того чтоб ввязываться в битву за десктопные ОС, гугл в нее особо не лезет, зато постепенно переманивает противников на своё поле.

[Homakov]

Не переманивает, а мы занимаем это поле. Это было неизбежно

[disserman]

не мы занимаем поле — нами его занимают.

[Gorthauer87]

XHTTPRequest больше ненужен? Уря товарищи!

[kirsan_vlz]

Да ну. Сокеты полезны, если нужно постоянный коннект держать. А если у нас добавление/изменение записей в БД или та же проверка доступности логина при регистрации, то зачем постоянное соединение держать?
Всему своё место. Сокеты будут нужны для динамически изменяющейся информации, например, чаты, новостные ленты и т.п.

[kirsan_vlz]

Хотя, я кажется, глупость написал. Ничто не мешает открыть сокет, отправить/получить информацию и закрыть. Как с тем же XHTTPRequest. Вроде бы сокеты лишены некоторых минусов этого объекта.
В общем надо бы поподробнее почитать.

[disserman]

ну в общем-то логичный поворот. всё идёт к тому что в браузере по сути будет выполняться полноценное приложение, использующее HTML для прорисовки интерфейса и javascript внутри. Эдакий контейнер вроде старой доброй JVM, только с юзерфрендли-фронтендом ввиде табов.

Подход впринципе правильный т.к. если JAVA и ActiveX шли с десктопа в веб со всеми своими дырками в основном из доступа к локальной фс, javascript идёт наоборот из веба на десктоп и дырки в нём специально делать никто не станет.

[el777]

Да. WebSockets входят в WebApplication.

[Finderom]

Я думаю для интерфейсов даже HTML отомрет, будут прямо на канвасе интерфейс рисовать со всеми кнопочками и ляляками.

[Masterkey]

просто данное решение позволяет вам выбрать самому6 использовать HTML или просто загрузить исполняемый код на машину клиенту.

гммм, я уже вижу какие вирусы будут этим летом расти )))

короче чем интереснее технология тем важнее в ней верификация сторон учавствующих в обмене.

[Masterkey]

WebSockets

[mihaild]

А какой смысл? Думаю то, что предусмотренно в HTML через него сделать проще (и браузером будет обрабатываться быстрее). Кнопки же в HTML как правило не делают картинками с обработчиком (если нет каких-то сильно необычных требований)

[mefcorvi]

Вообще, во многих web application, да и на многих обычных сайтах кнопки делают в виде ссылок с картинкой (это не повод к холивару о том, правильно ли это, но тем не менее это факт).

А DOM в браузерах ооочень медленный. Особенно в FF и IE.

[mihaild]

Ставят. Но, на мой взгляд, это скорее недоработка HTML — невозможность через него сделать картинку кнопкой. Как и многое другое.
DOM, конечно, медленный. Но не думаю, что canvas, управляемый js, будет работать быстрее. С чего бы? DOM все-таки львиную часть работы по отрисовке отдает скомпилированному коду. Canvas — нет.

[mefcorvi]

DOM помимо отрисовки выполняет ещё множество вещей, связанных с определением правильного положения элементов, их размеров и т.п. Кроме того, я не знаю никакой возможности хоть как-то буферизовать изменения свойств узлов дерева. Например, я меняю свойства для 10 элементов в DOM'е… и на каждое изменение каждого из свойств, браузер(по-крайней мере IE точно) будет пытаться перестраивать и перерисовывать дерево.

Мне кажется, что канвас на специфических задачах навороченного и очень динамического GUI вполне может оказаться быстрее. Тем более, что скрипты сейчас чуть ли не в нативный код компилируются.

[mihaild]

В специфических — безусловно. Но думаю, что все-таки с простой ссылкой работа будет быстрее, чем с нарисованным в canvas текстом и обработчиком на нем.
Вопрос в том, сколь сложные задачи лучше решать с помощью canvas. Реализовывать сложную работу с графикой через всевозможные хитрые манипуляции — глупо. Но и простое отображение текста через canvas — тоже. Где-то в промежутке есть задача, которую одинаково сложно делать как на HTML, так и с cavnas.

[vovchisko]

Ну вот… hollywar detected :)

[TimTowdy]

Ставьте родительскому элементу св-во display: none на время модификации, будет вам буферизация. Довольно известный трюк.

[mefcorvi]

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

[TimTowdy]

Вот несколько неплохих советов по оптимизации от Оперы, хотя насколько они помогут в случае с IE ручаться не могу.
dev.opera.com/articles/view/efficient-javascript/?page=3

[mefcorvi]

Спасибо за ссылку :-) Хотя, слава богу, оптимизировать приложение под Оперу пока не приходилось (куда ещё быстрее?).

[el777]

> невозможность через него сделать картинку кнопкой.
Не очень понял вас, а как же <input type=«button» ...>?

[ap3rus]

/>

Покажите мне браузер, который это не поддерживает.

[ap3rus]

<style type="text/css">
.btn { background: url(img.png) no-repeat; width:16px;height:16px; display:inline-block; }
.btn:hover { background: url(imgHover.png); }
input.btn { outline: none; border: none; }
</style>

<input type="button" class="btn" />

Спать пора… :)

[vovchisko]

а так же или

Вы чертовски правы! Пора спать!

[vovchisko]

а так же input type=«image» или просто тег button

[disserman]

врядли отомрёт скорее расширится. многие и под десктопные оси предпочитают интерфейс на HTML рисовать ибо просто, быстро и легко найти верстальщика

[Finderom]

Вот только потому, что верстальщика просто найти…
Для верстки текста — согласен HTML рулит.
А для интерфейса типа MS Office, HTML получится сложный и тяжелый
Мне кажется у канваса, в перспективе скорость и легкость (нет dom, стилей и пр....).
Договориться, как отображать HTML гораздо сложнее чем как рисовать на канвасе.
Описание стандарта будет тупо больше, поэтому и сложее. А значит место для разночтений и ошибок.
Сравните стандарт по HTML+CSS и по канвасу.
А строить интерфейсы все равно будут через либы типа ExtJS

[disserman]

тут согласен. всему своё. но HTML не обязательно для вёрстки текстов — для любого несложного приложения на ура сгодится.

[Barttos]

Как пример bespin.mozilla.com/ Полностью на canvas рисуется.

[gbezyuk]

о_О Зашёл, открыл firebug, поинспектил элементы — html как он есть.
Может быть я куда-то не туда посмотрел, но «полностью на canvas рисуется» не увидел.

[mefcorvi]

Ну насколько я понимаю речь идёт не о сайте https://bespin.mozilla.com/, а об их продукте Bespin, для просмотра которого нужна регистрация (она ещё и с оперой не дружит, при этом не даёт продолжить на свой страх и риск).

[gbezyuk]

Если я ничего не перепутал, этот их продукт — онлайновый html-редактор.
Зарегистрировался, посмотрел под фаерфоксом — опять же, никакого намёка даже на «только canvas» не обнаружил.

[mefcorvi]

Это весьма странно. Я тоже зарегистрировался и тоже смотрю под фаерфоксом, и, насколько я вижу, сам редактор — это всё-таки canvas. Прочие вспомогательные элементы интерфейса, вроде кнопок сохранения, всё-таки html.

[gbezyuk]

Вот и я о том — это явно не «только canvas».
Те же самые кнопочки рисовать может и нарисуешь, а обработчики на них повесить как в рамках canvas'а?
Всему своё место. Старый добрый HTML рано списывать со счетов, он много на что годится.

[TheShock]

а обработчики на них повесить как в рамках canvas'а?

Легко)

[boombick]

Выглядит красиво :) Ждем полноценной поддержки всеми браузерами и серверами :)

[stampoon]

Я что-то не понял, оно держит открытым соединение? Если это так, то полный ахтунг, это же какие нагрузки!

[el777]

А какие нагрузки от неактивного соединения?
Как раз постоянное подключение-отключение создаст большую нагрзку.

[stampoon]

Максимально возможное количество соединений ограничивается ядром, в данном случае оно должно будет быть увеличено, что строго говоря не есть гуд.

[Deepwalker]

А с longpoll/comet сейчас не так? И в чем не гуд? Если надо, то надо чтобы было гуд, патчи там и тп, если сейчас что-то мешает: )

[el777]

Оно настраивается.
Вот пример сервера, который поддерживает 1 миллион коннектов, да не просто поддерживает, а работает с ними: www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1

[kurokikaze]

Не больше чем от открытой ICQ.

[Finderom]

Как же давно я этого ждал!
Теперь смогу графики и логи в браузере смотреть в реальном времени.

[Mithgol]

Вышеприведённый скрипт демонстрирует, как клиент слушает сервер.

А вот ws.send('. . .') не показан, например.

[el777]

Это первая вводная статья. Если будет интерес — то продолжу дальнейшие изыскания.
Я подумал, что она и так уже длинная — чтобы не мучать читателя часть технологии опустил.

[Mithgol]

Понятно.

[j1nn]

продолжите изыскания, пожалуйста! ;)

[Bambr]

Ну Вы поняли насчет интереса :) Он есть!

[TravisBickle]

Надо попросить Сысоева добавить поддержку проксирования таких приложений. Не выделять же под это отдельный IP-шник…

[el777]

Сам уже об этом подумал :)
Я думаю Игорь добавит в nginx хороший мультиплексор и это позволит еще снизить нагрузку на сервер по поддержанию множества сокетов.

[Mithgol]

Половина дороги пройдена, ура.

А когда и на другом конце вместо сервера сможет быть браузер, то тогда такой P2P начнётся!..

[Mithgol]

Да. Пока без сокетов, впрочем.

[bolk]

Это тоже не сокеты.

[Goodkat]

Браузеры, как правило, за проксями и натами всякими.

[Mithgol]

Ну, это препятствие P2P-сети преодолевают через промежуточные незафайерволленные узлы.

[Goodkat]

Ага, в случае браузеров это сервер.

[grigoryvp]

NAT penetration эффективно пробивает 70-80% NAT'ов.

[benone]

Откройте для себя adobe flash:)

[rPman]

флеш позволяет создать приложение-сервер (подключение клиента к другим клиентам)? можно пример, ссылку или место в документации?

[benone]

Флеш умеет использовать как свои сокеты www.adobe.com/livedocs/flex/3/langref/flash/net/Socket.html
так и p2p
livedocs.adobe.com/flash/9.0/ActionscriptLangRefV3/flash/net/NetConnection.html

[benone]

Сорри, первая ссылка на флекс. На флеш надо поискать.

[Kane]

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

ps про gnash знаю

[phillennium]

Будучи ламером и параноиком, спрошу: а не даст ли это серверам злоумышленников возможность как-либо серьезно портить жизнь пользователям?

[glorybox]

ламер+параноик — ядрёная смесь

[Jama]

Не сильнее, чем сейчас.

[veter]

Наверняка даст. Как только пойдут массовые реализации, начнутся и грабли, которые в спецификации не описаны :)

[arty]

я не очень понял, что помешает криво настроенным проксям/антивирусам обрубать или тормозить соединения websocket, раз уж они так сильно похожи на обычные http-запросы?

и касательно ограничения одновременных соединений — вы уверены, что оно прописано именно в стандарте HTTP? Почему тогда у каждого браузера своё ограничение?

[el777]

> я не очень понял, что помешает криво настроенным проксям/антивирусам обрубать или тормозить
> соединения websocket, раз уж они так сильно похожи на обычные http-запросы?
В споре кривизны с прямизной, однозначно победит кривизна :)
С проксями получается такая ситуация:
— если прокся официальная (прописана в браузере), то она должна поддерживать метод CONNECT — с помощью которого браузер работает по HTTPS — ведь там тоже используется передача бинарных данных.
— если это NAT — то он просто завернет подключение и никто этого не заметит.
— самый сложный случай будет в случае «прозрачной прокси», когда все текущее на 80 порт заворачивается на сквид или другой прокси-сервер — здесь уже как он отработает. Впрочем я не исключаю, что в скором времени они научатся поддерживать веб сокеты.

> и касательно ограничения одновременных соединений — вы уверены, что оно прописано именно в
> стандарте HTTP? Почему тогда у каждого браузера своё ограничение?
Могу путать, но где-то проскавала цифра 2 или 4.
Конечно, это не жесткое ограничение — никто не мешает на своем фаерфоксе поставить цифру побольше. Однако есть некоторое официально рекомендованное значение, чтобы вы ненароком сервер не уронили.

[arty]

вы правы

Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy.

[grigoryvp]

Подскажите мне, неспециалисту, а чем это принципиально отличается от того, что сейчас реализовано во Flash? Насколько я понимаю (поправьте, если ошибаюсь), Flash уже давно может устанавливать асинхронные TCP соединение? YouTube, Augmented reality, игрушки всякие?

[arty]

тем, что это будет работать даже на тех устройствах, о которых не подозревают менеджеры Adobe

[arty]

ну и на айфоне, теоретически

[benone]

на айфон, теоретически собираются портировать флеш

[arty]

насколько я знаю, его уже давно портировали, но apple не даёт его туда ставить

[grigoryvp]

Рискну уйти глубоко в минус по рейтингу, но можете чуть поподробнее почему флэш является хаком? Я, к сожалению, больше по desktop решениям, но websockets даже для них открывает широчайшие перспективы :).

[Bambr]

Я думаю, автор имел в виду, что с помощью флеша часто обходят ограничения того же http и других доисторических прелестей, живущих у нас в браузере. Если так, то тут более подходит слово «костыль».

[lost_shadow]

Да, мы делали транспортную часть между Javascript-приложением на flash. В итоге от неё отказались по двум причинам:

• — Из-за глюков flash раз в неделю падал весь браузер с SIGSEGV (или как оно в винде называется?), что сильно расстраивало пользователей.
• — У кого есть флэш, обычно включен флэшблок. То есть включить наш, естественно, невидимый, флэш он не сможет.

Разумеется, кроме флэша была и другая реализация двустороннего обмена данными.

[catlion]

> Пока я не нашел открытых веб-сокет сервисов
www.mibbit.com/

> качать на свой компьютер демо-пример вебсокетов на php
А еще есть Jetty, Cometd, Orbited, Lightstreamer
Полный список технологий и серверов есть тут: cometdaily.com/maturity.html

[ingeniarius]

Это всё таки суррогаты, а не полноценные сокеты

[catlion]

Что такое «полноценные сокеты»? У всех перечисленных заявлена поддержка HTML5 WebSocket

[ingeniarius]

А уже… круто!

[el777]

> www.mibbit.com/
А где оно там используется? Сходу не заметил

> А еще есть…
Вы правы — сейчас появится много серверов с поддержкой WebSockets — некоторые команды уже реализовали ее.

[catlion]

blog.mibbit.com/?p=487

[Levsha100]

А как будет происходить проверка на целостность пакетов?

[arty]

это же tcp-соединение, нижний уровень обо всём позаботится

[shifttstas]

Написано же что используется TCP это вам не UDP…

[TravisBickle]

WebSockets — гвоздь в гроб IE.

[mihaild]

Боюсь, что все-таки IE — тормоз для WebSockets

[mihaild]

Не уверен, что другие компании действительно быстро подтянутся. Хром заставил зашевелиться остальных из-за того, что при переходе на него пользователь сразу получал существенные преимущества.
Для использования же WebSockets веб-приложения должны писаться в рассчете на них. Пока эта технология не будет поддерживаться браузерами большинства пользователей — этого не будет. Пока не будет достаточно большого количества таких приложений — производителям других браузеров беспокоиться смысла нет.
Получится ситуация в чем-то аналогичная связанной с IE6: из-за его популярности его все (почти) поддерживают, а то, что в нем работает большинство сайтов поддерживает его популярность.
Если 95% сайтов перестанут поддерживать IE6 — его популярность мгновенно упадет почти до нуля. Если 95% сайтов будут требовать WebSockets — браузеры, его не поддерживающие, очень быстро потеряют пользователей.
Но конкретный сайт, не поддерживающий IE6 из-за этого потеряет посетителей. Конкретный сайт, требующий WebSockets — тоже.
Возможно, некоторым компромиссом будет реализация двух вариантов — с сокетами и без них (или использование того же web-socket-js).
Но:
1. Это сложнее, чем сделать что-то одно.
2. Такая ситуация мало чем угрожает браузерам, не поддерживающим сокеты.
Разве что в браузерах, поддерживающих сокеты, можно будет делать что-то существенно лучшее, чем без них.
Чем ситуация будет принципиально отличаться от, скажем, canvas? Он уже работает во всех основных браузерах, кроме IE. И часто его встретишь где-то кроме демонстрационных страничек?

[eugyn]

Можно было букв поменьше
:-)

Исходя из общеизвестной страсти MS к Google, проигнорирует ли MS данную инициативу?

Если да, то прекрасное так и останется далеко…

[Bambr]

Скорее уж известная своим остроумием MS напишет свои MsSockets, с блекджеком и шлюхами :)

[lost_shadow]

Учитывая ещё, что в половине сайтов простой Javascript глючит :)

[kurokikaze]

Для использования же WebSockets веб-приложения должны писаться в рассчете на них. Пока эта технология не будет поддерживаться браузерами большинства пользователей — этого не будет

С Гугла станется наплевать на поддержку и начать внедрять вебсокеты с graceful fallback до обычных Ajax/Comet. Тут опять же пользователи браузеров с поддержкой WS окажутся в выигрыше.

[Glebushka]

Продвигают в массы технологии, нужные для Google Wave :D

[j3d1]

скорее для их ос

[Wott]

Я что-то не нашел в этом ssl…

[el777]

Я не стал раздувать статью, чтобы не мучать читателей.
Но существует протокол WSS — это тот же самый WS только поверх SSL/TLS.
Тоже самое как HTTP / HTTPS.

[Finderom]

Теперь рекламу пользователю будут вдувать еще и через сокеты.

[Mithgol]

Я думаю, что это мрачное пророчество ещё не скоро сбудется.

Чего-то я не видел, например, баннеров, нарисованных на холсте <canvas> для обхода Adblock Plus.

[Finderom]

Если бы вы это видели, это было бы уже не пророчество а реальность :-)

[mybrain]

утото только потому что в ИЕ не робит. ИЕ больше, чем Адблока

[kurokikaze]

Для IE вроде есть реализация Canvas на Javascript.

[shifttstas]

Я думаю после внедрения веб сокетов и полноценного HTML5 и CSS3 то Google Wave выстрелит так как будет менее ресурсоемкое и более шустрое, да и по идее вебсокеты будут жрать меньше ресурсов сервера да и юзера

Если бы еще по дефолту все бы жалось в gzip…

[amima]

Не каждый сервер выдержит столько соединений одновременно поддерживать

[el777]

www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1

[aleks_raiden]

выдержит

[safright]

За-ме-ча-тель-но!

Буквально с неделю назад крепко думал, что из-за намеренной неравноправности клиентов и серверов, появившейся черте-когда на тогдашних основаниях и причинах, нынче приходится пользовать какие-то убогие костыли. Рад, что гугл со мной солидарен :D

[not_ice]

WebSocket-Origin: site.com
WebSocket-Location: ws://site.com/demo


я немного не понял: может ли злоумышленник, манипулируя этими заголовками получить несанкционированный доступ?

[mefcorvi]

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

Поэтому, чтобы манипулировать этими заголовками нужно или вмешаться в код браузера, или в поток данных между пользователем и сервером… но если вы можете это сделать, то зачем вам заниматься такой ерундой, как подделка заголовков, если вы и так имеете доступ ко всем данным пользователя?)

[aspel]

например какой то forex.com отдает какую то статистику только для своего домена, что будет мне мешать получать эту статистику?
За 5 мин напишу промежуточный модуль который будет получать эти данные подменяя Origin, и после получения данных выводить информацию непосредственно уже на свой сайт.

Клиент -> Мой сервер -> подмена Origin -> forex
forex -> Мой сервер -> Клиент

И не нужно никого взламывать и ломать.

[danilissimus]

>И еще один «камень в ботинке» AJAX-разработчика — проблемы с кросс-доменными приложениями. Да, и для них тоже придумана масса хаков. Помашем им ручкой и смахнем скупую слезу. WebSockets не имеет таких ограничений. Ограничения вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере. Думаю, внимательные уже заметили новый заголовок Origin.
БЕЗОПАСНОСТЬ ВПЕРДЕ!

[eugyn]

Где-где безопасность?

[Mithgol]

ВПЕРДЕ!

Что определит сервер, если клиент окажется злоумышленным и подсунет некорректный Origin?

[eugyn]

О чем и речь.

Особенно если подсунет корректный Origin :-(

Работать это будет только если «разрешенный источник» будет знать про данный конкретный Origin. Иными словами домены по вопросу данного клиента должны между собой перепихнутся. И чем этот перепих лучше тупого проксирования?

[Bambr]

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

[el777]

Да, Origin присылается браузером, то есть потанциально его можно сфабриковать.
Но тут такая картина — из яваскрипта его изменить нельзя, браузер сам пришет что нужно. Если вы взломали браузер — то вы сможете слать что угодно — здесь уже не до проверки Origin-a. То есть такая схема не добавляет новой уязвимости, но дает больше возможностей.

[perda]

Нее. У меня нету :)

[mihaild]

Может быть, я не понимаю чего-то связанного с AJAX — но чем такая модель хуже нынешней? Браузер, думаю, не должен позволять менять Origin, а своими средствами в любом случае можно отправить какие угодно заголовки куда угодно

[danilissimus]

>Браузер, думаю, не должен позволять менять Origin
а еще браузер не должен позолять троллям троллить, а детям качать порно.

[mihaild]

Разве? Так как эти ограничения невозможно сформулировать достаточно строго, то их невозможно реализовать, а значит браузер и не обязан этого делать.
Браузер же обязан не позволять перезагружать компьютер или подключаться с помощью XHTTPRequest к другим доменам?

[eugyn]

>Браузер же обязан не позволять… подключаться с помощью XHTTPRequest к другим доменам?

Да.
И это правильно.

[kurokikaze]

Same Origin Policy — вещь конечно хорошая, но иногда она очень мешает. Сейчас сервисы взаимодействуют между собой всё чаще.

[Bambr]

Про троллей это Вы хорошо сказали

[xamelion]

а при большой нагрузке, увеличение количества запросов, сервер разве не положат?

[Deepwalker]

Почему квази? С лонгполом реальный реалтайм — есть данные, тут же и получаешь.

[alekciy]

Потому что зависит от логики реализации AJAX-а. Можно делать переконнект каждый Х секунд (когда серверная часть на PHP так обычно и делают), либо не закрывать соединение. В первом случае как раз квази реалтайм и имеем.

[Deepwalker]

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

[mdevils]

Уверены, что тред а не процесс? Насколько я знаю nginx создает мало процессов, но сами процессы генерируют треды. А создание процесса — как раз и есть ресурсоемкая операция, в отличие от треда.

[el777]

Не совсем, Nginx не создает ни процессов, ни потоков для соединения. Потому что при большом кол-ве соединений, обе эти операции очень быстро съедят все ресурсы системы. Вместо этого он в рабочем процессе хранит дескрипторы всех соединений и опрашивает их. Подробнее описано в методе epoll.

[mdevils]

Вы уверены? Даже в случае с epoll основной тред не сможет читать сразу из большого числа соединений. Операция чтения из буфера, конечно, быстрая, но не когда у тебя, скажем 500 буферов получили данные. Могу ошибаться.

[el777]

Почему не сможет? Разве это большая нагрузка прочитать в цикле 500 дескрипторов?
Весь вопрос в том, с чем это сравнивать. Если вы разобьете приложение на 500 тредов, то все равно у вас будет 500 буферов, которые надо прочитать, то есть объем работы это никак не уменьшит. Но наоборот добавится работа по шедулингу (пардон за слово, не подскажете нормальный русский перевод?) всех этих тредов. Плюс возрастут расходы памяти на всевозможные таблицы для хранения служебной информации и т.п. То есть нагрузка серьезно возрастет.
Тредами и даже процессами можно делать, если они сами «дешевые» и легкие. Например, в Erlang VM процессы отъедают меньше 1400 байт для хранения одного процесса в таблице. Такие процессы быстро запускаются и работают, они смогут без проблем держать тысячи соедиений. В более привычных языках есть аналоги green threads в java, taskets в python.

[mdevils]

Да, теперь понимаю. Не учел, что шедулинг, который производит операционная система, тоже отнимает процессорное время.

[mdevils]

Спасибо.

[el777]

И вам спасибо.
Дали повод глубже задуматься над темой :)

[Teapot]

Да, в итоге не понятно, в чём отличие от обычного Comet, кроме дополнительного заголовка и готового js-api.

[Bambr]

Хотя бы в том, что соединение не переоткрывается после отправки сообщения.

[gbezyuk]

1) WebSockets заявляется как элемент стандарта HTTP, а Comet — нет.
2) comet — более собирательный термин. en.wikipedia.org/wiki/Comet_(programming) даёт 6 вариантов имплементации

[Teapot]

Т.е. это седьмой вариант имплементации. Пока не очень понятен номер версии стандарта HTTP, в который попадают WebSockets ;-)

[el777]

Не совсем.
WebSockets предполагается как 1 прямой метод, чтобы заменить 6 хаков :)

[kurokikaze]

WebSockets — часть HTML5, не HTTP.

[el777]

Сейчас очень бы хотелось видеть плагин, который бы определял возможность работы с веб-сокетами, если есть, то использовал их. Если нет, то пробовал бы флешку. Если не работает она, то плавно деградировал бы до комета — вот чудо вещь была бы!

[kurokikaze]

Супер :) Пошёл ковырять.

[kurokikaze]

Осталось дать клиентам возможность слушать соединения, и можно делать P2P-Интернет.

[grigoryvp]

Opera unite. Если сделают поддержку websockets то это будет… у-у-у-у… O_O

[kurokikaze]

Я имею в виду именно JS-команду «слушать порт».

Например, открывая YouTube клиент получает JS со списком пиров и ф-цией проверки хеша, пытается соединиться с пирами, качает контент, проверяет хеш. Если соединиться быстро не получается — запрос на видео отправляется самому YouTube.

[kurokikaze]

Хотя Юнайт судя по всему подойдёт.

[FenixArt]

Это должны было быть еще с начала существования протокола, я все время удивлялся почему не так, когда появился Аякс стало легче, а теперь только сделают по человечески.

[ap3rus]

Очень крутая новость для разработчиков streaming-платформ, отличная технология на замену Reverse-AJAX с фреймом, яхуу :)

[rushman]

Вот, делал для себя, Websockets Protocol для Twisted
bitbucket.org/rushman/tx-websockets/src/

[Teapot]

Добротно. На данный момент не поддерживает Expect: 100-continue, так?

[bolk]

Скажите, чем это кардинально отличается от server-side events, которые появились в Opera 9?

my.opera.com/WebApplications/blog/show.dml/438711

[arty]

кардинальное отличие только одно — web socket это скорее транспортный уровень, он не определяет формат данных внутри пакета, а server-side events в некоторой степени определяют

[bolk]

В server-side events передаются произвольные данные.

[arty]

если мне не изменяет память, там описан приблизительно такой формат:

event: test-event
data: lorem ipsum
data: lorem ipsum
data: lorem ipsum

это немного более подробное описание, чем у вебсокета

кроме того, вроде бы SSE не позволяет передавать бинарные данные

[bolk]

Кодировать никто не мешает. Делать escape/unescape, base64, чтоугодноещё.

[arty]

ага, но это дополнительная нагрузка, увеличение объёма и прочие радости — никак не бинарные данные

в общем, на нижнем уровне возможностей у web socket побольше, а про верхний, где вызов обработчиков для события с конкретным именем, он ничего не говорит, но это легко эмулируется

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

[bolk]

JS, в общем виде, ещё мало что умеет делать с бинарными данные. Зачем они пока в браузере? Кроме того, экранировать надо всего ничего — несколько символов.

[arty]

js может положить их на canvas, например, да мало ли что ещё

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

[bolk]

Можно считать, что JS их пока не может положить в Canvas, циклом и по одной точке — это слишком разорительно. А других методов пока нет.

[arty]

тут я уже не специалист, но разве ImageData не для этого?

[bolk]

Я не помню там методов, чтобы картинку можно было загрузить из строки.

[el777]

Не стал сюда примешивать Server-Sent Events, чтобы не раздувать статью.
Ключевое отличие в том, что SSE — это попытка «легализации» комета с лонг-поллингом — он работает поверх HTTP и имеет все те же проблемы, что его «родители». В частности даже официальная дока говорит о том, что прокси серверы могут закрывать неактивное соединение, поэтому периодически надо отправлять пустые сообщения. SSE — пассивный протокол, браузер «подписывается» на сообщения и дальше просто слушает, что ему пришлют. Самой интересной вещью в нем является контроль потока сообщений, если соединение вдруг разорвалось, то при возобновлении браузер передаст Last-Event-Id и передача начнется с того же места.
WebSockets же кардинально новая вещь — он работает как бы «сбоку» от HTTP на чистом TCP и ему ничего не мешает. Это протокол с 2 активными участниками — оба асинхронно обмениваются сообщениями. Вы можете не только получать сообщения, но и отправлять свои по тому же самому каналу.

С помощью WebSockets можно реализовать функционал SSE, причем работать это будет чуть ли не лучше оригинала. А вот наоборот не получится.

Поэтому, на мой взгляд, SSE уже потерял актуальность. Лично я не хочу тратить на него свое время.

Кстати, если говорить про реализацию в Опере 9, то она не идеальна — в стандарте предусмотрено название тега eventsource, а в опере тег называется event-source

[bolk]

WebSocket работает вполне себе на том же HTTP, никакого «боку», не вводите людей в заблуждение, это всего лишь расширение протокола.

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

Это недостаток SSE? Но он же есть и в WebSockets. Или WebSockets соединения прокси почему-то не будут закрывать?

Поэтому, на мой взгляд, SSE уже потерял актуальность. Лично я не хочу тратить на него свое время.

Вы как-то очень уж горячо взялись пропагандировать WebSockets и гнать от себя SSE. Вы знаете, что, например, существуют прокси и firewalls, которые режут незнакомые (да и некоторые знакомые, например, Accept-Encoding) заголовки? Как WebSockets будут чувствовать себя с таким софтом. Если мне не изменяет память, это около 10% всех подключений.

Кстати, если говорить про реализацию в Опере 9, то она не идеальна — в стандарте предусмотрено название тега eventsource, а в опере тег называется event-source

Стандарт меняется. Это ещё не релиз.

[el777]

> WebSocket работает вполне себе на том же HTTP, никакого «боку», не вводите людей в
> заблуждение, это всего лишь расширение протокола.
WebSockets использует HTTP только для коннекта дальше идет чистая TCP-сессия, SSE — на всем протяжении сессии для транспорта.

> Это недостаток SSE? Но он же есть и в WebSockets. Или WebSockets соединения прокси почему-
> то не будут закрывать?
WebSockets через прокси идет как бинарный трафик (метод CONNECT), SSE как чистый HTTP.

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

Разработчики уделили пробиваемости проксей немало времени.

> Стандарт меняется. Это ещё не релиз.
Это серьезная проблема. Стандарт еще не готов, а уже устарел. Необходимость в нем уже отпала. Когда он выйдет, WebSockets захватит рынок.

[bolk]

WebSockets использует HTTP только для коннекта дальше идет чистая TCP-сессия, SSE — на всем протяжении сессии для транспорта.

В любом случае, это протокол внутри HTTP, а не TCP.

WebSockets через прокси идет как бинарный трафик (метод CONNECT), SSE как чистый HTTP.

prooflink?

Разработчики уделили пробиваемости проксей немало времени.

Что они сделали для этого, я не увидел?

Это серьезная проблема. Стандарт еще не готов, а уже устарел. Необходимость в нем уже отпала. Когда он выйдет, WebSockets захватит рынок.

Так часто бывает с вещами, которые вышли до окончательного принятия стандарта. Вы, видимо, просто не следите за реализациями в браузере вещей из WHATWG.

[el777]

> В любом случае, это протокол внутри HTTP, а не TCP.
Протокол начинается как HTTP, а дальше работает по чистому TCP. Разработчики спецаиально сделали его похожим на HTTP, чтобы было проще использовать, и иметь меньше проблем с фаерволами, открытыми портами и всем прочим. Даже так скажу: изначально для него предполагался порт 81 (и 815 для шифрованного аналога WSS). Но в дальнейшем решили, что начинать надо по HTTP-шному, поэтому в текущей редакции выбраны 80 и 443 порты.

> prooflink?
Официальная дока: tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68#section-4.1

EXAMPLE: For example, if the user agent uses an HTTP proxy
for all traffic, then if it was to try to connect to port 80
on server example.com, it might send the following lines to
the proxy server:

CONNECT example.com:80 HTTP/1.1
Host: example.com

If there was a password, the connection might look like:

CONNECT example.com:80 HTTP/1.1
Host: example.com
Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE=

Otherwise, if the user agent is not configured to use a proxy,
then open a TCP/IP connection to the host given by /host/ and
the port given by /port/.

Вот про SSE:

As currently specified in
www.w3.org/html/wg/html5/#server-sent-events, HTTP proxies may buffer
fragments of the HTTP response, because they may legitimately assume that an
entire HTTP response is expected by the browser. This buffering behavior is
clearly bad for the end-to-end latency of message delivery and should be
avoided if possible.

7.2.5 Notes

Legacy proxy servers are known to, in certain cases, drop HTTP connections after a short timeout. To protect against such proxy servers, authors can include a comment line (one starting with a ':' character) every 15 seconds or so.

Значит надо готовить два «вантуза»: один 2-килобайтный, другой 15-секундный?

> Так часто бывает с вещами, которые вышли до окончательного принятия стандарта.
Да. Хотя я понимаю компании, им очень хочется быть первыми и объявить о новой фиче, чтобы привлечь пользователей. Но веб такая отрасль — здесь нельзя быть лучшим в одиночку. Весь веб — это взаимодействие участников на всех уровнях и во всех видах. Что толку от того, что кто-то поддерживает сверхмодный язык типа того же Jscript, если никто больше его не использует?

[arty]

> Кстати, если говорить про реализацию в Опере 9, то она не идеальна — в стандарте предусмотрено название тега eventsource, а в опере тег называется event-source

знали бы вы, сколько раз стандарт переписывался с момента реализации в опере, не называли бы его стандартом; ) Собственно, этого и нельзя делать, потому что он ещё не принят

[el777]

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

[arty]

вот смотрите: когда опера не спешит с реализацией скруглённых уголков, её ругают, а когда спешит с SSE — её тоже ругают. Как вы предлагаете поступать разработчикам оперы?

[brammator]

беспроигрышный совет — начать разрабатывать хром.

[arty]

мы уже видели, что бывает, когда остаётся только Один Браузер

[arty]

кстати, не напомните, разве в SSE есть возможность двустороннего обмена данными по одному каналу? в WS вроде есть, это тоже может сойти за кардинальное отличие

[bolk]

Нет, такой возможности нет. А в чём разница с практической точки зрения? Разве что скорость прохода команды. Но ведь у WebSocket есть огромный недостаток — он расширяет протокол HTTP, значит его будут резать некоторые прокси и firewallы (есть такие, которые режут всё незнакомое и часть знакомого), таких, кстати, около 10%.

[arty]

скорость прохода команды, да, плюс уменьшение накладных расходов для постоянного потока команд

что касается злых фаерволов и проксей: они будут в любом случае, но сейчас они рвут соединения и буферизуют данные, а у WS будут резать лишние заголовки, так что шило меняется на мыло, и разницы большой нет

[bolk]

При этом SSE будет работать и тут, а WebSockets — нет.

[arty]

если вспомнить двухкилобайтный буфер, то наверное лучше никак не работать, чем как SSE через такой буфер: )

вы станете спорить, что WS даёт больше возможностей ценой меньшей надёжности?

[bolk]

Возможностей столько же. Просто получить их можно меньшей ценой. А вот то, что WS не будет работать у 10% всех пользователей — очень плохо.

[arty]

вы недавно признали, что двустороннего обмена данными у SSE нет — и это означает, что у SSE возможностей меньше, а теперь говорите, что их столько же

[bolk]

Не приписывайте мне лишнего. Я признал, что двустороннего обмена по одному каналу нет.

[arty]

arty: кстати, не напомните, разве в SSE есть возможность двустороннего обмена данными по одному каналу?

bolk: Нет, такой возможности нет.

[bolk]

Именно это я и сказал — у SSE нет возможности двухстороннего обмена по одному каналу.

[arty]

а по двум есть?

[bolk]

Если мы говорим о рамках именно SSE — то нет, просто открывается канал любым другим способом. Ограничений-то нет.

[arty]

представьте, что я делаю многопользовательский шутер в браузере. Как мне передавать информацию о движениях пользователя 10 раз в секунду, не используя WS?

[bolk]

WebSockets тут тоже вряд ли подойдёт. Обрывы будут. Кроме того, я же не говорю, что WebSockets бесполезны. Я говорю, что их переоценили, а SSE недооценили.

[arty]

в хороших условиях WS тут подойдёт. И именно поэтому я говорю, что у WS больше возможностей, но меньше надёжности. Вы продолжите утверждать, что возможностей у WS не больше, а столько же?

[bolk]

Я продолжаю утверждать, что достоинства WS перед SSE уравновешиваются недостатками.

[arty]

то есть, вы согласны с моими словами многими комментариями выше, что WS даёт больше возможностей ценой меньшей надёжности? Я тогда не говорил, что эти новые возможности уравновешиваются меньшей надёжностью, но я с этим согласен.

[bolk]

Да.

Надеюсь, вы согласны, что SSE даёт больше надёжности, ценой меньшей возможности?

[arty]

конечно, согласен : )

к этому результату мы могли бы прийти намного раньше, если бы вы тогда не стали утверждать, что возможностей у SSE столько же, а просто сказали, что бо́льшая надёжность оправдывает SSE ; )

[bolk]

Почему я тогда должен был так говорить? Я так считал.

[arty]

ясно

[el777]

В чем большая надежность SSE?
Last-Event-Id?
Его можно сделать с помощью WebSockets — просто в случае обрыва канала передать номер последнего сообщения и продолжить получать данные.

[arty]

в неиспользовании новых http-заголовков

[el777]

Вы имеете ввиду надежность сессии или вероятность проблем при ее установлении?

[arty]

я имею в виду надёжность технологии, которая среди прочего включает в себя и вероятность проблем при установлении сессии

[el777]

Что касается установления, то проблемы должны решаться со временем, когда больше проксей будет настраиваться под WS. Хотя разрабы протокола писали, что они оптимизировали его под большую «пробиваемость».
А сама сессия, тоже должна быть надежнее. Хотя бы из-за отсутствия необходимости в «вантузах» для пробивания проксей.

[arty]

я не уверен, что время тут поможет, и полагаю, что за последние лет пять ситуация с проксями лучше не стала

[el777]

Мне нравится, что разрабы об этом подумали заранее: через прокси сессия должна устанавливаться как бинарная (метод CONNECT – по аналогии с HTTPS) либо использовать SOCKS-прокси.

[arty]

а у вебсокета есть .send()

[ni4]

Гм, и что тут оригинального? И какой с этом всего смысл, пока оно не станет поддерживаться всеми браузерами (а главное, серверами)?

[ap3rus]

Москва не сразу строилась ©

[vovchisko]

Всё будет хорошо. Все будут трудится вместе и сделают много хорошего. ;)

[silentroach]

Портов-то в системе не так и много, насколько я знаю, если проект высокопосещаемый и будет держать открытыми все коннекты — это ж сколько их потребуется?
А закрывать сервер соединение будет только если клиент пошлет определенный запрос? Ололо, заддосить сервера стало еще проще?

Да и как-то не считаю я это великим прогрессом, мир от этого сильно не изменится, просто программисты станут еще ленивее. Я лично хочу сам делать запросы, а не подходить к компьютеру и видеть, что сервер моему клиенту послал пару гигабайт не понятно чего, а клиент ему ответил еще большим :)

[grigoryvp]

Исходящих — 65к. Входящих на один и тот же порт — сколько угодно. У меня на тестах Windows Server 2008 миллион (!!!) входящих TCP подключений держал

[silentroach]

Я могу что-то путать, но мне казалось все время что сервер получает запрос на 80 порт (к примеру), берет свободный порт и оттуда уже общается с клиентом. Разве нет?

[grigoryvp]

Не совсем. Есть порты, есть сокеты. С точки зрения операционной системы все соединения идут на 80-й порт. Операционная система на каждое такое входящее подключение выделяет сокет — с ним сервер и работает. По сути, для берклевских сокетов сервер выглядит следующим образом: создаем сокет, говорим операционке — «этот сокет на 80-м порту. Жди на него входящих подключений». Как только к нам подключаются, операцонка нам извещает — «подключились. Вот вам сокет подключения». И этих сокетов на входящие подключения может быть очень много, от операцонки зависит.

[silentroach]

Спасибо, надо будет почитать что-нибудь по сетям, а то что-то у меня с ними совсем туго, похоже :(

[alekciy]

Очень рекомендую «UNIX. Разработка сетевых приложений» Стивенс У. Р. Сейчас вышло еще третье издание, его Раго переработал (Стивенс к сожалению уже умер). Но если и первое попадется бери. Труд гениальнейший. Написано так, что, имхо, может использоваться как учебник.

[bolk]

Нет, соединение идентифицируется по паре port-IP.

[mihaild]

Так если вы открыли страницу с чужого сайта — то он уже может послать сколько хочет информации через ajax.
Программисты, конечно, станут ленивее. Многие новые технологии придумываются исключительно для удобства программистов. Взять хотя бы языки высокого уровня)

[grigoryvp]

Это не лень. Это абстракции более высокого уровня. Чем более высокоуровневые абстракции предалгает технология, тем с меньшими затратами по времени и усилиям можно сделать работу. Соответственно, можно будет за то же время делать более сложные вещи.

[mihaild]

Так и WebSockets позволят делать более сложные вещи (в которых используются постоянные соединения => настоящий real-time вместо AJAX'ового «дерганья» сервера) за то же время.

[VolCh]

>тем с меньшими затратами по времени и усилиям можно сделать работу.

Ну, лень — двигатель прогресса ;)

[uno]

Правилом хорошего тона станет вопрос от сервера:
«Я тут вам гиг хочу прислать, можно?» :)

[vovchisko]

«Халява? давайте два!»

[elw00d]

Я всегда говорил, что рано или поздно HTTP вместе с HTML/js будет постепенно заменен на более мощную штуку. И первым, кто осуществит этот переход, станет гугл. Сначала это будет преподнесено как некое усовершенствование HTTP 1.1, а затем появятся и принципиально новые решения. Пионером в поддержке этих новшеств призван стать google chrome.

[bolk]

Я вашего восторга не разделяю. Обычная обёртка над Comet, которому сто лет в обед. «Опера» в девятой версии сделал то же самое — server-side events, никто, я уверен, из комментирующих даже не слышал об этом.

[grigoryvp]

Не обычная. Если вы про long polling — то там достаточно много весит HTTP-заголовок запроса. Передавать его на каждый чих во многих случаях очень накладно. Плюс, насколько я понимаю, long polling пересоздает TCP подключение после каждого получения данных с сервера. А пересоздание TCP подключения это длительный процесс.

[bolk]

Вы бы почитали о чём речь, прежде чем отвечать.

[bolk]

То есть, вы считаете, у Гугла они есть?

«Опера» не придумала этот стандарт, это часть стандарта WHATWG: www.whatwg.org/specs/web-apps/current-work/#scs-server-sent

[bolk]

Пока остальные браузеры не поддержат, никто не будет это широко использовать.

[bolk]

Именно. Поэтому проще просто использовать любой способ для организации Comet.

[bolk]

Достаточно FF.

[arty]

зря вы так, я их даже использовал; )

[elw00d]

Восторга, собственно, никакого и не испытываю. И про замену HTTP я говорил в более глобальном контексте развития web, скажем так.

[pgrishin]

прокси серверы идут лесом?

[pgrishin]

ну и файрволы, наты

[bolk]

Часть файрволов/проксей всё-таки идут (точнее их клиенты) — есть софт, который режет все незнакомые заголовки.

[belnetmon]

Масса проки знают, что HTTP висеть открытым не может и будут грохать его как зависший

[bolk]

Ровно как и в случае с WebSockets.

[sse]

О том и речь. Есть большая вероятность, что WebSockets будет нормально работать только «в теплице» на стенде, а в вебе, где большинство каналов спроектированы на «раз-два-конец связи», долгоиграющие коннекшены либо спровоцируют переделку инфраструктуры, либо станут крайне неюзабельны в связи с низкой надежностью.
По этому поводу (MMO real-time action app в брайзере) у разработчиков ТанкиОнлайн отличный доклад есть.

[el777]

Очень важное замечание. А ссылочкой на доклад не поделитесь?

[sse]

Вечером, хорошо? А то я счас не могу найти.
Еще мне интересно вот что: как в WebSockets будет реализован load-balancing? Ведь для для существующего веба это делается достаточно просто как раз потому, что он stateless или практически stateless.

[el777]

Спасибо.

Load balancing можно сделать на основе round robin, когда несколько машин будут принимать подключения, после этого, конечно, клиент «привязывается» к конкретному серверу.
Раскидывать подключения можно как с помощью железяки (ну это всегда будет работать), DNS, или же просто установить один приемник, который будет делать 302 редирект на конкретный сервер.

[el777]

Ответил тут: habrahabr.ru/blogs/webdev/79038/#comment_2318631

[vovchisko]

«Всё это в UTF8 и с бантиком».
//из печальной беседы о джумле с коллегой.

[Aux]

Странно, когда Opera сделала поддержку Server Sent Events, которые по-большому-то счёту тоже самое (но нужны два канала связи, а не один, тем не менее обе штуки из HTML5), то бомбы не случилось… Вебдевы странные — если новую фишку двигают вендоры из вне США, то никому она нафиг не нужна…

[ap3rus]

Это не совсем так, и SSE это не совсем то же самое, что и WebSockets, даже обсудили.

[Aux]

Я знаю про различия (: Фишка не в них, фишка в том, что у гугла хороший маркетинг, а люди не любят оперу. С SSE много чего интересного можно было сделать, но не прижилось. А насчёт сокетов — дык их сначала заимплементили в WebKit, потом решили вынести из HTML5 (я считаю правильно) и вырезали из вебкита. Сейчас вот обратно вернули.

[LaggyLuke]

В Хроме все изменения сделаны в WebKit — а значит очень скоро появится поддержка в Safari.

WebKit — это движок рендеринга.
Вы ничего не перепутали?

[KKS]

Ну вот, а совсем недавно кое-кто представлял свое comet-решение… Успел :)

[Alex_At_Net]

Товарищи, можно пару вопросов?

А когда появится расширение в браузере, которое будет WebSocket сервером? Тогда Opera Unite RIP?

Пасибо.

[Mithgol]

1) Ответ на вопрос «когда» не знаю, оттого что не онейромант, не телепат, не хиромант, не огнищанин, не чревогадатель, не авгур, не теург, и так далее.

2) Думаю, что в случае чего Opera Unite проапгрейдят, и тем невозбранно достигнут желаемого.

[bolk]

Какое же всё-таки неудачное название — WebSocket. На WebSocket нельзя написать веб-сервер.

[TravisBickle]

Кстати, не переживайте из-за совместимости ;-) Мы с товарищем скоро сделаем флешку в несколько килобайт, и API для Javascript полностью совместимое с оригинальным объектом WebSocket. Будет работать во всех броузерах где есть флеш.

[sys]

только вы проверьте сначала работоспособность с активным антивирусом касперского.

[TravisBickle]

Боюсь его под Ubuntu 9.10 нету :-) А что — проблемы? Я думаю их пофиксят, как только дядя Женя прочтет Хабр.

[alekciy]

С технической точки зрения сравнивать WebSocket и AJAX безграмотно. WebSocket это описание конкретного интерфейса взаимодействия. AJAX это не более, чем принцип, подход к написания веб приложения (Гаррет, автор данного термина, вообще не программер). Реализован он может быть через XHR, через iframe.

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

[el777]

А чуть точнее, где именно логические ошибки?
Ну и данная статья — вводная.

[alekciy]

Ну конкретно меня зацепила строка «На мой взгляд, через некоторое время останется только 2 технологии: чистый AJAX и WebSockets.» Ну и по изложения складывается впечатление, что автор вкладывает в термин AJAX «юзерско-маркетинговое» понимание. Бог с ними с манагерами, им бы продать только понавесив красивых ярлычков, но технически образованные люди не должны так писать.

[el777]

Под «чистым AJAX-ом» я подразумею AJAX без всех Комет-наворотов типа лонг-поллинга, стриминга, мультипарта и прочего. Все, что пытается расширить его дальше задумки.
XHR — это способ реализации, но опять же не единственный.
Кстати, XHR обозначает XmlHttpRequest, но только XML-ем там давно не пахнет.

[alekciy]

>Кстати, XHR обозначает XmlHttpRequest, но только XML-ем там давно не пахнет.
И это вы мне говорите?

Нет ни чистого ни грязного AJAX. Есть просто подход при котором обновляется только часть страницы. Причем люди с прямыми руками реализовывали это на iframe+html+javascript еще в конце девяностых прошлого века.

Нельзя сравнивать белое с пушистым, AJAX с WebSockets, подход к написанию приложения с конкретным примером реализации.

[el777]

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

Я с вами соглашусь, что люди делали тоже самое с помощью IFrame уже давно. Но по большому счету (с точки зрения предназначения HTML, Frame и тп.) — это хак — то есть использование инструментов не по назначению. В дальнейшем это было стандартизовано и снабжено доп. фичами в виде XmlHttpRequest. И предназначено для частичного обновления страницы. В дальнейшем возникла необходимость обновлять часто и в неизвестное для клиента время. Пошли лонг-поллинги и прочее.
Но опять же, асинхронность в них довольно однобокая. Например, вы можете отправить одновременно 2 запроса? А 5?
Проблема в том, что принцип «запрос-ответ» все равно лежит в основе всего этого: от ифрейма прошлого века, до новейшего XHR.

Теперь же предлагется честная асинхронность. Уже нет ни «запросов», ни «ответов» — каждый говорит когда ему надо. Поэтому WebSockets не просто новая технология или название яваскриптовых объектов на странице, но еще и новая идеология.

[alekciy]

2? 5? Я могу.

Могу уверить, WebSockets как технология абсолютно не нова. Флеш спокойно позволяет держать сокеты. В обычном сетевом, не веб мире, долгие коннекты вполне себе банальное действо. Но вот оно доползло до HTTP и все, революция. Ничуть. Поэтому я все же настаиваю, что в данном случае WebSockets это не более, чем описание интерфейса для старой технологии созданное для веба. Да, меня как разработчика это не может не радовать, но я то отлично понимаю, что это не вопрос создания новой технологии, а просто вопрос того, сколько крупных игроков поддержит эту реализацию (XHR поддержали очень многие и это стало очень быстро развиваться) и она уйдет в массы. Не более. Написать свое расширение HTTP на самом деле не проблема, возьмем, к примеру, WebDAV, проблема в том, на сколько это будет поддержано другими игроками.

[el777]

В обычном сетевом, не веб мире, долгие коннекты вполне себе банальное действо.

Совершенно верно! TCP-протокол старше нас с вами! Это норма сетевого взаимодействия. А команде telnet, которая позволяет это все делать в консоли — «в обед сто лет». Здесь я не собираюсь с вами спорить, т.к. придерживаюсь той же самой точки зрения.

Но вот оно доползло до HTTP и все, революция. Ничуть.

Несмотря на то, что HTTP бегает поверх TCP, он разработан не для долгих сеансов, а чтобы подключиться, взять документ и освободить ресурсы. Именно в таком порядке: «запрос — ответ(ы)», и никак иначе. Я имею наглость утверждать, что HTTP в принципе синхронный протокол именно по этой причине. Даже в слове AJAX первая буква написана маркетологом. Асинхронный по отношению к чему? К загруженной страничке в браузере, к вызвавшему ява-скрипту, но не по отношению к серверу. Поэтому в аяксе асинхронность половинчатая. Все комет-технологии это только способ улучшить положение, приподнять степень асинхронности. И именно вот сюда — в сетевое взаимодействие сервер-клиент — веб-сокеты приносят честную асинхронность. Потому что все остальное (яваскрипт с коллбеками) уже готово и ждет.

Флеш спокойно позволяет держать сокеты.

Чуть выше уже выразили мнение, что флеш это хак. И оно имеет под собой почву. Флеш вещь немного инородная по отношению к браузеру, поэтому логично, что он имеет свои сокеты, свой XML-объект и так далее. Очень хорошо, что мы его можем использовать для исправления положения. Но когда мы сможем от него отказаться и использовать нативную поддержку веб-сокетов, будет лучше. Потому что иначе мы будем натыкаться на проблемы с проксями, баннерорезалками, корп. политиками и прочим — обратная сторона самостоятельности флеша.

Поэтому я все же настаиваю, что в данном случае WebSockets это не более, чем описание интерфейса для старой технологии созданное для веба.

А я возьму и соглашусь :) И даже выделю курсивом три последних слова в вашей фразе! :)
Мне тут попалось хорошее определение веб-сокетов, которое претендует на звание лучшего: «WebSockets — это TCP для Web».

это не вопрос создания новой технологии, а просто вопрос того, сколько крупных игроков поддержит эту реализацию

Согласен. Например, Мозилла уже поддержала эту инциативу, и, полагаю, в следующем фаерфоксе будет эта технология. Может где-то к лету.

(XHR поддержали очень многие и это стало очень быстро развиваться)

Да, хотя и там косяков было предостаточно, вплоть до разных название одного объекта в разных браузерах. Проблема в том, что там решение шло «снизу» — от конкретных разработчиков браузеров, а здесь «сверху» — от разработчиков стандартов. Понятно, что на самом деле это одни и те же люди :) Но в одном случае действуют сами по себе, а в другом — сообща.

[Teapot]

Многие ли уже перешли на Google Protocol Buffers?

[Kodeks]

Это, наверное, и можно назвать web 2.0…

[el777]

Зачем переписывать? Можно добавить!

[TravisBickle]

Товарищи! Меня опередили! Уже есть JS <-> Flash <-> WebSocket Server
http://github.com/gimite/web-socket-js
Так что все броузеры уже поддерживаются.

[el777]

Товарищъ TravisBickle!
Вы меня расстроили — ведь я даже указал ее в статье!

А если нельзя, но очень хочется?

На этот случай придуман временный заменитель — библиотечка web-socket-js с помощью флеша эмулирующая веб-сокеты

[TravisBickle]

Видимо, не с самого начала, я просто не перечитывал заново.
Спасибо за пост.
Буду готовить статью о демоне =)

[el777]

Будем ждать статью! :)
Спасибо!

[TravisBickle]

P.S. Кстати, предлагаю разместить в вашей статье ссылку на мою реализацию сервера, я кидал её в комментах.
Приведенный проект phpwebsocket производит стойкое впечатление убогой фигни, кривее написать трудно =)

[el777]

> Приведенный проект phpwebsocket производит стойкое впечатление убогой фигни, кривее написать трудно =)
СОгласен. Это очень примитивный пример, который легко пощупать собственными руками на своем компе. Я смотрел разные реализации, но какие-то сделаны на Руби, какие-то на Erlang в конце концов выбрал ПХП — как язык, который более-менее всем знаком. А значит проще будет поковыряться.

Да, давайте размещу. Пришлите к ней небольшой коммент, как лучше написать про вашу реализацию.

[kuser]

Google уже торт.

[orcy]

Все зависит от проксей. Пока прокси не начнут поддерживать эти соединения не будет вебсокетс нормального.

[mybrain]

а как насчет аплоада бинарных данных (типа файлов из локальной фс)? так и будем невидимый флеш впихивать, управляемый яваскриптом?

[el777]

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

[el777]

А это не требуется, потому что длина блока данных заранее известна.

[el777]

Все в порядке — 28 число на вроде:)
Уже пора думать о ёлках, голова сама просит :)

[el777]

Жестко:)
А что пишете если не секрет? На чем?

[el777]

Как запустите — напишите!
Из питонистого хайлоадного я тоже присмотрел торнадо.

Это нормально — ведь нужны разные спецы, им можно поручить что-нить другое. :)

[Throwable]

Возвращаемся в 90-е. Когда аплет открывал обычное TCP-соединение с сервером и использовал функциональность без всяких наворотов. ))))

> В отличие от HTTP веб-сокеты не имеют ограничений на время жизни в неактивном состоянии.
Теоретически. Реально в ОС практически всегда установлен Timeout по которому автоматически закрывается сокет.

> Это значит, что больше не надо периодически рефрешить соединение, т.к. его не вправе «прихлопывать» всякие прокси.
Опять теоретически. Когда это станет реальностью, пройдет еще лет 5. А пока что будьте уверены, если у вас корпоративный файрволл — через пару минут ваше соединение завершится.

> Значит, соединение может висеть в неактивном виде и не требовать ресурсов. Конечно, можно возразить, что на сервере будут забиваться TCP-сокеты.
И забьются моментально, т.к. клиент при закрытии соединения не посылает терминального пакета. Сокеты так и останутся висеть в неактивном состоянии.

Реально что приходится делать:
1. Сервер время от времени пингует клиентов, чтобы оборвать неактивные «висящие» сокеты.
2. Опционально клиент тоже может пинговать сервер, и например определять время пинга.
3. Поскольку надежность http-соединения не гарантирована (корпоративные прокси), приходится реализовать механизм автоматического реконнекта.

[el777]

> Возвращаемся в 90-е. Когда аплет открывал обычное TCP-соединение с сервером и использовал функциональность без всяких наворотов. ))))
А в том и соль эволюции технологий, что тоже самое (или чуть лучшее) достигается более простыми средствами, с большей надежностью, безопасносностью, сервисом и тп.

> А пока что будьте уверены, если у вас корпоративный файрволл — через пару минут ваше соединение завершится.
HTTP — да. Но прибивать любое TCP подключение просто через 2 минуты некорректно даже для корпоративного фаервола.

> И забьются моментально, т.к. клиент при закрытии соединения не посылает терминального пакета. Сокеты так и останутся висеть в неактивном состоянии.
Почему не посылает? Это предусмотрено стандартом TCP, если он не посылает, то он работает не по стандарту. Значит, он не клиент, а неведомая хрень.
Чтобы не забивалось надо иметь хорошую цифру в somaxconn и хороший мультиплексор.

> Реально что приходится делать:…
Да, на практике это надо будет сделать. Чтобы учеть даже такие банальные вещи, как случайный отруб инета у клиента (например, если у него модем или еще что-то). В таком случае, нам надо узнать, что он отвалился и дать ему возможность переконнектиться.

Но и это тоже легко реализуется в технологии вебсокетов:
1. Честное отключение вызовет закрытие сокета, которое можно обработать.
2. Если мы при отправке пакета получили ошибку, то сокет надо закрыть.
3. Если отправили пинг и клиент за установленное время не ответил — то так же надо закрыть.

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

[inxaoc]

Да уж запоздал WebSockets! Его бы года-два назад, кто ж сейчас будет переписывать сотни веб-приложений которые работают по принципу десктопных и с активным ajax-взаимодействия (гугл доксы, веб топы, гмейл, вейв, и пр)? Т.е. можно смело выделять бюджеты на переписывание веб-приложений ))

Но лучше поздно чем никогда!

[inxaoc]

Кстати кто писал веб-приложения, в соответствии с канонами разработки, используя паттерны смогут возрадоваться! WebSockets еще раз доказал необходимость умного подхода к разработке — абстрагируйтесь от httprequest, comet и прочего.

[inxaoc]

что-то мне подсказывает, что если бы не real-time web, долго бы еще лежать этой технологии на полке!

[el777]

Так часто бывает: возникла необходимость, а потом появилось решение. Точно так же было с самим аяксом — все тоже самое вначале делалось с помощью IFrame, долгогрузящийся скрипт и пр. Но это все были кривые решения, которые естественно вызывали разные проблемы с проксями, антивирусами и тп. XHR стандартизировал поведение и отправил всех своих предшественников на свалку истории. Та же ситуация сейчас с Comet — это ряд хаков, наросших на XHR. По этому они таким же образом будут заменены WebSockets-ами! И мы получим хорошее безглючное окружение.

[clockworkbird]

Возможно пропустил, но интересно, как будет решаться проблема, по которой веб изначально и был асинхронным. Если я открываю коннект и не закрываю — как долго коннект будет висеть? А если открывать их очень быстро, в цикле и очень долго? Просто интересно.

Если нет заголовков, и де-факто самого протокола (т.е. веб-сокеты получаются очень низкоуровневым протоколом), то придется писать собственный протокол поверх веб-сокета, чтобы отслеживать юзеров (аналог куки), например. Предвкушаю появление библиотек реализующих протоколы поверх сокетов )

А вообще возможности открываются поистине безграничные, это радует.

[el777]

> Если я открываю коннект и не закрываю — как долго коннект будет висеть?
По идее сколько угодно. Спецификация не оговаривает этот вопрос и оставляет на откуп разработчику прикладного приложения. На практике надо учесть таймауты, какие-нибудь промежуточные роутеры, обрывы соединения и прочее, что может закрыть его раньше.

> А если открывать их очень быстро, в цикле и очень долго?
Снова вам дана полная свобода действий. Как разработчик приложения вы можете решить, что для каждого блока данных вам нужно свое подключениее, а можете все гонять через одно подключение — как сделано в моем демо примере.

> Если нет заголовков, и де-факто самого протокола (т.е. веб-сокеты получаются очень низкоуровневым протоколом), то придется писать собственный протокол поверх веб-сокета, чтобы отслеживать юзеров (аналог куки), например.
С одной стороны да, протокол получается довольно низкоуровневым, а с другой масса проблем исчезает как класс. Например, отслеживать юзеров уже не нужно — потому что у вас постоянное подключение и на этапе его установления вы понимаете кто пришел. Дальше вам не нужно проверять его куку — потому что все, что пришло через данное подключение пришло от данного пользователя.

Если вам интересно, могу предложить посмотреть мой демо-пример: chat.websockets.ru/
— Работает на одном подключении: каждое сообщение имеет признак типа. Далее на клиенте JS разруливает что с ним делать.
— как только пользователь подключается или отклчючается моментально всем в чате присылается инфо об этом
— Реализован пинг — раз в 5 секунд идет обмен пингами для проверки живости. Но это из разряда улучшений — если вдруг где-то посередине бешеный роутер прихлопнет сообщение. Но это не очень обязательно.
— Весь обмен сообщениями в JSON — можно легко отдебагать.
— Есть авторизация: при установлении соединения пользователю назначается рандомный цвет ника, с которым он дальше ходит до тех пор, пока не закроется его подключение.
— Можно легко сделать проверку пароля — сейчас сделана проверка не непустой ник. Плюс — все проверки только один раз при подключении
— Масса вещей намеренно не оптимизировалась, чтобы посмотреть на скорость работы. Например, присылка истории чата — все сообщения присылаются по отдельности вместо общего пакета

[romy4]

а очень интересно будут работать xss с открытыми веб сокетами :) если не проверять, то встроенная сторонняя библиотека в сайт сможет сделать огого сколько всего

[el777]

так проверьте :) — ссылку на чат я привел :)
Дело в том, что XSS не есть проблема самой технологии будь то HTML, JS, PHP — что угодно. XSS — это проблема плохо отфильтрованных данных. Если вы их качественно фильтруете, то все будет в порядке.

[romy4]

никто не спросил, я спрошу. такой ли уж выигрыш от изменяемого размера поля „длина данных“, если а) надо делать каждый раз перевод в формат поля на сервере, б) перевод поля из формата в инт на клиенте. длина более 2миб данных уже займут 4 байта. что-то как-то непонятно

[el777]

Что такое 4 байта при размере данных в 2 МБ? Накладные расходы на заголовки будут занимать в сотни раз больше.
Выигрыш главным образом за счет отсутствия ограничений — надо вам передать гигабайт — пожалуйста, нужно будет потом несколько терабайт — тоже без проблем. Без необходимости обновления протокола. При этом для небольших данных (сотни байт) минимальный оверхед — всего 1-2 байта.

[romy4]

если за один раз можно отправить только один пакет данных размером N, то да, а если сокет не закрывается после отправки данных, то тогда непонятно. заголовок, я так понимаю, только один раз отправляется при установления соединения.

[el777]

У меня сложилось впечатление, что вы путаете 1) установочные заголовки соединения — то есть те, которые отправляются только при открытии сокета, и 2) рабочие заголовки — то есть те, которые отправляются при каждом сообщении.

1) Это большой блок начинающийся с GET c Upgrade и прочим — это все будет отправлено только вначале и только 1 раз, на этапе установления соединения.
После чего сокет остается открытым.

2) После установления соединения, каждое сообщение имеет заголовок.
Если это текстовое сообщение, то вначале его идет байт 0х00, а в конце 0xFF.
Если это бинарное сообщение, то вначале его будет 0x80, потом то самое указание длины, а после тела сообщения ничего не будет.
После каждого сообщения сокет остается открытым и готовым передавать новые данные.

Пос

[romy4]

блин, ошибся веткой. ответ ниже habrahabr.ru/blogs/webdev/79038/#comment_3948167

[romy4]

не путаю. у меня конкретный вопрос про указание длины в странном формате, а не uint32 и даже не uint64 которые накладывает на обе стороны ещё дополнительные преобразования, занимающие время.

[el777]

Так и не понял, что же вас смущает? Оверхед из-за того, что поле получается чуть длиннее, чем если записать в банальный uint32? Сложность обработки?

[megido]

афигеть, вы уже полтора года отвечаете на комментарии данного поста!

[el777]

:))
если тема интересна — то почему нет :)

[kolpeex]

Мне, кстати, тоже не нравится эта странная экономия на паре байт. Могли бы уж сделать разные заголовки: 0x81 для одного байта длины и т.д.

[WiZ_Ed]

А благодаря этой технологии запреты на вконтакте можно будет обойти?
Если да, то как с этим бороться?

[el777]

Технология не имеет отношения к запретам на вконтакте.

P.S. Вы хотите обойти этот запрет или наоборот не дать другим обходить их?

[WiZ_Ed]

Не дать другим.
Просто на одном из сайтов видел комментарий, что вроде даст такую возможность.
Вот и возникли сомнения.

[el777]

Ссылочку подкинете?
Самому стало интересно как это может быть :)

[WiZ_Ed]

Просто был комментарий на ЛОРе.
Было без аргументации.
Но если нет, то хорошо.
Спасибо за ответ.

[vmarunin]

Что значит «нет таймаута»?!
Я вот смотрю на это дело с точки зрения сервера и немного не разделяю восторга.
Во-первых, каждый сокет стоит памяти, ядерной, не свопящейся памяти размером в TCP Window как минимум. Если взять 1500 байт (Ethernet фрейм), то 1 миллион открытых коннектов это 1,5 Gb памяти на сервере псу под хвост. И это на передачу только ping'ов! Чтобы качать большие данные нужны большие окошки.
Во-вторых, как сервер будет закрывать дохлые сокеты без таймаута? Очевидно, что связь рвётся и т.д., а открытые сокеты будут утекать. Явно будут таймауты на сервере, то есть обрабатывать их всё равно надо.

Ну и не понятно как это хозяйство отобразить на стандартные процессы/нити. Если как обычно, один запрос — одна нить, то не очевидно как делать серверный броадкаст. Да и пара тысяч одновременных (с точностью до миллисекунды) запросов к PHP может плохо кончится для сервера.

[FlameStorm]

0x00, <строка в кодировке UTF-8>, 0xFF

круто… получите string-zero в новой упаковке.

0x80, <длина — один или несколько байт>, <тело сообщения>

...

Что значит «один или несколько байт»? Чтобы не создавать ограничений на длину передаваемого сообщения и в тоже время не расходовать байты нерационально, разработчики использовали очень хитрый способ указания длины тела сообщения. Каждый байт в указании длины рассматривается по частям: самый старший бит указывает является ли этот байт последним (0) либо же за ним есть другие (1), а младшие 7 битов содержат собственно данные. Обрабатывать можно так: как только вы получили признак бинарного дата-фрейма 0x80, вы берете следующий байт и откладываете его в отдельную «копилку», смотрите на следующий байт — если у него установлен старший бит, то переносите и его в «копилку», и так далее, пока вам не встретится байт с 0 старшим битом. Значит это последний байт в указателе длины — его тоже переносите в «копилку». Теперь из всех байтов в «копилке» убираете старшие биты и слепляете остаток. Вот это и будет длина тела сообщения. Еще можно интерпретировать как 7-битные числа без старшего бита.

Ну что за нафиг за шедевр инженерной мысли 21 века с псевдоэкономией байтов?
Нет бы отдали старт-коды с 0x80 по 0x87 под бинарные данные, где в старткоде в младших 3 битах хранится лог2 размера инт-числа хранящего длину бинарного сообщения?
80 значит длина 2^0 = 1 байт, читаем следующий байт и получаем длину сообщения от 0 до 255
81 — 2 байта — 0..65535
82 — 4 байта — до 4Гб
83 — 8 байт — до 17 млн терабайт
84-87 исключительно для маньяков, на вырост технологиям.
Что касается 3 байт или там 5 байт — бессмысленно при объёме сообщения 64Кб+ и тем более 4Гб+.

Плюс решения понятный — и размер переменной, хранящей длину сообщения, просто определяется — как 1 << (codebyte & 0x07), — и читать придётся круглое число последующих байт хранящих длину (байт, слово, двойное, четверное) в большинстве случаев прямо в регистр процессора (для ЯВУ — прямо в интовую переменную) без какой либо последующей обработки.

Сейчас конечно шашкой махать по вебсокетам уже не время, но быть может и коммент в дебрях Хабра позволит будущим разработчикам создавать чуть больше правильного кода.

[el777]

Возможно, разработчики всеми силами хотели избежать ловушки «точно хватит для всех» — то есть задавать какое бы то ни было ограничение, пусть даже нереально огромное.
Когда-то казалось, что IPv4 содержит достаточно адресов. В общем так оно и есть и даже с огромным запасом — если считать только военные компьютеры. Никто не знал, как будет развиваться интернет, что он станет частью обычной гражданской жизни.

Разработчики заложили еще 127 вариантов кодирования бинарных данных. Не исключено, кто когда-то добавят код 0x81, при этом в следующем байте будет ln₂ следующих байт длины, дальше сама длина. Итого, можно будет задавать значения до 2²²⁵⁵. Теперь точно должно хватить. Но вдруг через 5-10-20 лет появится межгалактический интернет? Количество атомов во Вселенной оценивается величинами порядка 10⁸⁰ ≈ 2²⁶⁶. Но, возможно, наша оценка размеров Вселенной будет кардинально пересмотрена? Или, что более вероятно, инструмент будет использоваться каким-то совсем другим способом и опять не хватит.

[FlameStorm]

Вы тоже разделяете мой оптимизм по будущему http-надстройки по имени вебсокет? )

[el777]

Еще как разделяю. Только не готов называть его надстройкой. Скорее это кардинальное расширение в соседние сферы. )

[chabapok]

Сорри за некропост, но если делать так: «как только вы получили признак бинарного дата-фрейма 0x80, вы берете следующий байт и откладываете его в отдельную «копилку», смотрите на следующий байт — если у него установлен старший бит, то переносите и его в «копилку», и так далее, пока вам не встретится байт с 0 старшим битом.»

то при вот таком фрейме: 0x80, 0x2B, |тело сообщения|
первый байт (и возможно следующие) тела сообщения попадет в рассчет длины — что будет некорректно.

У 0x2b тоже должен быть проверен 7 бит, т.е. сразу после 0x80 ненадо откладывать в копилку. Надо проверить 7 бит, и только потом откладывать.

[el777]

Приветствую. Только сейчас заметил ваш коммент )
Возможно, надо было расставить скобки, чтобы читалось более однозначно.
В этом цикле должен быть не только перенос следующего байта, но и проверка нового байта на конец повторения.
Здесь имелся ввиду примерно такой псевдокод «как только вы получили признак бинарного дата-фрейма 0x80, do { берете следующий байт, делаете ему & 0x7f и переносите его 7 младших битов в «копилку», } unless ( у текущего байта 0 старший бит.) »

[chabapok]

Да, об этом и речь.

[Encircled]

Update 2016+ год на всякий случай: как минимум у data-frame спецификация немного изменилась (ссылка)

[muradali]

Привет из 2022 года! Технология вебсокетов полностью созрела и можно начинать пользоваться!