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


28

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:

iplệnh linh hoạt và hiệu quả hơn so với ifconfigvì nó sử dụng các ổ cắm netlink hơn là các cuộc gọi hệ thống ioctl .

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?

PS 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

Câu trả lời:


39

Các ifconfiglệnh trên 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. BSD cung cấp ioctl()hỗ trợ cho những điều này.

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

  • ifconfigtừ GNU inetutils
    jdebp% inetutils-ifconfig -l
    enp14s0 enp15s0 lo
    jdebp% inetutils-ifconfig lo
    lo Liên kết mã hóa: Loopback cục bộ
          inet addr: 127.0.0.1 Bcast: 0.0.0.0 Mặt nạ: 255.0.0.0
          LÊN LOOPBACK CHẠY MTU: 65536 Số liệu: 1
          Các gói RX: 9087 lỗi: 0 rớt: 0 tràn: 0 khung: 0
          Các gói TX: 9087 lỗi: 0 rớt: 0 tràn: 0 sóng mang: 0
          va chạm: 0 txqueuelen: 1000
          Các byte RX: 51214341 TX byte: 51214341
    jdebp%
  • ifconfigtừ các công cụ mạng NET-3
    jdebp% ifconfig -l
    ifconfig: tùy chọn --help 'cung cấp thông tin sử dụng.-l' not recognised.
    ifconfig:
    jdebp% ifconfig lo
    lo: flags = 73 <LÊN, LOOPBACK, CHẠY> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 :: 1 tiền tố 128 scopeid 0x10 <host>
        inet6 :: 2 tiền tố 128 scopeid 0x80 <compat, global>
        inet6 fe80 :: prefixlen 10 scopeid 0x20 <link>
        vòng lặp txqueuelen 1000 (Vòng lặp cục bộ)
        Gói RX 9087 byte 51214341 (48,8 MiB)
        Lỗi RX 0 rớt 0 vượt 0 khung 0
        Gói TX 9087 byte 51214341 (48,8 MiB)
        Lỗi TX 0 rớt 0 vượt 0 nhà cung cấp 0 va chạm 0
    jdebp%
  • ifconfigtừ (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 bdaddr 00: 00: 00: 00: 00: 00 
        địa chỉ inet4 127.0.0.1 tiền tố 8 bdaddr 127.0.0.1 
        địa chỉ inet4 127.53.0.1 tiền tố 8 bdaddr 127.255.255.255 
        địa chỉ inet6 :: 2 scope 0 prefixlen 128 
        địa chỉ inet6 fe80 :: scope 1 prefixlen 10 
        địa chỉ inet6 :: 1 scope 0 prefixlen 128
    jdebp% sudo ifconfig lo inet4 127.1.0.2 bí danh
    jdebp% sudo ifconfig lo inet6 :: bí danh 3/128
    jdebp% ifconfig lo
    lo
        liên kết lên loopback chạy
        địa chỉ liên kết 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00 
        địa chỉ inet4 127.0.0.1 tiền tố 8 bdaddr 127.0.0.1 
        địa chỉ inet4 127.1.0.2 tiền tố 32 bdaddr 127.1.0.2 
        địa chỉ inet4 127.53.0.1 tiền tố 8 bdaddr 127.255.255.255 
        địa chỉ inet6 :: 3 scope 0 prefixlen 128 
        địa chỉ inet6 :: 2 scope 0 prefixlen 128 
        địa chỉ inet6 fe80 :: scope 1 prefixlen 10 
        địa chỉ inet6 :: 1 scope 0 prefixlen 128 
    jdebp% 

Như bạn có thể thấy, các inetutils GNU và các công cụ mạng NET-3 ifconfigcó 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 ioctl()giao diện. Nó chỉ cho phép các chương trình xem và thao tác các địa chỉ IPv4 thông qua các mạng ioctl().

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 nhóm địa chỉ đặc biệt và hơi kỳ lạ AF_NETLINK.

GNU và NET-3 ifconfigs có thể đã được điều chỉnh để sử dụng API mới này. Các lập luận chống lại làm như vậy là nó đã không cầm tay để hệ điều hành khác, nhưng các chương trình này là trong thực tế đã không cầm tay nào để là không nhiều của một cuộc tranh cãi.

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 qua, 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á có thêm một số khả năng API netlink cho các công cụ mạng NET-3 ifconfig, 4 năm sau khi bản vá đã được viết.)

Thay vào đó, một số người hoàn toàn phát minh lại bộ công cụ như một iplệnh, 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 thời trang .command subcommand

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

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. Nó là hiện nay không đúng sự thật để nói rằng " ifconfigkhông sử dụng netlink.". Cái chăn phủ hai cái không che ba cái.

Người ta luôn 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 ifconfig, thực sự không có nhiều trong đó khi nói đến hiệu quả giữa API netlink và ioctl()API. 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 lệnh gọi hệ thống trong trường hợp netlink, trái ngược với một cuộc gọi trong ioctl()hệ thống. 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.

Nó được, hơn nữa, không đúng sự thật để nói rằng iplà "linh hoạt hơn" so với GNU và NET-3 ifconfigs vì nó sử dụng netlink . Nó linh hoạt hơn bởi 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 khác 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 công cụ all-in-one rằng sử dụng FreeBSD ioctl()API, ví dụ, và tốt như nhau bang rằng nó là "linh hoạt hơn" so với các cá nhân ifconfig, route, arp, và ndpcác lệnh.

Người ta có thể viết route, arpndplệnh cho Linux mà sử dụng API netlink, quá.

đọc thêm


Tôi nghĩ rằng bạn đang đọc quá nhiều vào yêu cầu "linh hoạt hơn". IMHO chỉ nói rằng netlink là thứ tạo ra ipsự linh hoạt hơn, bởi vì tất cả các loại tính năng thú vị đơn giản là không thể sử dụng ioctls trên Linux (vì ioctls không có ở đó và có khả năng sẽ không bao giờ có).
TooTea ngày

1
"netlink là thứ làm cho ip linh hoạt hơn" giống như "ip linh hoạt hơn vì nó sử dụng netlink", điều này có ngay trong câu hỏi .
JdeBP

8

Tiêu chuẩn ifconfigchú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ư ifconfigcác phiên bản mà bạn có thể thực hiện ip. Ngoài ra, sự ifconfighỗ trợ 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 ipvà không có trong SuSE ifconfig.

Đối với sự khác biệt trong chương trình: Từ ifconfig so với ip: Sự khác biệt và so sánh cấu hình mạng là gì

Mặc dù ipcó 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.

Mặc dù ifconfigchủ yếu hiển thị hoặc sửa đổi các giao diện của một 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 (bổ sung 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 IPC đặc biệt được sử dụng để chuyển thông tin giữa các quá 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? Đây là một nhiệm vụ không cần thiết để thêm các cuộc gọi hệ thống, ioctls hoặc các tệp Proc cho các tính năng mới; 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, socket 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.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.