我们遇到一些奇怪的丢包，想知道这个的原因。
我们有一个图像服务器和一个服务器来强调图像服务器。 两者都位于同一个数据中心
首先我们运行一个像这样的负载testing（缩短了可读性的命令）：
ab -n 50 -c 5 http://testserver/img/de.png 该图像只有大约300字节。 结果是非常快速的回应：
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 0 Processing: 1 3 0.7 3 4 Waiting: 1 3 0.7 3 3 Total: 1 3 0.7 3 4
当我们增加并发时，我们看到一些滞后（为了可读性缩短命令）：
sudo ab -n 500 -c 50 http://testserver/img/de.png
结果与并发50：
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 1 Processing: 2 35 101.6 12 614 Waiting: 2 35 101.6 12 614 Total: 3 36 101.7 12 615
所以我们看到大多数请求都很快，其中一些非常慢。
我们用tcpdump转储整个networkingstream量，并看到一些奇怪的重新传输。
替代文字http://vygen.de/screenshot1.png
这个转储是在图像服务器上拍摄的！
所以你可以看到包含GET请求的初始包（No. 306）到达了映像服务器，但是在tcpdumplogging之后，它看起来丢包了。 在我看来，这个软件包没有到达tomcat映像服务器。
重发是由请求服务器在200ms后触发的，并且之后一切正常。
你知不知道为什么一个包裹收到后会迷路？
我们的机器都是：
所以我们没有任何关于内存或CPU负载的问题。
前一段时间，我们的networkingpipe理员遇到了一些问题。 我们通过使用不同的驱动程序处理它，我们现在使用r8168而不是r8169
但是，我们也遇到了同样的问题：英特尔网卡 – 以太网控制器：英特尔公司82541PI千兆以太网控制器（05版）
所以我们看到相同的机器，但不同的以太网卡的问题。
直到现在，我认为丢包只会发生在线路上的服务器之间，当数据包被损坏或类似的东西。
我们真的很想知道在tcpdumplogging完成后丢失数据包的原因是什么。
你的帮助非常感谢。
我们find了这个的根本原因。 我们在tomcat server.xml中有一个25的acceptCount。
acceptCountlogging如下：
acceptCount
所有可能的请求处理线程正在使用时传入连接请求的最大队列长度。 队列满时收到的任何请求将被拒绝。 默认值是100。
但这不是关于acceptCount的全部内容。 短：acceptCount是打开套接字时的backlog参数。 所以这个值对于监听积压很重要，即使不是所有线程都忙。 如果请求更快，那么tomcat可以接受并委托它们等待线程。 acceptCount的默认值为100.这对于处理请求中的突然高峰来说仍然是一个很小的值。
我们用apache和nginx检查了同样的东西，并且发现了同样奇怪的数据包丢失，但是具有更高的并发值。 apache中相应的值是ListenBacklog，默认为511。
但是，在Debian（和其他基于Linux的操作系统）中，backlog参数的默认最大值是128。
$ sysctl -a | grep somaxc net.core.somaxconn = 128
所以无论你在acceptCount或ListenBacklog中input什么内容，都不会超过128，直到你改变了net.core.somaxconn
对于一个非常繁忙的networking服务器128是不够的。 你应该改变它像500,1000或3000，取决于你的需要。
将acceptCount设置为1000并将net.core.somaxconn设置为1000后，我们不再有那些丢弃的数据包。 （现在我们在其他地方有一个瓶颈，但这是另一回事..）
200ms是默认的TCP重新传输超时（RTO;在RFC2988中描述，尽pipe没有定义最小值）。
所以…有些东西正在被拖延或丢失，以至于RTO正在被击中。 也许这个数据包被延迟了，RTO就被触发了，但是在数据包parsing/渲染过程中，wireshark会对这个数据包进行平滑处理？ 你应该更详细地调查跟踪。
你能提供一个更大的数据包捕获图像吗？