负载均衡故障诊断-一个MSS值引发的疑案.docx

负载均衡故障诊断：一个MSS值引发的疑案 2011-10-19 23:16:14 标签： 负载均衡 抓包 mtu mss 添加标签 原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 /3027116/692407 负载均衡设备位于客户端和真实服务器之间，一旦访问发生问题，在客户经过简单诊断后，负载均衡设备往往会成为首要被怀疑的对象。客户一般这样质疑：为什么我直接访问服务器没有问题，通过你的设备访问就不行了呢？ 质疑的确实有道理，但大多数事情往往不是非一即二这样简单，有很多东西都在互相影响，这就使得真相迷雾重重。 某一天接到某客户报障，说是通过负载均衡设备访问某一业务的时候，页面无法打开或者等半天后只打开了部分页面，而客户端如果直接访问服务器，则可以顺利打开页面。 事情很明显，这中间肯定是有问题存在。登录负载均衡设备检查配置和log，并取一些内部诊断信息，没发现什么错误，只剩下唯一的办法：去客户现场抓包分析。 于是开始抓包，同时抓回了出现问题的服务的数据包和其他没有出现问题的服务的数据包。 经过分析，果然有所不同，下面是有问题的抓包内容（抓包1）： 08为客户端地址 12为VIP 9为真实服务器地址 由于是以旁路方式部署，需要转换源IP, 23为经过负载均衡设备转换的客户端地址（snat地址） 负载均衡的VIP配置为HTTP模式，这表示负载均衡设备是以proxy的方式来处理连接，也就是对每个连接，客户端先跟负载均衡设备完成一个三次握手，然后负载均衡设备再跟真实服务器完成一个三次握手。 访问流程： 1) 08访问12 2) 负载均衡设备与客户端完成三次握手 3）然后负载均衡设备把源IP: 08转换成23向服务器9发起连接 4）服务器9与负载均衡设备完成三次握手。 下图是访问没有问题的服务的抓包内容（抓包2）： 为客户端地址 13为VIP 04为真实服务器地址 由于是以旁路方式部署，同样需要把客户端源IP转换为 23 访问流程跟抓包1相同。 仔细比较两个抓包内容，终于发现了差异出现在MSS值的协商上。 首先我们描述一下Client访问Server过程中MSS值的协行过程： 1） 客户端在向服务器发出SYN包的时候，会带上客户端设备可以接受的最大MSS值，意思是服务器发送到客户端的每个包的内容大小都不能大于这个值。 2） 服务器向客户端回复SYN,ACK包的时候，会比较客户端发来的MSS值和自己设定的MSS值，取两者的最小值作为自己可以接受的最大MSS值返回给客户端，意思是告诉客户端发送到服务器的每个包的内容大小都不能大于这个值。 3） 在实际的传输中，双方往往会取二者中的最小值作为双方互相发送的包大小的最大值。 基于以上通信流程我们来分析一下以上的两个抓包内容： 抓包1： 客户端发出SYN包，标明自己可接受的最大MSS值为1460,负载均衡设备回应自己可接受的MSS值为1400,协商成功后，双方交互的包大小不会大于1400。 负载均衡设备向服务器发出自己的可接受MSS值为1380,服务器回应自己可接受的MSS值120,协商成功后，负载均衡设备发给服务器的包就不能大于120了。 问题正是出在最后跟服务器协商出的大小为120的MSS值上。 我们看到客户端向负载均衡设备发出的第一个请求包大小为905字节，这个包大小不大于1400，所以负载均衡设备接收到了，接着负载均衡设备要把该请求发给选定的服务器9，由于服务器可接收的包不能大于120,所以负载均衡设备只能把客户端发来的请求包分成八个小包发送给服务器，然后一些不可控制的问题就出现了，客户端发出请求包后，需要等待应答，但由于负载均衡设备把一个包分解成8个包后，使得负载均衡设备跟服务器之间的交互时间变长，这个过程中客户端可能会超时重发请求包，而负载均衡设备跟服务器之间那八个小包的处理还可能出现丢包，重传，重装等问题。最关键是客户端在该连接的所有请求发完后如果是发送一个RST包来关闭连接，那么即使该连接上还有内容没传输完，该条连接也会关闭，由于一个请求包分成太多的小包传输，一旦发生客户端发出RST包的这种情况，基本上都会导致数据不能传输完毕，以上种种原因导致了页面不能打开或者不能完全打开的现象。 我们再分析抓包2： 客户端发出SYN包，标明自己可接受的最大MSS值为1460,负载均衡设备回应自己可接受的MSS值为1400,协商成功后，双方交互的包大小不会大于1400。这一点跟抓包1相同。 负载均衡设备向服务器发出自己的可接受最大MSS值为1380,服务器回应自己可接受的MSS值1380,协商成功后，所以双方会以1380的MSS值互相通信。 无论是客户端跟负载均衡设备还是负载均衡设备跟服务器之间，都是一个