《wireshark网络分析的艺术》总结
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《linux为什么卡住了?》《像福尔摩斯一样思考》《一篇关于VMware的文章》《来点有深度的》 ==================================================================================================================== 《linux为什么卡住了?》 现象:ssh登陆某些linux服务器时,输完用户名会卡住10秒 抓包分析:发现linux服务器会向dns服务器进行进行反向解析(进行2次,1次5秒) 测试:在dns服务器中添加对应的PTR记录,卡现象解决 解决方法:google “ssh dns”;修改/etc/ssh/sshd_config cat /etc/ssh/sshd_config |grep -i usedns #UseDNS no ---------------------------------------------------------------------------------------------- 《像福尔摩斯一样思考》 现象:web服务器的端口号会随机发生变化; 排查1:客户端和web服务器直连,问题就消失了 根因:防火墙的一些错误配置导致的 观察到的现象: 1.回包的mac和网关mac不同-----说明了往返路径不一致 2.ttl值不符合预期,预期应该是63,实际为64-----说明了往返路径不一致 3.3次握手的sys/ack包和后续的ack包的ip identification不一致(一般情况下,identification是不变的) ---------------------------------------------------------------------------------------------- 《一篇关于VMware的文章》 问题现象:某些iSCSI存储阵列在出现网络拥塞时处理不当,会严重影响VMware的独行性能 根因:存储基于TCP实现的关系 解决方式:在VMware和iSCSI存储阵列关闭延迟确认(delayed ack) 有很多tcp协议栈默认启用延迟确认 VMware建议关闭延迟确认 ---------------------------------------------------------------------------------------------- 《来点有深度的》 对应上一篇文件,另一种解法是开启sack 启用sack比关闭延迟确认更高效,因为它可以一次性重传多个丢包,而不用每重传一个就等待一次ack,白费多个往返时间。 这在局域网环境中,优势不是很明显;但是在远程场景下,一个正常的往返时间都需要花费上百ms,那就更应该启用asck了 延迟确认严重影响性能的场景: 0.上述的场景,网络拥塞的场景下,每重传一个报文,都需要等待延迟确认 1.tcp窗口极小的情况下,例如接口窗口只有2920字节,相当于2个MSS,那么每发2个报文,就需要等待ack,因为没有ack,发送窗口就不会更新,就无法发送报文 tcp.analysis.ack_rtt > 0.2 and tcp.len == 0 #过滤出所有超过200毫秒的ack
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《三次握手的小知识》《被误解的TCP》《最经典的网络问题》《为什么丢了单子?》《受损的帧》《虚惊一场》 ==================================================================================================================== 《三次握手的小知识》 握手失败一般2种情况: 1.丢包 2.拒绝 (tcp.flags.reset == 1) && (tcp.seq == 1) #直接过滤出reset置位的拒绝报文 (tcp.flags.syn == 1) && (tcp.analysis.retransmission) #过滤出丢包or服务端静默的情况or服务端回包丢包 建议在client和server两端同时抓包,观察数据包是否相同。 ---------------------------------------------------------------------------------------------- 《被误解的TCP》 误区1:tcp每个包都有对应的ack 每发出一个http请求,就会收到一个http响应; 不止是http,绝大多数应用层协议都采用一问一答的工作方式 但是tcp不一样,ack的频率,不同的操作系统有不同的偏好,比如linux客户端喜欢每收到2个包会一个ack windown客户端更懒,隔好多包菜ack一次 安卓手机收到每个包都会回复ack 误区2:tcp的传输效率比udp低 作者表达的意思:只要发送窗口足够大,tcp也可以源源不断地发送数据,那么这种情况下,未必效率就比udp低了 ---------------------------------------------------------------------------------------------- 《最经典的网络问题》 wireshark不但能发现网络上的问题,也能反映出接收方和发送方的一些配置,只不过需要一些技巧来发现 问题:AIX备份到windows系统特别慢,只有1MB/s;基于SFTP传输 其实讲的就是nagle算法+延迟确认 产生的问题。。。 解决方法:2种算法关闭其中一种即可。 ---------------------------------------------------------------------------------------------- 《为什么丢了单子?》 问题:访问NFS服务器时,有些文件命名允许某个用户组访问,但是该组的用户却访问不了 复现问题: 1.在linux客户端创建测试账号,并将该账号加入到20个用户组中 2.某个NFS服务器的共享目录挂载到客户端 3.用root账号在共享目录中创建20个空的测试文件,逐个分配给第一步提到的那20个用户组,并将文件权限都设置为070 4.用测试账号逐一打开(cat)这些文件,前16个没有报错,但后4个都报permission denied错误。 抓包分析:客户端的RPC层,只将该账号所属的前16个用户组传递给NFS服务器 RFC 5531 中确实限制了最多传16个用户组 问题解决:将客户端的/etc/passwd和/etc/group复制到服务器上;当服务器用到用户组时,进行本地查询,完全忽略了RPC层传过来的信息 弊端:客户端修改了用户组,需要手工同步到服务器,否则会出现访问问题 ---------------------------------------------------------------------------------------------- 《受损的帧》 链路层的错误检测机制FCS: 发送方:每个帧在发送前都会被发送方校验一次,然后生成4字节的FCS存在帧尾 接收方:拿到帧之后,用相同的算法再做一次校验并生成FCS。如果两个FCS不一致,则认为帧已经被损坏,应该丢弃了。 这个校验是由网卡来完成的。所以主机上一般看不到FCS区域 既然抓包看不到损坏的帧,那么如何判断存在损坏的帧呢? netstat -i 问题:wireshark也有bug的时候,会显示错误,把上一个包的部分数据(12字节)作为另一个包的链路层数据显示。结果看起来是另一个包的链路层数据量过大,看起来像是一个损坏的帧 ---------------------------------------------------------------------------------------------- 《虚惊一场》 抓包分析时,需要充分考虑到通信两端的发送和接收是存在延迟的;因为这些延迟,可能导致数据包看起来和理想的数据不一致时,此时需要深入分析,而不是觉得就是遇到bug了
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《NTLM协议分析》《wireshark的提示》《书上错了吗?》《顺便说说LSO》 ==================================================================================================================== 《NTLM协议分析》 NTLM是window NT时代就出现的身份验证协议 例如使用windows打开一个远程目录,这里会进行验证,此时就用到了NTLM NTLM协商过程: 1.客户端向服务器发送一个NTLM协商请求;服务器立即回复一个随机字符串作为challenge 2.客户端收到challenge后,向服务器回复了输入的那个用户名xxxx以及2个response值(2个response值是用hash过的用户密码对challenge锁进行的加密,两种不同的加密方式产生了2个不同的response) 3.服务器收到之后,把challenge和2个response转发给域控(domain controller),让域控帮忙验证真假 4.域控收到之后,也用hash过的用户密码对该challenge进行加密。如果加密结果和这2个response一致,说明密码正确,身份验证通过;在响应时,将用户以及用户所属的群组信息告知服务器 5.服务器收到域控发来的消息后,告诉客户端身份验证通过了 ---------------------------------------------------------------------------------------------- 《wireshark的提示》 packet size limited during capture:说明被标记的包没有抓全 操作系统不同,默认的抓包长度也有不同;可以通过-s进行设置 tcp previous segment not captured:wireshark发现一个包的seq大于上一个包的seq+len时,就会进行提示 出现该情况的可能:1.丢包;2.抓包工具漏了;3.乱序 如果是抓漏了,可以通过ack报文来确认是否真的是漏了 tcp out-of-order:乱序 wireshark发现后一个包的seq小于前一个包的seq+len时,会认为乱序 tcp acked unseen segment:ack包对应的那个数据包没有抓到,wireshark就会进行该提示 这个提示是可以忽略的,因为都回ack了,那么接收方肯定是收到报文了,只不过没有被抓到而已。。 tcp dup ack:重复ack;当乱序or丢包发生时,接收方收到了一些seq号大于预期值的包 tcp fast retransmission:tcp快速重传 tcp retransmission:tcp超时重传 tcp zerowindow:表示缓存区已满,不能接受数据(不常出现,因为很少缓存区被真正消耗到0) tcp window fill:表示发送方已经把对方声明的接收窗口耗尽了(所以这个也出现的比较少?因为一般剩余几十字节的窗口时,算法会等待窗口放大了再发送) tcp segment of a reassembled PDU:wireshark将属于同一个应用层PDU的tcp包虚拟地集中起来。 该功能需要在wireshark中主动开启:edit-->preferences-->protocols-->tcp菜单-->启用allow sub reassemble tcp streams continuation to#:说明“allow sub reassemble tcp streams”功能未开启 time-to-live exceeded(fragment reassembly time exceeded):表示这个报的发送方之前收到一些分片,但由于某些原因迟迟无法组装起来。 例如某数据包分片丢失,导致无法组装。 ---------------------------------------------------------------------------------------------- 《书上错了吗?》 建议两边同时抓包,否则可能会因为回包的传输时延看到与理论不相符的现象;所以需要两边同时抓包,对照着看,避免出现误解。 《计算在途字节数》 在途字节数(bytes in flight):已经发送,但是还未经确认的字节数 在途字节数如果超过了网络的承载能力,那么就会造成丢包/重传 对于接收方,是看不到在途字节数的,也没有分析的意义;因为接收方看到数据就会进行接收咯。。。 对于发送方,存在已发送,但未经确认的数据,这就是在途数据,在途字节数 在途字节数 = 当前数据包的seq+len - 上一个ack的ack值 《估算网络拥塞点》 拥塞点:发送数据正好超过网络承载力,造成丢包重传 发生拥塞时,在途字节数就是该时刻的网络拥塞点;这种方式计算不是完全准确,但具备一定的参考价值 查找拥塞点的方法: 1.找到第一个重传包,然后找到它的原始包 2.根据原始包以及上一个ack来计算在途字节数 3.使用该方法多次查找拥塞点,这样统计出的拥塞点更准确,也更具说服力 每一次拥塞都对传输性能有很大的影响,即使千分之一的概率,也足以导致性能大滑坡 ---------------------------------------------------------------------------------------------- 《顺便说说LSO》 现象:wireshark分析,可以看到重传包,但是却找不到原始包 原因: 1.丢包了,所以看不到原始包 2.抓包晚了,没抓到 3.wireshark bug,把一个正常包标记为重传包了 4.原始包实际上已经抓到了,但是存在于另一个包内,直接通过seq不能过滤到而已 传统网络工作方式: 1.应用层把产生的数据交给TCP层 2.TCP层根据MSS大小进行分段(CPU负责),然后交给网卡 LSO(large segment offload): 1.应用层把产生的数据交给TCP层 2.TCP层不分段,直接把大于MSS的数据交给网卡 3.网卡负责分段工作
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《熟读RFC》(cwnd)《一个你本该能解决的问题》《几个关于分片的问题》《MTU导致的悲剧》 =========================================================================================================== 《熟读RFC》 性能问题是最难的,因为没有任何报错可以入手 问题:客户端发送数据到国外服务器非常慢,不到预期值的一半 分析: 1.查看专家信息,1万个包只有7个包有重传 2.点击ack查看往返时间RTT,大概78ms,比较稳定 影响发送速度的发送窗口取决于2个窗口 1.拥塞窗口cwnd 2.接收窗口(本案例接收窗口很大了。。) cwnd增长的2个阶段 1.慢启动:起点低,增长快;每收到1个ack,cwnd就增加1个mss 2.拥塞避免:起点高,增长慢;每个rtt,即一轮的cwnd数据包确认后,cwnd才会增加1个mss 在途字节数一定程度上可以看成拥塞窗口 回到案例:发现每经过1个rtt,cwnd才增加195bytes,这个就是传输慢的原因 哦哦哦,上面那个确实是原因,但是这个原因是正常的!其实就是拥塞避免阶段的正常算法嘛 根因:服务端回的ack数量过少,导致了cwnd增长过慢。。。(回包过少的原因是因为服务器开启了LRO,会积累多个包再集中处理,因为ack包数量也少了) ---------------------------------------------------------------------------------------------- 《一个你本该能解决的问题》 问题背景:在上海的主数据,通过网络10分钟同步一次到北京的镜像。带宽经过计算是符合要求的,但是实际10分钟不能完成同步。 抓包看到问题:icmp time-to-live exceeded(接收发因为分片丢包而无法按时完成数据包的重组) 根因:传输使用udp,同时数据包被分片,部分分片的丢包导致了所有数据的重传,导致了传输效率低 ---------------------------------------------------------------------------------------------- 《几个关于分片的问题》 问题1:为什么要分片? 1个IP包最多些到1480字节数据(1500-20);传输的数据块大于1480时,就会进行分片 问题2:发送方是怎么样确认分片大小的? 一般来说,发送方根据自身的MTU来决定分片大小 问题3:接收方又是靠什么重组分片的? 1.每个分片都有“off=xxx,ID=xxx”的信息,根据off偏移量完成重组 2.最后一个分片有flag“more fragments = 0”;其他分片“more fragments = 1 ” 网络攻击:不断发送“more fragments = 1 ”的数据包,导致接收方耗尽内存 问题4:TCP是如何避免被发送方分片的? 1.TCP开始时就主动根据MTU进行协商MSS,发送数据时,主动分片后再传给IP层 2.UDP没有MSS的概念,所以可能会被分片 问题5:TCP怎么样适配接收方的MTU? 通过tcp3次握手协商;使用mtu较小的那一方的mtu值 但是传输路径上的网络设备mtu较小的话,这个问题无法避免 问题6:为什么udp比tcp更适合语音通话? 1.语音通话更在于数据的实时性 2.可以想象语音基于TCP,发生TCP重传的美妙场景 ---------------------------------------------------------------------------------------------- 《MTU导致的悲剧》 IP层DF位 1.若DF位置位,且数据包过大,那么丢包 2.若DF位没有置位,且数据包过大,那么分片 1472(数据)+8(icmp报头)+20(ip头) = 1500 所以指定数据>=1473字节时,且DF置位,那么将会一直丢包 案例1:用户浏览某些共享目录时,客户端会死机,浏览其他目录则不会 抓包分析发现持续重传,但是客户端一直没有确认 丢包的可能: 1.防火墙阻止(那么3次握手就会丢) 2.网络拥塞(那么不会持续丢,而应该是随机丢) 3.丢的那个包比较大,而其他较小的包没丢(有可能是MTU的缘故) 测试:ping包指定数据大小,同时设置DF位 案例2:客户端MTU 1500;服务端MTU9000,平时正常;两端都修改9000后,反倒出问题了 因为tcp协商使用较小的MTU,所以平时没有问题;但是两端都修改9000后,那么MSS也协商位8960,反倒出问题了
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《迎刃而解》《昙花一现的协议》《另一种流控》《过犹不及》《治疗强迫症》 =========================================================================================================== 《迎刃而解》 问题:某台客户端连接某台服务器有问题;连接其他服务器都是ok的 抓包分析: 1.看到了第2个包sys,ack包的虚假重传,客户端也回复了第3个包,ack包 2.说明了第3个包没有被服务器接收到,3次握手没跑完 3.深入分析,发现3次握手的syn包和ack包的dst mac不一致 TLB(transmit load balancing):多网卡完成一个NIC teaming,特点:接收由1张网卡负责,发送则分摊给所有网卡 所以这里回包发送给了只负责发送的网卡,该网卡不能负责接收,那么就丢包了。。。 ---------------------------------------------------------------------------------------------- 《昙花一现的协议》 背景:98年,当时以太网的传输速度不够快,此时的FC网络可以达到2Gbit/s,而以太网仅仅只是百兆网络 FMP网络协议,相当于是双栈的一个协议: 1.通过以太网获取文件位置 2.通过FC网络完成文件读写 现在已经不用FMP协议了,因为以太网更新换代,带宽甚至超过了FC ---------------------------------------------------------------------------------------------- 《另一种流控》 问题:服务器端使用千兆网络时,是正常的;仅升级服务器端网络为万兆后,反倒出现了问题,性能下降了 分析:wireshark抓包分析,果然看到了重传和快速重传 重传率超过千分之一,就得采取措施了 万分之一以下的重传率,很难消除 根因:服务器侧更滑万兆网络后,发包太快;而交换机连接客户端的还是千兆网络,从而造成了丢包 ---------------------------------------------------------------------------------------------- 《过犹不及》 问题:数据中心在中东,需要定时把新数据同步到英国,常常因为传输太慢而同步超时。 分析:wireshark专家信息显示10万个包中存在1万个重传和快速重传包 再查看会话数,发现了客户使用50个tcp连接来做数据同步 因为单个连接可能无法占满整条链路,增加一些连接数确实可以提高传输效率 但是连接数过多却没有意义,反倒可能造成资源争抢,提高了丢包率 合理的tcp连接数:这和网络带宽、往返时间、发送窗口都有关系;没有固定公式,只能一边调节一边观测 ---------------------------------------------------------------------------------------------- 《治疗强迫症》 以2人同时编辑一个文件为案例 notepad实验:后保存的动作会覆盖前一个人的内容,且没有提示 notepad++实验:第一人保存时,会给第二人弹窗提示 excel实验:不允许2个人同时编辑,第二人打开文件时,会提示该文件被锁
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《技术与工龄》《如何科学地推卸责任》《一个面试的建议》《假带宽的真相》《手机抓包》《微博为什么会卡》 =========================================================================================================== 《技术与工龄》 背景:客户购买了最高端的服务器,上线后却发现性能不达预期 客户投诉和服务器有关,服务器的接收窗口居然只有16KB(16384) 其实这里wireshark提示了“window size scaling factor”,因为tcp3次握手协商的 window scale参数没抓到 假如协商的window scale为3,那么实际通过的接收窗口为16384*2*2*2 = 131072 所以这里的根因并不在于接收窗口太小,而是其他原因。。。 ---------------------------------------------------------------------------------------------- 《如何科学地推卸责任》 故障现象:在client侧抓包,发现从server侧发来了大量的RST报文 在client/server两端同时抓包,发现client侧收到RST报文,但是server侧并没有发过RST报文 排查方法:通过TTL值来判断,发现RST报文却是不是server端发送的,根据TTL条数可以判断出是防火墙发送的RST报文 ---------------------------------------------------------------------------------------------- 《一个面试的建议》 仅仅只是面试建议 你在工作中遇到什么困难,最后是怎么解决的? ---------------------------------------------------------------------------------------------- 《假带宽的真相》 对测试软件进行抓包,发现同时使用了5个TCP连接 在《一定带宽接入速率测试方法》通信行业标准中,明确规定了“测试中使用的线程数量>=4” 连接数达到一定数量后,再多就没什么意义了,甚至会影响TCP的拥塞控制效果。 在下载测试开始前,使用get请求获得下载源,然后以IP的形式直接发起下载测试,避免了DNS的影响 ---------------------------------------------------------------------------------------------- 《手机抓包》 1.安卓和iphone的web抓包,可以使用fiddler和charles工具抓包 2.在pc上设置http代理,然后在pc上抓包 3.一些现成的安卓抓包工具,需要root权限;ios上没有这类软件 4.tpackercapture工具,无需root也可以抓包,但是需要到googleplay上下载。。。需要越狱 5.pc设置热点,手机连接该热点,在pc上抓包 ---------------------------------------------------------------------------------------------- 《微博为什么会卡》 手机微博经常发现会卡,通过pc热点抓包 发现了手机微博严重依赖dns,两分钟的抓包,上百个dns查询动作;相比之下,微信的dns请求就少很多 把手机dns设置了一个错误的ip,然后就复现了微博的问题
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《寻找httpDNS》《谁动了我的网络》《一个协议的进化》《假装产品经理》《自学的窍门》《打造自己的分析工具》《一个创业点子》 =========================================================================================================== 《寻找httpDNS》 DNS支持GSLB,能根据DNS请求所包含的原地址返回最佳结果,从而匹配同地区/同运营商的IP,使用户体验到最好的性能 腾讯的GSLB是通过DNS服务器的地址来判断的,而不是通过用户IP来判断; 这种配置会存在问题,假设电信用户配置了联通dns,那么访问网站时,将拿到该网站的联通ip,最终也将访问网站的联通ip,这属于绕远路的行为,用户体验变差 腾讯使用httpdns来解决这个问题,允许手机的app直接查询腾讯自家的httpdns服务器,根据用户的地址判断返回的ip,从而绕过来传统dns的影响 实际情况经过抓包测试,并没有发现哪个主流产品使用来httpdns,所以也没有抓到过httpdns的包 ---------------------------------------------------------------------------------------------- 《谁动了我的网络》 从一个网站广告的案例,找到了运营商插入广告的秘密 通过分光器设备,复制了http请求;结果真实server/虚假server都进行了响应,因为虚假server距离用户更近,所以响应会先一步到达 判断的网络层依据: 1.TTL值,数字相同的几率很低 2.IP头的Identification,在一个会话中,第一个包的Identification是随机的,之后每发一个包,数值+1;如果发现Identification值突然有变化,不符合规律,那么就是虚假server回的包 判断的tcp层依据: 1.虚假server并没有参与3次握手过程,不清楚windows scale数值,所以server在回包时,会携带真正的窗口值,很可能会大的夸张 2.虚假server的回包可能会导致wireshark提示乱序 ---------------------------------------------------------------------------------------------- 《一个协议的进化》 http协议的进化过程 ---------------------------------------------------------------------------------------------- 《假装产品经理》 用wireshark分析微博app是怎么上传和下载图片的 1.图片被选定之后就开始上传,而不是等待用户点击发送按钮之后。(用户体验更流畅) 2.微博app会先压缩,在上传图片 3.下载的图片比上传时更小了,说明又经过了一次压缩 ---------------------------------------------------------------------------------------------- 《自学的窍门》 1.浏览权威的百科网站开始,例如维基百科 2.善用搜索引擎:尽量用google;把关键词翻译成英文再搜;不要忽视图片搜索的价值 3.啃一本经典书籍 4.动手操作 ---------------------------------------------------------------------------------------------- 《打造自己的分析工具》 1.用tshark进行分析;tshark官网链接:https://www.wireshark.org/docs/man-pages/tshark.html 2.将分析工具web化 ---------------------------------------------------------------------------------------------- 《一个创业点子》 很多数据中心跨站点的访问存在网络性能瓶颈 1.花钱购买更大的带宽 2.通过传输层(基本都是tcp)的调优来提高带宽利用率(创业点子) 将tcp调优进行程序化 创业点子:在两个站点的出口各自架设1台加速器,代理两个站点之间的所有tcp连接 主要解决2个方面的问题: 1.延迟高,延迟越高,需要等待的时间就越长,这很影响用户体验;解决:在延迟无法减少的情况下,尽量增大窗口。 2.丢包率高: a.网络质量差导致的零星丢包 b.拥塞导致的大量丢包 解决:尽可能第降低丢包几率,比如提前预测并采取措施避免拥塞发生;更精细地处理丢包后的流控,避免过度限流 其他的加速手段 1.启用tcp window scale 2.检测延迟来避免拥塞 3.利用发送窗口实现优先级 4.启用sack 5.改进满启动算法 6.启用tcp timestamps