Server response sending triggers Nagle's algorithm/delayed ACK interaction #199
Comments
kyrias
added a commit
to kyrias/tide
that referenced
this issue
Sep 9, 2022
Due to the way the `async-h1` crate writes HTTP responses to the `TcpStream` the head and body end up in separate write calls to the underlying socket. If we're responding to more than one request received from the same `TcpStream` it means that we did two sends and then tried to read. That read can take up to 500 milliseconds to complete due to bad interactions between Nagle's algorithm and delayed ACK. (In practice this is 40 ms on Linux.) Disabling Nagle's algorithm works around this until `async-h1` is fixed. http-rs/async-h1#199 Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
kyrias
added a commit
to kyrias/async-h1
that referenced
this issue
Dec 30, 2022
Fixes http-rs#199. Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The way the
async-h1encoder streams the HTTP response head and body to the givenio: Writecauses the head and body to be written to the underlying socket as separate calls tosend, causing them to be sent as separate TCP segments.If we're handling more than one HTTP request from the same
iothat means that we're doing two sends and then a read. This I/O pattern triggers a bad interaction between Nagle's algorithm and delayed ACK where the read can take up to 500 milliseconds. (On Linux this is 40 milliseconds.)A work-around for this is to enable
TCP_NODELAYto disable Nagle's algorithm, but we shouldn't really be sending undersized TCP segment unnecessarily.The text was updated successfully, but these errors were encountered: