hyper-v ubuntu虚拟机测试网卡并发，含sar tcpdump抓包

在 Hyper-V 中运行的 Ubuntu 18.04 虚拟机里，没有直接命令能“检测网卡当时的并发量”或“并发上限”，因为“并发量”在网络领域通常不是一个标准指标。但我们可以从以下几个角度理解你的需求，并提供对应的监控和分析方法：

✅ 一、澄清概念：什么是“网卡并发量”？

在网络上下文中，“并发”一般指：

同时建立的 TCP/UDP 连接数（如 netstat 或 ss 统计的连接数）
单位时间内的数据吞吐量（如 Mbps、pps）
网卡队列/中断处理能力（底层性能）

而“并发上限”可能指：

系统最大允许的 socket 连接数（受 ulimit、net.core.somaxconn 等限制）
网卡或虚拟交换机的带宽上限（如 1 Gbps）
Hyper-V 虚拟网卡的性能瓶颈

✅ 二、常用命令与工具（Ubuntu 18.04）

1. 查看当前网络连接数（模拟“并发连接”）

# 查看所有 TCP 连接数
ss -t | wc -l

# 查看 ESTABLISHED 状态的连接数（更接近“活跃并发”）
ss -t state established | wc -l

# 按进程统计连接数
ss -tulpn

⚠️ 注意：这反映的是应用层连接数，不是网卡本身的“并发”。

2. 实时监控网络带宽（吞吐量）

使用 iftop、nethogs、bmon 等工具：

# 安装 iftop（需 root）
sudo apt update && sudo apt install iftop

# 实时查看 eth0 的流量（按连接显示）
sudo iftop -i eth0

输出示例：

192.168.1.100 => 10.0.0.50    8.2Mb  12Mb  9.1Mb

→ 表示当前每秒收发速率（近似“瞬时并发负载”）

3. 查看网卡理论带宽上限

Ubuntu 虚拟机中的网卡通常是 hyperv_netvsc 驱动（Hyper-V 虚拟网卡）：

# 查看网卡速率（注意：虚拟网卡可能显示为 "unknown" 或 10000Mb/s）
ethtool eth0 | grep Speed

# 如果 ethtool 未安装：
sudo apt install ethtool

💡 在 Hyper-V 中，虚拟网卡速率由 虚拟交换机配置 和 主机物理网卡 决定，通常可达 10 Gbps（逻辑值），实际受限于主机 I/O。

4. 查看系统网络连接限制（“并发上限”相关参数）

# 最大监听队列长度（影响 accept() 并发）
cat /proc/sys/net/core/somaxconn

# 最大跟踪的连接数（netfilter）
cat /proc/sys/net/netfilter/nf_conntrack_max

# 当前已跟踪连接数
cat /proc/sys/net/netfilter/nf_conntrack_count

若 nf_conntrack_count 接近 nf_conntrack_max，说明连接数已达系统上限。

5. 压力测试网卡极限（主动探测上限）

使用 iperf3 测试实际吞吐能力：

# 在另一台机器运行服务端
iperf3 -s

# 在 Ubuntu 虚拟机运行客户端
iperf3 -c <server_ip> -t 30 -P 8

可测出 实际 TCP/UDP 吞吐上限（Mbps）和并发流性能。

✅ 三、Hyper-V 特别注意事项

集成服务（Integration Services）必须启用
确保 Ubuntu 安装了 linux-virtual 内核或启用了 Hyper-V 集成：
```
lsmod | grep hv_
```
应看到 hv_netvsc、hv_storvsc 等模块。
虚拟交换机类型影响性能
- 外部虚拟交换机：性能最佳（直通物理网卡）
- 内部/NAT：有额外开销

关闭不必要的功能提升性能
在 Ubuntu 中可尝试：

# 关闭 GRO（Generic Receive Offload）有时可提升小包性能
sudo ethtool -K eth0 gro off

✅ 总结：如何回答你的问题？

你想知道的	实际可用命令/方法
当前“并发连接数”	`ss -t state established \| wc -l`
网卡实时流量（近似负载）	`iftop -i eth0`
系统连接数上限	`cat /proc/sys/net/netfilter/nf_conntrack_max`
网卡理论带宽	`ethtool eth0`（可能不准确）
实际吞吐上限	`iperf3` 压力测试

📌 结论：没有单一命令能直接告诉你“网卡并发量”，但通过组合上述工具，你可以全面评估网络负载、连接数和性能瓶颈。

如需进一步分析（如丢包、重传），可使用 sar -n DEV 1（来自 sysstat 包）或 tcpdump 抓包分析。

当然可以！以下是针对 Ubuntu 18.04 系统，用于深入分析网络性能问题（如丢包、重传、吞吐瓶颈）的实用命令，特别适用于你当前在 Hyper-V 虚拟机中排查 iperf3 异常的场景。

✅ 一、使用 `sar` 监控网卡实时流量与错误（来自 `sysstat`）

1. 安装 sysstat（如未安装）

sudo apt update
sudo apt install sysstat

⚠️ 注意：Ubuntu 默认可能禁用 sysstat 数据收集。
编辑配置文件启用：
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl restart sysstat

2. 实时监控网卡统计（每秒刷新）

# 监控所有网卡，每1秒输出一次
sar -n DEV 1

# 只监控 eth0
sar -n DEV 1 | grep eth0

🔍 关注字段含义：

字段	说明
`rxpck/s`	每秒接收的数据包数
`txpck/s`	每秒发送的数据包数
`rxkB/s`	每秒接收的千字节数（≈带宽）
`txkB/s`	每秒发送的千字节数
`rxerr/s`	每秒接收错误包数（关键！）
`txerr/s`	每秒发送错误包数（关键！）
`rxdrop/s`	接收丢包数（因缓冲区满等）
`txdrop/s`	发送丢包数

✅ 如果 rxerr/s 或 rxdrop/s > 0，说明网卡或驱动层存在丢包！

✅ 二、使用 `tcpdump` 抓包分析 TCP 行为（丢包、重传、窗口等）

1. 基础抓包（保存到文件）

# 抓取与 10.2.2.227 的通信，保存为 pcap 文件
sudo tcpdump -i eth0 host 10.2.2.227 -w iperf_test.pcap

在另一个终端运行 iperf3 -c 10.2.2.227 -P 8 -t 10，结束后按 Ctrl+C 停止抓包。

2. 实时分析重传和丢包（命令行快速诊断）

# 显示 TCP 重传（Retransmission）
sudo tcpdump -i eth0 host 10.2.2.227 -nn -q | grep -i "retrans"

# 或更精确地过滤 dup ack 和 fast retransmit
sudo tcpdump -i eth0 host 10.2.2.227 -nn -q 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0 or tcp[13] & 8 != 0'

3. 使用 `tshark`（Wireshark 命令行版）分析（推荐）

先安装：

sudo apt install tshark

然后分析重传比例：

# 统计 TCP 重传包数量
tshark -r iperf_test.pcap -Y "tcp.analysis.retransmission" | wc -l

# 查看 TCP Window Full（接收方缓冲区满）
tshark -r iperf_test.pcap -Y "tcp.analysis.window_full"

# 查看重复 ACK（暗示丢包）
tshark -r iperf_test.pcap -Y "tcp.analysis.duplicate_ack"

✅ 三、查看内核 TCP 统计（高级诊断）

1. 使用 `ss` 查看连接状态和重传

# 查看所有 TCP 连接的重传次数（重点看 rto、retrnsmt）
ss -i state established

# 示例输出片段：
# cubic rto:204 rtt:4/2 cwnd:10 send 1.2Mbps rcv_space:14600
# → 如果 rto 很大或 retrnsmt > 0，说明有重传

2. 查看全局 TCP 错误统计

# 显示 TCP 重传、丢包等累计计数器
cat /proc/net/netstat | grep TcpExt

# 关键字段（第二行对应值）：
# TCPLostRetransmit, TCPFastRetrans, TCPSlowStartRetrans, TCPRenoRecovery, TCPSACKRecovery
# TCPTimeouts, TCPLossProbes, TCPRenoFailures

例如：

awk '/TcpExt/ {getline; print}' /proc/net/netstat

输出类似：

TcpExt: ... 0 5 0 0 12 ...

→ 第 2 个数字是 TCPFastRetrans（快速重传次数），非零即有问题。

✅ 四、综合诊断建议（针对你的场景）

由于你 sender 是 Ubuntu，receiver 是 Windows（推测），且 telnet 通但 iperf3 数据收不到：

📌 推荐操作流程：

在 Ubuntu sender 端运行：

# 开启 sar 监控
sar -n DEV 1 > sar_log.txt &

# 同时抓包
sudo tcpdump -i eth0 host 10.2.2.227 -w debug.pcap &

# 运行 iperf3
iperf3 -c 10.2.2.227 -P 8 -t 10

# 停止后台任务
killall sar tcpdump

分析结果：
- 查看 sar_log.txt：是否有 rxerr/s 或 rxdrop/s？
- 用 tshark 分析 debug.pcap：
```
tshark -r debug.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.time -e ip.src -e tcp.seq
```
- 如果 只有 sender 发包，receiver 无 ACK → 数据被中间设备丢弃（Windows 防火墙）。
- 如果 有大量重传 → 网络拥塞或接收端处理慢。

✅ 五、附加：快速检查驱动和中断（Hyper-V 特有）

# 确认使用的是 hv_netvsc 驱动
ethtool -i eth0 | grep driver

# 查看中断是否均衡（多 vCPU 时）
cat /proc/interrupts | grep eth0

在 Hyper-V 中，若虚拟机分配了多个 vCPU，但网络中断集中在 CPU0，可能导致瓶颈。

总结：关键命令速查表

目的	命令
实时带宽+错误	`sar -n DEV 1`
抓包保存	`tcpdump -i eth0 host 10.2.2.227 -w test.pcap`
检查重传	`tshark -r test.pcap -Y "tcp.analysis.retransmission"`
查看连接重传	`ss -i`
全局 TCP 错误	`cat /proc/net/netstat \| grep TcpExt`

通过以上工具组合，你可以精准定位是 丢包、重传、接收端不响应、还是驱动瓶颈。
结合你之前的现象（receiver 收 0 字节），最可能仍是 Windows 防火墙拦截，但 tcpdump 能提供决定性证据。

如需进一步分析抓包文件，可将 .pcap 导出并在 Wireshark GUI 中打开，查看“Statistics → TCP Stream Graphs” 更直观。

你当前想分析 昨天（2026年1月14日）18:00–19:00 的网络设备（-n DEV）性能数据，但遇到了 sar -n DEV 1 -f sar14 报错：

Invalid system activity file: sar14

这是因为 sar 命令读取的是 saXX 文件，而不是 sarXX 文件。

✅ 正确理解 sysstat 文件命名规则

在 Ubuntu/Debian 系统中：

saDD：二进制格式的原始系统活动数据文件（sar 命令读这个）
- 例如：sa14 → 代表 14 日的数据
sarDD：通常是 sar 命令输出的文本日志（供人阅读），不能被 sar -f 直接解析

📌 所以你应该使用 sa14 来分析 1月14日 的数据。

✅ 正确命令：分析 1月14日 18:00–19:00 的网卡流量

# 查看 1月14日 全天的网卡统计（每10分钟一条，默认采集间隔）
sar -n DEV -f /var/log/sysstat/sa14

# 只查看 18:00 到 19:00 之间的数据（注意：时间格式为 HH:MM:SS）
sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

⚠️ 注意：

-s 和 -e 指定起止时间（24小时制）

如果系统 sysstat 配置的采集间隔是 10分钟（默认），那么你只能看到 18:00、18:10、18:20……18:50 这些时间点的数据，不会有秒级精度。

若需 1 秒粒度，必须当时用 sar -n DEV 1 实时记录（你没做，所以无法回溯秒级数据）。

🔍 示例输出解读

运行后你会看到类似：

06:10:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
06:20:01 PM        eth0     12000      8000     15000      9000         0         0         0      12.3
...
06:50:01 PM        eth0     50000     48000     62000     60000         0         0         0      48.7

重点关注：

rxkB/s / txkB/s：接收/发送带宽（KB/s）
%ifutil：网卡利用率（部分驱动支持）
如果 rxerr/s 或 txerr/s 出现（需加 -n EDEV），说明有错误

✅ 补充：查看错误和丢包（如果需要）

# 查看 1月14日 18-19点的网卡错误（如 CRC、丢包）
sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

字段说明：

rxerr/s：接收错误包/秒
txerr/s：发送错误包/秒
coll/s：冲突（半双工才有）
rxdrop/s：因缓冲区满丢弃的接收包
txdrop/s：发送丢包

❓ 为什么没有 `sa15` 完整文件？

你看到：

-rw-r--r-- 1 root root 485428 Jan 15 16:45 sa15

这是因为 今天（1月15日）还没结束，sa15 是当天正在写入的临时文件。
通常在 每日 23:59 由 sysstat 的 cron 任务 finalize 成完整文件。

✅ 所以分析历史数据请用 sa01 到 sa14。

✅ 总结：你要的命令

# 分析 2026-01-14 18:00–19:00 网卡流量
sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

# 如需错误统计
sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

💡 提示：如果输出为空，说明那段时间没有采集到数据（可能服务未运行，或采集间隔跳过了该时段）。

如有其他需求（如分析 CPU、内存同期负载），也可用：

sar -u -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14  # CPU
sar -r -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14  # 内存

希望这能帮你精准定位昨天的网络性能状况！