При выполнении IPC с использованием сокетов TCP / IP с использованием петлевого адреса, пропускают ли обычные сетевые стеки сообщение в кадрах более низкого уровня?

Question

В некоторых средах, таких как Java, естественно использовать сокеты TCP / IP для передачи сообщений между процессами на одном хосте с использованием адреса «localhost» (127.0.0.1 в IPv4 или :: 1 в IPv6). (Поскольку Java имеет тенденцию не раскрывать другие механизмы IPC в своем API).

Очевидно, что это может быть намного медленнее, чем IPC через передачу сообщений по каналам или IPC с использованием разделяемой памяти.

С другой стороны, если сетевой стек TCP / IP обнаружил, что оба конца соединения находятся на интерфейсе обратной связи, он мог бы выполнить небольшую оптимизацию, чтобы эффективность не сильно отличалась от использования каналов .

Но реализуют ли обычные операционные системы (Windows, Linux) такие оптимизации в своих стеках TCP / IP?

Answer 1

Да.Когда пакет / данные на адрес обратной связи (127.xxx) получен, уровень IP TCP / IP использует маршрут обратной связи для маршрутизации пакета к себе.

Looback Route

Сетевой пункт назначения ||Сетевая маска ||Шлюз ||Интерфейс ||Метрика

127.0.0.0 |||||||||||||||||||||255.0.0.0 ||127.0.0.1 ||127.0.0.1 ||1

После направления его на себя, на уровне TCP / UDP с помощью блоков управления протоколом (для каждой структуры данных соединения) будет идентифицирован соответствующий сокет и процесс его владельца для доставкипакет / данные.

Итог, все задачи на уровнях звена данных и физических уровнях (модели OSI) будут исключены.

Answer 2

Зависит от ОС и используемой конфигурации.Ответ «да», если вы запрашиваете поведение по умолчанию.

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

Answer 3

В частности, в linux, когда пакеты передаются по интерфейсу обратной связи, ядро ​​создает «программное» прерывание для каждого пакета.С этого момента прием пакета идентичен потоку приема пакета для физического устройства.Таким образом, вы правы, предполагая, что обмен данными через интерфейс обратной связи будет намного медленнее, чем альтернативные механизмы IPC, такие как сокеты Unix.

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