Bao lâu tôi có thể mong đợi kết nối TCP của máy khách/máy chủ cuối cùng trong tự nhiên?Cuộc sống kết nối TCP
Tôi muốn nó luôn kết nối vĩnh viễn, nhưng mọi thứ xảy ra, vì vậy khách hàng sẽ phải kết nối lại. Tại thời điểm nào tôi nói rằng có một vấn đề trong mã thay vì có một vấn đề với một số thiết bị bên ngoài?
Tôi đồng ý với Zan Lynx. Không có gì đảm bảo, nhưng bạn có thể duy trì kết nối gần như vô thời hạn bằng cách gửi dữ liệu qua nó, giả sử không có vấn đề về kết nối hoặc băng thông.
Nói chung tôi đã đi cho tiếp cận mức ứng dụng tiếp tục sống, mặc dù điều này thường là vì nó nằm trong thông số khách hàng nên tôi phải làm điều đó. Nhưng chỉ cần gửi một số dữ liệu ngắn mỗi phút hoặc hai, mà bạn mong đợi một số loại xác nhận.
Cho dù bạn đếm một lỗi không thừa nhận vì kết nối không thành công tùy thuộc vào bạn. Nói chung đây là những gì tôi đã làm trong quá khứ, mặc dù đã có một trường hợp tôi đã chờ đợi ba câu trả lời thất bại liên tiếp để thả kết nối vì ứng dụng ở đầu kia của kết nối cực kỳ lúng túng khi trả lời "bạn có ở đó không ? " yêu cầu.
Nếu kết nối không thành công, tại một số điểm có thể, ngay cả với các máy trên cùng một mạng, thì chỉ cần cố gắng thiết lập lại nó. Nếu điều đó không thành công, bạn có vấn đề. Nếu kết nối của bạn liên tục bị lỗi sau khi kết nối được một lúc thì bạn lại gặp sự cố. Rất có thể trong cả hai trường hợp, đó có thể là sự cố mạng, thay vì mã của bạn hoặc có thể là sự cố với ngăn xếp TCP/IP trên máy của bạn (đã được biết: Tôi gặp sự cố với phiên bản cũ của QNX - nó đã xảy ra chỉ ngẫu nhiên rơi xuống). Có nói rằng bạn có thể có một vấn đề phần mềm, và cách duy nhất để biết chắc chắn thường là để đính kèm một trình gỡ lỗi, hoặc để có được một số đăng nhập ở đó. Ví dụ. nếu bạn luôn có thể kết nối thành công, nhưng sau một thời gian bạn ngừng nhận ACK, ngay cả sau khi kết nối lại, thì có thể máy chủ của bạn bị bế tắc hoặc bị kẹt trong vòng lặp hoặc thứ gì đó. Điều gì thực sự hữu ích là để thiết lập một loạt các bài kiểm tra chạy dài trong một loạt các điều kiện tải, từ chỉ gửi giữ sống là bạn có?/Ack yêu cầu và phản ứng, để hoàn toàn đập máy chủ.Điều này nói chung sẽ giúp bạn tự tin hơn về các thành phần phần mềm của bạn, và có thể thực sự hữu ích trong việc làm nổi bật một số vấn đề thực sự kỳ lạ mà không nhất thiết gây ra vấn đề với kết nối của bạn, mặc dù chúng có thể dẫn đến các vấn đề xảy ra. Ví dụ, tôi đã từng viết một máy chủ ứng dụng viễn thông cung cấp các dịch vụ như dịch số, và chúng tôi chỉ để nó hoạt động trong nhiều ngày tại một thời điểm. Vấn đề là khi thứ bảy đến vòng, cả ngày, nó sẽ từ chối mọi yêu cầu cuộc gọi đến, mà lên đến hàng triệu cuộc gọi, và chúng tôi không biết tại sao. Hóa ra là do một lỗi chính tả trong một số mã chuyển đổi ngày chỉ gây ra sự cố vào thứ Bảy.
Hy vọng điều đó sẽ hữu ích.
Nó không thực sự quan trọng, bạn nên thiết kế mã của bạn để tự động kết nối lại nếu đó là hành vi mong muốn.
Thực sự không có cách nào để nói. Không có gì vốn có đối với TCP có thể khiến kết nối chỉ giảm sau một khoảng thời gian nhất định. Một người nào đó trên một kết nối đáng tin cậy có thể có nhiều thời gian hoạt động, trong khi một người nào đó trên một kết nối khác nhau có thể phải kết nối lại sau mỗi 5 phút. Không có cách nào để nói hoặc thậm chí đoán.
Chọn một giá trị. Một giọt mỗi giờ có lẽ là tốt. Mười kết nối không mong muốn giảm xuống trong 5 phút có thể cho thấy có vấn đề.
Kết nối TCP thường sẽ kéo dài khoảng hai giờ mà không có bất kỳ lưu lượng truy cập nào. Hoặc là kết thúc có thể gửi các gói dữ liệu tồn tại, đó là, tôi nghĩ, chỉ là một ACK trên gói nhận được cuối cùng. Điều này thường có thể được đặt cho mỗi ổ cắm hoặc theo mặc định trên mọi kết nối TCP.
Cũng có thể duy trì mức ứng dụng. Đối với giao thức kiểu telnet như FTP, SMTP, POP hoặc IMAP, chẳng hạn như gửi trả lại, dòng mới và nhận lại lời nhắc lệnh.
TCP keepalive là bộ đếm thời gian thay đổi theo Hệ điều hành, do đó, 2 giờ có thể thay đổi trong các môi trường cụ thể. – benc
Bạn sẽ cần một số dữ liệu đi qua kết nối định kỳ để duy trì trạng thái hoạt động - nhiều hệ điều hành hoặc tường lửa sẽ thả kết nối không hoạt động.
Tôi nghĩ ý tưởng quan trọng nhất ở đây là lý thuyết so với thực hành.
Lý thuyết ban đầu là các kết nối không có thời gian sống. Nếu bạn có một kết nối, nó vẫn mở mãi mãi, ngay cả khi không có giao thông, cho đến khi một sự kiện khiến nó đóng cửa.
Lý thuyết mới là hầu hết các bản phát hành hệ điều hành đã bật hẹn giờ tiếp tục hoạt động. Điều này có nghĩa là các kết nối sẽ tồn tại mãi mãi, miễn là hệ thống ở đầu bên kia phản hồi một trao đổi cấp TCP không thường xuyên.
Trong thực tế, nhiều kết nối sẽ bị chấm dứt sau thời gian, với nhiều tiêu chí và tình huống khác nhau.
Hai ví dụ thực sự tốt là: Máy khách từ xa đang sử dụng DHCP, thời gian thuê hết hạn và thay đổi địa chỉ IP.
Ví dụ khác là tường lửa có vẻ ngày càng thông minh và có thể xác định lưu lượng truy cập lưu động so với dữ liệu thực và kết nối chặt chẽ dựa trên bất kỳ tiêu chí cấp cao nào, đặc biệt là thời gian rảnh.
Cách bạn muốn triển khai logic kết nối lại phụ thuộc rất nhiều vào kiến trúc của bạn, môi trường làm việc và mục tiêu hiệu suất của bạn.
mãi mãi nếu bạn có khoảng thời gian KeepAlive chính xác, có liên quan: http://stackoverflow.com/questions/3907537/keep-alive-tcp-ip-connected-sockets-over-the-internet-when-how-and- how-much/5149662 # 5149662 – markmnl
Những gì mọi người trả lời vào năm 1999: https://ask.slashdot.org/story/99/09/19/2150236/longest-open-tcp-connection – user3041714