共计 3544 个字符，预计需要花费 9 分钟才能阅读完成。
排除网络问题可能很棘手，要是网络中多了负载均衡系统会带来另外的挑战。试图识别负载均衡系统是否在丢失数据包、以某种方式更改数据包或者添加更多的延迟可能并非易事。不过可以运用一些诀窍让你更容易发现问题。
任何故障排除工作的第一步就是检查相应网络部件的统计数字。然而，如果那些统计数字表明一切都很好，可是网络问题依然出现，那么你就只好引入故障 排除界的“瑞士军刀”――数据包分析。虽说市面上有好多出色的收费产品可用于分析数据包，不过我还是青睐开源工具 Wireshark(https://www.wireshark.org/download.html)。
在分析涉及负载均衡系统的问题时，需要解答的第一个问题就是负载均衡系统是不是处于透明模式下。在透明模式下，负载均衡系统会将原始客户机的 IP 地址作为源 IP 地址来传送。而在非透明模式下，负载均衡系统会使用负载均衡系统的虚拟 IP 地址 (VIP) 对服务器请求进行网络地址转换 (NAT) 处理。非 透明模式是最常见的实施模式。
现在你准备获取跟踪文件。在理想情况下，下图中的每一个点都会插入分路器 (tap)。要是你没有分路器，可以使用 SPAN(交换机端口分析器) 或 交换机上的镜像端口来捕获流量。或者你也可以对防火墙和负载均衡系统的入站和出站端口使用 tcpdump 命令。关键在于同时捕获所有四个位置的数据包，分 析来自四个不同有利位置的会话。
你捕获了数据后，必须找到出现在所有四个跟踪文件中的单一会话。通常，你只要过滤相应的两个 IP 地址就可以了。但是记住负载均衡系统在服务器端执行 NAT，所以过滤客户机 IP 地址并不适用于服务器端痕迹。
进入到第 4 层可以解决这个问题。你可以按照 TCP 报头中的序列号进行过滤。不过要小心;Wireshark 在默认情况下显示相对序列号，你到头来 会遇到数百个序列号为 1 的数据包。关键在于关闭 TCP 参数选项中的相对序列号。只要只要取消勾选该选项，实际的十进制数就会显示，而不是相对会话开始的序 列号。一旦你过滤了所有四个痕迹文件中的同一序列号，你在每个文件中应该有一个数据包。
如果你的负载均衡系统在 NAT 端创建自己的数据包发往服务器，棘手问题就来了。序列字段然后不再从头到尾都一样。这种场景下使用的最佳字段就是应 用层所特有的字段。如果是 HTTP，我建议使用 Cookie 字段; 如果是 HTTPS，则建议使用 Client Hello 中的 Random Bytes 字段。
最后，你面对在多个地方捕获的单一会话，可以分析其痕迹了。首先，寻找数据包丢失现象。在 Wireshark 的专家分析语言中，那些丢失的数据包 会被标为“Previous segment not captured”(未捕捉到的先前片段)。这会出现在一个或多个痕迹文件中，但并不出现在所有痕迹文件中。比如说，如果你在防火墙痕迹的出站端 (而不是 入站端) 看到来自服务器的响应，就知道防火墙丢失了数据包。
分析数据包丢失现象后，检查 TCP 握手机制，确保 TCP 选项在一路当中并没有被篡改。当沿途中的某个设备创建自己的数据包，而不是以透明方式一路 传送时，窗口缩放 (windows scaling) 和选择性确认 (Selective Acknowledgements) 往往会消失。那两个选项对吞吐量而言很重要，不应该去掉。
在痕迹中要关注的最后一个问题是很高的增量时间 (delta time)。如果捕获了四个不同位置的数据，你就真正能够查看什么东西在添加延迟(要是果真有什么东西的话)。先看一下握手机制。使用同步请求(SYN) 与同步响应(SYN/ACK) 的间隔时间作为基准。看一下离客户机最近的防火墙入站端留下的痕迹中的其余请求和响应。
针对那些增量时间为一秒或更长的请求 / 响应组合，逐步检查每个痕迹，直到你找到哪个端口在增添延迟为止。是处理器使用激增的防火墙吗? 还是跟踪 NAT 表有问题的负载均衡系统? 也许是并发连接数量太多的服务器。仔细检查痕迹，可以告诉你哪里有问题，哪里没有问题。
设置数据包捕获机制可能在网络灭火行动中会占用宝贵的时间，不过从长远来看它可以节省大量的时间。
英文：Network Troubleshooting: Consider The Load Balancer
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-08/121244.htm
排除网络问题可能很棘手，要是网络中多了负载均衡系统会带来另外的挑战。试图识别负载均衡系统是否在丢失数据包、以某种方式更改数据包或者添加更多的延迟可能并非易事。不过可以运用一些诀窍让你更容易发现问题。
任何故障排除工作的第一步就是检查相应网络部件的统计数字。然而，如果那些统计数字表明一切都很好，可是网络问题依然出现，那么你就只好引入故障 排除界的“瑞士军刀”――数据包分析。虽说市面上有好多出色的收费产品可用于分析数据包，不过我还是青睐开源工具 Wireshark(https://www.wireshark.org/download.html)。
在分析涉及负载均衡系统的问题时，需要解答的第一个问题就是负载均衡系统是不是处于透明模式下。在透明模式下，负载均衡系统会将原始客户机的 IP 地址作为源 IP 地址来传送。而在非透明模式下，负载均衡系统会使用负载均衡系统的虚拟 IP 地址 (VIP) 对服务器请求进行网络地址转换 (NAT) 处理。非 透明模式是最常见的实施模式。
现在你准备获取跟踪文件。在理想情况下，下图中的每一个点都会插入分路器 (tap)。要是你没有分路器，可以使用 SPAN(交换机端口分析器) 或 交换机上的镜像端口来捕获流量。或者你也可以对防火墙和负载均衡系统的入站和出站端口使用 tcpdump 命令。关键在于同时捕获所有四个位置的数据包，分 析来自四个不同有利位置的会话。
你捕获了数据后，必须找到出现在所有四个跟踪文件中的单一会话。通常，你只要过滤相应的两个 IP 地址就可以了。但是记住负载均衡系统在服务器端执行 NAT，所以过滤客户机 IP 地址并不适用于服务器端痕迹。
进入到第 4 层可以解决这个问题。你可以按照 TCP 报头中的序列号进行过滤。不过要小心;Wireshark 在默认情况下显示相对序列号，你到头来 会遇到数百个序列号为 1 的数据包。关键在于关闭 TCP 参数选项中的相对序列号。只要只要取消勾选该选项，实际的十进制数就会显示，而不是相对会话开始的序 列号。一旦你过滤了所有四个痕迹文件中的同一序列号，你在每个文件中应该有一个数据包。
如果你的负载均衡系统在 NAT 端创建自己的数据包发往服务器，棘手问题就来了。序列字段然后不再从头到尾都一样。这种场景下使用的最佳字段就是应 用层所特有的字段。如果是 HTTP，我建议使用 Cookie 字段; 如果是 HTTPS，则建议使用 Client Hello 中的 Random Bytes 字段。
最后，你面对在多个地方捕获的单一会话，可以分析其痕迹了。首先，寻找数据包丢失现象。在 Wireshark 的专家分析语言中，那些丢失的数据包 会被标为“Previous segment not captured”(未捕捉到的先前片段)。这会出现在一个或多个痕迹文件中，但并不出现在所有痕迹文件中。比如说，如果你在防火墙痕迹的出站端 (而不是 入站端) 看到来自服务器的响应，就知道防火墙丢失了数据包。
分析数据包丢失现象后，检查 TCP 握手机制，确保 TCP 选项在一路当中并没有被篡改。当沿途中的某个设备创建自己的数据包，而不是以透明方式一路 传送时，窗口缩放 (windows scaling) 和选择性确认 (Selective Acknowledgements) 往往会消失。那两个选项对吞吐量而言很重要，不应该去掉。
在痕迹中要关注的最后一个问题是很高的增量时间 (delta time)。如果捕获了四个不同位置的数据，你就真正能够查看什么东西在添加延迟(要是果真有什么东西的话)。先看一下握手机制。使用同步请求(SYN) 与同步响应(SYN/ACK) 的间隔时间作为基准。看一下离客户机最近的防火墙入站端留下的痕迹中的其余请求和响应。
针对那些增量时间为一秒或更长的请求 / 响应组合，逐步检查每个痕迹，直到你找到哪个端口在增添延迟为止。是处理器使用激增的防火墙吗? 还是跟踪 NAT 表有问题的负载均衡系统? 也许是并发连接数量太多的服务器。仔细检查痕迹，可以告诉你哪里有问题，哪里没有问题。
设置数据包捕获机制可能在网络灭火行动中会占用宝贵的时间，不过从长远来看它可以节省大量的时间。
英文：Network Troubleshooting: Consider The Load Balancer
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-08/121244.htm
