我们一直试图抓住一个奇怪的问题，我们可以在solaris 10上从Apache 2.2.19上find一个页面，并且一些请求的排列可靠地花费各种固定的时间来响应。
它看起来是基于TCP套接字的closures，从客户端上的tcpdump开始，我们通常会看到在填充TCP窗口的服务器与最后一次响应之间的暂停，以及最后一个数据块与FIN从服务器。
所以在networking上它只是挂起了HTTP响应的中间传输，但是服务器上的netstat在FIN_WAIT_1中显示了一个套接字。 我们不能在服务器上做一个tcpdump来澄清，但是在我们看来，操作系统已经把TCP对话交给了硬件，所以相信它已经开始四处closures了，但是NIC从来不放这个包，数据包（可能是1或2 @ 1500字节和400或其他）。
这就像我们可以绘制的一样清晰的图像，除了最近的一个testing，我们做了一个惊人的…一个64076字节的文件由apache提供 – 最后一个包的432ms延迟。 我们给文件添加了一个字符，这导致了一个额外的数据包被创build，53个字节也包含了FIN，而不是我们在略小的文件上看到的空的52字节FIN，延迟的那个文件。 这个额外的数据包的存在可靠地改变了FIN对话的发生，并使对话从几乎半秒到几毫秒。
最常见的是在调查的整个过程中，这个延迟时间为4.6秒，我们再次看到窗口大小在波动，SACK在需要的时候返回到Apache，但是最后一个窗口的时间已经满了，持续46秒，然后回到最后2或3kb的数据，以及Solaris认为它发送的FIN以前。
我们的tcpdumps在F5 BigIP上，所以有一个ASICstream量以及一个Cisco 6509（仅限L2），但是我们在相邻的Solaris机器上执行wget时看到的是相同的用户体验，所以不要不相信BigIP正在做的任何黑魔法。
但是这一切都混淆了窗口大小和MSS和喜欢的混淆，但如果这听起来很熟悉任何人，我们都耳朵！