Вопрос или проблема
У меня есть веб-сервер с клиентами SignalR. Топология:
Клиент — Caddy — IIS
Клиент – Просто JS клиент SignalR.
Caddy – В качестве обратного прокси.
Общий exe файл или служба WSL 1. (Я попробовал оба варианта, и для моего вопроса они одинаковы). Порт 8811 на 8082.
IIS – Api приложение на основе .Net 8.
Я заметил, что каждый клиент создает три TCP подключения, 1 к Caddy + 2 “дублирующихся”, хотя я ожидаю два, Клиент — Caddy + Caddy — IIS.
Вывод netstat (8811 – Caddy, сюда подключаются клиенты. 8082 – привязка сайта IIS):
TCP 192.168.21.42:8811 CLIENT:57803 ESTABLISHED
TCP 127.0.0.1:8082 SERVER:50121 ESTABLISHED
TCP 127.0.0.1:50121 SERVER:8082 ESTABLISHED
Что означают строки 2 и 3?
Почему они существуют одновременно?
Netstat не показывает подключения — он показывает сокеты.
Сокет — это один конец подключения (дескриптор на Windows или файловый дескриптор на Linux), удерживаемый программой. Таким образом, если у вас два программных обеспечения общаются через ‘localhost’ на одной и той же машине, в netstat будет два записа для каждого TCP соединения — “исходящий” сокет, удерживаемый одной программой, и “входящий” сокет, удерживаемый другой. Добавление -b (или -p для Linux) покажет вам соответствующий процесс.
Колонки ‘Local’ и ‘Remote’ отображаются с точки зрения каждой программы, поэтому сокет, удерживаемый IIS (принятая входящая связь), будет иметь 127.0.0.1:8082 как ‘Local’ адрес, в то время как сокет, созданный Caddy (исходящее соединение), будет иметь этот же адрес как удаленный.
Ответ или решение
Расшифровка ситуации с зеркальными или инвертированными TCP-соединениями между локальными процессами может быть немного сложной без надлежащего понимания того, как работают сетевые подключения и как они отображаются в инструментах диагностики, таких как netstat. Давайте разберёмся, что именно вы видите в вашем случае, и почему вы наблюдаете больше TCP-соединений, чем ожидали.
Теория
Для начала, TCP-соединение — это установка связи между двумя конечными точками в сети. Каждое соединение характеризуется четырьмя элементами: IP-адресом и портом назначения, а также IP-адресом и портом источника. Каждое из этих соединений регистрируется в операционной системе и может быть просмотрено с помощью инструментов, таких как netstat.
Понимание того, как интерпретировать вывод netstat, важно для распознавания того, что такое "зеркальные" соединения на вашей машине:
-
Сокеты и соединения: Netstat показывает сокеты, а не сами соединения. Сокет — это одна из сторон соединения, и если два процесса общаются локально через ‘localhost’, то у вас будет два отдельных отображения в netstat для каждого TCP-соединения: один для исходящего сокета одного процесса и другой для входящего сокета другого.
-
Локальные и удаленные адреса: Колонки ‘Local Address’ и ‘Foreign Address’ (или ‘Remote Address’) в netstat соотнесены с точкой зрения каждого процесса. Это значит, что изолированный процесс видит себя и все связи с ним под разными углами, в зависимости от контекста соединения.
Пример
В вашем случае, у вас есть три строки в выводе netstat:
TCP 192.168.21.42:8811 CLIENT:57803 ESTABLISHEDTCP 127.0.0.1:8082 SERVER:50121 ESTABLISHEDTCP 127.0.0.1:50121 SERVER:8082 ESTABLISHED
Эти строки указывают на установленные TCP-соединения между различными компонентами вашей системы. Первая строка показывает соединение между клиентом и сервером Caddy (слушает на порте 8811), в то время как вторая и третья строки зависят от локальных соединений между сервером Caddy и IIS.
Применение
Теперь, чтобы лучше понять вашу сетевую конфигурацию, важно знать, что каждая из двух последних строк представляет собой вид с разных точек на одно и то же соединение:
-
Вторая строка (Caddy слушает): Когда ваш сервер Caddy устанавливает исходящее соединение на локальный домен ‘localhost’ как часть проксирования для IIS, он создает локальное соединение, где 127.0.0.1:8082 — это адрес, к которому он пытается присоединиться (IIS), а 127.0.0.1:50121 — его собственный временный исходящий порт.
-
Третья строка (IIS слушает): Одновременно IIS видит каждое входящее соединение как следующее — оно слушает на порте 8082 и принимает соединение, исходящее от Caddy, которое локально принимает форму 127.0.0.1:50121.
Повторение одного физического соединения в двух отображенных строках является стандартной особенностью работы TCP-соединений на ‘localhost’. Это создается проксированием с использованием локальных адресов для передачи данных между разными серверами или серверами и службами на одном и том же физическом узле.
Заключение
Таким образом, то что вы наблюдаете, является стандартным поведением при проксировании трафика через такой промежуточный сервер, как Caddy, который перенаправляет трафик между клиентом и фактическим сервером IIS. Разница в отображении каждой из сторон из-за локального маршрута через ‘localhost’ подводит вас к дуальному виду на каждое непосредственное соединение, создавая иллюзию "зеркальных" TCP-соединений.
Это поведение может показаться сложным при первом просмотре, но его важно осознать, чтобы эффективно управлять, разрабатывать и оптимизировать ваши сетевые приложения, особенно когда вы работаете в средах с несколькими уровнями проксирования, как в вашем сценарии.