W pewnym momencie, w jakimś materiale dydaktycznym (z Linux Foundation) na temat Linuksa, z którym się zetknąłem, wymieniono:
ippolecenie jest bardziej wszechstronne i wydajniejsze niżifconfigdlatego, że używa gniazd netlink zamiast wywołań systemowych ioctl .
Czy ktoś może coś na ten temat rozwinąć, ponieważ nie rozumiem, co się dzieje pod maską?
PS Znam ten temat na temat tych narzędzi, ale nie dotyczy on tej konkretnej różnicy w sposobie ich działania
Odpowiedzi:
ifconfigPoleceń w systemach operacyjnych, takich jak FreeBSD i OpenBSD została zaktualizowana zgodnie z resztą systemu operacyjnego. Obecnie może konfigurować wszelkiego rodzaju ustawienia interfejsu sieciowego w tych systemach operacyjnych i obsługiwać szereg protokołów sieciowych. BSD zapewniają ioctl()wsparcie dla tych rzeczy.
Tak się nie stało w świecie Linuksa. Istnieją dziś trzy ifconfigpolecenia:
ifconfigz inetutils GNUjdebp% inetutils-ifconfig -l
enp14s0 enp15s0 lo
jdebp% inetutils-ifconfig lo
lo Link encap: Lokalna pętla zwrotna
adres inet: 127.0.0.1 Bcast: 0.0.0.0 Maska: 255.0.0.0
UP UP LOOPBACK RUNNING MTU: 65536 Metryczne: 1
Pakiety RX: 9087 błędów: 0 odrzuconych: 0 przekroczeń: 0 ramek: 0
Pakiety TX: 9087 błędów: 0 odrzuconych: 0 przekroczeń: 0 nośnych: 0
kolizje: 0 txqueuelen: 1000
Bajty RX: 51214341 Bajty TX: 51214341
jdebp%
ifconfigz narzędzi sieciowych NET-3 jdebp% ifconfig -l
ifconfig: opcja --help 'podaje informacje o użytkowaniu.-l' not recognised.
ifconfig:
jdebp% ifconfig lo
lo: flags = 73 <UP, LOOPBACK, RUNNING> mtu 65536
inet 127.0.0.1 maska sieci 255.0.0.0
inet6 :: 1 prefixlen 128 scopeid 0x10 <host>
inet6 :: 2 prefixlen 128 scopeid 0x80 <kompatybilny, globalny>
inet6 fe80 :: prefixlen 10 scopeid 0x20 <link>
loop txqueuelen 1000 (lokalna pętla zwrotna)
Pakiety RX 9087 bajtów 51214341 (48,8 MiB)
Błędy RX 0 usunięte 0 przekroczeń 0 ramka 0
Pakiety TX 9087 bajtów 51214341 (48,8 MiB)
Błędy TX 0 usunięte 0 przekroczenia 0 przewoźnik 0 kolizje 0
jdebp%
ifconfigz (wersja 1.40) zestawu narzędzi nosh jdebp% ifconfig -l
enp14s0 enp15s0 lo
jdebp% ifconfig lo
lo
uruchomione sprzężenie zwrotne
adres linku 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
adres inet4 127.0.0.1 prefiks 8 bdaddr 127.0.0.1
adres inet4 127.53.0.1 prefiks 8 bdaddr 127.255.255.255
adres inet6 :: 2 zakres 0 prefiks 128
inet6 adres fe80 :: przedrostek 1 zakresu 10
adres inet6 :: 1 zakres 0 prefiks 128
jdebp% sudo ifconfig lo inet4 127.1.0.2 alias
jdebp% sudo ifconfig lo inet6 :: 3/128 alias
jdebp% ifconfig lo
lo
uruchomione sprzężenie zwrotne
adres linku 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
adres inet4 127.0.0.1 prefiks 8 bdaddr 127.0.0.1
adres inet4 127.1.0.2 prefiks 32 bdaddr 127.1.0.2
adres inet4 127.53.0.1 prefiks 8 bdaddr 127.255.255.255
adres inet6 :: 3 zakres 0 prefiks 128
adres inet6 :: 2 zakres 0 prefiks 128
inet6 adres fe80 :: przedrostek 1 zakresu 10
adres inet6 :: 1 zakres 0 prefiks 128
jdebp% Jak widać, inetutils GNU i narzędzia sieciowe NET-3 ifconfigmają pewne wyraźne braki w odniesieniu do IPv6, w odniesieniu do interfejsów, które mają wiele adresów i pod względem funkcjonalności -l.
Problemem IPv6 jest po części brakujący kod w samych narzędziach. Ale głównie jest to spowodowane faktem, że Linux nie zapewnia (podobnie jak inne systemy operacyjne) funkcji IPv6 przez ioctl()interfejs. Pozwala jedynie programom widzieć adresy IPv4 i manipulować nimi za pośrednictwem sieci ioctl().
Zamiast tego Linux zapewnia tę funkcjonalność poprzez inny interfejs send()oraz recv()na specjalnej, nieco dziwnej, rodzinie adresów gniazd AF_NETLINK.
GNU i NET-3 ifconfigs mogłyby zostały dostosowane do korzystania z tego nowego API. Argumentem przeciwko temu tak było to, że nie było przenieść do innych systemów operacyjnych, ale programy te były w praktyce już nie przenośny w każdym razie tak, że nie było dużo kłótni.
Ale nie zostały dostosowane i pozostają do dziś. (Niektóre osoby pracowały nad nimi w różnych momentach na przestrzeni lat, ale, niestety, ulepszenia nigdy nie pojawiły się w programach. Na przykład: Bernd Eckenfels nigdy nie zaakceptował łatki, która dodawała pewne funkcje API netlink do narzędzi sieciowych NET-3) ifconfig, 4 lata po napisaniu łatki).
Zamiast tego niektórzy całkowicie wymyślili zestaw narzędzi jako ippolecenie, które korzystało z nowego Linux API, miało inną składnię i połączyło kilka innych funkcji za modnym interfejsem w stylu.command subcommand
Potrzebowałem takiego, ifconfigktóry ma składnię wiersza poleceń i styl wyjściowy FreeBSD ifconfig(którego nie ma ani GNU, ani NET-3 ifconfig, a który z ippewnością nie ma). Więc napisałem jeden. Jest to dowód na to, że można napisać i ifconfigkorzystający z interfejsu API netlink w systemie Linux.
Tak więc otrzymana wiedza na temat ifconfig, na przykład tego, co cytujesz, nie jest już tak naprawdę prawdą. Nie jest teraz prawdą stwierdzenie, że „ ifconfignie używa netlink”. Koc obejmujący dwa nie obejmuje trzech.
To zawsze było nieprawdziwe stwierdzenie, że „netlink jest bardziej efektywny”. W przypadku zadań, które się wykonuje ifconfig, tak naprawdę nie ma wiele, jeśli chodzi o wydajność między interfejsem API netlink a ioctl()interfejsem API. Wykonuje się prawie taką samą liczbę wywołań API dla każdego zadania.
Rzeczywiście, każde wywołanie API to dwa wywołania systemowe w przypadku netlink, w przeciwieństwie do jednego w ioctl()systemie. I prawdopodobnie interfejs API netlink ma tę wadę, że w często używanym systemie wyraźnie zawiera on możliwość, że narzędzie nigdy nie otrzyma komunikatu potwierdzającego informującego go o wyniku wywołania interfejsu API.
Jest ponadto nieprawdziwe powiedzieć, że ipjest bardziej „uniwersalny” niż GNU i NET-3 ifconfigs , ponieważ używa netlink . Jest bardziej wszechstronny, ponieważ wykonuje więcej zadań, wykonując czynności w jednym dużym programie, które można wykonać z osobnymi programami innymi niż ifconfig . Nie jest bardziej wszechstronny po prostu dzięki interfejsowi API, którego używa wewnętrznie do wykonywania tych dodatkowych zadań. Nie ma w tym nic związanego z interfejsem API. Można napisać narzędzie all-in-one, że używany FreeBSD ioctl()API, na przykład, i równie dobrze stan, że jest „bardziej uniwersalne” niż indywidualne ifconfig, route, arpi ndppoleceń.
Można napisać route, arpi ndppolecenia dla Linuksa, które wykorzystywane Netlink API, too.
ifconfig. Przewodnik nosh . Oprogramowania.Standard, ifconfigktóry mamy w wielu dystrybucjach, jest przestarzały z kilku powodów. Rozmawia z jądrem w nieaktualny i ograniczony sposób, a tak naprawdę nie rozumie już wszystkich konfiguracji sieci. Nie będziesz w stanie manipulować niektórymi konfiguracjami sieci, takimi ifconfigwersjami, które możesz zrobić ip. Ponadto ifconfigobsługa sieciowych nazw jest ograniczona.
Jako anegdotyczną opowieść znalazłem alias IP interfejsu, który jest widoczny tylko ipw SuSE, a nie w nim ifconfig.
Jeśli chodzi o różnice pod maską: od ifconfig vs ip: Jaka jest różnica i porównanie konfiguracji sieci
Choć
ipmoże wydawać się nieco skomplikowane na pierwszej stronie, ale ma znacznie szerszą funkcjonalność niż ifconfig. Jest funkcjonalnie zorganizowany na dwóch warstwach stosu sieciowego, tj. Warstwie 2 (Warstwa łącza), Warstwie 3 (Warstwie IP) i wykonuje wszystkie wyżej wymienione polecenia z pakietu net-tools.Chociaż
ifconfignajczęściej wyświetla lub modyfikuje interfejsy systemu, to polecenie może wykonywać następujące zadania:
Wyświetlanie lub modyfikowanie właściwości interfejsu.
Dodawanie, usuwanie wpisów pamięci podręcznej ARP podczas tworzenia nowego statycznego wpisu ARP dla hosta.
Wyświetlanie adresów MAC powiązanych ze wszystkimi interfejsami.
Wyświetlanie i modyfikowanie tabel routingu jądra.
Jedną z głównych zalet, która odróżnia go od starożytnego odpowiednika ifconfig, jest to, że ten ostatni używa ioctl do konfiguracji sieci, co jest mniej docenianym sposobem interakcji z jądrem, podczas gdy ten pierwszy wykorzystuje mechanizm gniazda netlink do tego samego, co jest znacznie bardziej elastycznym następcą ioctl do komunikacji między jądrem a przestrzenią użytkownika za pomocą rtnetlink (który dodaje możliwość manipulowania środowiskiem sieciowym).
O użyciu / zaletach netlink: Od LJ - Kernel Korner - Dlaczego i jak korzystać z Netlink Socket
Gniazdo Netlink jest specjalnym IPC służącym do przesyłania informacji między procesami jądra i przestrzeni użytkownika. Zapewnia pełne dupleksowe łącze komunikacyjne między nimi za pomocą standardowych interfejsów API gniazd dla procesów w przestrzeni użytkownika oraz specjalnego interfejsu API jądra dla modułów jądra. Gniazdo Netlink korzysta z rodziny adresów AF_NETLINK.
.....
Dlaczego powyższe funkcje używają netlink zamiast wywołań systemowych, systemów plików ioctls lub proc do komunikacji między światem użytkownika i jądra? Nietrudnym zadaniem jest dodawanie wywołań systemowych, plików ioctls lub plików proc dla nowych funkcji; ryzykujemy zanieczyszczenie jądra i uszkodzenie stabilności systemu. Gniazdo Netlink jest jednak proste: do netlink.h należy dodać tylko stałą, typ protokołu. Następnie moduł jądra i aplikacja mogą natychmiast komunikować się za pomocą interfejsów API w stylu gniazd.
....
Gniazdo Netlink to elastyczny interfejs do komunikacji między aplikacjami przestrzeni użytkownika a modułami jądra. Zapewnia łatwy w użyciu interfejs API gniazd zarówno dla aplikacji, jak i jądra. Zapewnia zaawansowane funkcje komunikacji, takie jak pełny dupleks, buforowane operacje we / wy, multiemisja i komunikacja asynchroniczna, których nie ma w innych IPC jądra / przestrzeni użytkownika.
ipbardziej wszechstronnym, ponieważ wszelkiego rodzaju fajne funkcje są po prostu niemożliwe do wykonania przy użyciu ioctlów na Linuksie (ponieważ ioctlów nie ma i prawdopodobnie nigdy nie będzie).