tra-loi-cau-hoi-phat-trien-web.com

lệnh ip vs ifconfig ưu và nhược điểm

Tại một số điểm, trong một số tài liệu giảng dạy (từ Linux Foundation) về Linux mà tôi đã gặp, những điều sau đây được đề cập:

Lệnh ip linh hoạt và hiệu quả hơn so với ifconfig vì nó sử dụng ổ cắm netlink thay vì ioctl gọi hệ thống.

Bất cứ ai cũng có thể giải thích một chút về điều này bởi vì tôi không thể hiểu những gì đang diễn ra dưới mui xe?

P.S. Tôi biết chủ đề này trên các công cụ đó nhưng nó không giải quyết sự khác biệt cụ thể này về cách chúng hoạt động

33
pkaramol

Lệnh ifconfig trên các hệ điều hành như FreeBSD và OpenBSD đã được cập nhật phù hợp với phần còn lại của hệ điều hành. Ngày nay, nó có thể cấu hình tất cả các loại cài đặt giao diện mạng trên các hệ điều hành đó và xử lý một loạt các giao thức mạng. Các BSD cung cấp hỗ trợ ioctl() cho những thứ này.

Điều này đã không xảy ra trong thế giới Linux. Hôm nay, có ba lệnh ifconfig:

  • ifconfig từ GNU inetutils [.__.]
    jdebp% inetutils-ifconfig -l [.__.] enp14s0 enp15s0 lo [.__.] jdebp% inetutils-ifconfig lo [.__.] Mặt nạ 0.0.0.0: 255.0.0.0 [.__.] LÊN LOOPBACK CHẠY MTU: 65536 Số liệu: 1 [.__.] Gói RX: 9087 lỗi: 0 rớt: 0 tràn: 0 khung: 0 [.__.] Gói TX : 9087 lỗi: 0 rớt: 0 tràn: 0 sóng mang: 0 [.__.] Va chạm: 0 txqueuelen: 1000 [.__.] RX byte: 51214341 TX byte: 51214341 [.__.] Jdebp%
  • ifconfig từ NET-3 công cụ mạng [.__.]
    jdebp% ifconfig -l [.__.] ifconfig: tùy chọn -l' not recognised.
    ifconfig: - help 'cung cấp thông tin sử dụng. [.__.] jdebp% ifconfig lo [.__.] lo: flags = 73 <UP, LOOPBACK , RUNNING> mtu 65536 [.__.] Inet 127.0.0.1 netmask 255.0.0.0 [.__.] Inet6 :: 1 prefixlen 128 scopeid 0x10 <Host> [.__.] Inet6 :: 2 prefixlen 128 scopeid 0x80 <compat, toàn cầu> [.__.] inet6 fe80 :: prefixlen 10 scopeid 0x20 <link> [.__.] loop txqueuelen 1000 (Local Loopback) [.__.] Gói RX 9087 byte 51214341 (48.8 MiB) [.__.] lỗi 0 rớt 0 tràn 0 khung 0 [.__.] Gói TX 9087 byte 51214341 (48.8 MiB) [.__.] Lỗi TX 0 rớt 0 tràn 0 sóng mang 0 va chạm 0 [.__.] jdebp%
  • ifconfig từ (phiên bản 1.40 của) bộ công cụ nosh [.__.]
    jdebp% ifconfig -l [.__.] enp14s0 enp15s0 lo [.__.] jdebp% ifconfig lo [.__.] lo [.__.] liên kết lên loopback chạy [.__.] địa chỉ liên kết 00:00:00: 00:00:00 bdaddr 00: 00: 00: 00: 00 [.__.] Inet4 địa chỉ 127.0.0.1 tiền tố 8 bdaddr 127.0.0.1 [.__.] Inet4 địa chỉ 127.53.0.1 tiền tố 8 bdaddr 127.255.255.255 [ .___.] Địa chỉ inet6 :: 2 scope 0 prefixlen 128 [.__.] inet6 địa chỉ fe80 :: scope 1 prefixlen 10 [.__.] inet6 address :: 1 scope 0 prefixlen 128 [.__.] jdebp% Sudo ifconfig lo inet4 127.1.0.2 bí danh [.__.] jdebp% Sudo ifconfig lo inet6 :: 3/128 bí danh [.__.] jdebp% ifconfig lo [.__.] lo [.__.] liên kết lên loopback chạy [.___ .] địa chỉ liên kết 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00 [.__.] inet4 địa chỉ 127.0.0.1 tiền tố 8 bdaddr 127.0.0.1 [.__.] inet4 địa chỉ Tiền tố 127.1.0.2 32 bdaddr 127.1.0.2 [.__.] Inet4 địa chỉ 127.53.0.1 tiền tố 8 bdaddr 127.255.255.255 [.__.] Inet6 address :: 3 scope 0 prefixlen 128 [.__.] Inet6 address :: 2 scope 0 prefixlen 128 [.__.] inet6 address fe80 :: scope 1 prefixlen 10 [.__.] inet6 address :: 1 scope 0 prefixlen 128 [.__.] jdebp% 

Như bạn có thể thấy, các công cụ GNU inetutils và NET-3 ifconfig có một số thiếu sót rõ rệt, liên quan đến IPv6, đối với các giao diện có nhiều địa chỉ, và liên quan đến chức năng như -l.

Vấn đề IPv6 là một phần thiếu mã trong các công cụ. Nhưng nguyên nhân chính là do Linux không (như các hệ điều hành khác làm) cung cấp chức năng IPv6 thông qua giao diện ioctl(). Nó chỉ cho phép các chương trình xem và thao tác các địa chỉ IPv4 thông qua mạng ioctl() s.

Thay vào đó, Linux cung cấp chức năng này thông qua một giao diện khác, send()recv() trên một họ địa chỉ đặc biệt và hơi kỳ quặc, AF_NETLINK.

GNU và NET-3 ifconfig s có thể đã được điều chỉnh để sử dụng API mới này. Đối số chống lại làm như vậy là nó không khả dụng cho các hệ điều hành khác, nhưng các chương trình này đã có trong thực tế đã không không di động anyway vì vậy đó không phải là một đối số.

Nhưng họ không điều chỉnh, và vẫn như trước cho đến ngày nay. (Một số người đã làm việc với họ ở nhiều điểm khác nhau trong nhiều năm, nhưng những cải tiến, đáng buồn thay, không bao giờ được đưa vào chương trình. Ví dụ: Bernd Eckenfels không bao giờ chấp nhận bản vá đã thêm một số khả năng API liên kết mạng đến NET-3 công cụ mạng ifconfig, 4 năm sau khi bản vá được viết.)

Thay vào đó, một số người đã phát minh lại hoàn toàn bộ công cụ dưới dạng lệnh ip, sử dụng API Linux mới, có một cú pháp khác và kết hợp một số chức năng khác đằng sau giao diện kiểu commandsubcommand Thời thượng.

Tôi cần một ifconfig có cú pháp dòng lệnh và kiểu đầu ra của FreeBSD ifconfig (không phải GNU hay NET-3 ifconfig có, và ip chắc chắn không có). Vì vậy, tôi đã viết một cái. Bằng chứng là người ta có thể viết ifconfig sử dụng API netlink trên Linux.

Vì vậy, sự khôn ngoan nhận được về ifconfig, chẳng hạn như những gì bạn trích dẫn, không thực sự đúng nữa. Bây giờ không đúng để nói rằng "ifconfig không sử dụng netlink.". Cái chăn phủ hai cái không che ba cái.

luôn luôn là không đúng khi nói rằng "netlink hiệu quả hơn". Đối với các tác vụ mà người ta thực hiện với ifconfig, thực sự không có nhiều trong đó khi nói đến hiệu quả giữa API netlink và API ioctl(). Một người thực hiện khá nhiều số lần gọi API cho bất kỳ tác vụ nào.

Thật vậy, mỗi lệnh gọi API là hai cuộc gọi hệ thống trong trường hợp netlink, trái ngược với một trong hệ thống ioctl(). Và có thể cho rằng API netlink có nhược điểm là trên một hệ thống được sử dụng nhiều, nó kết hợp rõ ràng khả năng công cụ không bao giờ nhận được thông báo xác nhận thông báo về kết quả của lệnh gọi API.

Hơn nữa, thật không đúng khi nói rằng ip "linh hoạt hơn" so với GNU và NET-3 ifconfig s bởi vì nó sử dụng netlink . Nó linh hoạt hơn vì nó thực hiện nhiều nhiệm vụ hơn, thực hiện mọi thứ trong một chương trình lớn mà người ta sẽ làm với các chương trình riêng biệt ngoài ifconfig. Nó không linh hoạt hơn chỉ đơn giản là do API sử dụng nội bộ để thực hiện các tác vụ bổ sung đó. Không có gì vốn có của API về điều này. Người ta có thể viết một chẳng hạn, công cụ tất cả trong một đã sử dụng API FreeBSD ioctl() và cũng nói rõ rằng nó "linh hoạt hơn" so với cá nhân ifconfig, route, Các lệnh arpndp.

Người ta có thể viết các lệnh route, arpndp cho Linux cũng sử dụng API netlink.

Đọc thêm

49
JdeBP

Tiêu chuẩn ifconfig chúng tôi có trong nhiều bản phân phối bị phản đối vì nhiều lý do. Nói một cách lỗi thời và hạn chế với kernel, và trên thực tế, không hiểu gì nữa về tất cả các cấu hình mạng. Bạn sẽ không thể thao tác một số cấu hình mạng như các phiên bản ifconfig mà bạn có thể thực hiện với ip. Ngoài ra, hỗ trợ ifconfig cho các không gian tên mạng bị hạn chế.

Như một câu chuyện giai thoại, tôi tìm thấy bí danh IP giao diện chỉ hiển thị trong ip và không có trong SuSE ifconfig.

Đối với sự khác biệt trong trình duyệt: Từ ifconfig vs ip: Sự khác biệt về cấu hình mạng và So sánh cấu hình mạng

Mặc dù ip có vẻ hơi phức tạp ở trang đầu tiên nhưng nó có chức năng rộng hơn nhiều so với ifconfig. Nó được tổ chức theo chức năng trên hai lớp của Stack Network, tức là Lớp 2 (Lớp liên kết), Lớp 3 (Lớp IP) và thực hiện công việc của tất cả các lệnh được đề cập ở trên từ gói công cụ mạng.

Trong khi ifconfig chủ yếu hiển thị hoặc sửa đổi giao diện của hệ thống, lệnh này có khả năng thực hiện các tác vụ sau:

  • Hiển thị hoặc Sửa đổi thuộc tính Giao diện.

  • Thêm, xóa các mục nhập ARP Cache cùng với việc tạo mục nhập ARP tĩnh mới cho Máy chủ lưu trữ.

  • Hiển thị địa chỉ MAC liên kết với tất cả các giao diện.

  • Hiển thị và sửa đổi các bảng định tuyến kernel.

Một trong những điểm nổi bật chính tách biệt nó với ifconfig đối tác cũ của nó là cái sau sử dụng ioctl cho cấu hình mạng, đây là cách tương tác ít được đánh giá cao với kernel trong khi trước đây tận dụng cơ chế ổ cắm netlink cho cùng một công cụ linh hoạt hơn nhiều của ioctl để liên lạc giữa kernel và không gian người dùng bằng rtnetlink (có thêm khả năng thao tác môi trường mạng).

Về công dụng/ưu điểm của netlink: Từ LJ - Kernel Korner - Tại sao và Cách sử dụng Ổ cắm Netlink

Ổ cắm Netlink là một đặc biệt IPC được sử dụng để truyền thông tin giữa các quy trình nhân và không gian người dùng. Nó cung cấp một liên kết giao tiếp song công hoàn chỉnh giữa hai bằng cách sử dụng API ổ cắm tiêu chuẩn cho các quy trình không gian người dùng và API hạt nhân đặc biệt cho các mô-đun hạt nhân. Ổ cắm Netlink sử dụng họ địa chỉ AF_NETLINK.

.....

Tại sao các tính năng trên sử dụng netlink thay vì các cuộc gọi hệ thống, ioctls hoặc hệ thống tập tin Proc để liên lạc giữa thế giới người dùng và hạt nhân? Việc thêm các lệnh gọi hệ thống, ioctls hoặc Proc cho các tính năng mới là một nhiệm vụ không cần thiết; chúng tôi có nguy cơ gây ô nhiễm hạt nhân và làm hỏng tính ổn định của hệ thống. Mặc dù vậy, ổ cắm Netlink rất đơn giản: chỉ cần một hằng số, loại giao thức, cần được thêm vào netlink.h. Sau đó, mô-đun hạt nhân và ứng dụng có thể nói chuyện bằng cách sử dụng API kiểu ổ cắm ngay lập tức.

....

Ổ cắm Netlink là một giao diện linh hoạt để liên lạc giữa các ứng dụng không gian người dùng và các mô-đun hạt nhân. Nó cung cấp API socket dễ sử dụng cho cả ứng dụng và kernel. Nó cung cấp các tính năng giao tiếp nâng cao, chẳng hạn như toàn bộ song công, I/O được đệm, giao tiếp đa hướng và không đồng bộ, không có trong các IPC kernel/không gian người dùng khác.

9
Rui F Ribeiro