蚂蚁网-多维人生，三实而立！

1，此案例为服务器端系统异常MSS通告导致的业务应用故障，的确属于疑难故障范畴；

2，关于MSS的知识点，大家可参考本博客《TCP MSS与PMTUD》一文；

3，此案例充分证明，在遇到疑难故障时，站在原始报文交互的角度做深入的解码分析才是分析定位的根本之道；

4，此案例中，使用了正常时与异常时的对比分析法，关于对比分析法，大家可参考本博客《疑难网络故障的分析方法和原理之对比分析法》一文；

5，个人认为，此案例还可以做进一步的分析，如原作者开篇所言“很多东西都在互相影响”，既然经过负载均衡设备访问就出现这种问题，那么是否是负载均衡在发给服务器端的SYN报文跟客户端直接发给服务器端的SYN报文某些地方存在差异导致的呢？

【原文链接】：

http://virtualadc.blog.51cto.com/3027116/692407

【原文全文】：

负载均衡设备位于客户端和真实服务器之间，一旦访问发生问题，在客户经过简单诊断后，负载均衡设备往往会成为首要被怀疑的对象。客户一般这样质疑：为什么我直接访问服务器没有问题，通过你的设备访问就不行了呢？ 质疑的确实有道理，但大多数事情往往不是非一即二这样简单，有很多东西都在互相影响，这就使得真相迷雾重重。

某一天接到某客户报障，说是通过负载均衡设备访问某一业务的时候，页面无法打开或者等半天后只打开了部分页面，而客户端如果直接访问服务器，则可以顺利打开页面。

事情很明显，这中间肯定是有问题存在。登录负载均衡设备检查配置和log，并取一些内部诊断信息，没发现什么错误，只剩下唯一的办法：去客户现场抓包分析。

于是开始抓包，同时抓回了出现问题的服务的数据包和其他没有出现问题的服务的数据包。

经过分析，果然有所不同，下面是有问题的抓包内容（抓包1）：

10.52.127.108为客户端地址

10.0.1.112为VIP

10.0.1.99为真实服务器地址

由于是以旁路方式部署，需要转换源IP, 10.0.1.123为经过负载均衡设备转换的客户端地址（snat地址）

负载均衡的VIP配置为HTTP模式，这表示负载均衡设备是以proxy的方式来处理连接，也就是对每个连接，客户端先跟负载均衡设备完成一个三次握手，然后负载均衡设备再跟真实服务器完成一个三次握手。

访问流程：

1) 10.52.127.108访问10.0.1.112

2) 负载均衡设备与客户端完成三次握手

3）然后负载均衡设备把源IP: 10.52.127.108转换成10.0.1.123向服务器10.0.1.99发起连接

4）服务器10.0.1.99与负载均衡设备完成三次握手。

下图是访问没有问题的服务的抓包内容（抓包2）：

10.0.76.2为客户端地址

10.0.1.113为VIP

10.0.1.104为真实服务器地址

由于是以旁路方式部署，同样需要把客户端源IP转换为 10.0.1.123

访问流程跟抓包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，所以负载均衡设备接收到了，接着负载均衡设备要把该请求发给选定的服务器10.0.1.99，由于服务器可接收的包不能大于120,所以负载均衡设备只能把客户端发来的请求包分成八个小包发送给服务器，然后一些不可控制的问题就出现了，客户端发出请求包后，需要等待应答，但由于负载均衡设备把一个包分解成8个包后，使得负载均衡设备跟服务器之间的交互时间变长，这个过程中客户端可能会超时重发请求包，而负载均衡设备跟服务器之间那八个小包的处理还可能出现丢包，重传，重装等问题。最关键是客户端在该连接的所有请求发完后如果是发送一个RST包来关闭连接，那么即使该连接上还有内容没传输完，该条连接也会关闭，由于一个请求包分成太多的小包传输，一旦发生客户端发出RST包的这种情况，基本上都会导致数据不能传输完毕，以上种种原因导致了页面不能打开或者不能完全打开的现象。

我们再分析抓包2：

客户端发出SYN包，标明自己可接受的最大MSS值为1460,负载均衡设备回应自己可接受的MSS值为1400,协商成功后，双方交互的包大小不会大于1400。这一点跟抓包1相同。

负载均衡设备向服务器发出自己的可接受最大MSS值为1380,服务器回应自己可接受的MSS值1380,协商成功后，所以双方会以1380的MSS值互相通信。

无论是客户端跟负载均衡设备还是负载均衡设备跟服务器之间，都是一个请求一个应答就能完成交互，不会发生要把包分割的现象，所以不会出现抓包1所出现的问题。

网络通信中由于MTU的设置不当引发的问题屡见不鲜，比如在存在ADSL设备的情况下，如果把设备的MTU设置成1500, 往往客户端的访问会出现问题，这是因为ADSL的PPPoE协议在MTU中占去8个字节，也就是ADSL的MTU最大值最多为1492, 如果客户端跟服务器设的很大，传输的数据包恰好大于1492字节，将导致数据包不能通过。  在程序设计中，程序所取MSS值往往是本机的MTU-40（TCP和IP头各占20个字节，MTU一般设成1500）， 所以基本上所有设备所能接受的最大MSS值不可能会大于1500-40=1460, 那么再考虑到网络中可能会存在PPPoE，VPN等设备会占用更多MTU字节，所以各家网络设备厂商提供的网络设备会进一步减小MSS值的设置，一般网络设备设定的MSS值大小为1400左右。

显然1400字节左右的MSS值是网络通信中的正常值，所以服务器返回一个120字节的MSS值这是一个不正常的现象，所以问题的根源在于服务器返回的MSS值不合适，那么这个值是谁返回的呢？ 是服务器，也就是说该返回哪个值主动权在于服务器，所以我们诊断问题原因出在服务器上。

接下来的处理需要去检查服务器为什么返回这个值，跟负载均衡设备无关了。但仍然有追踪的价值，因为服务器并不是一直返回120这个值，而是有些时候会协商成1380,这时候访问是正常的，有些时候是返回120，这时候就自然访问不正常。

客户的服务器装的是HP操作系统，应用软件是Oracle的ebs，在我们把问题定位到了服务器后，客户也找了HP的工程师来检查和分析，但无法找出原因。

个人分析问题原因可能出现在如下几个方面：

1） HP操作系统或者网卡驱动程序关于MTU的定义存在可变值，或者

2） Oracle ebs的底层通信程序在MSS值的协商时，会根据一些条件改变MSS值

以上仅仅是猜测，因为没有以上两个厂家的资深工程师的深度参与，无法最终定位结果，所以该问题成为了一个疑案。

阅读全文>>

标签: 疑难故障 负载均衡 tcpdump MTU MSS 抓包 A10

评论(0) 引用(0) 浏览(9864)

【转】tcpdump使用手册

作者：易隐者 发布于：2012-6-16 17:35 Saturday 分类：参考资料

       Linux下使用最广泛的就是tcpdump，下面是tcpdump的使用手册：

总览 (SYNOPSIS)

tcpdump [ -adeflnNOpqStvx ] [ -c count ] [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ expression ]  

描述 (DESCRIPTION)

Tcpdump显示网络接口上符合布尔表达式expression的报头.
对于SunOS的nit或 bpf 界面: 要运行tcpdump，你必须有/dev/nit或/dev/bpf*的读访问权限.
对于Solaris 的dlpi:你必须有网络仿真设备(network pseudo device)， 如/dev/le的读访问权限
对于HP-UX的dlpi:你必须是 root， 或者把它安装成root的setuid程序.
对于IRIX的snoop: 你 必须是 root， 或者把它安装成root的setuid 程序. 对于Linux:你必须是root，或者把它安装成 root的setuid程序.
对于Ultrix和Digital UNIX: 一旦超级用户用pfconfig(8)开放了杂凑模式(promiscuous-mode)，任何用户都可以运行tcpdump.
对于BSD: 你必须有/dev/bpf*的读访问权限.

选项 (OPTIONS)

-a
试着把网络和广播地址转换成名称.
-c
当收到count个报文后退出.
-d
把编译好的报文匹配模板 (packet-matching code) 翻译成可读形式，传往标准输出，然后退出.
-dd
把报文匹配模板(packet-matching code)以C程序片断的形式输出.
-ddd
把报文匹配模板(packet-matching code)以十进制数形式输出(前面加上总数).
-e
每行都显示链路层报头.
-f
用数字形式显示“外部的”互联网地址，而不是字符形式(这个选项用来绕开脑壳坏掉的SUN黄页服务器的问题——一般说来，它翻译外部网络数字地址的时候 会长期挂起).
-F
指定文件file的内容为过滤表达式. 忽略命令行上的表达式.
-i
监听interface接口.如果不指定接口，tcpdump在系统的接口清单中，寻找号码最小，已经配置好的接口(loopback除外).选中的时候会中断连接.
-l
行缓冲标准输出.可用于捕捉数据的同时查看数据. 例如，
``tcpdump  -l  |  tee dat'' or’`tcpdump  -l   > dat  &  tail  -f  dat''.
-n
不把 地址 转换成 名字 (如主机地址， 端口号等)
-N
不显示 主机名字 中的 域名 部分. 例如， 如果 使用 这个 选项， tcpdump 只显示’`nic''， 而不是’`nic.ddn.mil''.
-O
禁止运行 报文匹配模板 的 优化器. 当 怀疑 优化器 含有 bug 时， 这个选项 才有用.
-p
禁止 把 接口 置成 promiscuous 模式. 注意， 接口 有可能 因 其他原因而 处于 promiscuous 模式; 因此， '-p' 不能 作为’ether host {local-hw-addr} 或 ether broadcast' 的 简写.
-q
快速输出. 显示 较少的 协议信息， 输出行 将 短一点点.
-r
从 file 中 读入 数据报 (文件 是用 -w 选项 创建的). 如果 file 是’`-''， 就 读 标准输入.
-s
从每个 报文 中 截取 snaplen 字节的数据， 而不是 缺省的 68 (如果是 SunOS 的 NIT， 最小值是 96). 68 个字节 适用于 IP， ICMP， TCP 和 UDP， 但是 有可能 截掉 名字服务器 和 NFS 报文 的 协议 信息 (见下面). 输出时 如果指定’`[|proto]''， tcpdump 可以 指出 那些 捕捉量过小的 数据报， 这里的 proto 是 截断发生处 的 协议层 名称. 注意， 采用 更大的 捕捉范围 既增加了 处理 报文 的 时间， 又 相应的 减少了报文的 缓冲 数量， 可能 导致 报文的丢失. 你 应该 把 snaplen 设的尽量小， 只要 能够 容纳 你 需要 的 协议信息 就可以了.

-T
把 通过 "expression" 挑选出来的 报文 解释成 指定的 type. 目前 已知 的 类型 有: rpc (远程过程调用 Remote Procedure Call)， rtp (实时应用协议 Real-Time Applications protocol)， rtcp (实时应用控制协议 Real-Time Applications control protocol)， vat (可视音频工具 Visual Audio Tool)， 和 wb (分布式白板 distributed White Board).
-S
显示 绝对的， 而不是 相对的 TCP 序列号.
-t
禁止 显示 时戳标志.
-tt
显示 未格式化的 时戳标志.
-v
(稍微多一点) 繁琐的输出. 例如， 显示 IP 数据报 中的 生存周期 和 服务类型.
-vv
更繁琐的输出. 例如， 显示 NFS 应答报文 的 附加域.
-w
把 原始报文 存进 file， 不分析 也 不显示. 它们 可以 以后 用 -r 选项 显示. 如果 file 是’`-''， 就 写到 标准输出.