TCP window reduces due to slow reads but not increases later
A program is downloading a large file via HTTPS (50M). It's fast until at some time (~30M) it slows down significantly, never resuming.
From the capture file I see that the receive window gets full, then it reduces to 384 or so. It never resumes. The receive queue is clear as I can see with netstat -npt. This doesn't happen with wget the same URL (no window full; wget downloads smoothly to the end).
I don't understand why the receive window doesn't increase after the data has been read?
Here is the capture file: https://mega.nz/#!el1B3SRR!gERqKWq30x...
Here is the program (in Go):
package main
import (
"io/ioutil"
"net/http"
)
func main() {
resp, _ := http.Get("A URL here")
ioutil.ReadAll(resp.Body)
}
This is a Linux box kernel version 4.15.0-1023-aws.
I don't know why the receive window doesn't open up either, but I am suspicious of Frame #18915. That frame contains a TCP segment of size 29200, which is exactly ten times the size of many of the other segments sent since the last ACK from 172.26.10.241 in Frame 18888. The capture appears to be taken at 13.107.236.9 so these large segments will be split into separate segments of 1440 bytes each (or less for the last segment of the data), as that's the MSS, which can be seen during the TCP handshake in Frame 2.
There are other also other frames (568, 7724, 14615 and 14675) with a segment size of 14600, again exactly ten times typical segment sizes of 1460 bytes seen in the capture file, although none of those seem to be problematic. Perhaps the 10x factor is ...(more)
It's not possible to capture on the other side because that's a Microsoft service. I could have tried other downloads but this is not my aws account. I saw this in a chat group but the asker had lost patience and destroyed the node. This issue is weird to me I'm curious so I asked here.
Do you mean the kernel or the application? I tried to search but didn't see anything like a kernel bug. IIUC it's ok for the application to handle incoming data at its own pace, and the connection should slow down to the speed of its consumption, not too slow and never back.