答案：链路速率与实际吞吐量不符主要因单位混淆、协议开销和系统瓶颈。1000Mb/s理论带宽对应125MB/s，TCP/IP头部、确认机制等降低有效传输率，CPU处理能力或磁盘I/O不足也会限制实际速度。
在Linux系统里，想搞清楚你的网卡到底跑多快，是不是全双工，或者压根儿有没有连上，核心的办法其实就那么几个：
ethtool
和
ip
命令是你的左膀右臂。它们能帮你从物理链路层一直看到网络接口的运行状态，基本上，网络链路的“健康报告”都在这儿了。
要直接查看网络链路的速率和状态，我通常会从以下几个命令入手。
ethtool <接口名>
：这是我最常用，也觉得最直接的工具。比如，如果你想看
eth0
网卡的情况：
ethtool eth0
输出里，你会看到
Speed
（速率，比如1000Mb/s）、
Duplex
（双工模式，Full或Half）、
Link detected
（链路是否已连接）。如果
Link detected: no
，那说明物理连接都没建立起来，得检查网线或者交换机端口了。
ip link show <接口名>
：这个命令更侧重于网络接口的整体状态，比如它是不是
UP
（启用）状态，有没有错误。
ip link show eth0
你会看到
state UP
或
state DOWN
，以及
RX errors
、
TX errors
等统计信息。如果
state DOWN
，那即便
ethtool
显示
Link detected: yes
，接口也可能因为某些配置问题没法工作。
cat /sys/class/net/<接口名>/speed
和
cat /sys/class/net/<接口名>/duplex
： 有时候，如果你只想快速获取某个特定信息，直接查看
/sys
文件系统会更快，尤其是在脚本里。
cat /sys/class/net/eth0/speed cat /sys/class/net/eth0/duplex
这会直接返回链路的速度（如1000）和双工模式（full）。
我觉得这几个命令的组合，基本就能给你一个关于网络链路速率和状态的全面视图了。
如何判断网络接口是否正常工作？
判断一个Linux网络接口是不是“活的”，并且工作正常，这可不是简单看一眼就行的事。在我看来，它涉及几个层面的检查。
最直观的，就是物理链路是否建立。
ethtool eth0
的输出中，
Link detected: yes
是基石。如果这里显示
no
，那不管你后续做什么配置，网卡都是“盲”的。这通常意味着网线没插好、线缆损坏、交换机端口故障，或者网卡本身有问题。我遇到过不少次，一个看似完好的网线，其实内部已经断了，或者水晶头没压好。
接着，网络接口是否被系统启用。
ip link show eth0
的
state UP
是关键。即便物理链路是通的，如果接口是
DOWN
状态，那它也无法收发数据。这可能是因为你手动把它关了（
ip link set eth0 down
），或者驱动加载有问题，甚至某些网络管理服务（如NetworkManager）没有正确启动或配置。有时候，系统重启后，网卡莫名其妙地变成
DOWN
状态，这时候通常检查一下
/etc/network/interfaces
或相关配置，看看是不是哪里写错了。
再来，检查错误和丢包情况。
ip -s link show eth0
会提供更详细的统计信息，包括
RX errors
（接收错误）、
TX errors
（发送错误）、
dropped
（丢弃包）等。少量的错误可以忽略，但如果这些数字持续增长，而且量很大，那绝对是个警报。这可能预示着物理层面的问题（如电磁干扰、网线质量差），或者是驱动问题，甚至是网络拥堵。我曾调试过一个系统，发现
RX errors
异常高，最后定位到是交换机端口的协商问题，导致了大量CRC错误。
最后，验证IP地址和路由。虽然这不直接是链路状态，但一个没有IP地址或者路由不通的接口，即便链路和状态都显示正常，也无法进行有效的网络通信。
ip addr show eth0
和
ip route show
是这里的主要工具。在我看来，一个“正常工作”的接口，不仅仅是物理连接和系统状态正常，它还得能正确地参与到网络通信中去。
ethtool命令在诊断网络问题时有哪些高级用法？
ethtool
远不止查看速率那么简单，它在网络诊断方面简直是个瑞士军刀。
一个我经常用来深入排查物理层问题的用法是
ethtool -S <接口名>
。这个命令会显示网卡驱动层面更详细的统计信息，比如各种类型的错误包计数、中断次数、缓冲区溢出等等。
ethtool -S eth0
输出会非常详细，像
rx_packets
、
tx_packets
、
rx_errors
、
tx_dropped
、
tx_carrier_errors
等。如果看到
rx_crc_errors
或者
rx_missed_errors
之类的计数在快速增加，那基本上可以确定是物理链路质量差、网线问题，甚至是交换机端口配置不匹配导致的。我曾用这个命令定位过一个看似随机的网络中断问题，最终发现是某个特定类型的错误计数异常增长，指向了网卡驱动和特定交换机芯片组的兼容性问题。
另一个非常实用的功能是控制网卡LED灯：
ethtool -p <接口名> [超时秒数]
。当你在一堆服务器中，不知道哪根网线连着哪台机器时，这个命令简直是救星。
ethtool -p eth0 10
这会让
eth0
对应的网卡指示灯闪烁10秒，让你在机柜里能快速找到对应的物理端口。这比跟着网线一根一根捋要高效多了，尤其是在线缆管理不那么规范的环境下。
修改网卡协商参数也是
ethtool
的一个高级（但需谨慎使用）功能。比如：
ethtool -s eth0 speed 100 duplex full autoneg off
这个命令可以强制网卡以100Mbps全双工模式工作，并关闭自动协商。通常，我们都建议开启自动协商（
autoneg on
），因为现代网络设备都能很好地进行协商。但有时候，在连接老旧设备或者遇到自动协商失败导致链路不稳定时，手动强制设置能起到奇效。我曾经在连接一台老旧的工业交换机时，就是通过强制设置网卡参数才让链路稳定下来的。不过，一旦网络环境恢复正常，记得改回来，或者让它自动协商，否则可能会引入新的兼容性问题。
ethtool -i <接口名>
可以显示网卡的驱动信息，包括驱动名称、版本、固件版本等。这在排查驱动兼容性问题或者需要升级驱动时非常有用。
网络链路速率与实际吞吐量不符，可能是什么原因？
这是一个非常常见的困惑，也是很多网络新手容易混淆的地方。链路速率（比如
ethtool
显示1000Mb/s）和实际的吞吐量（比如你用
scp
传文件发现只有几十MB/s）是两个概念，它们之间存在诸多影响因素。
首先，单位的差异。链路速率通常以
Mb/s
（兆比特每秒）表示，而文件传输速度常用
Mb/s
（兆字节每秒）。1字节等于8比特，所以一个1000Mb/s的链路理论上最大吞吐量是125MB/s。很多人忽略了这个8倍的转换关系，导致误解。
接着，协议开销。TCP/IP协议栈在传输数据时，会增加各种头部信息（以太网帧头、IP头、TCP头等），这些都会占用链路带宽，但不是有效数据。此外，还有TCP的握手、确认、流量控制等机制，都会消耗一部分带宽。所以，你永远不可能达到理论上的100%链路利用率。
然后，系统资源瓶颈。这在高性能网络场景中尤为突出。
- CPU限制：数据包的处理、加密解密、TCP/IP协议栈的计算都需要CPU资源。如果CPU负载过高，可能无法及时处理数据，导致吞吐量下降。
- 磁盘I/O：如果你正在进行文件传输，那么源端