Here is another Linux TCP horror story: An application I&#x27;m working on was experiencing slow database query performance under &quot;load&quot; [1]. Restarting the database temporarily &quot;fixed&quot; the issue, only to reappear again after a short time.<p>Luckily I was able to recreate the problem in a test environment (our secondary backup cluster) allowing me to study it. What I found was that I could reliably send the database cluster in a &quot;bad state&quot; by sending a burst of &gt; ~200 concurrent requests to it. After this, I observed a bi-modal response time distribution with some requests completing quickly as expected (&lt;10ms) and some taking much longer (consistently ~6s for one particular request). My initial instinct was to blame the database, but some SYN Cookie flood warnings in the kernel logs caused me to consider the network as well.<p>So I started using tcpdump and Wireshark to go deeper and found the following: The burst of traffic from the application also caused a burst of traffic between the database cluster nodes which were performing some sort of result merging. To make things worse, the inter-node requests of the database cluster were using http, which meant a lot of connections were created in the process. Some of these connections were interpreted as a SYN flood by the Linux kernel, causing it to SYN-ACK them with SYN cookies. Additionally, these connections would get stuck with very small TCP windows (as low as 53 bytes), and also suffer from really high ACK latencies (200ms), so a 1600 byte inter-node http request wound up taking 6s! Disabling SYN cookies &quot;fixed&quot; the issue (and so did increasing somaxconn, but that&#x27;s effectively the same), but despite my best effort, I was unable to understand why SYN cookies should impact the TCP window.<p>To make this even more mysterious, this problem only occurred in one of our data centers, and we narrowed it down to the router being the only difference. Replacing the router also &quot;fixed&quot; the issue.<p>I wish my team had the resources and expertise to debug problems like this down to the kernel, but I was too far out of my depth trying to understand the gnarly code the makes up the Linux TCP Syn Cookie and Congestion Control implementation ... : (.<p>Anyway, I&#x27;m posting this in the vague hope that somebody may have seen something similar before, or becomes inspired to go on kernel bug hunt :).<p>Additionally this experience gave me a new appreciation for TCP&#x2F;IP and how amazing it is that is usually &quot;just works&quot; for me as an application developer. This is not to say that we can&#x27;t improve upon it, but I think there is a lot to learn from the philosophy and approach that went into designing TCP&#x2F;IP.<p>[1] By &quot;load&quot; I mean bursts of hundreds of concurrent http requests created due the application performing JOIN requests on behalf of the NoSQL database which doesn&#x27;t provide this feature. My journey of replacing this database with one that&#x27;s more suited for the task at hand is being written as we speak :).
[2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SYN_cookies" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SYN_cookies</a>