Em algum momento, em algum material de ensino (da Linux Foundation) no Linux que me deparei, o seguinte é mencionado:
ipO comando é mais versátil e mais eficiente do queifconfigporque usa soquetes netlink em vez de chamadas de sistema ioctl .
Alguém pode elaborar um pouco sobre isso, porque eu não consigo entender o que está acontecendo sob o capô?
PS Estou ciente deste tópico sobre essas ferramentas, mas ele não aborda essa diferença específica de como elas operam
Respostas:
O ifconfigcomando em sistemas operacionais como FreeBSD e OpenBSD foi atualizado de acordo com o restante do sistema operacional. Atualmente, ele pode definir todos os tipos de configurações de interface de rede nesses sistemas operacionais e lidar com uma variedade de protocolos de rede. Os BSDs fornecem ioctl()suporte para essas coisas.
Isso não aconteceu no mundo Linux. Hoje existem três ifconfigcomandos:
ifconfigde inetutils GNUjdebp% inetutils-ifconfig -l
enp14s0 enp15s0 lo
jdebp% inetutils-ifconfig lo
lo Encap do link: Loopback local
endereço inet: 127.0.0.1 Bcast: 0.0.0.0 Máscara: 255.0.0.0
UP LOOPBACK EM FUNCIONAMENTO MTU: 65536 Métrico: 1
Pacotes RX: 9087 erros: 0 eliminados: 0 excedentes: 0 quadro: 0
Pacotes TX: 9087 erros: 0 eliminados: 0 excedentes: 0 transportadora: 0
colisões: 0 txqueuelen: 1000
Bytes RX: 51214341 Bytes TX: 51214341
jdebp%
ifconfigdas ferramentas de rede NET-3 jdebp% ifconfig -l
ifconfig: option --help 'fornece informações de uso.-l' not recognised.
ifconfig:
jdebp% ifconfig lo
lo: flags = 73 <UP, LOOPBACK, RUNNING> mtu 65536
inet 127.0.0.1 máscara de rede 255.0.0.0
inet6 :: 1 prefixo 128 escopo 0x10 <host>
inet6 :: 2 prefixo 128 escopo 0x80 <compat, global>
inet6 fe80 :: prefixlen 10 escopo 0x20 <link>
loop txqueuelen 1000 (loopback local)
Pacotes RX 9087 bytes 51214341 (48,8 MiB)
Erros de RX 0 eliminados 0 excedem 0 quadros 0
Pacotes TX 9087 bytes 51214341 (48,8 MiB)
Erros de TX 0 eliminados 0 excedentes 0 transportadora 0 colisões 0
jdebp%
ifconfig(versão 1.40 de) o conjunto de ferramentas nosh jdebp% ifconfig -l
enp14s0 enp15s0 lo
jdebp% ifconfig lo
eis
vincular a execução de loopback
endereço de link 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
endereço inet4 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1
endereço inet4 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255
inet6 address :: 2 scope 0 prefixlen 128
endereço inet6 fe80 :: prefixo 1 do escopo 1 10
endereço inet6 :: 1 escopo 0 prefixo 128
jdebp% sudo ifconfig para o alet do inet4 127.1.0.2
jdebp% sudo ifconfig para o inet6 :: 3/128 alias
jdebp% ifconfig lo
eis
vincular a execução de loopback
endereço de link 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00
endereço inet4 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1
endereço inet4 127.1.0.2 prefixlen 32 bdaddr 127.1.0.2
endereço inet4 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255
inet6 address :: 3 scope 0 prefixlen 128
inet6 address :: 2 scope 0 prefixlen 128
endereço inet6 fe80 :: prefixo 1 do escopo 1 10
endereço inet6 :: 1 escopo 0 prefixo 128
jdebp% Como você pode ver, os inetutils GNU e as ferramentas de rede NET-3 ifconfigtêm algumas deficiências marcadas, com relação ao IPv6, com relação a interfaces que possuem vários endereços e com relação a funcionalidades como -l.
O problema do IPv6 é em parte algum código ausente nas próprias ferramentas. Mas, em geral, isso é causado pelo fato de o Linux não (como outros sistemas operacionais) fornecer funcionalidade IPv6 através da ioctl()interface. Ele só permite que os programas vejam e manipulem endereços IPv4 através da rede ioctl().
O Linux fornece essa funcionalidade por meio de uma interface diferente send()e recv()em uma família de soquetes especial e um tanto estranha AF_NETLINK.
O GNU e o NET-3 ifconfigs poderiam ter sido ajustados para usar esta nova API. O argumento contra a fazê-lo foi que não era portável para outros sistemas operacionais, mas estes programas foram, na prática já não portátil de qualquer maneira para que não era muito de um argumento.
Mas eles não foram ajustados e permanecem como mostrados até hoje. (Algumas pessoas trabalharam neles em vários pontos ao longo dos anos, mas é triste dizer que as melhorias nunca foram incluídas nos programas. Por exemplo: Bernd Eckenfels nunca aceitou um patch que adicionava algum recurso da API de netlink às ferramentas de rede NET-3 ifconfig, 4 anos após o patch ter sido escrito.)
Em vez disso, algumas pessoas reinventaram completamente o conjunto de ferramentas como um ipcomando, que usava a nova API do Linux, tinha uma sintaxe diferente e combinou várias outras funções por trás de uma interface no estilo da moda .command subcommand
Eu precisava de um ifconfigque tivesse a sintaxe da linha de comando e o estilo de saída do FreeBSD ifconfig(que nem o GNU nem o NET-3 ifconfigpossuem e que ipcertamente não possui). Então eu escrevi um. Como prova de que alguém pode escrever um ifconfigque use a API netlink no Linux, ele usa.
Portanto, a sabedoria recebida sobre ifconfig, como o que você cita, não é mais verdadeira. Agora é falso dizer que " ifconfignão usa o netlink". O cobertor que cobria dois não cobre três.
Ele sempre foi falso dizer que "netlink é mais eficiente". Para as tarefas com as quais se realiza ifconfig, não há muito em termos de eficiência entre a API netlink e a ioctl()API. Um faz praticamente o mesmo número de chamadas de API para qualquer tarefa.
De fato, cada chamada de API é composta por duas chamadas de sistema no caso netlink, em oposição a uma no ioctl()sistema. E, sem dúvida, a API netlink tem a desvantagem de que, em um sistema muito usado, incorpora explicitamente a possibilidade de a ferramenta nunca receber uma mensagem de confirmação informando o resultado da chamada da API.
É, além disso, falso dizer que ipé "mais versátil" que o GNU e NET-3 ifconfigs , porque ele usa netlink . É mais versátil porque realiza mais tarefas, fazendo coisas em um grande programa que se faria com programas separados que não ifconfig . Não é mais versátil simplesmente por meio da API que ela usa internamente para executar essas tarefas extras. Não há nada inerente à API sobre isso. Pode-se escrever uma ferramenta tudo-em-um que usou o FreeBSD ioctl()API, por exemplo, e igualmente bem estado que é "mais versátil" do que os individuais ifconfig, route, arp, e ndpcomandos.
Pode-se escrever route, arpe ndpcomandos para Linux que utilizaram o API netlink, também.
ifconfig. Guia nosh . Softwares.O padrão ifconfigque temos em muitas distribuições foi descontinuado por vários motivos. Fala de maneira desatualizada e limitada com o kernel e, de fato, não entende mais todas as configurações de rede. Você não será capaz de manipular algumas configurações de rede, tais ifconfigversões com as quais pode fazer ip. Além disso, o ifconfigsuporte para namespaces de rede é limitado.
Como um conto anedótico, encontrei o alias de IP da interface que é visível apenas ipno SuSE e não no mesmo ifconfig.
Quanto às diferenças ocultas: From ifconfig vs ip: o que é diferença e comparando a configuração de rede
Embora
ippossa parecer um pouco complexo no primeiro site, mas é muito mais amplo em funcionalidade do que o ifconfig. Ele é funcionalmente organizado em duas camadas da pilha de rede, ou seja, a camada 2 (camada de link), a camada 3 (camada de IP) e realiza o trabalho de todos os comandos mencionados acima no pacote net-tools.Embora a
ifconfigmaioria exiba ou modifique as interfaces de um sistema, esse comando é capaz de executar as seguintes tarefas:
Exibindo ou modificando propriedades da interface.
Adicionando, removendo entradas do cache do ARP ao criar uma nova entrada estática do ARP para um host.
Exibindo endereços MAC associados a todas as interfaces.
Exibindo e modificando tabelas de roteamento do kernel.
Um dos principais destaques que o separa de sua contraparte antiga ifconfig é que o último usa o ioctl para configuração de rede, que é uma maneira menos apreciada de interação com o kernel, enquanto o antigo aproveita o mecanismo de soquete de netlink para o mesmo, que é um sucessor muito mais flexível do ioctl para intercomunicação entre o kernel e o espaço do usuário usando o rtnetlink (que adiciona capacidade de manipulação do ambiente de rede).
Sobre o uso / vantagens do netlink: No LJ - Kernel Korner - Por que e como usar o Netlink Socket
O soquete Netlink é um IPC especial usado para transferir informações entre os processos do kernel e do espaço do usuário. Ele fornece um link de comunicação full-duplex entre as duas por meio de APIs de soquete padrão para processos de espaço do usuário e uma API de kernel especial para módulos de kernel. O soquete Netlink usa a família de endereços AF_NETLINK.
.....
Por que os recursos acima usam o netlink em vez de chamadas de sistema, ioctls ou proc filesystems para comunicação entre mundos de usuário e kernel? É uma tarefa não trivial adicionar chamadas do sistema, ioctls ou arquivos proc para novos recursos; corremos o risco de poluir o núcleo e danificar a estabilidade do sistema. O soquete do Netlink é simples: porém, apenas uma constante, o tipo de protocolo, precisa ser adicionada ao netlink.h. Em seguida, o módulo e o aplicativo do kernel podem falar usando APIs de estilo de soquete imediatamente.
....
O soquete Netlink é uma interface flexível para comunicação entre aplicativos de espaço do usuário e módulos do kernel. Ele fornece uma API de soquete fácil de usar para aplicativos e kernel. Ele fornece recursos avançados de comunicação, como comunicação full-duplex, E / S em buffer, multicast e assíncrona, ausentes em outros IPCs do kernel / espaço do usuário.
ipmais versátil, porque todos os tipos de recursos interessantes são simplesmente impossíveis de se usar usando ioctls no Linux (porque os ioctls não estão lá e provavelmente nunca estarão).