Kiểm thử TCP idle timeout và keepalive qua NAT/firewall: session aging, half-open và reconnect

Không nên bắt đầu bằng câu hỏi “đặt TCP keepalive bao nhiêu giây”. Trước hết cần biết phiên nào thực sự cần sống lâu khi không có payload, middlebox nào giữ state, timeout được tính lại bởi packet nào, và ứng dụng chấp nhận gián đoạn bao lâu. SSH quản trị, WebSocket, database pool và kết nối IoT dài phiên có cùng TCP nhưng khác hẳn yêu cầu dịch vụ.

Theo RFC 9293, TCP cung cấp truyền byte tin cậy giữa hai endpoint; RFC không làm cho mapping NAT hay state firewall tồn tại vô thời hạn. RFC 1122 và RFC 9293 mục 3.8.4 mô tả keepalive là tùy chọn, mặc định phải tắt; nếu bật, khoảng idle mặc định trước khi gửi probe không dưới hai giờ và phải cấu hình được; nhiều stack và ứng dụng hiện đại cấu hình khác, nên phải ghi rõ OS, runtime và socket option đang thử.

Mục tiêu kiểm thử là tìm ba mốc: thời gian middlebox loại session im lặng, thời gian endpoint phát hiện đường chết, và thời gian ứng dụng phục hồi. Ba mốc này không đồng nhất.

Topology cơ bản gồm client generator, NAT/firewall dưới thử nghiệm, server phản hồi và một impairment node có thể chặn một chiều. Đặt packet capture ở cả hai phía middlebox; nếu thiết bị xuất session table hoặc counter drop, thu chúng theo cùng timeline. Đồng bộ NTP/PTP và ghi sai số clock trước khi chạy.

Tạo ít nhất ba đường: direct baseline không qua stateful middlebox; một middlebox; và chuỗi NAT plus firewall/load balancer. Đường chuỗi giúp phát hiện timer ngắn nhất nhưng không tự chỉ ra thiết bị nào xóa state, vì vậy cần thử từng hop riêng trước.

Khóa address family, TCP options, MSS, congestion control, TLS hay cleartext, hướng khởi tạo, NAT mode, HA state sync và policy. Với keepalive, ghi TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT hoặc giá trị tương đương; với heartbeat ứng dụng, ghi chu kỳ, payload và cơ chế timeout. Không gọi ACK thuần, keepalive probe và application ping là cùng một thứ.

Traffic profile phải chứa phân bố thời gian im lặng chứ không chỉ một giá trị trung bình. Ví dụ minh họa, không phải khuyến nghị chung hay số đo thực tế: 60% phiên nghỉ 30 giây, 30% nghỉ 5 phút và 10% nghỉ 30 phút. Giữ nguyên số phiên, tốc độ mở kết nối và payload để so sánh các timer.

KPI chính là idle lifetime quan sát được, tỷ lệ phiên sống sau mỗi khoảng nghỉ, thời gian phát hiện state mất, số retransmission, reconnect success rate và thời gian phục hồi giao dịch. Ở quy mô lớn cần thêm session-table occupancy, CPU/memory middlebox, packets per second do keepalive và tỷ lệ port exhaustion của NAT.

Pass/fail phải ràng buộc với SLO. Ví dụ minh họa “99,9% phiên im lặng 10 phút thực hiện giao dịch tiếp theo trong 2 giây” hữu ích hơn “keepalive hoạt động”; tổ chức phải tự chốt SLO, không coi các số này là chuẩn hoặc kết quả đo của NetVali.

• Lớp: TCP endpoint · KPI: RTO, retransmission, reset · Bằng chứng: pcap, socket state · Sai lầm cần tránh: Chỉ nhìn ESTABLISHED
• Lớp: NAT/firewall · KPI: session age, delete reason · Bằng chứng: session table, log, counter · Sai lầm cần tránh: Tin cấu hình mà không đo
• Lớp: Ứng dụng · KPI: heartbeat miss, reconnect, transaction time · Bằng chứng: log có correlation ID · Sai lầm cần tránh: Đồng nhất reconnect với phục hồi
• Lớp: Hệ thống · KPI: CPU, memory, session scale, PPS · Bằng chứng: telemetry theo thời gian · Sai lầm cần tránh: Bỏ qua chi phí keepalive

Không mặc định mọi keepalive probe đều refresh NAT mapping. RFC 5382 và RFC 7857 đưa ra yêu cầu hành vi NAT TCP, nhưng triển khai, profile và chuỗi thiết bị thực tế vẫn phải đo.

• Kịch bản: Direct baseline · Biến tác động: Không middlebox · Kỳ vọng: Phiên sống theo endpoint timer
• Kịch bản: Idle dưới/ngang/trên ngưỡng · Biến tác động: Khoảng nghỉ · Kỳ vọng: Xác định boundary bằng binary search
• Kịch bản: Keepalive bật/tắt · Biến tác động: Chu kỳ probe · Kỳ vọng: Mapping được refresh nếu thiết bị chấp nhận packet
• Kịch bản: Heartbeat ứng dụng · Biến tác động: Payload hợp lệ · Kỳ vọng: Phát hiện end-to-end, có chi phí cao hơn
• Kịch bản: Chặn chiều server→client · Biến tác động: Blackhole một chiều · Kỳ vọng: Endpoint phát hiện bằng ACK/probe timeout
• Kịch bản: Reboot/failover firewall · Biến tác động: Mất state · Kỳ vọng: Đo reset, silent drop và reconnect
• Kịch bản: Session scale cao · Biến tác động: 50/80/95% capacity · Kỳ vọng: Timer và delete reason không drift ngoài ngưỡng

Một packet bất kỳ xuất hiện trong thời gian idle có thể làm sai kết quả. Capture phải được lọc theo đúng phiên TCP để phát hiện heartbeat hoặc dữ liệu nền trên chính kết nối đang thử. DNS hay telemetry trên flow khác không tự làm mới idle timer của phiên này.

• Bước 1: Chạy direct baseline, xác minh không có packet nền ngoài traffic profile.
• Bước 2: Mở một phiên, gửi giao dịch xác nhận, sau đó idle theo dãy 30 s, 1, 2, 4, 8, 16, 32 phút.
• Bước 3: Sau mỗi khoảng nghỉ, gửi transaction có correlation ID; ghi ACK đầu tiên, retransmission và kết quả ứng dụng.
• Bước 4: Dùng binary search quanh mốc thất bại để ước lượng timeout, lặp tối thiểu ba lần.
• Bước 5: Bật TCP keepalive với cấu hình được ghi đầy đủ; lặp lại cùng dãy idle.
• Bước 6: Thử heartbeat ứng dụng, so sánh khả năng phát hiện lỗi một chiều và chi phí PPS.
• Bước 7: Xóa state có kiểm soát hoặc failover middlebox khi phiên im lặng; quan sát reset hay silent drop.
• Bước 8: Lặp với TLS, IPv4/IPv6, NAT44/NAT64 nếu nằm trong phạm vi triển khai.
• Bước 9: Xuất pcap hai phía, session log, config snapshot và bảng pass/fail.

Ở một phiên, keepalive dày có vẻ vô hại; ở một triệu phiên, nó tạo thêm packet, wake-up, log và state churn. Tăng tải theo bậc 25–50–75–90% session capacity, giữ phân bố idle cố định, rồi đo timeout thực tế có thay đổi khi thiết bị gần đầy hay không. Không dùng số “maximum sessions” của datasheet làm tải acceptance nếu chưa gắn với traffic mix.

Failure injection gồm drop một chiều, mất route ngắn, restart process, failover HA và cạn NAT port. Mỗi lỗi phải có trigger timestamp ngoài băng và tiêu chí recovery: phát hiện, đóng socket cũ, backoff, mở phiên mới, xác thực lại và hoàn tất transaction.

Nếu keepalive giữ được session, kết luận chỉ đúng với packet format, hướng, timer, software và tải đã thử. Nếu heartbeat ứng dụng phục hồi nhanh hơn, nguyên nhân có thể là phát hiện end-to-end tốt hơn chứ không phải transport kém. Nếu phiên vẫn ESTABLISHED nhưng transaction treo, đó là bằng chứng lệch state, không đủ để quy toàn bộ lỗi cho firewall khi chưa đối chiếu route và server.

Timer dài giảm reconnect nhưng tăng state occupancy và rủi ro giữ phiên chết. Timer ngắn giải phóng tài nguyên nhưng có thể làm hỏng workload bursty. Kết luận nên là một operating envelope: khoảng idle được bảo đảm, tải đã chứng minh và điều kiện cần tái kiểm thử.

• Chốt danh sách ứng dụng dài phiên, owner và SLO phục hồi.
• Lưu baseline OS/runtime, socket options, NAT/firewall policy và firmware.
• Đo timeout từng hop rồi mới đo chuỗi.
• Kiểm tra keepalive/heartbeat có jitter để tránh burst đồng bộ.
• Đặt reconnect backoff và giới hạn retry để không tạo storm.
• Giám sát session occupancy, delete reason, retransmission và reconnect rate.
• Canary thay đổi timer; chuẩn bị rollback và test lại sau nâng cấp.

• Idle timeout: thời gian không có traffic trước khi state bị loại.
• TCP keepalive: probe tùy chọn để kiểm tra peer/đường và có thể duy trì state.
• Application heartbeat: bản tin ở lớp ứng dụng xác nhận cả transport lẫn logic dịch vụ.
• Half-open connection: hai phía không còn cùng nhận thức về trạng thái phiên.
• Session aging: cơ chế hết hạn state tại NAT/firewall.
• Service restoration: thời gian tới khi giao dịch hữu ích hoàn tất, không chỉ socket kết nối lại.