this post was submitted on 15 Sep 2024
19 points (100.0% liked)

Data Structures and Algorithms

165 readers
1 users here now

A community dedicated to topics related to data structures and algorithms.

founded 7 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] lysdexic@programming.dev 1 points 1 month ago* (last edited 1 month ago) (1 children)

The only think that TCP_NODELAY does is disabling packet batching/merging through Naggle's algorithm. Supposedly that increases throughput by reducing the volume of redundant information required to send small data payloads in individual packets, with the tradeoff of higher latency. It's a tradeoff between latency and throughput. I don't see any reason for transfer rates to lower; quite the opposite. In fact the very few benchmarks I saw showed exactly that: TCP_NODELAY causing a drop in the transfer rate.

There are also articles on the cargo cult behind TCP_NODELAY.

But feel free to show your data.

[–] BB_C@programming.dev -3 points 1 month ago (1 children)

You clearly have no idea what ping-pong protocol means.

[–] DahGangalang@infosec.pub 1 points 1 month ago (1 children)
[–] BB_C@programming.dev 4 points 1 month ago

I specifically mentioned HTTP/2 because it should have been easy for everyone to both test and find the relevant info.

But anyway, here is a short explanation, and the curl-library thread where the issue was first encountered.

You should also find plenty of blog posts where "unexplainable delay"/"unexplainable slowness"/"something is stuck" is in the premise, and then after a lot of story development and "suspense", the big reveal comes that it was Nagle's fault.

As with many things TCP. A technique that may have been useful once, ends up proving to be counterproductive when used with modern protocols, workflows, and networks.