Преимущества использования именованных каналов UNIX вместо сокетов TCP в Linux?

Question

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

В Linux есть ли какое-то преимущество в использовании именованных каналов вместо сокетов?

Спасибо за вашу помощь и время.

РЕДАКТИРОВАТЬ: Я нашел несколько сравнений здесь , но это UNIX -сокеты (также известные как UNIX доменные сокеты), которые основаны на этом, Я понимаю, что они другое существо.

Поэтому я уточняю: я спрашиваю о сокетах TCP по сравнению с Unix именованными каналами (потому что в MS Windows есть еще одна вещь, называемая «именованные каналы», но они, похоже, функционально более похожи на UNIX доменные сокеты).

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

Answer 1

Вероятно, это несовершенный ответ, но вот что я знаю.

Отправка данных через сокет TCP означает, что передача должна осуществляться через вашу сетевую систему, будет получен IP-адрес источника и назначения, разделенный на максимум 64К пакетов. Упаковано как в TCP, так и в IP конверт, возможно, go через правила брандмауэра. Получатель также должен подтверждать пакеты, удостовериться, что они прибывают в порядке, и что необходимо согласование на случай, если пакеты будут потеряны и их нужно будет повторно отправить.

Отправка данных в именованный канал больше или less работает как просто запись в файловый дескриптор, такой как STDOUT, и чтение из STDIN.

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

Answer 2

Везде, где я читал об именованных каналах и сокетах, я вижу, что сокет может делать то же, что и именованный канал, и многое другое.

Именованные каналы используются как файлы.

Это большое преимущество, если вы хотите сделать что-то, что работает с файлом, но не работает с сокетом.

Примеры:

ls > /dev/lp1
ls > ./myNamedPipe
# Not possible: ls > 127.0.0.1:9323

dd if=myFile bs=1 count=100 of=/dev/lp1
dd if=myFile bs=1 count=100 of=./myNamedPipe
# Not possible: dd if=myFile bs=1 count=100 of=127.0.0.1:9323

MS * В 1044 * есть еще одна вещь, называемая «именованные каналы», но они кажутся функционально более похожими на UNIX доменные сокеты

На самом деле MS Windows имеет дополнительные функции API для доступа к именованным каналам. . Однако стандартный файловый API Windows (который используется функциями C, такими как open(), read() и write()) также работает с именованными каналами.

По этой причине вы также можете использовать именованный канал как файл в Windows. Я уже сделал это для эмуляции последовательного порта с подключенным определенным устройством.

... и другие потенциальные преимущества.

Одно очевидное преимущество (как именованных каналов, так и Unix сокетов) - это само имя:

Если какая-то программа foobarSimpleProgram хочет связаться с другой программой с именем foobarOtherProgram, она может просто создать сокет Unix или именованный канал с именем /tmp/foobarProgramSuite .

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

В случае TCP-сокета, прослушивающего localhost, программа должна использовать фиксированный TCP-порт; в этом случае существует риск того, что другая программа будет использовать тот же порт TCP, поэтому может использоваться только одна из двух программ.

Или программа привязывается к порту TCP 0, поэтому ОС назначает некоторый свободный порт TCP. Затем программа записывает номер порта в файл /tmp/foobarProgramSuite, который считывается другой программой, которая затем выполняет connect().

Это сложнее, чем прямое подключение к каналу или сокету с помощью имя.