0 借书如山倒，读书如抽丝
书写的挺有意思，由wireshark解决一个个问题的小经历组成，再引申一点其他的知识或者有趣的相关事件，比较引人入胜。
但看之前最好还是有系统的网络知识存储，比如这本书第一页的例子就需要用到ARP和子网掩码的知识，不然根本不知道语气愉悦的作者在乐些什么，当时的我虽然记得有ARP这么回事儿，但还是被吓到了，于是赶紧回去继续啃教材。等我看完谢希仁计网的前六章，再看它时就感觉比较通顺，能够和作者一块儿乐了。但一些没接触过的部分看的还是有点迷糊。有些太超纲的东西，比如Kerberos我就直接不整理笔记了。
估计这本书的后半部分应该在职业生涯里会常看常新，里边的例子虽然很多都看起来不深，但都是作者几年积攒下来的问题解决的经验。
1 初试锋芒
从一道面试题开始说起
两台服务器子网掩码
A 255.255.255.0
B被错配为255.255.255.224
默认网关192.168.26.2
结果：能正常通信
过程：
1号包：B通过子网掩码计算出A属于不同子网，通过ARP广播查询默认网关的MAC地址，进行跨子网转发。
2号包：默认网关向B回复自己的MAC地址。
3号包：B发出ping包，目的IP是A的，目的MAC是默认网关的。
4号包：B收到A发送的ARP广播，查询B的MAC地址，在A看来B属于相同子网，同子网通信不需默认网关参与，此包表明网关成功把3号包转给A。
5号包：B回复A的ARP请求，发MAC地址，说明ARP回复不考虑子网。
6号包：B收到A的ping回复。
小试牛刀
重启服务器A，就无法和B通信了。
问题大概出在A，收集A的配置
eth0 inet:192.168.26.131 bcast:192.168.26.255 mask:255.255.255.0
eth1 inet:192.168.174.131 bcast:192.168.174.255 mask:255.255.255.0
eth2 inet:192.168.186.131 bcast:192.168.186.255 mask:255.255.255.0
服务器B配置：ip地址 192.168.18.131 mask:255.255.255.0
ifconfig和route查出网卡和默认网关，A是多IP的服务器，配置路由方式一般是：假如自身有一个IP和对方在同一个子网，就从这个IP直接发包给对方，假如没有一个IP和对方同子网，就走默认网关。
在A上pingB时，AB不属于同一子网，需要默认网关转发，Aping网关是通的，
在链接默认网关的eth0上抓包，没有相关网络包，
在eth1抓包，A正在通过ARP寻找B的MAC地址，试图绕过网关与B直接通信，
说明A上存在一项符合192.168.18.131的路由，促使A通过eth1与B直接通信，
以前配置过该路由，后来删掉了，配置文件里还留着，重启时重新加载了一遍配置文件，于是又出现了。
检查路由表。
Excel文件的保存过程
用NotePad等编辑器保存：客户端：“我要写”，服务器：“写好了”。
微软保存：
创建一临时文件，把内容保存进里边，原来的文件被重命名为一个临时文件，把第一个临时文件命名为原来的文件名，最后删除第二个临时文件。
容易被占用。
你一定会喜欢的技巧
一、抓包
操作大包相当费时，尽量只抓必要的部分。
1.只抓包头
大部分时间只需要TCP/IP头，每包只抓前80字节，TCP，IP，数据链路都能抓到。
linux的tcpdump命令可加参数-s，（保存在文件中）
tcpdump -i eth0 -s 80 -w /tmp/tcpdump.cap
2.只抓必要的包
过滤器，filter表达式
tcpdump -i eth0 -s 80 host 10.32.200.131 -w /tmp/tcpdump.cap
设置之前三思，避免把有用的包也过滤掉，尤其是被忽略的广播包，比如NAT有可能把对方地址改掉。
把每步操作打上标记
ping IP -n 1 -1 1
操作步骤1
ping IP -n 1 -1 2
操作步骤2
ping IP -n 1 -1 3
操作步骤3
二、个性化设置
1.设置时间，和服务器同步时区/时间格式，方便
2.自定义网络包颜色
三、过滤
1.如果知道是哪个协议的问题，可以用协议名过滤
但要考虑到协议间的依赖性，比如NFS挂载失败，问题可能在挂载所用的mount协议，也可能在mount之前的portmap协议，用mount||portmap过滤
2.ip地址加端口号过滤
手工输入ip.addreq<IP地址>&&tcp.porteq<端口号>
右键单击感兴趣的宝，选择Follow，自动过滤
3.右键单击包，自动生成过滤表达式
4.过滤后得到的网络包存在文件里时，再打开时会显示很多错误，因为过滤后得到的不是一个完整的TCP Stream
四、让Wireshark自动分析
1.分析-专家信息
显示不同级别的提示信息，比如重传统计，连接建立，重置统计
2.统计-响应时间
3.统计-TCP流图形，可生成统计图
4.统计信息 平均流量等 推测负载状况
五、Ctrl+F
2 庖丁解牛
NFS协议的解析
“《鸟哥的Linux私房菜》中对NFS的介绍虽称得上友好，但美中不足的是不够深入，出了问题也不知道如何排查。”
文件分享，多用于Linux。
看到portmap请求没有得到回复，考虑防火墙对111端口的拦截
发现mount请求被服务器拒绝，检查共享目录的访问控制。
NFS对客户端的访问控制是通过IP地址实现的。创建共享目录时指定哪些IP允许读写，哪些只允许读，还有哪些连挂载都不允许，有可能会出现客户端IP被NAT转换成别的从而无法访问的问题。
NFS协议只认UID不认用户名，owner信息和UID有关，用户名与UID的对应关系是通过客户端的/etc/passwd决定的，在客户端A上，UID501对应用户名是admin，在客户端B上是nasamin，所以会出现不一样的情况。
读
Linux客户端读NFS共享文件时是多个READCALL连续发出的，WindowsCIFS是发一个Call，等收到Reply再发下一个。
每个READCall请求多少数据也会影响性能，在高性能环境中，要手动指定一个比较大的值，可以在mount时通过rsize参数来定义，比如“mount -o rsize=524288 10.32.106.62:/code/tmp/code”
写
挂载时默认参数是async写，多个call一起发出去，如果使用sync参数，writecall和replay就会交替出现，还可以在writecall上看，如果有unstable和file_sync就说明是sync，所以每个writecall写多少数据也是影响写性能的重要因素，可以在mount时用wsize参数指定
但在有些客户端启用sync参数之后wsize会被强制为4KB，从而导致写性能很差，有些特殊的应用要求服务器收到sync的写请求之后，一定要等到存盘才能回复writereply。
mount时如果用sync参数，读写性能都会下降，noac作用是让客户端不缓存文件属性，因为写会被强制改成sync方式，读会因为客户端频繁通过GETATTR查询文件属性，所以读的性能也受到影响，在高延迟的网络中影响尤为明显。
从Wireshark看网络分层
MTU 最大传输单元 大多数是1500字节，有些网络启用巨帧（Jumbo Frame），能达到9000字节，
MSS（Maximum Segment Size）
MSS+IP+TCP=MTU
TCP的连接启蒙
DNS一般用UDP，
Seq，该数据段的序号，单位字节
Len，数据段的长度，不包括TCP头，
Ack，确认号，接收方确认收到了哪些字节
TCP的确认可以累积
SYN，携带这个标志的包表示正在发起连接请求，链接是双向的，双方都要发一个SYN
FIN，表示正在请求终止连接，双方都要。
RST，重置一个混乱的连接，拒绝一个无效的请求。
实验环境中的RST一般意味着有大问题
标准建立过程：
[SYN] Seq=0
[SYN,ACK] Seq=0,Ack=1
[ACK] Seq=1,Ack=1
Seq=0因为WireShark启用了Relative Sequence Number，可以关闭
三次握手，当客户端丢掉的包又传到了服务器上，连接是旧的无效包时，客户端可以在第三次时发送一个拒绝请求
四次挥手，
[FIN,ACK]
[ACK]
[FIN,ACK]
[ACK]
用四次挥手来断开连接也不完全可靠
世界上不存在100%可靠的通信机制，著名“两军问题”
快递员的工作策略——TCP窗口
每个包的TCP层含有window size 这不是发送窗口，而是在向对方声明自己的接收窗口。
无法在包里看出发送窗口的大小。
TCP Window Scale
TCP头只给接收窗口留了16位，最大接收窗口无法突破65535字节。
window scale放在TCP头之外的options中，不需要修改TCP头的设计，是2的指数，再乘以TCP头中定义的接收窗口就是实际的接收窗口
重传的讲究
超时重传对性能有严重影响，万分之一的超时重传影响也很大。
1 RTO阶段不能传数据，相当于浪费了一段时间，
2 拥塞窗口急剧减小
三个以上重复确认：Dup Ack
没有拥塞时，发送窗口越大，性能越好。
如果经常发生拥塞，限制发送窗口能提高性能。
超时重传对性能影响最大，因为RTO时没有传输任何数据。
快速重传对性能影响小一些，因为它没有等待时间，且拥塞窗口减小的幅度没那么大。
SACK和NewReno有利于提高重传效率，提高传输性能。
丢包对极小文件的影响比大文件严重，因为读写一个小文件需要的包数量很少，所以丢包时往往凑不满3个Dup Ack，只能等待超时重传，大文件有较大可能触发快速重传。
延迟确认与Nagle算法
TCP有延迟确认，原理：如果收到一个包之后暂时没有什么数据要发送给对方，那就延迟一段时间再确认，假如在这段时间里恰好有数据要发送，那确认信息和数据就可以在一个包里发出去了。
延迟确认并没有直接提高性能，只是减少了部分确认包，减轻了网络复旦。有时候延迟确认反而会影响性能。
Nagle：在发出去的数据还没有被确认之前，假如又有小数据生成，那就把小数据收集起来，凑满一个MSS或者等收到确认后再发送。
百家争鸣
Westwood算法：先通过Ack推算出有多少包已经被送达接收方，从而更精确地估算发生拥塞时的带宽，最后再依据新的带宽来确定新的拥塞窗口。
Vegas算法：通过监控网络状态来调整发包速度，从而实现真正的拥塞避免。当网络状态良好时，数据包的RTT比较稳定，这时候可以增大拥塞窗口。反之减小。
（敏感，稳重，谦让的君子）
Compound算法：同时维持两个拥塞窗口，一个类似Vegas，一个类似RFC2581，真正起作用的是两者之和，走中庸之道，在保持谦让的前提下也不失进取。
Linux kernels2.6.18用的是BIC算法，2.6.19升级到CUBIC算法。后者比前者的行为保守一些，因为在网络状况非常糟糕的情况下，保守一点的性能反而更好。
简单的代价——UDP
UDP不在乎双方MTU的大小，拿到应用层的数据后，直接打上UDP头就交给下一层了，此时网络层负责分片，接收方收到分片后再组装起来，这个过程会消耗资源，降低性能。
UDP没有重传机制，丢包由应用层来处理，比如某个写操作需要六个包完成，当有一个包丢失时，客户端需要重传整个写操作。
分片机制存在弱点，会成为黑客的攻击目标，接收方之所以知道什么时候该把分片组装起来，是因为每一个包里都有一个More fragments的flag，1表示后续还有分片，0表示这是最后一个分片，可以组装了，如果黑客持续快速地发送flag为1的UDP包，接收方一直无法把这些包组装起来，就有可能耗尽内存。
剖析CIFS协议
Common Internet File System有三个版本：SMB，SMB2，SMB3，目前12比较普遍
端口号445
TCP连接
协商版本
建立CIFS Session
Session Setup 身份验证
打开共享 Tree Connect
服务器返回Tree ID，用这个ID去访问共享的子目录和子文献。
Q1 如果用户无权访问此目录，会不会在Tree Connect这一步失败？
不会，Tree Connnect并不检查权限，即使是无权访问的用户也能得到Tree ID，检查权限由接下来的Create操作完成。
Q2 某用户已经打开了一个文件，如果想打开另一个，需要再建立一个TCP连接吗？
没有必要，在一个TCP上可以维持多个打开的Tree Connect
查询文件的基本属性，标准属性，扩展属性，还有文件系统的信息。
Create Request
Create是CIFS中非常重要的一个操作，无论是新建文件，打开目录，还是读写文件，都需要Create，有时候因为没有权限遭遇Access Denied错误，或者覆盖文件时收到File Already Exists提醒，都是来自Create这个操作。
Q1 如果上级文件夹拒绝访问，但里边的文件夹允许访问，那他打开里边文件夹时会不会失败？
如果该用户先打开上级文件夹，就会在NT Create 上级文件夹这一步收到Access Denied报错，而如果在地址栏直接输入里层文件夹，就可以跳过NT这一步，所以不会有任何报错。
Q2 Windows 的 Backup Operators组中的用户有权限备份所有文件，但不一定有权限读文件，服务器是如何知道一个用户是想备份还是想读取的？
备份和读行为非常相似，都是依靠Read操作来完成，不同点在于，备份的时候在Create请求中的Backup Intent设为1，读的时候设为0，服务器就是依靠这个来决定是否允许访问的。
以下两个问题有些复杂，懒得看懂，无法将原句简写，所以把全文抄过来：
Q3 如果多个用户一起访问文件，CIFS该如何处理冲突？
在Create请求中有Access Mask和Share Access Mask两个选项。前者表示该用户对此文件的访问方式（读、写、删等），后者表示该用户允许其他用户对此文件的访问方式。举个例子，用户A发送的Create请求中，Access Mask是“读+写”，Share Access Mask是“读”，表示自己要读和写，并同时允许其他人只读。假如接下来用户B也发送Access Mask为“读+写”的Create请求，就会收到“Sharing Violation”错误，因为A不允许其他人写。图10中的Access Mask只是读。
注意：这里讨论的访问冲突指的是 CIFS 协议层的。有些应用软件还有专门的机制防止访问冲突，比如Word和Excel，但Notepad就没有。
Q4 CIFS如何保证缓存数据的一致性？
客户端可以暂时把文件缓存在本地，等用完之后再同步回服务器端。这是提高性能的好办法，就像我们写论文时，都喜欢把图书馆的资料借回来，以备随时查阅。假如不这样做，就得频繁地跑图书馆查资料，时间都浪费在路上了。当只有一个用户在访问某文件时，在客户端缓存该文件是安全的，但是在有多个用户访问同一文件的情况下则可能出现问题。CIFS采用了Oplock（机会锁）来解决这个问题。Oplock有Exclusive、Batch 和 Level2三种形式。Exclusive允许读写缓存，Batch 允许所有操作的缓存，而 Level 2 只允许读缓存。Oplock 也是在Create中实现的，如图11底部所示，该客户端被授予Batch级别的机会锁，表示他可以缓存所有操作。
为了更好地理解Oplock的工作方式，我们假设一个场景来说明。1.用户A用Exclusive/Batch锁打开某文件，然后缓存了很多修改的文件内容。2.用户B想读同一个文件，所以发了Create请求给服务器。3.如果此时服务器忽视A的Oplock，直接回复B的请求，那B就读不到被A 修改后的内容（也就是出现数据不一致）。因此服务器通知 A 释放Exclusive/Batch锁，换成Level2锁。4.A立即把缓存里的修改量同步到服务器上。5.服务器给B回复Create响应，同时授予其Level2锁。B接下来再发读请求，从而得到A修改后的文件内容。到了Create这一步，距离TCP连接的建立已经过去0.093秒。虽然听上去很短，但在局域网中已经算是很长一段时间了。这段时间足够我实验室的NFS服务器响应45个64KB的读操作，而本例中的读操作却刚要开始，可见CIFS协议有多啰嗦。这让我想起一个经典问题，“为什么复制一个 1MB 的文件比复制 1024个1KB的文件快很多，虽然它们的总大小是一样的？”原因就是读写每个文件之前要花费很多时间在琐碎的准备工作上。一个 1MB 的文件只需要准备一次，而1024个1KB的文件却需要1024次。从包号71开始，读操作终于出现了。如图12所示，CIFS的读行为看上去和NFS非常相似，都是从某个offset开始读一定数量的字节。文件的内容“I need a vacation!”能从包里直接看出，说明传输时没有加密。
还有很多有趣的行为是从这两个包里看不出来的，必须设计一些实验才能归纳出来。比如下面几个常见问题，可能很多读者会感兴趣。
Q1：同样是用SMB协议读一个文件，Windows XP和Windows 7的表现有何不同？Windows XP发了一个读请求之后就会停下来等回复，收到回复后再发下一个读请求。而Windows7则可以一口气发出多个读请求，就像NFS一样。两种读方式在延迟小的网络中体现不出差别，在带宽小的环境中差别也不大（因为发送窗口小，一个读请求本来就要多个往返才能传完）。但在高延迟、大带宽的环境中就很不一样了，Windows7的性能会比Windows XP好很多。在网络有丢包的情况下差别还会更大，因为Windows XP比Windows7更容易碰到超时重传。
Q2：利用 Windows Explorer 从 CIFS 共享上复制文件，为什么比Robocopy和EMCopy之类的工具慢很多？答案：如果复制一个大文件可能是看不出差别的，但如果是复制一个包含大量小文件的目录，的确是比这些工具慢很多。这是因为Windows Explorer是逐个文件复制的（单线程），而这些工具能同时复制多个文件（多线程）。比如上文提到的前0.093秒里虽然交互多次，但占用带宽极少，多个文件并行操作的效率会高很多。下面两个图是EMCopy的单线程和双线程复制同一文件夹的结果，后者明显要快得多。
Q3：从CIFS共享里复制一个文件，然后粘贴到同一个目录里，为什么还不如粘贴到客户端的本地硬盘快？答案：前者需要把数据从服务器复制到客户端的内存里，然后再从客户端的内存写到服务器上，相当于读+写两个操作。而后者只是从服务器读到客户端内存里，然后写到本地硬盘，相当于网络上只有读操作，这样就快了一些。
SMB3 对此有了本质上的改进，可以完全实现服务器端的本地复制，这样前者反而比后者快了。
Q4：在 CIFS 共享上剪切一个文件，然后粘贴到同一共享的子目录里，为什么就比粘贴到本地硬盘快呢？答案：在相同的文件系统上剪切、粘贴，本质上只有“rename”操作，并没有读和写，所以是非常快的。
Q5：为什么在Windows7上启用SMB2之后，读性能提高了很多？
答案：因为SMB2 没有SMB那么啰嗦。SMB2读之前的查询用了不到10个包，而SMB往往要用数十个包来查询各种信息。
网络江湖
复制粘贴过程实际是这样的。1.客户端发送读请求给服务器。2.服务器把文件内容回复给客户端（这些文件内容被暂时存在客户端内存中）。3.客户端把内存中的文件内容写到服务器上的新文件abc-Copy.txt中。4.服务器确认写操作完成。在这个过程中，文件内容通过第2步和第3步在网络上来回跑了两次，很浪费带宽资源。为此SMB3设计了一个叫“Offload Data Transfer”的功能，能够把过程变成这样。1.客户端向服务器发送复制请求。2.服务器给了客户端一张token。3.客户端利用这张token给服务器发写请求。4.服务器按要求写新文件。5.服务器告诉客户端复制已经完成。
可见在 SMB3 的复制过程中，我们只是在网络上传输了一些指令，而文件内容并没有出现在网络上，因为复制数据完全由服务器自己完成了。假如是复制一个大文件，那对性能的提升幅度是非常可观的，你甚至可以在数秒钟里复制几个GB的数据，远超网络的瓶颈。在虚拟化的应用场合中，通过这个机制克隆一台虚拟机也可以变得很快。SMB3的另一个破天荒改进是在CIFS层实现了负载均衡。与其他CIFS版本不同，一个SMB3Session可以基于多个TCP连接。Windows8服务器上的两个网卡，可以分别和文件服务器上的两个网卡建立TCP连接，然后一个SMB3 Session 就基于这两个连接之上。当其中一个 TCP 连接出现故障，比如网卡坏掉时，SMB3连接还可以继续存在。
DNS小科普
PTR记录：从Ip地址解析到域名。
SRV记录：Windows的域管理员要特别关心SRV记录，因为它指向域里的资源。比如我想知道我们公司的域 nas.com 里有哪些DC，只要随便在一台电脑上查询ldap.tcp.dc._msdcs.nas.com这个SRV记录就可以了。如果你也想查贵司的DC，请把nas.com改成正确域名即可。
CNAME记录：Alias记录，别名的意思。比如服务器同时提供www网页、mail邮件和map地图服务，客户端访问这三个域名时，都会被定向到主机ip地址上
别名是如何起作用的呢？当客户端查询 mail.nas.com 或者 map.nas.com 时， DNS服务器通过www.nas.com找到10.32.106.73，然后把结果返回给客户端。那直接把10.32.106.73配给mail和map可以吗？可以，但如果某天要改变这个IP地址，就不得不在DNS上修改www、mail和map这3项记录。而在使用别名的情况下，只要修改www一项的IP就行了，mail和map都没有必要改动。别名的使用节省了管理时间，站长们应该会喜欢这个功能。
递归查询：老板给我发个短信：“阿满，附近哪个川菜馆最正宗？”我屁颠屁颠地去问我的吃货朋友二胖，二胖又问了他的女友川妹子；川妹子把答案告诉二胖，二胖再告诉我，最后我装作很专业的样子回复了老板。这个过程对老板来说就是递归查询。
迭代查询：老板说：“阿满，推荐一下附近的洗脚店呗？”我立即严辞拒绝：“这个我不知道，不过你可以问问公关部的张总。”老板去找到张总，又被指引到销售部的小李，最终从小李那里问到了。这个过程就是迭代查询，因为是老板自己一步一步地查到答案。
我的DNS中有两个叫“Isilon-Cluster”的同名 A 记录，分别对应着 IP 地址 10.32.106.51 和10.32.106.52。当我连续执行两次“nslookup Isilon-Cluster.nas.com”时，两次返回的 IP 地址是一样的，但顺序却是相反的。如果我执行第三次nslookup，结果又会跟第一次一样，这就是DNS的循环工作（round-robin）模式。这个特性可以广泛应用于负载均衡。比如某个网站有10台Web服务器，管理员就可以在DNS里创建10个同名记录指向这些服务器的IP。由于不同客户端查到的结果顺序不同，而且一般会选用结果中的第一个IP，所以大量客户端就会被均衡地分配到10台Web服务器上。随着分布式系统的流行，这个特性的应用场景将会越来越多，比如本例中的分布式存储设备Isilon。
DNS的缺点
DNS 上也存在山寨域名。比如招商银行的域名是www.cmbchina.com，但是www.cmbchina.com.cn和www.cmbchina.cn却不一定属于招行。
DNS服务器被恶意修改。比如登录招行网站时虽然用了正确域名www.cmbchina.com，但由于DNS服务器是黑客控制的，很可能解析到一个钓鱼网站的IP。
即便是配了正规的DNS服务器，也是有可能中招的。比如正规的DNS服务器遭遇缓冲投毒之后，也会变得不可信。
DNS 除了能用来欺骗，还能当做攻击性武器。著名的 DNS 放大攻击就很让人头疼。下面是我在执行“dig ANY isc.org”（解析isc.org的所有信息）时抓的包，可见6号包发出去的请求只有25字节（Length:25），而11号包收到的回复却能达到3111字节（Length 3111），放大了124倍。
假如在 6 号包里伪造一个想要攻击的源地址，那该地址就会莫名收到 DNS服务器3111字节的回复。利用这个放大效应，黑客只要控制少量电脑就能把一个大网站拖垮了。
一个古老的协议——FTP
FTP 用最简单的方式实现了文件的传输，客户端只需要输入用户名和密码，就可以和服务器互传文件了；有的甚至连用户名和密码都不用（匿名FTP）。FTP常被用来传播文件，尤其是免费软件；另一个广泛应用是采集日志，我们可以让服务器发生故障之后，自动通过FTP把日志传回厂商。这些场合之所以适合FTP而不是NFS或者CIFS，就是因为它实现起来更加简单。
客户端连接FTP服务器的21端口仅仅是为了传输控制信息，我们称之为“控制连接”。当需要传输数据时，就重新建立一个 TCP 连接，我们称之为“数据连接”。随着文件传输结束，这个数据连接就自动关闭了。
连接分开后，就有机会在路由器上把控制连接的优先级提高，免得被数据传输影响了控制。
当文件下载到一半时突然反悔了，就可以 Abort（终止）这次下载。如果 Abort请求是通过优先级较高的控制连接发送的，也许能完成得更加及时。
FTP配置防火墙，由于数据连接的三次握手是由服务器端主动发起的（主动模式），如果客户端的防火墙阻挡了连接请求，传输不就失败了吗？
FTP的被动模式。
上网的学问——HTTP
要对这些加密包进行解码，只需要以下几个步骤（本例所用的网络包和密钥来自 http://wiki.wireshark.org/SSL 上的 snakeoil2_070531.tgz 文件，建议你也下载来试试）。1.解压 snakeoil2_070531.tgz并记住key文件的位置，比如C:\tmp\rsasnakeoil 2.key。2.用Wireshark打开rsasnakeoil2.cap。3.单击Wireshark的Edit-->Preferences-->Protocols-->SSL-->RSA keys list。然后按照IP Address,Port,Protocol,Private Key 的格式填好，如图10所示。既然HTTPS包能被解码，是不是说明它也不安全呢？事实并非如此，因为解码所用到的密钥只能在服务器端导出。
无懈可击的Kerberos
太复杂了，看不懂，甚至不想把原文粘贴在这。
我希望我一辈子都不会有需要搞明白Kerberos原理的时候。
作者原话：“如果这是你第一次认识 Kerberos，我估计已经看得云里雾里了。请相信这是人类的正常反应，我给好几批工程师培训过 Kerberos，几乎没有人能很快理清楚的。”
3 举重若轻
“一小时内给你答复”
总体上就是讲了个作者处理“NFS对客户端的访问控制是通过IP地址实现的。创建共享目录时指定哪些IP允许读写，哪些只允许读，还有哪些连挂载都不允许，有可能会出现客户端IP被NAT转换成别的从而无法访问的问题”的故事，所以挂载不上的时候要去查查IP地址有没有被NAT转换了。
午夜铃声
在作者的例子里，服务器读的性能差，他分析发现很多包发生重传，还有大量乱序，但重传并非乱序引起，问题的原因是一个20440的包一直乱序，放在了后边，很奇怪的例子。
深藏功与名
这个例子是，服务器到客户端的网络上存在瓶颈，重传太多，解决方法是启用SACK。
棋逢对手
文件服务器为多台Linux应用服务器提供NFS访问。访问文件时偶尔会卡一下，症状的出现是不定时的、稍纵即逝的。不知道接下来是什么时候，发生在哪台应用服务器上。NFS服务器172.16.2.80给客户端172.16.2.102发了一个Portmap请求，咨询其NLM进程的端口号。请求没有得到回复
性能问题三板斧
用Wireshark打开网络包。1.单击Statistics-->Summary。从Avg.MBit/sec看到，那段时间的流量不高，所以该存储的负担似乎并不重。2.单击Statistics-->Service Response Time-->ONC-RPC-->Program:NFS Version:3-->Create Stat，可以看到各项操作的Service Response Time都不错，这进一步说明该存储并没有过载。3.单击Analyze-->Expert Info Composite，从Error和Warning里都没有看到报错，这说明网络没有问题。假如有重传、乱序之类的现象，应该能在这个窗口里看到。
NLM Network Lock Manager。客户端用它来锁定服务器上的文件，从而避免和其他客户端发生访问冲突。
NLM工作过程总结如下。1.客户端甲→NLM_LOCK_MSG request→NFS服务器（甲尝试锁定一个文件）客户端甲←NLM_LOCK_RES granted ←NFS服务器（服务器同意了这个锁定）2.客户端乙→NLM_LOCK_MSG request→NFS服务器（乙尝试锁定同一个文件）客户端乙←NLM_LOCK_RES blocked←NFS服务器（因为该文件已经被甲锁定，所以服务器让乙等着）3.客户端甲→NLM_UNLOCK_MSGrequest→NFS服务器（甲尝试释放锁）客户端甲←NLM_UNLOCK_RES granted←NFS服务器（服务器同意释放）4.客户端乙←NLM_GRANTED_MSG←NFS服务器（服务器主动把锁给了乙）客户端乙→NLM_GRANTED_RES accept→NFS服务器（乙接受了）
Wireshark里看到的那个Portmap请求，发生在第三步和第四步之间。
1.第三步之后，服务器要通过Portmap查询乙的NLM端口号（也就是那个诡异的包），得到回复后才能进入第四步。2.假如查询端口号失败，则第四步无法进行，也就意味着服务器没有办法把锁给乙。3.由于乙得不到锁，所以只能继续等到超时为止。这对于应用程序来说，就是卡住了。4.该问题只发生在多个客户端同时访问同一文件的情况下，所以表现为偶发症状。5.乙没有响应Portmap查询，很可能是包被防火墙拦截了。
学无止境
tshark命令，它相当于Wireshark的命令行版本。和图形界面相比，命令行有一些先天的优势。命令行的输出可以通过awk之类的方式直接处理，这是图形界面无法实现的。有一些高手之所以说tshark的功能比Wireshark强大，也大多出于这个原因。
编辑命令虽然费时，但是编辑好之后可以反复使用，甚至可以写成一个软件。比如我经常需要进行性能调优，那就可以写一段程序来完成本书多次提到过的三板斧（Summary, Service Response Time 和 Expert Info Composite）。拿到一个性能相关的包之后，直接运行该程序就可以得到三板斧结果。
tshark 输出的分析文本大多可以直接写入分析报告中，而 Wireshark 生成不了这样的报告。比如说，我想统计每一秒钟里 CIFS 操作的 Service Response Time, 那只要执行以下命令就可以了，如下例所示。
tshark -n -q -r tcpdump.cap -z "io,stat,1.00,AVG(smb.time)smb.time"
这个结果导入Excel, 又可以生成各种报表。和其他软件一样，命令行往往比图形界面快得多。比如现在有一个很大的包需要用IP192.168.1.134过滤，用Wireshark操作的话先得打开包，再用ip.addr==192.168.1.134过滤，最后保存结果。这三个步骤都很费时，但是tshark用下面一条命令就可以完成了。
tshark -r tcpdump.log -R "ip.addr==192.168.1.134 " -w tcpdump.log.filtered
因为上述这些优势，一位工程师可能上手 tshark 之后很快就会舍弃Wireshark。