《wireshark网络分析就这么简单》总结
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《从一到面试题开始说起》、《小试牛刀:一个简单的应用实例》、《excel文件的保存过程》、《你一定会喜欢的技巧》(tcpdump抓包技巧)、《NFS协议的解析》 ====================================================================================================================== 《从一到面试题开始说起》 2台服务器,A 192.168.26.129/24;B 192.168.26.3/27;两台服务器可以通信吗? A直接发给B;B先把请求转给网关,由网关转发给A ----------------------------------------------------------------------- 《小试牛刀:一个简单的应用实例》 重启服务器A之后,再也不能和服务器B通信了 这个网络的设定就是要求A通过网关才能和B通信的。但是重启导致了另一条路由的出现(这条路由曾经配置,已被删除,不知道为什么还残留在配置文件内),该路由和服务器B处于同一网段,所以会尝试解析ARP,而解析ARP失败,所以通信还未开始就结束了 ----------------------------------------------------------------------- 《excel文件的保存过程》 windows notepad保存过程:如果是通过网络访问notepad文件,发起保存请求,那么服务器直接保存。(2个人同时编辑的话,那么后一位保存的会直接覆盖前一位保存) office保存过程就复杂一些了:比如会出现提示“说明该文件被占用,暂时保存不了”,这种问题在notepad上是不会发生的 excel的保存过程:先创建一个随机名称的文件(隐藏文件),再保存时,将该文件重命名 ----------------------------------------------------------------------- 《你一定会喜欢的技巧》 1.只抓包头 一般每个包(称为“帧”更准确)的最大长度1514字节;启用了jumbo frame(巨型帧)之后可达9000字节+;但是大多是时候我们只需要IP报头或者TCP报头就足够分析了。 一般设置80字节就足够了,足够包含tcp层、IP成、链路层的信息 如果问题设计应用层,那么应该加上应用层协议头的长度,如果不确定应用层协议头的长度,那么设置200字节是一个比较保险的数值 tcpdump抓包可以用-s 达到该效果 2.只抓必要的包 抓包时,指定抓包条件进行过滤。 过滤时,需要指定正确的条件,例如一般抓包条件会把广播包过滤掉;或者网络中存在nat设备,那么应该抓nat之后的ip 使用一些小技巧,在抓包时,人为制造一些分界线 例如 ping $IP -n 1 -l 1;ping $IP -n 1 -l 2;ping $IP -n 1 -l 3;这里指定了icmp的data(1字节、2字节、3字节) wireshark个性化设置 。。。。。。 分析时,进行过滤 让wireshark自动分析 专家信息、各种图等等 最容易上手的搜索功能 wireshark是支持ctrl+F进行搜索的!!!!! ----------------------------------------------------------------------- 《NFS协议的解析》 1.client找到server的portmap进程,查询NFS进程的端口号(portmap的功能是维护一张进程与端口号的对应关系表,而portmap的端口号111是众所周知的) 2.client尝试连接NFS进程端口;成功则继续 3.client再次联系server的portmap进程,查询mount进程的端口号(mount的端口号比较随机,该查询不能跳过) 4.client尝试联系server的mount进程,确认mount进程是否已经启动(这一步真正挂载了目录) 5.client进行查看文件等操作;应该联系的是mount进程把。。。 NFS对客户端的访问控制是通过IP地址实现的。创建共享目录时,可以指定哪些IP允许读写,哪些IP只读,哪些IP连挂载都不允许 NFS的用户权限经常让人困惑:客户端A在/code目录创建一个文件,该文件的owner正常显示为admin;但是客户端B查看该文件,owner却变成nasadmin 原因是在nfs传递过程中,使用UID来代表身份;但是客户端AB的UID 501却对应的是2个用户名 NFS的async和sync
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《从wireshark看网络分层》、《TCP的连接启蒙》、《快递员的工作策略-TCP窗口》 ===================================================================================== 《从wireshark看网络分层》 MTU = MSS + TCP + IP TCP连接中,MSS是由MTU较小的一方决定的 ------------------------------------------------------------------------ 《TCP的连接启蒙》 DNS默认使用UDP nslookup可以用“set vc”强制使用TCP ------------------------------------------------------------------------ 《快递员的工作策略-TCP窗口》 TCP发送窗口的2个因素:1.接收方的接收窗口;2.网络 接收窗口不等于发送窗口,这是一个误区! 接收窗口:加入接收方的处理速度跟不上接收数据的速度,那么缓存将会被挤占,从而导致接收窗口为0 如何判断发送窗口的大小: 当网络不是决定因素时,那么发送窗口=接收窗口,我们可以通过“window size”的值来判断 当网络是决定因素时,事情就变得复杂(下一章讲解) 当时大多数时候,我们不能确定是哪个因素在起作用,只能大概推理 发送窗口和MSS的关系: 发送窗口决定了一口气可以发送多少字节 MSS决定了这些字节需要几个报文可以发送完 数据包的数量是会大于ack包数量的,ack包一般都会少一些 “TCP window scale”在TCP的option中,只在出现在TCP3次握手的协商阶段,若没有抓到3次握手,那么很多时候查看的接收窗口/发送窗口是不准确的 假设3次握手,TCP option中,window scale的shift count = 5,那么2的5次方 = 32 意味着真实的接收窗口 = 接收窗口*32 window size value = 183 [calculated window size] = 5856 【真实接受窗口 183*32】 若防火墙识别不了window scale,那么对方无法获得shift count ,这将导致严重的性能问题!
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《重传的讲究》---发送窗口和网络拥塞;《延迟确认和Nagle算法》;《百家争鸣》---各种拥塞算法 ===================================================================================== 《重传的讲究》---发送窗口和网络拥塞 网络能限制发送窗口,是因为网络收到太多的数据就会拥塞。拥塞的结果就是丢包,这是发送方最忌惮的。 拥塞点:能导致网络拥塞的数据量 所以发送方希望把发送窗口控制在拥塞点以下,这样就能避免拥塞了 1.发送方知道自己网卡的带宽,能否以此推测该连接的拥塞点? 显然不能。发送方和接收方之间可能存在很多网络设备,网络环境是复杂的,任何一台设备都可能是瓶颈 2.逐次增加发送量,直到网络拥塞,那么此时的最大发送量就是拥塞点吗? 显然也不是,因为网络是动态的,网络中并不是只有一个链接。所以拥塞点是动态的。 网络对发送窗口的限制,就是通过拥塞窗口实现的。 1.拥塞窗口初始值很小,RFC建议2个/3个/4个MSS,具体是MSS大小而定 2.慢启动过程,每收到1个确认,拥塞窗口增加1个MSS 3.拥塞避免的临界窗口值:当拥塞窗口达到一个较大的值,此时传输速度较快,触碰到拥塞点的几率也大了,这时切换到拥塞避免阶段 在拥塞避免阶段,每个RTT时间增加1个MSS(实际的算法:假设拥塞窗口足够发送20个MSS,那么每接受到1个ack报文,拥塞窗口增加1/20) 所以拥塞避免的临界窗口值的取值很有讲究: 当从未拥塞过,那么拥塞点可以取一个相对较大的值,比如=最大接收窗口 日常生活工作中,为什么感觉不到拥塞呢: 1.未启用“TCP window scale”,那么最大接收窗口只有64KB,现在的网络这么牛逼,64KB远远达不到拥塞点 2.很多应用场景是交互式的小数据,比如网路聊天 3.传输数据的时候,如果采用同步方式,可能需要的窗口非常小。比如采用了同步方式的NFS写操作,每发一个写请求就停下来等待回复,而一个写请求可能只有4KB 4.偶尔拥塞,持续时间也不足以长到能感受出来,除非进行网络抓包分析 数据包丢失将导致超时重传,这个后果很严重,因为将会导致该连接的拥塞窗口降到1MSS,进入慢启动;同时将拥塞避免的临界窗口值设置为上一个拥塞点(发送窗口)的1/2【不能小于2MSS】 RTO:发出原始包到重传该包的这段时间(文章不讲RTO的计算公式) 偶发的丢包(轻微拥塞or校验码不对),和严重拥塞的现象是不一样的。 偶发的丢包因为后续报文可以到达,所以可以触发快速重传 拥塞阶段触发快速重传,则进入快速恢复阶段 RFC5681建议拥塞临界窗口值应设为发送窗口的1/2(不小于2MSS),拥塞窗口设置为临界窗口值+3MSS,继续保留在拥塞避免阶段。 SACK的功能 重传的总结: 1.没有拥塞时,发送窗口越大,性能越好。即在没有带宽限制时,接收窗口越大越好 2.若经常发生拥塞,那么限制发送窗口反而能提高性能,因为即使万分之一的重传对性能也影响巨大 3.超时重传对性能影响最大,因为a.在RTO阶段不能传输数据,浪费了一段时间;b.拥塞窗口的急剧缩小,相当于接下来的传输慢的多了 4.快速重传对性能影响小一些,因为他没有等待时间,而且拥塞窗口减小幅度也没那么大 5.SACK和NewReno有利于提高重传效率,提高传输性能 6.丢包对极小文件的影响比大文件的影响更大,因为读写小文件需要的包数量很少,所以往往凑不满3个DUP ACK,只能等待超时重传 ------------------------------------------------------------------------ 《延迟确认和Nagle算法》 延迟确认:收到一个包,若暂时没什么数据要发送给对方,那么延迟一段时间(windows默认为200ms)再确认;假如这段时间恰好有数据要发送,那么确认信息和数据放在一个包发出去 延迟确认并没有直接提高性能,它减少了部分确认包,减轻了网络负担 Nagle算法:在互动的传输场景下,输入字符是被逐个打成小包的;此时可以使用Nagle算法将这些小包合并为一个大包。 Nagle算法原理:在发出去的数据还没有被确认之前,假如又有小数据生成,那么就把小数据收集起来,凑满1个MSS or收到确认再发送数据 Nagle也没有提高性能,它和延迟确认一样,减少了部分数据包,减轻了网络负担 当Nagle算法+延迟确认场景下:网络性能将会差的难以想象 发送端使用了Nagle算法,将会一直等待确认报文(因为都是小数据嘛,基本很难凑满1个MSS) 接收端使用了延迟确认,但是因为没有数据回复,所以200ms才会回复ACK 所以 实际RTT = 理论RTT + 200ms ------------------------------------------------------------------------ 《百家争鸣》 拥塞窗口临界值:RFC2001建议把拥塞窗口临界值定义为发生丢包时,拥塞窗口的1/2 westwood算法:在轻微丢包时,不会大幅度减小拥塞窗口临界值,同时传输速度也可以保持 这个在经常发生非拥塞丢包的环境中(比如无线网络),westwood是比较有优势的 RFC2581改进了RFC2001的拥塞窗口临界值的计算公式: 把拥塞窗口的1/2改为FlightSize的1/2(FlightSize已发送,但未确认的数据量) 这个算法确实会比之前的更严格,引进FlightSize是一种更为保守的想法,而并不是那种比较理想的想法(尽量地去取一个较高的拥塞窗口临界值) Vegas算法:Vegas独辟蹊径,通过监控网络状态来调整发包速度,从而实现真正的“拥塞避免”。 当网络良好时,RTT比较稳定,那么可以增大拥塞窗口临界值 当网络开始繁忙时,数据包开始排队,RTT变大,这时就会减小拥塞窗口 优势:在拥塞发生之前,发送方通过RTT预测,减小发包速度,避免了丢包 缺点:在网络中存在其他算法时,Vegas算法会主动降低发包速率,所以导致了Vegas传输速度低,因为它太君子了。。。 compound算法走的是中庸之道,算是RFC2581和Vegas算法的结合体,在windows7上,默认是关闭的
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《简单的代价---UDP》、《剖析CIFS协议》《网络江湖》、《DNS小科普》 ===================================================================================== 《简单的代价---UDP》 UDP的问题: 1.UDP不在于双方MTU的大小,应用拿到数据包,打上UDP报头,就交给下一层了;若数据包超过MTU,那么在传输过程中,要么被丢包,要么被网络设备分片 分片会消耗网络设备的资源,降低性能 2.UDP没有重传,丢包则依靠应用层来处理。 3.分片机制存在弱点,会被黑客攻击 黑客若发送“more fragments”的flag置1的包,那么接收设备将会一直接收报文,而不会组装报文、处理报文,将会导致内存耗尽 ------------------------------------------------------------------------ 《剖析CIFS协议》 NFS协议只在linux/unix上流行 windows使用SMB协议(也叫CIFS协议),一共3个版本:SMB、SMB2、SMB3,SMB、SMB2较为常用 CIFS基于TCP,端口号445 关于CIFS协议原理的分析过程,总结略 ------------------------------------------------------------------------ 《网络江湖》 CIFS协议继续分析。。。 ------------------------------------------------------------------------ 《DNS小科普》 A记录(Address记录):域名解析到IP PTR记录:IP反向解析为域名 SRV记录:windows域的管理员要特别关心这个 CNAME记录:别名,又称为Alias记录; CNAME记录可以使域名管理更加方便,例如:某台服务器上提供了多个服务,那么相对应的就存在多个域名;当这台服务器更换IP时,那么这多个域名的A记录都需要修改。 但是将多个域名通过CNAME指向同一个域名,那么就只需要修改这个域名的A记录就可以了 DNS的工作原理 电信、联通等运营商的DNS也是不权威的,这并不是指这些DNS服务器不值得信任,而是他们本身不包含NDS的注册信息 递归查询:当存在dns解析需求时,我的笔记本将DNS解析工作完全甩给了DNS服务器,依赖这台服务器的返回结果 迭代查询:当存在dns解析需求时,我的笔记本主动依次地去查询根服务器、权威服务器、。。。直到获取结果 dig +trace 强迫客户端采用迭代查询 DNS特性:DNS的RR模式 假设一个域名存在2个A记录,连续2次去解析时,返回的解析结果相同,但是A记录的顺序是相反的。 因为客户端一半会选用第一个A记录,以此方式实现了RR DNS的缺点: 1.山寨域名(欺骗) 2.设备的DNS服务器IP被修改(欺骗) 3.DNS放大攻击:请求解析的包不大,若解析结果的A记录比较多,那么响应包就比较大。此时若伪造了解析包的源IP,那么就可以轻易实现DNS放大攻击
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《一个古老的协议---FTP》、《上网的学问---HTTP》、《无懈可击的Kerberos》 ===================================================================================== 《一个古老的协议---FTP》 FTP服务端的控制端口21 。。。。 ------------------------------------------------------------------------ 《上网的学问---HTTP》 海量文件不适合传统的目录结构,所以云存储一半使用对象存储的方式: 客户端访问文件时,并不使用其路径和文件名,而是使用它的对象ID 解析HTTPS的方式 ------------------------------------------------------------------------ 《无懈可击的Kerberos》 Kerberos是一种身份认证协议,采用的方法:引入一个权威的第3方(KDC)来负责身份认证 KDC记录了域内所有账号和资源的密码
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
案例:《一个小时内给你答复》、《午夜铃声》、《深藏功与名》、《棋逢对手》 ===================================================================================== 《一个小时内给你答复》 一个案例:搭建NFS服务器,客户端一直无法挂盘 根因:NFS服务器限制了挂盘的源IP;但是网络环境中存在NAT设备,客户端的真实IP被NAT了。。 ------------------------------------------------------------------------ 《午夜铃声》 一个读性能的问题 1.抓包分析,存在很多重传(Retransmission)和大量的乱序(out-of-order) 乱序一般是由发送方or网络设备导致的 2.关闭了设备的LargeSegmentOffload和NIC teaming,确实不存在乱序了,但还是有比较高的重传 结论:重传和乱序无关;重新分析数据包后,发现虽然有乱序,但是凑不齐3个dup ack,无法触发快速重传 3.再度分析,重传的根因是接收设备的导致的乱序 4.根因:一张诡异的ghost盘导致的接收设备接收报文时存在乱序。。。更换系统后进行测试就ok了。。 抓包小技巧: 1.尽量把客户端和服务端处于同一个网络环境,较少中间网络的设备,排除网络设备的影响 2.乱序有时是由设备的NIC teaming导致的,可以尝试关闭 3.尽量在客户端和服务端同时抓包,进行对比 ------------------------------------------------------------------------ 《深藏功与名》 多台AIX(客户端)和Data Domain(服务端) 这个环境两端的带宽是不对等的: AIX连接的是1G接口 Data Domain连接的是10G接口 故障现象: 客户端写数据时,性能比较好,能超过90MB/s 客户端读数据时,性能比较差,20MB/s 一般存储设备,读比写更快 两端带宽不对等可能是根因 抓包分析发现,在读数据时,发现了很多重传,0.5%,这个对性能影响是很大的 所以该问题的根因确实就是两端带宽不对等,读数据时,流量较大,在交换机上产生了丢包 解决方法: 0.更换网络架构(不给更换) 1.修改Data Domain的发送窗口,改成一个较小值,降低拥塞几率 2.修改AIX的接收窗口,从而限制Data Domain的发送速度(该方案不合适,因为修改接收窗口影响的是AIX上的所有应用) 3.SACK,AIX默认关闭了SACK,导致了大量的不必要的重传(开启SACK后,减少了重传,同时因为快速重传的关系,速度确实提上来了,达到了客户的需求) 方法1/2需要估算合适的拥塞点: 根据在途数据来计算,在途数据左侧为起点,终点则是丢失的那个数据包的seq 假如发送了6个包,第6个包丢包了,那么5个数据包携带的字节数就是一个合适的拥塞点 ------------------------------------------------------------------------ 《棋逢对手》 故障场景: NFS文件服务器 客户端在访问文件时,偶尔会卡一下;症状不定时,无规律,稍纵即逝 可能原因: 1.服务器负载高,导致了响应慢; 2.网络拥塞,导致了重传 写了一个脚本进行测试,方便更多的复现现象,同时进行抓包 根据抓包结果的分析,排除了网络拥塞的可能,因为根本就没有重传 故障根因:防火墙拦截了报文 在多台客户端同时访问NFS服务器的同一个文件时,NFS会对文件上锁,后访问的拿不到锁,就会一直等待 在前一个客户端访问结束后,NFS服务器会释放该锁,同时通过NLM协议将该锁给到客户端。(中间涉及了一步服务端查询客户端的NLM端口号请求) 防火墙拦截了该请求!
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
《学无止境》---tshark ------------------------------------------------------------------------ 《学无止境》---tshark 1.windows命令行搜索tshark的输出 建议使用安装qgrep的windows resourece kit,使用方式类似linux命令行 2.三板斧查看性能问题 a.capinfos 123.pcap #查看抓包文件的统计信息 b。。。。 3.如何统计一个包里的所有对话 4.使用editcap对大pcap包进行切片 tshark官方说明:https://www.wireshark.org/docs/man-pages/tshark.html