Một ứng dụng gọi API qua proxy chạy tốt khi gửi liên tục, nhưng báo lỗi sau vài phút nghỉ. Đây là ví dụ giả định. Bật mọi tùy chọn “keepalive” chưa chắc sửa được lỗi: cần phân biệt lớp TCP, chính sách HTTP và phiên ứng dụng.
TCP keepalive kiểm tra điều gì?
TCP keepalive gửi gói thăm dò khi kết nối nhàn rỗi để tìm dấu hiệu đầu TCP bên kia còn phản hồi. Nó không kiểm tra tài khoản hay phiên đăng nhập. Đầu TCP trả lời vẫn có thể nằm trước ứng dụng đang lỗi. RFC 9293, mục TCP Keep-Alives yêu cầu không kết luận kết nối chết chỉ vì một thăm dò không được trả lời.
HTTP keep-alive là tái sử dụng kết nối
HTTP keep-alive thường chỉ việc dùng lại kết nối cho nhiều yêu cầu. HTTP/1.1 mặc định hỗ trợ kết nối bền vững, nhưng máy chủ hoặc proxy vẫn có quyền đóng kết nối. Nó không tự tạo một chuỗi yêu cầu “ping” để giữ socket sống. RFC 9112 về kết nối HTTP bền vững mô tả quy tắc này và không bảo đảm thời gian nhàn rỗi vô hạn.
Không nên thêm thủ công header Connection: keep-alive vào mọi giao thức. Với HTTP/2, cơ chế quản lý kết nối khác HTTP/1.1. Xem thêm HTTP/2 stream và kết nối khi dùng proxy để tránh nhầm số yêu cầu với số socket.
Heartbeat kiểm tra ở lớp ứng dụng
Heartbeat là thông điệp được ứng dụng hoặc giao thức ứng dụng định nghĩa, chẳng hạn một yêu cầu kiểm tra phiên hoặc Ping/Pong của WebSocket. Phản hồi có thể cho biết dịch vụ đang xử lý thông điệp, thay vì chỉ cho biết đầu TCP phản hồi. Phải dùng đúng cơ chế mà máy chủ hỗ trợ; tự gửi dữ liệu bất kỳ có thể phá giao thức.
Ví dụ, một màn hình giám sát có heartbeat theo tài liệu của dịch vụ và thời hạn chờ phản hồi riêng. Cơ chế ấy không thay thế việc làm mới token. Trường hợp tương tác thời gian thực có thể tham khảo cách khoanh vùng WebSocket mất kết nối qua proxy.
Vì sao bật TCP keepalive vẫn bị ngắt?
Máy khách, proxy, cân bằng tải và máy chủ có thể áp dụng các giới hạn khác nhau. Một thiết bị trung gian có thể chỉ coi dữ liệu ứng dụng là hoạt động, hoặc áp dụng tuổi thọ kết nối tối đa. Thăm dò gửi quá muộn cũng không cứu được socket đã bị đóng. Vì vậy, keepalive có thể hỗ trợ phát hiện đứt kết nối nhưng không bảo đảm vượt qua mọi idle timeout.
Với proxy chuyển tiếp TCP thông thường, chặng máy khách đến proxy và chặng proxy đến đích là các kết nối riêng. Cấu hình socket trên máy khách không tự sửa cấu hình socket phía proxy. Theo tài liệu keepalive của curl, curl bật TCP keepalive mặc định và cho phép đổi khoảng thăm dò; khả năng áp dụng còn tùy hệ điều hành.
Thử tái sử dụng HTTP với số yêu cầu nhỏ
Trên endpoint kiểm thử do bạn quản lý, dùng một lệnh curl với hai URL để quan sát log kết nối. Thay địa chỉ mẫu bên dưới; endpoint cần hỗ trợ HEAD. Không đưa mật khẩu proxy vào ảnh chụp hoặc log gửi công khai.
curl --proxy http://proxy.example:8080 --http1.1 --connect-timeout 5 --max-time 20 --verbose --head https://kiemthu.example/status https://kiemthu.example/statusHai lượt chạy curl độc lập không phải phép thử tái sử dụng socket trong cùng tiến trình. Lệnh ngắn này cũng chưa đủ để quan sát thăm dò TCP sau một khoảng nhàn rỗi dài. Nếu nhận lỗi xác thực, sửa quyền truy cập trước, không diễn giải thành lỗi keepalive.
Khoanh vùng trước khi đổi cấu hình
- Ghi thời điểm yêu cầu cuối, thời gian nghỉ và lỗi đầu tiên sau khi nghỉ.
- Thử lại một vài lần trên môi trường được phép, không chạy vòng lặp tải cao.
- Đối chiếu timeout của thư viện, pool kết nối, proxy và dịch vụ đích.
- Thay một tham số mỗi lần, ghi giá trị cũ để hoàn tác.
Nếu socket cũ bị đóng, ứng dụng cần mở lại kết nối phù hợp. Với thao tác có tác dụng phụ như tạo đơn hàng, không tự gửi lại vô hạn: phải kiểm tra kết quả trước hoặc dùng cơ chế chống xử lý trùng mà API hỗ trợ. Phân biệt thêm các lỗi trong hướng dẫn timeout, refused và reset.
Câu hỏi thường gặp
Bật keepalive có giữ phiên đăng nhập mãi không?
Không. Phiên đăng nhập và token có thời hạn riêng, độc lập với việc socket còn mở hay không.
Có nên đặt thăm dò thật dày?
Không mặc định. Cần cân nhắc tài nguyên, pin thiết bị, chính sách dịch vụ và số kết nối đồng thời. Chọn theo bằng chứng đo, không sao chép một giá trị cho mọi hệ thống.
Bắt đầu bằng log thời gian nhàn rỗi, xác định lớp bị ngắt rồi thử một thay đổi có thể hoàn tác trên endpoint được phép.