Tuần trước team mình xử lý một vụ khó chịu: ứng dụng chạy chậm bất thường, dev kêu database timeout, DBA bảo query nhanh lắm. Sau 2 tiếng ngồi đào bới log và profiling, thủ phạm hóa ra là băng thông giữa app server và DB server bị nghẽn về chiều tối. Cái đáng tiếc là nếu mình chạy iperf3 kiểm tra từ đầu, đã tìm ra trong 5 phút.
Từ hôm đó, iperf3 trở thành bước kiểm tra đầu tiên của mình mỗi khi nghi ngờ mạng có vấn đề. Bài này mình sẽ đi vào so sánh các tool đo network, và cách dùng iperf3 đúng cách cho những tình huống thực tế nhất.
Các tool đo hiệu suất mạng — cái nào dùng khi nào?
speedtest-cli — Chỉ đo tốc độ kết nối Internet
speedtest-cli kết nối đến server của Ookla để đo download/upload speed. Hữu ích khi bạn cần kiểm tra ISP có deliver đúng gói cước không, nhưng hoàn toàn vô dụng khi cần đo bandwidth nội bộ giữa hai server trong cùng datacenter hoặc cùng VPC. Nó đo qua Internet, không phải qua mạng nội bộ của bạn.
netperf — Cổ điển nhưng đang lỗi thời
netperf ra đời từ thập niên 90, hỗ trợ đo TCP/UDP, có nhiều metric chi tiết. Vấn đề là project này ít được maintain, documentation cũ, cú pháp khó nhớ hơn. Một số distro hiện đại không có sẵn trong repo chính thức. Mình dùng thử vài lần nhưng không thấy lý do gì để dùng nó thay cho iperf3.
iperf3 — Lựa chọn tiêu chuẩn cho DevOps
Cái mình tin dùng nhất là iperf3, được maintain bởi ESnet — mạng nghiên cứu của Bộ Năng lượng Mỹ, nên code khá solid. TCP lẫn UDP, parallel streams, reverse mode, JSON output cho automation — đủ hết. Có sẵn trong repo của hầu hết distro. Cài xong dùng luôn, không cần config gì.
iperf3: điểm mạnh và những thứ cần biết trước
Ưu điểm:
- Đo băng thông thực tế point-to-point giữa hai server — không phụ thuộc Internet
- UDP mode để phát hiện packet loss và jitter — TCP sẽ tự điều chỉnh tốc độ, che giấu vấn đề
- Parallel streams mô phỏng nhiều connection đồng thời như traffic thực tế
- JSON output để tích hợp vào monitoring script
- Reverse mode kiểm tra cả hai chiều bandwidth
- Nhẹ, không cần config phức tạp
Hạn chế cần biết:
- Cần cài và chạy trên cả hai đầu (server + client)
- Port 5201 cần được mở trên firewall phía server
- Không đo được tốc độ kết nối Internet ra bên ngoài
- iperf3 không backward-compatible với iperf2 (khác protocol hoàn toàn)
Chọn tool phù hợp với từng tình huống
Trước khi cài gì, xác định xem bạn đang cần đo gì:
- ISP có deliver đúng tốc độ cam kết? → speedtest-cli
- Bandwidth giữa hai server nội bộ? → iperf3 TCP mode
- Có packet loss hoặc jitter trong mạng không? → iperf3 UDP mode
- Mạng InfiniBand/RDMA (HPC environment)? → qperf
- Cần test nhanh không cần cài tool? →
curl+ file download từ server nội bộ (kém chính xác hơn nhưng tiện)
Cài đặt iperf3 trên Linux
Hầu hết distro có sẵn iperf3 trong repo chính thức, cài xong là dùng được:
# Ubuntu / Debian
sudo apt update && sudo apt install iperf3
# CentOS / RHEL / Rocky Linux
sudo dnf install iperf3
# Arch Linux
sudo pacman -S iperf3
Kiểm tra version sau khi cài:
iperf3 --version
# iperf 3.14 (cJSON 1.7.15)
Sử dụng cơ bản — Server và Client
Mô hình đơn giản: một đầu chạy server mode để lắng nghe kết nối, đầu còn lại là client khởi tạo test. Không cần daemon chạy ngầm — start server khi cần, xong thì tắt.
Trên máy server (máy nhận kết nối):
# Chạy foreground, lắng nghe port 5201
iperf3 -s
# Chạy nền và ghi log
iperf3 -s -D --logfile /var/log/iperf3.log
Trên máy client (máy khởi tạo test):
# Test cơ bản: TCP, 10 giây, 1 stream
iperf3 -c 192.168.1.100
# Test dài hơn — 30 giây
iperf3 -c 192.168.1.100 -t 30
# Truyền đúng 5GB rồi dừng (thay vì dùng thời gian)
iperf3 -c 192.168.1.100 -n 5G
Output mẫu của một link Gigabit khỏe mạnh:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 940 Mbits/sec
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec
...
[ 5] 0.00-10.01 sec 1.09 GBytes 935 Mbits/sec sender
[ 5] 0.00-10.01 sec 1.09 GBytes 934 Mbits/sec receiver
Các option nâng cao thường dùng
Parallel streams — Mô phỏng traffic thực tế
Mặc định iperf3 chỉ dùng 1 TCP stream. Trong thực tế, ứng dụng mở nhiều connection đồng thời. Dùng -P để test với nhiều stream:
# 4 stream song song
iperf3 -c 192.168.1.100 -P 4
Thường thấy bandwidth tổng cao hơn khi dùng multiple streams, vì TCP window scaling hoạt động hiệu quả hơn trên các link có latency cao.
Reverse mode — Đo bandwidth chiều ngược lại
# Server gửi data về Client (download từ góc nhìn client)
iperf3 -c 192.168.1.100 -R
JSON output — Tích hợp vào automation
iperf3 -c 192.168.1.100 -J > /tmp/result.json
# Lấy bitrate từ JSON
iperf3 -c 192.168.1.100 -J | python3 -c \
"import sys,json; d=json.load(sys.stdin); print(d['end']['sum_received']['bits_per_second']/1e6, 'Mbps')"
UDP mode — Phát hiện packet loss và jitter
TCP giỏi che giấu vấn đề mạng. Khi có packet loss, nó tự retransmit và throttle bandwidth xuống — bạn chỉ thấy throughput thấp, không rõ nguyên nhân. UDP không có cơ chế đó: mất gói là báo thẳng vào output. Đây là mode bắt buộc khi muốn đo packet loss và jitter thực sự.
# Test UDP với target bandwidth 1Gbps
iperf3 -c 192.168.1.100 -u -b 1G
# Test với bandwidth 100Mbps (cho link 1G để tránh overload)
iperf3 -c 192.168.1.100 -u -b 100M -t 30
Output UDP có thêm hai cột quan trọng:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 1.16 GBytes 998 Mbps 0.052 ms 847/885802 (0.096%)
- Jitter: biến động độ trễ (ms). Lý tưởng <1ms trong LAN, <10ms qua WAN
- Lost/Total: tỉ lệ mất gói. Trong LAN khỏe mạnh phải là 0%. Cần điều tra ngay nếu >0.1%
Chẩn đoán intermittent packet loss — Kinh nghiệm thực tế
Lần debug network issue khó nhất của mình là khi intermittent packet loss chỉ xảy ra vào giờ cao điểm (9-11h sáng và 3-5h chiều). Mình chạy iperf3 kiểm tra buổi tối — hoàn toàn bình thường, 0% packet loss, 940 Mbps. Sáng hôm sau chạy lại — vẫn ổn.
Sau đó mình viết script chạy liên tục và ghi log để bắt đúng thời điểm:
#!/bin/bash
# Chạy iperf3 UDP test mỗi 5 phút, ghi log
SERVER="192.168.1.100"
LOGFILE="/tmp/iperf3_monitor.log"
for i in $(seq 1 288); do # 288 lần = 24 giờ
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
RESULT=$(iperf3 -c $SERVER -u -b 1G -t 30 -J 2>/dev/null)
LOSS=$(echo $RESULT | python3 -c \
"import sys,json; d=json.load(sys.stdin); print(d['end']['sum']['lost_percent'])" 2>/dev/null)
echo "$TIMESTAMP packet_loss=$LOSS%" >> $LOGFILE
sleep 270 # 270 giây nghỉ + 30 giây test = 300 giây (5 phút)
done
Kết quả: vào giờ cao điểm packet loss lên đến 2.3%, còn ngoài giờ là 0%. Truy ra nguyên nhân là một SFP module trên switch uplink bị lỗi, chịu tải kém khi traffic tăng cao. Thay SFP mới là xong.
Mở firewall cho iperf3
Trước khi test, nhớ mở port 5201 trên server:
# UFW (Ubuntu/Debian)
sudo ufw allow 5201/tcp
sudo ufw allow 5201/udp
# firewalld (CentOS/RHEL/Rocky)
sudo firewall-cmd --permanent --add-port=5201/tcp
sudo firewall-cmd --permanent --add-port=5201/udp
sudo firewall-cmd --reload
Nếu cần dùng port tùy chỉnh (ví dụ chạy nhiều instance hoặc tránh conflict):
# Server lắng nghe port 9001
iperf3 -s -p 9001
# Client kết nối port 9001
iperf3 -c 192.168.1.100 -p 9001
Checklist kiểm tra nhanh khi nghi ngờ vấn đề network
- Chạy TCP test cơ bản — kiểm tra bandwidth tổng thể đạt kỳ vọng chưa
- Chạy UDP test với bandwidth bằng 80% link capacity — kiểm tra packet loss và jitter
- Chạy với
-P 4(parallel streams) — một số vấn đề chỉ xuất hiện khi có nhiều connection - Chạy reverse mode
-R— bandwidth hai chiều có thể khác nhau nếu có asymmetric routing - Nếu vấn đề intermittent, dùng script monitor chạy theo thời gian như ví dụ trên
iperf3 kết hợp với ss/netstat là đủ để khoanh vùng phần lớn network issue trên Linux. Bandwidth bottleneck, packet loss ẩn, asymmetric routing — mỗi loại vấn đề có cách test riêng. Quan trọng không phải biết hết mọi flag, mà là biết đặt đúng câu hỏi trước khi chạy.

