NodeJS, экспресс с взаимодействием Socket.io - PullRequest
0 голосов
/ 25 апреля 2018

В настоящее время работает с бэкэндом Node.JS, в котором используются express.js и Socket.io. Основа приложения выглядит примерно так:

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);

app.get('/', function(req, res){
  res.sendFile(__dirname + '/index.html');
});

io.on('connection', function(socket){
  console.log('a user connected');
});

http.listen(3000, function(){
  console.log('listening on *:3000');
});

Так что, если я правильно понимаю, express.js обрабатывает все запросы HTTP/HTTPS, а Socket.io обрабатывает все взаимодействия, касающиеся веб-сокетов. Итак, это 2 сущности, которые полностью разделены. После запуска приложения часть express прослушивает запросы http, а часть socket.io прослушивает события веб-сокета или подключается (подключение выполняется с помощью HTTP, рукопожатие веб-сокета с использованием заголовков HTTP). Поскольку экземпляр express и экземпляр socket.io используют один и тот же сервер HTTP, они могут использовать одно и то же TCP-соединение.

Вопросы:

  1. Правильно ли мое вышеописанное понимание?
  2. Могут ли эти две сущности взаимодействовать друг с другом, если да, то каким образом?

1 Ответ

0 голосов
/ 26 апреля 2018

Чтобы понять, как это работает под прикрытием, вы действительно должны понять, как работает соединение socket.io, а затем вы можете увидеть, как оно связано с вашим http-сервером.

  1. Соединение по умолчанию с socket.io начинается с пары http-запросов. Вот как клиент socket.io договаривается с сервером, чтобы решить, что именно они могут поддерживать. Эти http-запросы поступают на ваш веб-сервер node.js (тот же, который вы используете для Express). Обработчик запросов, вставленный в socket.io, перехватывает эти запросы и обрабатывает их, поэтому они не отправляются на ваши экспресс-маршруты.
  2. После пары запросов http, подобных приведенному выше, если обе стороны согласны с тем, что соединение webSocket может быть установлено в качестве базового транспорта для текущего соединения socket.io, тогда клиент socket.io отправляет на сервер специальный запрос http с несколькими пользовательскими заголовками.
  3. http-сервер (опять тот же, который вы используете для Express) получает этот специальный http-запрос, а код сервера socket.io снова перехватывает этот запрос и обрабатывает его. В этом случае он отвечает на этот специальный запрос http «обновлением» протокола webSocket, а сокет, который начался как запрос http, преобразуется в протокол webSocket и становится долгоживущим сокетом, который говорит только по протоколу webSocket.
  4. На этом этапе веб-сервер http больше не участвует в дальнейшей связи. Сокет, который начал работать как http-запрос, был передан серверному коду socket.io, и теперь этот сокет использует протокол webSocket. На этом этапе клиент или сервер могут отправлять сообщения через этот сокет, и они будут получены с помощью соответствующего кода на другом конце.
  5. Теперь socket.io фактически использует слой поверх webSocket. Хотя базовые пакеты данных отформатированы для протокола webSocket, socket.io добавляет свой собственный прикладной уровень поверх webSocket, что означает, что для этого нужно иметь код socket.io на обоих концах (клиент socket.io не может разговаривать с обычным сервером webSocket или наоборот).

Так что, если я правильно понимаю, express.js обрабатывает все запросы HTTP / HTTPS, а Socket.io обрабатывает все взаимодействия, касающиеся веб-сокетов.

В некотором роде. Http-сервер (который лежит в основе Express) обрабатывает все входящие http-запросы. Это включает в себя обычные http-запросы, которые будут направляться через Express, но также и http-запросы, связанные с открытием и установлением соединения с socket.io. Эти особые запросы обрабатываются обработчиком запросов http-сервера, вставляемым socket.io, и не передаются в очередь для обработки Express.

Итак, это 2 сущности, которые полностью разделены.

Есть один http-сервер, а затем несколько обработчиков запросов, которые решают, должен ли Express обрабатывать запрос или socket.io должен обрабатывать запрос. После того, как запрос был передан другому, они в значительной степени разделены.

Но есть некоторые точки, где они могут пересекаться. Например, если вы используете диспетчер сеансов с Express, который устанавливает cookie сеанса или любой другой тип кода, который устанавливает cookie, то эти cookie также доступны для соединений socket.io. Таким образом, при наличии правильного кода поддержки соединение socket.io может получить доступ к объекту сеанса (или другим файлам cookie), созданным промежуточным программным обеспечением Express или обработчиками запросов. Помните, что соединение socket.io начинается с запроса http, поэтому любые файлы cookie, которые браузер обычно отправляет с запросом http, также будут присутствовать для запроса socket.io.

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

Как я уже говорил выше, http-сервер прослушивает входящие http-запросы, и у socket.io и Express есть обработчики запросов, которые смотрят на эти входящие запросы и решают, должны ли они участвовать в обработке этого запроса или нет.Некоторые входящие запросы направляются на код сервера socket.io, а некоторые - на обработчики экспресс-маршрутов.

Поскольку экземпляр express и экземпляр socket.io используют один и тот же HTTP-сервер, они могут использоватьтакое же TCP-соединение.

На самом деле они не разделяют TCP-соединение.Существует один общий http-сервер, который прослушивает входящие http-запросы.Затем эти запросы направляются либо в код socket.io, либо в экспресс-код для дальнейшей обработки на основе данных в запросе.Если это запрос socket.io для инициирования соединения socket.io, то этот сокет TCP «обновляется» до протокола webSocket, и только код сервера socket.io обрабатывает этот сокет TCP с этого момента.Если это не запрос socket.io, тогда запрос http передается в код Express, и он решает, что с ним делать, основываясь на промежуточном программном обеспечении и определенных маршрутах.

Является ли мое вышеописанное текущее пониманиеправильно?

частично правильно, частично не правильно.Много деталей выше.

Могут ли эти два объекта взаимодействовать друг с другом, если да, то каким образом?

Они совместно используют http-сервер.Они делятся доступом к файлам cookie.

При правильном коде на стороне сервера можно получить запрос http (обычно вызов Ajax с уже загруженной веб-страницы) в Express и обработчик этого запроса отправит данные этому конкретному клиенту через него.соответствующее соединение socket.io.Используя некоторый идентификатор клиента cookie, можно связать существующее соединение socket.io с входящим http-запросом.


Я должен добавить, что вышеописанное - это то, как все работает, когда вы делаетесоединение socket.io с тем же хостом и портом, с которого была загружена веб-страница.Это не обязательно.У вас может быть один http-сервер, с которого загружаются все ваши веб-страницы и веб-ресурсы, и другой http-сервер (с другой комбинацией хост / порт), который обрабатывает входящие запросы socket.io.В этом случае, экспресс-сторона вещей на самом деле не имеет ничего общего со стороной socket.io.Это были бы буквально разные серверы, которые, вероятно, не разделяли бы файлы cookie и т. Д.

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