Некоторые отличные ответы от других, которые охватывают множество вопросов. Вот еще немного.
Единственное преимущество WebSockets перед плагинами, такими как Java Applets, Flash или Silverlight, заключается в том, что WebSockets изначально встроены в браузеры и не зависят от плагинов.
Если под этим вы имеете в виду, что вы можете использовать Java-апплеты, Flash или Silverlight для установления соединения через сокет, то да, это возможно. Однако вы не часто видите это в реальном мире из-за ограничений.
Например, посредники могут отключить этот трафик. Стандарт WebSocket был разработан для совместимости с существующей инфраструктурой HTTP и поэтому гораздо менее подвержен вмешательству со стороны посредников, таких как межсетевые экраны и прокси.
Более того, WebSocket может использовать порты 80 и 443, не требуя выделенных портов, опять же благодаря дизайну протокола, который максимально совместим с существующей инфраструктурой HTTP.
Эти альтернативы сокетов (Java, Flash и Silverlight) сложно безопасно использовать в архитектуре с перекрестным происхождением. Таким образом, люди, часто пытающиеся использовать их из разных источников, скорее будут терпеть неуверенность, чем прилагать усилия, чтобы сделать это безопасно.
Они также могут потребовать открытия дополнительных «нестандартных» портов (что администраторы ненавидят делать) или файлов политик, которыми необходимо управлять.
Короче говоря, использование Java, Flash или Silverlight для подключения к сокетам достаточно проблематично, поэтому вы не увидите, как они часто используются в серьезных архитектурах. Flash и Java имеют такую возможность, вероятно, по крайней мере 10 лет, и все же она не является распространенной.
Стандарт WebSocket смог начать с нового подхода, помня об этих ограничениях и, надеюсь, извлек из них некоторые уроки.
Некоторые реализации WebSocket используют Flash (или, возможно, Silverlight и / или Java) в качестве запасного варианта, когда соединение WebSocket не может быть установлено (например, при работе в старом браузере или при вмешательстве посредника).
Хотя какая-то запасная стратегия для таких ситуаций является разумной и даже необходимой, большинство из тех, кто использует Flash и др., Будут иметь недостатки, описанные выше. Так не должно быть - существуют обходные пути для достижения безопасных соединений с возможностью кросс-происхождения с использованием Flash, Silverlight и т. Д. - но большинство реализаций этого не делают, потому что это непросто.
Например, если вы полагаетесь на WebSocket для соединения с разными источниками, это будет работать нормально. Но если вы затем запустите в старом браузере или вмешался брандмауэр / прокси и, скажем, полагаетесь на Flash в качестве запасного варианта, вам будет трудно установить такое же соединение между разными источниками. Если, конечно, вы не заботитесь о безопасности.
Это означает, что сложно иметь единую унифицированную архитектуру, которая работала бы для нативных и неродных соединений, если вы не готовы приложить немало усилий или использовать фреймворк, который справился с этим хорошо. В идеальной архитектуре вы не заметите, были ли соединения родными или нет; ваши настройки безопасности будут работать в обоих случаях; ваши настройки кластеризации по-прежнему будут работать; ваше планирование мощностей по-прежнему останется в силе; и так далее.
Единственное преимущество WebSockets перед потоковой передачей по протоколу http заключается в том, что вам не нужно прилагать усилия для «понимания» и анализа полученных данных.
Это не так просто, как открыть поток HTTP и сидеть сложа руки, пока ваши данные текут в течение минут, часов или дольше. Разные клиенты ведут себя по-разному, и вам нужно с этим справляться. Например, некоторые клиенты будут буферизовать данные и не передавать их приложению, пока не будет достигнут некоторый порог. Хуже того, некоторые не передают данные в приложение, пока соединение не будет закрыто.
Таким образом, если вы отправляете несколько сообщений клиенту, возможно, что клиентское приложение не получит данные, например, пока не будет получено 50 сообщений. Это не слишком в реальном времени.
Хотя потоковая передача HTTP может быть жизнеспособной альтернативой, когда WebSocket недоступен, это не панацея. Для надежной работы в бесплодных землях Интернета в реальных условиях необходимо хорошее понимание.
Есть ли другие существенные отличия, которых мне не хватает?
Есть еще одна вещь, о которой еще никто не упомянул, поэтому я подниму ее.
Протокол WebSocket был разработан как транспортный уровень для протоколов более высокого уровня. Хотя вы можете отправлять сообщения JSON или что-то еще напрямую через соединение WebSocket, оно также может передавать стандартные или настраиваемые протоколы.
Например, вы можете использовать AMQP или XMPP через WebSocket, как это уже сделали люди. Таким образом, клиент может получать сообщения от брокера AMQP, как если бы он был подключен непосредственно к самому брокеру (а в некоторых случаях это так).
Или, если у вас есть существующий сервер с каким-то настраиваемым протоколом, вы можете передать его через WebSocket, тем самым расширив этот внутренний сервер до Интернета. Часто существующее приложение, заблокированное на предприятии, может расширить его охват с помощью WebSocket без необходимости изменения какой-либо внутренней инфраструктуры.
(Естественно, вы хотите иметь возможность делать все это безопасно, поэтому обратитесь к поставщику или поставщику WebSocket.)
Некоторые люди называют WebSocket TCP для Интернета. Потому что так же, как TCP передает протоколы более высокого уровня, WebSocket тоже, но способом, совместимым с веб-инфраструктурой.
Таким образом, хотя отправка сообщений JSON (или любых других) напрямую через WebSocket всегда возможна, следует также учитывать существующие протоколы. Потому что для многих вещей, которые вы хотите сделать, вероятно, уже есть продуманный протокол.
Прошу прощения, если я повторно задаю или объединяю многие из вопросов, которые уже есть в SO, в один вопрос, но я просто хочу понять всю информацию, которая есть в SO и в Интернете относительно этих концепций.
Это был отличный вопрос, и все ответы были очень информативными!