А зачем нужны websocket?

Поверх http только handshake

ИМХО, нужны в первую очередь не зачем а для кого. Для программистов JS-фронтэндов (ну, ещё и dart недавно объявился). Им очень не хватало сокетов, а производители браузеров почему-то не давали им в руки такого функционала. Приходилось извращаться, типа внедрять в страницу flash-объект, который уже мог соединяться c хостами, отличными от того, с которого страница загрузилась.

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

по сравнению с обычным TCP

Работает в браузере, это же очевидное преимущество.

Ты знаешь разницу между прикладным и транспортным уровнём?

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

You are doing it wrong. Кто в здравом уме будет слушать 65535 портов и делать отдельные соединения на каждый чих?

А в чем отличия слушать 65535 портов или столько же вебсокетов?

Зачем слушать 65535 вебсокетов??! ЯННП.

а зачем слушать 65535 портов, если тебе хватит меньшего числа?

Хватит одного порта.

веб-сокеты работают внутри HTTP протокола

Нет, от HTTP там только handshake. RFC 6455, пункт 1.5:

Conceptually, WebSocket is really just a layer on top of TCP

это не важно — идут они внутри HTTP. Так что прокси / веб-сервер должен это понимать

Нет. И вообще, поверх http дуплексный канал не сделать

Websockets работают внутри HTTP соединения. Сомневающиеся могут посмотреть tcpdump

Ну, возможно я плохо читал стандарт. Но мне показалось, что все-таки только рукопожатие в http завернуто.

Тем что можно слушать евенты с сервера + на коротких сообщениях сильно меньше накладные расходы.

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

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

Вебсокеты выгоднее если тебе нужен постоянный интерактив

ну тоесть для чата или онлайн-игрушек браузерных. а для всяких рейтингов, корзин в веб-магазинах и всяких прочих сортировок-фильтров - получается лучше ajax? хотя логично в целом.
но - с точки зрения веб-сервера ajax-запрос это самый обычный запрос, и если там настроено keepalive - соединение будет висеть еще некоторое время. а веб-сокет через какое время отваливается? как вообще там организованы таймауты?

Помоему никак. Если клиент присоединился то будет сидеть пока страница открыта или твое приложение его не отсоединит

я так понял это альтернатива AJAX?

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

и да, с этого момента что-то изменилось?

Проверял в фоксе 19 - работают на ура.

По-человечески, нужно просто разрешить JS открывать любой сокет

Ты упоролся. И получим кучу syn-flood ботнетов. Ах да, плюс уязвимость в виде подключения к портам, слушающих только на локалхостах.

ну а если клиент присоединился, а затем у него пропал интернет или поменялась траса к целевому ресурсу? с ajax все понятно. в случае с вебсокетом - не совсем.

А у Вас тег тупняк отклеился.

а ты почитай остальные треды этого пациента, на этом форуме тег «тупняк» равносилен нику ТСа

И получим кучу syn-flood ботнетов

С чего бы?

А если ты в аську зашёл, а потом пропал интернет? Всё то же самое.

а затем у него пропал интернет или поменялась траса к целевому ресурсу? с ajax все понятно. в случае с вебсокетом - не совсем.

websock.onclose = function(e) {
 тут код для реконнекта
}

ну т.е есть механизм keepalive все-таки, ясно =)
спасибо всем за инфу, дальше буду читать за них сам.

Потому что получаем возможность создавать сотни висящих tcp-соединений к атакуемому ресурсу от каждого клиента.

Я не знаю, чего не хватает в tcp для реализации нужного функционала

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

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

даже прогриммисты не хотят вынимать руки из известного места, они готовы /dev/exynos_mem доступный любому пользователю запилить, лишь бы не думать.

скоро и не такое появится.

Не альтернатива, а гораздо более полноценная замена.

Траффик не жмется. Уже не полноценная

Проверял в фоксе 19 - работают на ура.

Осталась мелочь - чтобы заработало за кучей корпоративных прокси.

Траффик не жмется. Уже не полноценная

Не знал. А в чем проблема гзиповать?

Осталась мелочь - чтобы заработало за кучей корпоративных прокси.

Это уже вопрос времени.

Не знал. А в чем проблема гзиповать?

Протокол пока не поддерживает из коробки (ХЗ в каком состоянии drafts). Можно ручками, но гиморно.

Я к тому, что есть домашние эксперименты «работает у меня и у друга Васи», а есть реальные продакшены, где все эти смелые идеи бесполезны.

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

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

Ваши рассуждения про светлое будущее на продакшен не прикрутить :)