Revision history [back]

Some preliminary information:

• Browser - Firefox 104.0 (64-bit)
• Server - Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

(Apparently I cannot attach the wireshark pcap until I have >60 something, so I'll put the pertinent packet bytes here)

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000 10.0.0.188  10.0.0.225  TCP 74  43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSecr=0 WS=128
2   0.001635595 10.0.0.225  10.0.0.188  TCP 66  80 → 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001674970 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001751029 10.0.0.188  10.0.0.225  HTTP    451 GET /js/math.min.js HTTP/1.1 
5   0.004238756 10.0.0.225  10.0.0.188  TCP 60  80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=0
6   0.024392047 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024405659 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8   0.038481649 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1461 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9   0.038494319 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10  0.052616814 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=2921 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11  0.052638389 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0

.... (skipped some packets for brevity) ....

No. Time    Source  Destination Protocol    Length  Info
72  1.220794991 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=48181 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73  1.266740106 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74  1.280819523 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=49641 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75  1.301652905 10.0.0.188  10.0.0.225  TCP 74  43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSecr=0 WS=128
76  1.303284866 10.0.0.225  10.0.0.188  TCP 66  80 → 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77  1.303316377 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78  1.303445281 10.0.0.188  10.0.0.225  HTTP    399 GET /favicon.ico HTTP/1.1 
79  1.305447545 10.0.0.225  10.0.0.188  TCP 150 80 → 43074 [ACK] Seq=1 Ack=1 Win=186880 Len=96 [TCP segment of a reassembled PDU]
80  1.305467257 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81  1.306119233 10.0.0.225  10.0.0.188  HTTP    60  HTTP/1.1 503 Service Unavailable 
82  1.306246772 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [FIN, ACK] Seq=346 Ack=98 Win=64256 Len=0
83  1.307186083 10.0.0.225  10.0.0.188  TCP 60  80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84  1.322753934 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
85  1.336850281 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=51101 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86  11.290742683    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0

Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.

P.S. Is there a way to debug the browser to see why is didn't ACK?

Some preliminary information:

• Browser - Browser: Firefox 104.0 (64-bit)
• Server - Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

(Apparently I cannot attach the wireshark pcap until I have >60 something, so I'll put the pertinent packet bytes here)

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000 10.0.0.188  10.0.0.225  TCP 74  43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSecr=0 WS=128
2   0.001635595 10.0.0.225  10.0.0.188  TCP 66  80 → 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001674970 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001751029 10.0.0.188  10.0.0.225  HTTP    451 GET /js/math.min.js HTTP/1.1 
5   0.004238756 10.0.0.225  10.0.0.188  TCP 60  80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=0
6   0.024392047 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024405659 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8   0.038481649 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1461 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9   0.038494319 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10  0.052616814 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=2921 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11  0.052638389 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0

.... (skipped some packets for brevity) ....

No. Time    Source  Destination Protocol    Length  Info
72  1.220794991 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=48181 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73  1.266740106 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74  1.280819523 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=49641 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75  1.301652905 10.0.0.188  10.0.0.225  TCP 74  43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSecr=0 WS=128
76  1.303284866 10.0.0.225  10.0.0.188  TCP 66  80 → 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77  1.303316377 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78  1.303445281 10.0.0.188  10.0.0.225  HTTP    399 GET /favicon.ico HTTP/1.1 
79  1.305447545 10.0.0.225  10.0.0.188  TCP 150 80 → 43074 [ACK] Seq=1 Ack=1 Win=186880 Len=96 [TCP segment of a reassembled PDU]
80  1.305467257 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81  1.306119233 10.0.0.225  10.0.0.188  HTTP    60  HTTP/1.1 503 Service Unavailable 
82  1.306246772 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [FIN, ACK] Seq=346 Ack=98 Win=64256 Len=0
83  1.307186083 10.0.0.225  10.0.0.188  TCP 60  80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84  1.322753934 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
85  1.336850281 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=51101 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86  11.290742683    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0

Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.

P.S. Is there a way to debug the browser to see why is didn't ACK?

Some preliminary information:

• Browser: Firefox 104.0 (64-bit)
• Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

(Apparently I cannot attach the wireshark pcap until I have >60 something, so I'll put here is a link to a shared file: https://ln5.sync.com/dl/ac4466430/ykdcndnf-2tkf7zuk-fk2nuujs-q5ytenpk. Also, here are the pertinent packet bytes here)in text form - Transaction No. 85 does not get a reply. Why?

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000 10.0.0.188  10.0.0.225  TCP 74  43070 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSecr=0 WS=128
2   0.001635595 10.0.0.225  10.0.0.188  TCP 66  80 → 43070 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001674970 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001751029 10.0.0.188  10.0.0.225  HTTP    451 GET /js/math.min.js HTTP/1.1 
5   0.004238756 10.0.0.225  10.0.0.188  TCP 60  80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=0
6   0.024392047 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024405659 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=1461 Win=64128 Len=0
8   0.038481649 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=1461 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9   0.038494319 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=2921 Win=64128 Len=0
10  0.052616814 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=2921 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11  0.052638389 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=4381 Win=64128 Len=0

.... (skipped some packets for brevity) ....

No. Time    Source  Destination Protocol    Length  Info
72  1.220794991 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=48181 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73  1.266740106 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=49641 Win=64128 Len=0
74  1.280819523 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=49641 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75  1.301652905 10.0.0.188  10.0.0.225  TCP 74  43074 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSecr=0 WS=128
76  1.303284866 10.0.0.225  10.0.0.188  TCP 66  80 → 43074 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77  1.303316377 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78  1.303445281 10.0.0.188  10.0.0.225  HTTP    399 GET /favicon.ico HTTP/1.1 
79  1.305447545 10.0.0.225  10.0.0.188  TCP 150 80 → 43074 [ACK] Seq=1 Ack=1 Win=186880 Len=96 [TCP segment of a reassembled PDU]
80  1.305467257 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=346 Ack=97 Win=64256 Len=0
81  1.306119233 10.0.0.225  10.0.0.188  HTTP    60  HTTP/1.1 503 Service Unavailable 
82  1.306246772 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [FIN, ACK] Seq=346 Ack=98 Win=64256 Len=0
83  1.307186083 10.0.0.225  10.0.0.188  TCP 60  80 → 43074 [ACK] Seq=98 Ack=347 Win=186880 Len=0
84  1.322753934 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 Ack=51101 Win=64128 Len=0
85  1.336850281 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 [ACK] Seq=51101 Ack=398 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86  11.290742683    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 Ack=51101 Win=64128 Len=0

Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.

P.S. Is there a way to debug the browser to see why is didn't ACK?

Some preliminary information:

• Browser: Firefox 104.0 (64-bit)
• Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

Apparently I cannot attach the wireshark pcap until I have >60 something, so here is a link to a shared file: https://ln5.sync.com/dl/ac4466430/ykdcndnf-2tkf7zuk-fk2nuujs-q5ytenpk. Also, here are the pertinent packet bytes in text form - Transaction No. 85 86 does not get a reply. Why?

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000 10.0.0.188  10.0.0.225  TCP 74  43070 41202 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270624431 TSval=1312026123 TSecr=0 WS=128
2   0.001635595 0.001519852 10.0.0.225  10.0.0.188  TCP 66  80 → 43070 41202 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001674970 10.0.0.188  10.0.0.225  TCP 54  43070 0.001560889 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001751029 0.001673032 10.0.0.188  10.0.0.225  HTTP    451 454 GET /js/math.min.js /js/angular.min.js HTTP/1.1 
5   0.004238756 0.003887051 10.0.0.225  10.0.0.188  TCP 60  80 → 43070 41202 [ACK] Seq=1 Ack=398 Ack=401 Win=186880 Len=0
6   0.024392047 0.024216943 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=1 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024405659 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 0.024239272 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8   0.038481649 0.038301890 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=1461 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9   0.038494319 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 0.038340740 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=401 Ack=2921 Win=64128 Len=0
10  0.052616814 0.052425962 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=2921 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11  0.052638389 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 0.052459562 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=401 Ack=4381 Win=64128 Len=0

.... (skipped some packets for brevity) ....

No. Time    Source  Destination Protocol    Length  Info
72  1.220794991 1.208656628 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=48181 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73  1.266740106 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 1.254572136 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=401 Ack=49641 Win=64128 Len=0
74  1.280819523 1.268635475 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=49641 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75  1.301652905 1.276658583 10.0.0.188  10.0.0.225  TCP 74  43074 41204 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1270625733 TSval=1312027400 TSecr=0 WS=128
76  1.303284866 1.278292328 10.0.0.225  10.0.0.188  TCP 66  80 → 43074 41204 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77  1.303316377 10.0.0.188  10.0.0.225  TCP 54  43074 1.278336324 10.0.0.188  10.0.0.225  TCP 54  41204 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78  1.303445281 1.278516418 10.0.0.188  10.0.0.225  HTTP    399 402 GET /favicon.ico HTTP/1.1 
79  1.305447545 10.0.0.225  10.0.0.188  TCP 150 80 → 43074 1.280896982 10.0.0.225  10.0.0.188  TCP 60  80 → 41204 [ACK] Seq=1 Ack=1 Ack=349 Win=186880 Len=96 Len=0
80  1.287570511 10.0.0.225  10.0.0.188  TCP 101 80 → 41204 [ACK] Seq=1 Ack=349 Win=186880 Len=47 [TCP segment of a reassembled PDU]
80  1.305467257 10.0.0.188  10.0.0.225  TCP 54  43074 → 80 [ACK] Seq=346 Ack=97 81  1.287596789 10.0.0.188  10.0.0.225  TCP 54  41204 → 80 [ACK] Seq=349 Ack=48 Win=64256 Len=0
81  1.306119233 82  1.289099762 10.0.0.225  10.0.0.188  HTTP    60  HTTP/1.1 503 Service Unavailable 
82  1.306246772 10.0.0.188  10.0.0.225  TCP 54  43074 404 Not found 
83  1.289292405 10.0.0.188  10.0.0.225  TCP 54  41204 → 80 [FIN, ACK] Seq=346 Ack=98 Seq=349 Ack=49 Win=64256 Len=0
83  1.307186083 84  1.290905334 10.0.0.225  10.0.0.188  TCP 60  80 → 43074 [ACK] Seq=98 Ack=347 41204 [ACK] Seq=49 Ack=350 Win=186880 Len=0
84  1.322753934 10.0.0.188  10.0.0.225  TCP 54  43070 → 80 [ACK] Seq=398 85  1.310571817 10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [ACK] Seq=401 Ack=51101 Win=64128 Len=0
85  1.336850281 86  1.324619741 10.0.0.225  10.0.0.188  TCP 1514    80 → 43070 41202 [ACK] Seq=51101 Ack=398 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
86  11.290742683 87  11.294575726    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 43070 → 80 [ACK] Seq=397 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
88  12.314605673    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
89  13.342577224    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
90  14.362582354    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
91  15.390582366    10.0.0.188  10.0.0.225  TCP 54  41202 → 80 [RST, ACK] Seq=401 Ack=51101 Win=64128 Len=0

Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.

P.S. Is there a way to debug the browser to see why is didn't ACK?

Some preliminary information:

• Browser: Firefox 104.0 (64-bit)
• Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.

I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.

My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.

My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB

This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.

The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.

Why does the browser not respond to my packet segment?

Apparently I cannot attach the wireshark pcap until I have >60 something, so here is a link to a shared file: https://ln5.sync.com/dl/ac4466430/ykdcndnf-2tkf7zuk-fk2nuujs-q5ytenpk. Also, here are the pertinent packet bytes in text form - Transaction No. 86 does not get a reply. Why?

No. Time    Source  Destination Protocol    Length  Info
1   0.000000000 10.0.0.188  10.0.0.225  TCP 74  41202 39890 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312026123 TSval=1312662211 TSecr=0 WS=128
2   0.001519852 0.001636251 10.0.0.225  10.0.0.188  TCP 66  80 → 41202 39890 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.001560889 10.0.0.188  10.0.0.225  TCP 54  41202 0.001673090 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4   0.001673032 0.001745945 10.0.0.188  10.0.0.225  HTTP    454 GET /js/angular.min.js HTTP/1.1 
5   0.003887051 0.003977207 10.0.0.225  10.0.0.188  TCP 60  80 → 41202 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=0
6   0.024216943 0.024330297 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7   0.024239272 10.0.0.188  10.0.0.225  TCP 54  41202 0.024361342 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8   0.038301890 0.038601693 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=1461 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
9   0.038340740 10.0.0.188  10.0.0.225  TCP 54  41202 0.038618972 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=2921 Win=64128 Len=0
10  0.052425962 0.052858026 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=2921 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
11  0.052459562 10.0.0.188  10.0.0.225  TCP 54  41202 0.052883415 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=4381 Win=64128 Len=0

.... (skipped some packets for brevity) ....

No. Time    Source  Destination Protocol    Length  Info
71  1.219332911 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=48181 Win=64128 Len=0
72  1.208656628 1.233711923 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=48181 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
73  1.254572136 10.0.0.188  10.0.0.225  TCP 54  41202 1.275343115 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=49641 Win=64128 Len=0
74  1.268635475 1.288693443 10.0.0.188  10.0.0.225  TCP 74  39892 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312663499 TSecr=0 WS=128
75  1.289689153 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=49641 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
75  1.276658583 10.0.0.188  10.0.0.225  TCP 74  41204 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312027400 TSecr=0 WS=128
76  1.278292328 1.291021096 10.0.0.225  10.0.0.188  TCP 66  80 → 41204 39892 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
77  1.278336324 10.0.0.188  10.0.0.225  TCP 54  41204 1.291036249 10.0.0.188  10.0.0.225  TCP 54  39892 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
78  1.278516418 1.291171415 10.0.0.188  10.0.0.225  HTTP    402 GET /favicon.ico HTTP/1.1 
79  1.280896982 1.293348709 10.0.0.225  10.0.0.188  TCP 60  80 → 41204 39892 [ACK] Seq=1 Ack=349 Win=186880 Len=0
80  1.287570511 1.299963557 10.0.0.225  10.0.0.188  TCP 101 80 → 41204 39892 [ACK] Seq=1 Ack=349 Win=186880 Len=47 [TCP segment of a reassembled PDU]
81  1.287596789 10.0.0.188  10.0.0.225  TCP 54  41204 1.299984281 10.0.0.188  10.0.0.225  TCP 54  39892 → 80 [ACK] Seq=349 Ack=48 Win=64256 Len=0
82  1.289099762 1.301555541 10.0.0.225  10.0.0.188  HTTP    60  HTTP/1.1 404 Not found 
83  1.289292405 10.0.0.188  10.0.0.225  TCP 54  41204 1.301979479 10.0.0.188  10.0.0.225  TCP 54  39892 → 80 [FIN, ACK] Seq=349 Ack=49 Win=64256 Len=0
84  1.290905334 1.303427429 10.0.0.225  10.0.0.188  TCP 60  80 → 41204 39892 [ACK] Seq=49 Ack=350 Win=186880 Len=0
85  1.310571817 10.0.0.188  10.0.0.225  TCP 54  41202 1.331334859 10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [ACK] Seq=401 Ack=51101 Win=64128 Len=0
86  1.324619741 1.345386507 10.0.0.225  10.0.0.188  TCP 1514    80 → 41202 39890 [ACK] Seq=51101 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
87  11.294575726 11.299340118    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
88  12.314605673 12.323329898    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
89  13.342577224 13.351333464    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
90  14.362582354 14.375333012    10.0.0.188  10.0.0.225  TCP 54  [TCP Keep-Alive] 41202 39890 → 80 [ACK] Seq=400 Ack=51101 Win=64128 Len=0
91  15.390582366    10.0.0.188  10.0.0.225  TCP 54  41202 15.399330446    10.0.0.188  10.0.0.225  TCP 54  39890 → 80 [RST, ACK] Seq=401 Ack=51101 Win=64128 Len=0

Any suggestions would be appreciated. I've tried changing server HTTP reply to Connection: Keep-Alive. I will probably have to resort to a lazy load, although I don't want to. Most odd thing: this only happens when connected to certain routers (LAN port to LAN port) - Kasda exhibits the behaviour, Netgear does not.

P.S. Is there a way to debug the browser to see why is didn't ACK?