
Mục lục bài viết 8 phần
Ba chỉ số mô tả ba áp lực khác nhau lên firewall. Một thiết bị có thể đạt throughput cao với phiên dài nhưng vẫn suy giảm khi phải thiết lập nhiều phiên mới, giải mã TLS hoặc duy trì bảng trạng thái lớn.
Bài viết giúp bạn
- Throughput đo lượng dữ liệu, không đo toàn bộ trải nghiệm
- CPS đo tốc độ tạo và hủy phiên
- Concurrent connections đo độ lớn bảng trạng thái
Throughput đo lượng dữ liệu, không đo toàn bộ trải nghiệm
#Throughput là lượng dữ liệu được chuyển qua trong một khoảng thời gian. Kết quả thay đổi mạnh theo frame size, tỷ lệ hai chiều, protocol mix, payload, NAT, logging, IPS, application control và TLS inspection.
Cần báo cáo cả offered load, forwarded load và loss. Nếu chỉ ghi giá trị nhận được mà không ghi điều kiện, con số rất khó so sánh hoặc dùng làm capacity planning.
- Frame size cố định hay IMIX
- Traffic một chiều hay hai chiều
- Tính năng bảo mật và logging đang bật
- Số policy, object và route
- Thời gian steady state và ngưỡng loss cho phép
CPS đo tốc độ tạo và hủy phiên
#Connections per second phản ánh khả năng xử lý handshake, state allocation, policy lookup, NAT và các bước kiểm tra đầu phiên. Workload web/API với nhiều kết nối ngắn thường tạo áp lực CPS lớn dù throughput không cao.
Bài đo CPS phải chỉ rõ thế nào là một connection thành công, timeout bao lâu, close bằng FIN hay reset, tỷ lệ thất bại và số lần retransmission. Nếu client cạn ephemeral port hoặc server emulator quá tải, giới hạn đo được không còn là giới hạn của firewall.

Concurrent connections đo độ lớn bảng trạng thái
#Concurrent connections là số phiên hợp lệ được duy trì đồng thời. Để tăng con số này, cần kiểm soát session lifetime, keepalive, idle timeout và tốc độ ramp. Việc tạo hàng triệu session nhưng không trao đổi dữ liệu không đại diện cho mọi workload thực tế.
Trong giai đoạn giữ phiên, theo dõi memory, CPU, session table utilization, packet loss và khả năng xử lý phiên mới. Một thiết bị có thể giữ được nhiều phiên nhưng latency tăng hoặc CPS cho người dùng mới giảm mạnh.
TLS làm thay đổi hoàn toàn bài toán
#TLS inspection bổ sung handshake, key exchange, certificate processing, bulk encryption và policy kiểm tra nội dung đã giải mã. Kết quả phụ thuộc phiên bản TLS, cipher suite, key size, tỷ lệ session reuse, kích thước object và tỷ lệ lưu lượng được bypass.
Do đó cần tách baseline không giải mã, bài đo TLS pass-through và bài đo full inspection. Không nên dùng một con số throughput duy nhất để đại diện cho cả ba trạng thái.
Thiết kế test matrix có thể giải thích
#Thay vì chạy một profile cực đại, hãy xây ma trận theo từng mức tải và từng nhóm tính năng. Mỗi hàng chỉ thay đổi một biến chính để tìm knee point — vùng mà latency, loss hoặc error bắt đầu tăng nhanh.
- Baseline L3/L4 với policy tối thiểu
- IMIX và application mix gần production
- CPS tăng dần với session lifetime cố định
- Concurrent session tăng dần trong khi giữ transaction nền
- Bật lần lượt IPS, antivirus, application control và TLS inspection
- Lặp lại sau failover hoặc nâng cấp phần mềm
KPI và tiêu chí pass/fail
#Ngoài throughput, CPS và concurrent sessions, báo cáo nên có transaction success, response time percentile, handshake failure, reset, drop reason, CPU, memory và HA state. Pass/fail phải gắn với SLO của dịch vụ, không chỉ với ngưỡng mà thiết bị chưa crash.
Kết luận tốt chỉ rõ cấu hình nào đạt, tại mức tải nào, trong bao lâu và dấu hiệu suy giảm đầu tiên là gì. Đây mới là dữ liệu dùng được cho sizing và vận hành.
Tách giới hạn của generator, firewall và server
#Kết quả chỉ có ý nghĩa khi traffic generator và server emulator còn đủ tài nguyên. Trước bài chính, chạy loopback hoặc baseline không qua firewall để xác nhận CPU, memory, port utilization, ephemeral port, socket và khả năng sinh/nhận traffic. Nếu baseline đã lỗi, không thể quy lỗi cho firewall.
Trong bài chính, theo dõi đồng thời offered load, established rate, forwarded traffic, retransmission, timeout, bảng session, dataplane CPU và log drop. Điểm giới hạn là nơi nhiều tín hiệu cùng thay đổi, không phải chỉ là một con số trên dashboard.
- Calibrate theo từng frame size và protocol mix
- Xác nhận server response không phải bottleneck
- Kiểm tra NAT pool và client source-port reuse
- Giữ nguyên policy, logging và security profile giữa các lần chạy
Mẫu bảng kết quả có thể nghiệm thu
#Mỗi dòng kết quả nên gắn với một cấu hình duy nhất và ghi cả điều kiện đo. Báo cáo tốt cho phép người khác lặp lại bài test mà không cần suy đoán.
- Test ID, thời gian, phiên bản, topology và cấu hình checksum
- Offered/forwarded throughput, CPS thành công và peak concurrent
- P50/P95/P99 latency, timeout, reset, retransmission và loss
- CPU, memory, session table, thermal và error counter của DUT
- Kết luận pass/fail, giới hạn quan sát được và sai số phép đo
Khái niệm cần nhớ
- Security efficacy
- Mức độ phát hiện hoặc ngăn chặn đúng nội dung kiểm thử trong phạm vi đã xác định.
- Goodput
- Lưu lượng ứng dụng hữu ích tới đích, không tính phần truyền lại hoặc overhead không tạo giá trị.
- False positive
- Lưu lượng hợp lệ bị nhận diện hoặc xử lý nhầm như một mối đe dọa.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo1 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
