网络诊断与测速：ping/mtr/iperf3/curl

国内从 NCBI/ENA 下载 SRA 数据时，常见问题包括：带宽不足、防火墙限速、DNS 解析慢、磁盘写满。本文覆盖网络诊断全栈工具链：ping/mtr 路由追踪、iperf3 带宽测试、curl 下载分析、DNS 排查和代理配置。

实测环境：Debian 12，千兆教育网接入。

1. 连通性诊断——从ping开始但不只ping#

1.1 ping——第一把手术刀#

1
# 基础连通性
2
ping -c 10 ftp.ncbi.nlm.nih.gov
3

4
# 看延迟波动（-i 间隔，-c 次数）
5
ping -i 0.2 -c 100 ftp.sra.ebi.ac.uk
6

7
# 大包测试（看MTU/分片问题）
8
ping -s 1400 -c 10 ftp.ncbi.nlm.nih.gov

解读：

指标	正常	需关注	严重
延迟（RTT）	<50ms(国内) <300ms(国际)	300-500ms	>500ms 或剧烈抖动
丢包率	0%	1-2%	>5%
抖动（mdev）	<10ms	10-50ms	>50ms

但要注意：ping 通 ≠ 带宽够。ICMP 包只有几十字节，和下载 50GB 完全不是一回事。而且很多服务器根本不响应 ping（禁了 ICMP），ping 不通不代表网络有问题。

1.2 mtr——ping + traceroute 的合体#

1
sudo apt install mtr -y
2

3
# 交互式实时追踪
4
mtr ftp.ncbi.nlm.nih.gov
5

6
# 报告模式（发送100个包然后输出）
7
mtr -r -c 100 ftp.ncbi.nlm.nih.gov
8

9
# 不解析主机名（更快）
10
mtr -r -n -c 100 130.14.29.30

mtr 输出解读——每跳一个路由器，关键看：

1
HOST                           Loss%   Snt   Last   Avg  Best  Wrst StDev
2
1. 10.0.0.1                    0.0%   100    0.3   0.5   0.2   2.1   0.3
3
2. 192.168.1.1                 0.0%   100    1.2   1.5   0.8   5.3   0.8
4
3. ???                         100.0% 100    0.0   0.0   0.0   0.0   0.0
5
4. 202.112.x.x                 0.0%   100    5.2   5.8   4.1  12.3   1.2
6
...
7
12. be-101-pe02.ashburn.va     0.0%   100  215.6 220.1 210.3 260.2 12.5
8
...
9
15. ftp.ncbi.nlm.nih.gov       1.0%   100  230.1 235.2 225.3 280.1 11.2

中间某跳 100% 丢包但后面又正常：该路由器不响应 ICMP，正常现象
从某跳之后丢包率突然出现并持续到终点：这里就是瓶颈
延迟在某跳大幅跃升：跨国出口——比如从 5ms 跳到 200ms——说明到了国际网关

$RTT_{end\_to\_end} = \sum_{i=1}^{N} RTT_{hop\_i} + RTT_{ocean\_fiber}$

海洋光缆延迟约 1ms/200km（光速在光纤中约为真空的 2/3）。中美之间约 10000km，物理延迟最低约 70ms。如果 RTT > 300ms，问题不在物理而在路由/拥塞。

1.3 traceroute——备选方案#

1
# 传统traceroute（UDP，容易被墙）
2
traceroute ftp.ncbi.nlm.nih.gov
3

4
# TCP模式（更不容易被拦截，因为像正常连接）
5
traceroute -T -p 443 ftp.ncbi.nlm.nih.gov

2. 带宽测试——iperf3测真实吞吐#

2.1 内网测速#

1
sudo apt install iperf3 -y
2

3
# 服务端（在你要测的目标机器上）
4
iperf3 -s
5

6
# 客户端（在你的机器上）
7
iperf3 -c 192.168.1.100
8

9
# 多线程并行（模拟多连接下载）
10
iperf3 -c 192.168.1.100 -P 8
11

12
# 反向测试（服务端发送，测下载速度）
13
iperf3 -c 192.168.1.100 -R

典型输出：

1
[ ID] Interval           Transfer     Bitrate         Retr
2
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    0     sender
3
[  5]   0.00-10.00  sec  1.09 GBytes   935 Mbits/sec          receiver

Bitrate 接近千兆（940Mbps）= 内网没问题。如果内网只有 100Mbps，检查网线/交换机端口。

2.2 到外网的带宽测试#

1
# 用curl直接下载测试文件
2
curl -o /dev/null -w "%{speed_download}\n" \
3
    https://ftp.ncbi.nlm.nih.gov/genomes/Homo_sapiens/README
4

5
# speed_download 单位是 bytes/s，除以 1048576 得 MB/s
6

7
# 更详细的curl测速
8
curl -o /dev/null -s -w \
9
    "time_namelookup: %{time_namelookup}\n\
10
time_connect: %{time_connect}\n\
11
time_starttransfer: %{time_starttransfer}\n\
12
time_total: %{time_total}\n\
13
speed_download: %{speed_download}\n" \
14
    https://ftp.ncbi.nlm.nih.gov/genomes/Homo_sapiens/README

各时间指标的含义：

指标	含义	正常值	异常信号
`time_namelookup`	DNS解析时间	<50ms	>1s = DNS服务器慢
`time_connect`	TCP握手时间（含DNS）	<200ms	>2s = 连不上/墙了
`time_starttransfer`	首字节时间（TTFB）	<1s	>5s = 服务器慢
`time_total`	总传输时间	—	—
`speed_download`	下载速度(bytes/s)	—	—

2.3 实际吞吐量公式#

$throughput_{effective} = \min(bandwidth_{link}, \frac{BDP}{RTT}, rate_{server}, rate_{local\_disk})$

其中 BDP（带宽延迟积）:

$BDP = bandwidth \times RTT$

TCP 的拥塞控制窗口受 BDP 限制。中美之间 RTT=200ms，即使带宽是 1Gbps：

$BDP = 1Gbps \times 0.2s = 200Mb = 25MB$

单连接 TCP 最多能用 25MB 的窗口，实际吞吐受此限制。这就是为什么多线程下载（如 axel）能显著加速：

$throughput_{multi} \approx N \times \min(\frac{BDP}{RTT}, rate_{server}/N)$

3. DNS诊断——被忽略的瓶颈#

DNS 慢会导致每个连接都多等几秒。SRA 下载时频繁建立新连接，DNS 慢会被放大。

1
# 当前DNS配置
2
cat /etc/resolv.conf
3

4
# 测DNS解析速度
5
dig ftp.ncbi.nlm.nih.gov | grep "Query time"
6
# Query time: 120 msec —— 正常
7
# Query time: 3000 msec —— 有问题
8

9
# 批量测多个DNS服务器
10
for dns in 8.8.8.8 1.1.1.1 114.114.114.114 223.5.5.5; do
11
    echo -n "${dns}: "
12
    dig @${dns} ftp.ncbi.nlm.nih.gov +short +time=3 2>/dev/null || echo "TIMEOUT"
13
done
14

15
# 查看DNS缓存（systemd-resolved）
16
resolvectl statistics
17

18
# 清理DNS缓存
19
sudo resolvectl flush-caches

教育网用户常见问题：学校的 DNS 服务器解析国外域名特别慢，或者返回了错误的 IP（被劫持到缓存服务器）。解决：

1
# 在 /etc/systemd/resolved.conf 中指定上游DNS
2
[Resolve]
3
DNS=223.5.5.5 8.8.8.8
4
FallbackDNS=1.1.1.1

4. HTTP/FTPSRA下载实战#

4.1 用curl诊断下载问题#

1
# 1. 测试连接（不下载数据）
2
curl -I https://ftp.ncbi.nlm.nih.gov/
3

4
# 2. 显示详细连接过程
5
curl -v https://sra-download.ncbi.nlm.nih.gov/traces/sra00/SRR/001234/SRR12345678 2>&1 | head -50
6

7
# 3. 断点续传（-C -）
8
curl -C - -o SRR12345678.sra \
9
    https://sra-download.ncbi.nlm.nih.gov/traces/sra00/SRR/001234/SRR12345678
10

11
# 4. 限速下载（避免占满带宽影响别人）
12
curl --limit-rate 50M -o file.sra https://...

4.2 axel多线程下载#

1
sudo apt install axel -y
2

3
# 基础用法（-n 线程数）
4
axel -n 8 ftp://ftp.sra.ebi.ac.uk/vol1/srr/SRR123/SRR12345678
5

6
# 断点续传
7
axel -n 8 -a ftp://ftp.sra.ebi.ac.uk/vol1/srr/SRR123/SRR12345678
8
# -a: 简洁进度条
9

10
# 指定输出文件名
11
axel -n 16 -o SRR12345678.sra ftp://...

实测：从国内教育网下载 EBI 的 SRA，单线程 2MB/s，用 axel -n 8 后 15MB/s。提速约 7.5 倍。

4.3 速度优化检查清单#

下载速度慢时，逐个检查：

1
#!/bin/bash
2
TARGET="https://ftp.ncbi.nlm.nih.gov/genomes/Homo_sapiens/README"
3
echo "=== Speed Diagnosis ==="
4

5
# 1. DNS
6
echo "1. DNS response time:"
7
dig ftp.ncbi.nlm.nih.gov | grep "Query time"
8

9
# 2. Ping延迟
10
echo "2. Ping:"
11
ping -c 5 ftp.ncbi.nlm.nih.gov | grep "rtt"
12

13
# 3. 路由
14
echo "3. Route (last 3 hops):"
15
mtr -r -c 5 ftp.ncbi.nlm.nih.gov | tail -3
16

17
# 4. HTTP连接速度
18
echo "4. HTTP speed test:"
19
curl -o /dev/null -s -w \
20
    "   DNS: %{time_namelookup}s\n   Connect: %{time_connect}s\n   TTFB: %{time_starttransfer}s\n   Speed: %{speed_download} B/s\n" \
21
    "${TARGET}"
22

23
# 5. 磁盘写入速度
24
echo "5. Disk write speed:"
25
dd if=/dev/zero of=./test_write bs=1M count=1024 conv=fdatasync 2>&1 | \
26
    grep -o '[0-9.]* MB/s'
27
rm -f ./test_write

按这个顺序跑一遍，大多数情况下能在 30 秒内定位到瓶颈所在。

5. 特殊场景：代理和SSH隧道#

5.1 为命令行工具设置代理#

1
# HTTP/HTTPS代理
2
export http_proxy="http://proxy.university.edu:8080"
3
export https_proxy="http://proxy.university.edu:8080"
4

5
# 对所有工具生效（wget, curl, prefetch, fasterq-dump...）
6
# prefetch 和 fasterq-dump 尊重 http_proxy 环境变量
7

8
# 不需要代理的本地地址
9
export no_proxy="localhost,127.0.0.1,.local,.edu.cn"
10

11
# 测试代理
12
curl -v --proxy "${https_proxy}" https://www.ncbi.nlm.nih.gov

5.2 SSH隧道端口转发#

场景：在不能直接访问外网的集群上，通过能上网的跳板机转发：

1
# 本地端口转发：把本地 8888 端口通过跳板机转到NCBI
2
ssh -L 8888:ftp.ncbi.nlm.nih.gov:443 user@jump_host
3

4
# 然后在本地用
5
curl --resolve ftp.ncbi.nlm.nih.gov:443:127.0.0.1 https://ftp.ncbi.nlm.nih.gov/
6

7
# 动态转发（SOCKS5代理）
8
ssh -D 1080 user@jump_host
9
# 然后设置：
10
export https_proxy="socks5://127.0.0.1:1080"

5.3 生信专用下载加速策略#

1
# 策略1：EBI镜像（欧洲，对国内教育网友好）
2
# EBI的FTP通常比NCBI的快
3
wget -c ftp://ftp.sra.ebi.ac.uk/vol1/srr/SRR123/SRR12345678
4

5
# 策略2：使用aspera（如果有）
6
ascp -i /path/to/asperaweb_id_dsa.openssh \
7
     -T -l 300M -k 1 \
8
     anonftp@ftp.ncbi.nlm.nih.gov:/sra/.../SRR12345678 .
9

10
# 策略3：预取 + 本地快速提取
11
prefetch SRR12345678 --max-size 50G
12
fasterq-dump SRR12345678 --threads 16
13

14
# 策略4：使用国内镜像（如果有高校提供）
15
# 中科院基因组所、华大等有时提供SRA镜像

6. 踩坑记录#

坑1：ping得通但下载速度只有几十KB#

Ping 用的是 ICMP 协议，很多网络设备对 ICMP 不做限速，但对 TCP 大流量有限制。另外，到不同站点的路由可能完全不同——ping google.com 快不代表 NCBI 快。

1
# 用curl测试真实TCP吞吐
2
curl -o /dev/null https://ftp.ncbi.nlm.nih.gov/genomes/Homo_sapiens/README

坑2：MTU不匹配导致TCP连接失败#

症状：小文件（HTTP GET）没问题，大文件下载到某个大小就卡死。

原因：路径中有设备的 MTU 小于你的发包大小，且 ICMP Fragmentation Needed 消息被防火墙拦截了（PMTUD 黑洞）。

1
# 检查当前MTU
2
ip link show | grep mtu
3

4
# 手动降低MTU试试
5
sudo ip link set dev eth0 mtu 1400
6
# 恢复正常后再改回去：sudo ip link set dev eth0 mtu 1500

坑3：axel下载地址含特殊字符导致失败#

1
# URL中有 & ? = 时必须加引号
2
axel -n 8 "ftp://ftp.sra.ebi.ac.uk/vol1/srr/SRR123/SRR12345678?param=value"

坑4：iperf3测试速度正常但真实下载慢#

iperf3 测的是 TCP 性能（你的机器↔iperf 服务器），但真实下载还涉及：

远程服务器的带宽限制
中间路由器的拥塞策略
磁盘 I/O（下载的同时要写盘）

1
# 排查是不是磁盘瓶颈
2
# 下载到 /dev/null（纯内存/网络测试）
3
curl -o /dev/null https://...large_file...
4

5
# 如果/dev/null很快但写到磁盘慢 → 磁盘问题

坑5：`/etc/resolv.conf` 被覆盖#

症状：改完 DNS 重启后又变回去了。

Debian 上 resolv.conf 可能被 systemd-resolved 或 NetworkManager 管理：

1
# 正确姿势：修改 systemd-resolved 配置
2
sudoedit /etc/systemd/resolved.conf
3
# 添加：DNS=223.5.5.5 8.8.8.8
4
sudo systemctl restart systemd-resolved

坑6：curl下载一段时间后速度降到0#

症状：开始很快，几分钟后速度降到 0，然后又恢复。

可能是 TCP 拥塞控制算法的问题。BBR 对高延迟链路友好：

1
# 检查当前算法
2
sysctl net.ipv4.tcp_congestion_control
3

4
# 启用BBR（需要root）
5
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
6
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
7
sudo sysctl -p
8

9
# 验证
10
sysctl net.ipv4.tcp_congestion_control
11
# 输出：net.ipv4.tcp_congestion_control = bbr

坑7：prefetch 尊重 http_proxy 但 fasterq-dump 不尊重#

sra-tools 的工具行为不一致：

1
# prefetch 走代理
2
export http_proxy="http://proxy:8080"
3
prefetch SRR12345678  # ✓ 走代理
4

5
# fasterq-dump 可能不走
6
# 解决办法：先 prefetch 下载 .sra 到本地，再 fasterq-dump 本地文件
7
fasterq-dump ./SRR12345678/SRR12345678.sra  # 纯本地操作

7. 总结#

排查步骤	命令	看什么
1. DNS	`dig ftp.ncbi.nlm.nih.gov`	Query time <100ms
2. 延迟	`ping -c 10`	丢包率0%，RTT<300ms
3. 路由	`mtr -r -c 50`	定位延迟跳跃点
4. 真实速度	`curl -o /dev/null -w "%{speed_download}"`	MB/s 能接受吗
5. 并发提速	`axel -n 8`	BDP限制→多线程突破
6. 本地磁盘	`dd` 或 `curl -o /path/to/disk`	排除磁盘瓶颈

网络问题排查最重要的原则：逐层排除。不要上来就说”网好慢”——先 ping 看延迟，再 curl 看吞吐，再 iperf3 看带宽，最后查 DNS 和路由。90% 的”网慢”最后发现是 DNS 太慢、磁盘写满了、或者单线程被 BDP 限制。

本文于 2026-01-18 在 Debian 12 上实测。ping iputils-s20240117, mtr 0.95, iperf3 3.16, curl 8.11.0, axel 2.17.14。

1. 连通性诊断——从ping开始但不只ping#

1.1 ping——第一把手术刀#

1.2 mtr——ping + traceroute 的合体#

1.3 traceroute——备选方案#

2. 带宽测试——iperf3测真实吞吐#

2.1 内网测速#

2.2 到外网的带宽测试#

2.3 实际吞吐量公式#

3. DNS诊断——被忽略的瓶颈#

4. HTTP/FTPSRA下载实战#

4.1 用curl诊断下载问题#

4.2 axel多线程下载#

4.3 速度优化检查清单#

5. 特殊场景：代理和SSH隧道#

5.1 为命令行工具设置代理#

5.2 SSH隧道端口转发#

5.3 生信专用下载加速策略#

6. 踩坑记录#

坑1：ping得通但下载速度只有几十KB#

坑2：MTU不匹配导致TCP连接失败#

坑3：axel下载地址含特殊字符导致失败#

坑4：iperf3测试速度正常但真实下载慢#

坑5：`/etc/resolv.conf` 被覆盖#

坑6：curl下载一段时间后速度降到0#

坑7：prefetch 尊重 http_proxy 但 fasterq-dump 不尊重#

7. 总结#

文章分享

文章目录

网络诊断与测速：ping/mtr/iperf3/curl

1. 连通性诊断——从ping开始但不只ping#

1.1 ping——第一把手术刀#

1.2 mtr——ping + traceroute 的合体#

1.3 traceroute——备选方案#

2. 带宽测试——iperf3测真实吞吐#

2.1 内网测速#

2.2 到外网的带宽测试#

2.3 实际吞吐量公式#

3. DNS诊断——被忽略的瓶颈#

4. HTTP/FTPSRA下载实战#

4.1 用curl诊断下载问题#

4.2 axel多线程下载#

4.3 速度优化检查清单#

5. 特殊场景：代理和SSH隧道#

5.1 为命令行工具设置代理#

5.2 SSH隧道端口转发#

5.3 生信专用下载加速策略#

6. 踩坑记录#

坑1：ping得通但下载速度只有几十KB#

坑2：MTU不匹配导致TCP连接失败#

坑3：axel下载地址含特殊字符导致失败#

坑4：iperf3测试速度正常但真实下载慢#

坑5：/etc/resolv.conf 被覆盖#

坑6：curl下载一段时间后速度降到0#

坑7：prefetch 尊重 http_proxy 但 fasterq-dump 不尊重#

7. 总结#

文章分享

文章目录

坑5：`/etc/resolv.conf` 被覆盖#