《wireshark网络分析就这么简单》总结
《从一到面试题开始说起》、《小试牛刀：一个简单的应用实例》、《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
《从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 ，这将导致严重的性能问题！
《重传的讲究》---发送窗口和网络拥塞；《延迟确认和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上，默认是关闭的
《简单的代价---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放大攻击
《一个古老的协议---FTP》、《上网的学问---HTTP》、《无懈可击的Kerberos》 ===================================================================================== 《一个古老的协议---FTP》 FTP服务端的控制端口21 。。。。 ------------------------------------------------------------------------ 《上网的学问---HTTP》 海量文件不适合传统的目录结构，所以云存储一半使用对象存储的方式： 客户端访问文件时，并不使用其路径和文件名，而是使用它的对象ID 解析HTTPS的方式 ------------------------------------------------------------------------ 《无懈可击的Kerberos》 Kerberos是一种身份认证协议，采用的方法：引入一个权威的第3方（KDC）来负责身份认证 KDC记录了域内所有账号和资源的密码
案例：《一个小时内给你答复》、《午夜铃声》、《深藏功与名》、《棋逢对手》 ===================================================================================== 《一个小时内给你答复》 一个案例：搭建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端口号请求） 防火墙拦截了该请求！
《学无止境》---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
