In these situations I would normally use wireshark to look at the life-cycle of a single session. Which direction are the FIN and RST packets going? Are they sent from the client, or the server? If the RST packets are sent by the server - i.e. the server is slamming shut the connection, then the client can not reuse them and has to create new ones.
If foo is https, then this does make it harder to use tcpdump to look at the headers. But you can print out the response headers sent bt foo.com using https://golang.org/pkg/net/http/httputil/#DumpResponse and this should give you a bit more information. Hope this helps... - Amnon On Thursday, 7 May 2020 15:13:04 UTC+1, Ryan Rank wrote: > > This is what I did, and see no change in behavior. > > for i := 0; i < 10; i++ { > response, err :=client.Get("https://foo.com";) > if err!= nil{ > panic(err) > } > ioutil.ReadAll(response.Body) > response.Body.Close() > } > > The network trace shows a SYN, SYN-ACK, ACK at the beginning of each HTTP > GET, and a FIN-ACK followed by some RST packets (those RSTs are common for > the foo.com in this case). > > I do know that foo.com honors keepalives because it's readily apparent > when I use *ab *to test. > > Also, I did upgrade to go 1.14.2 and nothing changed. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/33d4eca3-e80a-458b-9cdd-51fe6b674632%40googlegroups.com.
