ในบางจุดในสื่อการสอน (จาก Linux Foundation) บน Linux ที่ฉันเจอมีการกล่าวถึงสิ่งต่อไปนี้:

ipคำสั่งมีความหลากหลายและมีประสิทธิภาพมากกว่าifconfigเพราะมันใช้ซ็อกเก็ตnetlinkมากกว่าการเรียกระบบioctl

ใครสามารถอธิบายรายละเอียดเล็กน้อยเกี่ยวกับเรื่องนี้เพราะฉันไม่เข้าใจว่าเกิดอะไรขึ้นภายใต้ประทุน?

ป.ล. ฉันทราบเกี่ยวกับหัวข้อนี้ในเครื่องมือเหล่านั้น แต่ไม่ได้ระบุความแตกต่างเฉพาะนี้เกี่ยวกับวิธีการใช้งาน

ifconfigคำสั่งบนระบบปฏิบัติการเช่น FreeBSD และ OpenBSD ได้รับการปรับปรุงให้สอดคล้องกับส่วนที่เหลือของระบบปฏิบัติการ ทุกวันนี้สามารถกำหนดค่าการตั้งค่าอินเทอร์เฟซเครือข่ายได้ทุกประเภทบนระบบปฏิบัติการเหล่านั้นและจัดการโปรโตคอลเครือข่ายที่หลากหลาย BSD ให้ioctl()การสนับสนุนสิ่งเหล่านี้

สิ่งนี้ไม่ได้เกิดขึ้นในโลก Linux มีสามifconfigคำสั่งในวันนี้:

• ifconfigจากGNU inetutils

  jdebp% inetutils-ifconfig -l
  enp14s0 enp15s0 แท้จริง
  jdebp% inetutils-ifconfig แท้จริง
  lo Link encap: Local Loopback
        inet addr: 127.0.0.1 Bcast: 0.0.0.0 รูปแบบ: 255.0.0.0
        การเรียกใช้ LOOPBACK RUNNING MTU: 65536 ตัวชี้วัด: 1
        RX แพ็กเก็ต: 9087 ข้อผิดพลาด: 0 ลดลง: 0 overruns: 0 เฟรม: 0
        แพ็กเก็ต TX: 9087 ข้อผิดพลาด: 0 ลดลง: 0 overruns: 0 ผู้ให้บริการ: 0
        การชน: 0 txqueuelen: 1,000
        จำนวนไบต์: 51214341 TX ไบต์: 51214341
  jdebp%

• ifconfigจากNET-3 เครื่องมือสุทธิ

  jdebp% ifconfig -l
  ifconfig: ตัวเลือก- ช่วย 'ให้ข้อมูลการใช้งาน-l' not recognised.
  ifconfig:
  jdebp% ifconfig แท้จริง
  lo: ค่าสถานะ = 73 <ขึ้นไป, วนกลับ, การวิ่ง> mtu 65536
      inet 127.0.0.1 netmask 255.0.0.0
      inet6 :: คำนำหน้า 1 128 ขอบเขตid 0x10 <host>
      inet6 :: คำนำหน้า 2 128 ขอบเขตid 0x80 <compat, global>
      inet6 fe80 :: คำนำหน้า 10 ขอบเขตid 0x20 <link>
      loop txqueuelen 1000 (Local Loopback)
      RX แพ็คเก็ต 9087 ไบต์ 51214341 (48.8 MiB)
      ข้อผิดพลาดของ RX 0 ลดลง 0 เกิน 0 เฟรม 0
      แพ็คเก็ต TX 9087 ไบต์ 51214341 (48.8 MiB)
      ข้อผิดพลาดของ TX 0 ลดลง 0 เกิน 0 ผู้ให้บริการ 0 ชน 0
  jdebp%

• ifconfigจาก (เวอร์ชัน 1.40 จาก) ชุดเครื่องมือ nosh

  jdebp% ifconfig -l
  enp14s0 enp15s0 แท้จริง
  jdebp% ifconfig แท้จริง
  ดูเถิด
      เชื่อมโยงการทำงานลูปแบ็ค
      ที่อยู่ลิงก์ 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 แท้จริง inet4 127.1.0.2 นามแฝง
  jdebp% sudo ifconfig แท้จริง inet6 :: 3/128 นามแฝง
  jdebp% ifconfig แท้จริง
  ดูเถิด
      เชื่อมโยงการทำงานลูปแบ็ค
      ที่อยู่ลิงก์ 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 address 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 ifconfigs มีข้อบกพร่องบางอย่างเกี่ยวกับ IPv6 ที่เกี่ยวกับส่วนต่อประสานที่มีที่อยู่หลายแห่งและเกี่ยวกับหน้าที่การใช้งานเช่น-lเดียวกัน

ปัญหา IPv6 เป็นส่วนหนึ่งของรหัสที่หายไปในเครื่องมือด้วยตนเอง แต่โดยหลักแล้วมันเกิดจากข้อเท็จจริงที่ว่า Linux ไม่ได้ (เช่นระบบปฏิบัติการอื่น) ให้การทำงานของ IPv6 ผ่านทางioctl()อินเตอร์เฟส มันช่วยให้โปรแกรมดูและจัดการที่อยู่ IPv4 ผ่านเครือข่ายioctl()s เท่านั้น

ลินุกซ์แทนให้ฟังก์ชันการทำงานนี้ผ่านอินเตอร์เฟซที่แตกต่างกันsend()และในวันที่พิเศษและค่อนข้างแปลกครอบครัวอยู่ของซ็อกเก็ตrecv()AF_NETLINK

แอฟริกาและ NET-3 ifconfigs อาจได้รับการปรับเปลี่ยนให้ใช้ API ใหม่นี้ ข้อโต้แย้งเกี่ยวกับการทำเช่นนั้นคือมันไม่สามารถพกพาไปยังระบบปฏิบัติการอื่น ๆ ได้ แต่โปรแกรมเหล่านี้ในทางปฏิบัติแล้วไม่ได้พกพาอยู่แล้วดังนั้นจึงไม่ได้มีข้อโต้แย้งมากมาย

แต่พวกเขาก็ไม่ได้ปรับตัวและยังคงเป็นเหมือนวันนี้ (บางคนทำงานกับพวกเขาที่จุดต่าง ๆ ในช่วงหลายปีที่ผ่านมา แต่การปรับปรุงเศร้าที่จะพูดไม่เคยทำมันเข้าไปในโปรแกรมตัวอย่าง: Bernd Eckenfels ไม่เคยยอมรับแพทช์ที่เพิ่มขีดความสามารถ netlink API ให้กับ NET-3 net-tools ifconfig4 ปีหลังจากที่แพทช์ได้ถูกเขียนขึ้น)

แต่บางคนคิดค้นชุดเครื่องมือใหม่ทั้งหมดเป็นipคำสั่งซึ่งใช้ Linux API ใหม่มีไวยากรณ์ที่แตกต่างกันและรวมฟังก์ชั่นอื่น ๆ อีกหลายอย่างไว้เบื้องหลังอินเทอร์เฟซแบบสไตล์ที่ทันสมัยcommand subcommand

ฉันต้องการสิ่งifconfigที่มีไวยากรณ์บรรทัดคำสั่งและรูปแบบการส่งออกของ FreeBSD ifconfig(ซึ่ง GNU หรือ NET-3 ifconfigไม่มีและที่ipแน่นอนที่สุดไม่มี) ดังนั้นฉันจึงเขียนหนึ่ง เป็นข้อพิสูจน์ว่าเราสามารถเขียนifconfigที่ใช้ netlink API บน Linux ได้

ดังนั้นปัญญาที่ได้รับifconfigเช่นสิ่งที่คุณพูดไม่เป็นความจริงอีกต่อไป ตอนนี้มันไม่จริงที่จะบอกว่า " ifconfigไม่ใช้ netlink" ผ้าห่มที่ครอบคลุมสองไม่ครอบคลุมสาม

มันไม่จริงเสมอที่จะบอกว่า "netlink มีประสิทธิภาพมากขึ้น" สำหรับงานที่ทำifconfigมีไม่มากจริง ๆ เมื่อพูดถึงประสิทธิภาพระหว่าง netlink API และioctl()API หนึ่งทำให้การเรียก API จำนวนเท่ากันสำหรับงานที่กำหนด

แท้จริงแล้วการเรียก API แต่ละครั้งเป็นการเรียกสองระบบในกรณี netlink ซึ่งตรงข้ามกับการเรียกหนึ่งครั้งในioctl()ระบบ และเนื้อหาที่ว่า netlink API นั้นมีข้อเสียที่บนระบบที่ใช้งานอย่างหนักมันได้รวมเอาความเป็นไปได้ของเครื่องมืออย่างชัดเจนโดยไม่เคยได้รับข้อความตอบรับเพื่อแจ้งให้ทราบถึงผลของการเรียก API

มันเป็นเรื่องที่ยิ่งจริงที่จะบอกว่าipเป็น "มากกว่าอเนกประสงค์" กว่า GNU และ NET-3 ifconfigs เพราะมันใช้ netlink ก็จะมากขึ้นหลากหลายเพราะมันไม่งานมากขึ้นการทำสิ่งที่ยิ่งใหญ่ในโปรแกรมหนึ่งที่หนึ่งจะทำอย่างไรกับโปรแกรมแยกอื่นที่ไม่ใช่ ifconfigมันไม่ได้มีความหลากหลายมากขึ้นเพียงแค่ใช้ API ที่ใช้ภายในเพื่อดำเนินงานพิเศษเหล่านั้น API ไม่มีอะไรเกี่ยวข้องกับเรื่องนี้ หนึ่งสามารถเขียนเป็นเครื่องมือทั้งหมดในหนึ่งเดียวที่ใช้ FreeBSD ioctl()API สำหรับตัวอย่างและเท่าเทียมกันทั้งรัฐว่ามันคือ "อเนกประสงค์" กว่าบุคคลifconfig, route, arpและndpคำสั่ง

หนึ่งสามารถเขียนroute, arpและndpคำสั่งสำหรับลินุกซ์ที่ใช้ API netlink เกินไป

อ่านเพิ่มเติม

• Jonathan de Boyne Pollard (2019) ifconfig. Nosh คู่มือ โปรแกรม
• Eduardo Ferro (2009-04-16) ifconfig: รายงานที่อยู่ IP ที่ไม่ถูกต้อง / แพทช์เริ่มต้น Debian bug # 359676

มาตรฐานที่ifconfigเรามีในการแจกแจงจำนวนมากถูกคัดค้านด้วยเหตุผลหลายประการ พูดในลักษณะที่ล้าสมัยและ จำกัด ด้วยเคอร์เนลและในความเป็นจริงไม่เข้าใจการกำหนดค่าเครือข่ายทั้งหมดอีกต่อไป คุณจะไม่สามารถจัดการกับบางส่วนกำหนดค่าเครือข่ายเช่น รุ่นที่ให้คุณสามารถที่จะทำอย่างไรกับifconfig ipนอกจากนี้การifconfigรองรับเนมสเปซเครือข่ายมี จำกัด

ในฐานะที่เป็นเรื่องประวัติผมพบว่าอินเตอร์เฟซนามแฝง IP ที่มีเฉพาะที่มองเห็นในipและไม่ได้อยู่ใน ifconfigSuSE

สำหรับความแตกต่างภายใต้ประทุน: จากifconfig vs ip: ความแตกต่างและการเปรียบเทียบการกำหนดค่าเครือข่าย

แม้ว่าipอาจดูเหมือนซับซ้อนเล็กน้อยในไซต์แรก แต่มีการทำงานที่กว้างกว่า ifconfig มันถูกจัดระเบียบตามหน้าที่ในสองชั้นของ Networking Stack เช่น Layer 2 (Link Layer), Layer 3 (IP Layer) และทำงานการทำงานของคำสั่งทั้งหมดที่กล่าวถึงข้างต้นจากแพ็คเกจเครื่องมือสุทธิ

ขณะที่ifconfigส่วนใหญ่แสดงหรือปรับเปลี่ยนอินเตอร์เฟสของระบบคำสั่งนี้สามารถทำงานต่อไปนี้ได้:

• การแสดงหรือแก้ไขคุณสมบัติอินเตอร์เฟส

• การเพิ่มการลบรายการ ARP Cache พร้อมกับสร้างรายการ ARP แบบคงที่ใหม่สำหรับโฮสต์

• การแสดงที่อยู่ MAC ที่เชื่อมโยงกับส่วนต่อประสานทั้งหมด

• การแสดงและการแก้ไขตารางเส้นทางเคอร์เนล

หนึ่งในไฮไลท์หลักที่แยกออกมาจาก ifconfig ที่เก่าแก่ของมันคือหลังใช้ ioctl สำหรับการกำหนดค่าเครือข่ายซึ่งเป็นวิธีการโต้ตอบกับเคอร์เนลที่ไม่ค่อยชื่นชมในขณะที่อดีตใช้ประโยชน์จากกลไกซ็อกเก็ต netlink สำหรับสิ่งเดียวกัน ของ ioctl สำหรับการสื่อสารระหว่างเคอร์เนลและพื้นที่ผู้ใช้โดยใช้ rtnetlink (ซึ่งเพิ่มความสามารถในการจัดการสภาพแวดล้อมเครือข่าย)

เกี่ยวกับการใช้ / ข้อดีของ netlink: จากLJ - Kernel Korner - ทำไมและวิธีการใช้ Netlink Socket

Netlink socket เป็น IPC พิเศษที่ใช้สำหรับการถ่ายโอนข้อมูลระหว่างเคอร์เนลและกระบวนการพื้นที่ผู้ใช้ ให้การเชื่อมโยงการสื่อสารแบบ full-duplex ระหว่างสองทาง API ซ็อกเก็ตมาตรฐานสำหรับกระบวนการพื้นที่ผู้ใช้และเคอร์เนล API พิเศษสำหรับโมดูลเคอร์เนล ซ็อกเก็ต Netlink ใช้ตระกูลที่อยู่ AF_NETLINK

.....

เหตุใดคุณสมบัติด้านบนจึงใช้ netlink แทนการเรียกระบบ ioctls หรือระบบไฟล์ proc สำหรับการสื่อสารระหว่างผู้ใช้กับโลกเคอร์เนล มันเป็นงานที่ไม่สำคัญในการเพิ่มการเรียกระบบ, ไฟล์ ioctls หรือ proc สำหรับคุณสมบัติใหม่; เราเสี่ยงที่จะสร้างความเสียหายกับเคอร์เนลและสร้างความเสียหายต่อเสถียรภาพของระบบ ซ็อกเก็ต Netlink นั้นง่าย แต่ต้องเพิ่มเฉพาะชนิดโปรโตคอลเท่านั้นที่จะเพิ่มใน netlink.h จากนั้นเคอร์เนลโมดูลและแอปพลิเคชันสามารถพูดคุยโดยใช้ API แบบซ็อกเก็ตได้ทันที

....

Netlink socket เป็นอินเตอร์เฟสที่ยืดหยุ่นสำหรับการสื่อสารระหว่างแอปพลิเคชันพื้นที่ผู้ใช้และโมดูลเคอร์เนล มันมีซ็อกเก็ต API ที่ใช้งานง่ายสำหรับทั้งแอปพลิเคชันและเคอร์เนล มันมีคุณสมบัติการสื่อสารขั้นสูงเช่น full-duplex, บัฟเฟอร์ I / O, multicast และการสื่อสารแบบอะซิงโครนัสซึ่งขาดใน IPC เคอร์เนล / ผู้ใช้พื้นที่