Việc tiếp tục sử dụng tùy chọn TCP_NODELAY

 (brooker.co.za)
2 điểm bởi GN⁺ 2024-05-10 | 1 bình luận | Chia sẻ qua WhatsApp

Tầm quan trọng của cấu hình TCP_NODELAY

  • Khi gỡ lỗi các vấn đề về độ trễ trong hệ thống phân tán, điều đầu tiên cần kiểm tra là liệu tùy chọn TCP_NODELAY có được bật hay không
  • Nhiều nhà phát triển hệ thống phân tán đã có trải nghiệm giải quyết nhanh các vấn đề về độ trễ chỉ bằng cách bật tùy chọn socket đơn giản này
  • Điều này cho thấy hành vi mặc định có thể chưa phù hợp hoặc toàn bộ khái niệm này có thể đã lỗi thời

Bối cảnh và vấn đề của thuật toán Nagle

  • Thuật toán Nagle, lần đầu được đề xuất trong RFC896 của John Nagle vào năm 1984, nhằm mục tiêu khấu hao chi phí của header TCP tốt hơn để đạt được thông lượng mạng cao hơn
  • Thuật toán Nagle hoạt động bằng cách ngăn việc truyền các segment TCP mới nếu chưa nhận được ACK cho dữ liệu đã gửi trước đó
  • Tuy nhiên, điều này gây ra vấn đề khi tương tác với delayed ACK
    • Thuật toán Nagle chặn việc gửi thêm dữ liệu cho đến khi nhận được ACK, trong khi delayed ACK lại trì hoãn ACK cho đến khi có phản hồi sẵn sàng
    • Điều này tốt cho việc lấp đầy gói tin, nhưng không phù hợp với các ứng dụng pipeline nhạy cảm với độ trễ

Sự cần thiết của thuật toán Nagle trong các hệ thống hiện đại

  • Máy chủ hiện đại có thể xử lý khối lượng công việc rất lớn trong vòng vài trăm micro giây, nên việc trì hoãn truyền dữ liệu dù chỉ một RTT cũng có thể không mang lại lợi ích rõ ràng
  • Hầu hết cơ sở dữ liệu phân tán và các hệ thống phân tán không gửi các gói chỉ có một byte
    • Điều này là do có nhiều dữ liệu cần truyền hơn, cùng với overhead của các giao thức như TLS và overhead từ mã hóa và tuần tự hóa
  • Việc tránh gửi các thông điệp nhỏ vẫn rất quan trọng, nhưng hiện nay điều đó đang được xử lý hiệu quả ở tầng ứng dụng

Quan điểm về việc sử dụng TCP_NODELAY

  • Khi xây dựng các hệ thống phân tán nhạy cảm với độ trễ, có thể bật TCP_NODELAY (tắt thuật toán Nagle) mà không cần quá lo lắng
  • Trong các hệ thống hiện đại, khi xét đến lưu lượng, tổ hợp ứng dụng và hiệu năng phần cứng, thuật toán Nagle có thể không còn cần thiết
    • Nói cách khác, TCP_NODELAY nên trở thành giá trị mặc định
    • Điều này có thể làm chậm một số đoạn mã kiểu "ghi mọi byte", nhưng nếu bạn thực sự coi trọng hiệu quả thì dù sao cũng nên sửa ứng dụng đó

Ý kiến của GN⁺

  • Vấn đề tương tác giữa thuật toán Nagle và delayed ACK là một ví dụ điển hình cho thấy thiết kế giao thức khó đến mức nào. Tình huống hai tính năng hợp lý lại tạo ra hành vi ngoài ý muốn là điều mà các nhà thiết kế hệ thống sẽ thấy quen thuộc.

  • Tối ưu hóa việc truyền các thông điệp nhỏ ở tầng ứng dụng đang là xu hướng phổ biến. Việc giảm thiểu overhead không cần thiết thông qua mã hóa và tuần tự hóa hiệu quả là rất quan trọng.

  • Nếu mục tiêu của thuật toán Nagle là tối ưu băng thông mạng, thì ngày nay việc giảm thiểu độ trễ mới là yêu cầu quan trọng hơn. Trong những tình huống mà khả năng phản hồi của ứng dụng gắn trực tiếp với trải nghiệm người dùng, cần tránh các độ trễ không cần thiết.

  • Tuy nhiên, việc đặt TCP_NODELAY làm mặc định có thể không lý tưởng trong mọi tình huống. Với các môi trường bị giới hạn băng thông, hoặc các hệ thống mà hiệu quả truyền dẫn quan trọng hơn nhiều so với độ trễ, vẫn có thể cần sử dụng thuật toán Nagle một cách có chọn lọc.

  • Khi thiết kế giao thức mạng, điều quan trọng là phải cân bằng giữa nhiều yêu cầu khác nhau. Việc thay đổi hành vi mặc định của một giao thức dùng chung cần được cân nhắc thận trọng, nhưng cũng cần có sự linh hoạt để chọn tùy chọn phù hợp với nhu cầu của ứng dụng.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-10
Bình luận trên Hacker News

Tóm tắt:

  • Thuật toán Nagle là một nỗ lực gom lô khi ghi, và trong một số trường hợp, việc ghi theo lô sẽ tốt hơn bất kể phần cứng, mạng, ứng dụng hay trường hợp sử dụng
  • Ngày nay nhiều hệ thống tính toán sử dụng ghi theo lô, và các giao thức cấp cao mới như QUIC cũng thực hiện gom lô ghi, chuyển phần xử lý kết nối độc lập và lỗi của TCP lên không gian người dùng
  • Khi mạng bị bão hòa, thuật toán Nagle sẽ quay trở lại sâu hơn trong mã ứng dụng dưới dạng các điều chỉnh kiểu QUIC
  • Thuật toán Nagle cũng hữu ích khi số gói trên giây (PPS) bị bão hòa do các gói nhỏ
  • Thuật toán Nagle không hoạt động tốt với một số khối lượng công việc, nên tốt hơn là buộc kỹ sư phải thiết lập nó khi tạo socket
  • Có thể vô hiệu hóa delayed ACK bằng tùy chọn socket TCP_QUICKACK hoặc dùng /proc/sys/net/ipv4/tcp_delack_min và /proc/sys/net/ipv4/tcp_ato_min
  • Trong một thế giới bị giới hạn băng thông, gửi một gói TCP cho từng byte là lãng phí băng thông, vì vậy cần có thuật toán Nagle
  • Vẫn chưa có cách tốt để bật TCP_NODELAY nếu không có quyền truy cập vào mã nguồn ứng dụng
  • Các ngôn ngữ hiện đại như Go bật TCP_NODELAY theo mặc định nên vấn đề này không xảy ra
  • Nếu có cách để ứng dụng báo cho TCP stack biết rằng nó là một shell tương tác, thì có thể để TCP_NODELAY mặc định tắt và chỉ bật cho ứng dụng đó để giảm overhead