我有两台机器，一台Mac和一台Linux，在同一个本地网络中。我试着用其中一个作为HTTP服务器来传输文件，结果发现下载速度因服务器而异。如果我使用Mac作为服务器，下载速度大约是3MB/s，但反过来，它大约是12MB/s。然后我用iperf3测试了它们之间的速度，得到了类似的结果：
当Mac是服务器，Linux是客户端时：
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 28.7 MBytes 2942 KBytes/sec 1905 sender
[ 5] 0.00-10.00 sec 28.4 MBytes 2913 KBytes/sec receiver
当Linux是服务器，Mac是客户端时：
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 162 MBytes 16572 KBytes/sec sender
[ 4] 0.00-10.00 sec 161 MBytes 16526 KBytes/sec receiver
我请一个朋友帮我做下载测试，他告诉我，他的两台Mac电脑的速度都在1MB/s左右，这与路由器的容量相去甚远。这怎么会发生？
这不会是一个很大的答案，但它可能足够长，无法放入评论中。
您对"；伪TCP报头长度"；非常有趣；我以前从未在拍摄中看到过它，所以我想看看它到底意味着什么。在这里，您可以看到，这意味着wireshark TCP协议解析器无法理解该段，因为TCP标头长度小于最小TCP标头长度。
看来你有一个无效的TCP段。我只知道两个原因是它在某种程度上构造错误(即错误或入侵尝试(或已损坏。
在处理原始套接字时，我确实创建了大量无效的段，我也看到了大量不符合标准的伪造段，但在您的情况下似乎不太可能出现这种情况。
因此，根据我的经验，它似乎很可能已经被某种方式破坏了。尽管如果它是捕获中传输的数据包，那么实际上您发送的是一个无效的段。所以在接下来的内容中，我假设这是一个收到的片段。
那么，它在哪里被破坏了呢？第一个谜团是你在一次拍摄中看到了它。如果它在网络中已损坏，则帧检查序列(FCS，CRC(不应匹配，并且应该丢弃它。
但是，可以将NIC/驱动程序配置为交付具有无效FCS的分段。在linux上，你可以用ethtool检查/配置这些设置，相关参数是rx-fcs和rx-all(对不起，我不知道如何在Mac上做到这一点(。如果这两者都是"；off；你的NIC/驱动程序不应该向你发送带有无效FCS的分段，因此它们不会出现在捕获中。
由于您在捕获中看到了TCP标头长度无效的段，并且假设您的NIC/驱动程序配置为丢弃具有无效FCS的段，则您的NIC在导线上看到了一个有效段，并且该段在发送器计算FCS之前已损坏(通常在NIC中完成(，或者在接收NIC验证FCS之后已损坏。
在这两种情况下，在CPU存储器和NIC之间都存在通过总线(例如PCI-e(的DMA传输。我猜是硬件问题导致了这里的腐败，但我对这个猜测不太有信心，因为我没有什么信息可以继续
您可以尝试在两端获取捕获，以比较传输的内容和接收的内容(尤其是在TCP标头长度无效的段的情况下(。您可以使用IP标头中的ID字段来匹配捕获中的分段(假设它也没有损坏(。
祝你好运！