细节决定成败3:特定页面无法打开

细节决定成败, 做技术的尤其如此，今天我们继续分享一个和负载均衡相关的排障案例:

之前系列:

细节决定成败2: 链路负载均衡遇到IPS

细节决定成败1: 负载均衡和应用层面的结合

 

七层服务器负载均衡时，HTTP Header的大小限制

客户报障，使用A10设备配置了七层应用交换，在经过负载均衡后访问同一台内部服务器的不同页面，一个可以正常打开，另外一个无响应。

在明确的确是相同客户端通过负载均衡设备访问相同的后台服务器出现的问题后；很显然这个问题和网络互通基本上无关，通常这种问题是比较难处理的。这种情况下无非回归到根本，从客户端，负载均衡和服务器三处同时抓包进行详尽的分析：

访问该页面时，客户端发送请求；负载均衡代理应答后，客户端发送HTTP请求，但未接收到任何后续的响应报文

服务器：可以接收到客户端的请求并正确返回响应报文

负载均衡：接收到服务器的请求并正确转发给服务器；成功接收来自服务器的报文但未转发给前段客户端：

看过我们之前有关PMTU文章的读者，可能会马上考虑到这个是不是PMTU的问题，经过报文的详细分析排除；在进一步排查时发现，服务器的详细响应报文是这样的(通过wireshark分析服务器响应报文, Follow TCP产生）

经过确认，是由于服务器响应报文中HTTP Header中的一个Set Cookie长度过长；超过了常用的16K字节；而负载均衡设备通常为能快速处理7层报文，对整个服务器响应中HTTP Header的内容会放入系统buffer中处理； 在HTTP Header的长度超过该buffer大小时会丢弃，造成上面提到的访问故障。

需要提到的是，IIS系统等WEB中间件对用户的HTTP请求，和服务器的HTTP响应都有大小的限制，不同的版本设定值不同；在淘宝 叔同的"大型互联网站性能优化"一文中也特别提到要减小服务器返回Cookie的大小作为网站优化的一种手段：

 

在此再次提醒诸位：四层和七层的应用对负载均衡/应用交付来讲是完全不同的机制；七层由于应用上的种种细节，就有可能存在类似这篇文章提到的细枝末节的问题；何时采用四层部署，何时又应该使用七层功能，请大家务必根据应用需求仔细定夺。

(J.L.)