Nodejs - Как HTTP-ответы всегда попадают на нужное устройство? - PullRequest
Новая
       8

Nodejs - Как HTTP-ответы всегда попадают на нужное устройство?

0 голосов
/ 28 мая 2019

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

Так, например, приведенный ниже код никогда не может быть на 100% функциональным ... 

require('http').createServer((req, res) => {

    let uniqueDeviceId = getUniqueDeviceId(req);

}).listen(80, '<my public ip>', 511);

... потому что нет способа реализовать getUniqueDeviceId гарантированным способом. Он не может просто вернуть req.connection.remoteAddress, так как несколько устройств могут иметь один и тот же адрес.

Учитывая это, мой вопрос: Как res.end(...) всегда отвечает на правильное устройство ??

например. рассмотрим этот простой сервер: 

require('http').createServer((req, res) => {

    res.end(req.url);

}).listen(80, '{{my public ip}}', 511);

Возьмите два разных устройства, подключенных к одному IP-адресу. Каждое устройство использует свой собственный URL:

  • Устройство 1 использует http://{{my public ip}}/device1
  • Устройство 2 использует http://{{my public ip}}/device2

Теперь оба этих устройства бомбардируют свои URL тысячами запросов в секунду.

В ответ устройство 1 всегда получает /device1, а устройство 2 всегда получает /device2, даже с такой конфигурацией, которая должна приводить к условиям гонки!

Даже если I не может определить уникальный идентификатор устройства напрямую, res.end всегда будет соответствовать соответствующему req - он никогда не будет ошибаться и отправлять ответ на какой-то другой req, даже если разные req были получены практически в одно и то же время с одного и того же IP-адреса. Для меня это доказательство того, что на некотором уровне, ниже, чем у Nodejs, могут быть определены уникальные идентификаторы устройств.

Если это правильно, на каком уровне архитектуры HTTP мы получаем гарантию того, что ответ всегда будет возвращаться к первоначальному запрашивающему? И как это реализовано?

Ответы [ 2 ]

1 голос
/ 28 мая 2019

"Для меня это доказательство того, что на каком-то уровне, ниже, чем Nodejs, могут быть определены уникальные идентификаторы устройств"

- Нет, определяется не «уникальный идентификатор устройства», а уникальная комбинация «IP-порт».

Например, в вашем случае устройство 1 и устройство 2 скрыты за маршрутизатором, что делает их IP-адрес (IP-адрес маршрутизатора) вашим веб-сервером. Однако, хотя они имеют одинаковый IP-адрес, их порт отличается.

Для устройства 1 с точки зрения вашего веб-сервера Node.js сокет (комбинация SourceIP / Port - DestinationIP / Port) может быть: 

{{RouterIP}}:{{PortX}} - {{Node.js serverIP}}:{{Node.js serverPort}}

Для устройства 2 с точки зрения веб-сервера Node.js сокет может быть: 

{{RouterIP}}:{{PortY}} - {{Node.js serverIP}}:{{Node.js serverPort}}

Таким образом, хотя устройство 1 и устройство 2 имеют одинаковый IP-адрес, HTTP-ответ будет возвращен на соответствующий порт в маршрутизаторе - ответ для устройства 1 будет возвращен на PortX маршрутизатора, а ответ для устройства 2 - на Porty.

Затем внутри роутера есть отображение, например: 

{{PortX}} - {{Device 1's private IP}}:{{Device 1's Port}}
{{PortY}} - {{Device 2's private IP}}:{{Device 2's Port}}

Таким образом, ответ, возвращенный на PortX маршрутизатора, будет перенаправлен на устройство 1 (и соответствующий ему порт), а ответ, возвращенный на PortY, будет перенаправлен на устройство 2.

Это называется NAT , и приведенное выше описание является очень простым примером.

«На каком уровне HTTP-архитектуры мы получаем гарантию того, что ответ всегда будет возвращаться первоначальному инициатору? И как это реализовано?»

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

0 голосов
/ 28 мая 2019

MAC-адреса «уникально» идентифицируют устройства. Но даже если:

Прежде всего: http находится поверх tcp / ip. IP - это стандарт определения местоположения устройств в сети. Устройства получают IP-адрес от своего маршрутизатора, и устройство может отправлять маршрутизатору свой собственный IP-адрес. (192.168.2.1:80(Router) -> 192.168.2.100:80(PC))

Затем маршрутизатор отправляет данные в WWW через вашего интернет-провайдера.

Ваш общедоступный IP-адрес -Запрос> ISP -Запрос> TargetIP -Ответ> ISP -Ответ> Вы

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

Тогда есть порты: если вы используете порт, он будет локально заблокирован устройством. Если бы не было портов, TCP / IP имел бы те условия гонки, которые вы упомянули, поскольку они блокировали бы друг друга.

Дело в том, что вы не используете разные порты или IP-адреса. Поэтому, что бы вы ни делали, это просто наличие одного Сервера, который обрабатывает оба входящих Запроса, иначе второй Сервер, который пытается заблокировать Порт, не сможет, поскольку он не соответствует TCP / IP. Вы не сможете иметь IP1: 80 / устройство1 и IP1: 80 / устройство2, работающие с двумя различными приложениями, пытающимися заблокировать порт 80.

Так что вы как бы правы (что могут быть расхождения), но также очень вводите в заблуждение из-за мысли, что 2 Server может работать через порт 80.

Они рассмотрят дело, о котором вы говорите, следующее:

Или

  • Используйте Apache / Nginx / Nodejs и создайте основное приложение (маршрутизатор) для перенаправления запросов на сервер через обратный прокси-сервер и другие виды * квест-методов.
  • Использовать разные порты

И для уточнения: HTTP это следующее:

  • Pathing (/ this / is / a / path)
  • Заголовки (их вы на самом деле не видите, но они содержат подсказки кеша, типы данных и обработку файлов о том, как файлы должны обрабатываться, а также что и как) и безопасность)

То, что серверы делают с HTTP, использует данные, которые они получают из формата HTTP. (это просто конкретное расположение данных в TCP) И используйте это, чтобы определить, куда направить / направить результат.

Обработка сокетов, как упомянуто shaochuancs, является частью TCP и UDP, двух протоколов низкого уровня. Есть около 7 уровней в сети. Так что это только часть всей истории. Если вы заинтересованы в получении дополнительной информации, ищите сетевые уровни специально в Google. Это хорошее ключевое слово, чтобы получить больше информации об этом материале.

...