Throughput là gì? Phân biệt với Bandwidth, Latency cực dễ

Throughput (thông lượng mạng) là lượng dữ liệu thực tế được truyền thành công giữa hai điểm trong một khoảng thời gian nhất định. Đây là chỉ số phản ánh trực tiếp hiệu năng mạng, đồng thời giải thích lý do vì sao băng thông cao nhưng tốc độ truyền tải vẫn có thể bị chậm. Vậy Throughput khác gì so với Bandwidth và Latency, và đâu là yếu tố quan trọng nhất cần quan tâm? Hãy cùng tìm hiểu chi tiết trong bài viết dưới đây.

1. Throughput là gì?

Throughput (thông lượng mạng) là thước đo tốc độ truyền tải dữ liệu thực tế thành công giữa hai điểm mạng trong một giây (đo bằng Mbps hoặc Gbps). Khác với băng thông lý thuyết, chỉ số này phản ánh năng lực xử lý thật của hệ thống sau khi đã trừ đi các hao hụt do tắc nghẽn, mất gói tin hay chi phí giao thức (overhead).

Để dễ hình dung, hãy tưởng tượng mạng như một đường ống nước:

• Bandwidth là độ rộng của ống (khả năng chứa tối đa)
• Latency là độ dài của ống (thời gian nước chảy từ đầu đến cuối)
• Throughput là lượng nước thực tế chảy qua trong một khoảng thời gian

Trong thực tế, Throughput luôn thấp hơn Bandwidth do ảnh hưởng của các yếu tố kỹ thuật. Ví dụ: một cổng mạng 1Gbps thường chỉ đạt khoảng 940 Mbps Throughput tối đa, do tiêu hao từ quá trình đóng gói dữ liệu như Ethernet frame, TCP/IP overhead,…

1.1. Phân loại Throughput trong hệ thống IT

Trong lĩnh vực công nghệ thông tin, Throughput được chia thành 3 phân loại chính: Network Throughput (Thông lượng mạng), Storage Throughput (Thông lượng ổ cứng) và Application Throughput (Thông lượng ứng dụng). Việc xác định đúng loại Throughput giúp quản trị viên khoanh vùng chính xác điểm nghẽn của hệ thống.

• Network Throughput (Thông lượng mạng): Tốc độ truyền tải dữ liệu thành công qua hạ tầng mạng, tính bằng Mbps hoặc Gbps. Đây là chỉ số phổ biến nhất khi nhắc đến Throughput.
• Storage Throughput / Disk Throughput (Thông lượng lưu trữ): Tốc độ đọc/ghi khối lượng dữ liệu thực tế của ổ cứng trong một giây, thường đo bằng Megabyte trên giây (MB/s). Yếu tố này cực kỳ quan trọng đối với các máy chủ Database.
• Application / System Throughput (Thông lượng ứng dụng): Năng lực xử lý yêu cầu của một phần mềm hoặc API. Chỉ số này được đo lường bằng Requests Per Second (RPS – Số truy vấn/giây) hoặc Transactions Per Second (TPS – Số giao dịch/giây).

1.2. Mối quan hệ giữa IOPS và Storage Throughput

IOPS là số lượng lệnh đọc/ghi dữ liệu trong một giây, còn Storage Throughput là tổng khối lượng dữ liệu thực tế được ổ cứng xử lý trong giây đó. Đây là hai chỉ số kỹ thuật gắn liền nhau, quyết định trực tiếp đến hiệu năng vận hành của mọi hệ thống Cloud Server.

Để dễ hiểu, nếu ví quá trình vận chuyển dữ liệu như một đội xe tải: IOPS là số lượng chuyến xe chạy được trong 1 giây, còn Throughput là tổng khối lượng hàng hóa (MB) mà các chuyến xe đó chở được.

Mối quan hệ này được quản trị viên hệ thống tính toán theo công thức chuẩn:

Kinh nghiệm thực tế cho thấy, khi thuê máy chủ ảo, việc chỉ quan tâm đến Port mạng (Network Throughput) là chưa đủ. Hệ thống bắt buộc phải sử dụng các chuẩn ổ cứng tốc độ cao như SSD NVMe Enterprise để đảm bảo cả IOPS và Storage Throughput không trở thành “nút thắt cổ chai” khi xử lý dữ liệu lớn.

1.3. Phân biệt Throughput IT và Throughput trong Sản xuất (Xuất lượng)

Throughput trong hệ thống IT đo lường lượng dữ liệu kỹ thuật số được truyền tải, trong khi Throughput (Xuất lượng) trong quản trị sản xuất là tổng số lượng thành phẩm vật lý hoàn thiện được giao cho khách hàng trong một chu kỳ nhất định.

Trong các tài liệu về Lean Manufacturing (Sản xuất tinh gọn), bạn sẽ thường bắt gặp khái niệm Throughput Time – khoảng thời gian từ khi đưa nguyên liệu vào dây chuyền cho đến khi xuất xưởng thành phẩm. Mặc dù chung tên gọi, hai khái niệm này hoàn toàn khác biệt về mặt bản chất và ngành nghề ứng dụng.

2. Goodput là gì?

Goodput là lượng dữ liệu hữu ích (payload) thực tế được ứng dụng đích nhận và xử lý thành công, không bao gồm các chi phí mào đầu (protocol overhead) hay gói tin lỗi phải truyền lại. Mức Goodput luôn có giá trị nhỏ hơn Throughput.

Ví dụ, bạn tải một file backup database 10GB từ Cloud Server. Để hoàn tất toàn bộ quá trình truyền tải này, hệ thống sẽ ghi nhận hai mức dung lượng khác nhau dựa trên cách đo lường:

• Throughput đo tổng dữ liệu đi qua đường truyền, bao gồm cả header và dữ liệu truyền lại (có thể ~10.5GB)
• Goodput chỉ tính phần dữ liệu hữu ích đến đích, tức 10GB / thời gian truyền

3. So sánh Throughput, Bandwidth và Latency

Ba chỉ số này quyết định toàn bộ hiệu năng mạng: Bandwidth là sức chứa lý thuyết tối đa, Latency là thời gian trễ của gói tin, còn Throughput là tốc độ truyền tải thực tế đạt được. Sự kết hợp của cả ba sẽ chỉ ra điểm nghẽn chính xác của hệ thống.

3.1. Bảng phân biệt Bandwidth, Throughput với Latency

Để phân biệt rõ bản chất, Bandwidth được đo bằng dung lượng thiết kế (lý thuyết), Latency đo bằng mili-giây (ms), trong khi Throughput phản ánh tốc độ thực đạt. Dưới đây là bảng đối chiếu kỹ thuật chi tiết dành cho quản trị viên mạng:

Có thể hiểu đơn giản, Bandwidth là giới hạn tối đa của đường truyền, Latency là độ trễ khi dữ liệu di chuyển, còn Throughput phản ánh tốc độ thực tế đạt được trong quá trình sử dụng. Cả ba yếu tố này luôn gắn kết chặt chẽ và tác động qua lại lẫn nhau trong quá trình vận hành mạng.

Trong ba yếu tố này, Throughput là chỉ số thể hiện trực tiếp trải nghiệm thực tế, do chịu ảnh hưởng đồng thời từ cả Bandwidth và Latency. Do đó, đây luôn là chỉ số được các kỹ sư mạng ưu tiên theo dõi hàng đầu để đánh giá chất lượng dịch vụ.

3.2. Mối quan hệ “Nút thắt cổ chai” giữa 3 chỉ số

Trong mạng TCP, Throughput bị giới hạn trực tiếp bởi Latency và Packet Loss, tạo thành nút thắt cổ chai bất chấp Bandwidth cao đến đâu. Nghĩa là, độ trễ càng lớn và suy hao càng nhiều, tốc độ truyền tải thực tế (Throughput) sẽ càng rớt thê thảm.

Trong thực tế, Bandwidth cao không đảm bảo Throughput cao, vì hiệu suất truyền tải còn phụ thuộc vào độ trễ (Latency) trong cơ chế kiểm soát luồng và tắc nghẽn của TCP. Khi Latency lớn, thời gian chờ phản hồi (ACK) tăng lên, làm chậm quá trình gửi dữ liệu và giảm tốc độ thực tế.

Mối quan hệ này được thể hiện rõ nhất qua mô hình tính toán Mathis dành cho giao thức TCP. Theo đó, TCP Throughput thực tế luôn tỷ lệ nghịch với độ trễ (RTT) và căn bậc hai của tỷ lệ rớt gói tin (Packet Loss).

Công thức lý thuyết:

Trong đó:

• MSS (Maximum Segment Size): Kích thước payload TCP lớn nhất trong một TCP segment (không bao gồm header TCP/IP), thường là 1460 bytes khi MTU = 1500 với TCP IPv4.
• RTT (Latency): Thời gian chờ phản hồi (giây)
• Packet Loss: Tỷ lệ suy hao gói tin trên đường truyền

Nhìn vào biến số trên, có thể thấy khi mạng xảy ra hiện tượng mất gói tin (Packet loss), Throughput sẽ suy giảm theo tỷ lệ nghịch với căn bậc hai của tỷ lệ mất gói tin (1/√p). Điều này giải thích tại sao một hệ thống mạng dù có gói cước băng thông cực lớn (10Gbps) nhưng định tuyến qua cáp quang biển quốc tế có độ trễ lớn và suy hao nhiều thì tốc độ tải file thực tế vẫn rớt thê thảm.

Ví dụ: Đường truyền quốc tế 1Gbps từ Việt Nam sang Mỹ có Latency ~200ms sẽ cho Throughput của một luồng TCP thấp hơn đáng kể so với kết nối nội địa có Latency ~5ms, dù cùng băng thông. Khoảng cách địa lý quá xa chính là nguyên nhân trực tiếp kéo dài thời gian chờ xác nhận gói tin (RTT) trong trường hợp này.

4. Tầm quan trọng của Throughput đối với vận hành hệ thống

Giám sát Throughput là yêu cầu bắt buộc trong quản trị Data Center vì nó quyết định trực tiếp đến trải nghiệm người dùng (UX), hiệu suất xử lý ứng dụng và mức độ tuân thủ SLA cam kết. Chỉ số này giúp đội ngũ IT phát hiện sớm các sự cố mạng.

4.1. Nâng cao trải nghiệm người dùng

Throughput ảnh hưởng tới tốc độ load các trang web nặng nhiều tài nguyên và độ mượt của video stream chất lượng cao. Khi thông lượng thực tế không đáp ứng đủ nhu cầu, người dùng lập tức gặp tình trạng video giật lag, xoay vòng tải trang hoặc ứng dụng bị timeout (hết hạn kết nối).

Ví dụ, một hệ thống có Bandwidth lớn nhưng Throughput thấp vẫn mang lại trải nghiệm kém do tốc độ truyền thực tế không đáp ứng nhu cầu. Người dùng sẽ dễ dàng cảm nhận được sự chậm trễ này thông qua tình trạng giật lag hoặc xoay vòng load trang liên tục.

4.2. Đánh giá hiệu suất ứng dụng

Throughput phản ánh số lượng giao dịch/dữ liệu mà ứng dụng có thể xử lý thành công trong thời gian thực dưới áp lực tải cao. Mức sụt giảm Throughput đột ngột chính là dấu hiệu cảnh báo lỗi code, rò rỉ RAM hoặc hết tài nguyên CPU.

Khi Throughput giảm bất thường, đây thường là dấu hiệu của các vấn đề như tắc nghẽn, giới hạn tài nguyên hoặc lỗi hệ thống. Lúc này, đội ngũ IT cần nhanh chóng rà soát lại nhật ký hoạt động của các thiết bị mạng và phần cứng máy chủ.

4.3. Quản lý tắc nghẽn và mở rộng mạng

Khi lưu lượng truy cập (Traffic) tăng mạnh nhưng Throughput thực tế bị đi ngang (không tăng), đó là bằng chứng rõ ràng nhất của tình trạng quá tải hạ tầng. Quản trị viên cần dựa vào biểu đồ này để đưa ra quyết định nâng cấp gói mạng vật lý.

Dựa vào Throughput, quản trị viên có thể xác định khu vực cần nâng cấp, phân bổ lại tài nguyên hoặc mở rộng hạ tầng phù hợp. Đây là cơ sở dữ liệu cốt lõi để lập kế hoạch chi tiêu và đầu tư IT một cách thông minh cho doanh nghiệp.

4.4. Tuân thủ thỏa thuận mức dịch vụ (SLA)

Thông lượng mạng thực tế là thước đo pháp lý bắt buộc trong các hợp đồng SLA giữa nhà cung cấp Cloud/ISP và khách hàng doanh nghiệp. Vi phạm mức cam kết Throughput tối thiểu sẽ trực tiếp dẫn đến các khoản phạt bồi thường dịch vụ.

Khi Throughput không đạt mức cam kết, hệ thống có thể vi phạm SLA, ảnh hưởng đến chất lượng dịch vụ và uy tín doanh nghiệp. Điều này đôi khi còn dẫn đến những khoản phạt hợp đồng bồi thường không đáng có giữa nhà cung cấp và khách hàng.

4.5. Tối ưu hóa hạ tầng IT

Dữ liệu Throughput giúp doanh nghiệp tối ưu chi phí hạ tầng, tránh việc “đốt tiền” nâng cấp vô ích. Việc biết chính xác tốc độ truyền tải thực tế giúp IT phân bổ lại các luồng dữ liệu nặng vào giờ thấp điểm, tận dụng tối đa băng thông đang có.

Khi Throughput thấp so với khả năng hệ thống, đó là dấu hiệu cần tối ưu cấu hình, phân bổ lại tài nguyên hoặc điều chỉnh kiến trúc. Quá trình điều chỉnh này sẽ giúp doanh nghiệp tránh việc lãng phí ngân sách vào những thiết bị không phát huy hết công năng.

5. Tại sao Throughput thực tế luôn thấp hơn Băng thông định mức?

Throughput thực tế luôn thấp hơn Bandwidth vì đường truyền phải gánh thêm chi phí cấu trúc gói tin (Protocol Overhead), thời gian mã hóa bảo mật, hiện tượng suy hao mất gói (Packet Loss) và giới hạn năng lực đọc ghi của thiết bị phần cứng.

5.1. Suy hao do chi phí giao thức truyền dẫn

Mỗi gói dữ liệu (Payload) truyền đi luôn bị đính kèm thêm các đoạn mã Header định tuyến như TCP/IP, UDP hay Ethernet Frame. Chi phí mào đầu (Overhead) bắt buộc này chiếm dụng khoảng 2% – 5% tổng băng thông đường truyền.

Trong quá trình truyền, các giao thức như Ethernet, IP và TCP/UDP đều bổ sung header để phục vụ định tuyến và kiểm soát. Phần dữ liệu này không phải payload hữu ích nhưng vẫn chiếm băng thông, làm tổng dung lượng truyền tăng lên trong khi dữ liệu thực không đổi. Do đó, Throughput luôn thấp hơn Bandwidth ngay cả khi mạng hoạt động ổn định.

5.2. Gánh nặng xử lý từ các lớp Bảo mật

Quá trình mã hóa và giải mã dữ liệu 2 chiều từ các giao thức VPN (IPsec, SSL/TLS) không chỉ tạo thêm độ trễ cho CPU mà còn làm phình to kích thước gói tin. Tùy chuẩn bảo mật, chi phí dữ liệu (data overhead) có thể từ 4–6% (WireGuard) cho đến 20–40% (OpenVPN TCP), đồng thời throughput thực tế còn có thể giảm sâu hơn do gánh nặng mã hóa lên CPU.

5.3. Hiện tượng suy hao gói tin và Tắc nghẽn mạng

Khi thiết bị Switch bị quá tải dung lượng cổng (Port Capacity), hệ thống buộc phải vứt bỏ gói tin (Drop). Cơ chế TCP ngay lập tức yêu cầu truyền lại (retransmit) gói tin hỏng, tạo ra vòng lặp gây tắc nghẽn và kéo sập Throughput.

5.4. Giới hạn năng lực xử lý của phần cứng (CPU, RAM, Disk I/O)

Throughput mạng sẽ hoàn toàn vô nghĩa nếu tốc độ đọc/ghi của ổ cứng (Disk I/O) chậm hoặc CPU máy chủ đang chạm trần 100%. Lúc này, phần cứng không thể xử lý kịp lượng Data đổ về, buộc đường truyền mạng phải hạ tốc độ (Drop rate).

Đặc biệt, ổ cứng là điểm nghẽn phổ biến: mạng có thể rất nhanh nhưng nếu tốc độ đọc/ghi không theo kịp, toàn bộ hệ thống vẫn bị chậm. Việc nâng cấp từ ổ HDD truyền thống lên các chuẩn lưu trữ tốc độ cao như SSD NVMe thường là giải pháp khắc phục triệt để nhất.

5.5. Giới hạn cấp phát mạng từ ảo hóa

Trên môi trường Cloud VPS, các phần mềm ảo hóa (Hypervisor) thường áp dụng cơ chế Burst Bandwidth. Khi Cloud Server dùng hết “điểm tín dụng” băng thông ưu tiên, hệ thống sẽ tự động bóp (Throttle) Throughput về ngưỡng giới hạn thấp nhất.

Điều này khiến hiệu năng mạng trong môi trường Cloud có thể không ổn định nếu không được giám sát và cấu hình phù hợp. Người dùng nên thường xuyên theo dõi biểu đồ tài nguyên trên trang quản trị Cloud để kịp thời phát hiện các điểm sụt giảm băng thông.

6. [TỔNG HỢP] Các phương pháp đo kiểm tra Network Throughput

Quản trị viên có 3 phương pháp tiêu chuẩn để đo kiểm Throughput: Tính toán thủ công cho ước lượng nhanh, dùng phần mềm iPerf3 cho kết nối nội bộ/Cloud server và dùng thiết bị phần cứng VeEX theo chuẩn RFC2544 đối với hạ tầng Enterprise.

6.1. Tính toán thủ công

Cách đơn giản nhất để tính Throughput là lấy Tổng dữ liệu truyền thành công (Total Data) chia cho Thời gian truyền (Time). Phương pháp này thường được dùng để kiểm tra nhanh trong các trường hợp cơ bản.

Công thức:

Trong đó:

• Total Data: tổng dữ liệu truyền thành công (bits hoặc bytes)
• Time: thời gian truyền (giây)

Ví dụ: Tải một file 100MB trong 10 giây → Throughput ≈ 80 Mbps (sau khi quy đổi về bits). Phương pháp tính toán này tuy đơn giản nhưng lại cực kỳ hữu dụng khi bạn cần ước lượng nhanh năng lực của đường truyền mạng gia đình.

6.2. Dùng phần mềm mã nguồn mở (iPerf/iPerf 3)

iPerf/iPerf3 là công cụ đo Throughput phổ biến nhờ dễ triển khai và phản ánh chính xác hiệu năng truyền tải trong điều kiện thực tế. Công cụ này tạo lưu lượng trực tiếp giữa hai máy để kiểm tra tốc độ truyền.

• Hoạt động theo mô hình client–server: một máy gửi dữ liệu, máy còn lại nhận để đo tốc độ
• Hỗ trợ cả TCP và UDP, phù hợp cho nhiều kịch bản kiểm tra
• Cung cấp các chỉ số như Throughput, jitter và packet loss
• Có thể áp dụng cho nhiều môi trường như mạng nội bộ, WAN hoặc Cloud

6.3. Dùng thiết bị chuyên dụng VeEX cho mạng doanh nghiệp

Đây là phương pháp đo Throughput chuyên sâu, thường được sử dụng trong môi trường doanh nghiệp khi cần độ chính xác cao và tuân thủ các tiêu chuẩn kiểm thử. Các thiết bị như VeEX cho phép đánh giá hiệu năng mạng một cách độc lập và chi tiết.

• Là thiết bị đo chuyên dụng, phục vụ kiểm tra hiệu năng mạng ở mức độ nâng cao
• Hỗ trợ nhiều dải tốc độ, từ 10Mbps đến 100GbE/400GbE/800GbE tùy dòng thiết bị
• Tích hợp các bài test theo chuẩn như RFC2544 và RFC6349
• Đo đầy đủ các chỉ số: Throughput, Latency, packet loss và hiệu năng TCP
• Hoạt động độc lập, không phụ thuộc vào hệ thống đang chạy

Bảng so sánh các phương pháp đo Network Throughput

6.4. Sử dụng hệ thống giám sát Throughput liên tục 24/7

Thay vì chỉ đo kiểm (benchmark) một lần lúc cài đặt, quản trị viên nên triển khai các nền tảng giám sát thời gian thực (như Zabbix, PRTG hoặc Prometheus). Các hệ thống này thu thập Throughput liên tục qua giao thức SNMP để tạo biểu đồ và phát cảnh báo sự cố ngay lập tức.

Khác với iPerf3 hay VeEX chỉ dùng để test (benchmark) giới hạn mạng, các phần mềm Real-time Monitoring mang lại giá trị vận hành thực tế cao hơn:

• Zabbix / PRTG Network Monitor: Thu thập dữ liệu Throughput của toàn bộ Switch, Router thông qua giao thức SNMP, vẽ biểu đồ băng thông theo từng phút.
• Prometheus & Grafana: Bộ công cụ mã nguồn mở tiêu chuẩn cho hạ tầng Cloud và Kubernetes, giúp trực quan hóa dữ liệu Network/Disk Throughput trên các Dashboard cảnh báo.
• Thiết lập Alerting: Hệ thống tự động bắn cảnh báo qua Telegram, Email hoặc Slack ngay khi Throughput sụt giảm bất thường hoặc có dấu hiệu bị tấn công DDoS làm nghẽn cổ chai mạng.

7. Hướng dẫn đo lường Throughput chính xác với iPerf3

Quy trình kiểm tra Throughput chuyên sâu bằng iPerf3 bắt buộc phải thiết lập 2 máy chủ: một máy đóng vai trò Server lắng nghe (Listening Port) và một máy Client đóng vai trò đẩy luồng dữ liệu (Traffic) để lấy báo cáo tốc độ.

7.1. Cách thiết lập mô hình Test iPerf3 (Client – Server)

Để bắt đầu kiểm tra, quản trị viên cần dùng SSH truy cập vào cả 2 máy chủ tham gia test và thực thi lệnh cài đặt gói phần mềm iperf3 tương ứng với nhân hệ điều hành (apt cho Ubuntu/Debian, yum cho CentOS/RHEL).

Trên Ubuntu / Debian:

sudo apt-get install iperf3

Trên CentOS / RHEL:

yum install epel-release
yum install iperf3

Trên Fedora / RHEL 8+:

sudo dnf install iperf3

7.2. Thực thi lệnh và Phân tích báo cáo Throughput

Sau khi bơm luồng traffic kết thúc, bạn cần tập trung đọc kết quả ở dòng tổng kết báo cáo tại máy nhận (Receiver). Hai chỉ số quan trọng nhất cần phân tích là: Transfer (Tổng dữ liệu truyền) và Bitrate (Throughput thực tế đạt được tính bằng Mbit/sec).

1. Kiểm tra trên TCP Protocol

Bước 1: Trên máy chủ (server) chạy lệnh sau để khởi động iPerf3 ở chế độ server:

iperf3 -s -p <port>

• -p: Chỉ định port lắng nghe (mặc định là 5201)

Ví dụ:

root@localhost ~]# iperf3 -s

-----------------------------------------------------------

Server listening on 5201

-----------------------------------------------------------

Lúc này server đã sẵn sàng nhận kết nối TCP trên port 5201.

–

Bước 2: Trên máy khách (client) chạy lệnh sau để bắt đầu kiểm tra băng thông:

iperf3 -c <IP_server> -p <port>

• -p: port mà server đang lắng nghe

Ví dụ: kiểm tra băng thông từ client đến máy chủ

[root@localhost ~]# iperf3 -c 192.168.1.10

Connecting to host 192.168.1.10, port 5201

[  5] local 192.168.1.20 port 3200 connected to 192.168.1.10 port 5201

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd

[  5]   0.00-1.00   sec   113 MBytes   951 Mbits/sec    0    725 KBytes       

[  5]   1.00-2.00   sec   112 MBytes   944 Mbits/sec    3    455 KBytes       

[  5]   2.00-3.00   sec   110 MBytes   923 Mbits/sec    0    508 KBytes       

[  5]   3.00-4.00   sec   111 MBytes   933 Mbits/sec   44    334 KBytes       

[  5]   4.00-5.00   sec   111 MBytes   933 Mbits/sec    1    404 KBytes       

[  5]   5.00-6.00   sec   112 MBytes   944 Mbits/sec    0    501 KBytes       

[  5]   6.00-7.00   sec   111 MBytes   933 Mbits/sec    0    554 KBytes       

[  5]   7.00-8.00   sec   111 MBytes   933 Mbits/sec    2    411 KBytes       

[  5]   8.00-9.00   sec   110 MBytes   923 Mbits/sec   29    424 KBytes       

[  5]   9.00-10.00  sec   111 MBytes   933 Mbits/sec    3    396 KBytes       

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bitrate         Retr

[  5]   0.00-10.00  sec  1.09 GBytes   935 Mbits/sec   82             sender

[  5]   0.00-10.04  sec  1.09 GBytes   928 Mbits/sec                  receiver

iperf Done.

Lúc này phía máy chủ server cũng cho kết quả kiểm tra kết nối từ IP client 

[root@localhost ~]# iperf3 -s

-----------------------------------------------------------

Server listening on 5201

-----------------------------------------------------------

Accepted connection from 192.168.1.20, port 32000

[  5] local 192.168.1.10 port 5201 connected to 192.168.1.20 port 32000

[ ID] Interval           Transfer     Bitrate

[  5]   0.00-1.00   sec   106 MBytes   891 Mbits/sec                  

[  5]   1.00-2.00   sec   112 MBytes   938 Mbits/sec                  

[  5]   2.00-3.00   sec   110 MBytes   927 Mbits/sec                  

[  5]   3.00-4.00   sec   111 MBytes   933 Mbits/sec                  

[  5]   4.00-5.00   sec   112 MBytes   936 Mbits/sec                  

[  5]   5.00-6.00   sec   111 MBytes   935 Mbits/sec                  

[  5]   6.00-7.00   sec   111 MBytes   934 Mbits/sec                  

[  5]   7.00-8.00   sec   112 MBytes   935 Mbits/sec                  

[  5]   8.00-9.00   sec   110 MBytes   927 Mbits/sec                  

[  5]   9.00-10.00  sec   111 MBytes   929 Mbits/sec                  

[  5]  10.00-10.04  sec  4.53 MBytes   935 Mbits/sec                  

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bitrate

[  5]   0.00-10.04  sec  1.09 GBytes   928 Mbits/sec                  receiver

-----------------------------------------------------------

Server listening on 5201

Dựa trên báo cáo trả về, bạn cần tập trung vào hai thông số quan trọng nhất tại dòng tổng kết (receiver). Việc nắm bắt đúng các thông số này sẽ quyết định độ chính xác của toàn bộ quá trình kiểm tra mạng.

• Transfer: Tổng lượng dữ liệu đã được gửi đi/nhận về trong suốt phiên kiểm tra
• Bitrate: Throughput thực tế (Tốc độ truyền dẫn trung bình). 

Trong ví dụ trên:

• Tổng dữ liệu truyền đạt 1.09 GB
• Throughput đạt khoảng 928 – 935 Mbps.

Nghĩa là đường truyền của bạn đang vận hành ổn định ở mức xấp xỉ 930 Mbps, đạt hiệu suất cao cho các kết nối Gigabit. Kết quả này chứng tỏ hệ thống cáp mạng và thiết bị Switch nội bộ của bạn ít bị suy hao, hoạt động rất sát với lý thuyết.

2. Kiểm tra trên UDP Protocol

Khác với TCP, UDP cho phép chủ động thiết lập mức băng thông để kiểm tra giới hạn truyền tải và tỷ lệ mất gói. Do UDP không có cơ chế xác nhận lại gói tin, nó là lựa chọn lý tưởng để mô phỏng các luồng dữ liệu thời gian thực như livestream hay gọi thoại VoIP.

Bước 1: Trên server, vẫn khởi động iPerf3 ở chế độ lắng nghe:

iperf3 -s -p <port>

Bước 2: Trên client, thực hiện lệnh:

iperf3 -c <server_ip> -p <port> -u -b 100M

Trong đó:

• <server_ip>: Địa chỉ IP của máy chủ.
• -u: Sử dụng giao thức UDP
• -b: Chỉ định băng thông mục tiêu cần kiểm tra (ví dụ: 100 Mbps)

8. Kỹ thuật tối ưu hóa Throughput cho hệ thống Cloud Server

Để tối đa hóa Throughput trong môi trường Cloud Server, cần áp dụng đồng thời nhiều kỹ thuật từ hạ tầng mạng, phần cứng đến tối ưu giao thức truyền tải nhằm loại bỏ các điểm nghẽn và nâng cao hiệu năng truyền dữ liệu. Chỉ khi các lớp kỹ thuật này được cấu hình đồng bộ, máy chủ mới có thể xử lý mượt mà mức tải lượng truy cập khổng lồ.

8.1. Sử dụng Caching và mạng phân phối nội dung (CDN)

Sử dụng mạng CDN giúp phân tán (cache) hình ảnh, video tĩnh ra các máy chủ biên (Edge Node) gần vị trí người truy cập nhất. Kỹ thuật này triệt tiêu độ trễ địa lý, trực tiếp giảm tải băng thông và giải phóng Throughput cho máy chủ web (Web Server) gốc.

Thay vì mọi request đều phải đi về server gốc, các tài nguyên như ảnh, video, file HTML tĩnh sẽ được cache tại các Edge node của CDN. Khi người dùng truy cập, dữ liệu sẽ được trả về từ node gần nhất, giúp:

• Giảm độ trễ do khoảng cách địa lý
• Hạn chế số lượng request trực tiếp về Web Server
• Giải phóng tài nguyên xử lý và băng thông tại server

8.2. Cấu hình Quality of Service (QoS) ưu tiên luồng dữ liệu

Thiết lập bộ định tuyến QoS (Quality of Service) giúp bảo vệ Throughput cho hệ thống quan trọng. IT quản trị sẽ gán băng thông ưu tiên cao (High Priority) cho ứng dụng ERP/Database, đồng thời bóp băng thông của các dịch vụ nền tảng ngầm như Windows Update.

Giải pháp phổ biến là cấu hình Quality of Service (QoS) để kiểm soát và ưu tiên luồng dữ liệu theo mục đích sử dụng. Bằng cách thiết lập bộ quy tắc hợp lý trên Router, băng thông sẽ được phân bổ công bằng và bảo vệ hiệu năng cho các dịch vụ cốt lõi.

Một cấu hình QoS điển hình trong môi trường doanh nghiệp:

• Thiết lập giới hạn băng thông (Bandwidth Limit) cho các dịch vụ nền như Windows Update, backup hoặc đồng bộ dữ liệu
• Đồng thời, gán mức ưu tiên cao (High Priority) cho các hệ thống quan trọng như Database, ERP hoặc ứng dụng nội bộ

8.3. Loại bỏ nút thắt Wi-Fi, ưu tiên kết nối Full-Duplex

Kết nối LAN cáp quang/đồng chuẩn Full-Duplex cho phép máy chủ gửi và nhận dữ liệu đồng thời trên hai kênh độc lập. Điều này loại bỏ hoàn toàn độ trễ do cơ chế Half-Duplex (chờ sóng – chỉ gửi hoặc nhận tại 1 thời điểm) của kết nối Wi-Fi.

Về bản chất, Wi-Fi hoạt động theo cơ chế bán song công (Half-Duplex), tức là tại một thời điểm chỉ có thể gửi hoặc nhận dữ liệu, không thể thực hiện đồng thời. Điều này dễ dẫn đến độ trễ cao và xung đột khi có nhiều thiết bị truy cập cùng lúc.

Ngược lại, kết nối mạng có dây (LAN) sử dụng Full-Duplex, cho phép gửi và nhận dữ liệu đồng thời, giúp tận dụng tối đa băng thông và giảm thiểu độ trễ. Đó cũng là lý do tại sao các Data Center tiêu chuẩn trên thế giới luôn bắt buộc sử dụng hoàn toàn cáp quang hoặc cáp đồng trực tiếp cho máy chủ.

Vì vậy, trong các hệ thống Cloud Server hoặc môi trường cần tối ưu Throughput:

• Nên ưu tiên sử dụng kết nối mạng dây thay vì Wi-Fi
• Đảm bảo các thiết bị mạng (Switch, NIC) đều hỗ trợ Full-Duplex
• Hạn chế sử dụng Wi-Fi cho các tác vụ quan trọng hoặc yêu cầu băng thông cao

8.4. Nâng cấp Firmware và thiết bị phần cứng hiện đại

Trong tối ưu Throughput, phần cứng mạng là yếu tố nền tảng quyết định giới hạn hiệu năng thực tế. Dù cấu hình và tối ưu phần mềm tốt, hệ thống vẫn không thể vượt quá năng lực của Router, Switch hoặc NIC.

Các thiết bị không còn phù hợp thường gây ra các hạn chế như:

• Giới hạn khả năng xử lý lưu lượng (Throughput ceiling thấp)
• Thiếu hỗ trợ các công nghệ tối ưu hiện đại như offloading hoặc QoS nâng cao
• Firmware lỗi thời dẫn đến hiệu năng không ổn định hoặc thiếu bản vá bảo mật

Do đó, cần thực hiện đồng thời:

• Cập nhật Firmware mới nhất để đảm bảo hiệu năng và độ ổn định
• Nâng cấp thiết bị mạng (Router, Switch, NIC) khi không còn đáp ứng yêu cầu băng thông
• Đảm bảo toàn bộ hệ thống hỗ trợ các chuẩn hiện đại (1Gbps, 10Gbps hoặc cao hơn nếu cần) 

8.5. Tối ưu hóa giao thức vận chuyển (TCP BBR, MTU)

Trong thực tế, Throughput còn chịu ảnh hưởng trực tiếp từ cơ chế điều khiển của TCP. Trên Linux, hệ thống mặc định sử dụng TCP CUBIC, điều chỉnh tốc độ dựa trên tín hiệu mất gói nên chưa tối ưu trong các môi trường yêu cầu hiệu năng cao.

Kết luận

Throughput là thước đo phản ánh hiệu năng thực tế của mạng, khác với Bandwidth chỉ mang tính lý thuyết. Dù băng thông cao, Throughput vẫn có thể thấp nếu bị ảnh hưởng bởi Latency, mất gói hoặc giới hạn hệ thống.

Vì vậy, để đánh giá và tối ưu đúng, cần tập trung vào Throughput thực tế, kết hợp đo lường chính xác và loại bỏ các điểm nghẽn trong toàn bộ hệ thống. Thực hiện tốt khâu kiểm định này sẽ giúp doanh nghiệp khai thác triệt để hiệu suất từ mọi khoản chi phí đầu tư hạ tầng mạng.

Để theo dõi thêm nhiều bài viết mới nhất của VinaHost, bạn có thể truy cập blog TẠI ĐÂY. Hoặc nếu bạn muốn được tư vấn thêm thì có thể liên hệ với chúng tôi qua:

• Email: cskh@vinahost.vn
• Hotline: 1900 6046 phím 1
• Livechat: https://livechat.vinahost.vn/chat.php