服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

来自网关虚拟机的神秘“碎片要求”拒绝

我一直在解决一个严重的广域网速度问题。 我固定它,但为了别人的利益: 通过WireShark,日志logging和简化configuration,我把它缩小到了从DNAT到内部networking上的服务器的一个奇怪的行为。 网关(一个CentOS盒)和服务器都运行在同一台VMware ESXi 5主机上(事实certificate这很重要)。 当我试图从DNAT后面的HTTP服务器上下载一个文件时,使用一个直接连接到网关WAN侧的testing客户端(绕过这里通常使用的实际的Internet连接) : 通常的TCP连接build立(SYN,SYN ACK,ACK)正常进行; 网关正确地重新映射服务器的IP。 客户端使用HTTP GET发送单个TCP段,并且这也正确地被DNATted到目标服务器。 服务器通过网关发送一个1460字节的带有200响应和部分文件的TCP段。 线路上的帧的大小是1514字节 – 有效载荷是1500。 这部分应该通过网关,但没有。 服务器通过网关发送第二个1460字节的TCP段,继续文件。 同样,链路有效载荷是1500字节。 这个细分市场也没有穿过网关,也从来没有考虑过。 网关向服务器发送一个ICMP Type 3 Code 4(目标不可达 – 分片需要)数据包,引用事件3中发送的数据包.ICMP数据包指示下一个中继站MTU为1500. 这看起来是无意义的 ,因为networking是干净的1500字节,并且3和4中的链路负载已经在规定的1500字节限制内 。 服务器可以理解,忽略了这个回应。 (原来,ICMP被一个过分热心的防火墙所淹没,但是这个问题已经解决了。) 经过相当长的时间(并且在一些configuration中,来自服务器的重复ACK)之后,服务器决定单独从事件3重新发送段。 除了IP标识字段和校验和之外,帧与事件3中的帧是相同的。它们长度相同 ,新的帧仍然设置了不分片标志。 但是,这一次,网关将网段快速传递给客户端,而不是发送一个ICMP拒绝。 客户确认这一点,转移仍在继续,虽然慢得令人难以置信 ,因为随后的分段经历了大致相同的被拒绝,超时,重新发送和接通的模式。 如果客户端移动到局域网以便直接访问服务器,则客户端和服务器正常协同工作。 这个奇怪的行为根据目标服务器的看似不相关的细节而不可预知地变化。 例如,在Server 2003 R2上,如果启用Windows防火墙(即使允许HTTP和所有ICMP),7MBtesting文件将花费7小时以上传输,而问题根本不会出现,而矛盾的是拒绝将永远不会如果Windows防火墙被禁用,首先由网关发送 。 另一方面,在Server 2008 R2上,禁用Windows防火墙并没有任何效果,但是在传输过程中仍会受到影响,比启用防火墙的Server 2003 R2快得多。 (我想这是因为2008 R2使用更智能的超时启发式和TCP快速重传。) 更奇怪的是,如果WireShark安装在目标服务器上,问题就会消失。 因此,为了诊断这个问题,我必须在单独的虚拟机上安装WireShark来观察LAN端的networkingstream量(由于其他原因,可能是一个更好的主意)。 ESXi主机是版本5.0 […]