В какой-то момент в некоторых учебных материалах (из Linux Foundation) по Linux, с которыми я сталкивался, упоминается следующее:
ipКоманда является более универсальной и более эффективной, чемifconfigпотому, что она использует сокеты netlink, а не системные вызовы ioctl .
Может кто-нибудь уточнить это, потому что я не могу понять, что происходит под капотом?
PS Мне известна эта тема об этих инструментах, но она не касается этой конкретной разницы в том, как они работают
Ответы:
Команда ifconfigв операционных системах, таких как FreeBSD и OpenBSD, была обновлена в соответствии с остальной частью операционной системы. В настоящее время он может настраивать все виды параметров сетевого интерфейса в этих операционных системах и обрабатывать различные сетевые протоколы. BSD предоставляют ioctl()поддержку для этих вещей.
Этого не произошло в мире Linux. Сегодня есть три ifconfigкоманды:
ifconfigиз GNU inetutilsjdebp% inetutils-ifconfig -l
enp14s0 enp15s0 вот
jdebp% inetutils-ifconfig lo
lo Link encap: Local Loopback
адрес в сети: 127.0.0.1 Bcast: 0.0.0.0 Маска: 255.0.0.0
UP LOOPBACK RUNNING MTU: 65536 Метрика: 1
Пакеты RX: 9087 ошибок: 0 отброшено: 0 переполнений: 0 кадр: 0
Пакеты TX: 9087 ошибок: 0 отброшено: 0 переполнений: 0 несущая: 0
столкновения: 0 txqueuelen: 1000
RX байтов: 51214341 TX байтов: 51214341
jdebp%
ifconfigот NET-3 net-tools jdebp% ifconfig -l
ifconfig: опция --help 'предоставляет информацию об использовании.-l' not recognised.
ifconfig:
jdebp% ifconfig lo
lo: flags = 73 <UP, LOOPBACK, RUNNING> mtu 65536
Инет 127.0.0.1 маска сети 255.0.0.0
inet6 :: 1 prefixlen 128 scopeid 0x10 <хост>
inet6 :: 2 prefixlen 128 scopeid 0x80 <compat, global>
inet6 fe80 :: prefixlen 10 scopeid 0x20 <ссылка>
loop txqueuelen 1000 (локальная петля)
RX-пакеты 9087 байт 51214341 (48,8 МиБ)
RX ошибок 0 отброшено 0 переполнений 0 кадра 0
Пакеты TX 9087 байтов 51214341 (48,8 МиБ)
Ошибки TX 0 отброшены 0 переполнений 0 несущих 0 коллизий 0
jdebp%
ifconfigиз (версия 1.40 из) набора инструментов nosh jdebp% ifconfig -l
enp14s0 enp15s0 вот
jdebp% ifconfig lo
вот
соединить петлю работает
адрес ссылки 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
inet4 адрес 127.0.0.1 префиксный 8 bdaddr 127.0.0.1
inet4 адрес 127.53.0.1 префиксный 8 bdaddr 127.255.255.255
адрес inet6 :: 2 область 0 префикс 128
inet6 адрес fe80 :: префикс 1 области видимости 10
адрес inet6 :: 1 область 0 префикс 128
jdebp% sudo ifconfig lo inet4 127.1.0.2 псевдоним
jdebp% sudo ifconfig lo inet6 :: псевдоним 3/128
jdebp% ifconfig lo
вот
соединить петлю работает
адрес ссылки 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
inet4 адрес 127.0.0.1 префиксный 8 bdaddr 127.0.0.1
inet4 адрес 127.1.0.2 с префиксом 32 bdaddr 127.1.0.2
inet4 адрес 127.53.0.1 префиксный 8 bdaddr 127.255.255.255
адрес inet6 :: 3 области видимости 0 префикс 128
адрес inet6 :: 2 область 0 префикс 128
inet6 адрес fe80 :: префикс 1 области видимости 10
адрес inet6 :: 1 область 0 префикс 128
jdebp% Как видите, в GNU inetutils и NET-3 net-tools ifconfigесть некоторые заметные недостатки, как в отношении IPv6, так и в отношении интерфейсов, которые имеют несколько адресов, и в отношении функциональных возможностей, подобных -l.
Проблема IPv6 отчасти заключается в нехватке кода в самих инструментах. Но в основном это связано с тем, что Linux (как и другие операционные системы) не обеспечивает функциональность IPv6 через ioctl()интерфейс. Он позволяет программам видеть и управлять IPv4-адресами только через сеть ioctl().
Вместо этого Linux предоставляет эту функциональность через другой интерфейс send()и recv()по специальному и несколько странному семейству сокетов адресов AF_NETLINK.
ГНУ и NET-3 ifconfigs может быть скорректирована , чтобы использовать этот новый API. Аргумент против делать это был то , что он не подходит для других операционных систем, но эти программы были на практике уже нет переносных все равно , так что была не так много аргументов.
Но они не были откорректированы и остаются такими же, как было показано по сей день. (Некоторые люди работали над ними в разные годы, но, к сожалению, усовершенствования так и не попали в программы. Например: Бернд Экенфельс никогда не принимал патч, который добавлял некоторые возможности netlink API к сетевым инструментам NET-3. ifconfigЧерез 4 года после написания патча.)
Вместо этого некоторые люди полностью заново изобрели набор инструментов как ipкоманду, которая использовала новый Linux API, имела другой синтаксис и объединила несколько других функций за модным интерфейсом в стиле.command subcommand
Мне нужно было ifconfigиметь синтаксис командной строки и стиль вывода FreeBSD ifconfig(чего нет ни у GNU, ни у NET-3 ifconfig, а у которого ipнаверняка нет). Итак, я написал один. В качестве доказательства того, что можно написать ifconfigAPI, который использует netlink API в Linux, это так.
Таким образом, полученная мудрость о том ifconfig, что вы цитируете, больше не соответствует действительности. Это в настоящее время не соответствует действительности сказать , что « ifconfigне использует NetLink.». Одеяло, которое покрывало два, не покрывает три.
Это всегда было бы неверно говорить о том , что «NetLink является более эффективным». Для задач, с которыми можно справиться ifconfig, не так много, когда дело доходит до эффективности между netlink API и ioctl()API. Один делает почти одинаковое количество вызовов API для любой задачи.
Действительно, каждый вызов API - это два системных вызова в случае netlink, а не один в ioctl()системе. И, возможно, недостатком API netlink является то, что в интенсивно используемой системе он явно включает в себя возможность того, что инструмент никогда не получит подтверждающее сообщение, информирующее его о результате вызова API.
Он, кроме того, неверно говорить о том , что ipявляется «более универсальным» , чем GNU и NET-3 ifconfigs , потому что он использует NetLink . Он более универсален, потому что он выполняет больше задач, выполняя действия в одной большой программе, чем с другими программами ifconfig. Он не более универсален, просто благодаря API, который он использует внутри для выполнения этих дополнительных задач. В этом нет ничего присущего API. Можно было бы написать инструмент все-в-одном , который использовал FreeBSD ioctl()API, например, и в равной степени хорошо , что оно является «более универсальным» , чем отдельные ifconfig, route, arpи ndpкоманд.
Можно было бы написать route, arpи ndpкоманды для Linux , которые использовали NETLINK API, тоже.
ifconfig, Руководство Nosh . Softwares.Стандарт, который ifconfigмы имеем во многих дистрибутивах, устарел по нескольким причинам. Говорит устаревшим и ограниченным образом с ядром, и фактически не понимает все конфигурации сети. Вы не сможете управлять некоторыми сетевыми конфигурациями, такими ifconfigверсиями, с которыми вы можете работать ip. Кроме того, ifconfigподдержка сетевых пространств имен ограничена.
В качестве анекдотического рассказа я обнаружил псевдоним IP интерфейса, который виден только ipв SuSE, а не в нем ifconfig.
Что касается различий под капотом: Из ifconfig против IP: В чем разница и сравнение конфигурации сети
Хотя
ipна первый взгляд может показаться немного сложным, но по функциональности он намного шире, чем ifconfig. Он функционально организован на двух уровнях сетевого стека, то есть на уровне 2 (канальный уровень), на уровне 3 (IP-уровень) и выполняет работу всех вышеупомянутых команд из пакета net-tools.В то время как в
ifconfigосновном отображает или изменяет интерфейсы системы, эта команда способна выполнять следующие задачи:
Отображение или изменение свойств интерфейса.
Добавление, удаление записей ARP Cache вместе с созданием новой записи Static ARP для хоста.
Отображение MAC-адресов, связанных со всеми интерфейсами.
Отображение и изменение таблиц маршрутизации ядра.
Одним из основных моментов, который отличает его от его древнего аналога ifconfig, является то, что последний использует ioctl для конфигурации сети, что является менее ценным способом взаимодействия с ядром, в то время как первый использует механизм сокетов netlink для того же самого, который является гораздо более гибким преемником. ioctl для взаимодействия между ядром и пользовательским пространством с использованием rtnetlink (что добавляет возможность манипулирования сетевой средой).
Об использовании / преимуществах netlink: от ЖЖ - Kernel Korner - почему и как использовать сокет Netlink
Сокет Netlink - это специальный IPC, используемый для передачи информации между процессами ядра и пространства пользователя. Он обеспечивает полнодуплексный канал связи между ними посредством стандартных API-интерфейсов сокетов для процессов пользовательского пространства и специального API-интерфейса ядра для модулей ядра. Сокет Netlink использует семейство адресов AF_NETLINK.
.....
Почему вышеупомянутые функции используют netlink вместо системных вызовов, файловых систем ioctls или proc для связи между мирами пользователей и ядра? Нетривиальная задача - добавлять системные вызовы, файлы ioctls или proc для новых функций; мы рискуем загрязнить ядро и нанести ущерб стабильности системы. Однако сокет Netlink прост: необходимо добавить в netlink.h только константу, тип протокола. Затем модуль ядра и приложение могут немедленно общаться с помощью API в стиле сокетов.
....
Сокет Netlink - это гибкий интерфейс для связи между приложениями пользовательского пространства и модулями ядра. Он предоставляет простой в использовании API-интерфейс для сокетов как для приложений, так и для ядра. Он обеспечивает расширенные функции связи, такие как полнодуплексный, буферизованный ввод / вывод, многоадресная и асинхронная связь, которые отсутствуют в других IPC ядра / пространства пользователя.
ipболее универсальным, потому что все виды интересных функций просто невозможно сделать с помощью ioctl в Linux (потому что ioctl не существует и, вероятно, никогда не будет).