Thả các kết nối với tcp_tw_recycle

Question

tóm tắt các vấn đề

chúng tôi đang có một thiết lập trong đó rất nhiều (800-2400 mỗi giây (kết nối đến một hộp linux và chúng tôi có một thiết bị NAT giữa client và server. do đó, có rất nhiều ổ cắm TIME_WAIT còn lại trong hệ thống Để khắc phục điều đó, chúng tôi đã đặt tcp_tw_recycle thành 1, nhưng điều đó dẫn đến sự sụt giảm trong các kết nối đang truy cập sau khi duyệt qua mạng chúng tôi đã tìm thấy tài liệu tham khảo khung với tcp_tw_recycle và thiết bị NAT xảy ra.

độ phân giải đã thử

chúng tôi sau đó đã thử bằng cách đặt tcp_tw_reuse thành 1 nó hoạt động tốt mà không gặp bất kỳ sự cố nào với cùng một thiết lập và cấu hình.

Nhưng tài liệu nói rằng tcp_tw_recycle và tcp_tw_reuse không nên được sử dụng khi kết nối đi qua nút nhận biết trạng thái TCP, chẳng hạn như tường lửa, thiết bị NAT hoặc bộ cân bằng tải có thể thấy khung bị rớt. Càng có nhiều kết nối, bạn càng có nhiều khả năng gặp vấn đề này.

Truy vấn

1) có thể sử dụng tcp_tw_reuse trong loại trường hợp này không? 2) nếu không, phần nào của mã linux đang ngăn chặn tcp_tw_reuse được sử dụng cho kịch bản như vậy? 3) nói chung sự khác nhau giữa tcp_tw_recycle và tcp_tw_reuse là gì?

Answer 1

Theo mặc định, khi cả hai tcp_tw_reuse và tcp_tw_recycle bị vô hiệu hóa, hạt nhân sẽ đảm bảo rằng ổ cắm trong TIME_WAIT nhà nước sẽ vẫn trong trạng thái đó đủ lâu - thời gian đủ dài để chắc chắn rằng các gói tin thuộc các kết nối trong tương lai sẽ không bị nhầm lẫn với các gói trễ của kết nối cũ.

Khi bạn bật tcp_tw_reuse, các ổ cắm trong trạng thái TIME_WAIT có thể được sử dụng trước khi hết hạn và hạt nhân sẽ cố gắng đảm bảo rằng không có xung đột liên quan đến số thứ tự TCP. Nếu bạn bật tcp_timestamps (a.k.a. PAWS, để bảo vệ chống lại số thứ tự được bao bọc), nó sẽ đảm bảo rằng những va chạm đó không thể xảy ra. Tuy nhiên, bạn cần bật các dấu thời gian TCP trên cả hai kết thúc (ít nhất, đó là sự hiểu biết của tôi). Xem definition of tcp_twsk_unique để biết chi tiết đẫm máu.

Khi bạn bật tcp_tw_recycle, hạt nhân trở nên tích cực hơn nhiều và sẽ đưa ra các giả định về dấu thời gian được máy chủ từ xa sử dụng. Nó sẽ theo dõi dấu thời gian cuối cùng được sử dụng bởi mỗi máy chủ từ xa có kết nối trong trạng thái TIME_WAIT) và cho phép sử dụng lại ổ cắm nếu dấu thời gian đã tăng đúng cách. Tuy nhiên, nếu dấu thời gian được máy chủ lưu trữ thay đổi (tức là quay ngược thời gian), gói SYN sẽ tự động bị xóa và kết nối sẽ không thành công (bạn sẽ thấy lỗi tương tự như "thời gian chờ kết nối"). Nếu bạn muốn đi sâu vào mã hạt nhân, thì definition of tcp_timewait_state_process có thể là điểm khởi đầu tốt.

Bây giờ, dấu thời gian sẽ không bao giờ quay ngược thời gian; trừ khi:

• máy chủ được khởi động lại (nhưng lúc này trở lại, có thể sẽ hết hạn, vì vậy nó sẽ không có vấn đề);
• địa chỉ IP nhanh chóng được sử dụng lại bởi một số thứ khác (TIME_WAIT kết nối sẽ ở lại một chút, nhưng các kết nối khác có thể bị ấn tượng bởi TCP RST và điều đó sẽ giải phóng một số không gian);
• dịch địa chỉ mạng (hoặc tường lửa thông minh) được tham gia vào giữa kết nối.

Trong trường hợp thứ hai, bạn có thể có nhiều máy chủ ở cùng một địa chỉ IP, và do đó, chuỗi thời gian khác nhau (hoặc, dấu thời gian được ngẫu nhiên tại mỗi kết nối bởi tường lửa). Trong trường hợp đó, một số máy chủ sẽ ngẫu nhiên không thể kết nối, vì chúng được ánh xạ tới một cổng mà trong đó nhóm TIME_WAIT của máy chủ có dấu thời gian mới hơn. Đó là lý do tại sao các tài liệu cho bạn biết rằng "thiết bị NAT hoặc cân bằng tải có thể bắt đầu thả khung vì cài đặt".

Một số người khuyên bạn chỉ nên để tcp_tw_recycle một mình, nhưng bật tcp_tw_reuse và thấp hơn . Tôi đồng ý :-)