Tôi nghĩ rằng tôi hiểu ý nghĩa chính thức của tùy chọn. Trong một số mã kế thừa mà tôi đang xử lý bây giờ, tùy chọn được sử dụng. Khách hàng phàn nàn về RST là phản hồi đối với FIN từ phía họ khi kết nối gần với phía họ.
Tôi không chắc mình có thể gỡ bỏ nó một cách an toàn, vì tôi không hiểu khi nào thì nên sử dụng nó.
Bạn có thể vui lòng cho một ví dụ về thời điểm tùy chọn sẽ được yêu cầu?
Câu trả lời:
Lý do điển hình để đặt SO_LINGERthời gian chờ bằng 0 là để tránh số lượng lớn các kết nối đang ở TIME_WAITtrạng thái, buộc tất cả các tài nguyên có sẵn trên một máy chủ.
Khi kết nối TCP được đóng hoàn toàn, phần cuối bắt đầu quá trình đóng ("hoạt động đóng") sẽ kết thúc với việc kết nối ở trong TIME_WAITvài phút. Vì vậy, nếu giao thức của bạn là một trong đó máy chủ khởi tạo kết nối đóng và liên quan đến số lượng rất lớn các kết nối tồn tại trong thời gian ngắn, thì nó có thể dễ bị sự cố này.
Tuy nhiên, đây không phải là một ý tưởng hay - TIME_WAITtồn tại là có lý do (để đảm bảo rằng các gói tin lạc từ các kết nối cũ không gây trở ngại cho các kết nối mới). Tốt hơn hết là bạn nên thiết kế lại giao thức của mình thành một giao thức mà máy khách bắt đầu đóng kết nối, nếu có thể.
TIME_WAITchí ngồi vào khách hàng không gây hại gì. Hãy nhớ như nó nói trong "Lập trình mạng UNIX" ấn bản thứ ba (Stevens và cộng sự) trang 203: "Trạng thái TIME_WAIT là bạn của bạn và ở đó để giúp chúng tôi. Thay vì cố gắng tránh trạng thái, chúng ta nên hiểu nó (Phần 2.7) . "
Đối với đề xuất của tôi, vui lòng đọc phần cuối cùng: “Khi nào sử dụng SO_LINGER với thời gian chờ 0” .
Trước khi chúng ta đến với bài giảng nhỏ về:
TIME_WAITFIN, ACKvàRSTTrình tự kết thúc TCP bình thường trông giống như sau (đơn giản hóa):
Chúng tôi có hai đồng nghiệp: A và B
close()
FINcho BFIN_WAIT_1trạng tháiFIN
ACKcho ACLOSE_WAITtrạng tháiACK
FIN_WAIT_2trạng tháiclose()
FINcho ALAST_ACKtrạng tháiFIN
ACKcho BTIME_WAITtrạng tháiACK
CLOSEDtrạng thái - tức là bị xóa khỏi bảng socketVì vậy, peer bắt đầu kết thúc - tức là các cuộc gọi close()trước - sẽ kết thúc ở TIME_WAITtrạng thái.
Để hiểu tại sao TIME_WAITnhà nước là bạn của chúng ta, vui lòng đọc phần 2.7 trong "Lập trình mạng UNIX" ấn bản thứ ba của Stevens và cộng sự (trang 43).
Tuy nhiên, nó có thể là một vấn đề với nhiều ổ cắm ở TIME_WAITtrạng thái trên một máy chủ vì nó cuối cùng có thể ngăn các kết nối mới được chấp nhận.
Để giải quyết vấn đề này, tôi đã thấy nhiều người đề xuất đặt tùy chọn ổ cắm SO_LINGER với thời gian chờ 0 trước khi gọi close(). Tuy nhiên, đây là một giải pháp không tốt vì nó khiến kết nối TCP bị lỗi.
Thay vào đó, hãy thiết kế giao thức ứng dụng của bạn để việc kết thúc kết nối luôn được bắt đầu từ phía máy khách. Nếu máy khách luôn biết khi nào nó đã đọc tất cả dữ liệu còn lại, nó có thể bắt đầu trình tự kết thúc. Ví dụ, một trình duyệt biết từ Content-Lengthtiêu đề HTTP khi nó đã đọc tất cả dữ liệu và có thể bắt đầu đóng. (Tôi biết rằng trong HTTP 1.1, nó sẽ giữ nó mở trong một thời gian để có thể sử dụng lại và sau đó đóng nó.)
Nếu máy chủ cần đóng kết nối, hãy thiết kế giao thức ứng dụng để máy chủ yêu cầu máy khách gọi close().
Một lần nữa, theo "Lập trình mạng UNIX" phiên bản thứ ba trang 202-203, việc thiết lập SO_LINGERthời gian chờ 0 trước khi gọi close()sẽ khiến trình tự kết thúc bình thường không được bắt đầu.
Thay vào đó, thiết lập ngang hàng tùy chọn này và gọi close()sẽ gửi RST(đặt lại kết nối) cho biết điều kiện lỗi và đây là cách nó sẽ được nhận biết ở đầu bên kia. Bạn thường sẽ thấy các lỗi như "Thiết lập lại kết nối bởi ngang hàng".
Do đó, trong tình huống bình thường, thực sự là một ý tưởng tồi nếu đặt SO_LINGERthời gian chờ là 0 trước khi gọi close()- từ bây giờ được gọi là đóng hủy bỏ - trong một ứng dụng máy chủ.
Tuy nhiên, dù sao thì một số tình huống nhất định cũng đảm bảo làm như vậy:
CLOSE_WAIThoặc kết thúc ở TIME_WAITtrạng thái.TIME_WAIT(khi gọi close()từ cuối máy chủ) vì điều này có thể ngăn máy chủ nhận được các cổng khả dụng cho các kết nối máy khách mới sau khi được khởi động lại.CLOSE_WAITcố gắng cung cấp dữ liệu đến một thiết bị đầu cuối bị kẹt nhưng sẽ đặt lại đúng cách cổng bị kẹt nếu nó có RSTquyền loại bỏ dữ liệu đang chờ xử lý. "Tôi muốn giới thiệu này bài viết dài mà tôi tin rằng đưa ra một câu trả lời rất tốt cho câu hỏi của bạn.
TIME_WAITchỉ là bạn khi nó không bắt đầu gây ra vấn đề: stackoverflow.com/questions/1803566/…
Khi nán lại được bật nhưng thời gian chờ bằng 0, ngăn xếp TCP không đợi dữ liệu đang chờ được gửi trước khi đóng kết nối. Dữ liệu có thể bị mất do điều này nhưng bằng cách cài đặt kéo dài theo cách này, bạn đang chấp nhận điều này và yêu cầu kết nối được đặt lại ngay lập tức thay vì đóng một cách dễ dàng. Điều này khiến RST được gửi thay vì FIN thông thường.
Cảm ơn EJP đã bình luận, xem chi tiết tại đây .
Việc bạn có thể loại bỏ phần còn sót lại trong mã của mình một cách an toàn hay không phụ thuộc vào loại ứng dụng của bạn: đó là “máy khách” (mở kết nối TCP và chủ động đóng nó trước) hay là “máy chủ” (nghe TCP mở và đóng nó sau khi bên kia bắt đầu đóng)?
Nếu ứng dụng của bạn có hương vị của một “máy khách” (đóng trước) VÀ bạn khởi tạo và đóng một số lượng lớn các kết nối đến các máy chủ khác nhau (ví dụ: khi ứng dụng của bạn là một ứng dụng giám sát giám sát khả năng truy cập của một số lượng lớn các máy chủ khác nhau) thì ứng dụng của bạn có vấn đề là tất cả các kết nối máy khách của bạn bị kẹt ở trạng thái TIME_WAIT. Sau đó, tôi khuyên bạn nên rút ngắn thời gian chờ xuống giá trị nhỏ hơn giá trị mặc định để vẫn tắt một cách duyên dáng nhưng giải phóng tài nguyên kết nối máy khách sớm hơn. Tôi sẽ không đặt thời gian chờ thành 0, vì 0 không tắt một cách duyên dáng với FIN nhưng hủy bỏ với RST.
Nếu ứng dụng của bạn có hương vị của một “máy khách” và phải tìm nạp một lượng lớn tệp nhỏ từ cùng một máy chủ, bạn không nên khởi tạo kết nối TCP mới trên mỗi tệp và kết thúc bằng một lượng lớn kết nối máy khách trong TIME_WAIT, nhưng giữ cho kết nối luôn mở và tìm nạp tất cả dữ liệu qua cùng một kết nối. Tùy chọn nán lại có thể và nên được loại bỏ.
Nếu ứng dụng của bạn là “máy chủ” (đóng thứ hai khi phản ứng với ứng dụng đóng của ứng dụng ngang hàng), khi đóng () kết nối của bạn sẽ tắt một cách duyên dáng và tài nguyên được giải phóng khi bạn không vào trạng thái TIME_WAIT. Nán lại không nên được sử dụng. Nhưng nếu ứng dụng sever của bạn có một quy trình giám sát phát hiện các kết nối mở không hoạt động ở chế độ chờ trong một thời gian dài (định nghĩa là "dài"), bạn có thể tắt kết nối không hoạt động này từ phía mình - xem nó như một loại xử lý lỗi - với việc tắt tạm thời. Điều này được thực hiện bằng cách đặt thời gian chờ kéo dài thành 0. close () sau đó sẽ gửi RST cho khách hàng, nói với anh ta rằng bạn đang tức giận :-)
Trong máy chủ, bạn có thể muốn gửi RSTthay vì FINkhi ngắt kết nối các máy khách hoạt động sai. Điều đó bỏ qua FIN-WAITtheo sau là TIME-WAITtrạng thái ổ cắm trong máy chủ, điều này ngăn chặn việc làm cạn kiệt tài nguyên máy chủ và do đó, bảo vệ khỏi loại tấn công từ chối dịch vụ này.
Tôi thích quan sát của Maxim rằng các cuộc tấn công DOS có thể làm cạn kiệt tài nguyên máy chủ. Nó cũng xảy ra mà không có kẻ thù thực sự độc hại.
Một số máy chủ phải đối phó với 'cuộc tấn công DOS không chủ ý' xảy ra khi ứng dụng khách có lỗi rò rỉ kết nối, nơi chúng tiếp tục tạo kết nối mới cho mọi lệnh mới mà chúng gửi đến máy chủ của bạn. Và sau đó có lẽ cuối cùng sẽ đóng các kết nối của họ nếu họ gặp phải áp lực GC, hoặc có lẽ các kết nối cuối cùng đã hết thời gian.
Một kịch bản khác là khi "tất cả các máy khách có cùng một địa chỉ TCP". Sau đó, các kết nối máy khách chỉ có thể phân biệt được bằng số cổng (nếu chúng kết nối với một máy chủ duy nhất). Và nếu các máy khách bắt đầu xoay vòng nhanh chóng các kết nối mở / đóng vì bất kỳ lý do gì, chúng có thể làm cạn kiệt bộ không gian (cổng thêm + cổng, IP máy chủ + cổng).
Vì vậy, tôi nghĩ rằng các máy chủ có thể được khuyên tốt nhất nên chuyển sang chiến lược Linger-Zero khi chúng thấy số lượng ổ cắm cao ở trạng thái TIME_WAIT - mặc dù nó không khắc phục được hành vi của máy khách, nhưng nó có thể làm giảm tác động.
Ổ cắm lắng nghe trên máy chủ có thể sử dụng kéo dài với thời gian 0 để có quyền truy cập liên kết trở lại ổ cắm ngay lập tức và để đặt lại bất kỳ máy khách nào có kết nối chưa kết nối xong. TIME_WAIT là một cái gì đó chỉ thú vị khi bạn có một mạng đa đường và có thể kết thúc với các gói không có thứ tự hoặc nếu không thì đang xử lý thứ tự gói / thời gian đến của mạng lẻ.