Linux – TCP Zero Window with no corresponding Window Update

If you are capturing packets on the server then you might see TCP sending out larger segments than the MTU. The packets on the wire , however, will be MTU size only. You can verify this by capturing on a network device (switch) etc. Alternatively capturing packets on the remote (client) machine will reveal that each packet is <= MTU .

This behaviour is due to the fact that with TSO/GSO enabled, the TCP segment is split into MTU sized packets by NIC hardware. Since tcpdump captures at software layer, it sees segments larger than the MTU being sent to the NIC card for further transfer.

If you disable tso/gso for the NIC, then you will see all outgoing packets to be <= MTU size (more likely pMTU size).

Making sure the TCP window is opening up wide enough to cover the Bandwidth Delay Product would have been my first guess too. Assuming that is configured properly (and supported by both ends) I would next examine a packet trace to make sure that the window really is opening up and that one of the hops in the path isn't stripping the window scaling. If that is all good, and you are certain you are not banging into a bandwidth constrained hop in the path, the likely cause to your problems is random packet drops. This hypothesis is supported by the indication of the duplicated ACKs you mentioned. (Duplicated ACKs are generally a direct result of lost data). Also note that with a large bandwidth delay product and therefore a large open sliding window, even low levels of random packet drops can significantly hamper the total throughput of the connection.

Side Note: For bulk data transfers over TCP and over a multi-hop WAN connection, there should be no need or reason to disable Nagle. In fact, that exact scenario is why Nagle exists. Generally, Nagle only needs to be disabled for interactive connections where sub-MTU sized datagrams need to be forced out without any delay. ie: For bulk transfers, you want as much data in each packet as possible.