[DEV-1765] Set TCP_NODELAY on HttpConnector to disable Nagle's algorithm

[w1am]

NodeConnection::new builds a custom hyper client whose HttpConnector never enables TCP_NODELAY (grpc.rs:897), so Nagle's algorithm stays on for every gRPC connection. Nagle's interaction with delayed ACKs is a documented cause of latency for small request/response traffic like gRPC, with TCP_NODELAY as the standard mitigation.

This sets http.set_nodelay(true), which matches tonic's transport::Channel default. It only affects when small segments are flushed, with no change to TLS, auth, or payload.

Closes #232

Additional resources:

1. https://www.stuartcheshire.org/papers/nagledelayedack/
2. https://learn.microsoft.com/en-us/archive/blogs/nettracer/tcp-delayed-ack-combined-with-nagle-algorithm-can-badly-impact-communication-performance

[linear-code]

DEV-1765

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[qodo-code-review]

PR Summary by Qodo

Enable TCP_NODELAY on gRPC HttpConnector to reduce latency
🐞 Bug fix 🕐 Less than 5 minutes

Walkthroughs

Description

• Enable TCP_NODELAY on the gRPC HttpConnector to avoid Nagle/delayed-ACK latency.
• Align custom hyper client behavior with tonic Channel defaults.
• Reduce tail latency for small gRPC request/response traffic without changing TLS/auth/payload.

Diagram

graph TD
  A["NodeConnection::new"] --> B["HttpConnector"] --> C["TCP socket"]
  B --> D["TCP_NODELAY=true"]

  subgraph Legend
    direction LR
    _fn["Function"] ~~~ _cmp["Component"] ~~~ _net["Network"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Expose TCP_NODELAY as a user-configurable knob

• ➕ Allows opting out for workloads that prefer packet coalescing
• ➕ Provides parity with other transport tuning options
• ➖ Adds API/config surface area and documentation burden
• ➖ Risk of misconfiguration and inconsistent latency behavior across deployments

2. Use tonic::transport::Channel builder directly (avoid custom connector)

• ➕ Inherits tonic defaults (including TCP_NODELAY) and future tuning improvements
• ➕ Reduces custom networking code ownership
• ➖ May not fit existing custom connector layering/behavior requirements
• ➖ Could be a larger refactor than warranted for this specific issue

Recommendation: Setting http.set_nodelay(true) in the existing custom HttpConnector is the best near-term fix: it’s minimal, matches tonic defaults, and addresses the documented Nagle/delayed-ACK latency issue without widening the public API. Consider making it configurable only if future use-cases require toggling.

File Changes

Bug fix (1)

grpc.rs Disable Nagle’s algorithm for gRPC TCP connections +1/-0

Disable Nagle’s algorithm for gRPC TCP connections

• Sets TCP_NODELAY on the hyper HttpConnector created in NodeConnection::new. This reduces latency for small gRPC request/response traffic by preventing Nagle/delayed-ACK interactions.

kurrentdb/src/grpc.rs

---