Начиная понимать веб-сокеты и HTTP-запросы (и STOMP)

Недавно я присоединился к новому проекту, где мне поручено внедрять потоковые данные с помощью сетевых сокетов. Идея состоит в том, что информация в настоящее время отображается через HTTP-запросы (в режиме RESTful), которые они хотят открывать через веб-сокеты.

Я провел кучу исследований за последние 48 часов по поводу веб-сокетов и STOMP и хотел получить некоторые пояснения по нескольким пунктам:

Таким образом, для клиента и сервера для подключения через веб-сокет, а не через HTTP-запрос/ответ, сначала необходимо согласиться настроить соединение с веб-сокетом между ними. Это делается через HTTP GET с уникальным заголовком, который говорит, что вместо этого нужно использовать соединение с веб-сокетом?
Теоретически, скажем, что в браузере имеется целый ряд различных данных, которые могут быть переданы через некоторый API. Представьте, что существует целая куча разных HTTP-запросов, которые могут быть сделаны GET'S, POST'S, DELETE. Таким образом, чтобы некоторые части всей этой информации были переданы через веб-сокет, просто нужно изменить текущий запрос GET для каждого ресурса, чтобы проверить, есть ли этот специальный заголовок websocket и что-то сделать? Или есть что-то еще, что нужно сделать, чтобы выставить определенные части данных через веб-сокеты. Я просто могу неправильно понимать отношения HTTP и сокетов, если вы инициализируете сокет из HTTP-запроса.

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

Ответ 1

Таким образом, для клиента и сервера для подключения через веб-сокет, а не через HTTP-запрос/ответ, сначала нужно согласиться настроить соединение с веб-сокетом между ними. Это делается через HTTP GET с уникальным заголовком, который говорит, что вместо этого нужно использовать подключение к веб-соке?

Да, более или менее. Заголовки:

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: <random string, base64 encoded>
Sec-WebSocket-Version: <version>

Обычно version составляет 13 в эти дни, хотя я считаю, что 8 также все еще используется.

Если сервер согласен с websocket, он вернет HTTP-код 101 со следующими заголовками:

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <base64 encoded hash based on Sec-WebSocket-Key>

Теоретически, скажем, что в браузере имеется целый ряд различных данных, открытых через некоторый API. Представьте, что существует целая куча разных HTTP-запросов, которые могут быть сделаны GET'S, POST'S, DELETE. Таким образом, чтобы некоторые части всей этой информации были переданы через веб-сокет, просто нужно изменить текущий запрос GET для каждого ресурса, чтобы проверить, есть ли этот специальный заголовок websocket и что-то сделать? Или есть что-то еще, что нужно сделать, чтобы выставить определенные части данных через веб-сокеты. Я просто могу неправильно понимать отношения HTTP и сокетов, если вы инициализируете сокет из HTTP-запроса.

Похоже, вы это понимаете, но я укажу, что вы можете только запустить WebSocket с помощью GET.

Из того, что вы описали, неясно, что WebSockets на самом деле то, что вы хотите. WebSockets используются для двусторонней связи между сервером и клиентом. Если вы просто хотите, чтобы вы могли передавать данные с сервера на клиент, вам будет намного легче проводить события Server-Sent.

Ответ 2

Мне потребовалось больше 48 часов, чтобы по-настоящему обмануть это. Это большое изменение от AJAX.

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

Если вам нужно отправлять только личные данные, вы можете остановиться на уровне STOMP (или ниже). На данный момент технология не очень зрелая, потому что большинство решений связаны с вышеупомянутыми очередями сообщений. STOMP теоретически должен позволить вам иметь несколько конечных точек с каждой стороны (браузер и сервер) для получения сообщений (сериализованных в JSON или XML между JavaScript и С#). Если вам не нравится эта технология, довольно просто использовать WebSockets для передачи сообщений туда и обратно. В этом случае у вас есть один приемник с каждой стороны, и вы передаете простую структуру, такую как строка, которая называет сообщение, за которым следует запятая, тогда само сообщение сериализуется в зависимости от того, какая технология работает для вас (я предпочитаю JSON на стороне браузера, но XML может работать).

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

ОБНОВЛЕНИЕ: кто-то, у кого больше информации о .NET-реализации WebSockets, ответьте на некоторые детали, которые я не знаю, и у меня нет времени для расследования. Мой ответ не завершен, у меня просто нет времени, чтобы ответить правильно, прежде чем истечет срок.