《从一到面试题开始说起》、《小试牛刀：一个简单的应用实例》、《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
《从一到面试题开始说起》、《小试牛刀：一个简单的应用实例》、《excel文件的保存过程》、《你一定会喜欢的技巧》（tcpdump抓包技巧）、《NFS协议的解析》
《从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 ，这将导致严重的性能问题！
《从wireshark看网络分层》、《TCP的连接启蒙》、《快递员的工作策略-TCP窗口》
《重传的讲究》---发送窗口和网络拥塞；《延迟确认和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上，默认是关闭的
《重传的讲究》---发送窗口和网络拥塞；《延迟确认和Nagle算法》；《百家争鸣》---各种拥塞算法
《简单的代价---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放大攻击
《简单的代价---UDP》、《剖析CIFS协议》《网络江湖》、《DNS小科普》
《一个古老的协议---FTP》、《上网的学问---HTTP》、《无懈可击的Kerberos》
=====================================================================================
《一个古老的协议---FTP》
FTP服务端的控制端口21
。。。。
------------------------------------------------------------------------
《上网的学问---HTTP》
海量文件不适合传统的目录结构，所以云存储一半使用对象存储的方式：
客户端访问文件时，并不使用其路径和文件名，而是使用它的对象ID
解析HTTPS的方式
------------------------------------------------------------------------
《无懈可击的Kerberos》
Kerberos是一种身份认证协议，采用的方法：引入一个权威的第3方（KDC）来负责身份认证
KDC记录了域内所有账号和资源的密码
《一个古老的协议---FTP》、《上网的学问---HTTP》、《无懈可击的Kerberos》
案例：《一个小时内给你答复》、《午夜铃声》、《深藏功与名》、《棋逢对手》
=====================================================================================
《一个小时内给你答复》
一个案例：搭建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
《学无止境》---tshark
标签：总结,窗口,重传,网络,拥塞,网络分析,发送窗口,客户端,wireshark From： https://www.cnblogs.com/AllenWoo/p/16949844.html