Tôi đã viết một chương trình nhỏ tương tác với một máy chủ trên một cổng cụ thể. Chương trình hoạt động tốt, nhưng:
Sau khi chương trình kết thúc đột ngột và kể từ khi kết nối socket đó được hiển thị ở CLOSE_WAITtrạng thái. Nếu tôi cố gắng chạy một chương trình, nó bị treo và tôi phải buộc nó đóng lại, điều này làm tích tụ nhiều CLOSE_WAIT kết nối ổ cắm hơn .
Có cách nào để xóa các kết nối này không?
Câu trả lời:
CLOSE_WAITcó nghĩa là chương trình của bạn vẫn đang chạy và chưa đóng socket (và hạt nhân đang đợi nó làm như vậy). Thêm -pvào netstatđể lấy pid, và sau đó giết nó mạnh hơn ( SIGKILLnếu cần). Điều đó sẽ loại bỏ các CLOSE_WAITổ cắm của bạn . Bạn cũng có thể sử dụng psđể tìm pid.
SO_REUSEADDRdành cho máy chủ và TIME_WAITổ cắm, vì vậy không áp dụng ở đây.
Theo mô tả của Crist Clark .
CLOSE_WAIT có nghĩa là đầu cục bộ của kết nối đã nhận được FIN từ đầu kia, nhưng Hệ điều hành đang đợi chương trình ở đầu cục bộ thực sự đóng kết nối của nó.
Vấn đề là chương trình của bạn đang chạy trên máy cục bộ không đóng ổ cắm. Nó không phải là một vấn đề điều chỉnh TCP. Một kết nối có thể (và khá chính xác) ở trong CLOSE_WAIT mãi mãi trong khi chương trình giữ kết nối mở.
Sau khi chương trình cục bộ đóng ổ cắm, HĐH có thể gửi FIN đến đầu cuối từ xa để chuyển bạn sang LAST_ACK trong khi bạn chờ ACK của FIN. Sau khi nhận được, kết nối sẽ hoàn tất và rơi khỏi bảng kết nối (nếu điểm kết thúc của bạn ở CLOSE_WAIT, bạn không kết thúc ở trạng thái TIME_WAIT).
close()hoặc closesocket(), tùy thuộc vào nền tảng bạn đang sử dụng.
Tôi cũng gặp vấn đề tương tự với máy chủ Tomcat mới nhất (7.0.40). Nó không phản hồi một lần trong một vài ngày.
Để xem các kết nối đang mở, bạn có thể sử dụng:
sudo netstat -tonp | grep jsvc | grep --regexp="127.0.0.1:443" --regexp="127.0.0.1:80" | grep CLOSE_WAIT
Như đã đề cập trong bài đăng này , bạn có thể sử dụng /proc/sys/net/ipv4/tcp_keepalive_timeđể xem các giá trị. Giá trị dường như tính bằng giây và mặc định là 7200 (tức là 2 giờ).
Để thay đổi chúng, bạn cần chỉnh sửa /etc/sysctl.conf.
Open/create `/etc/sysctl.conf`
Add `net.ipv4.tcp_keepalive_time = 120` and save the file
Invoke `sysctl -p /etc/sysctl.conf`
Verify using `cat /proc/sys/net/ipv4/tcp_keepalive_time`
Mặc dù quá nhiều kết nối CLOSE_WAIT có nghĩa là mã của bạn đã xảy ra lỗi trong lần đầu tiên và điều này được chấp nhận là không tốt.
Bạn có thể muốn xem: https://github.com/rghose/kill-close-wait-connections
Những gì tập lệnh này thực hiện là gửi ACK mà kết nối đang chờ đợi.
Đây là những gì làm việc cho tôi.
Cần lưu ý rằng Socketcá thể trong cả máy khách và máy chủ cần phải gọi rõ ràng close(). Nếu chỉ một trong các đầu cuối cũng gọi ra close()thì ổ cắm sẽ vẫn ở trạng thái CLOSE_WAIT.
Bạn có thể buộc phải đóng các socket bằng sslệnh; các sslệnh là một công cụ dùng để đổ thống kê ổ cắm và hiển thị thông tin trong thời trang tương tự (mặc dù đơn giản hơn và nhanh hơn) để netstat.
Để loại bỏ bất kỳ ổ cắm nào ở trạng thái CLOSE_WAIT, hãy chạy cái này (dưới dạng root)
$ ss --tcp state CLOSE-WAIT --kill
Cũng cần lưu ý rằng nếu chương trình của bạn sinh ra một quy trình mới, quy trình đó có thể kế thừa tất cả các chốt đã mở của bạn. Ngay cả sau khi chương trình của riêng bạn bị tắc nghẽn, những tay cầm kế thừa đó vẫn có thể tồn tại thông qua quá trình trẻ mồ côi. Và chúng không nhất thiết phải hiển thị hoàn toàn giống nhau trong netstat. Nhưng tất cả đều giống nhau, socket sẽ treo lơ lửng trong CLOSE_WAIT trong khi tiến trình con này vẫn còn.
Tôi gặp trường hợp đang chạy ADB. Bản thân ADB tạo ra một quy trình máy chủ nếu nó chưa chạy. Điều này kế thừa tất cả các tay cầm của tôi ban đầu, nhưng không hiển thị là sở hữu bất kỳ cái nào trong số chúng khi tôi đang điều tra (điều này cũng đúng cho cả macOS và Windows - không chắc chắn về Linux).