Sử dụng TCP_DEFER_ACCEPT trong thế giới thực?

Tôi đã xem qua hướng dẫn sử dụng Apache httpd trực tuyến và đã gặp một chỉ thị cho phép điều này. Tìm thấy một mô tả trong trang người đàn ông cho tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Sau đó, tôi tìm thấy bài viết này nhưng tôi vẫn chưa rõ loại khối lượng công việc này sẽ hữu ích cho việc gì. Tôi giả định rằng nếu httpdcó một tùy chọn cụ thể cho việc này, thì nó phải có một số liên quan đến các máy chủ web. Tôi cũng giả sử từ thực tế đó là một tùy chọn và không chỉ là cách httpdkết nối mạng, mà có những trường hợp sử dụng mà bạn muốn nó và những người khác mà bạn không.

Ngay cả sau khi đọc bài viết, tôi vẫn chưa rõ lợi thế của việc chờ đợi bắt tay ba cách là gì. Có vẻ thuận lợi để đảm bảo rằng nó sẽ không cần phải trao đổi trong trường hợp có liên quan httpdbằng cách làm như vậy trong khi bắt tay vẫn đang diễn ra thay vì có khả năng gây ra sự chậm trễ đó sau khi kết nối được hình thành.

Đối với bài viết, đối với tôi, dường như bất kể TCP_DEFER_ACCEPTtrạng thái của ổ cắm, bạn vẫn sẽ cần bốn gói (bắt tay sau đó dữ liệu trong mỗi trường hợp). Tôi không biết làm thế nào họ đếm ngược đến ba, cũng như làm thế nào điều đó mang lại sự tăng cường có ý nghĩa.

Vì vậy, câu hỏi của tôi về cơ bản là: Đây chỉ là một tùy chọn lỗi thời hoặc có một trường hợp sử dụng thực tế cho tùy chọn này?

(để tóm tắt ý kiến ​​của tôi về OP)

Cái bắt tay ba chiều mà họ đang đề cập đến là một phần của thiết lập kết nối TCP, tùy chọn trong câu hỏi không liên quan cụ thể đến điều này. Cũng lưu ý rằng trao đổi dữ liệu không phải là một phần của bắt tay ba cách, điều này chỉ tạo ra kết nối TCP ở trạng thái mở / thành lập.

Liên quan đến sự tồn tại của tùy chọn này, đây không phải là hành vi truyền thống của ổ cắm, thông thường luồng xử lý của ổ cắm được đánh thức khi kết nối được chấp nhận (vẫn còn sau khi bắt đầu ba cách bắt đầu) và đối với một số hoạt động giao thức bắt đầu tại đây ( ví dụ: máy chủ SMTP gửi một dòng chào 220), nhưng đối với HTTP, thông điệp đầu tiên trong cuộc trò chuyện là trình duyệt web gửi dòng GET / POST / etc của nó và cho đến khi điều này xảy ra, máy chủ HTTP không quan tâm đến kết nối (ngoài thời gian nó ra), do đó đánh thức quá trình HTTP khi chấp nhận ổ cắm hoàn thành là một hoạt động lãng phí vì quá trình sẽ ngay lập tức ngủ lại để chờ dữ liệu cần thiết.

Mặc dù có lập luận chắc chắn rằng việc đánh thức các quy trình nhàn rỗi có thể khiến chúng 'sẵn sàng' để xử lý thêm (tôi đặc biệt nhớ việc đánh thức các thiết bị đầu cuối đăng nhập trên các máy rất cũ và cho chúng chui từ trao đổi), nhưng bạn cũng có thể lập luận rằng bất kỳ máy nào có hoán đổi quy trình cho biết đã tạo ra nhu cầu đối với tài nguyên của nó và việc thực hiện thêm các nhu cầu không cần thiết có thể làm giảm hiệu suất hệ thống - ngay cả khi hiệu suất rõ ràng của luồng riêng lẻ của bạn cải thiện (điều đó cũng có thể không, một máy cực kỳ bận rộn sẽ bị tắc nghẽn trên đĩa IO. làm chậm những thứ khác nếu bạn đổi chỗ và nếu bận, giấc ngủ ngay lập tức có thể tráo đổi ngay lập tức). Nó dường như là một canh bạc, và cuối cùng, canh bạc 'tham lam' không nhất thiết phải trả giá trên một cỗ máy bận rộn,

Lời khuyên chung của tôi về mức độ điều chỉnh hiệu suất đó là không đưa ra quyết định theo chương trình về điều gì là tốt nhất, nhưng cho phép người quản trị hệ thống và hệ điều hành làm việc cùng nhau để giải quyết các vấn đề quản lý tài nguyên - đó là công việc của họ và họ rất nhiều phù hợp hơn để hiểu khối lượng công việc của toàn bộ hệ thống và hơn thế nữa. Đưa ra lựa chọn và lựa chọn cấu hình.

Để trả lời cụ thể câu hỏi, tùy chọn này có lợi cho tất cả các cấu hình, không phải ở mức độ bạn có thể nhận thấy ngoại trừ tải cực lớn của lưu lượng HTTP, nhưng về mặt lý thuyết là cách "đúng" để thực hiện. Đây là một lựa chọn vì không phải tất cả các hương vị Unix (thậm chí không phải tất cả Linux) đều có khả năng đó, và do đó đối với tính di động, nó có thể được cấu hình không được đưa vào.

Tôi không rõ lợi thế của việc chờ đợi bắt tay ba cách là gì.

Bắt tay ba chiều là một giao thức phổ biến trong điện thoại thoại:

1. Máy chủ : "Xin chào, Epiphyte Corp"
2. Người gọi : "Xin chào, đây là Randy."
3. Máy chủ : "Vâng, tôi có thể giúp gì cho bạn?"
4. Người gọi : cơ thể của cuộc gọi bắt đầu yêu cầu một trò đùa

Chúng rất quan trọng trong TCP để đảm bảo rằng kênh được thiết lập. Nếu Khách hàng bắt đầu gửi nội dung cuộc gọi trước khi nghe (3), có khả năng Máy chủ không nghe hoặc chưa sẵn sàng. Nghe (3) không đảm bảo rằng Máy chủ không bị cháy tự phát ngay sau khi truyền nhưng điều đó làm tăng sự tin cậy mà Máy chủ sẵn sàng nhận.

Như đã lưu ý trong Wikipedia về Bắt tay :

1. Alice [Máy ​​chủ] trả lời bằng tin nhắn xác nhận có số xác nhận y + 1, mà Bob [Client] nhận được và anh ta không cần phải trả lời .

Vì vậy, nếu bạn sẵn sàng từ bỏ một chút chắc chắn rằng máy chủ đã sẵn sàng, Máy chủ có thể bỏ qua bước (3) và khách hàng sẽ chỉ cho rằng máy chủ đã sẵn sàng. Điều này biến việc trao đổi giao thức ở trên thành:

1. Máy chủ : "Xin chào, Epiphyte Corp"
2. Người gọi : "Xin chào, đây là Randy."
3. Người gọi : "Bạn có biết bất kỳ câu chuyện cười nào về Imelda Marcos không?"