Enabling the TCP_NODELAY option turns Nagle's algorithm off. In the case of interactive applications or chatty protocols with a lot of handshakes such as SSL, Citrix and Telnet, Nagle's algorithm can cause a drop in performance, whereas enabling TCP_NODELAY can improve the performance.
In any request-response application protocols where request data can be larger than a packet, this can artificially impose a few hundred milliseconds latency between the requester and the responder, even if the requester has properly buffered the request data. Nagle's algorithm should be disabled by enabling TCP_NODELAY by the requester in this case. If the response data can be larger than a packet, the responder should also disable Nagle's algorithm by enabling TCP_NODELAY so the requester can promptly receive the whole response.
Consider we are performing a lot of TLS/HTTP handshakes over Realm, I think it's a good trade-off.
Tokio has provided a convenient API: tokio::net::TcpStream::set_nodelay. To set the TCP_NODELAY socket option, we just need to invoke that fn right after connect() or accept().
zhboner
commented
3 years ago
From https://www.extrahop.com/company/blog/2016/tcp-nodelay-nagle-quickack-best-practices/
Consider we are performing a lot of TLS/HTTP handshakes over Realm, I think it's a good trade-off.
Tokio has provided a convenient API:
tokio::net::TcpStream::set_nodelay. To set theTCP_NODELAYsocket option, we just need to invoke that fn right afterconnect()oraccept().