服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 来自这个networking的所有连接都处于SYN_RECV状态，来自家庭或电话的连接正确地获得ESTABLISHED
Intereting Posts
无源以太网tap 当资源需求增加时如何做一个虚拟秤 删除域中的旧计算机 MS Word 2007随机保存一个空白的文档 在ejabberd中将MUSIA的MUC（多用户会议）数据迁移到MySQL 运行PHP作为fastcgi与Apache国防部与777目录权限 哪里可以find一份很好的SLA协议？ vSphere 6.0上的Xeon E5-2630v3（Haswell）无法启用VMware EVC 重新启动后，ESXi设置丢失 有什么办法可以将tcp_proxy模块作为ubuntu软件包安装nginx吗？ 柯尼卡美能达多function打印机默认为双面打印 MAB和802.1x问题 – MABauthentication的设备被丢弃 Exchange 2010垃圾邮件filter不起作用 nginx：基于cookie的不同configuration 麻烦使用gitweb与nginx

来自这个networking的所有连接都处于SYN_RECV状态，来自家庭或电话的连接正确地获得ESTABLISHED

我的服务器（一个linode VPS）昨天突然开始超时。

我在networking方面相当缺乏经验，并且很想学习debugging这些连接问题的过程。

让我感到困惑的是，昨天有些人（我的电话，我在家里，在家里的朋友）可以一直访问这个站点，我用netstat看到一个连接已经build立。 我禁用了firwalls并设置了iptables来接受所有连接，以排除任何将我们的IP列入黑名单的奇怪的自动规则。 我不知道它的相关，但本地networking的跟踪路由超时 – 从一些外部的机器traceroutefind我的服务器。

我已经确认各种设置是正确的，通过比较我的开发服务器上正常运行的设置。

以下文件与我的开发环境相匹配（各自的IP地址除外）： 

 /etc/hosts /etc/hosts.allow /etc/hosts.deny /etc/networking/interfaces ifconfig

Apache正在端口80上进行侦听，安装看起来和我运行的服务器完全一样。 

 # server that doesn't work: tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 22008/apache2 tcp 0 0 69.164.201.172:80 71.56.137.10:57487 SYN_RECV - # server that does work tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3334/apache2 tcp 0 0 72.14.189.46:80 71.56.137.10:57490 ESTABLISHED 20931/apache2

我试图理解

每次我加载页面一次， netstat -an | grep :80 netstat -an | grep :80显示SYN_RECV状态下的所有连接。 

 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 69.164.201.172:80 71.56.137.10:56657 SYN_RECV tcp 0 0 69.164.201.172:80 71.56.137.10:56669 SYN_RECV tcp 0 0 69.164.201.172:80 71.56.137.10:56671 SYN_RECV

所以SYN_RECV意味着服务器正在等待ACK从客户端发回。
如何debuggingACK是否被发回？ 如何debugging通信失败的地方？

下面是我尝试加载页面一次tcpdump的样子。

在下面的贴上，我的服务器不断地发送数据包到客户端，没有得到响应。

这是什么意思？ 客户没有得到回应？ 或者，也许我正在吞服服务器的某个地方的响应？ 我怎么知道进一步缩小罪魁祸首呢？ 

 tcpdump -i eth0 -n -tttt port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 2011-05-25 20:12:54.627417 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 2011-05-25 20:12:54.627512 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:12:54.814463 IP 69.164.201.172.80 > 71.56.137.10.57157: Flags [S.], seq 604630211, ack 496040070, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:12:55.214482 IP 69.164.201.172.80 > 71.56.137.10.57158: Flags [S.], seq 998358186, ack 2224730755, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:12:57.624737 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 2011-05-25 20:12:57.624793 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:12:59.014477 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:13:03.618790 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,nop,sackOK], length 0 2011-05-25 20:13:03.618866 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:13:05.014514 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0 2011-05-25 20:13:17.014504 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0

tcpdump的function服务器

在查看我的function服务器的tcpdump后，我确实看到了服务器和客户端之间的后端和第四个通信。 

 00:00:00.000000 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [S], seq 34114118s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 00:00:00.000110 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [S.], seq 2454858 win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0 00:00:00.061827 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 1, win 100:00:00.004292 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 1:597, ngth 596 00:00:00.000074 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 597, win00:00:00.493990 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], seq 1:2921, ngth 2920 00:00:00.000024 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 2921:30, length 98 00:00:00.065135 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 3019, wi00:00:00.034766 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 597:12925, length 699 00:00:00.000035 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 1296, wi00:00:00.000457 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 3019:328, length 211 00:00:00.019196 IP 71.56.137.10.57262 > 72.14.189.46.80: Flags [S], seq 10674886s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

任何build议，解释或评论将非常赞赏，以便我可以更多地理解TCP，希望在下次需要debugging这样的问题时更有用一些。

谢谢！

对于这个疲惫的眼睛来说，它似乎有一些类似的路由问题接近有问题的服务器。 数据包沿着一条path进入，但是似乎通过不同的path分离，并且在这条path上有状态，并丢弃奇怪的“没有SYN”数据包的ACK。

我曾经遇到过这种事。 结果是服务器有一个不好的networking掩码，所以当来自子网的stream量进入时，它会发出一个ARP请求来获得节点的MAC地址。 不幸的是，对于我来说，路由器和我们的负载平衡器都启用了Proxy-ARP，并且负载平衡器比触发器的触发速度要快一些。 所以SYN数据包通过路由器进入，但试图通过负载平衡器离开子网。 由于LB没有连接这个ACk包，所以把它放在地板上。

在你的情况下，一些明智的跟踪路线可能会照亮networkingpath问题。 从受影响的服务器上，尝试对发生问题的IP进行跟踪路由，并从相同的IP执行相同的操作。 如果你得到不同的path，那可能就是它的位置。

刚刚有同样的问题。

在我的情况下，这是一个networkingconfiguration错误。

服务器configuration为10.0.1.111 255.255.254.0，客户端configuration为10.0.0.15 255.255.255.0。 将客户端的networking掩码更改为/ 23解决了我的问题。

希望这可以帮助。

关于tcpdump