对网络问题进行故障排查往往是件棘手的任务，而负载均衡器的存在则会带来其它更为复杂的挑战。我们很难判断负载均衡器单纯是在丢弃数据包、以某种方式变更数据包还是导致网络整体延迟水平上升。不过在今天的文章中，我们将共享几项常见技巧，相信它们能帮助各位更加轻松地发现问题所在。
对于任何一种故障排查流程来讲，首先要做的肯定是检查整套实体的统计信息。然而，即使统计信息显示一切运转正常，我们仍然不能就此排除存在网络问题的可能性。接下来，我们要做的就是引入故障排查领域的中立处理手段——数据包分析。虽然目前已经有大量优秀的收费数据包分析产品可供选择，但我个人更青睐开源Wireshark。
当对包含负载均衡器的网络体系进行问题分析时，首先要解决的问题就是该负载均衡器是否处于透明模式。在透明模式下，负载均衡器会将原有客户IP作为源IP。而在非透明模式下，该负载均衡器则会利用虚拟IP地址——或者简称VIP——向服务器发送请求。一般情况下，负载均衡器大多会以非透明模式运行。
现在大家已经准备好对文件进行追踪了。在理想状态下，我们可以在下图中的每个点内设置分接器。如果不具备分接器，大家也可以利用SPAN或者交换机上的镜像端口捕捉相关流量。当然，大家也可以在防火墙以及负载均衡器上的入站与出站端口使用tcpdump。其中的关窍在于，我们必须在全部四个位置一次性捕捉数据包，从而通过四种不同的角度审视传输会话。
在捕捉到数据之后，大家必须从全部四个跟踪文件当中找到同时存在的单一会话。一般来讲，大家能够通过过滤器找出请求与完成的两个IP地址。不过请注意，负载均衡器是在服务器端执行NAT的，因此对客户端IP进行过滤对服务器端追踪工作并无效果。
从第四层出发则能够解决这一难题。大家可以在TCP报头当中过滤序列号。不过需要注意的是，Wireshark会在默认情况下显示相关序列号，因此我们最终可能会得到成百上千个以序列号1开头的数据包。解决问题的关键在于关闭TCP设置当中的相关序列号功能。只需要取消勾选项，过滤结果就会显示实际十位序列号，而非作为会话开头的第一位数字。在对全部四个跟踪文件进行相同序列号过滤之后，大家应该会在每个文件中找到对应的惟一数据包。
麻烦的部分在于，如果大家的负载均衡器在NAT端自行创建出了指向服务器的数据包，那么各个文件当中的序列字段将不再完全相同。在这种情况下，最理想的办法是从应用层内选择惟一字段。对于HTTP，我建议大家使用Cookie字段;而对于HTTPS，Client Hello中的Random Bytes字段则最为合适。
最后，我们终于能够捕捉到单一会话，并对该痕迹进行访问了。首先，查看丢包情况。在Wireshark Expert Analysis当中，这些数据包会被标为“Previous segment no captured(即前段未被捕捉)。”这种情况可能出现在一个或者多个跟踪文件当中，但不会是全部。举例来说，如果大家在防火墙跟踪文件的出站端而非入站端发现了来自服务器的响应，那么就会判断出该数据包被防火墙丢弃。
在丢包查找完成后，检查TCP握手以确保各TCP选项没有在路径中受到篡改。当路径中的某个对话框自行创建数据包、而非以透明化方式直接经过时，则窗口缩放与选择性应答会出现消失趋势。这两个选项对于评估数据吞吐量而言非常重要，千万不要忽略。
最后一个需要解决的问题就是在跟踪文件中寻找高时间增量。通过对四个不同检查点进行数据捕捉，大家肯定能够发现的就是延迟水平的提升。首先查看握手，并以同步请求(SYN)与同步响应(SYN/ACK)之间的时间长度作为参考基准。查看跟踪文件中指向最接近客户端的防火墙的入站请求与响应。
对于那些时间增量达到1秒甚至更高的请求/响应组合，我们需要排查整个追踪过程，直到找出显著增加延迟水平的对应端口。其是否来自CPU处于运行峰值的防火墙?还是某个未能正常追踪其NAT表的负载均衡器?当然，也可能是存在太多并发连接的服务器。排查整个追踪流程将帮助大家了解问题的出现位置，同时明确哪些位置运转正常。
在网络排查工作当中，设置数据包捕捉可能会占用大量宝贵时间，但从长久角度看、这却是一种节约时间的良好习惯。
鼎峰胡佳雄
QQ.2881064155
Skype.live:2881064155