please show a reproducer for the issue.

I mean, if you're serious:

package main

import (
	"fmt"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprint(w, "Hello World")
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8080", nil)
}

should reproduce the issue just fine.

Can you please post a packet capture of what you are seeing (.pcap, .pcapng or anything that can be opened in wireshark are ideal) and or the benchmark tool that reports 600ms so someone can see the 600ms results you are seeing on their machine ?
The code you sent implements HTTP 1.1 and net/http tries really hard to not rely on FIN for signaling the end of requests (ideally we use Content-Length to signal end of requests, else chunked encoding is used, and then if neither are possible then we close the TCP connection).

It is important to eliminate that we are not waiting ~600ms because the HTTP server wants to allow the client to reuse the TCP stream to send an other HTTP request which a non HTTP 1.1 compliant benchmarking tool would incorrectly understand as the server being slow.

@Jorropo:

Can you please post a packet capture of what you are seeing

I can get some more packet captures, I didn't keep them around.

The code you sent implements HTTP 1.1 and net/http tries really hard to not rely on FIN for signaling the end of requests (ideally we use Content-Length to signal end of requests, else chunked encoding is used, and then if neither are possible then we close the TCP connection).

It appears to be just about any socket, h2, grpc, etc (though I haven't tested raw tcp sockets specifically).

Thanks for pointing out content-length, I'll give that a test as well to see if it improves things. It's also a bit worrisome since once a stream is closed you aren't getting any more data out of it, even if content-length says there is more data.

It is important to eliminate that we are not waiting ~600ms because the HTTP server wants to allow the client to reuse the TCP stream to send an other HTTP request which a non HTTP 1.1 compliant benchmarking tool would incorrectly understand as the server being slow.

I may be wrong, as I'm not a network engineer, by any means, but IIRC, once a FIN packet is sent, the client cannot send any more data even if it wanted to; at least on that connection.

I'll write some low-level clients in C so we can better test this as well. I'd also like to rule out network hardware, if at all possible.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)