为什么服务器不会响应SYN数据包发送SYN / ACK数据包？

我们有这个完全相同的问题。 只是禁用TCP时间戳解决了这个问题。

sysctl -w net.ipv4.tcp_timestamps=0 

要使这个更改永久化，请在/etc/sysctl.confinput一个条目。

要小心禁用TCP窗口缩放选项。 此选项对于通过互联网提供最高性能非常重要 。 如果往返时间 （基本上与Ping相同）超过55毫秒，那么连接速度为10兆/秒的人将会有不理想的传输。

当同一个NAT后面有多个设备时，我们真的注意到了这个问题。 我怀疑服务器可能会混淆看到来自Android设备和OSX机器的时间戳，因为它们在时间戳字段中input完全不同的值。

我们刚刚遇到了完全相同的问题（确实需要相当长的一段时间才能将其固定到服务器而不发送syn-ack）。

“解决scheme是closures我们的服务器上的tcp窗口缩放和tcp时间戳，公众可以访问。”

只是想知道，但为什么对于SYN数据包（帧＃539;被接受），WS和TSV字段在“信息”列中丢失？

WS是TCP窗口缩放 ，TSV是时间戳值 。 它们都在tcp.options字段中find，Wireshark仍然应该显示它们，如果它们存在。 也许客户端TCP / IP堆栈试图在第8次尝试不同的SYN数据包，这就是为什么它突然被确认的原因？

你能给我们提供框架539的内部价值吗？ SYN / ACK是否始终用于没有启用WS的SYN数据包？

在我的情况下，以下命令解决了从Linux服务器丢失SYN / ACK答复的问题：

 sysctl -w net.ipv4.tcp_tw_recycle=0 

我认为这比禁用TCP时间戳更正确，因为TCP时间戳毕竟是有用的（PAWS，窗口缩放等）。

关于tcp_tw_recycle的文档明确指出，不build议启用它，因为许多NAT路由器保留时间戳，因此PAWS开始使用，因为来自相同IP的时间戳不一致。

  tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4) Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended for devices communicating with the general Internet or using NAT (Network Address Translation). Since some NAT gateways pass through IP timestamp values, one IP can appear to have non-increasing timestamps. See RFC 1323 (PAWS), RFC 6191. 

继续Ansis所说的，当防火墙不支持TCP Windows Scaling时，我看到了类似的问题。 这两个主机之间是什么使/防火墙模式？

我刚刚发现Linux TCP客户端在3次尝试后更改它们的SYN数据包，并删除了Window Scaling选项。 我猜内核开发人员认为这是互联网连接失败的常见原因

这就解释了为什么这些客户端在11秒之后才能够连接（在我的简短testing中，在缺省设置下9秒后，无窗口的TCP SYN发生了）

这是侦听TCP套接字在积压已满时的行为。

Ngnix允许backlog参数在configuration中进行监听： http ://wiki.nginx.org/HttpCoreModule#listen

听80积压=数字

尝试将num设置为大于默认值的值，如1024。

我并不保证一个完整的监听队列实际上是你的问题，但这是一个很好的检查。

缺less的SYN / ACK可能是由于防火墙上的SYNFLOOD保护的限制过低造成的。 这取决于您的服务器用户创build多less个连接。 使用spdy会减less连接的数量，并可能有助于net.ipv4.tcp_timestampsclosures不起作用的情况。