应用程序级别的最大吞吐量略微取决于使用的传输协议 - UDP 增加了 8 字节的报头开销，TCP 增加了 20 字节。IPv4 数据包使用 20 个字节，以太网帧使用 18 个字节。在以太网线上，有 20 个字节的额外开销。

一个最大大小的以太网帧可以传输 1500 字节，包括 IP 和 TCP 开销。这也是 IP 数据包 (MTU) 的最大大小。加上帧和物理层开销，1538 字节正在通过网络传输。

总而言之，您将获得 1460 字节的用户数据 (TCP)，总大小为 1538 字节。在千兆位速度下，这是 81.274 帧/秒，总 TCP 吞吐量为 118.6 MB/秒或 119.6 MB/秒，使用 UDP（1472 字节用户数据）。

虽然这些是您在物理上可以达到的最大速度，但设计良好且具有适当应用程序支持的基础架构实际上可以达到这些速度。

对于您的问题：不，3 MB/s 的最大吞吐量对于千兆速度网络来说是不正常的。根据上面的计算，您应该可以轻松地运行 30 次。

您应该尝试诊断问题：

• 尽可能靠近生产者接收数据
• 将虚拟数据直接输入消费者
• 在整个数据路径或部分数据路径上运行性能测试（例如使用 iperf）
• 检查途中的交换机和路由器是否有错误迹象（丢包、FCS 错误）或拥塞（缓冲区负载、CPU 负载）
• 排除双工不匹配（增加 FDX 端的 FCS 错误，HDX 端的（后期）冲突）

1Gbs 是每秒 1 Giga比特，而 3MB/s 是每秒3 兆字节。（字节用大写 B 标注，位用小写 b 标注）

由于 1 字节 = 8 位，因此您可以在 1000Mb/s 链路上实现 24Mb/s 的速度。这很可怜。

当应用程序在 2 台机器之间传输数据时，这些数据会被分块成小块，每个块都会接收将块可靠地传输到预期目的地所需的附加信息。（想想你放一封信的信封，所以实际邮件比信重）。

由于这种开销，从应用程序的角度来看，1Gbs 链路上的实际带宽更接近 800 / 850 Mbs。

24Mbs 比你应该得到的要慢得多。

罪魁祸首很可能在消费者或生产者机器上。您应该检查 CPU 使用率、磁盘子系统 I/O 速率等...

但您也可以检查交换机上的日志和接口计数器是否有任何异常行为。

要检查服务器或网络是否有故障，您可以尝试在两台机器上运行类似iperf的工具（一台作为服务器，另一台作为客户端）。

在得知以太网“Mbit/sec”速度为 1,000,000 位之前，我在网络中工作了很长时间；而显然我们通常认为 2^20 表示字节数。多年来，我的计算结果都减少了约 5%！

另外：数据字节与 TCP 标头的比例变化很大；先前的答案省略了段大小和碎片数据包的提及。虽然我当然不同意一般结论。

我会从网络嗅探器开始查看数据包之间的滞后：服务器是否及时响应？您的数据包是否充满了 1 字节的段/数据报？

虽然之前的答案说 B 是字节，b 是位，但很多人并不那么细致，而且很多人感到困惑：我个人总是写 bit/sec 和 byte/sec 是为了明确。

让我们知道你是怎么上去的。

乔纳森。

如果您仍然没有使用至少 CAT5e（如果不是 CAT6）或更高，那么您将陷入旧以太网电缆设计的物理限制；也可能是旧的/损坏的电缆。天堂禁止您使用 sub-CAT5，这将导致可怕的吞吐速度。我有 CAT5e，并且单程上下最大速度为 100Mbps。这至少是你声称测量的两倍。

还有其他因素会影响速度，例如是否从硬盘驱动器（而不是 SSD）读取数据。特别是如果硬盘驱动器上有文件碎片，它会减慢很多速度。如果多台机器正在向服务器发出 HDD 请求，这可能会增加瓶颈。一种可能的 [但成本高昂] 解决方案：NAS 仅使用连接到 10G 交换机的 SSD，光纤线路为 1Gb+（FibreChannel 的奖励积分）。如果使用通过以太网电缆连接的 Cisco 交换机，您可能会在需要多条并行以太网电缆的交换机之间进行 EtherChannel 设置，这是假设您尚未通过光纤 (SFP/SFP+) 连接交换机。慢速还取决于网络拓扑以及它如何平衡网络流量负载。

恕我直言，经过认证的网络专业人员应该能够很容易地弄清楚这一点。我只是一个过期的 CCENT，所以这一切都从近十年前的记忆中消失了。